BINDINGS-97: Draft of suggested response

[Anish Karmarkar <Anish.Karmarkar@oracle.com>]

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