 | Level: Introductory Daniela Rudrof (Daniela.Rudrof@de.ibm.com), IT Specialist, IBM Security Operations
Andre Tost (atost@us.ibm.com), Solution Architect, IBM WebSphere Business Development Group
01 Nov 2002 For some time now, IT staffers have been able to use elements of the Java 2 Platform, Enterprise Edition (J2EE) to integrate back-end systems. The recent emergence of Web services technologies has opened up new and previously unimagined ways to achieve similar ends. In this article, Andre Tost and Daniela Rudrof offer a vision of how J2EE and Web services can work together to ease enterprise application integration (EAI). You'll see how the Java Messaging Service and the Java 2 Connector Architecture can be used in tandem with Web services technologies to bring the integration process to a new level of abstraction.
These days, developers spend a lot of effort and resources on application integration. This includes integrating new applications with existing ones, as well as getting existing applications to communicate with one another -- all while keeping the number of changes to these applications to a minimum. Typically, this kind of integration is called enterprise application integration, or EAI. There are several products on the market today that aim to ease the process of EAI. In most cases, enterprises achieve integration by building a middleware infrastructure, along with several adapters that allow different back-end applications to plug into a common protocol of some sort and thus exchange data with each other.
The Java 2 Platform, Enterprise Edition (J2EE) addresses the need for making existing applications and business processes available on the Web in a robust, secure, and transactional way. Several specifications -- most notably the Java Messaging Service (JMS) and the Java 2 Connector Architecture (JCA) -- have been established under the J2EE umbrella to focus on integrating J2EE applications with non-J2EE environments. In addition, Web services technologies have recently caught a lot of attention in the integration arena by defining common ways for applications to interact with each other across heterogeneous programming languages and operating systems. This is made possible because Web services use XML as the base for their data formats, be it for the description of a particular service (that is, the Web Services Definition Language, or WSDL), or for the actual invocation of a service (that is, the Simple Object Access Protocol, or SOAP).
In this article, you'll learn how to take advantage of J2EE integration technologies -- specifically the JMS and JCA standards -- and enhance them with Web services technologies in order to implement enterprise application integration in a more standards-based and interoperable way. We will show how a common Web services-based interface can help you integrate a back-end system into a J2EE environment. By doing so, you'll support a higher level of automation and the use of various tooling environments, thus making it easier to connect back-end systems to each other without needing to worry too much about individual APIs and protocols.
Before you read this article, you should have a basic understanding of both Web services and J2EE technologies. If you are not familiar with these topics, see the Resources section below for links to useful papers, articles, and tutorials.
J2EE, JMS, and JCA
Many articles have been written about J2EE and the APIs that it includes, so we won't repeat all of that information here. But to get all of you in sync for what is to come later in this article, let us briefly review some of the technologies that we'll be using as the basis for our discussion.
Java Messaging Service
The Java Messaging Service (JMS; see Resources for more information) defines a common API that can be used to exchange messages between applications. It allows asynchronous communication between applications, in which one application sends a message to a message queue and afterwards continues its normal processing instead of waiting for the message to be received by another application. Any receiving application retrieves the message from the queue, interprets it, and processes it appropriately. Both applications can potentially run at the same or at different times, and on the same or different machines.
Communication between applications as described above is called point-to-point communication, because a message sent by one application is received by exactly one other application. An alternate model describing how multiple applications interact over the JMS API is called the publish-subscribe model. In this model, an application publishes a message to a certain destination called a topic; there, the message is picked up by any application that has subscribed to that particular topic. Thus, the same message is potentially received by multiple client applications.
The JMS specification only defines a programming interface for the use of message queues and topics, and it leaves the implementation of this API to a so-called message provider, which comes with every J2EE 1.3-compliant application server.
When you integrate back-end applications using JMS, the applications are often referred to as loosely-coupled. This describes a message created and sent in one transaction, which is then picked up from the queue and processed in a separate transaction. There is a level of indirection that separates the creator and processor of the message. JMS is transactional as far as the exchange of messages goes, but the exchange and processing occurs in separate transactions. In other words, the JMS provider can assure a message's sender that it was delivered to it's destination (a queue or topic) once and only once. However, whether or not an error occurred in the processing of the message is a whole different story.
Java 2 Connector Architecture
The Java 2 Connector Architecture (JCA; see Resources for more information) defines a way for J2EE applications to communicate with a non-J2EE environment (typically, an enterprise information system, or EIS), in a secure and transactional way. Solutions taking advantage of the JCA API are more tightly-coupled to a back-end than JMS-based solutions; that is, the JCA specification can combine the sending and processing of a message within the same message exchange, or transaction.
The specification defines various levels of interfaces between an application and an EIS. Basically, the specification describes how a so-called resource adapter is deployed between the application server and the back-end application. The resource adapter exists in the address space of the application server and implements the programming interfaces that allow interaction between the application server and the EIS.
Two levels of programming interfaces are defined in the JCA specification. One level is called the common client interface (CCI), which any J2EE component can use to interact with an EIS. Its use is optional, meaning that a resource adapter is not required to implement it. An EIS vendor is free to use its own interface. This makes sense, especially if this interface has already been implemented in an earlier integration approach. For instance, a database may already have wrapper classes that connect to the database and process SQL statements.
The other interfaces defined by JCA are a collection of system programming interfaces (SPIs), which are only used internally by the application server. The SPIs are divided into three categories, addressing the following topics:
- Security interfaces allow the application server and the resource adapter to handle signing on to an EIS -- by implicitly passing along a user ID and password combination to the back end on behalf of the client, for example.
- Connection pooling interfaces ensure that any resources needed to communicate with the EIS are shared and pooled amongst many clients.
- Transaction handling interfaces deal with managing distributed transactions across various back ends that support a two-phase commit protocol.
Figure 1 shows the different types of interfaces defined by the JCA specification.
Figure 1. Java 2 Connector Architecture overview
Many aspects of JCA deserve a closer and more detailed look by themselves, but we will leave that task to other articles and papers. For our purposes, the key to keep in mind is that, compared to a system based on the exchange of messages using JMS, integration using JCA is more tightly coupled. Processing done by the EIS is synchronous and thus can become part of a transaction managed by the J2EE application server. As a result, a business process run by a J2EE application across multiple back-end applications can be transactional -- either all of the steps performed by these applications are committed or none of them are.
Figure 2 (which has been adapted from the book J2EE Connector Architecture and Enterprise Application Integration -- see Resources for a link) shows how you can use both JMS and JCA to connect an enterprise information system to a J2EE environment.
Figure 2. Connecting J2EE and non-J2EE systems using JMS and JCA
Why Web services?
So far, we have looked at two major interfaces in the J2EE world that allow you to integrate a non-J2EE environment with a solution that runs within a J2EE application server. One scenario addresses loosely coupled, asynchronous integration based on JMS, while the other describes a more tightly coupled, synchronous model, utilizing JCA. So where do Web services fit into the picture?
Web services in general describe a slightly different view of the programming world than what we are used to, namely one in which certain business functionality is represented by a service rather than an object or component. A service implements a part of a business process in a way that allows it to be invoked from any programming language and any platform, typically across a network. The public interface offered by the service is described in a language called Web Services Description Language (WSDL), which is based on XML and defines ways to abstractly describe operations and their input and output messages in a programming-language-neutral fashion. As such, Web services provide a mechanism to integrate business functions regardless of the language or particular API that was used to implement them. Obviously, this makes them very useful for any effort targeting the integration of heterogeneous back-end applications.
Web services don't solve the EAI problem in and of themselves. Instead, they allow for better automation and better tooling and runtime support, making it easier for applications to communicate even if they were not built to do so. For example, tools exist that can build client-side proxies to access a service described by a WSDL document. WSDL documents can be derived from existing code. Since WSDL is a de facto standard (with formal W3C standardization expected in the near future), it is supported by multiple vendor implementations. Similarly, various runtime packages exist that support the provisioning and consumption of Web services via SOAP, just to give one protocol as an example.
Given all this, combining the characteristics of a J2EE environment (robustness, scalability, and security, among many others) with the advantages of Web services technologies (namely platform and programming language neutrality) for enterprise application integration seems like an obvious choice. In order to make use of the J2EE specifications that we described above, JMS and JCA, an application developer would require knowledge of specific programming interfaces. We want to define a programming model that is independent of these interfaces, one that provides a service-oriented view of existing business processes and functions. This means that we are looking for a common programming model that applies across a variety of different invocation mechanisms. In this model, all you care about as a developer is a service's interface as described in WSDL, and not the particular invocation protocol that is used to access that service.
Protocol bindings in WSDL
Any WSDL document contains three parts. The first defines the abstract interface of a service, represented by port types, which contain collections of operations (that is, business functions). Each operation is defined through an input and, optionally, an output message. These messages are XML documents, described by one or more XML Schemas.
The second part of a WSDL definition is called the protocol binding. This is where the protocol to which a given service responds is specified. For example, most Web services today are implemented utilizing the SOAP protocol (see Resources). Detailed information about how to build a SOAP envelope that a service can interpret can be added to the WSDL document for that service.
Finally, the third piece of information contained in a WSDL document is the endpoint of the described service -- that is, the location of the actual business logic that resides somewhere in the application server. This can be a URL, in the case of SOAP, or simply any address that a protocol can use to address the service.
We have said above that the J2EE standard defines ways to integrate non-J2EE applications by the use of APIs like JMS and JCA. So, what is needed to take advantage of both J2EE and Web services technologies at the same time? The abstract definition of a business function, describable via a port type in WSDL, is not dependent on the protocol used. Thus, we can describe all of the JMS- and JCA-specific information about a service in the protocol binding part of the WSDL definition. Figure 3 shows how parts of a JCA resource adapter can be mapped to corresponding artifacts of WSDL.
Figure 3. WSDL-to-JCA mapping example
We can define bindings for all kinds of different protocols. We've already mentioned JMS and JCA, which are the protocols that are probably the most relevant to enterprise application integration. But we can also easily utilize WSDL for invocations of ordinary or Enterprise JavaBeans. To the application developer, the specific protocol used should be transparent, so that he or she can focus on the business interface and not have to deal with the various client programming models to invoke them. You can then potentially access the service through a number of client access protocols, as shown in Figure 4.
Figure 4. Creating multiple bindings to a single service implementation
The Web Services Invocation Framework
So far, we have said that if we want to integrate legacy applications using the integration techniques available in J2EE, JMS, and JCA, we could describe the legacy applications' interfaces as WSDL port types and add protocol bindings with information about how to access them. To be truly independent of any programming interface, we need a mechanism that can parse and interpret binding information contained in WSDL and generate the appropriate runtime invocation for the service. For example, if a service is accessible through a JCA resource adapter, we need a way to automatically utilize the CCI interface provided by the adapter -- without requiring that the application developer know how to use CCI. In other words, we want to be able to invoke this service strictly based on its interface, not on its implementation or protocol.
The Web Services Invocation Framework (WSIF; see Resources for a link) provides an interface that allows the invocation a Web service independent of the protocol that is used to actually communicate with that service. Its programming interface is strictly based on the abstract service interface defined by the WSDL port type. The appropriate request message is built at runtime based on the binding information found in the WSDL document, thus making it transparent to the application developer.
Conclusions
Many IT shops today face the challenge of integrating applications that run on heterogeneous environments. The Java 2 Platform, Enterprise Edition defines various programming interfaces that allow the integration of such applications, which can then be utilized in building new business solutions that are Web-enabled, robust, and secure. The most prominent of these interfaces are JMS and JCA. JMS addresses asynchronous and loose coupling of legacy applications, whereas JCA allows for tighter coupling through synchronous and transactional interfaces.
Web services technology introduces the notion of a service-oriented architecture to a business system. Business functionality is represented by abstract definitions based on XML, as described in WSDL documents. We can integrate J2EE and Web services technologies by defining specific protocol bindings for JMS and JCA in WSDL; this allows us to define back-end interfaces in a common, protocol-independent way. At runtime, the Web Services Invocation Framework handles the generation of service invocations regardless of protocol, which means that an application developer doesn't have to manage multiple programming interfaces to access business functions.
While this technology does not eliminate the need for EAI, it increases the level of automation that can be applied to integrate heterogeneous application, both from a runtime and from a tooling perspective, because it increases the level of standards, supported by many vendors, that can be utilized. And that can only make the integration process easier.
Resources
About the authors | | | Daniela Rudrof works as an IT specialist in the Security Operations -- Control and Compliance GU Main department of IBM. She helps to ensure security standards within IBM as well as with external customers. Before taking up her current task, she wrote her final thesis within the WebSphere Business Development Group, focusing on J2EE technologies and Web services. Daniela lives and works in Germany. In her free time, she enjoys being outdoors and participating in sports, including soccer, swimming, and martial arts. You can reach Daniela at Daniela.Rudrof@de.ibm.com. |
| | |
Andre Tost works as a solution architect in IBM's WebSphere Business Development group, where he helps IBM's strategic alliance partners integrate their applications with WebSphere. His special focus is on Web services technology throughout the WebSphere product family. Before his current assignment, he spent ten years in various development and architecture roles in IBM software development, most recently for the WebSphere Business Components product. Originally from Germany, he now lives and works in Rochester, Minnesota. In his spare time, he likes to spend time with his family and play and watch soccer whenever possible. You can reach Andre at atost@us.ibm.com.
|
Rate this page
| |
