Sebastien did a good job enumerating the rationale for why the <binding.sca>
exists in the specifications. Perhaps your concern is over the name of the
binding, and not the specific reason for its existence? I could be
convinced that "default" is a bad name, but we'd need a suggestion for
an improvement.
<binding.sca> differs from a wire in the fact that a wire only denotes
a relationship between two components. A binding specifies the message
format/transport-protocol to be used when the given components interact. A
wire is only valid if both ends of the wire are using the same (or
compatible)
binding. The definition of compatible is under construction at the moment.
When two components are related via a reference-value or via a wire, the
<binding.sca> capability (I'm trying hard not to say default binding) is
automatically
associated with the relationship. IMHO, the <binding.sca> element need not
be
specified.
I would expect that the vast majority of SCA services will be wired and
composed using the _default_ binding, without explicitly stating it.
There are several known issues in the Assembly spec that relate to the
_default_ binding, especially in the context of recursive composition, and
with binding overrides in general. Proposals are being discussed.
Dave Booz
----- Original Message -----
From: "Jeremy Boynes" <[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Monday, September 25, 2006 2:44 AM
Subject: Re: Why do we need binding.sca?
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
