Using a CompositeReference SCAObject to handle case 3) sounds reasonable to
me.
At the risk of complicating matters, what about services? For symmetry we
should also consider a couple more scenarios
4) Service with remote Binding->Component - the wire lies within the
composite and comes from the remote binding; this case seems to be well
covered as well
5) Service wired by the Composite->Component - there is an external wire to
the CompositeComponent from a sibling Component or Service, and a local wire
between the Service and the Component
To account for case 5), a case could also be made for a CompositeService
SCAObject that could work in conjunction with its containing
CompositeComponent to pass wires around.
----- Original Message -----
From: "Jeremy Boynes" <[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Friday, August 11, 2006 2:58 PM
Subject: Re: [jira] Updated: (TUSCANY-585) Initial support for callbacks
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
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
