Main Page

Previous Section Next Section


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 (

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.

Previous Section Next Section

JavaScript Editor Java Tutorials Free JavaScript Editor