General Java

XML has become the standard format for B2B data exchange. To actually implement such exchanges, however, the programmer must provide data transport and translation services. Java-based messaging provides an ideal transport for XML. This article explores how to use a Java messaging server as the infrastructure for exchanging XML data between B2B participants.

XML itself doesn't specify a communications infrastructure. Employing RPC (remote procedure call) mechanisms to exchange XML data via HTTP - an approach advocated by some - suffices for rudimentary applications but doesn't scale for distributed applications across multiple systems, such as in business-to-business e-commerce. In such systems parties are often unreachable, yet reliability of communications is crucial.

Take the relatively simple example of communicating price changes. To ensure that each disconnected party eventually receives the data, persistence and verification must be in place. RPC mechanisms don't provide persistence and verification, so the programmer must build these services into the application logic - no easy task! The burden becomes greater when the requirement is to communicate a message such as a bid request either to all parties or none. The programmer would have to provide rollback mechanisms similar to those found in database transactions.

JavaSoft's Java Message Service (JMS) specification offers a way to meet these needs. JMS comprises an API and semantics for a middleware messaging service that helps insulate the application from the issues posed by loosely coupled systems by providing services such as persistence, verification and transaction support.

Messaging middleware also improves the flexibility of e-commerce systems. Consider the example of a wireless phone company's marketing department communicating new rate plans to its franchised dealers every month. JMS-based messaging allows the company to provide value beyond simply publishing new rate plan information reliably and on a timely basis. By using a messaging middleware system, the company can decouple use of the rate plan data from the initial application that broadcasts it. Other departments in the company can use the data to create reports or communicate the data to third parties, such as regulatory agencies, with no need to modify the original application.

JMS provides mechanisms to implement virtually any form of e-commerce transaction. In this article I'll use the example of a B2B portal to illustrate how these mechanisms can be applied. The B2B portal will act as the hub of an online trading community, connecting buyers and sellers. The buyers broadcast their interest in obtaining goods and services to the community at large, and sellers selectively bid on these opportunities.

JMS Implementations
Programmers may elect to build their own Java messaging middleware from the JMS specification or obtain this functionality from a third party. Commercial JMS implementations are provided as stand-alone messaging servers or as JMS services embedded within other environments such as application servers.

A stand-alone server provides some advantages over an embedded messaging service by allowing the developer to:

• Place messaging broker(s) where needed to optimize network topology, control traffic loads, provide fail-safe operation and/or leverage existing hardware.
• Embed the messaging server infrastructure within a value-added application or operating platform.
• Be assured that enhancements of, and extensions to, the messaging server aren't tied to those of the environment in which the messaging server is embedded.
• Choose, if used with an application server, which app server(s) to pair with the messaging server.

On the other hand, having the messaging service built into another environment offers the convenience of a single (if less flexible) solution, especially for organizations that have standardized on an application server and anticipate that their needs will not change.

Persistence
Perhaps the greatest benefit of a fully featured JMS implementation is resilience, often referred to as "persistent" or "guaranteed" messaging. Typically this means:

• A sender specifies that a message persists within a broker-managed data store until all subscribed recipients receive it.
• Subscriptions are durable, meaning a client will automatically receive messages sent to the subscribed topics whenever the client attaches to the message broker, including any persistent messages sent when the client was disconnected.

It's important to note that the JMS specification doesn't prescribe how persistence should be implemented. Those specifying or building a JMS system should ensure that: (1) they know how the concepts of persistent and guaranteed messaging are defined in the context of the system that they're considering; and (2) they know how these concepts will be implemented so that their promise is met.

Advanced Functionality
The JMS spec leaves it to the vendor or programmer providing a JMS implementation to add additional functionality necessary for large-scale applications such as:

• Support for XML-formatted messages
• Hierarchical name spaces
• Clustered brokers
• Graphical administration tools
• Extensions to other environments, such as ActiveX

JMS and XML
In JMS an XML transaction is contained in the body of a message. This message is then broadcast to a number of potential recipients or sent to one recipient in particular. The actual transmission of the message is typically performed over TCP/IP or HTTP, although the JMS implementation shields the application code from the specifics of the wire protocol.

Routing of the message is based on fields in the message header and the manner in which recipients are subscribed to the messaging system. Recipients control which messages they receive by subscribing to specific message topics (described below). Additionally, recipients can request that the messaging system filter messages on their behalf by specifying filter criteria in a SQL-like syntax. For example, a supplier in our online trading community could register an interest in bid requests with a delivery time of 10 days or more by specifying a selector of "Property_DeliveryTime >= 10".

An XML application can use this mechanism to provide content-based routing by programmatically placing appropriate XML data within the message properties. The JMS spec currently doesn't allow the messaging system direct access to the message body, which would be required for XML content-based routing without application intervention.

How JMS Works
The JMS specification describes a JMS provider that implements the APIs and semantics. The most common implementation model for a JMS provider is a Java messaging broker, either a single broker or - in some implementations - multiple brokers. The broker is the heart of the messaging service, routing all messages through its hub (see Figure 1).

Multiple brokers - for those JMS implementations that offer this feature - may be clustered, facilitating scalability and offering a higher level of fault tolerance. Clustered brokers also allow for centralized maintenance of security functions.

The JMS spec calls for two types of messaging:

• Publish/subscribe (or "pub/sub"), a one-to-many model where a client application publishes messages to topics subscribed to by other clients
• Point-to-point, where a client sends messages to a queue from which one or more clients obtain messages sequentially

The programming model for JMS-based applications using these two models is virtually identical. In fact, many JMS-based applications use a mix of the two models. Both pub/sub and point-to-point use the same format of JMS message. There are three sections in a JMS message:

1. Header fields
2. Properties, used for message filtering and routing
3. Body, the application-specific portion of the message

While the logical routing of pub/sub messages is quite different from that of point-to-point, both models share a hub-and-spoke architecture between clients and the provider. Clients access the provider through the JMS API. Clients call a messaging client runtime library that implements the JMS interface and communicates with the broker.

To begin messaging, a client opens a connection to the message broker. The client locates a broker through JNDI and establishes a connection through a ConnectionFactory. Within the context of a connection, the client establishes one or more sessions. The process of sending and receiving messages is performed via the session, which holds the transactional and acknowledgment characteristics for messages to be sent or received. It's more efficient to employ multiple sessions per connection than multiple connections per broker. Connections require more resources to establish and maintain than sessions and can easily be reused for communication through different topics or queues.

JMS supports acknowledgment for both sessions and clients. Like handshaking in a low-level communications protocol, acknowledgment informs the message broker when a client has received a message. JMS also provides a ReplyTo mechanism. A message publisher can use ReplyTo to indicate where a receiver of the message should send replies. Unlike acknowledgments, replies are sent as full JMS messages.

JMS also supports transactions. When a session is transacted, the message broker stages the message traffic until the client application either commits or rolls back the transaction. When a rollback is performed in a session that is both a producer and a consumer, its produced messages are destroyed and its consumed messages are re-sent.

Publish and Subscribe
The pub/sub paradigm promotes the independence of producers and consumers from one another and allows for one-to-many and many-to-many configurations.

In pub/sub, each session object publishes and/or subscribes to one or more topics. An authorized publisher produces messages through a specified topic, and authorized subscribers receive messages by subscribing to that topic. Topics may be static or dynamic objects and can be temporary for transitory or anonymous uses.

Some JMS implementations allow topics to be defined in a hierarchical structure so that topics can have associated subtopics. Clients can subscribe to the appropriate topic level to receive the most relevant information. This technique provides a more granular approach to topic subscriptions, substantially reducing the amount of coding needed to filter unwanted messages while supporting highly flexible subject-based routing and security.

In our online trading community example, each buyer publishes messages to a bid_request topic, using the pub/sub model (see Figure 2).

The buyer uses the pub/sub model, as each buyer wants to inform all interested sellers of the bid request. In a large community that serves a colorful array of buyers and sellers, we may want to break the bid_request topic into several subtopics, with one subtopic for each category of product or service. These subtopics could further be divided into more granular categories. For example, a given topic hierarchy might be bid_request.vehicles.bicycles.

Each seller subscribes to the bid_request topics that it's interested in. Further, the seller can request that the portal forward only those bid requests that adhere to specified criteria. For example, a seller could subscribe to the bid_request.vehicles.bicycles topic, but indicate that it wants to receive bid requests only for mountain bikes or only when the buyer doesn't require overnight shipment. These filters would be created using the message selector mechanism discussed earlier:

"Property_MerchType = Mountain Bike' AND Property_ReqOvernight is NULL".

Quality of Service
In publishing a message, the publishing application specifies the quality of service - e.g., delivery mode, time-to-live, priority - and whether the subscriber requests a reply.

The delivery mode can be persistent, where the message is placed in a data store as part of the send operation for a "once-and-only-once" guarantee in which the message must not be delivered more than once and must not be lost.

The time-to-live parameter specifies how long the message broker should retain the message to ensure that all subscribers receive it. If the time-to-live is specified as zero, the message won't expire.

More efficient is the nonpersistent delivery mode, in which the provider delivers the message with an "at-most-once" guarantee. The message won't be delivered more than once but isn't protected against loss.

A durable subscription indicates that the client wants to receive all the messages published to a topic even if the client connection isn't active. The broker ensures that all messages published to the topic are retained until the durable subscriber acknowledges them or the messages have expired. For example, a seller in our trading community could go offline for an extended period and still receive bid requests that were broadcast during that time.

Point-to-Point
In point-to-point (PTP) each session object sends and/or receives through one or more queues. Consumers can either receive the message that's first in line - thus removing it from the queue - or browse through all the messages in the queue, causing no changes.

The first message received by the broker is the first message delivered to a consumer. This requires that the broker retain the second and subsequent messages until the first is consumed. Even when no clients are associated with a queue, messages are retained. Durability and persistence are implicit in PTP, unlike in pub/sub. There's only one message consumer for a given message. When each message is acknowledged as delivered, the broker discards it.

Let's refer again to our fictitious trading community to explore using a point-to-point queue. Each buyer in the community creates a queue for receiving bids from interested sellers. We use a point-to-point queue here because in each case only one party needs to receive the bid messages. The buyer can point to this queue from within its bid request messages, using the ReplyTo mechanism discussed earlier, making it easy for interested sellers to submit bids. The system can be made anonymous, that is, bidders don't even know the identity of the requestors until the end of the bidding process (see Figure 3).

Summary
We've examined the key capabilities and concepts of JMS, and looked at an e-commerce scenario that uses the two JMS messaging models: pub/sub and point-to-point. XML applications built using JMS are afforded a great deal of flexibility in how they send and receive messages, as well as how messages are routed within the system. Although JMS doesn't yet support content-based routing directly from XML tags, an application programmer can easily add this functionality by mapping XML tags to JMS message properties.

XML can greatly benefit from a transport that supports the loosely coupled, dynamic environments inherent in the large-scale heterogeneous systems used for B2B e-commerce. JMS provides such a transport and offers the required persistence, verification and transactional capabilities required in a highly flexible programming model. Those considering a JMS solution should look for functionality beyond the basic JMS spec that's necessary for deploying and managing a scalable system.