IMPLICIT ASYNCHRONOUS COMMUNICATION SOFTWARE ARCHITECTURE
Asynchronous implicit invocation communications
Also called publisher-subscriber or producer-consumer patterns , where
Two different modes:
Buffered
Non-buffered
Consumers are interested in some events or messages issued by a producer
Subscribers are interested in some events or messages issued by a publisher. OR
Non-Buffered Event-Based Implicit Invocations
The non-buffered event-based implicit invocation architecture breaks the software system into two partitions: Event sources and event listeners.
The event registration process connects these two partitions.
There is no buffer available between these two parties.
Observer pattern
The Observer pattern is another name used for this type of architecture.
Subscribers is an event listener and register themselves with the event source.
Once an event is fired off by an event source, all corresponding subscribers are notified, which then take corresponding actions.
Applicable Domain of Non-Buffered Event-Driven Architecture:
Suitable for interactive GUI component communication and Integrated Development Environment (IDE) tools.
Suitable for applications that require loose coupling between components that need to notify or trigger other components to take actions upon asynchronous notifications.
Suitable for the implementation of state machines.
Suitable when event handlings in the application are not predictable.
Benefits:
Framework availability: Many vendor APIs such as Java AWT and Swing components available.
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.
Limitations:
Difficult to test and debug the system
Hard to predict and verify responses and the order of responses from the listeners.
The event source cannot determine
when a response finished or
the sequence of all responses.
Reliability and overhead of indirect invocations may be an issue.
There is more tight coupling between event sources and their listeners than in buffer-based implicit invocation.
Buffered Message-Based Software Architecture
The buffered message-based software architecture breaks the software system into three partitions:
They are connected asynchronously by either a
This architecture is also considered data-centric.
Message producers
Message consumers
Message service providers.
message queue : one-to-one
message queue : one-to-one
The messaging system architecture is just a peer-to-peer client-server architecture.
The high degree of independency between components within the messaging system is one of its most important features.
Its high scalability, interoperability in heterogeneous networks, and reliability also make the messaging system more popular.
Publish-Subscribe Messaging (P&S)
The P&S messaging architecture is a hub-like architecture, where publisher clients send messages to a message topic that acts like a bulletin board.
Message topic publishers and subscribers are not aware of each other.
One difference between P&S from P2P is that each topic message can have multiple consumers.
The system delivers the messages to all its multiple subscribers instead of single receiver as in the message queue system.
Publishers and subscribers have a timing coupling dependency.
A message topic consumer must subscribe the topic before it is published unless subscription is a durable subscription, which is able to receive any topic messages sent while the subscribers are not active or not ready yet.
Applicable Domain of Message-Based Architecture:
Suitable for a software system where the communication between a producer and a receiver needs buffered message-based asynchronous implicit invocation for performance and distribution purposes.
The provider wants the components not to depend on information about other components' interfaces, so that components can be easily replaced.
The provider wants the application to run whether or not all other components are up and running simultaneously.
The application business model allows a component to send information to another and to continue to operate on its own without waiting for an immediate response.
Benefits
Providing high degree of anonymity between message producer and consumer.
The message consumer does not know who produced the message (user independence), where the producer lives on the network (location independence), or when the message was produced (time independence).
Supporting for concurrency among consumers and between producer and consumers.
Providing scalability and reliability of message delivery; reliability mechanisms include
Control level setting of message acknowledgement
Message persistence setting without loss
Message priority level setting
Message expiration setting
Supporting batch processing.
Supporting loose coupling between message producers and consumers and between legacy systems and modern systems for integration development.
Limitations
Capacity limit of message queue. This is not an inherent limitation but an implementation issue that can be eased if the queue is implemented as a dynamic data structure (e.g., linked lists).
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 generate development complexity since communications between agents only take place between the control of agents.
Increased complexity of the system design and implementation
A message receiver can still receive messages even if it is not running at the time the message was sent.
In an event-based invocation system the event handler must be ready in order to be able to intercept an event and take an action upon that event.
This architectural style is commonly used in the connection between the Model sub-system and the View sub-system in an MVC or PAC architecture.