Re: Fw: SOAP 1.1 One-way HTTP Binding doc

Anish Karamarkar asks:

>(Noah wrote)
> > I'm not sure where to go with this.  One of the 
> responsibilities of MEPs 
> > in general is to indicate where faults will be delivered.  In
> the case of 
> > req/resp, they are to be delivered to the requestor, I.e. whatever the 

> 
> Do you mean req-resp where it is a SOAP req and a SOAP response OR 
> req-resp where it is a SOAP req and a transport response?
> I think there are different implications for faults depending on whether 

> the response is a SOAP res or a transport-level-only response.

That way of phrasing it seems circular to me.  The MEP says that when you 
receive the request you will process it, though it doesn't say how 
promptly.  The processing model says that if there are certain problems 
with the message then there >is< exactly one fault.  The MEP says that if 
there is a fault, which is by the way an envelope, it is to be delivered 
as the response.   This is part of the contract of the MEP.  It seems to 
me that, at least as we conceived it originally, lack of an envelope in 
the response would be evidence that there had been no fault.

> (Noah wrote) 
> 
> > Of course, we're in the process of "clarifying" the MEP, and maybe 
> > we could/should "clarify" it to state that a responder that sends no 
> > envelope is making no warranty as to whether SOAP processing 
> has yet been 
> > done, and in the case that it's not been done, that the MEP 
> has nothing to 
> > say about fault routing.
> > 
> 
> That is what I'm leaning towards.

Yeah, and I'm suggesting it as the best compromise for our users, but I 
think it's a pretty liberal reading of what we published in SOAP 1.2.

> Basically, I want to allow the following usecase:
> 1) a soap request gets sent over HTTP request with WSA FaultTo and 
> ReplyTo as non-anonymous.
> 2) the HTTP server that gets the message pushes it on a queue 
> successfully but does not do any SOAP processing.
> 3) A 202 status code with empty entity body is returned in the 
> HTTP response
> 4) subsequently, another agent dequeues the SOAP message, processes it 
> and sends the response/fault to the appropriate address specified by WSA 

> ReplyTo/FaultTo

Yes, I know that's the use case. I'm saying that I see it as quite a 
stretch for the pure request/response MEP as we had earlier defined it, 
because you could make the case that it changes the rules for fault 
routing.  It does at least preserve the basics, which is that the client 
will know whether to wait for a response.  I think this is probably the 
MEP the WSA group wants, but it's much more conceptually complicated than 
the classic one in which a request/resp is two messages, period. 

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

Received on Wednesday, 15 February 2006 22:10:59 UTC