← Prev in month
← Prev in thread
Next in thread →
Next in month →
Text Minutes from Bindings Virtual F2F, Day 2
Introductions Roll call Scribe assignment Agenda bashing 2. Actions Check status of any actions opened on previous call 20081201-2 [Anish Karmarkar] Propose wording along the lines of "how about saying (1) wsdl allows extension, go look at what the rules are in the wsdl spec, (2) we define the following extension and what the MUST-ness for that is" to resolve Dave's second concern from his email. 20081201-3 [Simon Holdsworth] Produce updated revision of binding.jms using the phrase "raised" for error situations and revert line 219 to can 20081201-4 [Piotr Przybylski] Amend binding.jca spec to include all the listed updates except text for issue 45 3. New Issues Please note, as per resolution on 9th October 2008, new issues received on the mailing list after Noon GMT 1st November can only be opened using the same voting rules as re-opening a closed issue (2/3 majority of a full TC vote) Process any new issues opened on previous call No additional new issues 4. Open Issue Discussion Continue discussing issue resolutions. Note that from a scheduling point of view, each issue is limited to 1 hour of discussion on today's agenda. Any unresolved issues will be carried over to the next day. Open issues with proposed resolutions: http://www.osoa.org/jira/browse/BINDINGS-51 WS Binding spec needs RFC 2119 language Raiser: Dave Booz, owner: Editors Status: Current proposed text in http://www.oasis-open.org/committees/download.php/30115/sca-binding-ws-1.1-spec-cd01-rev3.doc Latest email: http://lists.oasis-open.org/archives/sca-bindings/200812/msg00020.html http://www.osoa.org/jira/browse/BINDINGS-52 JMS Binding needs RFC 2119 language Raiser: Dave Booz, owner: Editors Status: Current proposed text in http://www.oasis-open.org/committees/download.php/30243/sca-binding-jms-1.1-spec-cd01-rev3.doc http://www.osoa.org/jira/browse/BINDINGS-53 JCA Binding needs RFC 2119 language Raiser: Dave Booz, owner: Editors Status: Current proposed text in http://www.oasis-open.org/committees/download.php/29718/sca-binding-jca-1.1-spec-cd01-rev2.doc http://www.osoa.org/jira/browse/BINDINGS-2 How should SCA callback semantics be carried over Web Services? Raiser: Simon Nash, owner: Anish Karmarkar Status: Proposed resolution: http://lists.oasis-open.org/archives/sca-bindings/200810/msg00088.html Latest email: http://lists.oasis-open.org/archives/sca-bindings/200810/msg00091.html http://www.osoa.org/jira/browse/BINDINGS-7 JMS bindingType and ordered intent - clarification needed Raiser: Peter Peshev, owner Simon Holdsworth Status: Proposed resolution in email: http://lists.oasis-open.org/archives/sca-bindings/200812/msg00005.html http://www.osoa.org/jira/browse/BINDINGS-11 "Formal" WSDL generation is unclear, ambiguous, and incomplete Raiser: Eric Johnson, owner: Eric Johnson, Anish Karmarkar Status: Latest email: http://lists.oasis-open.org/archives/sca-bindings/200811/msg00071.html http://www.osoa.org/jira/browse/BINDINGS-31 What is a "plain name" for a connection factories or activation specs, and how is one distinguished from a JNDI name? Raiser: Eric Johnson, owner: Simon Holdsworth Status: Updated proposal in http://lists.oasis-open.org/archives/sca-bindings/200812/msg00027.html http://www.osoa.org/jira/browse/BINDINGS-40 Clarify rules around combination of destination, CF and AS elements Raiser: Simon Holdsworth, owner: Simon Holdsworth Status: Latest email: http://lists.oasis-open.org/archives/sca-bindings/200812/msg00028.html http://www.osoa.org/jira/browse/BINDINGS-42 Clarify default data binding for JMS Raiser: Simon Holdsworth, owner: Simon Holdsworth Status: Proposed resolution in email: http://lists.oasis-open.org/archives/sca-bindings/200812/msg00007.html http://www.osoa.org/jira/browse/BINDINGS-44 Update binding.jms spec for wireFormat/operationSelection elements Raiser: Simon Holdsworth, owner: Simon Holdsworth Status: Latest email: http://lists.oasis-open.org/archives/sca-bindings/200810/msg00073.html http://www.osoa.org/jira/browse/BINDINGS-55 WSDL 2.0 support Raiser: Bryan Aupperle, owner: Editors Status: Proposal in issue http://www.osoa.org/jira/browse/BINDINGS-57 Add a section documenting naming convention + be consistent on naming intents (binding.ws) Raiser: Anish Karmarkar, owner: Editors Status: Proposal in issue http://www.osoa.org/jira/browse/BINDINGS-58 Add a section documenting naming convention + be consistent on naming intents (binding.jca) Raiser: Anish Karmarkar, owner: Editors Status: Proposal in issue http://www.osoa.org/jira/browse/BINDINGS-59 Add a section documenting naming convention + be consistent on naming intents (binding.jms) Raiser: Anish Karmarkar, owner: Editors Status: Proposal in issue Open issues with identified resolution owner: http://www.osoa.org/jira/browse/BINDINGS-21 Support for callback and conversation ID-s in bindings Raiser: Peter Peshev, owner Peter Peshev Status: Proposed resolution in issue Notes: As for BINDINGS-2, this is waiting for clarification around conversations at the assembly level http://www.osoa.org/jira/browse/BINDINGS-39 JMS callback specification does not cater for callbacks using other bindings Raiser: Simon Holdsworth, owner Simon Holdsworth Status: Complete resolution proposal required http://www.osoa.org/jira/browse/BINDINGS-43 Update binding.ws spec for wireFormat/operationSelection elements Raiser: Simon Holdsworth, owner: Anish Karmarkar Status: Specific resolution text required. http://www.osoa.org/jira/browse/BINDINGS-45 Update binding.jca spec for wireFormat/operationSelection elements Raiser: Simon Holdsworth, owner: Piotr Przybylski Status: Specific resolution text required. http://www.osoa.org/jira/browse/BINDINGS-54 Endpoint URI algorithm is unclear Raiser: Eric Johnson, owner: Eric Johnson Status: Initial proposal in JIRA. Open issues with no identified resolution owner: http://www.osoa.org/jira/browse/BINDINGS-22 Bindings specifications should provide exemplary Implementations for Callbacks and Conversations Raiser: Mike Edwards Status: No proposed resolution Notes: As for BINDINGS-2, this is waiting for clarification around conversations at the assembly level http://www.osoa.org/jira/browse/BINDINGS-23 @wsdlElement definition needs clarification on "equivalent" and use of WSDL 2.0 constructs Raiser: Eric Johnson Status: Specific resolution text required http://www.osoa.org/jira/browse/BINDINGS-24 Which wire did a message arrive on? Raiser: Sanjay Patil Status: Waiting for examples from Sanjay as per 20080717-4 http://www.osoa.org/jira/browse/BINDINGS-25 Is it required that every implementation of binding.ws support the soap intent? Raiser: Anish Karmarkar Status: No current proposal. Latest email: http://lists.oasis-open.org/archives/sca-bindings/200807/msg00006.html http://www.osoa.org/jira/browse/BINDINGS-29 Properties on Bindings Raiser: Piotr Przybylski Status: No current proposal; defer until Policy 15 (External Attachment) is resolved http://www.osoa.org/jira/browse/BINDINGS-48 How are mayProvide intents on bindings satisfied Raiser: Ashok Malhotra Status: No current proposal; latest email: http://lists.oasis-open.org/archives/sca-bindings/200810/msg00041.html 6. AOB Topic: Actions 20081201-2: Complete 20081201-3: Complete 20081201-4: Pending Topic: Bindings-51 http://www.osoa.org/jira/browse/BINDINGS-51 Current proposed text in http://www.oasis-open.org/committees/download.php/30115/sca-binding-ws-1.1-spec-cd01-rev3.doc Latest email: http://lists.oasis-open.org/archives/sca-bindings/200812/msg00020.html anish: When a Web Service binding is specified using the @wsdlElement attribute, the details of the binding are specified by the WSDL element referenced by the value of the attribute. Per the WSDL specification, WSDL elements allow for extensibility via elements as well as attributes, and it specifies rules for processing such elements. The Web Service binding does not constrain the use of such extensibility in WSDL and relies on the rules specified in the WSDL specification for processing such extended elements. This binding requires that the SCA runtime MUST support the WSDL extensions [include-a-list-of-extensions] defined at [include-a-list-of-refs]. Note that as a consequence of this, when using this form of Web Service binding, it is not possible to determine whether the binding is supported by the SCA runtime without parsing the referenced WSDL element and its dependent elements. Simon Nash: s/WSDL elements allow/WSDL allows/ Anish reviews his propsal Mike E. reviews his proposed revision Discussion about what, if anything, needs to be said about WSDL extensions not defined by SCA anish: simonN, perhaps there is a better phrase than 'support', if so pl. suggest an alternative Eric: list of specs should be limited to Assembly and Policy Anish: Mild preference for listing all the WSDL extensions for readability. Mike E. an SCA runtime should not be allowed to throw an error if a WSDL document is used with an SCA-BPEL extension in it. anish: btw, sca-bpel does not define any wsdl extension, it defines BPEL extensions (on partnerlinks) Mike Edwards: +1 to Martin's point Bryan: we can and should use namespaces to separate wsdl extensions that not all SCA runtimes would be required to support. Martin: This is a question of packaging of conformance points. General discussion about conformance relationships between the specs. Mike E. we need to not use required WSDL extensions but rather each spec needs to state what a conforming implementation must support anish: btw, eventhough partnerLinkTypes are defined in WSDL, SCA-BPEL does not define extensions for partnerLinkType. It defines extensions for partnerLink and Variables -- both of these occur in a BPEL process Eric Johnson: Proposal: This binding requires that the SCA runtime MUST support the WSDL extensions defined in the SCA namespace. Mike Edwards: http://docs.oasis-open.org/ns/opencsa/sca/200712 anish: This binding requires that the SCA runtime MUST support the WSDL extensions defined in the SCA namespace used by this binding. This binding requires that an SCA runtime MUST support the WSDL extensions defined in http://docs.oasis-open.org/ns/opencsa/sca/200712 namespace. Mike Edwards: so: "sca:" namespace Simon Nash: where is "sca:" defined? Martin C : all our specs should have a namespace prefix table This binding requires that an SCA runtime MUST support the WSDL extensions defined in the sca: namespace. anish: using the prefix in this context, without calling it out that it is a prefix, is strange anish: how about: Simon Nash: yes, we should explain that Ashok: In the namespace identified by the sca: prefix anish: This binding requires that an SCA runtime MUST support the WSDL extensions defined in the namespace associated with the prefix "sca" (as defined in section 1.1). anish: or what ashok said anish: s/This binding/This specification/ Eric Johnson: Revised text proposal: Eric Johnson: When a binding.ws element uses the @wsdlElement attribute, the details of the binding are specified by the WSDL element referenced by the value of the attribute. Per the WSDL specification, WSDL elements allow for extensibility via elements as well as attributes, and it specifies rules for processing such elements. This specification does not constrain the use of such extensibility in WSDL and relies on the rules specified in the WSDL specification for processing such extended elements. This specification requires that an SCA runtime MUST support the WSDL extensions defined in the namespace associated with the prefix "sca" (as defined in section 1.1). Note that as a consequence of this, when using the @wsdlElement form of binding.ws, it is not possible to determine whether the binding is supported by the SCA runtime without parsing the referenced WSDL element and its dependent elements. Mike Edwards: (ie the WSDL might contain extension elements which cannot be supported by the SCA runtime). anish: When a binding.ws element uses the @wsdlElement attribute, the details of the binding are specified by the WSDL element referenced by the value of the attribute. Per the WSDL specification, WSDL allow for extensibility via elements as well as attributes, and it specifies rules for processing such elements. This specification does not constrain the use of such extensibility in WSDL and relies on the rules specified in the WSDL specification for processing such extended elements. This specification requires that an SCA runtime MUST support the WSDL extensions defined in the namespace associated with the prefix "sca" (as defined in section 1.1). Note that as a consequence of this, when using the @wsdlElement form of binding.ws, it is not possible to determine whether the binding is supported by the SCA runtime without parsing the referenced WSDL element and its dependent elements. Simon Nash: s/WSDL allow/WSDL allows/ Simon Holdsworth1: a (ie the WSDL might contain extension elements which cannot be supported by the SCA runtime). When a binding.ws element uses the @wsdlElement attribute, the details of the binding are specified by the WSDL element referenced by the value of the attribute. Per the WSDL specification, WSDL allows for extensibility via elements as well as attributes, and it specifies rules for processing such elements. This specification does not constrain the use of such extensibility in WSDL and relies on the rules specified in the WSDL specification for processing such extended elements. This specification requires that an SCA runtime MUST support the WSDL extensions defined in the namespace associated with the prefix "sca" (as defined in section 1.1). Note that as a consequence of this, when using the @wsdlElement form of binding.ws, it is not possible to determine whether the binding is supported by the SCA runtime without parsing the referenced WSDL element and its dependent elements (i.e. the WSDL might contain extension elements which cannot be supported by the SCA runtime). Simon Nash: Because the WSDL might contain extension elements which cannot be supported by the SCA runtime, when using the @wsdlElement form of binding.ws, it is not possible to determine whether the binding is supported by the SCA runtime without parsing the referenced WSDL element and its dependent elements. Simon Nash: Because a WSDL document might contain extension elements that cannot be supported by the SCA runtime, when using the @wsdlElement form of binding.ws it is not possible to determine whether the binding is supported by the SCA runtime without parsing the referenced WSDL element and its dependent elements. s/the WSDL/a WSDL document/ anish: When a binding.ws element uses the @wsdlElement attribute, the details of the binding are specified by the WSDL element referenced by the value of the attribute. Per the WSDL specification, WSDL allows for extensibility via elements as well as attributes, and it specifies rules for processing such elements. This specification does not constrain the use of such extensibility in WSDL and relies on the rules specified in the WSDL specification for processing such extended elements. This specification requires that an SCA runtime MUST support the WSDL extensions defined in the namespace associated with the prefix "sca" (as defined in section 1.1). anish: When a binding.ws element uses the @wsdlElement attribute, the details of the binding are specified by the WSDL element referenced by the value of the attribute. Per the WSDL specification, WSDL allows for extensibility via elements as well as attributes, and it specifies rules for processing such elements. This specification does not constrain the use of such extensibility in WSDL and relies on the rules specified in the WSDL specification for processing such extended elements. This specification requires that an SCA runtime MUST support the WSDL extensions defined in the namespace associated with the prefix "sca" (as defined in section 1.1). Because a WSDL document might contain extension elements that cannot be supported by the SCA runtime, when using the @wsdlElement form of binding.ws it is not possible to determine whether the binding is supported by the SCA runtime without parsing the referenced WSDL element and its dependent elements. anish: simon, do you want it to say something like 'MUST generate an error' if an unsupported extension is encountered? AI: (Anish) Post updated draft of binding.ws spec with above and correction per Dave B.'s note about non-required. Topic: Bindings-52 http://www.osoa.org/jira/browse/BINDINGS-52 Current proposed text in http://www.oasis-open.org/committees/download.php/30243/sca-binding-jms-1.1-spec-cd01-rev3.doc anish i found more occurrences of the word 'required', so going to fix that as well anish never mind, they are all in section 4, which we are going to change anyway Motion: Resolve bindings 52 using http://www.oasis-open.org/committees/download.php/30243/sca-binding-jms-1.1-spec-cd01-rev3.doc(Mike E. second Eric) Resolution: Motion passes w/o anish: ws-binding rev4 has been uploaded anish: http://www.oasis-open.org/apps/org/workgroup/sca-bindings/download.php/30249/sca-binding-ws-1.1-spec-cd01-rev4.doc anish: http://www.oasis-open.org/apps/org/workgroup/sca-bindings/download.php/30250/sca-binding-ws-1.1-spec-cd01-rev4.pdf Simon Holdsworth1: External URLs: http://www.oasis-open.org/committees/download.php/30250/sca-binding-ws-1.1-spec-cd01-rev4.pdf Simon Holdsworth1: http://www.oasis-open.org/committees/download.php/30249/sca-binding-ws-1.1-spec-cd01-rev4.doc resuming Topic Bindings-51 (again) Latest update at link above anish should have been cd01-rev2-51proposal Anish reviews latest changes (and clarifies totality of changes) Discussion about document revision naming. Motion: Resolve Bindings-51 using http://www.oasis-open.org/committees/download.php/30250/sca-binding-ws-1.1-spec-cd01-rev4.pdf (Dave, second Mike E.) Resolution: Motion passes w/o Mike takes up scribe duties http://www.osoa.org/jira/browse/BINDINGS-2 How should SCA callback semantics be carried over Web Services? Raiser: Simon Nash, owner: Anish Karmarkar Status: Proposed resolution: http://lists.oasis-open.org/archives/sca-bindings/200810/msg00088.html Latest email: http://lists.oasis-open.org/archives/sca-bindings/200810/msg00091.html Simon Holdsworth1: Latest discussion around separation of the callback protocol description: http://lists.oasis-open.org/archives/sca-bindings/200812/msg00030.html Anish suggests discussing the technical contents first, before worrying about the packaging question http://lists.oasis-open.org/archives/sca-bindings/200810/msg00088.html contains the document SCA-bindings-issue2-proposal-v3.doc Simon N: Does section 1) apply only for Bidirectional interfaces? Anish: Yes, this is for implementing bidirectional interfaces using SOAP Simon - is that error required even if the service does not attempt to make a callback Anish: Yes, it is still an error if there is no callback address Simon: Sounds as if there is inconsistency in the handling of error conditions here, since for example, a bogus address could only be detected when an actual callback is attempted. anish that is the robustness principle anish be liberal in what you accept and conservative in what you send Anish describes 2) and 3) in the proposal Simon - direction in SCA-J is not to provide correlation at the application level Simon - so could we make the message ID an optional requirement? Anish - There is nothing in WS-Addr that demands the message ID header The WSDL Request/Response pattern does require a message ID header on the request plus a relatesTo header on the response - but here we have a new interaction pattern so we can set the rules for ourselves Eric - what about the namespace being used here? Anish - either we use the common namespace or we have a namespace for the bindings (possibly with a suffix) Simon H: But this is a URI and not a QName - so we can make up what we want here Anish - Q. on the Java TC direction - not clear to Anish as to whether any decision was actually made Simon N argues that there if there is no client API in any SCA language, then it is best to avoid the overhead of a message ID anish: http://www.w3.org/TR/2006/REC-ws-addr-core-20060509/#msgaddrpropsinfoset Simon H: We need to propose that at least some C&I support exists for the use of messageIDs - otherwise it is a useless thing Mike E: I can make a proposal which would make the MessageID optional on the originating client request but that IF it is present, the service side is bound to return it in the callback relatesTo header Dave Booz: +1 TO Mike E anish: we do not want to go into the issue of EPR comparison Martin C : not at all anish: lots of dragons in there Mike Edwards: I agree Anish anish: simonN, don't all you need is a handle to the request message Mike Edwards: +1 Anish anish: ... and depending on which handle you use (app decision) the right EPR/message id gets used by the container Dave Booz: I'm not seeing how a 2nd callback can be present...i'm not seeing how an app ever has a choice of more than one callback the only time this would be the case is if an implementation instance could be concurrently dispatched on multiple threads Dave Booz: i think we already (in java) require composite scope to use an API to get the callback, so the container can provide the right callback info from the request msg which is currently running Simon Holdsworth1: But the request might not currently be running... anish: cookie by definition is opaque Dave Booz: Simon - doesn't matter, when it was it has a context - if it gets suspended, the container has to suspend the context <discussion of the option of using EPR reference parameters> Simon Holdsworth1: My concern is on "In addition, when the service invokes the callback interface, it MUST include a wsa:RelatesTo SOAP header block." - what do we mean by "the service" exactly? Mike Edwards: " the service" here would mean "the service component" Mike Edwards: the wording needs a tweak Simon Holdsworth1: but tge service component does not include SOAP header blocks in anything... Dave Booz: that's a good point, in this case I think service means the app initiates the invoke and the binding impl forms up the message in collaboration Mike Edwards: the point is that the callback is a cookie - and its contents would vary from binding to binidng Simon Holdsworth1: OK, so its the collaboration, so the binding.ws cannot mandate that the message ID can be sent in all cases unless all component implementations guarantee to play ball Mike Edwards: but that cookie must be used by the service component Dave Booz: Simon - no, it's a matter of the component container and binding impl collaborating, the app only initiates the callback Mike Edwards: the requirement is that ANY service component MUST use a callback cookie that it was given by the binding on the outbound requyest Simon Holdsworth1: Sorry - "component implementations " -> component container... Simon Holdsworth1: OK, is that stated anywhere? Mike Edwards: as I said earlier - no, but it needs to be Dave Booz: no it isn't because we don't Mike Edwards: it is the assumption Dave Booz: we don't specify what an SCA runtime looks like. the collaboration we're takling about is something that a runtime vendor has to figure out Simon Holdsworth1: SO otherwise the best we can say is that the callback message SHOULD contain the relatesTo with the original message ID Dave Booz: in order to allow 3rd party binding impls, such a spec would be needed, but we aren't there today Mike Edwards: no - we can say MUST Mike Edwards: it is then up to the SCA runtime to work out how to honour that Dave Booz: +1 to Mike Tom Rutt speaks against reference parameters... Simon Holdsworth1: I'm just concerned that if we only put a MUST here, it places a requirement on all component implementations from binding.ws which is not well called out - that requirement should be made from assembly. Simon is not convinced of the need for the use of the message IDs at this point anish interesting discussion in the chat Dave Booz: Simon - I actually think there are other cases of this....it was true for conversations, might even be true for databindings and operation selection. Runtime vendors are smart, they'll figure it out. Dave Booz: i really dont want to get into specifying the runtime, not in this release anyway COB Yours, Mike. Strategist - Emerging Technologies, SCA & SDO. Co Chair OASIS SCA Assembly TC. IBM Hursley Park, Mail Point 146, Winchester, SO21 2JN, Great Britain. Phone & FAX: +44-1962-818014 Mobile: +44-7802-467431 Email: Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
← Prev in month
← Prev in thread
Next in thread →
Next in month →