Web Services Async TF -- 6 Apr 2005

<GlenD> oops

<scribe> Scribe: Hugo

Glen goes over the agenda:

- SOAP work

- Scope our work into an issue in Addressing

Glen: I took an AI to frame our work into an issue
... Dave has also sent a blog entry about protocol independence; we'll see if we have time to get to it

SOAP MEP

Glen: there's been some discussion on the list within the last week

DaveH: [giving his summary of the discussion]
... the in-optional-out SOAP MEP is trying to address some async case
... with the reply/address going somewhere else
... the HTTP response is what tells you if you're going to get an answer or not
... DaveO's blog entry is about this

<TonyR> http://www.pacificspirit.com/blog/2005/04/05/underlying_protocol_is_a_completely_leaky_abstraction

DaveH: my personal opinion is that we will always have something going back: you need either an application message or an ack
... otherwise you don't know

Glen: how does that relate to a true one-way MEP? do we need a separate one-way MEP?

Marc: do you always need anything back with this MEP?

Umit: yes; if you think about HTTP, there's always something coming back

Marc: this can be abstracted, right?

DaveH: sure, but this has to be taken into account
... I think in-optional-out is a misnommer; I prefer to call it in-(out-or-ack)

Greg: the ack to me is QoS

DaveO: the problem is not about QoS, it's about the HTTP error codes for the response

<marc> for the minutes, my point is that SOAP MEPs are about exchange of SOAP messages not underlying protocol artifacts

DaveH: if your WSDL MEP is one-way, then you're happy with fire-and-forget one-way; if it's request-response, then we have to consider this MEP

Glen: the question is: a thread is sending a message; when can the thread can go off and do something else?

Dave: in terms of coming up with one issue, I think that it is: what is needed in terms of WSDL to fully describe the combinations of SOAP/WSDL MEPs, and whether we need new SOAP MEPs for that

Greg: does the application care about whether things happen sync or asynchronously?

DaveO: given what SOAP+HTTP is, does WSA give you the ability to do what you'd like to do with it?

DaveH: I think we could address this by reducing the semantics of ReplyTo and FaultTo

Glen: but that reduces interop
... every app using our spec should expect the same behavior

<uyalcina> +1 To Glen

DaveH: we do define semantics in the core; I want to be careful that we don't say too much there, when things should be said in the WSDL binding

<dorchard> Issue text proposal: What are the constructs in WS-Addressing and the specifications it uses, like WSDL and SOAP, necessary for the full range of interoperable WS-A scenarios, such as asynch request/response and Fault handling.

Umit: can we say that it's not possible to use FaultTo and ReplyTo other than for anonymous with the current combination of WSDL and SOAP bindings

<dorchard> Break #1: one-way

Umit: if you put something else than anonymous, we don't know how it's going to behave

<GlenD> Issue text : We cannot reliably and interoperably use MAPs like ReplyTo/FaultTo with the current WSDL/SOAP constructs - the MEPs/behavior at the various layers are not clearly defined.

<dorchard> Break #2: FaultTo

DaveO: I'd like to spell it like: if FaultTo is specified, we don't know what to do with it

Mark: I think we're going in the right direction

<marc> "What SOAP MEP should be used to send a fault in the presence of a non-anonymous FaultTo"

<dorchard> Break #2: FaultTo + HTTP

<dorchard> Issue around is use of HTTP connection.

Glen: it is possible in any binding to have a transport error that may or may not be relayed to the app

DaveO: but I'm talking about a SOAP error
... if you generate a fault, what do you do with it? what HTTP error code do you use?

Umit: what if you have a redirect and a fault

DaveO: so you use a 400; can you send the fault back?
... right now we don't have a MEP like in-optional-fault

Greg: over JMS, I can send a message that is going to be sent successfully or not, but I won't know and I won't care
... I could disregard the HTTP error code, the same way

DaveO: yes; either we are going to ignore the HTTP error codes and everything which makes HTTP special, or we can use them, and we need to carefully take them into account

Umit: if you were to say that we need in and robust-in, can we have 2 different SOAP MEPs and bindings, and go from there

Glen: can you close a connecting right after an HTTP request?
... the SOAP MEP will take care of ignoring any response

Marc: what's the difference between the two cases in case of a 404?

DaveO: they would both have an empty 404

Umit: the robust-in is close to what the BP does

Glen: but something's going to happen in the in-only case too
... it may be an implementation difference about the kind of feedback you get

DaveH: there's another possible approach
... we could have an in-only MEP, with a reply expected property
... and the binding could take care of that
... you know from the ReplyTo and FaultTo whether you're expecting something

DaveO: which MEP are you talking about?

DaveH: WSDL MEP req-resp

<dorchard> hugo, he's talking about WSDL mep

DaveO: I think that you have to say at some point at the SOAP level if you're sending just a request, or if you're expecting anything back
... there's only 4 MEPs at the SOAP level that we could have

<dhull> DaveH: So why not say so explicitly?

<dhull> +1 multiple issues

Glen: do we want multiple issues, or a generic issue covering them all?

DaveO: I'd prefer 1 issue from a managerial perspective

Glen: I'm proposing to take a crack at writing this issue

Umit: I prefer my approach to the issue

DaveH: it's good to have 1 over-arching issue, but it clearly has multiple facets

<scribe> ACTION: Glen and Umit to write text for issue [recorded in http://www.w3.org/2005/04/06-ws-async-minutes.html#action01]

Glen: can we get together in CA just before the F2F?

<dorchard> I can be available monday afternoon?

Some agreement around meeting at 1pm on the 18th

<TonyR> Sounds like a good idea

Umit proposes to hold the meeting at SAP

<scribe> ACTION: Glen to send mail about meeting in CA [recorded in http://www.w3.org/2005/04/06-ws-async-minutes.html#action02]

<dorchard> SFO does have BART from airport to city...

- DRAFT -

Web Services Async TF

6 Apr 2005

Attendees

Contents

SOAP MEP

Summary of Action Items

Scribe.perl diagnostic output