|< Day Day Up >|| |
Messaging middleware is a popular choice for accessing existing enterprise systems in an asynchronous manner. It is one of the options if you are implementing a solution based on the Message variation of the Direct Connection pattern in an intra-enterprise scenario.
A standard way of using messaging middleware from a Java application is using the Java Message Service (JMS) interface. JMS offers Java programmers a common way to create, send, receive and read enterprise messages. The JMS specification was developed by Sun Microsystems with the active involvement of IBM, other enterprise messaging vendors, transaction processing vendors, and RDBMS vendors.
In IBM WebSphere Application Server V5.0, the J2EE 1.3 specification is implemented, which includes JMS 1.0 and EJB 2.0.
According to the JMS 1.0 specification, a message provider is integrated in an application server. As shown in Figure 7-3, the integrated message provider makes it possible to communicate asynchronously with other WebSphere applications, without installing separate messaging software like IBM WebSphere MQ. WebSphere's integrated JMS server is based on IBM WebSphere MQ.
Figure 7-3: Integrated JMS Provider
An important new feature of EJB 2.0 is message-driven beans (MDB). Message-driven beans are designed specifically to handle incoming JMS messages. Further information on message-driven beans can be found in the IBM Redbook EJB 2.0 Development with WebSphere Studio Application Developer, SG24-6819.
Messaging is a form of communication between two or more software applications or components. One strength of messaging is application integration. Messaging communication is loosely coupled, as compared to tightly coupled technologies such as Remote Method Invocation (RMI) or Remote Procedure Calls (RPC). The sender does not need to know anything about the receiver for communication. The message to be delivered is sent to a destination (queue) by a sender component, and the recipient picks it up from there. Moreover, the sender and receiver do not both have to be available at the same time to communicate.
JMS has two messaging styles, or in other words, two domains:
One-to-one, or point-to-point model
When you want to integrate with an application not based on IBM WebSphere Application Server V5.0, an external JMS Provider is needed. IBM WebSphere MQ V5.3 includes built-in JMS Provider support with enhanced performance features for integrating JMS applications with other applications.
WebSphere MQ enables application integration by allowing business applications to exchange information across different platforms, sending and receiving data as messages. WebSphere MQ takes care of network interfaces, assures once and once only delivery of messages, deals with communications protocols, dynamically distributes workload across available resources, and handles recovery after system problems.
The JMS standard is important because:
It is the first enterprise messaging API that has achieved wide cross-industry support.
It simplifies the development of enterprise applications by providing standard messaging concepts and conventions that apply across a wide range of enterprise messaging systems.
It leverages existing, enterprise-proven messaging systems.
It allows you to extend existing message-based applications by adding new JMS clients that are integrated fully with their existing non-JMS clients.
Developers have to learn only one common interface for accessing diverse messaging systems.
Though JMS provides a common interface for Java applications to interact with messaging systems, it might lose out on some specific functionality offered by the messaging vendor. In that case, you might still have to write vendor-specific code to access such functionality.
JMS only provides asynchronous messaging, so the design is more complex when addressing response correlation, error handling, and data synchronization.
Further information on JMS can be found in the IBM Redbook MQSeries Programming Patterns, SG24-6506.
|< Day Day Up >|| |