XML Authors: Arron Fu, Jayaram Krishnaswamy, Jason Bloomberg, Asim Saddal, Greg Schulz

Related Topics: XML

XML: Article

When Should Java And XML Be Used For Messaging?

When Should Java And XML Be Used For Messaging?

When does it make sense to use JMS (Java Message Service) and XML to support a heterogeneous messaging environment? Most buzzword-compliant people talk about JMS and XML when thinking about developing a messaging solution for their organization.

While in most cases this is the correct answer, we need to understand the requirements we're trying to fulfill before giving an answer. For example:

  • Can the solution be deployed using asynchronous communications or does it require synchronous behavior?
  • Will the solution be used in the intranet or extranet?
  • What are the messaging paradigms supported by your system?
  • Does the underlying messaging system support JMS?
  • What qualities of service (QoS) are supported by the messaging system?
  • What are the characteristics of the information to be published on the network?
  • Are e-mail messages a requirement?
  • What are the possible messaging systems the solution will be deploying against?
In short, we need to understand the characteristics of the problem before we can justify the use of any technology - in this case JMS and XML. Let me first give a brief introduction to JMS and explain the role of XML. My goal this month is to help you understand the requirements that XML and JMS are attempting to meet.

Sun, IBM, Modulus, NEON, OpenHorizon, Oracle, TIBCO, and Vitria developed the JMS specification. The purpose was to define a common API that would enable Java developers to use the same messaging system. In the JMS specification there's a clear distinction between the application and the message provider layers. The software developer is responsible for coding his or her application against the JMS interfaces; the message provider is responsible for coding the implementation to the interfaces. The idea behind this approach is to decouple the client application from the specifics of the messaging system. This allows the message provider layer to plug into the application layer. JMS defines two types of messaging paradigms:

  • Point-to-point
  • Publish/subscribe
The point-to-point paradigm follows a producer/consumer pattern that allows the producer application to write information to a queue and a consumer application to read it from the queue (see Figure 1). The queue mechanism identifies the decoupling point between the producer application and the consumer application. The producer application doesn't depend on the consumer application to access the queue to write to it, or vice versa. Some messaging systems provide QoS that enables persistence of the information stored inside a queue.

The publish/subscribe paradigm follows an observer pattern with explicit interest defined (see Figure 2). This approach allows subscriber applications to specify the types of events they're interested in receiving and allows the publishing application to broadcast messages independent of interested parties. The mapping between interested subscribers and published content is facilitated by the messaging system. This allows subscribers to publish information totally independent of recipients and vice versa. Some messaging systems provide QoS that enables the persistence of published messages for future processing.

JMS developers are responsible for selecting the message provider and for specifying the type of messaging model they want to implement. In addition, some JMS services are supported by the JMS layer independent of the underlying messaging implementation. These are:

  • Transactions
  • Message filtering
These need to be supported by the JMS provider implementation layer, however.

Most messaging systems, including the JMS specification, are agnostic when it comes to message content. They categorize message content as:

  • Basic types (int, float, char, long, etc.)
  • Text (string)
  • Bytes (byte arrays)
This is where XML comes to the rescue by providing the mechanisms to define the content of a message. This information is used by both sender and receiver clients to manipulate complex objects. The XML tags allow the sender application to serialize an object for future consumption by the receiver application. It's the responsibility of the receiver application to reconstruct the object for further manipulation.

Another advantage of using XML for defining the content of a message is that it provides a platform-independent mechanism for exchanging information between heterogeneous applications. This means a Visual Basic application can package an object using XML and send it to a Java application where it can be reconstructed from the XML message.

It's important to realize that XML doesn't provide a communications transport like TIBCO, MQSeries, IIOP, SMTP, and HTTP. However, it can work with any of these transports to provide message- content abstraction. One example of how XML facilitates the creation of communication transport is the use of HTTP and XML to develop XML RPCs.

Does this mean that the buzzword-compliant people know best? I don't think so! However, they pay enough attention to know what the technologists are saying. As mentioned earlier, JMS provides a communication abstraction layer for messaging while XML provides a message content abstraction layer. JMS enables the use of XML via its TextMessage content type. This enables string-based messages and XML text (see Listing 1).

When JMS and XML?
JMS and XML provide a total abstraction of communications transport and data content. Given this statement, why should you care about any requirements? Isn't this the solution to all your messaging needs? Let's revisit the questions asked earlier:

Q: Can the solution be deployed using asynchronous communications or does it require synchronous behavior?
A: JMS deals with asynchronous communications. If you need to manipulate synchronous flows like RMI, CORBA, or HTTP, you may want to consider using synchronous protocols. While you can implement synchronous behavior with asynchronous protocols, this isn't the norm and it's more difficult.

Q: Will this solution be used in the intranet or extranet?
A: JMS deals with messaging in thje intranet. Publish/subscribe and queue management systems aren't designed to deal with unreliable networks like the Internet. If you want to set up extranet communications, you need to consider XML RPC (SOAP) or SMTP (e-mail).

Q: What are the messaging paradigms supported by your system?
A: Does the underlying system support publish/subscribe or point-to-point? Some systems support only one or the other. Publish/subscribe systems have been optimized for broadcast (e,g., TIBCO). They haven't been optimized for point-to-point. Similarly, queue management systems have been optimized to provide message persistence via queues and point-to-point communications. They haven't been optimized for publish/subscribe.

Q: Does the underlying messaging system support JMS?
A: If your corporate messaging system doesn't support JMS, you may be stuck with their proprietary Java interfaces or you may need to develop your own JNI interfaces.

Q: What QoS are supported by the messaging system?
A: Does the JMS implementation that comes with your messaging system support guaranteed delivery, transactions, and message filtering? If your application requires transactions and your JMS implementation doesn't support them, this may be a problem. You may be forced to evaluate a different JMS provider. If your JMS provider supports message persistence, where is the persistence storage happening, in an RDBMS or proprietary storage? Persistence may be an issue if your JMS provider requires you to purchase a specific RDBMS.

Q: What are the characteristics of the information to be published on the network?
A: If you're using publish/subscribe, what type of information are you publishing? This issue is particularly important if you're using publishing as an event mechanism. Events are normally regarded as lightweight messages. Because of this requirement, it may not make sense to inquire about the overhead of wrapping a simple event value in an XML message. The subscribers may be listening on a topic called shipping orders, and the only content inside the event may be the order number. In this situation there's no need to create an XML message to publish the information. However, if subscribers are listening for the complete order with all of its parameters, it makes sense to package the order object inside an XML message for further processing by the subscriber application.

Q: Are e-mail messages a requirement?
A: JMS doesn't handle e-mail sending or receiving. That's the purpose of the JavaMail APIs. If the application needs to support e-mail for asynchronous messaging, then JMS isn't the answer. However, if your application needs to use an intranet-based messaging system like TIBCO, and you want to implement an e-mail gateway, the combination of JMS and JavaMail is ideal.

Q: What are the possible messaging systems that the solution will be deployed against?
A: If the solution being developed will be used only against one messaging system, it may not make sense to use JMS. This is the case if there's no JMS provider for a particular messaging framework but there is a Java API for that system. However, if the solution can be deployed against multiple messaging systems, it makes sense to leverage a communications abstraction layer.

JMS and XML are an ideal combination and can be deployed to provide a total abstraction solution for messaging and data content. However, you need to understand your requirements clearly before making the technology call. Therefore, it's important to know the limitations and correct usage of the JMS and XML technologies.

More Stories By Israel Hilerio

Israel Hilerio is a program manager at Microsoft in the Windows Workflow Foundation team. He has 15+ years of development experience doing business applications and has a PhD in Computer Science.

Comments (0)

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.