Introduction

Messaging systems are used to build reliable, scalable and high performance applications. A messaging system shields programmers from the complications of message buffering and dissemination, crash recovery, client registrations, lost connections, etc. However, messaging systems have so far been proprietary, making application code non-portable and difficult to migrate to a different product. Also, the learning curve for messaging systems has been steep due to the lack of common concepts and APIs.

The Java Message Service (JMS) is an API defined by Sun Microsystems, which specifies how Java client applications can access an enterprise messaging system. JMS plays a fundamental role in J2EE as the foundation for Message Driven Beans. Although different vendors will still implement JMS using different transport mechanisms and message protocols, the specification allows programmers to write portable code using familiar concepts.

This guide provides an introduction to messaging middleware in general and the Java Message Service in particular. The intention is to show both how JMS fits in the bigger picture, and what specific benefits messaging and the Novell exteNd Messaging Platform can provide. If you are already familiar with these concepts, you can skip to the Administrator's Guide, which provides an overview of the features provided by JMS in the Novell exteNd Messaging Platform. Also, you may skip straight to the tutorial, which provides detailed information about JMS by describing Java programming examples.

Middleware

The Internet has provided tremendous growth opportunities for businesses engaged in e-commerce. Although e-commerce provides a more direct interaction with customers and a potential for higher transaction volume, companies that enter this fast-paced, dynamic environment often discover that their computer systems:

• Cannot keep pace with the volume of online transactions
• Require much more data storage capacity
• Are hard to modify or extends according to new requirements
• Conduct increased communications with customers and suppliers

New hardware and specialized software provide a solution, but one that often becomes outdated as the business grows. Therefore, traditional two-tier, client/server models for Internet-based applications are being replaced with architectures composed of multiple tiers:

• The upper tier (back-end) contains the enterprise level applications and data
• The middle tier is where server-side applications (middleware) operate
• The lower tier contains the client interface

The systems in the middle tier provides business solutions and services such as:

• Naming
• Security
• Messaging
• Database management

For developers creating Java applications, enterprise Java APIs have been standardized to provide access to these services. Middleware is loosely coupled with applications running in the upper and lower tiers, and is accessible to all components of the enterprise.

Loose coupling ensures a high degree of reliability because it isolates middleware from hardware or application failures that can occur on the other tiers. By providing services that link processes running on many computers across a network, middleware leverages existing software and hardware investments.

Message-Oriented Middleware

Message-oriented middleware (MOM), is a specialized type of middleware that connects heterogeneous applications. MOM applications are characterized by the following attributes:

• They are event-driven
• Messages are passed in many formats
• Messages are delivered fast and reliably
• Senders are de-coupled from receivers

The MOM component provides dependable mechanisms for applications to create, send, and receive messages asynchronously within an enterprise environment. To better understand the potential benefits of messaging, consider the differences between traditional synchronous communication such as Remote Procedure Calls (RPC) and asynchronous communication:

Synchronous communication

Synchronous communication is conducted between clients and servers in a traditional client/server model. Both parties must be available to participate, and must acknowledge receipt of a message before they can proceed to the next request. As the volume of traffic increases, more bandwidth is required, and the need for additional hardware becomes acute.

Because synchronous communication requires both parties to be running and available to process incoming requests, they are sensitive to hardware, software and network failures. The real issue here is that applications typically have to implement substantial logic to deal with various error situations to ensure that failures "just" result in slower response times rather than no response at all.

Asynchronous communication

The parties servers and clients are peers, and can send and receive messages at will. Unlike RPC, asynchronous communication does not require real-time acknowledgement of a message; an agent can move on with its business once it sends the message. This is achieved by putting a service in-between the client and server, which acts as an intermediary.

In real-world operations, asynchronous communication means that mobile or portable PCs can be switched off, and when they log on again, receive messages that have accumulated since the last time they were connected. This also means that component failures are inconvenient instead of catastrophic - messages may be delayed, but will not be lost.

The other benefit of using and intermediary is that the message sender does not have to execute in lock-step with the message receiver. As an example, a message sender might send messages during infrequent burst, while the receiver consumes messages continuously at its own pace. In this case, the message middleware acts like a buffer between the two peers.

A major difference between synchronous and asynchronous communication is the message acknowledge part. If a synchronous requests returns successfully, the client knows immediately that the server has executed the request. In messaging the sender does not know when the request is processed. Instead, it depends on the reliability characteristics of the messaging middleware.

Two popular asynchronous models are Publish and Subscribe (Pub/Sub) and Point-to-Point (PTP). In Pub/Sub, messages are broadcast from one publisher to several subscribers. In P2P, messages are rather sent from one sender to one particular receiver. Although the two models have similarities, they typically have a distinct set of applications.

Traditional MOM systems only support one of these models, and have also been proprietary, complex, and expensive, with a high degree of vendor lock-in. There has long been a need for standardization in the middleware space, and as Java has become a popular language for the middle tier, this was realized with the Java 2 Enterprise Edition (J2EE) platform.

The J2EE Platform

The J2EE platform provides standard system services and mechanisms such as:

• Transaction management
• Database access
• Security
• Host integration

These services are horizontal meaning that they are not targeted towards a particular industry. Any large scale distributed application has a need for such system service, regardless of whether it is a bank, insurance or telecommunication application.

The availability of common system services in the platform not only provides application developers with a standard framework for doing common tasks, it also reduces the need for writing low-level and error prone code. The J2EE platform consists of a suite of API's:

Enterprise Java Beans

Enterprise Java Beans (EJB) provide a component model for writing Java servers. The EJB model provides a framework of underlying system services such as:

• Transaction and resource management
• Database access
• Security

The EJB model also defines the interaction with various components in the system and supports processes within the EJB container. Because low-level functions are already implemented, developers can devote their time to developing business solutions.

EJBs can be deployed on a server along with other components to customize the capabilities of the business. Because EJB components are Java classes, they can run on any EJB-compliant server and interact with other Java API's. EJB defines three types of beans:

• Session beans
• Entity beans
• Message-driven beans

Session beans are associated with a single client and are typically not persistent. Entity beans are persistent and are often associated with database operations. The message-driven bean (MDB) is a new bean in the EJB 2.0 specification, which can asynchronously receive requests. MDB's are built using JMS.

Java Naming and Directory Interface

The Java Naming and Directory Interface (JNDI) provides naming and directory capabilities to Java applications. It support a hierarchical structure similar to a file system into which different kinds of objects can be stored, navigated and retrieved. Examples of such objects include EJB's, JDBC data sources, JMS destinations, etc.

JNDI is only an API and is typically backed by an existing naming service such as LDAP, NIS, or DNS. Also, JNDI can be used to used to interact with a CORBA CosNaming service. Java application developers can write code using the same JNDI API regardless of what naming service they are ultimately using.

Java Database Connectivity

Java Database Connectivity (JDBC) enables Java applications to access a wide range of relational databases. Databases store data efficiently, making it readily available to applications. They can also be administered to provide security and backup functionality.

The JDBC API shields application programmers from the details of managing network connections to a database. The commands for the database, which are written using the Simple Query Language (SQL) are embedded in the Java program, which make the program portable across different database vendors.

Java Message Service

The Java Message Service (JMS) provides a standard API for accessing messaging middleware systems from the Java programming language. JMS is an important API because provided a common model and vocabulary, which makes the learning curve for messaging systems less steep.

As mentioned above, JMS is also is an integral component of the J2EE model because it provides the foundation for message-driven beans. MDB's simplify messaging programming even further because the container takes care of connecting the bean to a JMS destination. The next two sections of this concepts guide provide a more in-depth description of JMS.

Transactions

The Java Transaction Service (JTS) and Java Transaction API (JTA) provides a standard way for Java applications to participate in distributed transactions. A distributed transaction groups several distinct operations into an atomic unit of work which support the ACID properties:

• Atomic - the work performed by all resources happen as one atomic unit of work.
• Consistency - a transaction moves data from one consistent state to another.
• Isolation - the changes in state during the transaction will not be visible outside the transaction.
• Durability - the effects of a transaction are persistent.

The ACID properties are enforced by driving a distributed transaction using the two-phase commit protocol (2PC). The 2PC protocol is driven by a piece of middleware called a resource coordinator (or transaction manager). The resource coordinator drives the two phases by executing the following actions:

1. First, all resources enlisted in the transaction are asked to prepare. If a resource is prepared it means that it is ready to go ahead and complete the transaction. If any resource can not prepare, the transaction aborts (rollback).
2. If the first phase succeeds and all resources are prepared, the second phase starts. In this phase all resources are asked to commit. The resource coordinator is responsible for calling commit on all resources until they succeed.

J2EE Connector Architecture

The J2EE (Connector) Architecture provides a standard framework for integrating existing Enterprise Information Systems (EIS) into the J2EE platform. This not only standardizes how Servlets and EJB access these systems, it also allows such systems to become web-enabled by leveraging the J2EE platform.

Using the connector architecture, EIS vendors provide resource adaptors for they systems, which can plug into, and be controlled by an application server. This allows security and transaction context to propagate properly, and application developers not longer have to write specific, low-level code for interacting with such resources.

Common Object Request Broker Architecture

The Common Object Request Broker Architecture (CORBA) is a complete programming environment for distributed and heterogeneous object systems, which includes an object model, wire protocol (IIOP), client and server programming language API's, and several standard system services, such as naming, security and transactions.

The J2EE platform supports CORBA by requiring that beans use the RMI/IIOP protocol for communicating with other beans. A standard wire protocol which describes how the transactional and security context flows from client to server ensures interoperability between beans residing inside containers provided by different vendors.

Java Server Pages

Java Server Pages (JSP) technology allows Java programmers to embed Java code directly into a web page. The Java code is embedded into the HTML files using special tags. As opposed to servlet technology, the JSP must be compiled on the client before it can be displayed.

JSP's are used to create a richer browsing experience by building more intelligence into web pages. As with all of the J2EE technologies, the key benefit is that the JSP is a Java application, which supports "Write Once, Run Anywhere^TM" allowing them to execute on any platform that supports the API.

The (Servlet) API provides application developers with a mechanism for extending the capabilities of a web server. A servlet is basically a Java program that executes the HTTP POST and GET commands issued by a client application. The most common client application is a browser.

Servlets are typically used to display context specific content on a web page. As an example, a servlet can customize the web page by fetching various information about the user from JDBC. As opposed to applets, servlets execute on the server and they do not have to be downloaded to the browser.

Web Services

Although Web Services are not yet formally part of the J2EE platform, several vendors are providing support for exposing EJB's and other objects as Web Services. A Web Service represents a piece of business functionality that can be accessed using standard Internet protocols. Web Services are defined using an XML document that describes the messages that the service accepts and generates.

The XML for a Web Service conforms to the WSDL standard. Because the interface of a Web Service is separate from its implementation, users and providers of Web Services can use any platform and programming language that is capable of producing and consuming the messages defined in the Web Service interface.

Web Services allow business applications to exchange information via ubiquitous Web protocols, including HTTP, SOAP, and MIME. Since the data format for exchanging messages is XML, true heterogeneous, Internet-wide business-to-business applications can be realized. In addition to SOAP and WSDL, Web Services are often associated with Internet registries such a UDDI or ebXML.