Those of you interested in this topic may also be interested in the book EnterpriseIntegrationPatterns.
In much the same way that ComponentDesignPatterns, EjbDesignPatterns and JavaIdioms got started, I'd like to start a discussion of Messaging Patterns. What I mean by this is I'd like to see what people believe are the different architectural patterns, design patterns and idioms involved in building software that uses messaging systems.
Very High Level Architectural Patterns:
The grand daddy of MessagingPatterns is the old ObserverPattern which is what makes PublishAndSubscribe messaging technology so powerful.
I welcome your input, refactoring, and additions.
-- KyleBrown
Very recently, MartinFowler and I got to spend some time together after the XpUniverse conference and one of the results of that collaboration was a better, more comprehensive list of MessagingPatterns. Here's the list that we arrived at, together with a categorization of them:
Topology patterns
- Point to Point
- HubAndSpoke
Flow patterns
- PipesAndFilters
- PeerToPeer
- MessageRouter
- Workflow Manager (related to WorkflowQueues)
- PublishAndSubscribe
Format and Content Patterns
- CanonicalMessageDataFormat
- Specializing a Canonical Model (Placeholder for a family of patterns)
- Command Format (I think this is CommandMessagePattern)
- Data-only Format
- DataFormatVersioning (Placeholder for a family of patterns)
- Message Format (Hierarchical/flat, positional/delimited/key-value/self-descriptive, binary/text)
- IncludedReplyDestination
- MessageBusinessProcessIdentifier
Processing Patterns
- MessageTranslator
- TransformationFactory
- LoggingToaQueue
- Shadow Table (General Design Pattern)
- Recording Commands
- MessagingToUpdateDistributedCaches (We decided we liked the name Distributed Cache Update better)
- TransactionalLocalAndRemoteUpdate
- DataReassembly (one of a family of transaction patterns including ordering, tolerance of duplicates, guaranteed delivery, sequence generation, unique sequences, split/merge/group)
- Two Phase Wrapper (a general transaction pattern)
Testing Patterns
Other messaging patterns include:
- TwoTransactionQueuing (error queues)
- AsyncMessaging (Messaging EventSystems) - probably within the scope of ComplexEventProcessing
- TemporaryTopics - Used to perform responses in a publish subscribe methodology.
I think that there are also some quality-of-service type patterns, e.g.:
- Best-effort delivery
- Guaranteed delivery
and delivery will be, e.g:
- (possibly zero for best-effort)
- once and only once
- at least once
and for each of these, delivery will be to, e.g.:
- (possibly zero recipients)
- one recipient (1-of-N)
- some recipients (M-of-N)
- all recipients
Another delivery pattern is "at most once". This is the style used in most RPC systems.
The ISO OSI reference model, especially the uppermost layers, covers the same areas as the format and content patterns. It defines a well known terminology that could be used in the descriptions of these patterns. --Good. Can you please provide some alternate OSI names for the patterns above - if the wikizens decide they like them we'll refactor the pages... I've added some comments to the CanonicalMessageDataFormat page describing where the pattern fits into the OSI reference model.
Architectural Patterns
MessagingAsAlternativeToMultiThreading is useful in domains where multi-threading is too expensive or risky.
CommunicatingSequentialProcesses are a very interesting form of messaging between threads/processes.