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

Rich Salz writes:

> Yes, my comments were only about TCP/IP, and as a generalization I don't 
disagree with you. 

Good.  I agree that we agree.

> I do disagree that it's worth standardizng MEPs that don't 
> leverage the common case in favor of general abstractions, however.

We seem to be on a course of standardizing:

* Request/response:  neither request nor response is optional, but the 
envelope is optional in the response.

* (probably) one way fire-n-forget

* Response only: as in SOAP 1.2, to model WebMethod=GET

I think that fits pretty well with standardizing common cases, at least as 
seen by applications.  If we can indeed support fire-n-forget on HTTP in 
particular, so be it, but we'll have to figure out who decides that it's 
not request/response, and what is actually done after the message is 
sent/received.  I still feel it's not particularly good practice to just 
close a socket after you receive an HTTP request, unless there's been some 
unrecoverable error.  In general, I think HTTP wants you to respond with 
some status code.  That's why I think the first MEP above is the right fit 
to HTTP, even if you have nothing more than a status code to signal that 
no more elaborate response is coming.

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








Rich Salz <[email protected]>
01/12/06 06:23 PM
 
        To:     "[email protected]" <[email protected]>
        cc:     "[email protected]" <[email protected]>
        Subject:        Re: The deep difference between request/response 
and fire-and-forget


Yes, my comments were only about TCP/IP, and as a generalization I don't
disagree with you.  I do disagree that it's worth standardizng MEPs that
don't leverage the common case in favor of general abstractions, however.

                 /r$

-- 
SOA Appliance Group
IBM Application Integration Middleware
* This address is going away; please use [email protected] *