JMS, XML, and heterogeneous enterprise

Today, most computing environments are made up of different platforms rather than sticking to any platform. The Java Messaging Service (JMS), together with Extensible Markup Language (XML), satisfies the desire for this heterogeneous environment integration. This article demonstrates how to use JMS to create xml-based messages and distribute them equally to Java and non-Java applications.

After several years of building, expanding, and maintaining a huge distributed application, programmers gradually realize the benefits of platform-independent behavior and platform-independent data.

The Java programming language has taken a step forward in the need to meet platform-independent behavior (although scripting languages such as TCL have been concerned for some time or longer). and XML (Extensible Markup Language) is becoming the backbone of open, platform-independent data solutions.

This article demonstrates the desire of XML to meet platform-independent data in a situation that is used with Java messaging Services (JMS).

Message delivery ties them together

JMS defines a common Java language interface for messaging services. It supports the most common messaging models, including publish/subscribe and point-to-point.

First of all, it seems strange to put platform-independent data and Java technology in a paragraph of text. However, since JMS is a java-based (and therefore platform-independent) technology, why do we need platform-independent data when using JMS?

The answer comes from an environment where messaging is often used. One of the greatest benefits of messaging is in the area of application integration. Most of the applications that are integrated are not all Java applications.

In this case, JMS is ideal because it is an interface specification-not an implementation. This means that JMS is located on the top level of existing technologies that already have considerable application. (Of course, all Java implementations can also take advantage of this JMS and XML solution.) ）

Figure 1. JMS at the top of the proprietary messaging service

Figure 1 illustrates such an environment. Non-Java applications communicate directly with the private messaging service. Java applications communicate through JMS. Everything is seamless, right?

But not exactly. Data is still a problem that needs to be addressed.

Platform-independent data solves the problem

Consider the five types of messages that you have in JMS. JMS provides three structured or semi-structured message types (Mapmessage, objectmessage, and Streammessage) and two unstructured or free-form message types (TextMessage and bytesmessage).

The structured message format represents only a handful of the many methods of processing structured data (only the mapping table, the serialized object, and the data element stream are directly represented). More importantly, they raise issues that interoperate with non-Java applications. Transformations or mappings, especially in the case of transformations involving serialized classes?

Unstructured message formats seem to be better able to interoperate, but only because they rarely use structs on messages. This small convenience, however, adds to the burden of grammatical analysis and validation for each recipient.

XML eases this burden. It provides a clear, standardized approach to rich functional data structures and supports it with an increasing number of tools used to perform parsing and validation of these laborious tasks.

By using XML in the link, everything is seamless.