Hmm, ok, first off a bit of clarification on the terminology. When I say
local callback (or plain invocation) via a reference, I was thinking about
the case of a component in a composite talking to a component in another
composite via their respective composite reference and service, where both
composites are contained in a third (larger) composite, all in the same
process or machine. Perhaps this is not a valid or considered use case but
it seems to be different from a wire between two components, and from a wire
whose target is a reference that has a remote binding, e.g., ws.
Wires between components are already taken care of. A wire to a reference
with a remote binding needs to involve the Reference (or Service) defined by
the appropriate binding, e.g., Axis2Reference (or Axis2Service). But before
we get there I thought we were trying to take care of the 'local via a
reference' case as above. If this is something we intend to do I am open to
the idea of not requiring a JavaReference or a JavaService. However, two
things come to mind:
(1) A Reference on a composite in this case may represent an external
service but not a remote one, i.e., a service external to the composite but
local wrt the process or machine. If this is a valid scenario, then one
question is what is the binding to be used by this reference? Can it be
plugged in depending on deployment scenario? If such scenario is as above
then binding.ws or some such may not be appropriate, what's the alternative,
binding.sca or even something like binding.java?
(2) If what we are doing is connecting two composites in the same machine
via their respective Reference and Service as above, then the target invoker
for the Reference of the source composite needs to behave like the target
invoker for an atomic component with the difference that no user-defined
logic is invoked, only the proxy for the Reference's outbound wire. Perhaps
this is what you meant by optimizing away a JavaReference and only using a
proxy. But the optimization seems to be dependent on the Reference's
binding, i.e., whether it is a remote binding (e.g., ws) or not (as above).
Hopefully things are not getting more confused.
Thanks
----- Original Message -----
From: "Jim Marino" <[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Thursday, August 10, 2006 10:42 PM
Subject: Re: [jira] Updated: (TUSCANY-585) Initial support for callbacks
On Aug 10, 2006, at 8:37 AM, Ignacio Silva-Lepe wrote:
Sure, I want to make sure I understand what local callbacks (or plain
invocations for that matter) via references means.
I was defining a local callback as being a bidirectional wire to a target
component, which (by definition) is in the same composite. A wire whose
target is a reference would be a "remote callback" since the invocation
flows outside a composite. For local callbacks, we don't need to persist
ids and have more "control" of things (lifecycle, thread dispatching,
by-ref, etc.). For remote callbacks, I don't think we should allow direct
wiring to a child component in another composite as that breaks
visibility rules for composites. Rather, I was thinking we would need to
design for a durable store to be able to map back to the callback wire
and target instance (target instance id may be able to be calculated
using an FQN of its component name in the composite hierarchy). On the
outbound leg, the reference target invoker would persist the id to wire
chain mapping. The binding would be responsible for flowing the ids. In
this case, references act as services and services act as references
during a callback and would have to re-associate the ids with invocation
chains.
A ReferenceExtension is built wrt a binding, e.g., Axis2Reference. So
for 'local' we treat the binding as a (dummy) special case and wire
directly to a component's or a composite's service, as in EchoReference
but more fleshed out. Similarly, for service, which for local could be
wired from a component's or a composite's reference. If this makes
sense, then it means we need new JavaReference, JavaService and
JavaBindingBuilder implementations that don't currently exist and that
use a dummy JavaBinding similar to EchoBinding.
I may be misunderstanding but for the local case, I think things are
conceptually the same but there are some optimizations and implementation
differences that do not require us to have JavaReference or JavaService.
References on composites are just representations of some external
service and are responsible for dispatching an invocation to it over a
binding. Similarly, a reference on a Java component is just a
representation of the target service and the binding can be considered
something like "pass-by- reference" or "vm". However, implementations vary
with the composite reference being realized as a Reference and a Java
component reference being just a proxy. I don't think we need the extra
step of creating JavaService or JavaReference for local wires as they are
never used (i.e. Java implementations always use the proxy
representation).
I may be missing your point though so let me know if this makes any
sense.
Jim
I am working on this assumption. Let me know if I'm missing something,
e.g., some currently existing classes that should be used.
Thanks
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
