I was reading where some people were wanting to use JMS as a vehicle for asynchronous web service communication. This made me go back and re-read the spec. It was as I thought, JMS is a predefined API, but leaves the wire protocol up to the vendor. Thus, the app dev person should be able to swap out JMS providers (vendors), but in all likelyhood, no two vendors calls will work with each other - thus, it isn't an option for B2B reliable messaging (nor was it intended).
APP 1 --> JMS API -->
[[Proprietary wire protocol]] -->
[[Server]] -->
[[Proprietary wire protocol]] -->
JMS API --> App 2
Nigel Thomas reminds us, "JMS implementations from different vendors are not required to interoperate - details of wire format and transport protocol are left to the provider's discretion. So JMS usage is limited to 'single provider' situations - where the developer controls both producers and consumers.
JAXM is designed to support inter-business messaging. Based on Simple Object Access Protocol (SOAP) 1.1 with Attachments, message formats, payloads and transport are standardized so that the other business will be able to receive and understand them. Unlike JMS, JAXM only supports the point-to-point messaging domain - not least because B2B messaging is usually one to one. The high performance, low latency and programmatic flexibility of JMS are traded for simplicity, reliability and interoperability. "
Hmm... better go back and read the JAXM spec. From what I remember it was a rather wordy API that didn't actually spell out a SOAP binding.
No comments:
Post a Comment