OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-msg message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: 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:


  1. 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.


  1. 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.


  1. 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.


  1. 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.


  1. 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.


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]