To ws-callback or not to ws-callback, that is the Q

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

Here is my rationale for separating out SCA ws-callback from the sca 
assembly/binding.ws specs (reiterating what I've already said on the 
call, but thought starting a thread might help):

1) I would like to start by asserting that what we are specifying is a 
WS-splat specification. This is true regardless of whether it is buried 
deep in an SCA spec or not. We are defining a on-the-wire protocol that 
is specific to SOAP/WS-Addressing, and which provides a particular (much 
needed) functionality. Potentially we would also provide a WSDL 
description (metadata) for the bidirectional contract. If you look 
around, that is exactly what most ws-splat specs do. For example, in 
OASIS, we have ws-tx, ws-sx, ws-rx TCs do pretty much the same thing. 
Interestingly, a similar thing happened in WS-RX TC: it started off by 
defining the much needed polling functionality in the context of 
reliable messaging, but realized that the way it was defined, there was 
nothing specific to reliability and spun off a separate spec 
(WS-MakeConnection) so as to make it reusable.
We may not have started off wanting to define yet another ws-splat spec 
(does the world need another one?), but let's call a spade a spade. If 
we don't want to go there, then we should not define this functionality 
at all.

2) Callbacks aren't unique to SCA. Lot of examples of existing 
technologies that do this. Specifically, in WS-land, there is WS-I's 
sample apps, and WS-MessageDelivery. The callback functionality that we 
are discussing is independent of SCA as such. At least, the WSDL 
extensibility proposal in assembly and the implementation of callbacks 
using SOAP, is completely independent of SCA. It is quite possible that 
there are callback usecases not covered by SCA. I'm not suggesting that 
we boil the ocean and create a callback spec that satisfies all possible 
usecases/scenarios. We have a particular need/usecase and our spec 
addresses that. If there are folks out there that have similar usecases 
we should enable the reuse of our spec. If they have a different 
usecase/scenario then of course they cannot use our spec (this won't 
lead to more fragmentation in ws-land, at least no more than if we bury 
this deep in an SCA spec). WS-splat specs are in any cases designed this 
way: addresses specific functionality and are composable within the 
ws-splat stack. Protocol: soap/ws-addressing, description: WSDL, 
metadata: policy and then a variety of specs that target specific 
functionality and are composable with each other.

3) To me this is purely a packaging issue. We won't change anything that 
we specify. This is an issue of by-value v. by-reference. Although, they 
essentially do the same, I would argue that from a perception POV, 
by-reference is much better for reusability, getting the right people to 
pay attention (and therefore feedback) and generally be on the WS-Head's 
radar screen.

4) We should also think about non-SCA clients communicating to services 
deployed using SCA technology. I would very much like the non-SCA 
clients be able to interop with such servers without limiting interop to 
non-bidirectional services.

5) A separate spec would mean more editorial work, but not necessarily 
more review/spec work. Yes, we are indeed overloaded, but such a split 
does have a potential upside. In fact, I would suggest separating the 
WSDL extension (as SCA WS-Callback) from the SOAP binding for SCA 
WS-Callback, a la WS-Addressing Core, WS-Addressing SOAP binding and 
WS-Addressing Metadata. The WSDL extension is at the abstract WSDL and 
provides the portType level contract which can be used with variety of 
bindings. Whereas the SOAP binding of the callbacks is a concrete 
wire-level protocol (nothing to do with WSDL or metadata) and specific 
to SOAP.

Comments?

-Anish
--