IRC log of ws-async on 2005-02-09

Timestamps are in UTC.

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