|Document type:||Building Block Type||Owner:|
This Building Block Type belongs to Working Area Middleware (MW). This facility can receive, process and/or send messages on behalf of its clients (be they users or other applications). A "message" in this context means a combination of
- a message header, containing a.o. addressing data, and possibly more message meta-data, and
- a message body, containing the actual message data.
The message engine can send and receives messages using one of the following two messaging styles:
Asynchronous messaging is a way of data exchange that makes use of a specific data format in order to make this data routable at application level. It transmits data without making use of an internal coordination mechanism between sender and recipient. Common messaging styles:
- Request-reply (note that this can be both synchronous and asynchronous);
- Fire and forget;
Asynchronous messaging has some advantages over synchronous messaging:
- There is no communication overhead from synchronization/coordination between sender and recipient;
- The recipient of the message doesn't have to be available or reachable at the moment the message is sent;
- The communication path that the message must travel need not be fixed and available; when a part of the communication path becomes unavailable while the message is in transit, a relay station may store the message until the path becomes available again (if a message store is available at that station) or reroute the message over another, available path;
- A recipient that was unavailable/unreachable at the moment of sending a message will still receive it, if a message store is used (often referred to as queue). The message can always be retrieved by the recipient at a later time from the store that retains the message;
- One sender can reach many recipients, by broadcasting (or multicasting) a message to a specific group recipient address.
Asynchronous messaging also has some disadvantages over synchronous messaging:
- Information required to detect and or/recover data from lost communication is not provided by the messaging facility itself. If detection of/recovery from message loss is needed, it should be provided by sender and receiver(s) separately, for example by making use of a separate set of (synchronous) messages or another way of data exchange.
- The very nature of asynchronous messaging precludes the sender to know when the recipient actually receives the message.
Disadvantages can be overcome by the appliance of a Message Store facility.
Synchronous messaging transmits data in an established, synchronized relationship between sender and receiver. Messages are only sent when the sender knows that the receiver is ready to receive the data, and at the speed and/or data amount the sender knows the recipient can handle. The synchronization mechanism ensures sequentiality, e.g. by timing the communication to a fixed clock signal, or by using sequence numbers.
Typically, an internal coordination mechanism is available to enable automated error detection and recovery (reliable message exchange).
Synchronous messaging offers some distinct advantages over asynchronous messaging:
- The synchronization mechanism usually lends itself to promotion of reliable messaging where the sender has a certain level of certainty that the message that was sent is actually received;
- Synchronous messaging makes it possible for the sender to predict when the recipient actually receives the message.
Synchronous messaging also has some disadvantages over asynchronous messaging:
- The recipient of the message must be available (reachable) at the moment the message is sent;
- All parts of the communication path that the message must travel need to be available. When a part of the communication path becomes unavailable while the message is in transit and no rerouting is possible, the sequentiality of the communication is lost;
- There is communication overhead from synchronization/coordination between sender and recipient.
Examples for the use of Synchronous Messaging facilities are:
- instant messaging (IM).
Besides sending and receiving messages, a message engine can also perform other message-related tasks. While some of these tasks have been described in their own separate infrastructure functions (e.g. message filtering), all other tasks may be considered part of the message engine, a.o.:
- constructing messages for the client, based on the offered message data and addressing data (message encapsulation);
- deconstructing received messages for the client (message decapsulation);
- validating a message upon receiving it, or prior to sending it.
The icon below can be used to represent this infrastructure function in graphical Pattern representations that it might be part of:
Variants of this Building Block Type
The following variants of this function have been defined:
No Pattern Variants based on this Pattern Type (yet)
Pattern Types using this Building Block Type
The following Pattern Types use this function:
|Pattern Variant||Brief Description||Owner||Maturity|
|PAT.Message Handling||Message Handling||S.A.D. Jumelet||3|