PAT.Message Handling

From OIAr Archive 2013
Revision as of 07:40, 12 November 2012 by Jan Schoonderbeek (talk | contribs) (linkfix)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search
Informational
Page maturity
This page has maturity level 3 (usable)

This is a Pattern document

Document icon PAT Message Handling Version: 0.4 OIAr logo
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


Framed Pattern Type legend.png

(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
BT.Message Engine icon 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.
BT.Name Resolution icon 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.
BT.Message Distribution icon 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.
BT.Header Modification icon 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.
BT.Message Transformation icon 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'.
BT.Message Responding icon 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.
BT.Message Store icon 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.
BT.Archiving icon 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.
BT.Message Filtering icon 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.
BT.Data Scanning icon 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 VariantBrief descriptionOwnermaturity
PAV.Asynchronous Message Handling.ESBAsynchronous Message Handling.ESBS.A.D. Jumelet1