Replies in line
Dave
----- Original Message -----
From: "Jeremy Boynes" <[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Tuesday, September 26, 2006 2:20 AM
Subject: Re: Why do we need binding.sca?
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.
"Unspecified" binding doesn't work for me. Something like
"built-in", "system", "fabric", "ESB" gets closer to the concept.
<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.
Agreed. The <binding.sca> concept does that very well, especially when
you don't even need to type it into the XML.
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
No. I'm reading "different SCA runtimes" to mean vendor1 and
vendor2 SCA runtimes. There is no federation of the SCA
System concept across different SCA runtimes. <binding.sca> is
bounded by the SCA system and therefore bounded by a vendor
runtime implementation. I know that SCA system is vaguely defined
in the specs right now. However, my point still holds.
, use of a _default_ binding is insufficient as the platforms hosting the
related components may have different _defaults_ with no guarantee of
interop.
That's precisely the point. <binding.sca> is non-interoperable by
definition, which means that a vendor can provide value add, optimized
capabilty without affecting the portability of the SCDL or the business
service/consumer implementations. If vendor1 and vendor2 want to interop,
their services/reference must choose an interoperable binding. There is no
wire in this case that can express the relationship between the
service/reference because the relationship occurs outside the scope of SCA.
Web services would be my recommendation for an interoperable binding.
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.
Except for the cases that Sebastien noted which lead to the need to
override/remove/change a binding specified lower in the composition
hierarchy. If there is an alternative way to accomplish this, then I
would be very open to hearing it, but the concept
must continue to exist. Don't you think it would be funny to have a
first class concept without an XML serialization?
In any case, when the policy work gets straightened out (there's a draft
spec now) we'll see the need to attach policy to bindings. Attaching policy
to <binding.sca> will be a 1st class concept also. I'd hate to have a
different way to attach policy for the "builtin","system","fabric","ESB"
binding as compared to every other binding in the world.
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
