A few comments inline :)
[snip]
Mike Edwards wrote:
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"
Yes, as I said earlier in this thread, that's how I'm implementing it. I
think it woulnd't hurt to add some text to the 0.96 spec doc to make
this more clear.
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.
+1, I've started a first implementation option using Axis2C, but it will
be possible to configure other options. We now know how to add --enable
and --with options in out configure scripts, that will help too.
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
Yes, agreed.
Yours, Mike.
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
