OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

sca-bindings message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

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

Thanks for your comments. More comments inlined below.


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 

>> 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

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]