7 eai-patterns

EAI Patterns

Cesare Pautasso and Gustavo Alonso
Computer Science Department
Swiss Federal Institute of Technology (ETHZ)
pautasso@inf.ethz.ch
http://www.iks.inf.ethz.ch

Design Patterns and EAI
Goal:
Practical advice and solutions to concrete design problems of
Enterprise Application Integration
Definition:
A pattern is a standard solution
to common and recurring design problems
Related:
Related (but different) to Object-Oriented Design Patterns
Hint:
these EAI patterns should be applied where they actually solve
a problem.
Warning:
as with all design decisions, all consequences should be
evaluated and fully understood.

©IKS, ETH Zürich. 2

EAI Design Patterns Overview
Service Oriented Architecture
Interoperability
Service Directory
Notification
Event Monitor
Observer
Publish/Subscribe
Messaging Bridge
Composition
Scatter/Gather
Synchronous
Asynchronous
Testing
Faux Implementation
Wire Tap
Optimization
Data Transfer Object
Partial Population


Service Oriented Architecture
Interoperability
Service Directory

Interoperability
Goal:
enable communication between different
platforms
Solution:
map to a standardized intermediate
representation and communication style
Design pattern:
components of different architectural styles
running on different platforms are integrated
by wrapping them with adapters. These
adapters enable interoperability as they
implement a mapping to common means of
interaction

Interoperability Pattern
Component Adapter Adapter Component
(Platform A) (Platform A) (Platform B) (PlatformB)

Components of different platforms can interoperate through
adapters mapping the internal message format to a common
representation and interaction style


Interoperability: Hints
Why two adapters?
For Point to Point solutions one adapter is enough
(direct mapping)
In general, when integrating among N different
platforms, the total number of adapters is reduced by
using an intermediate representation
Adapters do not have to be reimplemented for each
component, but can be generalized and shared among all
components of a given platform
This pattern helps to isolate the complexity of having to
deal with a different platform when building each
component. The adapters make the heterogeneity
transparent.
Warning: performance may suffer due to the overhead of
applying potentially complex transformations at each
adapter

Service Directory
Goal:
facilitate location transparency
(avoid hard-coding service addresses in clients)
Solution:
use a directory service to find service endpoints
based on abstract descriptions
Design pattern:
clients lookup services through a directory in
order to find out how and where to invoke
them


Service Directory Pattern
Client Directory Service

Service
Description 1. Publish

2. Lookup

3. Invoke

Clients use the Directory Service to lookup published service
descriptions that will enable them to perform the actual
service invocation


Service Directory Hints
Clients cannot directly invoke services, they first need to lookup their
endpoint for every invocation.
Directories are a service in its own right (the difference is that its
endpoint should be known in advance by all clients).
The directory data model heavily depends on the context where the
directory is applied and to the common assumptions shared by clients
and services:
Simplest model: map <Symbolic Name> to <IP:Port>
Directories can store complete service descriptions or only store
references to service descriptions (like UDDI)
Depending on the metadata stored in the directory, clients can
perform sophisticated queries over the syntax and semantics of the
published services
Directories are a critical point for the performance fault-tolerance of
the system. Clients usually cache previous results and repeat the
lookup only on failure of the invocations.
The amount of information stored in a directory may grow quite large
over time and needs to be validated and kept up to date. Published
services should be approved in order for clients to trust the
information provided by the directory.

Notification
Event Monitor
Observer
Publish/Subscribe
Messaging Bridge

Event Monitor
Goal:
inform clients about events happening at the service
Constraint:
service does not support a publish/subscribe
mechanism
Solution:
poll and compare snapshots
Design pattern:
clients use an event monitor that periodically polls
the service, compares its state with the previous one
and notifies the clients about changes


Event Monitor Pattern
Event
Client Service
Monitor

1. poll(frequency)
Snapshot (A)

Snapshot (B)

2. compare(A,B)

3. notify

A client instructs the Event Monitor to periodically poll the state
of a remote service. The Event Monitor only notifies the client
if a change has occurred between different snapshots.


Event Monitor: Hints
Necessary only if a service does not provide a
publish/subscribe interface
To minimize the amount of information to be
transferred, snapshots should be tailored to what events
the client is interested in detecting. This may be a
problem if the service interface cannot be changed.
One event monitor should be shared among multiple
clients by using the observer pattern
Clients should be able to control polling frequency to
reduce the load on service
Warning: this solution does not guarantee that all
changes will be detected, but only those which occur at
most as often as the sampling rate of the event monitor


Observer
Goal:
ensure a set of clients gets informed about all state
changes of a service as soon as they occur

Solution:
detect changes and generate events at the service

Design Pattern:
clients register themselves with the service, which
will inform them whenever a change occurs


Observer Pattern
Client (A) Service Client (B)

S.register(A) A
A.notify

B S.register(B)

A.notify B.notify

S.unregister(A) A

B.notify

Clients register a callback/notification endpoint with the service.
This is used by the service to notify all clients about state changes.
Clients should also unregister themselves when no longer interested.


Observer Hints
Assuming that a service can implement it, this pattern
improves on the Event Monitor pattern:
State changes are not downsampled by clients
State changes are propagated as soon as they occur
If no change occurs, useless polling by clients is spared
Clients could share the same endpoint with several observed
services. Notifications should identify the service from which
the event originates.
To avoid unnecessary polling by the client, notification
messages should also include information about the new
state and not just that a state change has occurred.
Warning: the set of registered clients becomes part of the
state of the service and may have to be made persistent to
survive service failures.
A client which stops listening without unregistering should
not affect the other registered clients

Publish/Subscribe
Goal:
decouple clients from services generating events

Solution:
factor out event propagation and subscription
management into a separate service

Design Pattern:
clients register with the event service by subscribing
to certain event types, which are published to the
event service by a set of one or more services.


Publish/Subscribe Pattern
Pub/Sub
Client (C) Service (S)
(E)

E.subscribe(C) C

X E.publish(X)

X C.notify(S,X)

As opposed to the Observer, subscriptions are centrally managed
for a set of services by the Pub/Sub Service.
As opposed to the Event Monitor, services actively push
state changes into the Pub/Sub Service.


Publish/Subscribe Hints
The interaction between published and subscriber is
similar to the Observer pattern. It is also more
decoupled, as messages are routed based on their
type.
Warning: event types become part of the interface of
a service, and it may be difficult to determine the
impact of changes in event type definitions
Like in the Observer pattern, subscriptions should be
made persistent, as it is difficult for clients to realize
that the pub/sub service has failed.
Unlike with the Observer pattern, all events in the
system go through a centralized component, which
can become a performance bottleneck. This can be
alleviated by partitioning the pub/sub service by
event type.

Messaging Bridge
Goal:
connect multiple messaging systems

Solution:
link multiple messaging systems to make messages
exchanged on one also available on the others

Design Pattern:
introduce a bridge between the messaging systems,
the bridge forwards (and converts) all messages
between the buses


Messaging Bridge Pattern
Bus Bridge Bus
Client (C) Service (S)
(E1) (B) (E2)

M
E1.subscribe(M) M
E2.subscribe(M)
M E2.publish(M)
M B.notify(M)
M E1.publish(M)
M C.notify(M)

The bridge (B) replays all subscriptions made by clients one bus (E1)
onto the other (E2) so that it can inform the client (C) of one bus of
messages published on the other


Messaging Bridge Hints
Enable the integration of existing multiple messaging
systems so that applications do not have to use multiple
messaging systems to communicate
Often it is not possible to use a single messaging system (or
bus) to integrate all applications:
Incompatible messaging middleware (JMS vs. .NET MQ)
External bus(es) vs. Internal bus
One bus does not scale to handle all messages
Although messaging systems may implement the same
standard API, they are rarely interoperable so they cannot be
directly connected.
Messaging bridges are available (or can be implemented) so
that messages can be exchanged between different buses.
They act as a message consumer and producer at the same
time and may have to perform message format translation.


Composition
Scatter/Gather
Synchronous
Asynchronous

Scatter/Gather
Goal:
send the same message to multiple recipients which
will (or may) reply to it

Solution:
combine the notification of the request with
aggregation of replies

Design Pattern:
broadcast message to all recipients, wait for all (or
some) answers and aggregate them into a single
message.


Scatter/Gather Pattern
Scatter/
Client A B C
Gather

Broadcast
Request

Aggregate
Results

Broadcasting can be implemented using subscriptions (loosely coupled)
or a distribution list provided by the client (which knows A, B, C)
Results will be collected and aggregated before they are returned to
the original client as a single message


Scatter/Gather Hints
This is a simple composition pattern, where we are interested in
aggregating replies of the components processing the same
message.
Alternatives for controlling the components:
The recipients can be discovered (using subscriptions) or
be known a priori (distribution list attached to request)
Warning: the response-time of each component may vary and the
response-time of the scatter/gather is the slowest of all component
responses
Different synchronization strategies:
Wait for all messages
Wait for some messages (within a certain time window, or using
an N-out-of-M synchronization)
Return fastest reply (discriminator, maybe only under certain
conditions)
Example:
Contact N airlines simultaneously for price quotes
Buy ticket from either airline if price<=200CHF
Buy the cheapest ticket if price >200 CHF
Make the decision within 2 minutes

Composition
Goal:
Improve reuse of existing applications

Solution:
Build systems out of the composition of existing ones

Design Pattern:
by including compositions as an explicit part of the
architecture, it becomes possible to reuse existing services in
order to aggregate basic services into value-added ones

Variants: Synchronous, Asynchronous
Synonyms: Orchestration


Composition Pattern
Composite Service Service Service
Client
Service (Web) (Extranet) (Intranet)

Initiate

Progress
Notification

Completion
(Final result)
Composite services provide value-added services to clients by
aggregating a set of services and orchestrating them according
to a well-defined and explicit business process model


Composition Hints
Composition is recursive: a composite service is a service
that can be composed.
Services involved in a composition do not necessarily have to
know that they are being orchestrated as part of another
service and may be provided by different organizations
Services can be reused across different compositions and
compositions can be reused by binding them to different
services
Composite services may be implemented using a variety of
tools and techniques:
Ordinary programming languages (Java, C#, …)
Scripting languages (Python, PERL, …)
Workflow modeling languages (JOpera, BPEL…)
Compositions may be long-running processes and involve
asynchronous interactions (both on the client side, and with
the services)

Testing
Faux Implementation
Wire Tap

Testing: Faux Implementation
Goal:
test a client
separately from the services it depends on
Solution:
bind the client to a local replacement
Design Pattern:
the interfaces of the production Web services that
are needed by the client are implemented by mockup
services. These are used to test & debug the client
that does not have to call the remote Web service

Synonyms: Interface Pattern, Mockup


Faux Implementation Pattern
Service
Interface

Testing Production
Client
Service Service

For testing the client calls a replacement service
which implements the same interface as the production one.


Faux Implementation: Hints
Necessary when the production Web services are not
(yet) available for testing the client
Warning: the faux implementation should behave
like the real one it replaces:
Compatible functional interface
Similar non-functional properties: e.g., response time
Applicable when it is good enough to reimplement a
subset of the original service interface.
As an alternative, a copy of the production service
could be redeployed for testing


Testing: Wire Tap
Goal:
inspect messages between client and server

Solution:
intercept messages in transit using a “wire tap”

Design Pattern:
The wire tap replaces the intended destination of the
messages, forwards them to the original destination
but also keeps a copy for inspection

Synonyms: Tee


Wire Tap Pattern

Wire
Client Server Log
Tap

The client may have to be modified to send messages to the wiretap
The server may be transparently replaced by the wiretap
Wire tap acts as a proxy between client and server


Wire Taps: Hints
Useful for debugging (read the data on the wire),
auditing (log all information in transit),
performance measurement (measure the time
between the request and response message)
Warning: wire taps introduce additional latency &
overhead, especially if the messages are logged
synchronously
Three ways to set it up:
Can Modify the Client: point the client to the wire tap
proxy instead of the original destination.
Can Replace the Server: make the wiretap listen on the
original server endpoint and forward messages to new
server address.
Cannot Change Anything: use a packet sniffer.


Optimization
Partial Population

Goal:
Reduce load on service, Minimize response time
(Performance Optimization)
Solution:
Reduce the number of SOAP messages that are
exchanged
Design Pattern:
Operations should be designed with the optimal
level of granularity to perform a given function. The
required input information and the results should be
exchanged with a minimal number of messages (2 in
the best case)


Data Transfer Object Pattern
Client Service Client Service

service.op1(a)

service.op2(b)
service.op(a,b,c,d)

service.op3(c)

service.op4(d)


Data Transfer Object: Hints
Performance is improved if:
N * O(Call(1)) > O(Call(N))
Calling N-times an operation with one object takes longer
than calling once an operation passing N-objects
Applicable when clients retrieve multiple data items from
a service
Warning: a Data Transfer Object should not have
behavior associated with it
Can be used to ensure client gets a consistent snapshot
of data on server (if each Call runs in its own transaction)
Variation: Data Transfer Collection (when multiple data
objects are transferred with one message)


Partial Population
Goal:
control and reduce message size
Solution:
a further optimization of the Data Transfer Object
pattern, where the amount of data to be transferred
can be controlled by the client
Design Pattern:
Extend a Data Transfer Object with a key field –
explicit description of the actual data it contains (for
sending data to service) and pass the key as input to
operation (for choosing what the service should
return)


Partial Population Pattern
Client Service Client Service

key
key

Filtering Partial Results Sending Partial Requests


Partial Population: Hints
Advantage: Avoid defining Data Transfer Objects for
every combination of data items that a client may
ever need
The same Data Transfer Object can use “null” values
to avoid transferring unwanted fields and reduce
message sizes
Further generalizing this pattern leads to a service
providing a flexible “query” (REST-ful) interface,
where clients use the same operation to submit any
possible query over the data provided by the service
ResponseDocument = Query(RequestDocument)


References
Gregor Hohpe, Bobby Woolf, Enterprise Integration
Patterns, Addison Wesley, 2004
Paul Monday, Web Service Patterns: Java Edition,
APress, 2003
Erich Gamma, Richard Helm, Ralph Johnson, John
Vlissides, Design Patterns: Elements of Reusable
Object-Oriented Software, Addison-Wesley, 1994


7 eai-patterns

More Related Content

What's hot (7)

Similar to 7 eai-patterns (20)

7 eai-patterns