Simon,
One of the questions here is whether the representation of the targets
needs to mirror the alternate ways in which a target can be defined by
the SCDL.
For example:
a) The target(s) can be defined by the @target attribute on the
reference. Each target can potentially use any one of the bindings
defined for the reference (which is used depends on the binding(s)
attached to each target service).
b) The target can be defined by the @uri attribute on the binding (or by
equivalent binding-specific data in other attributes or child elements
of the binding). These targets are specific to the binding (and
typically there is only one per declared binding)
While it is reasonable to envision the first type of reference being
attached to the reference, I don't see that it is a good idea to attach
the second type of reference to the reference - the second type are
clearly attached to a particular binding instance. (Consider the case
where a reference has 2 binding.ws bindings attached, each with its own
target defined in the @uri attributes, but where other aspects of the
binding (eg policies) differ between the bindings.
While the target uri's may be technically interchangeable, in reality
they have to be tied to the binding they are declared on - for example,
one target may be within our business and require a low level of
security applid, while a second target may be outside our business and
require a high level of security applied.
How do you think this plays out in the code?
Yours, Mike.
Simon Laws wrote:
When processing references at the domain level I need to know the name of
the target service which each reference binding is associated with so that I
can match the binding with the service name when the service endpoint is
made available or is moved or removed. As a work around I set the binding
name to the target service name in the case that target services cannot be
resolved locally. Not ideal! .
I would like to propose that we add this information into the base binding
model. For example,
public interface Binding extends Base {
Service getTargetService();
void setTargetService(Service service);
The other thing that this could help us sort out is the OptimizableBinding.
This holds target service information. With the changes made to take the
majority of the domain logic out of the SCA binding I could get away with
just knowing the target service.
We do still have to be able to clone bindings (another feature of
OptimizableBinding) in the case where there is more than one target. If I
understand it correctly the assembly model follows what you see in composite
XML, For example,
<component name="SomeComponent">
<implementation.java class="my.ComponentImpl"/>
<reference name="ref" target="TargetService1 TargetService2">
<binding.ws/>
<binding.jsonrpc/>
</reference>
</component>
Leads to a model that looks something like
Component
Reference
Targets
TargetService1
TargetService2
Bindings
binding.ws
binding.jsonrpc
With the obvious fun involved in working out which binding is associated
with which target. If they both want to use the same binding it has to be
cloned. Have I got this right? If so should we make bindings generally
cloneable?
Simon
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
