On Dec 17, 2007 2:02 PM, Simon Laws <[EMAIL PROTECTED]> wrote:

>
>
> On Dec 17, 2007 1:42 PM, Mike Edwards <[EMAIL PROTECTED]>
> wrote:
>
> > Simon,
> >
> > One comment inline.
> >
> > Yours,  Mike.
> >
> > Simon Laws wrote:
> > > Following on from the thread about identifying binding targets [1] the
> > SCA
> > > assembly specification (lines 2319-2327) describes a binding name as
> > being
> > > unique within a reference or service. If a binding name is not
> > specified in
> > > the SCDL this is not the case currently. I.e the each binding adopts
> > the
> > > name of the reference or service to which it belongs. This makes
> > > identification of an individual binding difficult, for example, if you
> > > wanted to retrieve the details of an individual binding artifact from
> > the
> > > live model. In the particular case where a default is chosen for a
> > binding
> > > name (as opposed to a name having been specified) how about we do the
> > > following:
> > >
> > > References - Append the name of the target service to the end of the
> > > reference name to form the binding name
> > > Services - Append a number to the end of the binding name based on the
> > > position of the binding name in the bindings list.
> > >
> >
> > Why treat references differently to services?  Why not use the idea of
> > appending a number in both cases?  What about the case where the same
> > binding on a reference gets used for more than one target service?
> >
> > > There are a couple of places that use the binding name that could do
> > with a
> > > little explanation if anyone knows the details.
> > >
> > > CompositeActivator.addReferenceWire()
> > >
> > >             for (Binding binding : callbackService.getBindings()) {
> > >                 // first look for a callback binding whose name
> > matches the
> > > reference binding name
> > >                 if (binding.getName().equals(refBinding.getName())) {
> > >                     callbackBinding = binding;
> > >                     break;
> > >                 }
> > >             }
> > >
> > > Not sure why this is checking that the callback binding name matches
> > the
> > > reference binding name before choosing a binding.Under what
> > circumstances
> > > will these names either match or not match.
> > >
> > > There is also something similar going on in
> > > CallbackReferenceImpl.selectCallbackWire()
> > >
> > >         // no exact match, so find callback binding with same name as
> > > service binding
> > >         EndpointReference to = msgContext.getTo();
> > >         if (to == null) {
> > >             //FIXME: need better exception
> > >             throw new RuntimeException("Destination for forward call
> > is not
> > > available");
> > >         }
> > >         for (RuntimeWire wire : wires) {
> > >             if (wire.getSource().getBinding().getName().equals(
> > to.getBinding().getName()))
> > > {
> > >                 //FIXME: need better way to represent dynamic wire
> > >                 if (wire.getTarget().getURI().equals("/")) { //
> > dynamic wire
> > >                     //FIXME: avoid doing this for genuine dynamic
> > wires
> > >                     return cloneAndBind(msgContext, wire);
> > >                 }
> > >                 //FIXME: no dynamic wire, so should attempt to create
> > a
> > > static wire
> > >             }
> > >         }
> > >
> > > Again it's filtering bindings based on binding name but it's not clear
> > what
> > > the circumstances are where this match will be successful.
> > >
> > > Regards
> > >
> > > Simon
> > >
> > > [1]
> > http://www.mail-archive.com/[email protected]/msg26380.html
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> > Hi Mike, as per the referenced thread, the Tuscany SCA runtime resolves
> all of the bindings to targets so is slightly optimized when compared with
> what you would see in the .composite file. So, for example, if you had the
> component...
>
>     <component name="SomeComponent">
>         <implementation.java class="my.ComponentImpl"/>
>         <reference name="ref" target="TargetService1 TargetService2">
>            <binding.ws/>
>            <binding.jsonrpc/>
>         </reference>
>     </component>
>
> Then you would end up with the following represented in the runtime currently
>
>
>   Component
>      Reference
>          Targets
>              TargetServiceA
>              TargetServiceB
>          Bindings
>               binding.ws
>                   name - ref
>               binding.ws
>                   name -= ref
>
> If we append target service names it could be something like
>
>   Component
>      Reference
>          Targets
>              TargetServiceA
>              TargetServiceB
>          Bindings
>               binding.ws
>                   name - ref#TargetServiceA
>               binding.ws
>                   name -= ref#TargetServiceB
>
>
> If we go with numbers
>
>   Component
>      Reference
>          Targets
>              TargetServiceA
>              TargetServiceB
>          Bindings
>               binding.ws
>                   name - ref#1
>
> binding.ws
>                   name -= ref#2
>
> Numbers would certainly work and give a nice symmetry with service but, as
> is currently the case, you don't know what the reference is for. You might
> get a hint from the URI but you might not.
>
> Regards
>
> Simon
>
My last sentence in the previous post should have read

"Numbers would certainly work and give a nice symmetry with service but, as
is currently the case, you don't know what the binding is for. You might get
a hint from the URI but you might not."

I used the word reference when I meant binding.

Simon

Reply via email to