[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: BINDINGS-97: Draft of suggested response
Thanks for taking the time to review the specification, sending your public review comment [1], and for sharing you thoughts. They are much appreciated. The public review comment at [1] suggests that: "... the work of defining a Web Service callback standard is best done by the appropriate Web Services working groups in OASIS in the broadest scope possible. This will foster a general interoperable mechanism for all architectures and programming models that use standard Web Services protocols on the wire." There is a misunderstanding on the commenter's part that the SCA Web Services Binding defines a (generally applicable) "Web Service callback standard." The binding defines an *SCA* Web service callback protocol standard that provides the wire-level details for implementing an SCA callback defined by the SCA Assembly specification [2]. [2] defines a callback mechanism that satisfies the needs of the SCA Assembly model and is not meant to satisfy general purpose callback requirements with a broadest scope possible. Furthermore, there does not exist any other OASIS Web Services Working Group or a Technical Committee that specializes in Web Services that has callbacks in its charter scope. This TC *does* specialize in Web services and is chartered to produce a Web services binding for SCA. This TC does believe that it should define an interoperable Web services protocol that implements SCA callback and it has done that. It does not believe that it is in the scope or interest of this TC to define a callback protocol for all architectures and programming models. WRT your comment about SCA Assembly specification Section 7.4, we respectfully request you to share that feedback with the SCA Assembly TC [3], as the SCA Assembly specification is not owned by and is not in scope for this TC. <broken-record> The part below is something I have said before (a few times). I don't think we necessarily need to resolve this before we respond to the commenter, but it would be nice. I do believe that we need to separate out the protocol bit in a separate specification to allow non-SCA clients to interoperate with SCA services. Currently, the protocol is buried deep in an SCA spec and the conformance criteria is not defined. We should follow the Web services extension and composability model wrt specifications, and define a separate spec that can be used with other Web services specs such as WS-Coordination, WS-ReliableMessage, WS-Security, WS-Trust and so on. Having been involved in a variety of WS specs and interop efforts, I can say that WS interoperability is hard. Trying to read/implement/test just one section buried deep in an spec is hard. And when the conformance criteria is not defined, it is not clear what the implementer has to do. Such a refactoring will change nothing wrt what a SCA runtime must or must not do, but it will go a long way in making interop with SCA services that use SCA WS binding easier. </broken-record> We do agree with that part of your comment that encourages interoperability. To that end, we have separated out the SCA Web services callback protocol into a separate specification to allow non-SCA clients to implement and and interoperate with SCA services that use the SCA Web services binding. This new separate specification clearly calls out the conformance criteria for implementing the protocol, which we hope will serve interoperability. Comments? -Anish -- [1] http://lists.oasis-open.org/archives/sca-bindings-comment/200908/msg00000.html [2] http://docs.oasis-open.org/opencsa/sca-assembly/sca-assembly-1.1-spec-cd03.pdf [3] http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=sca-assembly
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]