Comments inline.
Thanks,
Raymond
----- Original Message -----
From: "Simon Nash" <[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Monday, August 20, 2007 5:14 PM
Subject: Re: Do we still need special handling of callback bindings and
wires?
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.
It's my turn to update the discription now :-)
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.
I'm not sure why you think it's the binding's job to support static or
dynanic wire. To me, the dynamic wire needs to be bound an endpoint before
it can used for invocations.
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.
Now we support the lazy creation of RuntimeWire/Invocation for a reference.
I also changed the code to have the RuntimeSCABindingInvoker to delegate the
call to the first invoker in the target service chain instead of trying to
merge/connect the two chains together.
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.
On the service side, I don't think we should create static wires for
references corresponding to the service callbacks at all. I updated some of
the code to bind the dynamic wire to the callback endpoint in the context of
an invocation. Then the dynamic wire (cloned) becomes a static wire after
the target endpoint is bound.
Simon, did you create the static wires from service to reference for
performance optimization? I assume the dynamic association is not heavy at
all.
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
