Re: [sca-bindings] To ws-callback or not to ws-callback, that isthe Q

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

Thanks for your comments. More comments inlined below.

-Anish
--

Simon Nash wrote:
> Comments inline.
> 
>   Simon
> 
> Anish Karmarkar wrote:
>> 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.
>>
> I think we should try to satisfy the SCA use case without defining a
> new WS-splat spec.

But we *are* creating a WS-Splat spec whether we give it some 
ws-whizbang name or not.

>  If we were to remove per-message correlation, I think
> the proposal would become much simpler.  Perhaps it would merely describe
> a convention for using WS-Addressing to pass a callback endpoint.  This
> would not justify creating a new WS-splat spec.

This is more than a convention. It is a specification for a callback 
protocol and associated metadata.

> 
>> 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.
>>
> This sounds reasonable, if what we create has enough substance and
> invention to be useful to other folks who aren't SCA users.  Bearing
> in mind my comment above, I suspect that if we confine ourselves to
> the minimum needed for the SCA use case, we won't create enough
> substance in this first stage to be more generally useful.  This
> discussion could be revisited when we have a clearer idea what is
> the minimum needed to satisfy the SCA use case.
> 
>> 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.
>>
> See my comments above.  This point only has weight if the spec has
> enough substance to attract more widespread reuse.
> 

I don't think whether it has "enough" substance and invention really is 
an issue. The issue is whether we think this is a mechanism that other 
may find useful and whether we want to enable that / make it easy. It is 
also an issue of whether we want this to be adopted by non-SCA clients 
that communicate with SCA deployed services.
In the ws-* world, there are a lot of small things that are needed but 
there is no standard and everyone comes up with a proprietary way of 
doing things, hampering interop. I would argue that interop is *the* key 
to web services, without that it loses most of its value. The more we 
make things re-usable (as long as they are composable) the better off we 
are.

>> 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.
>>
> +1.  Whatever we do about the spec packaging, we need to enable this.
> 
>> 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.
>>
> I don't think we have the time and bandwidth to take on the creation of
> these extra specs within the SCA 1.1 timescales.
> 

Is that wrt the TC's time or editorial work load. I.e., if someone were 
to put in the time to create this, would that help?

>   Simon
> 
>> Comments?
>>
>> -Anish
>> -- 
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe from this mail list, you must leave the OASIS TC that
>> generates this mail.  Follow this link to all your TCs in OASIS at:
>> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>>
>>
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  Follow this link to all your TCs in OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php