GP.Message Handling

	GP	Message Handling	Version:	0.4
	Document type:	Generic Pattern	Owner:	J.A.H. Schoonderbeek

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:

Message Handling pattern

Generic Pattern Composition

This pattern is an aggregation of the following (mandatory and optional) functions, expressed in Generic Functions:

Icon	Function	Inclusion	Rationale
	Message Engine	recommended	The Message Engine is the core functionality of the Message Handling Pattern. It is responsible for receiving and sending messages, and comprises the intelligence for message processing (or delivering these messages to other facilities that process them). Among its tasks is making sure the messages are stored if they cannot continue on their way to the final recipient.
	Presentation Engine	recommended	Whether an instance of this Pattern is being used by humans or automated systems, it's often required that a Message Handling system can present and accept messages to and from the outside world in common, often open, standards. To this end, possible proprietary internal message formats need to be converted into the formats used outside of the facility, and vice versa. In this way, this function can be used to change message headers and/or content to enable communication between senders and receivers that use different message formats. Types of transformation encompass 'message splitting', 'message aggregation', 'message resequencing', 'message enrichment' and 'message content translation'.
	Controlling	recommended	This function models the manner in which the Pattern's administrators, and possibly authorized consumers, can administer message transmission. Since the messages handled by the Pattern may be business critical and/or have a certain level of confidentiality, care must be taken to limit access to this function to authorized users.
	Message Store	optional	Since this pattern may need to accommodate indirect communication between sender and receiver, messages may need to be stored in the process of their transfer. The Message Store function might have a temporary or a more long-term use, depending on it's location in the path of the message: intermediate stores along the way act as buffers only, but at the destination, a message may reside in the Message Store even after the recipient has read the message.
	Archiving	optional	This function moves messages to a different storage area within the message store environment, for example to free more expensive storage space and/or enforce message retention policies. This can be done automatically or by means of user intervention.
	Message Distribution	optional	This function is used to move messages to their intended destination, based on message addresses and/or message content. It enables a flexible usage of virtual paths (sometimes called Message Channels) between sender and receiver(s), without the necessity that senders have 'knowledge' of intermediate paths. On behalf of senders and receivers, this type of function does need routing information, either automatically or configured.
	Name Resolution	optional	This function may be used to resolve high-level addresses of message senders and receivers to corresponding lower-level addresses, e.g. from human readable email addresses to IP addresses. As such this function may be needed for advanced forms of message distribution
	Message Filtering	optional	In the process of sending and receiving messages, it is possible to filter messages, based on a set of predefined rules or mechanisms. Basic filtering is done by checking message metadata, more advanced filtering may comprise payload or content filtering. If rule-based filtering is used, then the rules may be stored in some sort of Permission Register.
	Data Scanning	optional	In the process of filtering messages, this function might be used to scan message metadata and/or content, in order to support filtering decisions.
	Header Modification	optional	In the process of message exchange, this facility can be used to change message headers to enable communication between senders and receivers that use different addressing and/or protocol formats.
	Message Transformation	optional	In the process of message exchange, this facility can be used to change message headers and/or content to enable communication between senders and receivers that use different message formats. Types of transformation encompass 'message splitting', 'message aggregation', 'message resequencing', 'message enrichment' and 'message content translation'.
	Message Responding	optional	This facility provides feed-back to message senders regarding the message sending and exchange process. For example, when a message is undeliverable, this facility reports failure of message delivery by formulating an appropriate message and sending it to the original message sender.

Services connected with this Generic Pattern

This Generic Pattern has the following mandatory and optional relations with adjacent Generic Services.

Service	Adjacency	Summary	Rationale
Authentication & Authorization	optional	This service can validate an identity claim, and it can validate the permissions required for an action, as part of an Authentication & Authorization process.	This adjacent facility can server a number of purposes: to validate permissions of senders, before accepting messages from these senders; to authenticate and authorize consumers/recipients that want to access messages contained in the facility; to provide Message Filtering with appropriate filtering rules.
Data Management	optional	This service provides its consumers the ability to manage strictly structured data.	The Pattern may be connected with a Data Management service to store some or all of the data processed by the Pattern: it may host the Message Store, sets of contact or address data, or configuration data.
File Storage	optional	This service offers clients the ability to store, retrieve and modify data in loosely structured form.	The Pattern may be connected with a File Storage service to store some or all of the data processed by the Pattern: it may host the Message Store, sets of contact or address data, or configuration data.
Archive Management	optional	This service provides the ability to create and use archives.	Messages contained in this facility may be archived outside of the facility, using this Archive Management service. Reasons for using an archive can be to reduce the storage requirements of a Message Store function; to conserve a copy of messages for future reference.

Applied Patterns based on this Generic Pattern

The following Applied Patterns are based wholly or in part on this Generic Pattern: