The mission of Web services however, is to provide high-level interoperability interfaces for business collaboration. Web services are based on XML technologies, designed from the ground up for seamless interoperability over the Internet. Therefore, Web services should be designed as document-oriented exchange systems and tuned to the needs of business collaborations. This differs from the object-oriented interfaces of business-tier components. Business-tier components require tighter coupling, which is difficult to achieve within companies on shared business processes. Web services, on the other hand, connect independent companies (actually their information systems) in a more loosely coupled fashion.

Web services pose new challenges for an information system. Today's requirements are very high - companies need to provide instant, online access to up-to-date information delivered with efficiency, reliability, and quality. Customers expect immediate response, and are not satisfied with days (nor even hours) of delays in confirming orders.

However, these delays are often the case when e-business is not backed by an efficiently integrated enterprise information system (EIS). In most cases, Web services will not implement their functionality themselves. Rather, they'll make several calls to the EIS applications. The problem here is that existing EIS applications have usually been developed with different, even legacy, technologies, and are very heterogeneous. Accessing these systems directly from Web services can be difficult because each existing system is unique and potentially requires a unique way to access it. This approach requires far too large an effort for development, and particularly for maintenance, because each change in the existing system will require an update in all related Web services.

Therefore, enterprise application integration (EAI) is the most important prerequisite for efficient Web services. Only an integrated information system inside the company allows on-demand processing of e-business requests. The responsiveness of Web services and the adequate quality of information provided through them can only be achieved by the tight integration of an enterprise information system in the back end. EAI is the key success factor for the successful introduction of Web services.

Research from leading consulting companies such as the Gartner Group confirms this thesis. It also shows that today there are very few Web services (or other means for front-end systems to directly communicate with business partners) that are efficiently integrated with the back-end applications inside the company. Most nonintegrated solutions fail to meet business expectations.

What is Enterprise Application Integration?
EAI, although not a buzzword anymore, is far from being an easy or well-defined task. Indeed, it has become one of the most difficult problems facing enterprise application development in the last few years. The major challenges relate to the integration of the different domains, architectures, and technologies. If we wish to integrate, we must also find ways to allow the coexistence of different architectures, and solve problems inherent with integrating several different technologies. In addition to all of this, we also have to look closely at application content in order to solve the problems of data redundancy and different views of the same problem. These conceptual challenges may be more difficult to overcome than the technical ones. To make things even more difficult, there is often a significant investment already in place for a variety of application integration technologies that we must deal with. Furthermore, the requirements placed on information systems are both growing significantly and changing frequently. Integration projects, therefore, have to be performed in the shortest possible time, deliver results quickly, and adapt to these ever-changing requirements. Of course, the resources for integration are often limited, too.

EAI is the total integration of applications within an enterprise. From the business perspective, it is the competitive advantage a company gets when all applications are integrated into a unified information system capable of sharing information and supporting business workflows. Information must often be gathered from several domains and integrated into a business process. Without EAI, although the required information may well be available and exist in some form somewhere in an application, for typical users it is practically impossible to access it online.

From the technical perspective, EAI refers to the process of integrating different applications and data to enable sharing of data and integration of business processes among applications without having to modify these existing applications (too much). EAI must be performed using methods and activities that enable it to be effective in terms of costs and time.

EAI with J2EE
In most real-world cases, companies have to perform EAI together with the development of new solutions (including Web services). Then it becomes a logical step to consider a modern software platform for both, and the new development. Java 2 Enterprise Edition (J2EE) is one of the two most important modern software platforms today. The other is Microsoft .NET. In this article, we will focus on J2EE.

As we know, J2EE is a very suitable platform for the development of Web services. Let's consider whether J2EE is also suitable for EAI. For successful EAI we need middleware technologies that provide an adequate infrastructure for the communication between existing applications. The J2EE platform provides support for a number of middleware APIs and protocols. The most important middleware APIs in J2EE are JDBC, RMI-IIOP, Java IDL, JMS, Java Connector Architecture, and JNDI. Very important APIs, which we'll discuss later, are JAXP (and other JAX APIs) for XML support, JTA and JTS for transaction support, and JAAS for authentication and authorization. The most important protocols supported by J2EE are HTTP(S), and IIOP.

For successful integration, we also have to define the integration architecture. This architecture should take advantage of the existing system's information and code and should easily accommodate new generation applications, particularly e-business solutions such as Web services.

Therefore, the integration architecture should be similar to the architecture of modern applications. This means that it should be multitier and component-based. The problem, however, is that most existing and legacy systems don't comply with this architecture. They don't look like components and they're not multitier. The challenge, therefore, becomes how to make the existing systems look like modern ones.

The solution is to place existing applications in the data-persistence or EIS tier and to find ways to encapsulate these existing applications into virtual reusable components that will expose the functionality though interfaces. Clients accessing these components through the interfaces won't see whether they're dealing with newly developed components or encapsulated legacy components; they'll access both in the same manner.

Virtual components implement the facade pattern for the existing systems. However, to provide the functionality of existing systems, virtual components have to access them programmatically. This can be achieved relatively simply if existing applications already provide some APIs. Otherwise, or if they're provided but don't meet our requirements, then we'll have to define and build them. For this, we'll modify the existing application and add the necessary APIs. This is called wrapping and is shown in Figure 1.

Adding wrappers can be quite straightforward, especially in solutions that have been developed in-house and where source code and documentation are available. However, with applications where we don't have the source code and where the documentation is limited, changing the application can be difficult.

The most important fact is that the component interfaces become the contracts in the integrated architecture. From that perspective, the interfaces have a very important role. As long as they stay unchanged, we can modify the implementation of the components without influencing the rest of the system. In other words, as long as we use the same interfaces, we can replace existing systems with newly developed solutions and none of the clients will ever know that a change has occurred.

Therefore, how we define the virtual components is very important. We have to focus on their semantics and define them on a highly abstract level, rather than just exposing the functionality of existing applications. Otherwise, it would be very difficult to replace existing systems with the new ones and preserve the interface. Consequently, achieving efficient integration is always connected with redesigning the information system as a whole, which is also a good opportunity to perform business process reengineering.

J2EE Technologies for EAI
J2EE provides the necessary technologies for developing virtual components and wrappers. Because J2EE supports several open standards for communication between tiers, such as HTTP(S) and IIOP protocols and APIs, such as JDBC, JMS, JNDI, and JCA, we can include components that have not been developed in Java on practically any of the tiers, thus providing a way to integrate existing applications.

On the business-logic tier we can deploy not only EJB components, but also CORBA (and RMI-IIOP) distributed objects and components communicating through a JMS-compliant MOM. This is one of the most important facts for integration. We can see that for developing virtual components on the business logic tier, we're not limited to EJBs but can use CORBA, RMI-IIOP and MOM components too. Please note that CORBA and MOM components don't have to be developed in Java; rather, we can use a variety of programming languages. Both CORBA and leading MOM products support all popular programming languages, including C++, C, Smalltalk, Ada, COBOL, Delphi, and even Visual Basic.

These non-Java components don't reside inside the EJB container, and as such they can't take advantage of the managed environment provided by containers. However, they can still take part in transaction and security mechanisms. For this, they have to use the corresponding APIs. Support for both-transactions, and security-is crucial for successful EAI. Let's look at how transactional and security integration can be achieved in J2EE.

To access the J2EE transaction service functionality, we can use JTA (the Java Transaction API). JTA provides an abstraction layer on top of JTS (the Java Transaction Service). This abstraction layer enables the platform to choose which JTS implementation it will use. The implementation, which is typically provided by the application server, is transparent to the application components because those components don't interact with JTS directly.

The really important fact for integration is that JTS is compliant with CORBA Object Transaction Service (OTS) 1.1. More exactly, JTS is the mapping of the CORBA OTS 1.1 to Java. It propagates transactions using the IIOP protocol. CORBA OTS provides support for distributed transactions and interoperability with X/Open DTP (Distributed Transaction Processing)-compliant transactional systems. Fortunately, the majority of today's transactional systems are X/Open DTP compliant.

However, the J2EE specification 1.3 does not require a J2EE implementation to support distributed transactions. Fortunately, most important J2EE application servers, such as BEA WebLogic, IBM WebSphere, Oracle 9iAS, and others, provide support for distributed transactions. If we choose such application servers, we'll be able to achieve transactional interoperability relatively easily with X/ Open DTP-compliant EIS systems. EIS systems that implement their own local transactions, which are not X/Open DTP-compliant, will require more manual work to achieve transaction integration. We'll have to commit or roll back each system explicitly and manually. One technique to manage this scenario is to use compensating transactions.

Security is another important topic for EAI. As we know, Java has a policy-driven, domain-based security model. It provides extension packages, which were initially introduced as optional but have been integrated into J2SE 1.4, including:

For authentication, JAAS supports different models to be plugged in at runtime. This enables us to use an industry-standard authentication technology through all the integrated applications. The most commonly used authentication technology that enables single sign-on support for multiple applications is Kerberos. Kerberos is a network authentication service created by MIT. For more information on Kerberos see http://web.mit.edu/kerberos/www.

JAAS, together with JSSE and JCE, enables us to build our own EAI security infrastructure. It allows us to wrap the existing applications in the same security process - using industry standards such as Kerberos for authentication and SSL and TLS for communication channel protection and application-independent encryption engines.

In EAI projects that involve integration of non-Java applications and resources, J2EE-based security may not always be sufficient to achieve end-to-end security. An alternative is to use the CORBA security model. This model can be used from Java as well as from applications written in other programming languages. It's outside the scope of this article to go into the details of CORBA security. More information can be found at www.omg.org.

Another possibility is to use the Generic Security Services (GSS) API, developed by the Internet Engineering Task Force. GSS provides a generic authentication and secure messaging interface that supports pluggable security mechanisms. GSS version 2 is defined in a programming language-independent format. Through GSS, applications can use different security mechanisms without having to make changes to the application itself. Java bindings for GSS are referred to as JGSS. The JGSS API is part of J2SE 1.4. JGSS allows Java developers to create uniform access to security services over different mechanisms, including Kerberos.

JGSS has some important features that the Java security model doesn't, including support for Kerberos cipher suite; ability to use any transport protocol for communication, not just sockets; and selection of encryption type. JGSS is likely to emerge as the standard API for security integration in EAI.

Support for transactions and security is the main reason we don't use Web services technologies for developing the EAI architecture. Web services currently don't provide adequate support for transactions and security and they have other disadvantages for EAI. Their performance and scalability is lower due to the use of XML-based protocols, which require more effort for marshaling and generate more network traffic. Finally, it's important to note that the tools and APIs for Web services in J2EE are still under development.

Web Services - the Next Logical Step
We can build Web services directly on top of the proposed EAI architecture. We should consider them as highly interoperable entry points for business partners. One approach is to map the business logic component interfaces to Web services directly, which will usually require that we develop a dedicated component (for example an EJB) that will provide a suitable document oriented interface. This approach is supported by the leading J2EE application servers, which provide tools to convert EJBs to Web services.

The other approach is to build Web services on workflow-based models, where each Web service calls several business components and other resources to fulfill the request. This approach requires more development work and some knowledge of the corresponding APIs. J2EE version 1.3 currently provides support for XML through the Java API for XML Processing (JAXP) only. Support for XML, provided through JAXP, is very primitive if we want to use it for Web services development. Fortunately, Sun's Java Community Process is currently defining additional XML-related specifications, most of them focused on Web services, including: JAXM (JSR 67) Java API for XML Messaging, JAX/RPC (JSR 101) Java API for XML-based Remote Procedure Calls, JAXR (JSR 93) Java API for XML Registries, JWSDL (JSR 110) Java Web Service Definition Language, and JAXB (JSR 31) Java API for XML Binding. These APIs are still under development and not a standard part of J2EE 1.3. In the meantime, we have to use custom APIs provided by application server vendors or add-ons, which can limit the portability in the future. Therefore, the first approach seems to be more suitable today. Figure 2 shows how Web services can be integrated on top of the composite information system EAI architecture.

Conclusion
We've seen that Enterprise Application Integration (EAI) is crucial for developing efficient and well-connected Web services. Only if the Web services are satisfactorily connected with back-end information systems can they provide immediate and accurate information to business partners - a prerequisite for successful e-business collaboration.

The fact is that most Web services will have to use existing and legacy applications as back-end solutions. Making the integration between such systems efficient will be the key success factor. In particular, immediate response and immediate propagation of data to all related applications will be the major issue. Web services that aren't efficiently supported by back-end applications will most likely fail to meet the requirements.

Resource