How does XML over HTTP compare with XML using JMS,...
1 posts in topic
Flat View  Flat View
TOPIC ACTIONS:
 

Posted By:   Sowmya_Karmali
Posted On:   Monday, February 26, 2001 09:53 PM

How does XML over HTTP compare with XML using JMS, with regard to transactional integrity (HTTP being stateless), security, etc?

Re: How does XML over HTTP compare with XML using JMS,...

Posted By:   Doug_Erickson  
Posted On:   Friday, March 30, 2001 11:53 PM

If you don't need reliable messaging, use XML over HTTP.
Otherwise, evaluate your time, money, and need for
compatibility. If you have more time than money, or require
compatibility, roll your own implementation of a standard like
RosettaNet or ebXML. If time is money and you
own both ends of the queue, XML over JMS is a quick, easy,
and robust solution.



Some of the advantages of XML/HTTP are that it is simple
to implement, widely compatible, and has less performance
overhead.



However, there are some disadvantages that begin to show
up when you try to get reliable messaging out of XML/HTTP.
HTTP doesn't provide headers that you'd need, such as
message ID to provide once-only delivery. You either have to
munge the message-layer metadata into the payload, or
devise a message envelope (MIME-based wrappers are
common) to carry this information.



Another problem that crops up with a servlet-based
"message consumers" is that the consumer can't be sure a
message has been acknowledged successfully. Here again,
there are at least two options. You can track the last
acknowledged message ID, so that if it's redelivered you'll be
able to tell. Or, you can perform acknowledgments by
opening a connection back to the message sender. This way,
if acknowledgment fails, your application sees the exception
rather than it being caught by the servlet engine. The
latter approach is used by RosettaNet and the (obsoleted)
ebXML draft.



Well, by the time you cover all these bases, as well as
building a persistence layer for your messages, you've made
a big investment in XML/HTTP. JMS begins to look very
attractive at this point. The JMS provider hides all of the
low-level muck behind a very simple API. Thus, the key
advantage of JMS is off-the-shelf reliability.



The main disadvantage of JMS is the loss of compatibility.
Typically, JMS providers use a proprietary protocol between
producer and consumer. To communicate, you (and your
partners) need (to buy) that provider's software at both ends
of the queue. As a uniform API, JMS allows you to toss one
provider and plug in another, but if you want to mix
providers, you need to make or buy some sort of bridge.

About | Sitemap | Contact