Chapter 8 - Implicit Asynchronous Communication Software Architecture

1. 8 Applicable domain of Non-Buffered Event-Driven architecure

1.1. Suitable for interactive GUI component communication and Integrated Development Environment (IDE) tools

1.2. Suitable for application

1.3. Suitable for implementation

1.4. Suitable when event handlings in the app are not predictable

1.5. Benefits

1.5.1. Framework availability

1.5.2. Reusability

1.5.3. Maintenance and evolution

1.5.4. Independency and flexible connectivity

1.5.5. Possibility of parallel execution of event handlings

1.6. Limitations

1.6.1. Difficult to test and debug the system

1.6.2. The event source cannot determine

1.6.3. Reliability and overhead of indirect invocations

1.6.4. More tight coupling

2. 7. Buffered Message-based software architecture

2.1. The buffered message-based software architecture breaks the software system into three partitions

2.1.1. M - producers

2.1.2. M - Consumers

2.1.3. M - Service providers

2.2. They are connected asynchronously by either a

2.2.1. M - queue: 1-1

2.2.2. M - topic: 1-n

2.3. This architecture is also considered data-centric

2.4. The message-based software architecture has been used for a long time

2.5. Messaging systems are used to build reliable, scalable, and flexible distributed applications supporting asynchronous communication

2.6. The messaging system architecture is just a peer-to-peer client-server architecture

2.7. The high degree of independency between components within the messaging system is one of its most important features

2.8. Its high scalability, interoperability in heterogeneous networks, and reliability also make the messaging system more popular

2.9. What is a message? A message is a structured data with a message id, message header, property, and a body

2.10. A typical example of a message is an XML document

2.11. What is messaging? Messaging is a mechanism or technology that handles asynchronous or synchronous message delivery effectively and reliably

2.12. A messaging client can produce and send messages to other clients, they can also consume messages from other clients

2.13. Each 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

3. 6. Applicable domain of Message-based architecture

3.1. Suitable for software system

3.2. Components can be easily replaced

3.3. The provider wants the application to run whether or not all other components are up and running simultaneously

3.4. The application business model allow a component to send information to another and to continue to operate on its own without waiting for an immediate response

3.5. Benefits

3.5.1. Providing high degree of anonymity between message and consumer

3.5.2. The message consumer does not know who produced the message

3.5.3. Supporting for concurrency among consumers and between producer and consumers

3.5.4. Providing scalability and reliability of message delivery, reliability mechanisms include

3.5.5. Supporting batch processing

3.5.6. Supporting loose coupling between message producers and consumers and between legacy systems and modern systems for integration development

3.6. Limitations

3.6.1. Capacity limit of message queue

3.6.2. Absolute limit based on available memory

3.6.3. Complete separation of presentation and abstraction

3.6.4. Increased complexity of the system design and implementation

3.6.5. A message receiver can still receive messages even if it is not running at the time the message was sent

3.6.6. 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

3.6.7. This architecture style is commonly used in the connection between the Model sub-system and the view sub-system in an MVC or PAC architecture

4. 1. Asynchronous Implicit Invocation Communications

4.1. Non-buffered

4.2. Buffered

5. 3. Non-buffered Event-base Implicit Invocation

5.1. Two partitions

5.1.1. Event sources

5.1.2. Event listers

5.2. Event registration process connects these two partitions

5.3. No buffer available between these two parties

6. 2. Observer pattern

6.1. Is another name used for this type of architecture

7. 5. Publish-Subscribe Messaging (P&S)

7.1. is a hub-like architecture

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

7.3. Topic message can have multiple consumers

7.4. The system delivers the messages to all its multiple subscribes instead of single receiver as in the message queue system

7.5. Publishers and subscribers have a timing coupling dependency

7.6. 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 subscribes are not active or not ready yet

8. 4. Point-to-point messaging (P2P)

8.1. P2P structure between producer and consumer

8.2. Composed of message queues, senders, and receivers

8.3. Each message is sent to a destination which is maintained by the consumer, consumer clients extract messages from these queues

8.4. The queue retains all message they receive either until the messages are consumed or until the message expire

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

8.6. This approach allows multiple message receivers but one and only one of them will get the message as determined by the message service provider.

8.7. A sender and a receiver of a message have no timing dependencies, that is, the receiver can still get the message even it was not available when the sender sent the message

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

8.9. It is much more reliable than simple event-listener based system we discussed earlier