On Sep 24, 2006, at 9:32 PM, Jean-Sebastien Delfino wrote:
My understanding is that the SCA default binding is there to handle
the communication with another SCA service without requiring the
application developer to explicitly choose and configure a WS, EIS,
JMS, or whatever other binding.
How does that differ from a wire?
The spec also says that the default binding is not intended to be
interoperable. This gives flexibility to runtimes to implement that
binding in the most efficient way in the context of a given
assembly. I'm currently implementing the Tuscany C++ default
binding on top of Axis2C but in the future we may want to implement
more optimized variants (start to turn on the SOAP MTOM - Message
Transmission Optimization Mechanism for example, or use a
completely different protocol like Jim suggested earlier).
The lack of interop here is one of the reasons that I think this is
problematic. We can't interop with non-SCA services as to do that we
need to know the protocol etc. they use - IOW we need a specific
binding like WS. We can't interop with other SCA systems unless they
happen to use the same default; SCA is designed for large-scale
heterogeneous systems and they are not likely to use the same default
and so to interop between them the user will either need to specify a
wire (if they are centrally administered) or use a physical binding
as if the other side was a non-SCA one.
I don't see how a default binding is useful - a user will either be
decoupled and use physical bindings, or they will have a SCA system
that would use wires.
Whether or not a <binding.sca> element must be present to tell the
runtime that the default binding is used on a composite service or
composite reference is debatable. The implementation I'm working on
does not require you to specify the <binding.sca> element, but I
need a little more work through some scenarios and double check one
more time with the spec documents to make sure that this is right.
It also obviously supports the <binding.sca> element if it is present.
I can see several use cases for the <binding.sca> element:
- When you want to specify a target service for your reference
directly in your composite, right in the reference definition (as
opposed to a wire which will only work from an outer composite).
See section 1.4.2 of the spec for the details.
I think this is a problematic scenario now that we have the recursive
model. This may have made sense with the old module concept but by
embedding address information in a composite you prevent its reuse.
One of the main objectives of the composite change was to allow that
by treating composites as types rather than instances and as such
they should not have such instance-related information.
There is a case for absolute references to non-SCA resources but
those would be associated with real bindings to those services (e.g.
via WS or JMS). Within the SCA domain though the connection should be
done with wires and so there is no need for a non-interoperable binding.
- When you want to override the binding specified on a composite
reference or composite service, for example a WS binding, and
request the default binding to be used instead for a particular
component (because it's optimized for example).
Why would someone use a non-interoperable default binding for that
when they can override with a wire? The SCA system can do more
optimization with a wire where it has information on both ends than
it can with a binding where it only knows one side.
- When you want to specify that a service should be available
through the WS, JMS and the default binding for example, then
you'll explicitly specify the three bindings on your service.
What does it mean to make a service available through the default
binding? It can't be used to talk to non-SCA services or with other
SCA implementations and within a single SCA domain the service is
there to be wired.
I would actually be very concerned if by adding a <binding.sca>
element to a service users were able to bypass the wiring and
connection model of the assembly spec and break the encapsulation a
composite is meant to provide.
There's probably more use cases, but I hope this helps. Maybe other
spec people can also give us their perspective on this?
Thanks for providing them and I think it helps discussion. I haven't
seen though that there is anything so far can cannot be addressed
through the SCA wiring model or through physical bindings when
interop is required. I would suggest we are better off keeping the
model consistent and so should consider dropping the concepts of
default binding and <binding.sca> entirely.
--
Jeremy
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
