Increasing visibility throughout the supply chain, improving efficiency across the enterprise, responding to regulatory or competitive pressures to reduce cycle times, eliminating errors due to inaccurate or out-of-date information, collaborating with your business partners. The common thread across each of these is the need for dissimilar business applications to interoperate effectively in support of business goals.

In any large organization, managing and maintaining the often spaghetti-like maze of connections between applications - your own and those of your business partners - is a costly and perpetual challenge. Enterprise application integration (EAI) is an effective solution. It offers a business process- oriented approach to integration that can insulate the processes that are the business from the systems that run it, facilitating a rapid response to changing business conditions. EAI creates efficient enterprise-wide communications, making information easily accessible throughout what Gartner calls the "enterprise nervous system." Most important, EAI reduces IT development and maintenance costs by minimizing expensive (and often redundant) custom development of point-to-point application connections. Note that in this article, I use the term EAI to cover both intraenterprise and interenterprise (e.g., A2A and B2B) application integration.

Web services are also predicted to transform the development and deployment of applications throughout and between enterprises. Some advocates even claim that Web services will spell the demise of EAI. Only time will tell whether this will be the case, of course. In this article, we'll examine EAI and Web services architectures and explore how each might be used within your enterprise. While there are similarities between the two models, significant areas of differentiation still remain that make EAI and Web services more complementary than competitive.

Enterprise Application Integration Architecture
EAI builds on proven middleware techniques such as message brokering and data transformation, and introduces architectural components called adapters for communication with applications and other data sources. EAI also incorporates business process modeling and workflow, metadata management, security and system administration, and monitoring. Working in concert, this set of services provides a robust environment for integrating disparate applications within and across enterprises.

Message Brokering
A message broker handles the fundamental role of ensuring reliable communication between applications and other system components. It manages the complex details of communication among different hardware platforms, operating systems, and network transport protocols. The message broker typically supports various service levels such as guaranteed once-only delivery or return receipt. It also supports both synchronous and asynchronous communication models such as publish-subscribe, publish-reply, and request-reply. The message broker uses rules, generally based on message type or message content, to route messages for delivery to appropriate recipients. Most important, if the recipient is unavailable for some reason (e.g., the receiving application is not running, the receiving system is unavailable, or there's some type of network difficulty), the message broker will queue the message(s) for future delivery once the recipient becomes available.

Data Transformation
Transformation services are essential to application integration since applications rarely, if ever, share a common data format or semantic model. This is even more apparent with business-to-business communication, even with all the standards-based efforts around common interchange formats such as EDI, RosettaNet, or ebXML. Traditionally, each individual application embeds separate transformation logic in its code base for every other application with which it integrates, thus dramatically increasing both application development and maintenance costs. EAI transformation services handle conversions among the differing message formats and semantic models used by the various applications participating in the EAI environment. Typically, EAI vendors offer a graphical interface and processing engine to create transformation and mapping rules, which can range from simple one-to-one field mapping to complex fan-in/fan-out operations involving external table lookup or multi level conditional substitution. With appropriate forethought during the design phase, transformation rules can often be reused for multiple integration scenarios, further reducing development and maintenance costs.

Adapter Architecture
An EAI system uses adapters to expose the functionality - in other words, the services - offered by participating applications or other data sources in a consistent manner. An adapter manages communication between the EAI system and the application, translating EAI system messages into application-specific events (and vice versa). In some cases, an adapter may translate a single EAI message into multiple calls to the application's programming interface, thus providing a higher-level "service interface" for the application. Adapters are typically designed to be non invasive - that is, to use whatever interface mechanisms are already supported by the application so it requires no modification in order to communicate with the EAI system. Adapters can also handle management functions such as alerting the EAI system if the participating application becomes unresponsive or unavailable.

All EAI vendors offer an adapter development kit to create your own adapters. Most also offer a wide range of prebuilt adapters for commercial applications or other technologies, which can dramatically reduce development time. Examples include:

• ERP and CRM applications: SAP, Oracle, PeopleSoft, and Siebel
• Application-independent formats: Flat file, fax, e-mail, or wireless application protocol
• Database protocols: ODBC, JDBC, DB2, and SQL
• Internet formats: HTTP/HTTPS, XML, WS DL, and SOAP
• Custom applications: Developed using COM/DCOM, CORBA, and EJB
• Mainframe protocols: IMSL and CICS
• Industry-specific formats: EDI/EDI FACT, SWIFT, HL7, and RosettaNet
• Messaging systems: MQSeries, TIBCO, and JMS

Business Process Modeling and Management
Sophisticated EAI packages now offer a business process-centric model. During the application design phase, business processes are modeled as a set of integrated, event-driven activities (or nested processes) supported by multiple applications or people. These integrated business processes may include activities that span departments, divisions, or enterprises. People may also be involved if the process requires an approval or override or if the situation requires a judgment call (e.g., deciding whether to underwrite a questionable insurance risk). During the development phase, the integrated business process models are mapped to a set of messages, information objects, transformation, and other processing rules, and supporting application or technology adapters. In production, the EAI software "runs" the integrated business process models, orchestrating the event-driven information flow between applications. If an exceptional condition causes a process to terminate or stall, the EAI system can alert the system operator or monitoring software to the nature of the problem.

Many integrated business processes are composed of multiple activities, some of which must be completed as a "work unit" in order for the process to be considered successful. While the traditional two-phase commit approach can't be applied to loosely coupled system integration, where applications may span enterprises and transactions may last for hours or days, the EAI system does need to ensure that all steps in a business transaction are successfully completed before allowing the entire transaction to progress forward. In the case of failure, the EAI system can restart the transaction at a known "stable" point. In some cases, a designer can even teach the EAI system to take corrective action by defining compensating transactions within an integrated business process that can be invoked to "undo" or work around a problem.

Metadata Repository
The EAI metadata repository acts, in essence, as the service directory for all information about the integration environment. Metadata includes definitions for integrated business process models, messages and integration objects, rules governing data transformation and other processing, parameters for application connectivity and system management, user roles and security information, trading partner profiles, and status information about in-flight business processes or other system components. Components within an EAI environment query the repository to determine the services that are available and their connectivity details (note that these services are restricted, however, to the particular EAI environment and not publicly available, as in the Web services model). Changes to system metadata can be automatically propagated to the affected EAI system components. The EAI repository is generally built on an industry-standard database, which may be deployed as a single instance or distributed across multiples sites for better performance.

Security
In an open applications environment, particularly for business-to-business transactions but even for intraenterprise integration in environments such as finance or health care, security concerns are para-mount. Security services include authentication, authorization, encryption, nonrepudiation and dynamic setup and closure of sessions between trusted partner companies, where sessions are supported over days rather than seconds. Some EAI vendors support LDAP or other directory services that provide user authentication or authorization information. In an integrated environment, it's important that security be managed across the entire life cycle of an integrated business process, not simply between any pair of activities participating within it.

System Administration and Monitoring
As there are many "moving parts" in an integrated applications environment, system administration and monitoring services are critical. System administration and monitoring services enable an administrator to deploy, manage and monitor system components, including in-flight integrated business processes, message brokers, queues, adapters, and metadata repositories. Some EAI systems can integrate with popular third-party systems' monitoring packages, allowing a system administrator to leverage existing resources and skills and have a unified view of the entire hardware, software, network, and applications and integration environment.

Web Services Architecture
The Web services architecture is defined by a set of specifications covering three major functional areas: service definition, messaging, and service discovery. Future specifications are expected to address other areas such as business process management.

Service Definition
The Web Services Description Language (WSDL) is an XML format for describing network services. WSDL includes both an abstract and a concrete description of a Web service. The abstract definition describes the operations and parameters (i.e., the messages) supported by the service. The concrete definition defines the implementation (or bindings) for the service, including the required network protocols, wire protocols and network endpoint addresses needed to invoke the service.

WSDL does not address any business process-modeling aspects of Web services - in other words, how developers should combine and orchestrate Web services (and possibly other application functionality) to create higher-level integrated business processes, which could themselves then be offered as Web services. Several alternate standardization efforts are under way to address these issues, including Business Process Modeling Language (BPML) and Web Services Flow Language (WSFL).

Messaging
The Simple Object Access Protocol (SOAP) is an XML-based protocol for exchanging information in an open network environment. SOAP describes the structure for a message and how to process it, a set of encoding rules for the message parameters, and a convention for representing remote procedure calls and responses. In the Web services runtime environment, a SOAP "listener" receives and accepts a SOAP message, extracts the XML message body, transforms the message into a native protocol, and delegates the request to the appropriate application for processing.

In theory, SOAP can support almost any message transport protocol, although SOAP V1.1 only defines bindings for HTTP. This presents some significant limitations for use in enterprise application integration scenarios, since HTTP does not support reliable or asynchronous messaging and its security capabilities, even using HTTPS and SSL, are restricted to connection-level requirements.

Service Discovery
WSDL is helpful to describe and invoke a Web service and SOAP is helpful for communicating with it, yet both are of limited use if no one knows about the service in the first place. To this end, a Web service provider can advertise its capabilities in a repository conforming to the Universal Description, Discovery, and Interaction (UDDI) standard. Web service clients can query the repository, searching either by service capability (yellow pages model) or by known service provider (white or green pages model). When a match is found, the repository returns the WSDL description corresponding to the Web service, which the client can use to format a request to the service for execution.

UDDI in its current form does have some limitations: it doesn't support the ability to rate service providers in terms of reliability or trustworthiness, to locate alternate service providers, or to notify clients if a service's definition or location has changed. Strictly speaking, UDDI isn't part of the Web services architecture or even necessary to implement it. Web service definitions can be advertised on regular Web pages or stored in conventional system directories. Alternative directory standards have also been proposed that may address these shortcomings.

Peaceful Coexistence
The Web services architecture presents a model for the development and deployment of new network-based application services. The EAI architecture presents a model for integration of new and existing applications, including Web services, within and between enterprises. Although the implementation details still vary considerably, as we've discussed, both EAI and Web services include messaging, service definition and service discovery (i.e., metadata in an EAI world). The Web services model does not currently address business process management, data transformation, system management, security, asynchronous communication, or reliable messaging - which are all essential in an application integration environment.

Let's explore a few areas for using Web services and EAI, as shown in Table 1:

Exposing existing application functionality
Some commercial software vendors, such as SAP, have announced that their products will eventually offer native Web services interfaces, so you could just decide to wait a while. For other existing applications that already support service-oriented interfaces, some EAI vendors offer tools to generate Web service definitions from existing application interfaces, including applications for which they already provide adapters. After all, a Web service definition is simply another form of application interface. On the other hand, if the application does not currently provide a service-oriented interface - for instance, if it requires multiple calls and/or preprocessing logic in order to act service-like - an adapter could also be used to provide a higher-level service interface that hides these details from clients of the service. Finally, if the application does not offer an interface that can be easily exploited, the case for many legacy applications, then exposing its functionality will be a challenge in a Web services or an EAI environment. Leveraging a prebuilt EAI adapter is the best choice in this case.

Exposing new application functionality
It makes sense to consider adopting a Web services model for new application development if you can work within the constraints of the current specifications and recognize that the specifications are still in flux. Since the current Web services model provides no support for reliable messaging, asynchronous communication or stringent security, Web services applications should be limited to internal enterprise usage where these may be less critical. If you do require this functionality, either leverage a pre-built EAI adapter or develop a custom EAI adapter for your application.

Incorporating services from multiple applications into an integrated business process
The main benefit of exposing any (new or existing) application functionality as a service is to allow it to be combined with other services in support of some integrated business process. This process may itself be considered a composite application, in which loosely coupled applications work in concert to solve a business need. To do this clearly requires the business process management, reliable messaging, data transformation, application connectivity, security and system management capabilities available today only in EAI environments. Of course, you could build these capabilities from scratch as part of a custom application development effort, but one would have to question such an investment decision when robust commercial integration packages are already available.

Exposing integrated business process functionality as a service
Building on the previous example, many enterprises will want to expose some of their integrated business processes as Web services for internal or external use. EAI tools that can create Web service definitions for integrated business processes will be the best option to provide this capability.

Managing an integrated systems environment
Enterprise environments include a complex combination of commercial, custom and legacy applications, integrated business processes, and now Web services, along with the systems that support them (e.g. hardware, networks, printers, firewalls). Components within such an environment must be "manageable," and we need tools that can effectively and coherently manage these disparate resources as an integrated whole. This remains a challenge for both Web services and EAI environments, although at least one EAI vendor is working aggressively with leading system management vendors to address it.

Conclusion
It should now be clear that the choice between EAI and Web services does not need to be an either-or proposition. The Web services model is a good choice for new application development, if you can work within the constraints of the current specifications. For integration-related activities that require industrial-strength reliability, security, and manageability, the enterprise application integration model remains the clear choice. EAI vendors are quickly moving to embrace Web services within their own products, so a combination approach is also a viable alternative.

Some day the two models may converge. Even if this does occur, it will still be several years away given the relatively slow pace of standardization efforts and the typical delay before approved standards actually materialize in commercial products. A more likely scenario is that EAI and Web services will peacefully coexist as complementary approaches to the perennial (yet separate) challenges of application development and integration. These are fundamentally different problems, and as every enterprise architect knows, few tools or approaches work well for every situation.

• Figure 1