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.
There's no need to do name mangling on the service side. Multiple
anonymous bindings for a service are illegal.
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.
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.
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.
Simon
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
