The short answer is Yes. The long answer follows below :-)
I'll describe the design approach used by the code in my patch for
TUSCANY-1496. Things are moving rapidly in this area with Raymond's
work to support late binding between references and services, so some
of this description may need to be updated.
Wires may be reference wires or service wires:
1. Reference wires connect a source reference to a target binding
and endpoint. The source reference could be a callback service's
pseudo-reference.
2. Service wires connect a binding endpoint to a service implementation.
The service implementation could be a callback reference's
pseudo-service.
Reference wires may be static or dynamic:
1. A static wire targets a specific binding and endpoint (local or
remote). Dispatching a call down an invocation chain for this
wire results in a call to the statically configured binding and
endpoint for the wire.
2. A dynamic wire targets a specific binding but an unspecified
endpoint. The actual target endpoint is provided at invocation
time. Depending on the binding type, dynamic wires may perform
worse than static wires, or their performance may be the same.
Some bindings may only support static wires. Some may only support
dynamic wires. Some may support both, with static wires providing
better performance.
Service wires are effectively always static since on the service
side, the binding and endpoint is known. Every service and binding
combination has a single service wire that is used by the binding
provider to invoke the service.
For statically connected references and services (e.g., wired in SCDL,
using an SCA binding, and locally accessible), static forward wires
are created. The core can't fully complete the end-to-end invocation
chain for the static wire, so the start methods of bindings that
support local optimization (like the local SCA binding) can complete
these connections using information provided by the core.
If the statically wired reference/service pair defines a callback
interface, static wires for callback purposes are created from the
pseudo-reference to the pseudo-service (this is what the code at
line 503 is doing). Again, the binding's start method may perform
invocation chain optimization. These static wires for use by callbacks
provide an optimized callback path for cases where the target of the
callback can be predicted in advance based on wiring information.
For references where a static target is not always known at wiring time,
a dynamic wire is created by the core. All callback pseudo-references
fall into this category, as do forward references that have wiredByImpl
semantics. Even callbacks that are statically wired will have a single
dynamic wire in addition to their static wires. The dynamic wire is
needed because there is always the chance of the callback service being
called through a service reference that has used a callback object
service reference to redirect the callback to a destination that could
not be predicted at static wiring time. The static wires are an
optimization that is likely to produce better performance when the
callback destination corresponds to a static wire.
When a callback is made at runtime, the invocation handler attempts to
locate a static wire whose destination endpoint matches the callback
destination endpoint. If one is found, this wire is used to provide
best performance. If one is not found, a dynamic wire can be used if
supported by the binding, or a new static wire can be constructed at
runtime. Think of the collection of static wires as a cache to optimize
calls to known destinations, with this cache either being partially
pre-populated by the code at line 503 or built dynamically on demand as
callbacks are made.
The code at line 579 has a different purpose. This is setting the
callback endpoint (pseudo-service) to pass with a forward call, so
that the target service knows where to direct any callbacks that
may occur.
Simon
Jean-Sebastien Delfino wrote:
Now that callbacks are represented as regular services/references, are
the "if (callback.....) { .... }" on lines 503 and 579 of
CompositeActivatorImpl still necessary?
If yes, then the next question is: Why? :)
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
