Please enable JavaScript.
Coggle requires JavaScript to display documents.
Chapter 8 Implicit Asynchronous Communication Software Architecture -…
Chapter 8 Implicit Asynchronous Communication Software
Architecture
Nonbuffered Event-Based Implicit Invocations
architecture breaks the software system into two partitions:
event sources
event listeners
The event registration process connects these two partitions
event-based implicit invocations
part of SmallTalk language where each object keeps its own dependency list.
Applicable domains of nonbuffered event-driven architecture:
■ Interactive GUI component communication and integrated development environment (IDE) tools
■ Applications that require loose coupling between components that need to notify or trigger other components to take actions upon asynchronous notifications
■ The implementation of state machines
■ When event handlings in the application are not predictable
Benefits:
■ Framework availability: Many vendor APIs such as Java AWT and Swing components are available.
■ Reusability of components: It is easy to plug in new event handlers without affecting the rest of the system.
■ System maintenance and evolution: Both event sources and targets are easy to update.
■ Independency and flexible connectivity: Dynamic registration and deregistration can be done dynamically at runtime.
■ Parallel execution of event handlings is possible.
Limitations:
■ It is difficult to test and debug the system since it is hard to predict and verify responses and the order of responses from the listeners. The event trigger cannot determine when a response has finished or the sequence of all responses.
■ There is tighter coupling between event sources and their listeners than in message queue-based or message topic-based implicit invocation. Data sharing and data passing in the event object forwarded from event sources to event listeners also make the coupling tighter and somewhat hard to debug and test.
■ Reliability and overhead of indirect invocations may be an issue
Related architecture:
■ PAC, message-based, MVC, multi-tier, and state machine architectures
Buffered Message-Based Software Architecture
breaks the software system into three partitions
message consumers
message service providers
message producers
Messaging systems are used to build:
scalable
flexible distributed applications supporting asynchronous communication
reliable
Messaging system architecture
essentially a peer-to-peer client-server architecture
Messaging-based architectures
widely used in the infrastructure for network management, telecommunication services, e-commerce, customer care, weather forecasting, supply chain management, banking systems, and many other systems.
A message-based software application consists of the following parts
A messaging service provider or message server: A messaging system that provides administrative and control features such as connection, session, and destination.
Clients of message service: Software components that produce and consume messages.
Messages: The objects that communicate information between message senders and message consumers.
Applicable domains of message-based architecture:
■ Suitable for a software system where the communication between a producer and a receiver requires buffered message-based asynchronous implicit invocation for performance and distribution purposes.
« The provider wants components that function independently of information about other component interfaces so that components can be easily replaced
■ The provider wants the application to run whether or not all other components are running simultaneously.
■ The application business model allows a component to send information and to continue to operate on its own without waiting for an immediate response.
Benefits:
■ Anonymity: provides 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).
■ Concurrency: supports concurrency both among consumers and between producer and consumers.
■ Scalability and reliability of message delivery: Reliability mechanisms include: control level setting of message acknowledgement; message persistence setting without loss; message priority level setting; and message expiration setting.
■ Supports batch processing.
■ Supports loose coupling between message producers and consumers, and between legacy systems and modern systems for int gration development.
Limitations:
■ Capacity limit of message queue: This is not an inherent limitation but an implementation issue that can be minimized 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 generates development complexity since communication between agents only takes place between the control of agents.
■ Increased complexity of the system design and implementation
Related architecture:
■ Event-based system, layered, multi-tier, and MVC