RE: [ebxml-msg] Groups - SOAP-1.2

Jacques and I have been reconsidering the SOAP 1.2 option
for ebMS-3. We would like to suggest adding support for SOAP 1.2 in ebMS-3 Core
Specification, in addition to SOAP 1.1. Some of the reasons for this are
the following:

 

 
Many implementers of SOAP
     related technologies have support for SOAP 1.2, and it is expected that
     over time several vendors will prefer to develop with SOAP 1.2. Several
     environments already support 1.2 (Axis 1.2, Sun’s JWSDP) Assuming
     1.2 will prevail in the long run, ebMS-3 should factor in this option -
     which really has no significant impact on its design, and not appear as
     tied to old standards. Even if SOAP 1.2 does not bring much from a
     functional aspect, the perception should not be that there is divergence. 

 

 
With an interoperability
     approach for ebMS that is pre-conditioned by adhesion to “conformance
     profiles” (in the W3C sense), as defined in current conformance
     proposal, adding the SOAP 1.2 option is handled by a new conformance
     profile(s). It becomes an “interoperability parameter” like
     the transport or the reliability standard being used. Although we
     don’t want to multiply such profiles, 1.2 is worth an additional
     conformance profile. SOAP 1.2 should be a core
     feature and not just included in the “Advanced” second part of
     ebMS-3 spec. 

 

 
WS-R* and WSS specs –
     like most WS-* – all support both 1.1 and 1.2. As for
     attachments, although there is no specification for SWA 1.2, this did not
     stop several SOAP 1.2 stacks to support them by extrapolating directly
     from SWA 1.1, which is straightforward. An Appendix could simply endorse
     what these vendors did. Also note that attachments are not as essential
     for business payloads in ebMS-3 as they were in ebMS2. 

 

 
Adding support for SOAP 1.2 is
     a small effort in our current draft. The example listings don’t have
     to include a version for SOAP 1.2. It suffices to include a statement
     similar to the following before the “Examples” section: the
     listed examples are for SOAP 1.1, but if using SOAP 1.2 please correct the
     SOAP headers accordingly. As far as the ebMS headers, nothing is dependent
     on the version of SOAP being used, except for the actor attribute which
     need to be called “role” when using SOAP 1.2. 

 

 
In terms of implementation,
     all SOAP parsers have now support for SOAP 1.2. SOAP processors usually
     deal with a program object called “SOAP Message”. This object
     is independent of the version of SOAP being used. At the web server side,
     before a SOAP processor can start working on a SOAP Message, the network
     data stream received by the web server is first transformed to a
     programmatic object (called SOAP Message), and the library doing this task
     understands both streams of data (data stream for SOAP 1.1 and data stream
     for SOAP 1.2). The result object (the SOAP Message object) has the same
     API and is identical for both versions of SOAP.