Please enable JavaScript.
Coggle requires JavaScript to display documents.
CHAPTER 8. IMPLICIT ASYNCHRONOUS COMMUNICATION SOFTWARE ARCHITECTURE -…
CHAPTER 8. IMPLICIT ASYNCHRONOUS COMMUNICATION SOFTWARE ARCHITECTURE
Implicit Asynchronous Comm
Can be specified in 2 different modes:
non-Buffered
Buffered.
Refer some architecture that apply the
publisher-subscriber patterns
producer-consumer patterns
The message queue and message topic
are typical buffered asynchronous architectures
subscribers/consumers need to register their interests with
the event/message is fired off
when available on the buffered message queue or topic
A message queue is
a one-to-one or point-to-point architecture
between message senders and message receivers
A message topic is a one-to-many architecture between publishers and subscribers
Non-Buffered Event-Based Implicit Invocations
Breaks the software system into 2 partitions:
Event sources
The event source class must provide mechanisms to
Register or Deregister event targets
To notify event targets of the occurrence of the event.
Event listeners.
Event targets must specify
The action in the handleEvent() method to respond to incoming events.
The event registration process connects these two partitions.
There is no buffer available between these two parties.
Above the concrete classes are the interfaces for event source and event listener.
Is a good solution for user interaction in a user interface application
Non-Buffered Event-Driven Architecture
Applicable Domain
Interactive GUI component communication
Integrated Development Environment (IDE) tools
Applications that require loose coupling between components
The implementation of state machines
When event handlings in the application are not predictable.
Benefits
Framework availability
Reusability of components
System maintenance and evolution
Independency and flexible connectivity
Possibility of parallel execution of event handlings
Limitations
Difficult to test and debug the system
The event trigger cannot determine
When the response finished
The sequence of all responses.
Tight coupling between event sources and their listeners
More 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
Reliability and overhead of indirect invocations may be an issue
Buffered Message-Based Software Architecture
Breaks the software system into 3 partitions:
Message producers
Message consumers
Message service providers
They are connected asynchronously by
a message queue
a message topic.
This architecture is also considered data-centric.
Is a peer-to-peer client-server architecture
The high degree of independency between components
Its high scalability, interoperability in heterogeneous networks, and reliability
A messaging client can
Produce message
Send messages to other clients
Also consume messages from other clients
Each client must register with
a messaging destination (a specific queue)
Point-to-Point Messaging (P2P)
The message queue architecture is a point-to-point structure between producer and consumer
Is composed of
Message queues
Senders
Receivers.
Each message is sent to a destination which is maintained by the consumer
Consumer clients extract messages from these queues.
The queue retains all messages they received
Until the messages are consumed
Or until the messages expire.
Each message has only one consumer
A sender and a receiver of a message have
no timing dependencies,
Requires every message sent to the message queue
must be processed successfully by a consumer
Publish-Subscribe Messaging (P&S)
Is a hub-like architecture
Message topic publishers and subscribers
are not aware of each other
publisher clients send messages to
a message topic that
acts like a bulletin board.
Difference between P&S from P2P
Each topic message can have multiple consumers
Have a timing coupling dependency
A message topic consumer
must subscribe the topic before it is published
unless subscription is a durable subscription
Message-Based Architecture
Applicable Domain
Where the communication between a producer and a receiver needs
Wants the components not to depend on information about other components' interfaces
Wants the application to run
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
Supporting for concurrency
among consumers
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
between legacy systems and modern systems for integration development.
Limitations:
Capacity limit of message queue
Difficult to determine the numbers of agents needed to satisfy the loose couplings between agents
Complexity development
caused by the complete separation of presentation and abstraction by control in each agent
Increased complexity of the system design and implementation