Please enable JavaScript.
Coggle requires JavaScript to display documents.
Software Architecture and Design Illuminated CH8 - Coggle Diagram
Software Architecture
and Design Illuminated CH8
Chapter 8 IMPLICIT
ASYNCHRONOUS COMMUNICATION SOFTWARE ARCHITECTURE
8.1 Overview
Also called publisher-subscriber or producer-consumer patterns , where:
Also called publisher-subscriber or producer-consumer patterns , where Consumers are interested in some events or messages issued by a producer
Two different modes:
Non-buffered
Buffered
8.2 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
There is no buffer available between these two parties
The event registration process connects these two partitions.
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
Benefit:
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 syste
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.
Limitation
Reliability and overhead of indirect invocations may be an issue.
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
There is more tight coupling between event sources and their listeners than in buffer-based implicit invocation
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.
8.3 Buffered Message-Based Software Architecture
Benefits:
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 settin
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
Supporting loose coupling between message producers and consumers and between legacy systems and modern systems for integration development
Supporting batch processing.
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 agent
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
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.
Increased complexity of the system design and implementation
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
The buffered message-based software architecture breaks the software system into three partitions:
Message
producer
Message consumers
Message service providers.
They are connected asynchronously by either a
message queue : one-to-one
message topic: one-to-many
This architecture is also considered data-centric.
The message-based software architecture has been used for a long time.
Messaging systems are used to build reliable, scalable, and flexible distributed applications supporting asynchronous communication
The messaging system architecture is just a peer-to-peer client-server architecture.
Point-to-Point Messaging (P2P)
The message queue architecture is a point-to-point
structure between producer and consumer
A P2P messaging architecture is composed of message
queues, senders, and receivers.
Each message is sent to a destination (a specific queue) which is maintained by the consumer; consumer clients extract messages from these queue
P2P messaging requires every message sent to the message queue must be processed successfully by a consumer.
It is much more reliable than simple event-listener based system we discussed earlier.
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)
Message topic publishers and subscribers are not aware of each other.
Publishers and subscribers have a timing coupling dependency.
The system delivers the messages to all its multiple subscribers instead of single receiver as in the message queue system.
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 ye
One difference between P&S from P2P is that each topic message can have multiple consumers.
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