Thoughts and comments inline.
Raymond Feng wrote:
Hi, Simon.
Nice summary:-). I was about to drop a note but you are ahead of me.
The code is still evolving and the WireableWiring is gone (with some
methods merged into SCABinding).
Please see my comments inline.
Thanks,
Raymond
----- Original Message ----- From: "Simon Nash" <[EMAIL PROTECTED]>
To: <tuscany-dev@ws.apache.org>
Sent: Thursday, July 19, 2007 3:35 AM
Subject: WireableBinding questions
I have some questions about the new interface WireableBinding that was
checked in as part of revision r557195.
1. Is it intended that all bindings should (eventually) implement this
interface, or only some of them? If only some of them, what's the
guideline for which bindings should implement it and which should
not?
If bindings want to be provided with pointers to a target
component/service/binding, they implement WireableBinding.
2. For bindings that don't (yet) implement it (i.e., all the current
extension bindings), what are the limitations on what can be done
with these bindings?
The WireableBinding interface is now gone.
Sorry, I think we should keep it :) the limitation for bindings that do
not implement WireableBinding is that they are not provided with
pointers to the target component/service/binding. Most bindings don't
care about these as they are simply using the endpoint information that
they are configured with.
3. This interface introduces three new getter/setter properties:
TargetComponent
TargetComponentService
TargetBinding
How are these set/used for reference bindings by the core wiring
framework? And how are they set/used for service bindings?
These methods are now in SCABinding. They are used to create local
wires for SCA bindings. The target is set when a reference SCABinding
is resolved to be wired to a target component service.
This is a staged approach. Ideally, we should be able to use the URI
(componentName/serviceName) to represent the endpoint reference which
can materialized locally if the target exists.
I think it's better to keep WireableBinding like you had yesterday, and
not tie it to SCABinding. This way:
- whatever binding needs pointers to the target can implement it
- implementations of the SCABinding interface do not have to if they
don't need that info.
In other words, support WireableBinding in the core runtime, but
SCABinding does not extend it. A particular SCABindingImpl can decide to
implement WireableBinding or not (e.g a remote-only distributed
SCABinding may not need to, on the other hand an SCABinding that wants
to optimize local calls may want to implement WireableBinding).
4. The core wiring framework is now calling getURI() as part of its
determination of whether or not a binding has an endpoint. Does
this put new obligations on extension bindings to call their setURI()
method even if no "uri" attribute was specified in the SCDL?
No, for other bindings than SCABinding, the current code assumes it
always has a URI. SCABinding is the only binding that supports
"target" attribute at this moment. If a binding starts to support
"componentName/serviceName" addressing, then "uri" attribute should be
correctly configured.
5. Are there any other changes that extension binding writers need
to make (or are recommended to make) to fully support the new
multiple bindings support for references with multiplicity and
promotion?
No.
Simon
---------------------------------------------------------------------
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]
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
