I have a feeling there may be some confusion here with terminology -
heck, I know I'm confused :-)
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.
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).
--
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: <tuscany-dev@ws.apache.org>
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]
