Please enable JavaScript.

Coggle requires JavaScript to display documents.

Implicit Asynchronous Communication Software Architecture (Buffered…

- - - - These two is connected by event registration process
      - No buffer available between them
  - - - Is event listener
        
        Register with event source
  - - - Framework availability: available vendor APIs (Java AWT, Swing components, etc.)
        
        Reusability of components: easy to plug-in new event handlers without affecting the rest of the system.
        
        System maintenance and evolution: Easy to update both of event sources and targets.
        
        Independency and flexible connectivity: Dynamic registration and deregistration can be done dynamically at run-time.
        
        Possibility of parallel execution of event handlings.
    - - Difficult to test and debug the system
        
        The event source cannot determine when a response finished or or the sequence of all responses.
        
        Reliability and overhead of indirect invocations
        
        There is more tight coupling between event sources and their listeners than in buffer-based implicit invocation.
- - - - They are connected asynchronously by either:
        
        message queue : one-to-one
        
        message topic: one-to-many
        
        message queue architecture is a point-to-point (P2P)
        structure between producer and consumer.
    - - sender sends out a message that requires only a guaranteed message delivery reply
      - typically implemented as a message-oriented middleware (MOM), which provides a reliable message service on a distributed system
      - Has been used for a long time
      - Used to build reliable, scalable, flexible distributed apps supporting asynchronous communication
      - just a peer-to-peer client-server architecture.
      - one of its most important features: high degree of independency between components
      - high scalability, interoperability in heterogeneous networks, and reliability => popular
  - - - Message Queue
        
        message is sent to a destination (a specific queue) maintainted by consumer
        
        consumer clients extract message from queues
        
        queue retains all messages received
        
        until messages are consumed, or
        
        until the messages expire
        
        Each message has only one consumer, i.e., the message will be “gone” once it is delivered.
        
        allow multiple receivers but one and only one of them will get the message, as determined by message service provider
    - - the receiver can still get the message even
        it was not available when the sender sent the message.
  - - - The system delivers the messages to all its multiple subscribers
  - - - Providing high degree of anonymity between message
        producer and consumer (with user independence, location independence, time independence)
        
        Supporting for concurrency among consumers and between producer and consumers.
        
        Providing scalability and reliability of message delivery;
        
        Supporting batch processing.
        
        Supporting loose coupling
        
        Reliability mechanism
        
        Control level setting of message acknowledgement
        
        Message persistence setting without loss
        
        Message priority level setting
        
        Message expiration setting
    - - Capacity limit of message queue. Not an inherent limitation but an implementation issue that can be eased. However, there is an absolute limit based on available memory. It is also difficult to determine the numbers of agents needed to satisfy the loose couplings between agents.
        
        Complete separation of presentation and abstraction by control in each agent generates development complexity since communication between agents only takes place between the control of agents.
        
        Increased complexity of the system design and implementation.