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

Comments inline.


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

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

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


> 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

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