Enterprise Integration Patterns
Asynchronous Messaging Architectures
in Practice
Gregor Hohpe
The Need for Enterprise Integration
More than one application (often
hundreds or thousands)
Isolated Systems
Single application too hard and inflexible
Vendor specialization
Corporate politics / organization
Historical reasons, e.g. mergers
Customers see enterprise as a
whole, want to execute business
functions that span multiple
applications
Unified Access
Integration Challenges
Networks are slow
Networks are unreliable
No two applications are alike
Change is Inevitable
Plus
Inherently large-scale and complex
Limited control over entities / applications
Far-reaching implications, business critical
Intertwined with corporate politics
Few standards exist, still evolving
3
Loose Coupling
Coupling = Measure of dependencies between
applications:
Technology Dependency
Location Dependency
Temporal Dependency
Data Format Dependency
Get Credit Score
System
System
740
System
System
RPC-Integration
Waldo et al, 1994:
Objects that interact in a distributed system need to
be dealt with in ways that are intrinsically different
from objects that interact in a single address space
4
Message-Oriented Middleware
Channels are separate
from applications
Channels are
asynchronous & reliable
Data is exchanged in
self-contained messages
System
A
Remove location
dependencies
Remove temporal
dependencies
Remove data format
dependencies
Channel
System
B
Message
Loosely coupled integration enables independent variation
5
Thinking Asynchronously
Order Mgmt
Web Site
Shipping
Inventory
New Order
Order Mgmt
Web Site
Shipping
Inventory
New Order
Confirm
New Order
Confirm
Idle
New Order
Confirm
Confirm
Synchronous
Asynchronous
Asynchronous Messaging Architectures
The emerging architectural style of the new
millennium
Mainframe
Mainframe
Client-Server
Client-Server
Distr.
Distr. Components
Components
Services
Services
Async.
Async. Messaging
Messaging
70ies
80ies
90ies
00s
7
Many Products & Implementations
Message-oriented middleware (MOM)
IBM WebSphere MQ
Microsoft MSMQ
Java Message Service (JMS) Implementations
EAI Suites
TIBCO, WebMethods, SeeBeyond, Vitria, ...
HOT
HOT
Asynchronous Web services
WS-ReliableMessaging, ebMS
Suns Java API for XML Messaging (JAXM)
Microsofts Web Services Extensions (WSE)
The Underlying Design Principles Are the Same!
8
Message-Oriented Integration
1. Transport messages
Application
Application
Application
Application
Application
Application
Application
Application
2. Design messages
3. Route the message to
the proper destination
4. Transform the message
to the required format
5. Produce and consume
messages
6. Manage and Test the
System
Application
Application
Application
Application
Integration Patterns
1. Transport messages
Channel Patterns
2. Design messages
Message Patterns
3. Route the message to
the proper destination
Routing Patterns
4. Transform the message
to the required format
Transformation Patterns
5. Produce and consume
messages
Endpoint Patterns
6. Manage and Test the
System
Management Patterns
Application
Application
10
Hello, Asynchronous World
Consumer
Request
Provider
Request Channel
Reply Channel
Reply
Service Provider and Consumer
Request-Reply (similar to RPC)
Two asynchronous Point-To-Point Channels
Channels are unidirectional
Separate request and response messages
11
Multiple Consumers
Requests
Requests
Provider
Request Channel
Consumer
Consumer
11
Reply Channel 1
Consumer
Consumer
22
??
Reply Channel 2
Replies
Each consumer has its own reply queue
How does the provider know where to send the reply?
Could send to all consumers very inefficient
Hard code violates principle of service
12
Pattern: Return Address
Reply
Channel 1
Reply
Channel 2
Provider
Request Channel
Consumer
Consumer
11
Reply Channel 1
Consumer
Consumer
22
Replies
Reply Channel 2
Consumer specifies Return Address
Service provider sends reply message to specified
channel
Return Address can point to a component different from
the consumer chaining
13
Multiple Service Providers
Provider
Provider 11
Request Channel
Consumer
Consumer
Provider
Provider 22
Reply Channel
Request message can be consumed by more than one
service provider
Point-to-Point Channel supports Competing Consumers,
only one service receives each request message
Channel queues up pending requests
14
Multiple Service Providers
Consumer
Service 1
(slow)
Request 1
Request 2
Reply 2
Reply 1
Service 2
(fast)
Messages can be
processed by different
consumers
Competing Consumers
(load balancing)
Content-Based Router
This causes messages to
get out of sequence
How to match request and reply messages?
Only send one request at a time very inefficient
Rely on natural order bad assumption
15
Pattern: Correlation
Message
Identifier
Consumer
1
Provider
Provider 11
2
Request Channel
Correlate
Request &
Reply
Provider
Provider 22
Response Channel
Correlation
Identifier
Equip each message with a unique identifier
Message ID (simple, but has limitations)
GUID (Globally Unique ID)
Business key (e.g. Order ID)
Provider copies the ID to the reply message
Sender can match request and response
16
Routing Pattern: Message Router
How can we decouple individual processing steps so
that messages can be passed to different components
depending on some conditions?
Different channels depending on message content, run-time
environment (e.g. test vs. production),
Do not want to burden sender with decision (decoupling)
Widget
Inventory
New
Order
Message
Router
Gadget
Inventory
Use a special component, a Message Router, to route
messages from one channel to a different channel.
17
Routing Pattern: Splitter
How can we process a message if it contains multiple
elements, each of which may have to be processed in a
different way?
Treat each element independently
Need to avoid missing or duplicate elements
Make efficient use of network resources
New
Order
Splitter
Order
Item 1
Order Order
Item 2 Item 3
Message
Router
Use a Splitter to break out the composite message into a
series of individual messages, each containing data related
to one item.
18
Routing Pattern: Aggregator
How do we combine the results of individual, but related
messages back into a single message?
Responses may be out of sequence
Responses may be delayed
Item 1 Item 2 Item 3
Aggregator
Validated
Order
An Aggregator manages the reconciliation of multiple,
related messages into a single message
Stateful component
19
Routing Pattern: Aggregator
Correlation
Which incoming messages belong together?
Completeness Condition
When are we ready to publish the result message?
Wait for all
Time out (absolute, incremental)
First best
Time box with override
External event
Aggregation Algorithm
How do we combine the received messages into a
single result message?
Single best answer
Condense data (e.g., average)
Concatenate data for
later analysis
20
Composed Pattern: Auction
Send a message to a dynamic set of recipients,
and return a single message that incorporates
the responses.
Pub-Sub
Channel
Auction
Vendor
Vendor B
B
Request
For Quote
Best
Quote
Vendor
Vendor A
A
Quote
Vendor
Vendor C
C
Aggregator
21
Example: Combining Routing Patterns
Receive an order, get best offer for each item
from vendors, combine into validated order.
Auction
Pub-Sub
Channel
Vendor
Vendor A
A
Quote
Vendor
Vendor B
B
New
Order
Splitter
Validated Aggregator
Order
Quote Request
for each item
Best Quote
for each item
Vendor
Vendor C
C
Aggregator
22
Example Continued
Only vendors on the preferred vendor list get to
bid on an item.
Recipient
List
Vendor
Vendor A
A
Enricher
New
Order
Splitter
Validated Aggregator
Order
Quote Request
for each item
Best Quote
for each item
Quote
Vendor
Vendor B
B
Vendor
Vendor C
C
Preferred
Vendor List
Aggregator
23
In Summary
Visual and verbal language to describe
integration solutions
Combine patterns to describe larger solutions
No fancy tools whiteboard or PowerPoint
No vendor jargon
Not a precise specification language
(e.g., see OMG UML Profile for EAI)
Not a new methodology
Each pattern describes trade-offs and
considerations not included in this overview
24
Resources
Book (late October):
Enterprise Integration Patterns
Addison-Wesley, 0-321-20068-3
Contact
Gregor Hohpe
ghohpe@thoughtworks.com
Web Site
http://www.eaipatterns.com
Pattern catalog
Bibliography, related papers
info@eaipatterns.com
www.thoughtworks.com
25
