Win a copy of Kotlin in Action this week in the Kotlin forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic

JAXM Provider ?  RSS feed

 
Peter Chang
Greenhorn
Posts: 18
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi All,
A question regarding asynchronous Web Service.
Can some one please tell me the difference between "JAXM Providers" and other standard Messaging Middewares (Providers) like IBM's MQ etc ?
Thanks in Advance,
Rupesh
 
Richard Monson-Haefel
author
Ranch Hand
Posts: 92
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
JAXM is specific to SOAP-based communications. Other messaging systems like MQ Series use their own proprietary protocols, which are not interoperable. SOAP, if used according to the WS-I Basic Profile 1.0 guidelines, is vendor agnostic and interoperable. What does this mean? Well, if you choose MQ Series as your messaging backbone, then you are pretty much stuck with that product. The alternative is to use protocol-gateways that translate MQ Series messages into something other vendor's standard, or vice versa.
So now I'll explain why, IMO, you don't want to use JAXM. First, JAXM is not endorsed by the largest J2EE vendors (i.e. IBM and BEA). Now if you don't care about what the big vendors support then consider this: JAXM is not, nor will it ever be, a part of the J2EE standard. So if you don't care about vendor support, and you don't care about standards, and you can find a decent implementation of JAXM, then go for it. Personally, I wouldn't waste another nanosecond on JAXM - I did waste a couple months working with a while back - I whish I could get that time back. JAXM is, IMO, dead.
If you want to use SOAP-based messaging in J2EE, than I would strongly suggest that you use JAX-RPC which provides support for asynchronous messaging. But really, it depends on your architecture - maybe you don't want to use SOAP at all.
One reason to use something like MQ Series, or SonicMQ, or whatever is that they offer qualities of service and performance that SOAP-based async messaging just can't match. Transactions, security, guaranteed messaging these are the QoS of message-oriented-middleware (MOM). SOAP-based async messaging doesn't offer those QoS, but it does offer interoperability, something that MOMs don't do very well. I hope that helps.
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!