JMS and its Relation to Other J2EE Technologies

The Java platform supports data exchange through a large set of middleware services like databases, asynchronous messaging systems, CORBA ORBs, etc. Java's platform independence and the availability of a large number of middleware services, is turning it into an excellent platform for enterprise solutions. The JMS API has been designed to integrate well with other enterprise Java APIs thus making it an enabling architecture to develop and deploy multi-tier distributed enterprise applications.

JMS and JDBC

JMS clients may use Java Database Connectivity (JDBC) with JMS in the same transaction. It is possible to do this with the Java Transaction API (JTA), but in a lot of cases, this will be achieved automatically by implementing these clients as message-driven EJBs.

JMS and EJB

Unlike other types of Enterprise JavaBeans (EJB), which are synchronously invoked by the EJB container in response to method calls from EJB clients, in the 2.0 version of the EJB specification, the message-driven bean is a type of EJB that is asynchronously invoked by the EJB container when a JMS client sends a message to it. JMS has thus become an important resource that will be available to EJB component developers. It can be used with other resources to implement enterprise services. See Chapter 7 for more details on JMS and EJBs.

JMS and JTA

The Java Transaction API (JTA) provides the transaction developer the requisite API to delimit distributed transactions and an API for accessing a resource's ability to participate in a distributed transaction. A JMS client can therefore use JTA to delimit distributed transactions. This is a function of the transactional environment that the client is running on and not a feature of JMS. However, a JMS provider can choose to support distributed transactions using JTA.

JMS and JTS

JMS along with the Java Transaction Service (JTS) can be used in distributed transactions to combine message sends and receives with database updates and other transaction services. The J2EE-compliant application server should automatically handle this even though it is also possible for JMS clients to code this programmatically.

JMS and JNDI

Configured JMS objects are created on a context accessible through the Java Naming and Directory Interface (JNDI). JMS clients look up these configured JMS objects using JNDI. JMS administrators use provider-specific facilities for creating and configuring these objects. JMS defines connection factories and destinations as administered objects that are configured and placed in a JNDI naming context. This ensures that JMS applications are easy to deploy and highly portable.

JMS and the CORBA Notification Service

The CORBA notification service provides filtering, delivery guarantee semantics, durable connections, and the assembly of event networks on top of the CORBA event service. It gets its delivery guarantee semantics from the CORBA messaging service (which defines asynchronous CORBA method invocation).

Java is already integrated well with CORBA. As of now, Java IDL and COS Naming have been bundled with the JDK since version 1.2. Most uses of COS Naming have been through the JNDI. Similarly, Java already provides RMI over IIOP to integrate seamlessly with CORBA. Most uses of JMS with the CORBA notification service will be through RMI over IIOP. There are a lot of CORBA vendors who are coming out with support for JMS layered on top of CORBA. Instead of competing with the CORBA notification service, JMS will interoperate seamlessly with it and help extend CORBA's reach to Java enterprise platforms.