You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by Ignacio Silva-Lepe <is...@verizon.net> on 2006/08/08 17:15:34 UTC
Re: [jira] Updated: (TUSCANY-585) Initial support for callbacks
Hi Jim,
I looked at the committed code including your changes. When I add
simplecallback to the samples/sca pom, it runs the sample successfully, as
far as I can tell.
----- Original Message -----
From: "Jim Marino" <jm...@myromatours.com>
To: <tu...@ws.apache.org>
Sent: Friday, July 28, 2006 10:47 PM
Subject: Re: [jira] Updated: (TUSCANY-585) Initial support for callbacks
> I'll apply it. Sorry I disappeared this week but I had a personal thing
> that came up...In the meantime, have a good vacation and ping when you
> are back.
>
> Jim
>
> On Jul 28, 2006, at 4:31 PM, Ignacio Silva-Lepe wrote:
>
>> Ok, I'm going to be on vacation next week (I won't have connectivity,
>> I'm even going to unsubscribe so I don't have to plow through my mailbox
>> when I get back), hopefully we'll be able to figure it out before then.
>> In any case, at least the patch is out there so that it does not get
>> stale by the time I'm back.
>> ----- Original Message ----- From: "Jim Marino"
>> <jm...@myromatours.com>
>> To: <tu...@ws.apache.org>
>> Sent: Friday, July 28, 2006 5:39 PM
>> Subject: Re: [jira] Updated: (TUSCANY-585) Initial support for callbacks
>>
>>
>>> O.K. thanks. I need to step out for a bit but I'll look into it
>>> tonight.
>>>
>>> Jim
>>>
>>>
>>> On Jul 28, 2006, at 2:25 PM, Ignacio Silva-Lepe wrote:
>>>
>>>> Ok, done. Forgot to add them to version control, apologies.
>>>> ----- Original Message ----- From: "Jim Marino"
>>>> <jm...@myromatours.com>
>>>> To: <tu...@ws.apache.org>
>>>> Sent: Friday, July 28, 2006 5:10 PM
>>>> Subject: Re: [jira] Updated: (TUSCANY-585) Initial support for
>>>> callbacks
>>>>
>>>>
>>>>> Hi Ignacio,
>>>>> I think the patch is missing the following classes:
>>>>> JavaMappedCallback and IllegalCallbackException
>>>>> Can you just attach the classes to the JIRA issue (no need to patch)?
>>>>> Jim
>>>>> On Jul 28, 2006, at 1:39 PM, Ignacio Silva-Lepe (JIRA) wrote:
>>>>>> [ http://issues.apache.org/jira/browse/TUSCANY-585?page=all ]
>>>>>>
>>>>>> Ignacio Silva-Lepe updated TUSCANY-585:
>>>>>> ---------------------------------------
>>>>>>
>>>>>> Attachment: CallbackPatch.txt
>>>>>>
>>>>>> Patch with code and sample attached
>>>>>>
>>>>>>> Initial support for callbacks
>>>>>>> -----------------------------
>>>>>>>
>>>>>>> Key: TUSCANY-585
>>>>>>> URL: http://issues.apache.org/jira/browse/
>>>>>>> TUSCANY-585
>>>>>>> Project: Tuscany
>>>>>>> Issue Type: New Feature
>>>>>>> Components: Java SCA Core
>>>>>>> Affects Versions: Java-Mx
>>>>>>> Reporter: Ignacio Silva-Lepe
>>>>>>> Assigned To: Ignacio Silva-Lepe
>>>>>>> Fix For: Java-Mx
>>>>>>>
>>>>>>> Attachments: CallbackPatch.txt
>>>>>>>
>>>>>>>
>>>>>>> Initial support for local callbacks is provided, along with a
>>>>>>> simple callback sample
>>>>>>
>>>>>> --
>>>>>> This message is automatically generated by JIRA.
>>>>>> -
>>>>>> If you think it was sent incorrectly contact one of the
>>>>>> administrators: http://issues.apache.org/jira/secure/
>>>>>> Administrators.jspa
>>>>>> -
>>>>>> For more information on JIRA, see: http://www.atlassian.com/
>>>>>> software/jira
>>>>>>
>>>>>>
>>>>>>
>>>>>> ------------------------------------------------------------------
>>>>>> -- -
>>>>>> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>>>>>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>>>>>>
>>>>> -------------------------------------------------------------------
>>>>> --
>>>>> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>>>>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>>>>>
>>>>
>>>>
>>>> --------------------------------------------------------------------
>>>> -
>>>> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>>>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: [jira] Updated: (TUSCANY-585) Initial support for callbacks
Posted by Jim Marino <jm...@myromatours.com>.
On Aug 11, 2006, at 1:59 PM, Jeremy Boynes wrote:
> On Aug 11, 2006, at 12:37 PM, Ignacio Silva-Lepe wrote:
>>
>> At the risk of complicating matters, what about services? For
>> symmetry we should also consider a couple more scenarios
>> 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")
>> 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
>>
> and
> 6) Composite(Component->Reference)->Composite(Service->Component) -
> a combination of 3) and 5) which may provide opportunities for wire
> optimization
>
>> 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.
>
> Agreed - I was thinking that would be symmetrical but decided to
> stick with just references :-)
>
Yes and we also need to deal with cycle detection at some point too :-(
> --
> Jeremy
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: [jira] Updated: (TUSCANY-585) Initial support for callbacks
Posted by Jeremy Boynes <jb...@apache.org>.
On Aug 11, 2006, at 12:37 PM, Ignacio Silva-Lepe wrote:
>
> At the risk of complicating matters, what about services? For
> symmetry we should also consider a couple more scenarios
> 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")
> 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
>
and
6) Composite(Component->Reference)->Composite(Service->Component) - a
combination of 3) and 5) which may provide opportunities for wire
optimization
> 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.
Agreed - I was thinking that would be symmetrical but decided to
stick with just references :-)
--
Jeremy
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: [jira] Updated: (TUSCANY-585) Initial support for callbacks
Posted by Ignacio Silva-Lepe <is...@verizon.net>.
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" <jb...@apache.org>
To: <tu...@ws.apache.org>
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: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: [jira] Updated: (TUSCANY-585) Initial support for callbacks
Posted by Ignacio Silva-Lepe <is...@verizon.net>.
----- Original Message -----
From: "Jim Marino" <jm...@myromatours.com>
To: <tu...@ws.apache.org>
Sent: Friday, August 11, 2006 4:59 PM
Subject: Re: [jira] Updated: (TUSCANY-585) Initial support for callbacks
>
> 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).
So, if a CompositeReference is a type of binding then it needs to define a
Binding subclass, a BindingBuilder and a BindingLoader, for which an XMLType
needs to be defined. What would this be, binding.sca, would it be implicit.
If it is implicit, how does the corresponding BindingBuilder know that a
CompositeReference is being built?
The interceptor realization of the target invoker seems a bit mysterious to
me, can you elaborate a bit?
>> --
>> Jeremy
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: [jira] Updated: (TUSCANY-585) Initial support for callbacks
Posted by Jim Marino <jm...@myromatours.com>.
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"
>> <jm...@myromatours.com>
>> To: <tu...@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: tuscany-dev-unsubscribe@ws.apache.org
>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: [jira] Updated: (TUSCANY-585) Initial support for callbacks
Posted by Jeremy Boynes <jb...@apache.org>.
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"
> <jm...@myromatours.com>
> To: <tu...@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: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: [jira] Updated: (TUSCANY-585) Initial support for callbacks
Posted by Ignacio Silva-Lepe <is...@verizon.net>.
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" <jm...@myromatours.com>
To: <tu...@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: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: [jira] Updated: (TUSCANY-585) Initial support for callbacks
Posted by Jim Marino <jm...@myromatours.com>.
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
> ----- Original Message ----- From: "Jim Marino"
> <jm...@myromatours.com>
> To: <tu...@ws.apache.org>
> Sent: Thursday, August 10, 2006 11:13 AM
> Subject: Re: [jira] Updated: (TUSCANY-585) Initial support for
> callbacks
>
>
>> Hi Ignacio,
>>
>> I'm out today and tomorrow. Could you maybe post to he list and
>> I'll try and respond as soon as I have a chance to pick up email?
>>
>> Jim
>>
>>
>> On Aug 10, 2006, at 7:12 AM, Ignacio Silva-Lepe wrote:
>>
>>> Hi Jim,
>>>
>>> When you have some time to chat, I have a few questions about
>>> references.
>>>
>>> Thanks
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: [jira] Updated: (TUSCANY-585) Initial support for callbacks
Posted by Ignacio Silva-Lepe <is...@verizon.net>.
Sure, I want to make sure I understand what local callbacks (or plain
invocations for that matter) via references means. 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
am working on this assumption. Let me know if I'm missing something, e.g.,
some currently existing classes that should be used.
Thanks
----- Original Message -----
From: "Jim Marino" <jm...@myromatours.com>
To: <tu...@ws.apache.org>
Sent: Thursday, August 10, 2006 11:13 AM
Subject: Re: [jira] Updated: (TUSCANY-585) Initial support for callbacks
> Hi Ignacio,
>
> I'm out today and tomorrow. Could you maybe post to he list and I'll try
> and respond as soon as I have a chance to pick up email?
>
> Jim
>
>
> On Aug 10, 2006, at 7:12 AM, Ignacio Silva-Lepe wrote:
>
>> Hi Jim,
>>
>> When you have some time to chat, I have a few questions about
>> references.
>>
>> Thanks
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: [jira] Updated: (TUSCANY-585) Initial support for callbacks
Posted by Jim Marino <jm...@myromatours.com>.
Hi Ignacio,
I'm out today and tomorrow. Could you maybe post to he list and I'll
try and respond as soon as I have a chance to pick up email?
Jim
On Aug 10, 2006, at 7:12 AM, Ignacio Silva-Lepe wrote:
> Hi Jim,
>
> When you have some time to chat, I have a few questions about
> references.
>
> Thanks
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: [jira] Updated: (TUSCANY-585) Initial support for callbacks
Posted by Ignacio Silva-Lepe <is...@verizon.net>.
Hi Jim,
When you have some time to chat, I have a few questions about references.
Thanks
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: [jira] Updated: (TUSCANY-585) Initial support for callbacks
Posted by Ignacio Silva-Lepe <is...@verizon.net>.
Do you have time to chat some time today or tomorrow about where we are on
wiring, callbacks via references (local and remote), and conversational
support? I'm available for the next 1.5 hrs today and all day tomorrow
(except for a 1-2pm EDT mandatory meeting).
----- Original Message -----
From: "Jim Marino" <jm...@myromatours.com>
To: <tu...@ws.apache.org>
Sent: Tuesday, August 08, 2006 12:03 PM
Subject: Re: [jira] Updated: (TUSCANY-585) Initial support for callbacks
> Yea for me too ;-). Do you want to take a look? I also posted a message
> describing some of the changes I made. Also, for next steps, we'll need
> to get this working with References (we only have component-to-component
> callbacks).
>
> Jim
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: [jira] Updated: (TUSCANY-585) Initial support for callbacks
Posted by Jim Marino <jm...@myromatours.com>.
Yea for me too ;-). Do you want to take a look? I also posted a
message describing some of the changes I made. Also, for next steps,
we'll need to get this working with References (we only have
component-to-component callbacks).
Jim
On Aug 8, 2006, at 8:15 AM, Ignacio Silva-Lepe wrote:
> Hi Jim,
>
> I looked at the committed code including your changes. When I add
> simplecallback to the samples/sca pom, it runs the sample
> successfully, as far as I can tell.
> ----- Original Message ----- From: "Jim Marino"
> <jm...@myromatours.com>
> To: <tu...@ws.apache.org>
> Sent: Friday, July 28, 2006 10:47 PM
> Subject: Re: [jira] Updated: (TUSCANY-585) Initial support for
> callbacks
>
>
>> I'll apply it. Sorry I disappeared this week but I had a
>> personal thing that came up...In the meantime, have a good
>> vacation and ping when you are back.
>>
>> Jim
>>
>> On Jul 28, 2006, at 4:31 PM, Ignacio Silva-Lepe wrote:
>>
>>> Ok, I'm going to be on vacation next week (I won't have
>>> connectivity, I'm even going to unsubscribe so I don't have to
>>> plow through my mailbox when I get back), hopefully we'll be
>>> able to figure it out before then. In any case, at least the
>>> patch is out there so that it does not get stale by the time I'm
>>> back.
>>> ----- Original Message ----- From: "Jim Marino"
>>> <jm...@myromatours.com>
>>> To: <tu...@ws.apache.org>
>>> Sent: Friday, July 28, 2006 5:39 PM
>>> Subject: Re: [jira] Updated: (TUSCANY-585) Initial support for
>>> callbacks
>>>
>>>
>>>> O.K. thanks. I need to step out for a bit but I'll look into it
>>>> tonight.
>>>>
>>>> Jim
>>>>
>>>>
>>>> On Jul 28, 2006, at 2:25 PM, Ignacio Silva-Lepe wrote:
>>>>
>>>>> Ok, done. Forgot to add them to version control, apologies.
>>>>> ----- Original Message ----- From: "Jim Marino"
>>>>> <jm...@myromatours.com>
>>>>> To: <tu...@ws.apache.org>
>>>>> Sent: Friday, July 28, 2006 5:10 PM
>>>>> Subject: Re: [jira] Updated: (TUSCANY-585) Initial support for
>>>>> callbacks
>>>>>
>>>>>
>>>>>> Hi Ignacio,
>>>>>> I think the patch is missing the following classes:
>>>>>> JavaMappedCallback and IllegalCallbackException
>>>>>> Can you just attach the classes to the JIRA issue (no need to
>>>>>> patch)?
>>>>>> Jim
>>>>>> On Jul 28, 2006, at 1:39 PM, Ignacio Silva-Lepe (JIRA) wrote:
>>>>>>> [ http://issues.apache.org/jira/browse/TUSCANY-585?
>>>>>>> page=all ]
>>>>>>>
>>>>>>> Ignacio Silva-Lepe updated TUSCANY-585:
>>>>>>> ---------------------------------------
>>>>>>>
>>>>>>> Attachment: CallbackPatch.txt
>>>>>>>
>>>>>>> Patch with code and sample attached
>>>>>>>
>>>>>>>> Initial support for callbacks
>>>>>>>> -----------------------------
>>>>>>>>
>>>>>>>> Key: TUSCANY-585
>>>>>>>> URL: http://issues.apache.org/jira/browse/
>>>>>>>> TUSCANY-585
>>>>>>>> Project: Tuscany
>>>>>>>> Issue Type: New Feature
>>>>>>>> Components: Java SCA Core
>>>>>>>> Affects Versions: Java-Mx
>>>>>>>> Reporter: Ignacio Silva-Lepe
>>>>>>>> Assigned To: Ignacio Silva-Lepe
>>>>>>>> Fix For: Java-Mx
>>>>>>>>
>>>>>>>> Attachments: CallbackPatch.txt
>>>>>>>>
>>>>>>>>
>>>>>>>> Initial support for local callbacks is provided, along with
>>>>>>>> a simple callback sample
>>>>>>>
>>>>>>> --
>>>>>>> This message is automatically generated by JIRA.
>>>>>>> -
>>>>>>> If you think it was sent incorrectly contact one of the
>>>>>>> administrators: http://issues.apache.org/jira/secure/
>>>>>>> Administrators.jspa
>>>>>>> -
>>>>>>> For more information on JIRA, see: http://www.atlassian.com/
>>>>>>> software/jira
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> ----------------------------------------------------------------
>>>>>>> -- -- -
>>>>>>> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>>>>>>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>>>>>>>
>>>>>> -----------------------------------------------------------------
>>>>>> -- --
>>>>>> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>>>>>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>>>>>>
>>>>>
>>>>>
>>>>> ------------------------------------------------------------------
>>>>> -- -
>>>>> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>>>>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>>>>>
>>>>
>>>>
>>>> -------------------------------------------------------------------
>>>> --
>>>> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>>>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>>>>
>>>
>>>
>>>
>>> --------------------------------------------------------------------
>>> -
>>> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org