Jeremy,
We need to bring these threads back together. Mike's comments
further reinforce the concepts.
<snip>
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.
<binding.sca> does define a protocol, the developer nor the assembler
just doesn't know what it is. The rest of your points are correct. It's an
optimization to simplify the binding concept. We're running out of ways
to say the same thing, so I'll refer you back to all the previous emails.
That a user does not need to type it in get back to my original
question - why do we need it?
We need it in the rare cases of overrides, etc.
<snip>
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.
Ok, the spec can be fixed to clarify the concept as I outlined it above.
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.
Agreed.
Other
implementations, whether from a single vendor or a federation, can
support the multi-platform distribution of an assembly.
Agreed.
<snip>
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.
Agreed
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.
I can imagine that 2 vendors got together and decided to allow
SCA System federation across their products. I hope they are sharing
their implementations of <binding.sca>, etc. I don't see what that has
to do with this discussion.
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.
It does help because as Mike said (a point that I forgot to mention)
bindings MUST be honored by the runtime. A _wire_ in a higher level
composite CANNOT ignore the binding specified on lower level services
and references (which must also match). We obviously need to clarify
this point as well.
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.
I am completely missing your point, I think. The <binding.sca>
implementation that lives between two collocated components
is simply an optimization of the implementation that lives between
two remote components. It's not a different binding.
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?
The <wire> element hardly ever exists either.
--
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]
