Category list

- page 48

Summary

The late binding of server-specific information as you assemble and install an application is one of the benefits of the J2EE architecture, and is what allows components of an application to be reused in multiple scenarios. In this chapter we have reviewed the assembly of the web and enterprise bean components into the complete application. The references within the components were resolved, and the complete application was built. This process can be completed using the WebSphere Application Assembly Tool, but for newly created applications it is easier to complete the assembly within Studio, as we did in this chapter. We also reviewed the deployment of an application, and the installation of that application into the Studio unit test server and a production server.

Chapter 7: EIS Integration and Messaging

Download CD Content

Overview

So far, we have discussed how to build the presentation and business logic for an application and how to assemble them together. The business logic can be tied to a relational database using entity EJBs to provide object oriented data access.

In this chapter, we will explore other forms of access, including asynchronous messaging and procedural data access. Asynchronous messaging will be discussed by adding it to the PlantsByWebSphere example application. Procedural access will be discussed from a client point of view, but is not included by example because of the effort required to create an example by hand and the lack of common backends that an example could draw from.

We will also look at the Service Oriented Architecture. Service Oriented Architecture provides a means of describing, publishing, locating, and accessing systems in a synchronous and asynchronous manner. It complements the existing J2EE functionality by defining a mechanism that non J2EE applications can use to access applications deployed in a J2EE environment, as well as providing new means for J2EE applications to communicate. The Service Oriented Architecture is introduced at the end of this chapter and covered in more detail in Chapter 8.

The integration of back end systems with J2EE applications can be performed in a number of ways depending on the requirements of the integration. The J2EE architecture provides three technologies useful for Enterprise Information System (EIS) integration. They are:

JDBC
Provides both a direct form of access to database information, and an object model form of access using EJBs. This has already been discussed as part of the business logic chapter.
Java Message Service (JMS)
Provides a messaging API that allows for asynchronous communications between applications, though synchronous messaging is also possible.

J2EE Connector Architecture
Provides synchronous integration APIs to a wide range of resource managers.

Asynchronous Messaging

JMS ( http://java.sun.com/products/jms/docs.html ) provides the ability for an application to send messages to another application without waiting for a reply. There are two forms of message delivery that are supported:

Point to Point using message queues
Allows a peer to peer form of communication in which two parties agree to provide the roles of message producer and message consumer, as shown in the figure below:
Publish/Subscribe using message topics
Allows for a one many communications pattern, shown in the figure below, where a message producer places messages into a topic based on its topic name . Consumers that are interested in that topic can then subscribe to be notified when a message for that topic has arrived:

The following sections describe WebSphere's support of messaging followed by an extension of the PlantsByWebSphere application to support order processing using messaging.

WebSphere Messaging Engines

WebSphere provides support for a number of different messaging engines for use within the various WebSphere products. They are:

LightWeight JMS
Embedded JMS
External JMS/MQ

These three messaging engines cover different needs and are discussed in more detail below.

Lightweight JMS

The WebSphere Lightweight JMS engine provides messaging support for development tools – WebSphere Studio Application Developer ( WSAD ) in particular – for rapid iterative development use. WSAD uses the lightweight JMS engine to provide messaging support within the unit test environment. However, this does not imply that WSAD cannot be used with the other messaging engines. It can be configured to use any of the three JMS engines. See the Configuring the Test Environment section for details on setting up connection factories.

The Lightweight JMS engine provides a close approximation to the J2EE-required JMS functionality; but trades off support for security, persistence, and recoverability, for a quicker startup time. Both point to point and publish/subscribe messaging are supported. It will accept durable subscriptions and persistent messages, but they will not be persisted across a server restart. The lightweight JMS engine will also support transactional semantics, but the transaction will not be logged or recoverable across server restart.

The Lightweight JMS provider is designed to be an in process JMS engine and will not interoperate with the other WebSphere JMS engines. It is installed as part of the WSAD installation.

Embedded JMS

The embedded JMS engine provides a subset of the WebSphere MQ 5.3 and WebSphere MQ Event Broker 2.1 functionality. It is a fully J2EE-compliant messaging engine. JMS provider management is integrated with WebSphere Systems Management. The message engine server is automatically started and stopped as part of the server configuration. Topics and queues can be created as part of the JMS resource configuration. The embedded JMS provider can only be installed if WebSphere MQ is not already installed on the node.

External JMS/MQ

The external JMS engine provides complete functionality for JMS messaging including message queue clustering support. There can only be one WebSphere MQ JMS provider, embedded or external, installed on a node. If WebSphere MQ is installed before the WebSphere Application Server, the external WebSphere MQ already installed will be used. If WebSphere MQ is not installed before WebSphere is installed, the embedded JMS will be installed and can be upgraded to use the full external WebSphere MQ by installing it after WebSphere Application Server is installed.

The WebSphere product family provides additional messaging support in the form of WebSphere MQ Integrator Broker, which provides rule based message transformation and routing that can be visually composed into message flows.

Other Supported Messaging Providers

In general, WebSphere supports the use of MQ based JMS providers. Other JMS providers can be used from a client point of view for non managed connections to a JMS provider, but they cannot replace the functions provided by the WebSphere messaging engines. These non managed connections are obtained using the same programming model as WebSphere MQ-based JMS connections, but they are not integrated to provide connection pooling behavior.

WAS expects a JMS provider to have implemented the Application Server Facilities (ASF) of the JMS specification to fully integrate with the runtime (for example, to drive work on message driven beans). Many JMS providers do not implement this part of the specification.