| [Thread Prev]
| [Thread Next]
| [Date Next]
| [Thread Index]
| [List Home]
Subject: Re: [sca-bindings] Response to: "Microsoft technical comment: Developinteroperable approach notspecific to SCA for callbacks"
- From: Mike Edwards <email@example.com>
- To: OASIS Bindings <firstname.lastname@example.org>
- Date: Tue, 13 Oct 2009 14:52:05 +0100
Thanks to Jim for these comments - they
help the debate here.
I've put comments inline as:
Strategist - Emerging Technologies, SCA & SDO.
Co Chair OASIS SCA Assembly TC.
IBM Hursley Park, Mail Point 146, Winchester, SO21 2JN, Great Britain.
Phone & FAX: +44-1962-818014 Mobile: +44-7802-467431
||Jim Marino <email@example.com>
||OASIS Bindings <firstname.lastname@example.org>
||Re: [sca-bindings] Re: [sca-bindings-comment]
Response to: "Microsoft technical comment: Develop interoperable approach
notspecific to SCA for callbacks"|
On Oct 7, 2009, at 7:42 PM, Eric Johnson wrote:
Here are my immediate thoughts, in response,
for the TC's consumption:
Michael Champion wrote:
Thank you for considering Microsoft's suggestion
for improving the SCA Web Services Binding spec's interoperability (http://www.osoa.org/jira/browse/BINDINGS-87).
We suggested that Web Services callbacks
in the SCA Web Services Binging spec should interoperate with comparable
frameworks such as JAX-WS and WCF, and not be limited to various implementations
of SCA. This would promote the original goals of the Web Services
standards to achieve wire-level interoperability among diverse run-times
I'm unaware of anything in JAX-WS that addresses
callbacks, so I don't understand that point, or how it is comparable. Nor
am I aware of anything that we've specified that prevents a vendor from
using JAX-WS to implement callbacks support within the SCA environment.
Presumably implementation experience will reveal details here?
I have run into a number of difficulties trying to integrate
SCA callbacks with WCF services (specifically, duplex services, see next
comment) for a client. Basically, the way SCA represents callbacks at the
protocol level (in WSDL and on the wire) is not interoperable with WCF.
The only way to make these types of interactions work is to introduce proprietary
behavior in an SCA runtime to support WCF's protocols.
So, Jim, do you want to make it an objective
that the SCA Web service binding should be capable of interoperating with
the WCF callback protocol?
Separately, do you want to make the SCA Web
services callback protocol the same as the WCF callback protocol?
A separate question: is the WCF callback
protocol standardized in any way?
With respect to WCF, I'm not aware of its
capabilities, and whether or not it provides anything equivalent to the
callback functionality of SCA. Does anyone else on the TC have insight
The analog of SCA callbacks in WCF is duplex services,
which provide bidirectional communication. One difference between WCF duplex
services and SCA callbacks are the former are stateful. That is, the WCF
client instance originating the forward call will receive callbacks. Prior
to the deferral of conversational services, SCA conversational callbacks
could be used to model this functionality.
As far as SCA interoperation is concerned,
I forsee 2 cases of interest:
a) WCF client talking to an SCA service which
has a callback
b) SCA client talking to a WCF service with
a) could be remodelled in WCF as a stateless
client that offers a service which is has the callback interface of the
- this clearly is not the same as current
WCF callbacks, but it is a potential practical approach
b) gives the problem that the WCF service
may have a business interface that makes the assumption that there is out-of-band
data that ties the callback messages to a
given forward message. This is indeed tricky to deal with.
At the protocol level, duplex services (which use the
WCF duplex binding) rely on WS-RM and sequence ids for correlation. In
WSDL, WCF represents duplex services as a a form of solicit-response with
an output/input sequence.
For SCA at the binding level, in principle
this could be handled by a particular policy specification which would
mandate the use of WS-RM etc.
This does not solve the statefulness problem
of b) above
At the wire level, what we've describe remains
interoperable and compatible. Seems to me like the actual issue is
at the protocol level.
At the wire level, things as they currently stand are
not strictly interoperable because SCA callbacks are stateless and WCF
duplex services are stateful.
The SCA Binding TC responded by saying
that the SCA Web Services binding protocol "defines an *SCA* Web service
callback protocol standard” and that it "is not meant to satisfy
general purpose callback requirements with a broadest scope possible".
In other works, the TC believes that the SCA Web Services callbacks will
NOT be interoperable with non-SCA implementations
That sounds incorrect to me. Seems like it is completely out of scope
for an SCA TC to dictate how or if any standard outside of SCA reaches
compatibility with something inside of SCA. Nothing prevents other
implementations (Mike Champion's word choice) from achieving interoperability.
The TC's response goes on to say that "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." We respectfully find
this statement contradictory, unless the TC defines the term "interoperability"
in its narrowest form: SCA implementations will only be interoperable amongst
themselves, and not with other frameworks and runtimes. We would find this
unfortunate, as OASIS is committed to broad interoperability, especially
when it comes to use of Web Service wire protocols. It would be better
to standardize a Web Services callback in a separate spec, with the participation
of all vendors who build platforms and products that support Web Services
Yes, we define interoperability amongst SCA runtimes (including from different
vendors), since that's within the scope of our charter. The "narrowest"
sense would be only interoperability among a single vendor (see JMS itself,
the "binding.sca" binding, and various Microsoft networking protocols,
at some point in time.). So I disagree with the characterization
of this as the "narrowest" possible form of interoperability.
Further, we don't deny the utility of a broad specification, and
yes, we believe interoperability at a larger scale would be useful. It
just isn't in our charter.
Is Microsoft explicitly requesting a change in charter? If so, they
should explicitly state that.
It is clear from  that the TC
is aware that interoperability with non-SCA runtimes is an issue. The TC
discussed the idea of moving the callback portion of the protocol into
its own document in order to address "the use case of non-SCA clients
does walk into the more general territory alluded to by MS." We highly
recommend that the Binding and Assembly TCs work together to design a Web
Services Binding spec that is interoperable with non-SCA technologies.
Without interoperability, software developers and users will find
it difficult to use SCA in the heterogeneous, multi-vendor environments
that all our customers live in.
Absolutely nothing here prevents vendors from building compatible systems
with both SCA and non-SCA parts that interact. In fact, we expect
it. Further, when bridging from a non-SCA environment to an SCA environment,
a vendor such as Microsoft should only have to implement compatibility
with the SCA WS Callbacks mechanism once, and it should work with all vendors
providing SCA environments. If they believe this last point is incorrect,
it would be enormously useful for Microsoft to identify the specific oversights
of the currently specified approach.
These last statements seem a bit odd. I thought one of
the purposes of the web services binding was to provide interoperability
into and out of a domain. For example, I think the requirement to
integrate with WCF and non-SCA software will be much more common than integration
between different SCA vendor runtimes. Of course, other systems could integrate
with SCA by implementing support for proprietary SCA protocols but that
kind of defeats the purpose of interoperability (a general integration
It seems that Microsoft is proposing the SCA TCs not define
a callback mechanism and instead work jointly in some other TC to define
an interoperable protocol for bidirectional communication. If this is the
case, such an approach would provide a lot more value to end-users than
a proprietary SCA mechanism since it would allow SCA, WCF, JAX-WS, etc.
to interoperate at a much deeper level. Maybe this is something we should
ask Microsoft if they would be interested in pursuing?
1) Are you proposing that we should remove
the current SCA callback description from the specification?
2) I suspect that if we went down the road
of standardizing a generalized callback mechanism in some new TC, that
it would take quite some time to complete.
Are you happy for there to be no defined
way of providing SCA callbacks over Web services for a significant amount
of time - with the probable consequence
of vendors building SCA runtimes simply each
implementing their own way of doing things in the interim?
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6
| [Thread Prev]
| [Thread Next]
| [Date Next]
| [Thread Index]
| [List Home]