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
