Re: Rewrite of SOAP 1.2 Adjuncts

David Hull writes:

> As far as I can tell, what we have, or at least what we want to have if 
we take this approach is SOAP-independent request-response.

I don't see it that way.  First of all, there is a political issue:  this 
specification is proposed for a version of the SOAP 1.2 Recommendation, 
for use in the context of SOAP implementations.  The conformance rules are 
at least broadly intended for use in that context.  Any other value that 
comes from writing down these rules is incidental.

More specifically: the crucial SOAP-related technical fact is that either 
the requestor or the responder has the right to send you a SOAP envelope, 
and I sure hope that when the dust settles the MEP will obligate you to 
process it per the SOAP processing model, and will tell you that if (a) if 
there is a SOAP error processing the request, e.g. an mU failure, you MUST 
attempt to deliver that fault back to the requestor and (b) if there is a 
SOAP failure processing the response you must similarly follow the rules 
of the SOAP Rec, but not in this case deliver the fault message to another 
site.  To support this MEP you MUST implement this SOAP-related behavior. 
The case where you choose not to send an envelope one way or the other is 
just one of the legal pathways through this.

So, I believe these are in both technical and political senses SOAP MEPs. 
As you know, framing them in the way we agreed on the call today is a bit 
of a compromise for me, but I don't think it's write to characterize 
either what DaveO first proposed or what we agreed to explore on today's 
call as SOAP-independent.  Thanks.

--------------------------------------
Noah Mendelsohn 
IBM Corporation
One Rogers Street
Cambridge, MA 02142
1-617-693-4036
--------------------------------------








David Hull <dmh@tibco.com>
Sent by: xml-dist-app-request@w3.org
01/06/2006 03:28 PM
 
        To:     David Orchard <dorchard@bea.com>
        cc:     xml-dist-app@w3.org, (bcc: Noah Mendelsohn/Cambridge/IBM)
        Subject:        Re: Rewrite of SOAP 1.2 Adjuncts


As far as I can tell, what we have, or at least what we want to have if we 
take this approach is SOAP-independent request-response.  That is, 
something always goes out, something always comes back, but neither 
message need be a SOAP envelope.  The optionality is in the SOAPiness, not 
in the existence of a response.

My rough understanding -- subject to change since I may be flat wrong -- 
is that this MEP would make sense on top of XMPP's "iq" (query) mechanism, 
which seems aimed at request-response, but probably not over the "message" 
mechanism.  The current SOAP/XMPP realizes this by taking advantage of 
XMPP's native WSA-like features to correlate a response message with a 
request message, but I believe this misses the important point that in 
request-response there is some guarantee that either a response comes back 
or a failure is signaled.

If it's possible for the "message"-based request-response MEP to simply 
fail to send back a response for arbitrarily long with no indication of 
failure, then it would be better to model the exchange as two one-ways, 
that is, move the request-response nature up a layer.  In any case, it 
would be good to expose XMPP's native WSA-like features as WSA (e.g., if 
you receive an XMPP message with an id, it's visible as the [message id] 
MAP, or perhaps acts as a default value for it, or MUST be identical to it 
or missing, or ...).  There is an open issue for this sort of thing in WSA 
at the moment.

David Orchard wrote: 
This is a rough rewrite of soap 1.2 adjuncts with a
request-optional-response MEP that is not SOAP specific (aka uber or
protocol mep) that supports one-way, simplified by removing the state
machine, and a commensurate SOAP HTTP binding.  In more detail, I've
removed the state machine from the SOAP MEPs, removed soap-response MEP,
change request-response to be optional response, removed some of the
properties from request-response MEP, removed need for SOAP envelopes on
request or response, added support for 202, updated binding for
request-response, and a few more things that I can't recall now. 

 

Some fascinating things: the HTML size dropped from 177 KB to 111 KB and
the xml dropped from 148 KB to 114 KB.  It's not often one can spend a
half day cutting 1/3 of a spec and (cross fingers) not break any impls.

 

Cheers,

Dave

Received on Wednesday, 11 January 2006 22:19:16 UTC