Re: The deep difference between request/response andfire-and-forget

noah_mendelsohn@us.ibm.com wrote:

>Jean-Jacques Moreau writes:
>
>  
>
>>Or are you implicitly calling for a "qos" property on the MEP
>>    
>>
>
>No.  In fact, while I think doing the MEP at all is a good idea sooner or 
>later, I'm neutral as to whether we should even tackle it in this round. 
>Unlike David Orchard, I feel that it is pretty close to being in the space 
>of the specific work we're being asked to do here.  In fact, our original 
>task was stated as "create a one-way MEP", and it was we who (correctly) 
>reinterpreted that as "solve WSA's problem."  Unlike what I take to be 
>David Hull's position to be, I don't think it's essential we do it now 
>either.  As I've said, I'm unconvinced that supporting it on HTTP is wise 
>in any case.
>
My position is that defining a one-way MEP is a major part of solving
WSA's problem.  I've also come to think [1] that defining more SOAP
properties (along with the existing ImmediateDestination and Action)
would be highly useful, though I haven't yet convinced WSA of this :-).

WSA only really makes sense at all if there's more than one protocol in
the world.  If there's just HTTP, then define HTTP "reply" and "fault"
headers and pretty much declare victory.

What really drove home the need for a one-way MEP was XMPP defining a
SOAP binding with only request-response, even though XMPP has a natural
fit for one-way.  As far as I can tell, this was done because
request-response (and response, which is clearly aimed at GET) are the
only game in town.  If there had been a one-way MEP, I'm 99.999% sure
that SOAP/XMPP would have bound it.  Perhaps the XMPP folks can comment.

I think the situation with email is similar.  In general, "binding SOAP
to a protocol" means binding request-response, whether it makes sense or
not (e.g., clearly there is a significant difference between doing a
request-response over HTTP and sending an email and hoping for a
response.)  This is purely an artifact of the present state of the SOAP
adjuncts.

WSA is built on the assumption that complex interactions can be built
out of one-way interactions (though we now rightly back away from
claiming that all interactions /are/ built that way from a WSA point of
view).  SOAP is built on a one-way processing model (albeit with these
elusive "intermediary" things lurking about).  I've argued elsewhere [2]
that the request-response MEP itself can be described more cleanly in
terms of one-way interactions.  The elephant is in the room.  Let's get
to know it and give it a name.

[1] http://lists.w3.org/Archives/Public/xml-dist-app/2006Jan/0135.html
[2]
http://lists.w3.org/Archives/Public/public-ws-addressing/2005Sep/0045.html
(Don't worry about the introductory text about making WSDL MEPs
primary.  The basic approach of re-analyzing request-response in terms
of one-way works even if WSDL doesn't exist)

> 
>
>If we do a one-way, I think that formalizing a qos property is complexity 
>that will be hard to get right.  On balance, I think I'd keep it simple 
>and do a straightforward one-way, without saying much about the qos 
>parameters.  If one ever did want to look at qos, then there would be more 
>than one parameter to consider.  Certainly expected delivery time and 
>likelihood of delivery are both potentially important.  I'd start by 
>keeping it simple and not trying to formalize either.
>
>Noah
>--------------------------------------
>Noah Mendelsohn 
>IBM Corporation
>One Rogers Street
>Cambridge, MA 02142
>1-617-693-4036
>--------------------------------------
>
>
>
>
>
>  
>