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