On Sep 26, 2006, at 6:26 AM, scabooz wrote:
----- Original Message ----- From: "Jeremy Boynes"
<[EMAIL PROTECTED]>
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.
Me neither :-) But then, if we're having problems naming it perhaps
we don't need it ;-)
<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.
I'm confused. <binding.sca> seems like a very different concept to
all other bindings. They all define protocols etc. but <binding.sca>
does not; they allow interaction with non-SCA services, <binding.sca>
does not; they support interop, <binding.sca> does not. They need to
be typed into the XML, <binding.sca> does not.
That a user does not need to type it in get back to my original
question - why do we need it?
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.
Ah - we have a real disconnect here. I agree SCA system is vaguely
defined but what is specified is that it is a logical domain of
control that spans multiple address spaces. It is the domain of
control throughout which SCA concepts (especially wiring) apply. The
assembly model does not constrain this to be a single-vendor, single-
runtime domain. Now individual implementations of SCA may be
constrained to homogeneous or even single address-space
configurations but that should be viewed as a limitation of that
implementation rather than part of the specification. Other
implementations, whether from a single vendor or a federation, can
support the multi-platform distribution of an assembly.
, 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.
I think the different ways we view a system may be relevant here. I
agree that for any connection that goes outside the SCA system then
you need to specify an interoperable binding so can't use
<binding.sca> - it is irrelevant if the other services use SCA or
not, they are a outside our domain of control and SCA concepts do no
apply.
Within a system though things are interoperable by definition. It
does not matter whether they come from a single vendor or a
federation, to the user there is a single domain in which SCA
concepts apply. Within an SCA assembly, a user can specify
connections using wires and the implementation must ensure that the
relationship define by that wire is materialized. How that is
achieved is a function of the implementation(s) and <binding.sca>
does not help here.
As soon as you go to a multi-address space configuration then you are
going to have different _defaults_ associated with <binding.sca> (be
it explicitly specified or not) - I can't think of any implementation
that would not use different protocols for remote vs. in-address-
space invocations.
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.
I think this may be the crux of the matter here. We have known issues
associated with the propagation/overriding of physical binding
definitions in conjunction with composition; we did not have those in
the 0.9 era.
Don't you think it would be funny to have a
first class concept without an XML serialization
We do: <wire>
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've not caught up with the latest spec but I have been assuming that
there would be a way to associate policies with wires for all those
cases where there is no <binding> specified at all (e.g. for wires
within a composite). Wouldn't that support this without the need to
introduce a special binding that is, ironically, different from every
other binding in the world?
--
Jeremy
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
