Hi
Some questions inline
Simon
On Dec 17, 2007 4:54 PM, Simon Nash <[EMAIL PROTECTED]> wrote:
> See comments inline.
>
> Simon
>
> Simon Laws 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.
> >
> For bindings specified in SCDL, this is correct. From section 1.7 in
> the Assembly spec:
> 2319 name (optional) – a name for the binding instance (a QName). The name
> attribute
> 2320 allows distinction between multiple binding elements on a single
> service or reference. The
> 2321 default value of the name attribute is the service or reference name.
> When a service or
> 2322 reference has multiple bindings, only one can have the default value;
> all others must have
> 2323 a value specified that is unique within the service or reference. The
> name also permits the
> 2324 binding instance to be referenced from elsewhere – particularly
> useful for some types of
> 2325 binding, which can be declared in a definitions document as a
> template and referenced
> 2326 from other binding instances, simplifying the definition of more
> complex binding instances
> 2327 (see the JMS Binding specification [11] for examples of this
> referencing).
>
> So having more than one anonymous binding on a single service or
> reference is not allowed and should be flagged as an error. I have
> opened TUSCANY-1937 for this.
>
> For "resolved bindings" that are generated by the Tuscany runtime in
> the case of multiple reference targets for the same binding, there are
> some cases where the generated binding names won't be unique unless a
> name mangling convention is used, as discussed below.
>
> IMO, the need to create mangled names for resolved bindings is a
> further reason why resolved bindings should be held elsewhere in the
> model than the bindings specified in SCDL.
I agree but others didn't seem to like the idea of keeping both the original
bindings and the resolved bindings.
>
>
> There's no need to do name mangling on the service side. Multiple
> anonymous bindings for a service are illegal.
So there is an element of interpretation of lines 2322-2323 here which is
where we differ.
2322 reference has multiple bindings, only one can have the default value;
all others must have
2323 a value specified that is unique within the service or reference. The
name also permits the
I interpreted "must have a value specified" to mean that the binding must
end up with a unique value while from reading your response you have
interpreted is as "must have a value specified BY THE USER". On reflection
you are probably right and it certainly makes more sense in the case of
identifying binding artifacts once they have been contributed. Although if a
user were to ask for some information for a binding given a name they
provided originally they may get information for more than one resolved
binding as per the discussion below.
>
>
> > 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.
> >>>
> This code has been commented out. Its intention was to allow the
> SCDL author to control the selection for a callback binding based
> on the forward binding being used. If there is a name match, this
> is given the highest priority in the selection algorithm.
I don't see that this has been commented out in SVN. It's still running when
I debug through the CompositeActivator
>
>
> >>>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.
> >>>
> This code has replaced (for now) the commented out code from
> CompositeActivatorImpl and has the same purpose. For example, for
> the SCDL
>
> <component name="MyServiceComponent">
> <implementation.java class="myserver.MyServiceImpl" />
>
> <service name="MyService">
> <interface.java interface="myserver.MyService"
> callbackInterface="myserver.MyServiceCallback" />
> <binding.xy name="first" />
> <binding.ab name="second" />
> <callback>
> <binding.xyz name="first" />
> <binding.abc name="second" />
> </callback>
> </service>
> </component>
>
> calls made to the service using binding.xy will get a callback
> binding of binding.xyz, and calls made to the service using
> binding.ab will get a callback binding of binding.abc.
Thanks for the explanation
>
>
> >>>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.
> >
> Do we have a use case where the name of the resolved binding for
> the reference side is significant? The example I gave was for the
> service side only. If we have a use case, it would be easier to say
> whether using names or numbers is better. However, the argument
> that numbers are symmetric with the service side doesn't apply, as
> it's illegal to have multiple anonymous bindings on the service side.
Re. symmetry - see previous comment about different interpretation of the
spec words.
The example that initiated the original question was about updating
reference information as service information changes. However having done
some work on this it's tricky to get this right given the code we have at
the moment so this is probably not a strong motivating scenario. Regardless,
if we have the opportunity to generate a binding name it would seem sensible
to make it as debuggable as possible and ref#TargetServiceA seems more
useful in this respect that ref#1 to me.
>
>
> Simon
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
