- From: David Orchard <dorchard@bea.com>
- Date: Tue, 29 Mar 2005 14:12:40 -0800
- To: "David Hull" <dmh@tibco.com>, "Yalcinalp, Umit" <umit.yalcinalp@sap.com>
- Cc: "Marc Hadley" <Marc.Hadley@Sun.COM>, <public-ws-async-tf@w3.org>
- Message-ID: <32D5845A745BFB429CBDBADA57CD41AF0E90A002@ussjex01.amer.bea.com>
It seems to me that the binding of a one-way onto the connection-oriented HTTP protocol causes the side-effect that the one-way sender can have some knowledge about the connection. If the one-way was over a true connectionless protocol, it would have no way of knowing whether it was OK or not, ie 202 or 4xx. A central question is: does this "extra knowledge" that HTTP offers leak into the application or not? If it does, then a one-way message might actually get a fault, if say a 400 was returned. I have a feeling that nobody would deploy a true one-way over HTTP, they would deploy the robust variation that allows the fault. We could say something along the lines of "If binding to a connection oriented protocol, then you may want to use the robust variation for the protocol response code". And then if somebody does truly deploy a one-way over HTTP, then a 4xx fault return code gets dropped on the floor as the app won't be expecting it.
FWIW, this is yet another problem of all these different abstraction layers and then trying to compose them together in a meaningful way in the real application.
Then there is the 2nd issue, which is that given a 202 back, how does the SOAP sender "know" that there may be a body in the HTTP response? Again, this depends upon the mep in action. If it's a one-way only, then close the connection after the 202. If it's a robust or in-out, then sit in "receiving" mode until some content shows up, a content-length shows up, or the connection is closed.
Cheers,
Dave
_____
From: public-ws-async-tf-request@w3.org [mailto:public-ws-async-tf-request@w3.org] On Behalf Of David Hull
Sent: Tuesday, March 29, 2005 1:55 PM
To: Yalcinalp, Umit
Cc: Marc Hadley; public-ws-async-tf@w3.org
Subject: Re: In-optional out
Yalcinalp, Umit wrote:
The response at the HTTP transport is just a side effect of using the http protocol (202). It is an HTTP response, not SOAP response for one way messages. Wrt SOAP MEP perspective, this is not an ACK per se for SOAP protocol, but for http transport since there is no SOAP response message. Hence, I don't think we should bring the side effect of the transport with an explicit ACK at the SOAP layer.
The question then is, how do you know when you're done?
If you get an explicit 202 back, you know you're not going to get an actual message on the back-channel. Do we try to capture that at the SOAP level? Whatever we choose to call it, how would the SOAP level distinguish "in, no out" from "in, no out yet"?
--umit
-----Original Message-----
From: public-ws-async-tf-request@w3.org [mailto:public-ws-async-tf-request@w3.org]
Sent: Tuesday, Mar 29, 2005 12:33 PM
To: Marc Hadley
Cc: public-ws-async-tf@w3.org
Subject: Re: In-optional out
Marc Hadley wrote:
On Mar 29, 2005, at 1:51 PM, David Hull wrote:
Marc Hadley wrote:
This is all a bit confusing. SOAP doesn't define anything like an
ACK, that's an application level construct (assuming its a SOAP
message) so the in-(out|ACK) MEP is just a SOAP in-out (or
request/response).
My understanding was that, if there were no explicit reply, you
would still want to get back an empty (i.e., non-SOAP) message with a
202 code. This is distinct from, e.g., the receiver simply closing
the connection. Thus the (possible) need to introduce the notion of
an ACK at the SOAP level.
I think my confusion here stems from the fact that SOAP MEPs only talk
about exchanging SOAP messages not underlying protocol exchanges
(that's where the binding comes in) so if the ACK is purely at the
underlying protocol level then it won't show up as part of the SOAP MEP.
The question then is whether it is enough to model POST in/202 out as
in-[out] with no out, or whether the SOAP layer needs to report that
/something/ happened. If it needs to report that something happened,
then it can't very well report a SOAP message arrived, and we (or
someone :-) will have to create some new construct -- which I'm calling
an ACK -- to describe what happened.
Marc.
This would not be an application-level construct. The application
may well view things differently. For example, it might consider
sending the request and getting back a reply or fault as separate
events.
E.g.
App View
SOAP View
App sends request, reply-to: a callback, fault-to: the back channel
Sender sends the inbound message of an in-[out]
(normal processing) App gets reply on callback
Receiver sends back ACK. And that's it (sending back the reply is a
separate interaction)
(fault processing) App gets a fault
Receiver sends back a message (and that's it).
Marc.
On Mar 29, 2005, at 12:46 PM, David Hull wrote:
I've just read over the minutes from last week, and I'm doubly
sorry I missed the discussion. I'd also like to thank Jonathan for
the clear and thorough minutes.
When I first heard of an in-[out] (or even [in]-[out]) "über MEP",
it seemed like it was trying to generalize any possible MEP. An
in-only would be treated as [in]-[out] with an in and no out, and so
forth.
This seemed like a bad idea. It wouldn't actually cover all
possible MEPs, but it would add a layer of complexity to in-only or
even in-out ("in-out is [in]-[out] with both in and out present" as
opposed to "in-out is in-out"). Thence the George Carlin quote about
volleyball being team ping-pong with a raised net etc.
Reading through the minutes, though, in-[out] looks to be more
narrowly focused on an important fact of life: In some scenarios you
can't tell in advance whether you will get an application-level reply
on the back-channel. For example, if the normal course of action
were to send messages on to the "approval" and "logging" endpoints
given in the message addressing properties, while a fault should come
back on the back-channel, you would have to find out dynamically
which alternative was actually in effect. I suppose the
request/reply case with the one of the two endpoints directed to the
back-channel and the other directed elsewhere would also be an example.
In such cases, the in-[out] pattern captures the fact that you
might get back a message on the back-channel, or you might just get
back an ACK. It doesn't quite capture the possibility of getting
more than one message back on the back-channel (e.g., two or more
non-mutually-exclusive endpoints both pointed at the back-channel),
but perhaps it could be expanded to cover that, too. It might also
be better to describe the pattern as "in-(out|ACK)", emphasizing that
something always comes back (if that's what we mean).
As a side-effect, we could also model a one-way WSDL MEP as an
in-[out] with just an ACK coming back.
This is all described at the SOAP level, without reference to HTTP
or any other physical binding, which is why I say "ACK" instead of
"202". It's up to the binding to say what form the ACK takes.
With this in place, as I understand it:
* a in-only message would manifest as in-[out] with just an
ACK in reply
* existing synchronous request/reply still manifests as
request/reply
* asynchronous request/reply manifests as in-[out]
Is this all roughly correct?
---
Marc Hadley <marc.hadley at sun.com>
Business Alliances, CTO Office, Sun Microsystems.
---
Marc Hadley <marc.hadley at sun.com>
Business Alliances, CTO Office, Sun Microsystems.
Received on Tuesday, 29 March 2005 22:12:55 UTC