Implicit Asynchronous Communication Software Architecture

Overview

Also called publisher-subscriber or producer-consumer
patterns

Two different modes

Non-buffered

Buffered

subscribers/consumers are interested in some events or messages issued by a publisher/producer

Nonbuffered Event-Based Implicit Invocations

Buffered Message-Based Software Architecture

Overview

breaks the software system into two partitions:

  • Event sources
  • Event listeners.

These two is connected by event registration process

No buffer available between them

Observer Pattern

another name used for this type

Subscribers

  • Is event listener
  • Register with event source

event source fires of event => corresponding subscribers are notified => take corresponding actions.

Applicable Domain

  • Interactive GUI component communication and IDE tools
  • Applications that require loose coupling between components that need to notify or trigger others
  • Implementation of state machine
  • When event handlings in the application are unpredictable

Evaluation

Benefits

Limitations

  • Framework availability: available vendor APIs (Java AWT, Swing components, etc.)
  • 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.
  • Difficult to test and debug the system
  • The event source cannot determine when a response finished or or the sequence of all responses.
  • Reliability and overhead of indirect invocations
  • There is more tight coupling between event sources and their listeners than in buffer-based implicit invocation.

Overview

breaks the software system into three partitions:

  • Message Producers
  • Message Consumers
  • Message Service Providers

They are connected asynchronously by either:

  • message queue : one-to-one
  • message topic: one-to-many

Is also considered data-centric.

Message-based system (fire and forget system)

sender sends out a message that requires only a guaranteed message delivery reply

typically implemented as a message-oriented middleware (MOM), which provides a reliable message service on a distributed system

Has been used for a long time

Used to build reliable, scalable, flexible distributed apps supporting asynchronous communication

just a peer-to-peer client-server architecture.

one of its most important features: high degree of independency between components

high scalability, interoperability in heterogeneous networks, and reliability => popular

Message?

structured data with a message id, message header, property, and a body. Example: XML document

Messaging?

Mechanism or technology handles asynchronous or synchronous message delivery
effectively and reliably.

Message clients

  • produce and send messages
  • consume messages

must register with a messaging destination in a
connection session provided by a message service provider

Point-to-Point Messaging (P2P)

Publish-Subscribe Messaging (P&S)

message queue architecture is a point-to-point (P2P)
structure between producer and consumer.

message queue architecture is a point-to-point (P2P)
structure between producer and consumer.

composed of message queues, senders, and receivers.

Message Queue

  • message is sent to a destination (a specific queue) maintainted by consumer
  • consumer clients extract message from queues

queue retains all messages received

  • until messages are consumed, or
  • until the messages expire

Each message has only one consumer, i.e., the message will be “gone” once it is delivered.

allow multiple receivers but one and only one of them will get the message, as determined by message service provider

A sender and a receiver of a message have no timing dependencies,

the receiver can still get the message even
it was not available when the sender sent the message.

requires every message sent to the message
queue must be processed successfully by a consumer.

much more reliable than simple event-listener

Hub-like architecture, where publisher clients send messages to a message topic that acts like a bulletion board

Message topic publishers and subscribers are not aware of each other.

each topic message can have multiple consumers.

The system delivers the messages to all its multiple subscribers

Publishers and subscribers have a timing coupling dependency.

Durable subscription: is able to receive any topic messages sent while the subscribers are not active or not ready

A message topic consumer must subscribe the topic before it is published unless subscription is a durable subscription

Applicable Domain

Evaluation

Benefits

Limitation

  • Software system where the communication need buffered message-based asynchronous implicit invocation for performance and distribution
  • provider wants the components not to depend on information about other components' interface => these components can be easily replaced
  • provider wants the application to run whether or not all others are up and running simultaneously
  • application business model allows a component to send information to another and continue to operate on its own without waiting for response
  • Providing high degree of anonymity between message
    producer and consumer (with user independence, location independence, time independence)
  • Supporting for concurrency among consumers and between producer and consumers.
  • Providing scalability and reliability of message delivery;
  • Supporting batch processing.
  • Supporting loose coupling

Reliability mechanism

Control level setting of message acknowledgement

Message persistence setting without loss

Message priority level setting

Message expiration setting

  • Capacity limit of message queue. Not an inherent limitation but an implementation issue that can be eased. 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.