Hi,
This email thread has stopped, but I'll revive it...comments here.
WRT the tables on the wiki, everything looks good except:
-Table 2, row 1, I think the binding should be binding.sca. I don't think
the spec is clear on this and thus there will be disagreement.
-Table 2, row2, I think there is one wire, no multiplicity violation.
-Table 2, row4, ok, but I think you will need a unique name for
each binding.sca.
Dave
----- Original Message -----
From: "Simon Nash" <[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Tuesday, July 17, 2007 5:18 PM
Subject: Re: Normalize the reference endpoints for bindings
Comments inline.
Simon
Jean-Sebastien Delfino wrote:
Comments inline.
Raymond Feng wrote:
Hi,
As captured at
http://cwiki.apache.org/TUSCANYWIKI/multiple-bindings-and-reference-multiplicity.html, a
reference can use "target" attribute or binding uri to declare the
outbound endpoints. Multiplicity and promotion complicate the picture
even more.
I'd like others familiar with the spec to review this table too, but it
looks good to me.
It looks good to me, but I am a bit surprised by the second row of the
promotion table. Why is this invalid and does not override the
lower-level target? I would have expected the override.
I suggest that we internally (for example, in CompositeBuilderImpl)
normalize the reference bindings as illustrated by column 4 of the
tables in the wiki page. Then the runtime can follow the two simple
rules:
Rule #1. Binding with a specified endpoint = a wire
Rule #2. Multiplicity is about the number of wires allowed for the
reference
+1 for normalizing reference bindings as you suggest.
+1 from me too but I would do it in a slightly different way as follows:
In the SCDL:
<reference name="R1" target="C2/S1 C3/S1">
<binding.x/>
</reference>
Normalized:
<reference name="R1">
<binding.x>
<wire uri="C2/S1"/>
<wire uri="C3/S1"/>
</binding.x>
</reference>
Interesting. It's not valid SCDL syntax but I get the jist of the idea.
It might require we add something such as "resolvedEndpoint" to the
Binding interface (leaving the "uri" attribute to host the value from
SCDL). For SCA reference binding, the resolvedEndpoint could be the
Component/ComponentService.
I don't know why the core wiring framework needs to obtain this value.
It needs to know whether or not the binding has a resolved endpoint
because the target attribute would then be invalid, but I don't think
it needs to know the value of the endpoint.
I think we can update the URI attribute in place like we already do for
many other cases where we normalize or "compile" the assembly model.
Having two different attributes would create confusion on how to use
these two attributes and when to set one or the other when you construct
an in-memory model.
I am uncomfortable with this because
1) it may not be possible in all cases to express all the binding
endpoint
information as a single URI string
2) I don't know why this is is needed. I would expect the binding to
be able to manage its own endpoint information in a binding-specific
way (see above)
3) this forces the use of cloned bindings to handle the case of
multiple targets. I don't think bindings should be cloned for
this case (see below).
To handle multiplicity, I think we should clone bindings (one per
target), as opposed to maintaining a list of target endpoints on a
binding.
I'm concerned about this because of the difficulty with naming the cloned
bindings. Each binding on a service or reference must have a unique name.
If the cloned binding has a different name, this violates what was
specified
in the SCDL. If it has the same name, this violates the unique naming
rule.
See my example above for an alternative way of doing the normalization.
Finally, looking at how the SCA binding works now, I propose the
following changes:
- remove or deprecate the component field (which was a hack, it's time to
clean it up)
>
+1
- add a targetBinding field pointing to the SCABinding on the target
service
I'm not sure why this is needed. What is not currently working in the
code that requires this to be added? Would this just be for local
SCABindings, or for remote SCABindings as well?
What do you guys think?
Thanks,
Raymond
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
