- From: Glen Daniels <gdaniels@sonicsoftware.com>
- Date: Thu, 10 Feb 2005 11:00:49 -0500
- To: <public-ws-async-tf@w3.org>
Expanded attendance list: Greg Truty Paco Curbera Ugo Corda Dave Hull Jonathan Marsh Mike Eder Marc Hadley Roberto Chinnici Kevin Liu Anish Karmarkar Tony Rogers Umit Yalcinalp Glen Daniels --Glen > -----Original Message----- > From: public-ws-async-tf-request@w3.org > [mailto:public-ws-async-tf-request@w3.org] On Behalf Of Hugo Haas > Sent: Thursday, February 10, 2005 5:15 AM > To: public-ws-async-tf@w3.org > Subject: Minutes of the 2005-02-09 teleconference > > ... 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/20 > 05Feb/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/2005 > Feb/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/2005 > Feb/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/2005F > eb/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 16:00:26 UTC