[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [sca-bindings] Response to: "Microsoft technical comment: Develop interoperable approach notspecific to SCA for callbacks"
|
Hi all, IMHO SCA is about components, services, an assembly model
allowing to use any implementation technology and communication protocol but
it’s NOT about creating own protocol or protocol extensions. That’s why I think defining an SCA-specific protocol
for callbacks in WS is wrong by its nature. It’s like building huge walls
around the SCA world, preventing interop with the outside! This is especially true for WS binding, which is the
standard solution when it comes to integration. I agree of course that the absence of an WS callback protocol
is an issue we need somehow to find a solution for. It seems to me that there is also no disagreement that
the best solution and the way to go is creation of a new TC, expert group (in OASIS,
W3C, whatever) standardizing a mechanism for callback in WS, covering statefull
as well as stateless communication. I’m also pretty optimistic that
some members of this TC as well as external parties like Microsoft, providers
of WS-Stacks, consumer companies would be willing to participate and to
contribute in this new body. Sooner or later this is going to happen, I’m pretty
sure. The question to me is what to do for the next two years while
such a standard doesn’t exist?! Burning a callback protocol into SCA specs is in my eyes the
worst option we could take. This will stick to SCA and be a hurdle for the
longest time possible. Better option IMO would be to be silent about callback
protocol in the spec and provide separately a document defining WS callbacks for
the time of standard absence. Though this won’t solve the interop
problem, it will allow to switch to the new callback standard ASAP without
waiting for WS Binding 3.0 to change the text of the spec (BTW this option
shouldn’t make proving compliance more complex IMO). The other option of being completely silent on callbacks
will ensure fastest adoption of new standard as soon as it’s out but will
limit compatibility of SCA runtimes in between. Being optimistic that it won’t
take long for a mature draft of the new callback standard to be released, this option
seems also fine to me. Thinking loud another idea just came into my mind: why not
make callback mechanisms configurable through SCA intents and policies? They
proved themselves when it comes to define the protocol details for a service binding
e.g. when it comes to authentication or encryption. By saying callback.sca,
callback.wcf, callback.foo the user can define which callback mechanisms should
be used for a particular service or reference. Not sure whether it’s
feasible, but seems worth to be discussed and who knows maybe we find some more
solutions when starting looking at it from another perspective. Regards, Philipp With best regards, From: Jim Marino
[mailto:jim.marino@gmail.com] On Oct 16, 2009, at 10:31 AM, Patil, Sanjay wrote:
Hi Jim, I have some questions on your following comment: <Jim>Even in the hypothetical case where the SCA approach is
adopted wholesale by other platforms, the namespaces and way of representing
callbacks would need to be changed to fit into a more general approach. If the
current approach is adopted, there is the real potential that an interoperable
approach will be needed later that is incompatible with the former. <Jim> What do we mean by a more general approach here? I thought
that SCA approach is intended to be the more general and standardized approach
and if there are any technical issues in that we should identify and address
them. If the callback functionality from the SCA WS binding specification were
made available in a modular manner so that it can be used independently in a
standalone manner (without requiring the use of the entire SCA WS binding
spec), would that be the solution here? As far as the namespace (for the
callback functionality) is concerned, whether it is defined by a SCA TC or some
other new TC, how does it matter? Namespaces are supposed to be opaque anyways!
Or am I missing something? It has become hard (for me) to sort out the dialogue
in the below email thread. Sanjay Hi Sanjay, The current SCA approach is very specific to SCA as is tied
to the SCA notion of callbacks and not a generic representation of
bidirectional communications. Consequently, it is not interoperable. I don't
think separating out the protocol into a separate *SCA* spec would be the
solution either, since that would not address the fundamental interoperability problem.
The best solution in my opinion would be to remove it from the SCA binding
specification and create another TC whose charter is to define an interoperable
protocol based on WS-* for bidirectional communications. Also, changing the
namespace won't be sufficient since the problem is that the protocol is tied to
the SCA representation of callbacks as opposed to a more generic one that can
be repurposed for other programming models such as WCF and JAX-WS. . Jim |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]