Folks,
I'm not sure that adding more comments inline is going to help clarity,
so I'll try to make my points standalone here:
1) My view is that binding.sca was intended to imply "the binding that
the SCA runtime system will use if you specify no other specific binding"
- implying that a detailed choice will be made by the runtime
- implying that you the assembler/developer don't really care - all you
want is that references should connect to the target services in some
way that works
2) I agree with Jeremy's point that in many cases, you don't need to
explicitly specify <binding.sca/> in your compositions - since it's the
default, you "get it for free"
3) HOWEVER, if I specify <binding.ws/> or some other specific binding on
a component, that does mean "the runtime must use the ws binding for
this service / reference" and the runtime is NOT allowed to choose any
other binding. This allows developers/assemblers to be specific about
the protocols they want to use, if they so wish.
4) Given the potential to reuse/override implementations in components
in a composite, I MAY find myself with an implementation that declares
itself to use (say) <binding.ws/> that I wish to use in a context where
I don't want to use the ws binding. In this case, I should be able to
override the binding specified on the implementation. This could be
with <binding.jms/> say - but it could also be with <binding.sca/>. The
latter case is useful where I want to say "use the system binding for
this one", especially to ensure that wires will work properly for that
component.
Wires may be a contract - but whether they are valid is another matter.
A wire can be drawn between incompatible endpoints - in that case the
Wire is invalid and an error gets raised. Compatible bindings on each
end is one requirement, amongst a host of others (eg interfaces must be
compatible, policy sets must be compatible)
5) I agree with Jeremy's sentiment that it would be a good idea for an
SCA runtime to allow configuration of which protocol would get used for
its binding.sca.
6) binding.sca is clearly of no use for services or references which
address things external to the SCA System.
To sum up:
- I think that binding.sca has a place, it has some uses
- We should be flexible about which protocol get used for binding.sca
Yours, Mike.
scabooz wrote:
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
