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