Summary

Pieces in the JAXM puzzle are still missing. For example, JAXM does not place any requirements on message security. En route encryption of message content is considered a provider implementation detail (e.g., HTTPs, PGP, or S/MIME). JAXM also has no requirements for authentication of clients to the JAXM providers.

Nor does JAXM specify the means to describe a JAXM service. WSDL does not suffice for messaging, because it cannot conveniently describe messaging conversations (as, for example, the ebXML CPP/CPA can). Nor does JAXM define any data types or relation to the data types defined by JAX-RPC.

JAXM is the Java community's first kick at the can for XML messaging. Like any new specification, it will evolve and must gain vendor acceptance. There is a belief in the community that JMS should have been extended to handle XML/SOAP payloads for asynchronous messaging instead of developing a new API such as JAXM (www.jcp.org/jsr/results/67-15-1.jsp).

However, with the move to service-oriented architecture, architects are striving to reach the outer edges of their enterprise boundaries. Simple interfaces such as JAXM provide a convenient mechanism for exchanging information with business partners. We believe JAXM is not just another event service and that in combination with messaging profiles such as ebXML, it gives a viable, provider-centric abstraction—where developers must work with and worry about the client and service and allow the vendor's provider software to do the legwork. We believe JAXM is a solution that businesses and architects can rely on for building XML/SOAP-based asynchronous messaging applications.