JMS + SOAP is seen as a solution for the framework needed to make Web services (SOAP calls) asynchronous. This is work for us.
A. How would this scale and port with JAXM in future?
B. Besides JAXM's acceptance/support/maturity in market at current time, is there something else wrong with JAXM vs. JMS?
C. What do we need to do to make them scalable (write our own abstraction at this time)?
A. JAXM and JMS complement each other nicely. E.g., a JMS provider could be used as the SOAP binding for transporting SOAP/JAXM messages. JAXM would be used as the API for creating rich SOAP (one-way) messages, with attachments etc.
B. I would not say there is anything "wrong" with JAXM. At the contrary: I think the API is well designed and will become popular among Web services developers. But its important to understand the particular strengths and limitations of the two technologies (JAXM and JMS).
JAXM has more "expressive power" in allowing developers to create structured XML messages, even containing attachments if you want. However, the JAXM standard does not require a JAXM provider to implement reliability, store-forward, transactions, acknowledgements etc.
But those are features which enterprise applications often provide, and such delivery guarantees are provided by a JMS provider. JMS' strength thus lies in ensuring guaranteed, reliable communication between application endpoints. In short, Using JAXM's expressive power atop a reliable JMS transport is a good idea. But the cost of that is that you lose vendor neutrality because JAXM-over-JMS requires application endpoint to link in the same JMS provide library.
However, there are other architectures to combine JMS and Web services. E.g., by using a JMS-SOAP Gateway instead of a SOAP-JMS binding, you can gain back vendor neutrality to a certain extent. Check out the following whitepaper for an explanation:
C. Scalability will come mainly from a well-designed JMS provider, offering load-sharing, fault-tolerance, and multicast communication. The JAXM layer must be optimized in respect to serializing and deserializing application data to and from XML.
Dig Deeper on Topics Archive
Have a question for an expert?
Please add a title for your question
Get answers from a TechTarget expert on whatever's puzzling you.