Scribd
Upload
17 views18 pages

Lecture 9 - SDaA

Uploaded by

qg6rtwm8f2
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPT, PDF, TXT or read online on Scribd
17 views18 pages

Lecture 9 - SDaA

Uploaded by

qg6rtwm8f2
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPT, PDF, TXT or read online on Scribd
You are on page 1/ 18

Software Design and

Architecture

Implicit Asynchronous
Communication Architecture

Chapter 8 of Kia Qian Book


Implicit Asynchronous Communication
Architecture

 Overview
 Asynchronous implicit invocation communication
 Non-buffered
 Buffered.
 Publisher-subscriber (producer-consumer)
 Subscribers are interested in some events/messages
issued by a publisher
 Subscribers register themselves with the event source.
 Once an event is fired off by an event source, all
corresponding subscribers are notified.
 It is up to the subscribers to decide on the actions to
execute.
Implicit Asynchronous Communication
Architecture
 Publisher-subscriber (producer-consumer)
 The message queue or topic are typical buffered
asynchronous architectures
 subscribers need to register their interests with the
 event/message is fired off when available on the buffered
message queue or topic.
 A Message queue: one-to-one or point-to-point architecture
between message senders and message receivers;
 A Message topic: one-to-many architecture between
publishers and subscribers.
Non-Buffered Event-Based Implicit Invocations

 The architecture breaks the system into two partitions:


 Event sources

 event listeners.
 The event registration process connects these two partitions.
 There is no buffer available between these two parties.
Non-Buffered Event-Based Implicit Invocations
Non-Buffered Event-Based Implicit Invocations

: Service : Service
requester provider

service ()

AsyncService ()

serviceResponse ()
Non-Buffered Event-Based Implicit Invocations

Event Source
Event Listener
+addEventListener()
+removeEventListener() +handleEvent()
+notify()

Concrete Event Source


-state Concrete Listener
+notify() -state
+getState() +handleEvent()
+setState()
Non-Buffered Event-Based Implicit Invocations

 Benefit
 Availability
 Reusability: Easy to plug-in new event handlers without
affecting the rest of the system.
 Maintenance and Evolution: Easy to update both of event
sources and targets.
 Flexibility: Dynamic registration and deregistration can be
done dynamically at run-time.
 Possibility of parallel execution of event handlings.
Buffered Message-Based Software
Architecture

 The architecture breaks into three partitions:


 Message producers,
 message consumers, and
 message service providers.
 They are connected asynchronously by either
 a message queue
 a message topic.
 This architecture is also considered data-centric.
Buffered Message-Based Software
Architecture
 What is a message?
 A message is a structured data with an id, message header, property, and
body, e.g. an XML document.
 What is messaging?
 A mechanism or technology that handles asynchronous or synchronous
message delivery effectively and reliably.
 A messaging client can send messages to other clients and
receive messages from other clients.
 A client must register with a messaging destination in a
connection session provided by a message service provider for
creating, sending, receiving, reading, validating, and processing
messages.
Point-to-Point Messaging (P2P)
 A P2P messaging architecture is composed of message queues,
senders, and receivers.
 Each message is sent to a specific queue maintained by the
consumer
 The queue retains all messages until either the messages are
consumed or the messages expire.
 Each message has only one consumer, i.e., the message will be
“gone” once it is delivered.
 This approach allows multiple receivers but only one of them
will get the message.
 P2P messaging requires every message in the queue be
processed by a consumer.
Point-to-Point Messaging (P2P)
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.
 Normally a message topic consumer must subscribe the topic
before it is published
Publish-Subscribe Messaging (P&S)
Buffered Message-Based Software
Architecture
 Applications
 Suitable for systems where the communication 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.
 A component can send information to another and continue to
operate on its own without waiting for an immediate
response.
Buffered Message-Based Software
Architecture
 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.
Buffered Message-Based Software
Architecture
 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

You might also like