On Sep 25, 2006, at 6:47 PM, scabooz wrote:
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.
It wasn't really but now that you mention it default does tend to
imply a well-known value. I would be concerned users may assume a
specific protocol will always be the default (e.g. the original
proposal on this thread about making WS the default for the C++
runtime) whereas the goal of the spec is to allow the container to
choose which protocol it considers optimal. The semantic is
"unspecified" rather than "default" but that is not a good description.
<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.
"Only"? I think a wire is more emphatic than that - it /defines/ a
relationship between two components. As you say, a binding specifies
the message format/transport protocol which is essential for non-SCA
interactions but which is also the very thing we are trying to
abstract away in the assembly model for SCA-to-SCA relationships.
Validity is also true for <binding.sca> but unlike a wire a binding
is only attached to one party in the relationship making
compatibility and validity harder to achieve. With the ability to
decompose a composite to different address spaces potentially
implemented by different SCA runtimes, use of a _default_ binding is
insufficient as the platforms hosting the related components may have
different _defaults_ with no guarantee of interop. However, the
presence of a wire in the assembly is a clear contract that the SCA
system must obey or default on [sorry, couldn't resist]
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 agree - in fact I would go further and say that <binding.sca> need /
never/ be specified, making it a redundant concept that could be
removed from the spec.
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.
--
Jeremy
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
