RE: [ebxml-dev] Same document payloads and the WS-I Basic Profile

["Dale Moberg" <dmoberg@cyclonecommerce.com>]

 Fraser Goffin writes: [ snip ]

"I believed (perhaps wrongly) that whereas the ebXML MS spec does
recommend use of the SwA/MIME packaging mechanism described it does not
mandate it ??"

DaleMoberg> I believe that ebXML Messaging 2.1 and beyond should not
mandate SWA packaging, and can allow simple SOAP envelope with a
non-empty body. Several use cases and "requirements" originally argued
for SWA (such as allowing transfer of xml PIs without encoding or,more
generally, avoiding lots of encodings forced by use of XML to envelope
data). HTTP had given us a binary clean transport, but XML enveloping
basically forced all the old hacks used in email right back on us, which
a lot of us disliked. But, we oversimplified and presumed using SWA
generally. As you point out, some tools provided by some vendors are not
geared to do much beyond simple SOAP:env structure transport. At this
point it seems desirable to allow use of the SOAP body as long as people
are willing to put up with its limitations and side-effects. That is
just my view, however. 

Maybe ebXML Messaging can reach consensus after raising this as an
issue, so this message is cross-posted to the messaging group. Most of
us in that group are technology pragmatists, and as Dick Brooks
mentioned, we are more interested in making certain that certain
business level security and acknowledgment requirements are met by the
spec, than in what the current technology fashion aesthetics prescribe.
But we know that we will need to adapt to changing fashions...


[another snip]
In any event, our approach unfortunately appears to have slightly 'back
fired'. I noted recently that the WS-I Basic Profile explicitly
disallows a document/literal message to include more than one part
within the SOAP Body binding (recommendation R2201). Thus the snippets
below I think would be invalid (ebXML namespaces omitted for bevity).

DaleMoberg> WS-I Basic Profile 1.0 is another wrinkle. Are the tools
unable to do anything beyond WS-I or are they just configured to operate
in a WS-I conformant mode by default? Anyway, the 1.0 specification did
not deal with several aspects of SOAP messaging (intermediaries, SWA,
etc) and perhaps you should stay tuned for another WS-I Basic Profile,
version 1.1 that may give you some relief. But, if push comes to shove,
you may need to wrapper your children up inside another element that
satisfies the one-child of SOAP body restriction. [I did mention that I
was a pragmatist, not an aesthetician, right?] WS-I really stripped out
a lot of stuff in WSDL and SOAP that SOAPbuilders and others found to be
sources of interop problems. Rather than fix some of the functionality
so it would be interoperable, they often chose to omit the functionality
to just avoid the complexity of the fix.