GP.Message Handling
Page maturity This page has maturity level 4 (mature) |
GP | Message Handling | Version: | 0.4 | ||
---|---|---|---|---|---|
Document type: | Generic Pattern | Owner: |
This Pattern accepts messages from senders, and then handles transport, storage, and delivery to recipients. |
Description
This Generic Pattern belongs to "Commons". This infrastructure function accepts chunks of digital data, or "messages", from parties called senders, and then handles transport, storage, and delivery of these messages to parties called recipients. The parties involved may be human users, digital systems, or even the digital equivalent of a mailboxes of which it is not known in advance who or what will send or collect the message. Any consumer of (the service delivered by) this Pattern may be a sender, a recipient, or both.
A message may be directed at a single recipient or multiple recipients, and the message may be delivered (near-) realtime or asynchronously. 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.) The message header may be invisible/inaccessible to the consumers of the Message Handling service.
- Message body: this contains the data transmitted to the intended recipient(s). The semantics of the message body data must be known to the intended recipient(s).
Important aspects of a Message Handling Pattern are:
- this Pattern makes it unnecessary for the sender to be in direct contact with the recipient(s);
- if any routing of the message is required, it is handled mainly or fully by this Pattern;
- the Pattern may provide a sender with acknowledgment of the message's reception, or not ("fire and forget").
The Generic Pattern already has a sizeable amount of optional Generic Functions and Generic Services. However, please note that in the interest of brevity, the following aspects have not been included (as either recommended or optional). These may require consideration nevertheless:
- The Data Transport service(s) that will actually carry the messages from sender to (an instance of) the Pattern, between (instances of) the Pattern, and from (an instance of) the Pattern to the recipients;
- Encryption and compression (Reduction), which may operate on individual messages and/or on the communication channels that the Pattern uses;
- Load Balancing and Queuing, which may be handled outside of (an implementation of) this Pattern, or may need to be included explicitly.
Services realized
This Pattern realizes the following service(s):
- Message Handling (This service handles transport, storage and delivery of messages between senders and recipients.)
Functional and Integration view
This is the graphic representation of the functional model of this Generic Pattern:
Generic Pattern Composition
This pattern is an aggregation of the following (mandatory and optional) functions, expressed in Generic Functions:
Icon | Function | Inclusion | Rationale |
Services connected with this Generic Pattern
This Generic Pattern has the following mandatory and optional relations with adjacent Generic Services.
Service | Adjacency | Summary | Rationale |
Applied Patterns based on this Generic Pattern
The following Applied Patterns are based wholly or in part on this Generic Pattern: