6.4 Web Services and EAIFriends or Foes?

6.4 Web Services and EAI ”Friends or Foes?

Enterprise Application Integration (EAI) is an established technology used to integrate different business processes. It can link one application to another sequentially or, based on a predefined pattern (workflow), perform certain business functionality. Thus, different chains of events can be related together seamlessly without manual intervention or disruption. These events can also be programmed to handle different conditions with a rule engine (that is, Business Process), instead of hard-coding with specific conditions.

Another key feature of EAI is its integration with existing applications and legacy back-end systems, including mainframe and ERP systems. The value of EAI technology is that it provides seamless interoperability between systems across different platforms without rebuilding the business functionality. Many legacy back-end systems run on an IBM mainframe, a Tandem mainframe, a DEC platform, and a PC platform. Most of these systems store data in legacy databases and do not have interfaces or APIs for integration with external systems. To standardize a single interface or API on all these platforms would not be pragmatic. Many architects and developers will opt to utilize an EAI product to accommodate different data formats in each system and convolute into a single data format centrally .

EAI technology is often implemented using middleware products. Middleware can be point-to-point, queue-based, or publish-subscribe models. Typically, middleware products require building customized adapters for each system. The adapter is usually platform-specific. It is designed to transform data from a proprietary format to another for a specific application (Data Transformation). Data from one system is transformed and exchanged with another system via the customized adapters (Messaging).

If using EAI and CORBA technology together, customized EAI adapters can expose legacy business functionality by wrapping existing interfaces with an Interface Definition Language (IDL). IDLs provide a self-describing structure for the data and service provided (Service Definition). Client stubs will be generated from IDLs in order to access remote business functionality. They will look up a naming server in order to locate and bind the local or remote business service (Service Discovery). The physical business service may reside on another machine or at a remote data center in another country. This provides a more dynamic environment to bring together different business functionality within the enterprise. However, only CORBA-based EAI technology products require IDLs and naming servers.

EAI technology using Message-Oriented Middleware (MOM) is able to scale up with the use of a hierarchy of topics or queues (Manageability). Different topics or queues (hierarchical subject namespace that indicates the message category or application areas, such as PROD.TREASURY.FX, PROD.TREASURY.OPTION, and DEV.TREASURY.FX), can be managed and segregated to specialize in processing specific categories of transactions. Queues can also be clustered to provide message-level load balancing and resilience. In other words, the workload can be shared between queues under the same cluster. When the transaction volume goes up, architects and developers simply add more queues in the same machine or in another machine (that is, a choice of vertical and horizontal scaling). A queue can fail over to another queue under the same cluster automatically, if there is any message level anomaly. This is a better option than using proprietary interfaces or APIs.

Web Services technology has emerged as an enabling technology for B2Bi. Is it a subset of EAI technology or a competing technology? If we take the broader meaning of EAI, we can categorize Web Services and J2EE technology as part of EAI technology, as they provide different technology implementations for enterprise integration. If we take the narrow meaning of EAI, where EAI is often associated with MOM middleware, then we may see many similarities between EAI and Web Services.

We learned from previous chapters that Web Services technology has a self-describing service definition (WSDL). Clients may discover different business services from a Service Registry, whether a UDDI or an ebXML Service Registry. Once the business service is found, clients can send service requests to the Service Provider using SOAP messaging. Java technology has extended the current WSDL-UDDI-SOAP-based Web Services technology to provide XML data transformation using JAXP and XSLT. To address guaranteed message delivery and manageability, architects and developers can leverage the Java Messaging Service (for example, SOAP-JMS) to collaborate with SOAP messaging. Java technology also eases legacy mainframe or ERP system integration with Java Connector Architecture, which provides a service contract for better Quality of Service and transactional integrity. ebXML's Business Process Specification Schema (BPSS, http://www.ebxml.org/ specs /ebBPSS.pdf ), Web Services Choreography Interface (WSCI, http://wwws.sun.com/software/xml/developers/wsci/wsci-spec-10.pdf ), Business Process Execution Service Definition Language for Web Services (BPEL4WS, http://www.oasis- open .org/cover/bpel4ws.html ), XML Processing Description Language (XPDL, http://www.simonstl.com/projects/xpdl/ ), and Enterprise Distributed Object Computing (EDOC, http://www.omg.org/cgi-bin/doc?ad/99-03-10 ) are Web Services technology extensions to provide better enterprise and cross-enterprise integration. They can collaborate with existing EAI vendor products for cross-enterprise or B2B integration. This addresses the issue of interoperability between multiple EAI products.

Carol Murphy (2002) has summarized the differences and similarities between EAI and Web Services technology concisely (see Table 6-2). Murphy shows that both EAI and Web Services technology can provide service definition, service discovery, and messaging capability to support exposing remote system functionality as reusable services components . We can see that Web Services technology is extending more to cover data transformation, Business Process Management, and manageability. We are beginning to see more commercial Web Services products with Business Process Management capability (such as Progress eXcelon's BPM) in the market. In essence, current Web Services technology is a lightweight integration option and collaborates very well with or complements existing EAI products.

Table 6-2. Similarities Between EAI and Web Services Technology

Functionality offered in each architecture	EAI
	Web Services
Functionality Required	Service Definition	Messaging	Service Discovery	Data Transformation	Business Process Management	Manageability
Usage Required
Exposing existing application functionality	X	X	X	X		X
Exposing new application functionality	X	X	X			X
Combining multiple applications into an integrated business process (composite application)	X	X	X	X	X	X
Exposing an integrated business process	X	X	X		X	X
Managing a heterogeneous environment	X	X	X		X	X

Remarks

The ebXML Message Service is tied to business processing through BPSS ( http://www.ebxml.org/specs/ebMS2.pdf ) and Collaboration Protocol Profile/Agreement http://www.ebxml.org/specs/ebTA.pdf ). There are similar initiatives to address business processes in BPEL4WS ( http://www-106.ibm.com/developerworks/webservices/library/ws-bpelcol1/?dwzone= webservices ) and in similar ways. This has made the boundary between EAI and Web Services more difficult to differentiate.