Scribd
Upload
95 views

Additional Patterns

This document introduces enterprise integration patterns for asynchronous messaging architectures. It discusses the need for integrating multiple isolated applications within an enterprise. Integration poses challenges due to network speeds, reliability issues, application differences and changes over time. Loose coupling is important to address these challenges. Message-oriented middleware uses asynchronous messaging through reliable channels to decouple applications. Common integration patterns are presented for routing, transforming and managing messages across applications. Examples demonstrate how patterns can be combined to implement integration solutions.

Uploaded by

Aadithya Aadithyaa
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
95 views

Additional Patterns

This document introduces enterprise integration patterns for asynchronous messaging architectures. It discusses the need for integrating multiple isolated applications within an enterprise. Integration poses challenges due to network speeds, reliability issues, application differences and changes over time. Loose coupling is important to address these challenges. Message-oriented middleware uses asynchronous messaging through reliable channels to decouple applications. Common integration patterns are presented for routing, transforming and managing messages across applications. Examples demonstrate how patterns can be combined to implement integration solutions.

Uploaded by

Aadithya Aadithyaa
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 25

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
[email protected]

Web Site

http://www.eaipatterns.com
Pattern catalog
Bibliography, related papers
[email protected]

www.thoughtworks.com
25

You might also like