GP.Message Handling

From OIAr
Revision as of 13:38, 8 May 2015 by Jan Schoonderbeek (talk | contribs) (stub)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search


This is a Generic Pattern document GP Message Handling Version: 0.4 OIAr logo
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:

Generic Pattern Message Handling
Generic Pattern Message Handling


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: