PAT.Message Handling

Informational

Page maturity
This page has maturity level 3 (usable)

	PAT	Message Handling	Version:	0.4
	Document type:	Pattern Type	Owner:	S.A.D. Jumelet

Informational

Create commentary

Description

This Pattern Type belongs to "Infrastructure Sector Commons". This Pattern handles transport, storage and delivery of messages between senders and recipients, which may be users, applications or other infrastructure facilities.

Graphical Overview

This is the graphical representation of the infrastructure functions in this Pattern Type, plus their main relations:

Message Handling

(The source file of this picture can be downloaded here).

Pattern Type Composition

This pattern has the following mandatory and optional subfunctions, expressed in Building Block Types:

Icon	Function	WA	Inclusion	Rationale
	Message Engine	MW	mandatory	The Message Engine is the core facility of the Message Handling Pattern. It is responsible for receiving and sending messages, processing them (or delivering these messages to other facilities that process them), and making sure the messages are stored if they cannot continue on their way to the final recipient.
	Name Resolution	NW	optional	This facility may be used to resolve high-level addresses of senders and receivers to corresponding lower-level addresses, e.g. from human readable mail addresses to IP addresses.
	Message Distribution	MW	mandatory	This facility is used to direct messages to their 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 facility does need routing information, either automatically or configured.
	Header Modification	MW	optional	In the process of message distribution, this facility can be used to change message headers to enable communication between senders and receivers that use different addressing formats.
	Message Transformation	MW	optional	In the process of message distribution, 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	MW	optional	This facility provides feed-back to message senders regarding the message sending and distribution 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.
	Message Store	MW	mandatory	Since this pattern must allow indirect communication between sender and receiver, messages need to be stored in the process of their transfer. The message store facility 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 client has read the message.
	Archiving	ST	optional	This facility archives messages that are placed into the Message Store. This way, it is possible to conserve a copy of a messages for future reference.
	Message Filtering	MW	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 headers, more advanced filtering may comprise payload or content filtering. If rule-based filtering is used, then the rules are stored in some sort of Permission Register.
	Data Scanning	SE	optional	In the process of filtering messages, this facility might be used to scan message content, in order to support filtering decisions.

Pattern Type Neighbors

This pattern has the following mandatory and optional relations with adjacent (sub)functions, expressed in Pattern Types (PAT). Note: if the table below is empty, then there are no architecturally prescribed relations with adjacent subfunctions:

Function	Adjacency	Description
Authentication & Authorization	optional	This adjacent facility can server a number of purposes: to validate permissions of senders, before accepting messages from these senders; to authenticate and authorize clients that want to access the Message Store to access messages; to provide Message Filtering with appropriate filtering rules.
Data Management	optional	The storage of messages with a more permanent character benefits from the application of a Data Management solution, that stores messages in a structured and organized way.

Pattern Variants based on this type

Pattern Variant	Brief description	Owner	maturity
PAV.Asynchronous Message Handling.ESB	Asynchronous Message Handling.ESB	S.A.D. Jumelet	1