BOSTON (05/08/2000) - XML has the flexibility and power to enable e-business applications to interoperate in new ways. As a result, the e-business world will likely move toward a standards-based XML data interchange using HTTP protocols over the Internet.
But many questions need to be answered in order to achieve large-scale, secure, reliable, cross-company deployments over the Internet. What happens when the system at the other end of the wire is not available? What happens when the network is down between systems? How does Company A grant access to Company B in such a way that only certain pieces of information are accessible?
Java Message Service (JMS) is a specification published by JavaSoft that details how applications, or parts of an application, communicate in a loosely coupled, mostly asynchronous environment. The specification prescribes the semantics of message delivery, as well as specifying the APIs for tying a message service into an application.
There are required and optional features in JMS. The good implementations go beyond what the specification dictates and add capabilities such as security through authentication and encryption, scalability through load balancing and server clustering, firewall traversal via HTTP tunneling, and ease of administration through a graphical user interface.
Although not required, typically a JMS implementation will make use of a hub-and-spoke architecture. In a simple case, this means there is a centralized message server and all clients connect to it.
The hub-and-spoke architecture lends itself to fewer network connections while still letting any part of the system communicate with any other part. It also fits in well with the publish-and-subscribe (pub/sub) model provided by JMS.
A pub/sub messaging model allows for application components to send and receive XML documents (messages) based on topic subscriptions that are managed administratively. A JMS client will "publish" a message on a topic, and there may be one or more "subscribers" interested in receiving that message. Because these pub/sub topics are controlled administratively and not hard-coded into the application, a system administrator can dynamically add subscribers to specific topics as needed.
For example, in a deployed environment you may want to dynamically add an audit-trail component that subscribes to a number of topics and stores them in a database. A good JMS system might provide a hierarchical name space for topics such as ACME. sales.anvils and ACME.sales.magnets. A really good JMS system might provide means to subscribe to topics using wildcards such as "ACME.sales.*" or "#.anvils".
The pub/sub model also includes the concept of a durable subscription. In the dynamic environment of the Internet, receiving clients might shut down, recipient applications might crash or the network connection might become broken. With durable subscriptions, receiving clients may register their interest in a set of topics and the message server will "persist" messages for later delivery to the intended recipient.
The other messaging model in JMS, point-to-point, is different in that you have a more definite knowledge of a known end point. Clients send and receive messages both synchronously and asynchronously on known queues that are located by name.
With either model, the key benefit is identical: If the intended recipient is not available, the messages will be reliably stored and delivered when it does become available.
In today's e-business scenarios, XML through a JMS system can be used to represent stages in a business flow such as purchase order processing. It can also be used as a means for tying together disparate applications including legacy systems, packaged applications or a foreign system that resides within the four walls of a trading partner.
Each stage in a process is a JMS client, which only needs to know that it subscribes to a given topic, then republishes to a new topic. This gives you the freedom to administratively control what pieces are in your business process and where and how the load gets distributed across machines on your network.
Chappell is director of engineering at Progress Software. He can be reached at firstname.lastname@example.org.