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/tuscany-dev@ws.apache.org/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

Reply via email to