Comments inline.
Simon
Simon Laws wrote:
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.
I saw a post from Sebastien saying this, to which I have just responded.
I also saw posts from others who did think the original information
should be available. As we explore this further, I think we are seeing
more reasons (like error reporting) for why it's desirable to retain the
original information.
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.
When I see the word "specified", I interpret this as meaning "specified
by the user" unless there's some indication that a different meaning
should apply. In this case, I believe it's referring to a name specified
using the "name" attribute of the <binding> element.
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
I was referring to CompositeActivatorImpl.java line 289. I had another look
at this file and I believe you're referring to similar code in line 349. My
apologies for the confusion.
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/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.
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.
Thanks, this helps me understand how the name would be used. I agree that
if there are problems with the binding and its name appears in an error
message, the ref#TargetServiceA form is more user-friendly.
Simon
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
