On Aug 11, 2006, at 11:58 AM, Jeremy Boynes wrote:
I have a feeling there may be some confusion here with terminology
- heck, I know I'm confused :-)
Yes, I think it is a terminology thing. I was thinking of the three
scenarios below and local only being a case of #1.
I think there are several scenarios here and would like to make
sure they are all being covered.
1) Component->Component - this must lie within a Composite and may
have local or remote semantics
2) Component->Reference with remote Binding - the wire lies within
a Composite and disappears into the remote binding
3) Component->Reference wired by the Composite - there is a local
wire between the Component and the Reference and an external wire
from the CompositeComponent to a sibling Component or Reference
(aka the "uncle")
I believe cases 1) and 2) are well covered. A target SCAObject is
created with an inbound wire which is then connected to an outbound
wire from the source. The resulting connection may be optimized
away, or may have policy or other interceptors applied.
Yes but #2 still need to be done.
I am confused about how case 3) is being handled, specifically how
the connection is being made between the Reference and the
CompositeComponent.
I think there is a good case to me made for having an SCAObject to
represent the Reference - for example, you may want to manage the
reference in some way. Having it there does not mean that it needs
to be part of the invocation path. For example, during connection
the wire could be optimized in a way that allowed the "uncle" to be
directly injected into the source.
Perhaps "JavaReference" is confusing here - how about we call it a
"CompositeReference", as in "a Reference whose wiring is handled by
the composite component that contains it." This would work in
conjunction with a CompositeComponent to pass wires around - for
example, CompositeComponent.addOutboundWire could just delegate
down to the appropriate CompositeReference (selected by name).
Yes having the special type of reference makes sense because this is
a type of binding. The target invoker in this case could actually be
an interceptor which flowed the invocation to the head interceptor of
the uncle. If this is the case, we may need to have the Connector
handle this case of finding the target in the outer "grandparent"
composite (if that makes sense).
--
Jeremy
On Aug 11, 2006, at 6:46 AM, Ignacio Silva-Lepe wrote:
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]
---------------------------------------------------------------------
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]
