19:58:12 RRSAgent has joined #ws-async 19:58:12 is logging to http://www.w3.org/2005/02/09-ws-async-irc 19:59:26 MSEder has joined #ws-async 20:00:26 WS_TF(async)3:00PM has now started 20:00:33 +MSEder 20:00:44 +Jonathan_Marsh 20:01:38 +GlenD 20:01:53 GlenD has joined #ws-async 20:02:27 ugo has joined #ws-async 20:02:39 +[IBM] 20:02:47 +Ugo_Corda 20:02:49 Roberto has joined #ws-async 20:02:50 marc has joined #ws-async 20:02:54 GregT has joined #ws-async 20:03:13 anyone else getting: "this passcode is not valid" ? 20:03:15 anish has joined #ws-async 20:03:16 + +1.919.969.aaaa 20:03:53 zakim, aaaa is DaveHull 20:03:53 +DaveHull; got it 20:03:57 +[IBM.a] 20:04:06 yes. what's the passcode? 20:04:15 +??P2 20:04:15 Roberto :ASYNC 20:04:28 zakim, ??P2 is me 20:04:28 +anish; got it 20:04:33 27962! 20:04:46 +[Sun] 20:04:47 kliu has joined #ws-async 20:04:51 zakim, Sun is Roberto 20:04:51 +Roberto; got it 20:05:02 the passcode at http://lists.w3.org/Archives/Member/member-ws-addressing/2005Feb/0003.html is not correct (the async is correct but 27692 is not) 20:05:04 glen, you had 27692 in the email 20:05:15 oops! 20:05:19 Sorry! 20:05:40 +Marc 20:05:42 tibco-dmh has joined #ws-async 20:06:04 + +1.650.849.aabb 20:06:33 Paco has joined #ws-async 20:07:12 - +1.650.849.aabb 20:07:28 I scribed last time and Addressing also 20:07:40 Scribe: GregT 20:07:43 + +1.650.849.aacc 20:09:00 could someone put up a link to the powerpoint? 20:09:09 ... discussion to be focused to try and figure out scope of the group 20:09:18 zakim, mute me 20:09:18 MSEder should now be muted 20:09:23 not sure if folks have seen this email which was sent not too long ago: http://lists.w3.org/Archives/Public/public-ws-async-tf/2005Feb/0034.html 20:10:33 Greg - need to focus on how we can close this issue (and be comfortable with it) 20:10:54 TonyR has joined #ws-async 20:12:07 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? 20:12:21 +??P7 20:12:35 zakim, ??P7 is me 20:12:35 +TonyR; got it 20:12:36 Paco - I think it's more the 2/3 packet solution 20:13:23 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 20:13:54 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) 20:14:21 Glen - doesn't same problem incur when you allow the response to come over a different protocol (whether you bind it 2 different ways)? 20:14:30 Marc - i don't know if WSDL is the right way to express that level 20:14:33 zakim, +1.919.969.aaaa is me 20:14:33 sorry, tibco-dmh, I do not recognize a party named '+1.919.969.aaaa' 20:14:48 Glen - I can tell you, within my company, we don't want to require something like BPEL 20:15:06 Marc - I'm suggesting you do require BPEL to require something as complex as req/resp over different transports 20:15:25 Paco - even w/BPEL, you can't express operations that represent requests sometimes sync and sometimes async 20:15:55 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. 20:16:06 q+ 20:16:17 q+ 20:16:24 Paco - the base case that triggered this, is the case where you have WSDL req/resp.. .and you want ot respond to it. 20:16:44 Paco - the async case (seperate connection), isn't covered by anything in WSDL 2.0 20:16:57 Marc - the point is that is using a binding that is not currently defined. 20:17:22 Marc - the standard soap binding supports this... (if I put a reply to in, it supports it) 20:17:34 Marc - people are building stuff w/these bindings in it now... 20:17:44 Anish - what's the advantage of using ws-addressing here then? 20:17:57 Marc - Action, messageIds, use those to compose long running conversations 20:18:25 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. 20:18:38 Glen - that's what we are trying to discuss.... we wrote these up 20:19:11 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 ...... 20:19:42 Glen - I would prefer to start from bottom up (taking one operation, and do we want to break that up) 20:20:48 usecases: http://lists.w3.org/Archives/Public/public-ws-async-tf/2005Feb/0034.html 20:20:55 Glen - is it just the http case which is interesting , or another goes over one and another goes over another 20:21:22 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. 20:21:38 Umit - once we get over that... we can look at addressing that next 20:22:27 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 20:22:43 marc - I should point out examples using http async is allowable in current binding 20:23:02 Glen - it's allowable in current bidning, but there is 2 soap MEPs going on 20:23:32 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. 20:23:41 Umit - this isn't written in the spec 20:23:45 Marc - the HTTP spec 20:23:56 Glen - I don't think is disallowed, but its not one MEP 20:24:18 Marc - how HTTP works.. that's coped by the bindings, and what to do when you get 3XX 20:24:30 We don't let that bubble up and get it into the soap. 20:25:13 Anish - in the current SOAP binding, marc is interpretting the behavior of the 303. 20:25:58 q- 20:26:03 Anish - it addressing polling use case.. 20:26:16 anish - it doesn't address callback, and the case w/the 202 20:26:21 zakim, unmute me 20:26:21 MSEder should no longer be muted 20:26:48 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) 20:27:23 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 20:28:05 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 20:28:42 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 20:29:25 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 20:29:47 Umit - replyTo is expected by client. 20:30:20 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 20:30:34 zakim, mute me 20:30:34 MSEder should now be muted 20:30:43 Tony - the question is.. .does WSDL have a way to send request and send reply back dynamically 20:30:47 Paco - that's one of the problems 20:30:50 Glen - should it? 20:31:08 Paco - should we start w/message exchanges that we think... we brought up a bunch of them 20:31:17 s/Tony/tibco-dmh 20:31:22 Paco - can we reduce the set, and build up the machinery? do we agree which ones those are? 20:31:47 umit has joined #ws-async 20:32:29 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 20:33:29 Glen - so far, I'm hearing marc as the opposition to keep everything as higher level above wsdl 20:33:33 zakim, unmute me 20:33:33 MSEder should no longer be muted 20:34:22 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 20:34:56 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) 20:35:17 umit - good idea jonathon. kevin was trying to make that point 20:35:23 q+ 20:35:33 Glen - my only worry is, if we have a wide-open space, we may spend time dealing w/each one. 20:36:04 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? 20:36:21 q+ 20:36:31 ack anish 20:36:43 Marc - my contention is we don't need anything new in existing WSDL 20:37:20 Marc - I want to push back on disallowing extensibility points 20:37:30 paco - does that violate current binding? 20:38:11 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 20:38:30 Marc - lot of req/rsp used... very little use of sending resp to another message 20:38:42 David - chicken/egg situation.. if you can't do it... 20:38:59 marc - is it? If you include ws-addressing heades, you are free to use them, in ways we haven't described? 20:39:16 marc - if you are using soap/http binding, and put replyTo, in something other than anonymous, it's not going to work 20:39:22 Paco - that's what I mean by disallowed 20:39:30 Marc - that doesn't work in this bindign... 20:39:52 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) 20:40:07 marc - if we had a one-way message, you can dfine what it means to put a replyTo, in there. 20:40:43 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 20:41:30 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 20:41:34 zakim, who is noisy? 20:41:37 Kevin - w/BPEL, you have a way of doing that 20:41:49 tibco-dmh, listening for 10 seconds I heard sound from the following: GlenD (29%), Ugo_Corda (99%) 20:41:59 (sorry... Ugo) 20:42:33 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 20:42:56 Marc - I'm quite happy having req/resp (it's THE MEP) 20:43:12 David - you can either advertise req/reply or one way message w/ message correlation 20:43:54 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. 20:44:04 Ugo - once you define 2 oneway operations, there will be a sequence 20:44:33 q+ 20:44:40 q- 20:45:00 Ugo - if I have 2 WSDL operations, there is no way to bind those operations to a single HTTP exchange 20:45:06 Ugo - that's 2 HTTP exchanges 20:45:11 David - it becomes harder 20:45:16 ack umi 20:45:19 q+ 20:46:04 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)? 20:46:07 Marc - no... 20:46:16 Umit - then I don't undestand what you are saying 20:46:37 Marc - we should fiddle w/low level wsdl, and break up operations. Like in ws-md that ties 2 operations together 20:46:45 Umit - so you aren't suggesting BPEL at this point 20:46:56 KevinL has joined #ws-async 20:46:59 Marc - BPEL is one way of how to do this but we don't have to build this into wsdl 20:47:14 Glen - do you believe people would want ot do this w/o BPEL, and it falls in our scope? 20:47:17 q+ to worry about our MEP definitions 20:47:21 Marc - I'm not sure we need to do it 20:47:52 MikeLieder - it sounds like you have some basic architecture questions here 20:48:17 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 20:48:21 s/we should fiddle/we shouldn't fiddle/ 20:48:54 Glen - this groups charter is to define what this issue is. If we think this problem is out of scope, we can say that 20:49:07 Paco - let's pick up jonathon's suggestion and see what's realistic to address 20:49:36 q+ 20:49:44 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) 20:50:13 kevin - for the client interface, it's still req/resp 20:50:14 q+ 20:50:23 zakim, mute me 20:50:23 MSEder should now be muted 20:50:40 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 20:51:10 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 20:51:21 Umit - kevin's use case is response is always generated 20:51:29 ack anish 20:52:33 q- 20:52:37 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? 20:52:50 Marc - I was objecting to, in my view, of overcomplicating basic wsdl. 20:53:25 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 20:53:45 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 20:54:24 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)? 20:54:34 Marc - I need to look at it. extension sounds right way to go 20:54:41 marc - new binding, I don't know 20:54:45 ack marsh 20:54:45 Marsh, you wanted to worry about our MEP definitions 20:55:35 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... 20:55:46 marsh - I would like to see before/after of this. 20:55:56 Glen - should we categorize the usecases, and assign people to right them up? 20:55:56 q+ 20:55:59 (yes) 20:56:21 Glen - one-way message (wsdl and soap issue). Is this something we should deal with? 20:56:29 Marsh - I think it needs to go into the table 20:56:35 use case 1: One way message 20:57:03 use case 1: one way message w/a transport level 202 message (in particular) 20:57:05 ack tony 20:57:30 Tony, the last thing I was to see is supporting simple cases, and making difficult cases even harder 20:58:27 use case 2: request/response 20:58:33 use case 3: 2 one-way correlated messages 20:58:39 Actually, I said I don't want to see the simple cases made complicated as a cost to supporting the unusual cases 20:59:02 use case 2: sync request/rsp over http (same connection) 20:59:19 zakim, unmute me 20:59:19 MSEder should no longer be muted 21:00:38 use case 3: async req/response (wire-format separate - callback style) 21:01:13 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 21:01:30 use case 5: 2 correlated one-way messages (as defined in WSDL) 21:02:20 -[IBM.a] 21:02:28 use case 3 has 2 subcases (separate protocol, and different protocols) 21:02:30 zakim,mute me 21:02:30 MSEder should now be muted 21:03:02 use case 6: request/response (that may be sync/async depending on addressing headers) 21:03:12 zakim unmute me 21:05:21 Glen - we are looking for (a) how they can be implemented w/whats there, and (b) what could be done to make ti better? 21:05:44 Marsh - i.e., the best attempt to descriibe it, and what you can make better on it. 21:06:08 Action: Marc will write up use case 1 21:06:19 ACTION: Marc will write up one-way message usecase 21:06:19 zakim, unmute me 21:06:19 MSEder should no longer be muted 21:06:19 ACTION: Marc will write up use case 1 21:06:55 ACTION: Glen will write up use case 2 (sync req/resp over same connection) 21:07:46 ACTION: Roberto will write up use case 3 (async req/response w/2 different connections, callback style) 21:07:56 zakim, mute me 21:07:56 MSEder should now be muted 21:08:37 ACTION: Anish will write up use case 4 (async req/resp polling style) 21:09:02 ACTION: Umit will write up use case 5 - 2 correlated one-way messages 21:10:25 ACTION: David will write up req/response (that may be sync/async depending on addressing headers) 21:11:05 Meeting is adjourned!!!! 21:11:10 -[IBM] 21:11:11 -anish 21:11:12 -Marc 21:11:13 - +1.650.849.aacc 21:11:14 GregT has left #ws-async 21:11:14 ugo has left #ws-async 21:11:15 -Jonathan_Marsh 21:11:16 MSEder has left #ws-async 21:11:17 -Roberto 21:11:18 -GlenD 21:11:20 -Ugo_Corda 21:11:21 -TonyR 21:11:23 TonyR has left #ws-async 21:11:24 -DaveHull 21:11:26 -MSEder 21:11:28 WS_TF(async)3:00PM has ended 21:11:29 Attendees were 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 21:11:55 zakim, +1.919.969.aaaa is me 21:11:55 sorry, tibco-dmh, I do not recognize a party named '+1.919.969.aaaa' 21:12:22 zakim, who is here 21:12:22 tibco-dmh, you need to end that query with '?' 21:12:29 zakim, who is here? 21:12:29 sorry, tibco-dmh, I don't know what conference this is; apparently WS_TF(async)3:00PM has ended 21:32:40 Marsh has left #ws-async 21:56:48 RRSAgent, bye 21:56:48 I see 7 open action items: 21:56:48 ACTION: Marc will write up one-way message usecase [1] 21:56:48 recorded in http://www.w3.org/2005/02/09-ws-async-irc#T21-06-19 21:56:48 ACTION: Marc will write up use case 1 [2] 21:56:48 recorded in http://www.w3.org/2005/02/09-ws-async-irc#T21-06-19-3 21:56:48 ACTION: Glen will write up use case 2 (sync req/resp over same connection) [3] 21:56:48 recorded in http://www.w3.org/2005/02/09-ws-async-irc#T21-06-55 21:56:48 ACTION: Roberto will write up use case 3 (async req/response w/2 different connections, callback style) [4] 21:56:48 recorded in http://www.w3.org/2005/02/09-ws-async-irc#T21-07-46 21:56:48 ACTION: Anish will write up use case 4 (async req/resp polling style) [5] 21:56:48 recorded in http://www.w3.org/2005/02/09-ws-async-irc#T21-08-37 21:56:48 ACTION: Umit will write up use case 5 - 2 correlated one-way messages [6] 21:56:48 recorded in http://www.w3.org/2005/02/09-ws-async-irc#T21-09-02 21:56:48 ACTION: David will write up req/response (that may be sync/async depending on addressing headers) [7] 21:56:48 recorded in http://www.w3.org/2005/02/09-ws-async-irc#T21-10-25