RESOLUTION: A Specification of async only or sync only on WSDL is REQUIRED TOPIC: B - Specification of binding for async response dhull: 4 Options: dhull: 1)do nothing; dhull: 2)protocol/transport; dhull: 3)WSDL binding; dhull: 4)or combine 2 and 3 tony: +1 to DavidH Marc: Need to be more consistant about terminology with wsdl. Make sure that we need transport (not protocol) dorchard: agreed with dhull dorchard: Note sent this morning: A set of concerns and questions about the QName reference in Marc's proposal. 1. This makes the simple case hard, as a simple protocol switch requires another binding element. 2. Which operations are used for the response binding when it isn't input/output mep? One-way input, one-way output, output followed by input? 3. Which modules/features/properties are used from the selected response binding? Are all the component model properties, such as wsoap:header, "picked up"? 4. What happens if the component model properties "collide" between the "source" and "reference" binding, such as binding#1 and #2 both have wsoap:action specified. 5. What if, any, component model properties are used for the original source binding, including the original response operation? 6. Which of Binding Faults, infaults, outfaults are picked up by the reference? 7. Is it possible to switch out of a SOAP binding? For example, I could point to an HTTP binding for the response which says that the response type is not soap. 8. Can I switch into a SOAP binding? Could I switch from an HTTP binding to a SOAP binding to effectively be a "soap-response mep"? Cheers, Dave dorchard: Speaking for 1 or 2. 3 makes common case hard marc: 3 is more capable, 2 is ok: 3 provides more than just transport binding glen: In general what we want is SOAP - most issues are wrt how to bind to SOAP (e.g. what are the fault codes going to be) not WSDL binding level. glen: speaking in favour of 2 - don't require anything as complicated as 3 hugo: would like to understand if complications switching bindings umit: 2 will be half-baked and cause more problems. Favour of either 1 or 3. Not 2 dhull: Clarify meant 4 to mean: 3 + some convenient mechanism for 2 anish: 2 does not make simple case simple - makes assumption that there is no variability in the wsdl bindings: Vote 1 or 3 paul: speak for 2 marc: 1 is an interoperability problem. People will still want to return async on different transport. Not specifying relationship in wsdl will cause problems. dorchard: There are a lot of things that can be specified in a binding - but 3 brings in additional complexity if there are conflicts between request and respnse dorchard: Number 2 solves majority of cases. Small step which will get us partially there. glen: 2 could be used with additional property values for JMS (eg) specific values glen: 2 is a good step at this stage hugo: Concerned about impact on schedule. Could we put this in a separate document? umit: +1 to hugo chair: possible of 2.0 or separate doc for schedule gil: In favour of 1. Accept that there will be proprietary solutions but it would be worse if we overshoot schedule. jonathan: fear unexpected interactions with supporting 3 marc: please could david explain use of component designator syntax? dorchard: could possibly put in wsdl 2.0 binidng uri but behaviour will be undefined under this proposal dhull: clarify 1: is this same protocol vs async over http? glen: this is a separate issue - we are just discussing whether we have wsdl markup for async response paul: Focus on the schedule. WSDL binding will old up. Long time spent discussing this already - don't spend more time on this. umit: in charter, nothing to deliver response binding. speaking in favour of 1. david: if do 3 might as well do 4 dhull: leaning towards 1. don't commit more than required for working group. dhull: willing to opt for 1 but don't want to box in wrt adopting it. gil: 1 does not restrict asnc behaviour to underlying protocol Chair: chad: please express choices in preference Chair: option 1 - do nothing. Details of vote are: options for i059 Option 1: nothing Option 2: underlying protocol/transport Option 3: WSDL binding Option 4: 2+3 17 voters: BEA (2, 1) , BT (2, 1) , CA (3, 1) , Ericsson (2, 1) , Fujitsu (3, 1) , Hitachi (2, 1) , IBM (1, 3, 2) , Microsoft (1) , Nortel (1, 3, 2) , Oracle (3, 1) , SAP (1) , Sonic (2) , Sonoa (1) , Sun (3, 2, 1) , TIBCO (1, 2, 3) , W3C (1, 2) , WebMethods (1, 3) Round 1: Count of first place rankings. Round 2: First elimination round. Eliminating candidadates without any votes. Eliminating candidate 4. Round 3: Eliminating candidate 3. Candidate 1 is elected. Election: options for i059 Method: British Columbia STV Number of Ballots: 17 Threshold Name: Droop Static Whole Threshold Value: 9.0 Delayed Transfer of Surplus: Not Enabled. Batch Elimination: None 4 candidates running for 1 seats. R| 1| 2| 3| 4|Exha|Surp --+----+----+----+----+----+---- 1| 8.0| 5.0| 4.0| 0.0| 0.0| 0.0 3|11.0| 6.0| | | 0.0| 2.0 Round 1: Count of first place rankings. Round 2: First elimination round. Eliminating candidadates without any votes. Eliminating candidate 4. Round 3: Eliminating candidate 3. Candidate 1 is elected. Chair: call for objections: none RESOLUTION: Specification for async response NO ACTION TOPIC: C Specification of async at the interface/op level Anish: This proposal is addressing the core issue of PM async/sync capabilities - not relating to binding dhull: this is a hint - no further semantics. Is attaching this hinr promising that we will support anonymous URIs? anish: the marker has no implications wrt value of MEPs or service support of anonymous. All it is saying is that there ...might be a long delay between request and response jonathan: separate from WS-Addressing - this is a WSDL issue. anish: to me, this is really the async issue. the issue is core to the client PM - developers aren't concerned with underpinning transport/binding issues dhull: Names are important again here. Callbacks at client level is important but async is more about freely flowing msgs not request response. dhull: This seems out of scope to talk about code generation in the context of ws-addressing umit: observation that this appears to be a wsld problem - it is more of style hint to help tools to generate programming model. jonathan: explained style hints in wsdl 2.0: you can use this hint. Doesn't this require more force than a hint? I.e. what is the result if I ignore the hint? anish: Would like this to be a hint - it's not possible to specify the details. To ignore the hint will be at implementor's peril glen: should this be a policy assertion not boolean. glen: this is not hard to do and is not critical to the WG at this point. anish: motivation for why this dosn't have implications on anon/nonanon. this is because this marker does not know what anonURi means to the underpinning binding. dhull: Anish's point is very helpful. This clarifies that, at this level there's nothing addressing specific that we can decide. dhull: I don't think this is in scope. dorchard: what is the relationship between this marker. WSDL request/response wrt underlying protocol dorchard: Also what's relationship between partner links and service links - i.e. 2 one way correlated messages anish: this marker is making no statement of protocol level just saying to the client that request response is separated by a large amout of time. anish: BPEL partner links question: because this is such a common problem, this is not sufficient soltion jeff: +1 to above jonathan: This is not a length of time between request and response - this is a client programming model hint. umit: agrees that programming model characterisation gil: If abstract interface level uses this markup but binding is async=never, should wsdl processor flag an error? anish: the async never is talking about the value of the wsa:replyTo so this is slightly different. jonathan: i think that this proposal is interesting but whether we do this in this group is an issue. dorchard: I heard that the flag has no affect on the other WS-Addressing elements of attributes in the binding. I am against any thing that is just a hint because ...we wont be able to test. With constraints on binding this would make this more applicable. anish: I would accept an amendment for restrictions on bindings. Also, it should be a positive point that there is no impact of this ...in testing. umit: response binding was far simpler to this because it's just a programming hint. jeff: we keep saying that we will do things elsewhere. paul: if this isn't a testable assertion, then I don't see the value in it. dochard: I think that there are 2 possibilities hint only or binding implications chair: chad - 3 options: a) no b) yes - as a hint as initially described by Anish's proposal c) yes - abstract assertion with constraints on binding winning vote a Details of vote: options for i059 (hint) Option a: no Option b: hint Option c: hint with constraints on the binding 17 voters: BEA (c, a) , BT (a) , CA (c, a) , Ericsson (b, c) , Fujitsu (b, a) , Hitachi (b, a) , IBM (a) , Microsoft (a) , Nortel (a) , Oracle (b, c) , SAP (b) , Sonic (a) , Sonoa (a) , Sun (b, a) , TIBCO (a, c, b) , W3C () , WebMethods (a, b) Round 1: Count of first place rankings. Round 2: Eliminating candidate c. Candidate a is elected. Election: options for i059 (hint) Method: British Columbia STV Number of Ballots: 16 Threshold Name: Droop Static Whole Threshold Value: 9.0 Delayed Transfer of Surplus: Not Enabled. Batch Elimination: None 3 candidates running for 1 seats. R| a| b| c|Exha|Surp --+----+----+----+----+---- 1| 8.0| 6.0| 2.0| 0.0| 0.0 2|10.0| 6.0| | 0.0| 1.0 Round 1: Count of first place rankings. Round 2: Eliminating candidate c. Candidate a is elected. Winner is a. RESOLUTION: Specification of async at the interface level - NO ACTION