EAI
Architecture
Patterns
Enterprise Application Integration (EAI) is a rapidly growing seg-
ment in enterprise computing. Multiple forces are driving this
trend. Many of them center on rapidly changing business needs
and opportunities driven by the Internet, merger/acquisitions, competition, regulation,
and deregulation. Increased attention on Customer Relationship Management (CRM) and
supply chain integration in many industries is driving the demand for intra- and inter-
enterprise system integration.
Mergers and acquisitions result in the daunting task of inte-
grating once separate enterprise computing infrastructures.
Many changes in the telecommunications industry, including
deregulation and new service offerings, are having a dramat-
ic effect on the system environments at established and
emerging telecommunications service providers.
On the technical front, significant changes are also con-
tributing to the rise of EAI. Enterprise Resource Planning
(ERP) systems have been added as core elements to the enter-
prise computing infrastructure. CRM systems are being devel-
oped and installed to meet business demands. Application
servers are maturing as a tool for developing and deploying dis-
tributed Web- and non-Web-based applications and services.
Legacy application services and data are becoming compo-
nents, liberated from the confines of legacy, stovepipe applica-
tions. Distributed computing middleware is continuing its push
into the enterprise on several fronts. This includes message-ori-
ented middleware, distributed objects, and remote data access
middleware. Also, tools are emerging to address various types
of EAI, including application integration, data integration, and
process automation.
Frequently, confusion and anxiety reign in times of massive
business and technical change. Rapid business change drives
64
JEFFREY
C. LUTZ
By
the need to deliver more capabilities faster. Increasingly, busi-
ness needs necessitate a high degree of application integra-
tion. For example, implementing Web-based bill presentation
requires integrating a Web server with the billing application.
Automating manual processes often requires integrating mul-
tiple applications. Naturally, the IT professional seeks to buy
off-the-shelf, where appropriate, to meet business demands
and ease the difficult task of application integration.
In seeking tools to speed EAI development, the IT profes-
sional can find many possibilities from dozens of EAI tool
and application server vendors. Moreover, there are many cat-
egories of middleware and competing products in each cate-
gory. Another complication comes from the failure of many
products to perform as advertised. The deck seems over-
whelmingly stacked against the IT professional trying to meet
business expectations and needs.
EAI Architecture Patterns to the Rescue
Architecture patterns are an important ally of the IT pro-
fessional in the battle against integration complexity and con-
fusion. EAI architecture patterns provide an architectural
view of EAI and a solid technical foundation for successful
EAI. The patterns help IT professionals determine the best ap-
eAI Journal • March 2000
proaches and tools to cleanly solve integration problems.
Patterns have recently drawn considerable attention through
books, articles, and conferences on the subject. The following
excerpt from the book, Design Patterns: Elements of Reusable
Object-Oriented Software, describes design patterns:
Design patterns capture solutions that have developed and
evolved over time. They reflect untold redesign and recoding
as developers have struggled for greater reuse and flexibility
in the software.
The EAI architecture patterns presented below also reflect
redesign as people have struggled for reuse and flexibility in
their systems. Both of those characteristics are crucial in an
era of rapid change and short time lines. Only a flexible IT
integration infrastructure can keep pace with the rapid
changes many businesses are coping with. Patterns capture
hard-won experience and seek to provide a convenient means
to communicate that experience.
Patterns solve recurring design and architecture problems
(e.g., the need to automate processes that span multiple appli-
cations or provide a simple interface to back-end applications
and data sources). This article captures these recurring prob-
lem/solution pairs and presents them in a generally recogniz-
able way. The intent is to help EAI developers overcome some
common challenges.
The EAI architecture patterns below have been proved,
often more than once, or have been partially or wholly sub-
stantiated within tools available from vendors. Indeed, these
patterns are a packaging and generalization of the designs and
discoveries of many in the field. This article categorizes the
problem and solution space of EAI, and packages proven
architectural approaches to EAI into patterns.
EAI architecture patterns focus on the overall structure of
a system or application. In the book, A System of Patterns:
Pattern-Oriented System Architecture, an architectural pattern
is defined as:
An architectural pattern expresses a fundamental structur-
al organization schema for software systems. It provides a set
of predefined subsystems, specifies their relationships, and
includes rules and guidelines for organizing the relationships
between them.
Such is the definition of EAI architecture patterns.
Notably, several of the architecture patterns (integration
adapter, integration façade, and integration mediator) are con-
ceptually close cousins of established design patterns. A key dif-
ference between the design patterns and architecture patterns,
however, is that architecture patterns specify the systemwide
structural properties of an application and have an impact on the
architecture of its subsystems. Design patterns have no such sys-
temwide impacts. Design patterns are smaller in scale than
architectural patterns. So, while the three architecture patterns
listed above are conceptually similar in intent to an established
design pattern, there is value in representing these concepts at an
architectural level. Doing so allows the pattern intent, problem
context, and solution to differ — depending on the level and
context of the problem.
Another point worth making is that one of the architectur-
al patterns (integration messenger) is similar to the estab-
66
lished broker architecture pattern. The difference, however, is
that the broker is categorized as a specialization of the more
general integration messenger EAI architecture pattern.
This article presents “architected” solutions, which are scal-
able and changeable approaches that help to manage complex-
ity. EAI-centric problems can and often are addressed using
brute force, point-to-point integration. While point-to-point
solutions may make sense in limited cases, the approach is
dangerous and costly in the medium- and long-term for many
integration situations. Bottom-line costs to the business are the
inability to rapidly change and extend operations. Such costs
inexorably lead to lost business and missed opportunities.
A common characteristic of all EAI architecture patterns is
a high degree of decoupling — the property where the depen-
dencies between elements (i.e., applications) are minimized. A
key benefit of decoupling at the architectural level is improved
IT system flexibility. Proper decoupling lets developers
change applications with minimal or no changes to dependent
applications. Decoupling helps to maintain the integrity of
integration-centric application architectures despite rapid busi-
ness and technical change. Ultimately, flexible, decoupled EAI
architectures translate into flexibility for the business.
Overview of EAI Architecture Patterns
Five EAI architecture patterns are presented:
• Integration adapter: converts an existing application inter-
face to a desired interface
• Integration messenger: describes an approach to minimize
application communication dependencies between applica-
tions
• Integration façade: provides a simplified interface to back-end
applications, minimizing dependencies between client and
server applications
• Integration mediator: encapsulates application interaction
logic, minimizing application dependencies
• Process automator: describes an architectural approach
that minimizes dependencies between process automation
logic and applications.
Most of the patterns have multiple variations of the base
pattern that extend the pattern in an important way. These
variations are more than instances of the pattern. The varia-
tions are themselves general (although less general than the
base pattern) in nature.
The EAI architecture patterns can be applied in two impor-
tant contexts within IT. The first is at the enterprise integra-
tion architecture level. The purpose of enterprise integration
architecture is to bring order and consistency to the many EAI
applications across the enterprise. The EAI architecture pat-
terns can serve as a framework for specifying EAI standards.
The second context is within a given application. EAI patterns
are useful for specifying the architecture for a given integra-
tion-centric application.
Integration Adapter Pattern
It’s increasingly common for IT organizations to open up
the services of legacy stovepipe applications to other applica-
tions. Business demands are driving much of this activity. For
example, moving customer account inquiry services online
requires access to account information previously locked up in
eAI Journal • March 2000
legacy customer account systems. The integration adapter pat-
tern describes a layered approach to exporting the services of
a non-integrated application to other applications. Once
exported, the services of the application become a reusable Client
Client
asset that can be much more effectively leveraged to meet Application
Application
business needs. BB
The integration adapter pattern provides a flexible Integration
Integration Server
Server
approach to exporting reusable application services. This Adapter
Adapter Application
Application
architectural pattern has the same motivation as the adapter Client
Client
Application
design pattern — to convert from a given (server) interface Application
BB
into an interface a client expects. An additional motivation of
the integration adapter architectural pattern (not explicitly
addressed in the adapter design pattern) is to provide a
reusable interface to multiple client applications.
Figure 1 shows the integration adapter pattern. The inte- Figure 1 — Integration Adapter Pattern
gration adapter pattern converts from a custom interface to an
open, reusable interface. Participants in this pattern are one or
more client applications, the integration adapter, and one
server application. The client applications invoke the services
of the server application through the adapter interface. The Wholesale
Client
Ordering
integration adapter converts the public Application Application
Application
A
Programming Interface (API) exported by the integration Customer
Application
Integration Account
Server
adapter to the API of the server application. The adapter does- Wrapper
Adapter Mgmt.
Application
n’t know the individual client applications exist. In a non- Online System
Client
intrusive adapter design, the server application doesn’t know Customer
Application
Account
of the adapter. In an intrusive adapter design, the server appli- B
System
cation is modified in some way.
The integration adapter pattern has two important special-
ties that are common in the enterprise — the application
wrapper and message broker adapter.
Figure 2— Application Wrapper for Customer Account Management
The application wrapper exports the services of an appli-
cation to other applications through a public interface.
In Figure 2, the application wrapper provides a clean, flex-
ible approach for exporting the services of a legacy system
(e.g., customer account management system). The wholesale
ordering application and online customer account system Message Broker- Server Application
accesses the customer account management system services to-Adapter Interface API
via the application wrapper.
The second variation of the integration adapter pattern, the
message broker adapter, is a close cousin of the application Message
Server Message Broker
Integration Server
Server
wrapper. The difference is that the public interface of a mes- Broker
Application Adapter
Adapter Application
Application
sage broker adapter is as defined by a message broker. A mes-
sage broker is an intelligent intermediary that directs the flow
of messages between applications, which become sources and
consumers of information.
Figure 3 shows the message broker adapter. A message bro- Figure 3 — Message Broker Adapter
ker commonly has many adapters for many types of systems. In
a message broker-based integration system, each message bro- supports the following communication models:
ker adapter must conform to the message-broker-to-adapter
interface. The message broker adapter, therefore, converts from • One-to-one synchronous (request/reply). This model
this message-broker-to-adapter interface to the server applica- involves a single client application and a single server appli-
tion API. Many EAI tool venders refer to the message broker cation, where the client blocks waiting for the server to
adapter as an “adapter” or “connector.” process the request.
• One-to-one asynchronous (message queuing). This model
Integration Messenger Pattern involves a single client and server application, where the client
The integration messenger pattern describes an architectur- does not block waiting for the server to process a request.
al approach to integrating applications where it’s unnecessary • One-to-many asynchronous (publish and subscribe). This
or impractical to decouple the application interaction logic model involves one client and one or more server (sub-
from the applications themselves. The key benefit is that com- scribing) applications.
munication dependencies between applications are minimal.
This yields a more flexible integration approach. This pattern While the communication models are varied, the intent is

eAI Journal • March 2000 67

the same in each case — to let applications communicate with
minimal communication dependencies. Figure 4 shows the
integration messenger pattern.
Participants in this pattern are the applications to be inte- Application Interaction Model
grated (applications A and B) and the integration messenger,
which is responsible for delivering messages between applica- Application
Integration
Application
tions and providing location transparency services. The inte- A
Messenger
B

gration messenger is a logical entity that’s typically distributed

at the physical level. The application interaction model refers
to the model the applications use to interact with one another.
Three of these application interaction models are:

• Remote method invocation

• Message queuing Figure 4 — Integration Messenger Pattern
• Publish/subscribe.

In this pattern, the applications themselves are fully

responsible for implementing the application interaction TCP Socket
logic. The integration messenger is completely unaware of the Online
Interface #1
application interaction semantics. Account
Web
Data
The integration messenger pattern has a specialization for Ordering
Server
Application
each interaction model: broker (remote method invocation),
message queuing, and publish and subscribe.
Internal
The broker specialization provides synchronous, one-to- Desktop Order
one communication between applications or components. Ordering Server
This pattern works for slightly more coupled application Application
TCP Socket
interaction such as intra-application and inter-component sce- Interface #2
narios. The broker pattern is commonly used in implementing
n-tier applications.
The message queuing specialization provides one-to-one Figure 5— Point-to-Point Integration
asynchronous communication between applications. Often,
message queuing provides guaranteed delivery services.
Publish and subscribe is a specialization of the integration TCP Socket
messenger that supports an asynchronous one-to-many com- Interface #1

munication model, where multiple subscriber applications

Online Interfaces
may subscribe to a single published event. Publish and sub- Web Remote Method Calls Integration
Account
Data
scribe is a highly decoupled communication architecture Ordering Adapter Server
Application
where the existence (not just location) of the interacting appli- Integration
Messenger
cations is hidden from one another. Internal (Broker)
Integration Order
The following shows an application of the broker specializa- Desktop
Ordering Adapter Server
tion of the integration messenger pattern. Suppose a company is Application

creating two client-ordering applications and both applications TCP Socket

require back-end account information and ordering services. Interface #2

The account information is maintained in the account data

server (a legacy mainframe application). The services of the
account data server have been exported to the world as a sock-
et-based interface with a custom application-messaging layer.
The order server provides the ordering services, which are
also available to client applications via a custom application
messaging protocol and sockets.
An online Web-ordering application lets customers order
products themselves using a Web browser. This application
interacts with both the account data server and order server.
Customer service representatives use a Microsoft Common
Object Model (COM) desktop application to submit customer
sales orders. This application also requires the services of
both the account data server and ordering server.
Figure 5 shows one approach to integrating the client appli-
cations with the back-end services. This approach has disad-
vantages. The client applications must know the location of the
back-end servers. Also, the client applications are bound to the
Figure 6 — Integration With Integration Messenger
custom interface protocol exported by the servers. That is, the
client application must code to a socket interface and a custom
application messaging protocol. In both cases, the client appli-
cations are tightly coupled to the servers.
A more flexible approach is to apply the integration messen-
ger pattern combined with the integration adapter pattern (see
Figure 6). The integration adapters perform the conversion from
the account data server and the order server socket APIs to an
interface the broker expects. The integration messenger inter-
faces with each server integration adapter and serves as an inter-
mediary between the client applications and server applications.
The broker severs some of the costly dependencies between
the client applications and servers. The client applications are
no longer coupled to the location of the servers, nor to server
application communication and low-level messaging proto-

68 eAI Journal • March 2000

cols. The result is a more flexible approach to integration.
Server
Integration Façade Pattern Server
Application
Application
The integration façade pattern describes an architectural Client
Client
AA
approach to integrating client applications with server appli- Application
Application
AA
cations. This architectural pattern has the same motivation as
Server
the façade design pattern, but this pattern provides a higher- Integration
Integration Server
Server
Application
Facade
Adapter Application
Application
level, simplified interface for client applications used to min- BB
Client
imize dependencies between client applications and server Client
Application
Application
applications. This provides flexibility and reusability of appli- BB
cation and application integration services. The integration Server
Server
Application
Application
façade pattern is shown in Figure 7. CC
The integration façade may be used to provide a simplified
interface to a single client application or to multiple client
applications. Participants in the integration façade pattern are Figure 7 — Integration Façade Pattern
one or more client applications, the integration façade and one
or more server applications. The client applications invoke the
simplified services of the integration façade. The integration
façade abstracts server functionality to make the server appli-
cations easier to use. The integration façade, therefore, trans- Voice
Voice
lates the integration façade interface to the server application Service
Availability
interfaces. The applications (subsystems) perform the actual Ordering
work, but the façade may have to do work of its own to trans- Application
late its interface to server application (subsystem) interfaces.
The interaction model of the façade pattern is one of client and Internet
server — that is, the interaction is unidirectional. In the inte- Access
Availability
gration façade pattern, the integration façade doesn’t know of
the existence of the individual client applications and the serv-
er applications are unaware of the integration façade.
The following example illustrates an application of the
integration façade pattern. A common situation in many Figure 8 — Point-to-Point Integration of Product Availability Systems
enterprises is that separate product lines have different sup-
port systems. Consider a full-service telecommunications ser-
vice provider. The company sells Internet access services as
well as voice services such as call waiting. Suppose the
Voice
Voice
Internet access support systems are largely package-based Ordering
Service
Application
and the voice service support systems are largely custom lega- Availability
cy systems. In that case, availability information for the two Integration
Integration
services will likely be housed in two different systems. A Facade
Adapter
Web-
request for availability information will access the voice ser-
Based Internet
vice inventory system or the Internet access inventory system. Ordering Access
An ordering application, which requires both voice service Application Availability
and Internet product availability, must access both availabili-
ty systems. One approach to integrating the ordering system
with the availability systems is illustrated in Figure 8.
As is the case with many point-to-point approaches to integra- Figure 9 — Product Inventory Integration Using an Integration Façade
tion, this approach has disadvantages. These include high applica-
tion coupling and the inability to share common logic (the integrat- between the ordering applications and the two availability
ed product availability logic is implemented in the ordering appli- resources. The integration façade implements the integrated
cation and is not available to other applications), both of which product availability logic and provides a simplified interface
reduce the flexibility of the business and system infrastructure. to the services of the two back-end systems.
For example, if a new application is added to the enterprise The integration façade pattern has two important special-
that needs an integrated view of product availability (e.g., a ties that are common in the enterprise. These are the business
Web-based ordering application), then the integrated product service façade and the activity service façade. The intent of a
availability logic must be repeated for the new application. business service façade is to decouple a client application
Worse still, if one or both of the availability systems should from the implementation of back-end services and to imple-
change, then all the applications that repeat the integrated ment a higher-level interface to back-end applications. Figure
product availability logic must change. 9 shows a business service façade used to provide integrated
A better approach to providing an integrated view of prod- product availability services.
uct availability is to use an integration façade (see Figure 9). The intent of the activity service façade pattern is to abstract
The figure shows the integration façade as an intermediary system interactions to the level of an activity (or task). The

70 eAI Journal • March 2000

activity service façade provides request-based services to a
process controller, which is part of the process automator pat-
tern (discussed later). A process controller is a program that Server
Application
Application
A
implements process activity sequencing logic. The interface A
published by the activity service façade conforms to the activ-
ity interface defined and required by the process controller.
The power of the activity abstraction is that the process con- Integration Server
Server
Application
Mediator Application
troller is completely decoupled from the implementation of Application
B
B
supplier applications that implement process activities. As a
result, the process controller will be unaffected by minor or
major changes to the supplier applications. Server
Application
Application
C
Integration Mediator Pattern C

The integration mediator pattern describes an architectural

approach to integrating applications where application inter- Figure 10 —Integration Mediator pattern
action logic is encapsulated and decoupled from the partici-
pating applications. The key benefits:

• Application dependencies and disruptions to existing appli-

cations are minimized. Online
• Maintenance is simplified as the application interaction Ordering
System
logic is centralized rather than distributed among the par- Wireless
ticipating applications. Service
Provisioning
• Reusable services can be conveniently built around the Legacy System
encapsulated application interaction logic. Ordering
System
These benefits provide a more flexible approach to inte-
gration and improve business agility.
In contrast to the integration messenger described previous-
ly, the integration mediator is application aware. The integra-
tion mediator pattern is shown in Figure 10. It consists of the Figure 11—Product ID Mapping Using Point-to-Point Integration
integration mediator and participating (colleague) applications.
The integration mediator contains the application interaction
logic. The colleague applications interact directly with the inte-
gration mediator, rather than with other colleague applications.
Online
The following example illustrates application of the inte- Ordering
gration mediator pattern. Suppose a telecommunications ser- System
Wireless
vice provider of voice services acquires a wireless telecom- Integration Service
munications service provider. The voice services provider has Mediator Provisioning
Legacy System
a Web-based, order-entry system for customer online ordering Ordering
and one legacy ordering system used by sales consultants. System
Similarly, the wireless service provider has its own ordering
systems as well as its own service provisioning systems (used
to activate and enable wireless services). Suppose the business
decides to add wireless service ordering capabilities to the
existing voice service ordering systems (the Web-based, order- Figure 12 — Product ID Mapping With an Integration Mediator
entry system and the legacy ordering system), thus providing
integrated ordering services to the ordering system users. systems is to use an integration mediator.
One element of this integration effort is to integrate the two In Figure 12, the integration mediator is used to centralize
voice service ordering systems with the wireless service pro- and encapsulate the common product ID mapping logic and to
visioning system. Part of the integration challenge is to map decouple the mapping logic from the two ordering systems.
product IDs from the online and legacy ordering systems to the Centralization of the mapping function simplifies product ID
product IDs used by the wireless service provisioning system. mapping logic development and maintenance. Decoupling the
One approach to integrating the systems is shown in Figure 11. mapping logic from the ordering systems reduces coupling
This approach has disadvantages; one is that the mapping between the ordering systems and provisioning system. This
of product IDs between the ordering systems and provisioning allows systems to change independently of one another, thus
system is replicated in both the ordering systems. improving overall business and system flexibility.
Additionally, the ordering systems are tightly coupled to the There are several degrees of interaction that can be managed
wireless service provisioning system. If the wireless service and controlled by an integration mediator. They can be broadly
provisioning system changes, both the ordering systems may grouped into stateless approaches and stateful approaches.
be substantially impacted. A better approach to integrating the A stateless integration mediator is used when the logic per-

eAI Journal • March 2000 71

formed by the integration mediator does not depend on the
state of the interaction between the applications. That is, the
integration mediator’s response to receiving a message (or Process Controller
event) from an application depends solely on the message con-
tent. The response is completely independent of all previous
application interaction instances. There’s no need for applica-
tion interaction state management and state persistence for
stateless interaction scenarios. Stateless scenarios include
message content transformation (an example is product ID Activity Activity
mapping) and intelligent routing. Service X Service Y

Message content transformations refer to translating from

one message format to another message format. The transfor-
mations may be of the syntactic or semantic variety. A syn-
tactic transformation refers to changing the message form. An
example is changing a date format or changing from mixed
case characters to upper case characters. A semantic transfor-
mation is a transformation based on the message data value.
An example is cross-referencing a product code from system
A to the product code used in system B.
Intelligent routing refers to controlling the message desti-
nation(s). The routing decision can be based on the message
content, source (system) or type, among other possibilities.
An example of intelligent routing is to route all provisioning
messages for a data product to the data product provisioning
system and all provisioning messages for wireless products to
the wireless product provisioning system.
A stateful integration mediator is used when the interaction
logic performed by the integration mediator depends on previ-
ous application interactions. A stateful interaction scenario is
when the integration mediator accumulates events and sends a
message to a destination application when some event accumu-
lation condition is met, such as receiving an event sequence
complete. Stateful interaction scenarios require state manage-
ment and often require state persistence. State persistence is
needed to maintain the integrity of application interactions in the
face of integration mediator system failures and for long-run-
ning interactions that must span system shutdown situations.
Stateful interaction scenarios can sometimes be highly complex;
the interactions may span minutes, hours or days, may involve
many states and events and may involve many applications.
Support for such complex interactions requires the ability to per-
sist the interaction state. Additionally, sophisticated develop-
Application Application
A B
Figure 13 — Process Automator Pattern
ment, deployment and runtime facilities are necessary.
Process Automator Pattern
The process automator pattern describes an architectural
approach to minimizing dependencies between process
automation control logic and Information Technology (IT) sys-
tems whereby all system interactions (and people interactions)
are hidden from the process controller via activity abstractions.
The key benefits:
• Powerful process automation solutions can be implemented
economically.
• The architecture enables unprecedented analysis of busi-
ness processes (e.g., process bottlenecks, statistics, error
fallout, resource utilization, etc.).
• The architecture enables unprecedented flexibility in redefin-
ing and rapidly deploying process automation applications.
• The process automation application implementation is close-
ly aligned with the business manager’s view. The semantic
gap between the business view of the world and that of IT is
significantly reduced. This minimizes the chance for errors
in translating from a business need to an IT solution.
• As with the integration façade and the integration mediator

Glossary of Key Terms

Term Definition
Publish and Subscribe A style of inter-application communications. Publishers can broadcast data to a communi-
ty of users or subscribers. An application or user can be both a publisher and subscriber.
Message Broker An intelligent intermediary that directs the flow of messages between applications, which
become sources and consumers of information. Message brokers provide a flexible com-
munications backbone and provide such services as data transformation, message routing
and message warehousing.
Message Queuing A form of communication between programs. Application data is combined with a head-
er (information about the data) to form a message. Messages are stored in queues, which
can be buffered or persistent. It’s an asynchronous communications style and provides a
loosely coupled exchange across multiple operating systems.
Source: www.messagequeue.com/glossary

72 eAI Journal • March 2000

 pattern, application integration logic is
encapsulated and can be shared.
Ultimately, the process automator
pattern improves business flexibility by
providing a flexible architecture for sys-
tem integration based on business
process automation.
The business driver for this pattern is
the need to improve the quality of the
output of a business process, reduce
process execution costs and/or reduce
cycle time. There are countless processes
repeatedly performed daily. This pattern
automates sequencing of the activities in
a process. The result is improved output
quality, reduced execution costs and
faster cycle time.
The core of this pattern is sequencing
and control of activities, which can be
automated or manual. For example, a
“product sale to customer” process
could have the following automated and
manual activities: assess customer
needs, select, price and configure prod-
uct(s), check product availability, per-
form credit check, ship the product(s)
and invoice the customer. Figure 13
shows the process automator pattern.
Figure 13 shows the process con-
troller, two activity services (see the
activity service façade variation of the
integration façade pattern discussed pre-
viously) under its control and two activ-
ity service façade supplier applications
(A and B). The process controller exe-
cutes a process definition that corre-
sponds to the process to be automated.
The activity services perform a neces-
sary task in the process definition. The
activity service façades provide a simpli-
fied and uniform interface to the ser-
vices provided by applications A and B.
The process controller is decoupled
from the API of applications A and B.
Some common constructs of a
process definition are activities, timers
and process context information. Figure
14 shows a generic view of a process
definition. As Figure 14 shows, the
process definition is centered on activi-
ties. Activity 1 is followed by two paral-
lel activities — 2 and 3. Activity 4 is
triggered by completion of 2 and 3. The
interval timer is a timer started by activ-
ity 1 and stopped by activity 4. If the
interval timer expires prior to activity 4
stopping the activity, activity 5 runs.
The process context contains informa-
tion particular to an execution instance
of the process definition.
eAI Journal • March 2000
Interval
Timer
Start
Activity 2
Activity 1
Activity 3
Process Context
– Process Attribute 1
– Process Attribute 2
Figure 14 — Process Definition
Conclusion
We’ve reviewed five key EAI architec-
ture patterns. All the patterns share the
goal of decoupling applications. The pat-
terns differ, however, in the level at which
decoupling occurs. The integration adap-
ter decouples at the interface level, the
integration messenger at the communica-
tion level. Both the integration façade and
integration mediator decouple at the
application level. Proper decoupling at
the architectural level is essential for
robust, flexible EAI solutions.
The intent of each pattern is as follows:
• Use the integration adapter to convert
an existing application interface to a
desired interface.
• Use the integration messenger to
minimize communication dependen-
cies between applications.
• Use the integration façade to provide a
simplified interface to back-end appli-
cations, minimizing dependencies
between client and server applications.
• Use the integration mediator to encap-
sulate application interaction logic,
minimizing application dependencies.
• Use the process automator to mini-
mize dependencies between process
automation logic and IT systems.
EAI architecture patterns can be a
powerful ally to EAI development orga-
nizations in the battle against enterprise
application integration complexity. EAI
architecture patterns help reduce inte-
gration complexity and improve the
chances for success in several ways:
Activity 5
Stop
Activity 4
• Robust EAI architectures can be cre-
ated quickly by selecting an architec-
ture from among proven EAI architec-
tures described in the EAI architec-
ture patterns.
• EAI architecture patterns can provide
a framework for evaluating the fit of a
tool and vendor for a given EAI prob-
lem and to identify tool strengths and
weaknesses.
• EAI architecture patterns can serve as
a framework for establishing EAI
standards in the enterprise.
In summary, EAI architecture pat-
terns provide a solid technical founda-
tion that significantly reduces the com-
plexities and risks inherent in EAI. eAI
About the Author
Jeffrey C. Lutz is
a principal consult-
ant at Denver-based
BoldTech Systems, a
leading telecommun-
ications Enterprise
Application Integra-
tion (EAI) and e-
commerce consult-
ing firm. He has over 13 years of system
design and development experience in the
telecommunications industry and extensive
experience in distributed systems develop-
ment. He has successfully architected and
implemented a wide variety of EAI and e-
commerce solutions for multiple telecommu-
nication firms. E-mail: jlutz@boldtech.com;
Website: www.boldtech.com.
73