See also: IRC log
what is the passcode for this call?
<kliu> sorry I forget the Zakim meeting id, can somebody help?
me too
<TonyR> async
<Marsh> http://www.w3.org/2001/01/cgi-irc
<marc> i'd also like to know the dial in info
<scribe> scribe: anish
<scribe> Scribe: anish
<marc> ah, found it: +1.617.761.6200, conference 27962
mark: glen has agreed to chair
the TF meetings
... we have 3 more weeks to present to the WG at the tech
plenary
greg presents what he sent out on the ML
glen: there are lot of usecases
where WSDL gets generated into server side code
... i take the wsdl and the code generated is the programming
model
greg: from a logical perspective this could be a single portType, but if they are split up then they are going to be different things
glen: wsdl is one layering of
looking at messages on the wire
... another layer is bpel
<kliu> glen, to me the scope of wsdl and bpel is clear: wsdl mep deals with message exchange within an operation, bpel deals with operations, and only in the abstract level
<kliu> the issue is now if an abstract wsdl mep is splitted into mulitple binding meps
<kliu> then bpel will not be able to compose the binding meps
discussion between anish and glen about bpel and wsdl. General agreement about various ways to do this and coming up with pros and cons and presenting it to the WGs
ugo: wsdl 1.1 does allow this thru extensibility
glen: yes, but syntactically it does not say how
jonathan: this (greg's approach) seems more creative than daveo's approach
anish: well regardless of which
approach we take I think we need to do what daveo has suggested
as well as what greg is trying to do
... daveo is looking at MEPs and bindings where as greg is
looking at things on the wire and WSDL
glen: at the very least we need to come up with a SOAP one-way MEP
kevin: we also need to provide a poll (out-only operation)
<more discussion on out-only operation and SOAP binding>
glen: we need to come up with question and possible answers to those, such as do we need to create a new MEP etc
jonathan: wouldn't it help enumerate what we want to support?
<kliu> sounds I didn't make myself clear
<kliu> what I was trying to say is that
greg: the three models are:
one-way, request-response, and response-response over different
transport
... sounds like glen is asking for a fourth case
<kliu> no matter it's in-only or out-only)
marc: there is a std way to do this in HTTP by saying get the result of this from this URI
<kliu> ...we can define a http binding
<kliu> ... for one-directional meps
marc: one of the problems is dealing with NATs for post followed by a get
<kliu> ... which specifies how to deal with the http response, just like what's in BP
glen: there is a case where the response may have a choice of binding (thru replyTO)
greg: in slide 16 of my presentation
<kliu> ... that http binding is applicable for both in-only and out-only wsdl meps
greg: won't the server need to know apriori what the binding will be
glen: the high order bit here is -- the given operation is bound asynch or synch?
greg: or different transports
<more discussion on how the bindings/transport>
glen: two things - same transport different connections, different transport different connections
anish: this ties in to the WSD issue about allowing binding at the input and output level
micheal: another thing to do is -- same operation and the server decides whether the response is sent synchronously or asynchronously
<discussion about synch v. asynch and client programming model>
tony: to my mind the important
thing about asynch is not what the server sees but what the
client does while the client is waiting for the response
... the only issue is if the client side is trying to do
something else
... if it is, then it is asynch
michael: we need to be more organized, we have good input from today's discussion. But need to list things out
<MSEder> +1
kevin volunteers to summarize the options
anish to help kevin
marc: willing to dig out stuff about HTTP and using GET
<scribe> ACTION: kevin to send out a summary with various option for WSDL 2.0
<scribe> ACTION: glen to start discussion for appropriate wsdl granularity for aynch binding
<scribe> ACTION: 2 to glen to start discussion for appropriate wsdl granularity for multi-transport binding
ACTION 2=glen to start discussion for appropriate wsdl granularity for multi-transport binding
ACTION 3=
<scribe> ACTION: marc to look into HTTP POST+GET approach
adjouned
This is scribe.perl Revision: 1.109 of Date: 2005/01/21 04:36:25 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/keving/kevin/ Found Scribe: anish Inferring ScribeNick: anish Found Scribe: anish Inferring ScribeNick: anish Scribes: anish ScribeNicks: anish WARNING: No "Topic:" lines found. Default Present: MarkN, Rigo, Steve, MSEder, Ugo_Corda, Glen, Jonathan_Marsh, TonyRogers, Greg, +1.503.417.aaaa, anish, KevinL, [Sun], Roberto, Marc, [webMethods], asir, [IBM] Present: MarkN Rigo Steve MSEder Ugo_Corda Glen Jonathan_Marsh TonyRogers Greg +1.503.417.aaaa anish KevinL [Sun] Roberto Marc [webMethods] asir [IBM] Got date from IRC log name: 2 Feb 2005 People with action items: 2 glen kevin marc WARNING: No "Topic: ..." lines found! Resulting HTML may have an empty (invalid) <ol>...</ol>. Explanation: "Topic: ..." lines are used to indicate the start of new discussion topics or agenda items, such as: <dbooth> Topic: Review of Amy's report[End of scribe.perl diagnostic output]