W3C home > Mailing lists > Public > xml-dist-app@w3.org > January 2006

RE: Rewrite of SOAP 1.2 Adjuncts

From: David Orchard <dorchard@bea.com>
Date: Mon, 9 Jan 2006 14:35:43 -0800
Message-ID: <E16EB59B8AEDF445B644617E3C1B3C9C3B514D@repbex01.amer.bea.com>
To: "David Hull" <dmh@tibco.com>
Cc: <xml-dist-app@w3.org>
The something goes out something always comes back might be your
preferred approach, but that's not what I wanted to write up in the
revised SOAP request-response mep which makes the response optional.
The optionality in "optional-response" is in the protocol response AND
the SOAPness of the response.

 

Dave

 

________________________________

From: David Hull [mailto:dmh@tibco.com] 
Sent: Friday, January 06, 2006 12:28 PM
To: David Orchard
Cc: xml-dist-app@w3.org
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 Monday, 9 January 2006 22:36:02 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:59:21 GMT