- From: Hugo Haas <hugo@w3.org>
- Date: Thu, 10 Feb 2005 11:15:00 +0100
- To: public-ws-async-tf@w3.org
- Message-ID: <20050210101500.GA9789@w3.org>
... are available at:
http://www.w3.org/2005/02/09-ws-async-minutes.html
Text dump follows:
[1]W3C
Web Services Asynchrony TF
9 Feb 2005
See also: [2]IRC log
Attendees
Present
MSEder, Jonathan_Marsh, GlenD, [IBM], Ugo_Corda, +1.919.969.aaaa, DaveHull, anish, [Sun], Roberto, Marc, +1.650.849.aabb, +1.650.849.aacc, TonyR
Regrets
Chair
Glen Daniels
Scribe
GregT
Contents
* [3]Topics
* [4]Summary of Action Items
__________________________________________________________________
<marc> anyone else getting: "this passcode is not valid" ?
<Roberto> yes. what's the passcode?
<GlenD> Roberto :ASYNC
<Roberto> 27962!
<anish> the passcode at [5]http://lists.w3.org/Archives/Member/member-ws-addressing/2005Feb/0003.html is not correct (the async is correct but 27692 is not)
<Roberto> glen, you had 27692 in the email
<GlenD> oops!
<GlenD> Sorry!
<MSEder> I scribed last time and Addressing also
<scribe> Scribe: GregT
<tibco-dmh> could someone put up a link to the powerpoint?
UNKNOWN_SPEAKER: discussion to be focused to try and figure out scope of the group
<anish> not sure if folks have seen this email which was sent not too long ago: [6]http://lists.w3.org/Archives/Public/public-ws-async-tf/2005Feb/0034.html
Greg - need to focus on how we can close this issue (and be comfortable with it)
Marsh - do we want people to describe all use cases by providing complete set of building blocks to combine specific scenario? or are there 2 or 3 common patterns to do soap both ways over different protocols?
Paco - I think it's more the 2/3 packet solution
Marc - we have the building blocks if we have a one-way message. I'm not convinced we need to introduce all this complexity underneath the operation
Marc - if we can focus on that question first... alot of this may not need to happen. I would like to get a sense of the group to figure whether we need to introduce these complex additions to WSDL (and do composition at the operation level)
Glen - doesn't same problem incur when you allow the response to come over a different protocol (whether you bind it 2 different ways)?
Marc - i don't know if WSDL is the right way to express that level
Glen - I can tell you, within my company, we don't want to require something like BPEL
Marc - I'm suggesting you do require BPEL to require something as complex as req/resp over different transports
Paco - even w/BPEL, you can't express operations that represent requests sometimes sync and sometimes async
Glen - if you are locked into a mode of one operation and another operation, there is no way to declare the other operation is the response to the first one.
Paco - the base case that triggered this, is the case where you have WSDL req/resp.. .and you want ot respond to it.
Paco - the async case (seperate connection), isn't covered by anything in WSDL 2.0
Marc - the point is that is using a binding that is not currently defined.
Marc - the standard soap binding supports this... (if I put a reply to in, it supports it)
Marc - people are building stuff w/these bindings in it now...
Anish - what's the advantage of using ws-addressing here then?
Marc - Action, messageIds, use those to compose long running conversations
Anish - seems like to me, and Marc has reinforced it, we havne't quite agreed as to the use cases we would like as output of this.
Glen - that's what we are trying to discuss.... we wrote these up
Anish - the ones that Kevin wrote up, it went into details of how wsdl 2.0 should do things. We need to focus on what use cases we want, how it works in SOAP, and how ......
Glen - I would prefer to start from bottom up (taking one operation, and do we want to break that up)
<anish> usecases: [7]http://lists.w3.org/Archives/Public/public-ws-async-tf/2005Feb/0034.html
Glen - is it just the http case which is interesting , or another goes over one and another goes over another
umit - if you want to get bogged down, you can do that... The underlying problem is not that SOAP is used in req/resp, we are bogged down on same connection problem.
Umit - once we get over that... we can look at addressing that next
Glen - we can look at this a number of ways.. 1) http binding allows 2 http connections (for req/resp), 2) taking an http binding for soap, and leaving composition to higher level
marc - I should point out examples using http async is allowable in current binding
Glen - it's allowable in current bidning, but there is 2 soap MEPs going on
Marc - in the post, you put request message (get a 303 - a redirect). You get a new URI, the semantic of 303 is do a get, where you get your result.
Umit - this isn't written in the spec
Marc - the HTTP spec
Glen - I don't think is disallowed, but its not one MEP
Marc - how HTTP works.. that's coped by the bindings, and what to do when you get 3XX
We don't let that bubble up and get it into the soap.
Anish - in the current SOAP binding, marc is interpretting the behavior of the 303.
Anish - it addressing polling use case..
anish - it doesn't address callback, and the case w/the 202
Umit - there is another thing (that assumes polling is ok and ambiguity is cleared). By looking at the WSDL, I don't know if someone is using polling or not. It's not explicit (in the binding section)
Glen - I think getting to this level is digging a bit too deeply. If we want to support this pattern, we need to make sure all the pieces are there. The question is, do we want to recommend that that pattern gets supported
Glen - right now, there is a contention, marc has been saying, it's not appropriate, for us to support a WSDL which is a req/resp on separate protocols, and you should use combination of these wsdl operatoins to support it
Paco - this doesn't capture full extent that wsa addresses req/resp operation. We have to make the decision to support this pattern. If you support req/resp, and wsa, you have to be prepared to open new connection and send response
Tony - there is a basic tension, that sending req/resp, everything looks the same (get a reqest in, send one out). From a client's point of view, I may never see the response. Therefore, it looks like 2 separate WSDL operations
Umit - replyTo is expected by client.
Glen - we had the discussion in WSDL group. It's completely up to sender to decide the concept of the same entity is. As long as we agree that I send the message to same "enttity", it doesn' t matter to same address
tibco-dmh - the question is.. .does WSDL have a way to send request and send reply back dynamically
Paco - that's one of the problems
Glen - should it?
Paco - should we start w/message exchanges that we think... we brought up a bunch of them
Paco - can we reduce the set, and build up the machinery? do we agree which ones those are?
ugo - regarding the question, 2 one-way composition,.... you aren't forced to decide when you write BPEL, whether the runtime is sync or async. If you want ot use 2 one-way operations, it's async
Glen - so far, I'm hearing marc as the opposition to keep everything as higher level above wsdl
Marsh - maybe this is a bad idea... but the charter may not be to make a decision, but recommend to another group. i.e., make an order list of things we can do to improve situation from documenting Marc's belief to support addressing, and publish a note to bring peoples attention, up to make changes in WSDL
Marsh - hopefully, the working group can draw the line where they feel they need to deal with. i.e., figure out benefit/cost ration (and let working group make the cut)
umit - good idea jonathon. kevin was trying to make that point
Glen - my only worry is, if we have a wide-open space, we may spend time dealing w/each one.
Anish - question for marc. Are you suggesting that we don't define new things, but it's enough ... 2 one way operations, that any correlation between the two should be done at BPEL, or WSDL?
Marc - my contention is we don't need anything new in existing WSDL
Marc - I want to push back on disallowing extensibility points
paco - does that violate current binding?
David - it seems that there are alot of req/resp operations currently defined, and if you just want to send to a 3rd party, it seems easier to tweek the binding, and say send wsa replyto and change req/repl to 2 one ways
Marc - lot of req/rsp used... very little use of sending resp to another message
David - chicken/egg situation.. if you can't do it...
marc - is it? If you include ws-addressing heades, you are free to use them, in ways we haven't described?
marc - if you are using soap/http binding, and put replyTo, in something other than anonymous, it's not going to work
Paco - that's what I mean by disallowed
Marc - that doesn't work in this bindign...
Paco - the bidnings we have, when we say disallow, you are claiming that everything is ok w/what we have (you can always define a new binding)
marc - if we had a one-way message, you can dfine what it means to put a replyTo, in there.
Paco - I think you are ignoring how things could play. people write wsdl w/req/resp... and don't use replyTo other than anonymous, and it's not an error
David - what concerns me when you advertise req/reply, I'm sending you a message, and sending you back a correlated reply. If you advertise a one-way, how do you advertise that this message MUST reply back w/the correlation
Kevin - w/BPEL, you have a way of doing that
(sorry... Ugo)
Anish - I'm of the same opinion you can use BPEL to do things on top. But this is a common use case that you don't need BPEL on top
Marc - I'm quite happy having req/resp (it's THE MEP)
David - you can either advertise req/reply or one way message w/ message correlation
David - it seems that the difference in this case, other than programming languages, the infrastructure can make the switch. Whereas, if I am writing code, I am going to say there is a callback arguement.
Ugo - once you define 2 oneway operations, there will be a sequence
Ugo - if I have 2 WSDL operations, there is no way to bind those operations to a single HTTP exchange
Ugo - that's 2 HTTP exchanges
David - it becomes harder
Umit - I'm trying to understand the concrete thing that Marc is asking us to do (and whether you are proposing... we did this for message delivery), but what is allowed for each WSDL MEP, whether people can use replyTo, faultTo, etc... (a specific matrix of what is possible)?
Marc - no...
Umit - then I don't undestand what you are saying
Marc - we shouldn't fiddle w/low level wsdl, and break up operations. Like in ws-md that ties 2 operations together
Umit - so you aren't suggesting BPEL at this point
Marc - BPEL is one way of how to do this but we don't have to build this into wsdl
Glen - do you believe people would want ot do this w/o BPEL, and it falls in our scope?
Marc - I'm not sure we need to do it
MikeLieder - it sounds like you have some basic architecture questions here
Glen - we got into a discussion of what is broken w/this stuff.. and that ended up in creating joint task force, as things end up on wsdl side, informed the addressing side
Glen - this groups charter is to define what this issue is. If we think this problem is out of scope, we can say that
Paco - let's pick up jonathon's suggestion and see what's realistic to address
Marsh - we can identify things that need to change. e.g., kevin's use case of expense report (if it's < $100 return immediately, if over $100, return later w/something)
kevin - for the client interface, it's still req/resp
Marsh - if we are talking about.. some of the other use cases have brought up this question.. If you have an in and the out may go somewhere out, you may not want to use an in/out mep
Marsh - maybe we need to defined new meps (I don't know). We need to draw the line somewhere of what ws-addressing can define, and what can be done in static wsdl description
Umit - kevin's use case is response is always generated
Anish - I want to go back to Marc's comment. he said something that the disagreement isn't hte usecase, but how to represent in wsdl. He said that you could do things like in ws-md, and decorate 2 one way operations, and say how they are correlated. Another way is to define new bindings, and include ws-addressing, and say resp may go over different http conenction. Is this correct marc? you talking about solutions to use case?
Marc - I was objecting to, in my view, of overcomplicating basic wsdl.
Marc - if people want to build usecases of tiying 2 one-way operations. I'm opposed to trying to address these usecases by having multiple bindings for an operation. It adds too much complexity to lower levels
Glen - it's not like you don't know the response is going to go as a sender, but more you are allowed to tell me where to send the response
Anish - let's say the taskforce decides to come up w/new binding, to do some things that people are talking about (and doesn't change wsdl structure), you wouldn't be opposed to defining such a binding (or to correlate one-ways)?
Marc - I need to look at it. extension sounds right way to go
marc - new binding, I don't know
<Zakim> Marsh, you wanted to worry about our MEP definitions
marsh - it would be helpfult ot me, to understand how to change wsdl to better accomodate. It's not clear to me what you can do today (i.e., whether you can break it up in 2 one-way operations). Some of this may work today, but whether or not you like the asthetics of the description...
marsh - I would like to see before/after of this.
Glen - should we categorize the usecases, and assign people to right them up?
(yes)
Glen - one-way message (wsdl and soap issue). Is this something we should deal with?
Marsh - I think it needs to go into the table
use case 1: One way message
use case 1: one way message w/a transport level 202 message (in particular)
Tony, the last thing I was to see is supporting simple cases, and making difficult cases even harder
use case 2: request/response
use case 3: 2 one-way correlated messages
<TonyR> Actually, I said I don't want to see the simple cases made complicated as a cost to supporting the unusual cases
use case 2: sync request/rsp over http (same connection)
use case 3: async req/response (wire-format separate - callback style)
use case 4: async req/response (wire-format separrate - polling style ) - i.e., 2 separate connections but wsdl as req/response both initiated by client
use case 5: 2 correlated one-way messages (as defined in WSDL)
use case 3 has 2 subcases (separate protocol, and different protocols)
use case 6: request/response (that may be sync/async depending on addressing headers)
<MSEder> zakim unmute me
Glen - we are looking for (a) how they can be implemented w/whats there, and (b) what could be done to make ti better?
Marsh - i.e., the best attempt to descriibe it, and what you can make better on it.
<scribe> ACTION: Marc will write up use case 1
<scribe> ACTION: Marc will write up one-way message usecase
<anish> ACTION: Marc will write up use case 1
<scribe> ACTION: Glen will write up use case 2 (sync req/resp over same connection)
<scribe> ACTION: Roberto will write up use case 3 (async req/response w/2 different connections, callback style)
<scribe> ACTION: Anish will write up use case 4 (async req/resp polling style)
<scribe> ACTION: Umit will write up use case 5 - 2 correlated one-way messages
<scribe> ACTION: David will write up req/response (that may be sync/async depending on addressing headers)
Meeting is adjourned!!!!
Summary of Action Items
[NEW] ACTION: Anish will write up use case 4 (async req/resp polling style)
[NEW] ACTION: David will write up req/response (that may be sync/async depending on addressing headers)
[NEW] ACTION: Glen will write up use case 2 (sync req/resp over same connection)
[NEW] ACTION: Marc will write up one-way message usecase
[NEW] ACTION: Marc will write up use case 1
[NEW] ACTION: Roberto will write up use case 3 (async req/response w/2 different connections, callback style)
[NEW] ACTION: Umit will write up use case 5 - 2 correlated one-way messages
[End of minutes]
__________________________________________________________________
Minutes formatted by David Booth's [8]scribe.perl version 1.110 ([9]CVS log)
$Date: 2005/02/10 10:13:31 $
References
1. http://www.w3.org/
2. http://www.w3.org/2005/02/09-ws-async-irc
3. http://www.w3.org/2005/02/09-ws-async-minutes.html#agenda
4. http://www.w3.org/2005/02/09-ws-async-minutes.html#ActionSummary
5. http://lists.w3.org/Archives/Member/member-ws-addressing/2005Feb/0003.html
6. http://lists.w3.org/Archives/Public/public-ws-async-tf/2005Feb/0034.html
7. http://lists.w3.org/Archives/Public/public-ws-async-tf/2005Feb/0034.html
8. http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
9. http://dev.w3.org/cvsweb/2002/scribe/
--
Hugo Haas - W3C
mailto:hugo@w3.org - http://www.w3.org/People/Hugo/
Received on Thursday, 10 February 2005 10:15:02 UTC