On Dec 11, 2007 5:46 PM, Raymond Feng <[EMAIL PROTECTED]> wrote: > 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: <tuscany-dev@ws.apache.org> > 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] > > Hi Raymond.
Thanks for pointing me back to that. I think maybe I'm only coming to appreciate the significance of this by working through this again from the domain point of view. I have to admit that I had forgotten the detail in your matrix. When I looked at the wiki a while ago I didn't cotton on to the fact that the "Normalized/Component Reference" column is actually all that is stored in the assembly model and that the original component reference binding information is not available after each composite has initially been built. >From the domain point of view that's a little inconvenient as it means we would have to rebuild the domain completely each time something changes so that you are starting with a clean slate, i.e. you have access to the original bindings for matching purposes. If I drop a new wire into the domain I can't simply go and match potential references to services as the bindings may no longer be a complete set. Actually it would work the first time but not if I dropped in another wire for the same reference. The wires must be present before the reference is built so the complete set of required bindings can be determined. So this is teasing out two points 1. Lack of original binding list once composites are built. We wouldn't need this if we were to rebuild the whole domain on each change but we would have to change the assembly builders to allow the domainLeveComposite to be built in one go as the original binding list is gone once a composite is built. The code currently doesn't treat includes correctly so it won't work as is. 2. My original point. No generic way to find the target name for a binding. It's difficult to quickly identify the binding that satisfies a particular target so any operations to update bindings in a reference after it's been built are problematic.We could maybe ignore for now the scenario where someone rewires a reference in a domain. However I am currently updating reference bindings to complete endpoint information as I don't know the endpoint information until a composite has been started in a node. Regards Simon
