Hi, Simon.
We went through a similar discussion before. The result is documented at
http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Multiple+bindings+and+reference+multiplicity.
Can you check if it helps?
Thanks,
Raymond
----- Original Message -----
From: "Simon Laws" <[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Tuesday, December 11, 2007 8:30 AM
Subject: Re: Binding target information
On Dec 11, 2007 3:11 PM, Mike Edwards <[EMAIL PROTECTED]>
wrote:
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]
Two points then some examples...
1) There are other cases also as the target could be specified using
autowire or wireByImpl.
2) The runtime code is interesting at the moment in as much as the service
resolution process gives rise to the reference binding list from the input
composite being replaced by a list of bindings that represent resolved
connections to target services.
A)
<component name="SomeComponent">
<implementation.java class="my.ComponentImpl"/>
<reference name="ref" target="TargetService1 TargetService2">
<binding.ws/>
<binding.jsonrpc/>
</reference>
</component>
may give rise to
reference
targets
TargetService1
TargetService2
bindings
binding.ws
uri="http://localhost:8080/TargetService1";<http://binding.ws/>
binding.ws
uri="http://localhost:8080/TargetService2";<http://binding.ws/>
This is where the effect is slightly odd. The result is right but we loose
the original list of bindings from the reference.
B)
<component name="SomeComponent">
<implementation.java class="my.ComponentImpl"/>
<reference name="ref">
<binding.ws uri="TargetService1"/ <http://binding.ws/>>
<binding.jsonrpc uri="TargetService2"/>
</reference>
</component>
may give rise to
reference
targets
? not sure if targets should be here
bindings
binding.ws
uri="http://localhost:8080/TargetService1";<http://binding.ws/>
binding.jsonrpc
uri="http://localhost:8080/TargetService2";<http://binding.ws/>
But I can't see that the code does this at the moment although I haven't
actually tried it to prove that it doesn't work.
C)
<component name="SomeComponent">
<implementation.java class="my.ComponentImpl"/>
<reference name="ref" >
<binding.ws
uri="http://localhost:8080/TargetService1";<http://binding.ws/>
/ <http://binding.ws/>>
</reference>
</component>
may give rise to
reference
targets
bindings
binding.ws
uri="http://localhost:8080/TargetService1";<http://binding.ws/>
D)
<component name="SomeComponent">
<implementation.java class="my.ComponentImpl"/>
<reference name="ref" target="TargetService1 TargetService2">
<binding.ws uri="TargetService3"/ <http://binding.ws/>>
<binding.jsonrpc uri="TargetService4"/>
</reference>
</component>
This may give rise to the runtime model
reference
targets
TargetService1
TargetService2
bindings
binding.ws
uri="http://localhost:8080/TargetService1";<http://binding.ws/>
binding.ws
uri="http://localhost:8080/TargetService2";<http://binding.ws/>
E)
<component name="SomeComponent" autowire="true">
<implementation.java class="my.ComponentImpl"/>
<reference name="ref" >
<binding.ws/>
<binding.jsonrpc/>
</reference>
</component>
may give rise to
reference
targets
? would be handy to know the autowired target names
bindings
binding.ws
uri="http://localhost:8080/TargetService1";<http://binding.ws/>
binding.ws
uri="http://localhost:8080/TargetService2";<http://binding.ws/>
I don't know what happens with wire by impl but again it would seem useful
if the target list included the names of services from the sca domain that
have been wired.
So not sure if this answers your question.
Regards
Simon
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
