GF.Message Engine
 | Page maturity This page has maturity level 3 (usable) |
|
GF | Message Engine | Version: | 0.2 | 
|
|---|---|---|---|---|---|
| Document type: | Generic Function | Owner: |
 | This function can receive, process and/or send messages. |
Description
This Generic Function belongs to Working Area Middleware. This function can receive, process and/or send chunks of digital data, or "messages". A message can most always be thought of to consist of two different sets of information:
- Message header: this contains the information necessary to route and deliver the message. A message header is analogous to the information printed on the outside of a letter (to, from, priority of message etc.);
- Message body: this contains the data transmitted in the message. The semantics of the message body data must be known to the intended recipient(s).
The message engine can send and receives messages using one of the following two messaging styles:
Asynchronous messaging
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;
- Publish-subscribe.
Asynchronous messaging has some advantages over synchronous messaging:
- 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.
Some of the disadvantages can be overcome by the appliance of Message Store functionality.
Synchronous messaging
Synchronous messaging transmits data in an established, synchronized relationship between sender and recipient. Messages are sent when the sender has assessed that the recipient is ready to receive the data, and using appropriate means (think parameters like speed, error correction etc). A synchronization mechanism ensures sequentiality, e.g. by timing the communication to a fixed time signal, or by using sequence numbers. An internal coordination mechanism may be used 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 in advance when the recipient will actually receive the message, and confirm after the fact that the message was actually received.
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;
- Also, 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 may be lost;
Message processing
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.:
- Validating a message upon receiving it, or prior to sending it;
- Allowing for authentication of service consumers (senders and/or recipients);
- Allowing for authorization of message related activity;
- Responding to events (such as delivery notification) by sending out a message on its own behalf.
Icon
The image "Icon GF Message Engine.png" (shown below) can be used to represent this infrastructure function in graphical Pattern representations that it might be part of:
Generic Patterns using this Generic Function
The following Generic Patterns use this function:
| Applied Pattern | Owner | Maturity |
|---|---|---|
| Message Handling | J.A.H. Schoonderbeek | 4 |
Applied versions of this Generic Function
The following variants of this function have been defined:
No Applied Pattern based on this Generic Pattern (yet)
