EAI - Messaging
Identification
Name: EAI - Messaging
Category: Applications/Technology
Version: v1.1
Modelling/Architecture Pattern: Architecture Pattern
Synonyms: Service composition using choreography.
Contributor(s): Ed Walters
Attribution: The basic ideas expressed here are based on information found in “Enterprise Integration Patterns” (Hohpe, Woolf 2003) [EAI]. “Java Message Service” (Richards, Monson-Haefel, Cappell 2009) [JMS] was also a useful source.
Description
Context: In most enterprises there is a mix of different applications and technologies that supply its automated information system needs. These will have been acquired from multiple vendors at different times. Information though needs to flow around the enterprise as smoothly and seamlessly as possible, hence there is a need to integrate data managed by a heterogeneous set of applications. There is also an expectation for modern enterprises to be able to exchange information with many sorts of external entities, including Customers, Partners and Regulators.
Problem: The problem that recurs is the need to pass data between distinct applications both within the enterprise and to link up with external entities. Common examples of modern data integration needs include: • Information Portal • Data Replication • Distributed Business Processes • B2B Integration
EAI - Messaging is an integration pattern that can address some of these needs.
Trade-offs, Design Constraints (Forces): This integration pattern relies on asynchronous messaging which implies a number of forces that need to be balanced, including performance issues, latency issues, security issues, robustness and the implications of failure to integrate and scalability of the solution.
Solution Structure: A ‘message’ is defined as any atomic form of information that needs to be exchanged between applications. It is typically structured as having a header, with routing information, and a body with the message contents.
The solution structure involves using a Message-Oriented Middleware system (MOM) to act as a broker between the application sending the message (‘Producer’) and the application receiving the message (‘Consumer’). The MOM requires some client software to be deployed within both the producer’s and the consumer’s IT landscape. This software is known as the messaging system’s ‘endpoints’. Access to the endpoints is through a messaging API provided by the MOM system.
The MOM provides the facility to create channels which act as logical ‘pipelines’ through which messages can travel from source to destination, under the control of a MOM system administrator. Two common forms of channel are ‘Point-to-Point’ (p2p) and ‘Publish/Subscribe’ (pub/sub). The messages could be manipulated along the way by MOM delivery functions, if that was required. Typical functions including Routing, Filters (filtering content) and Transformation (changing message format). The MOM may provide a way to persist messages for future transmission in case a destination endpoint is not available.
Solution Dynamics: A producer application constructs and sends a message through an API to the origin endpoint installed locally. The MOM picks up the message’s header information and constructs a channel accordingly. The MOM control system then organises the transmission of the message along the channel until it arrives at the destination endpoint. The message may undergo processing and formatting during its journey as setup in the MOM control system. The consumer application detects the message arrival, receives and processes it. Both pull and push options for receiving messages are typically available in a MOM system.
Layers/Aspects of the ArchiMate modelling language used: Application/Technology
Variants, Refinements and Combinations: There are a huge variety of detailed variations on the basic messaging pattern – the best source for these is [EAI]. [JMS] also shows some modern variations. See also Data Pipeline. This pattern could be used in conjunction with other integration solutions documented in the library.
Known Uses: there will be very few modern commercial enterprises that don’t use solutions of this kind somewhere in their application landscape for integrating application data. Asynchronous processing by this means is a key feature of modern distributed applications and partner integration.
Other comments and references: This solution to data integration has many benefits but is only suitable where asynchronous communication is acceptable in the business context. The benefits include very low coupling between the applications that are integrated and guaranteed delivery, or error feedback. Many MOM systems are feature-rich, providing sophisticated facilities for managing the messaging system.
Pattern Metamodel
Example(s)
![Messaging_Example] In this example a Retailer sends an order message asynchronously to a Wholesaler. The MOM organises this via a p2p (point-to-point) channel. The second example shows the pub/sub (publish/subscribe) style of messaging. A 'new Customer' message is placed onto the publisher channel. The MOM recovers the topic and subscriber information from its database and places appropriate messages onto the subscribers' channels. The example is inspired by Sam Newman's example of choreography in 'Building Micro-services'.
Downloadable Model
[EAI_Messaging.xml]EAI_Messaging.xml