Comments inline...
On Dec 5, 2006, at 12:29 AM, Venkata Krishnan wrote:
> Hi Raymond,
>
> Yes, I am debugging to figure out quite a few things.
>
> I just figured that in the ConnectorImpl.connect(OutboundWire
> sourceWire,
> InboundWire targetWire, boolean optimizable) we set the
> 'targetInvoker' of
> the 'targetComponent' to the outbound chain of the source. Hence I
> guess
> the interceptors of set on the inbound chain of the targetComponent
> is not
> getting invoked.
>
> I am looking to see if there is a way where at the end of the
> OutboundWire's
> invocation chain the target invoker triggers off the target
> component's
> inbound invocation chains.
>
The TargetInvoker's job is to dispatch a request to the target
instance *after* the request has been processed by the invocation
chain pair. The invoker is cached on the source side to avoid having
to perform target resolution on every invoke in certain situations
(e.g. when the target scope is "greater" than the source,e.g.
request--->composite). The invocation handler places the
TargetInvoker in the message sent down both chains and it is the
responsibility of the last interceptor on the target side to pull the
invoker from the message and call its invoke method.
The source and target chains are fused by the Connector with a
BridgingInterceptor, which may be synchronous or non-blocking.
I'm finding it a little difficult to follow what you are doing so do
you have a small testcase you can attach to a JIRA similar to this:
https://svn.apache.org/repos/asf/incubator/tuscany/java/sca/kernel/
core/src/test/java/org/apache/tuscany/core/integration/conversation/
ConversationStartStopEndTestCase.java
I can take a look and see what the problem is.
Jim
> I am still going at this... let me see if I see the light.
>
> Meanwhile if I am not on the right track (anybody) please advise
me on
> course corrections :)
>
> Thanks.
>
> - Venkat
>
>
>
> On 12/5/06, Raymond Feng <[EMAIL PROTECTED]> wrote:
>>
>> Hi,
>>
>> Can you debug to see how the interceptors are chained? It could be
>> a bit
>> tricky to make sure the new interceptor is added to the correct
>> position.
>>
>> Thanks,
>> Raymond
>>
>> ----- Original Message -----
>> From: "Venkata Krishnan" <[EMAIL PROTECTED]>
>> To: <[email protected]>
>> Sent: Monday, December 04, 2006 4:16 PM
>> Subject: Re: Pass-by-value support for remotable interfaces
>>
>>
>> > Hi Raymond,
>> >
>> > Thanks. I have started with this and here are a couple of
>> questions
>> that
>> > I
>> > need help with.
>> >
>> > I believe the PassByValue Interceptor is good to be on the
Inbound
>> > Invocation chain of the server component. Accordingly I looked
>> up the
>> > DataBindingWirePostProcessor's method -
>> > "public void process(OutboundWire source, InboundWire target)"
>> to do
>> this.
>> >
>> > Over here I added the PassbyValue interceptor to the 'target'.
>> But this
>> > did
>> > not invoke the interceptor. If I added it to the source then
the
>> > interceptor gets invoked. So, am I missing something here?
>> >
>> > I understand that the interceptor that you have attached is
for the
>> > default
>> > Java binding case. I will work on the databinding dependent
>> case once I
>> > get
>> > this default stuff working.
>> >
>> > Thanks
>> >
>> > - Venkat
>> >
>> >
>> >
>> > On 12/4/06, Raymond Feng <[EMAIL PROTECTED]> wrote:
>> >>
>> >> Hi, Venkat.
>> >>
>> >> Thank you for volunteering. I opened a JIRA
>> >> http://issues.apache.org/jira/browse/TUSCANY-969 and
attached some
>> >> prototype
>> >> code there. Hopefully it can get you started.
>> >>
>> >> Thanks,
>> >> Raymond
>> >>
>> >> ----- Original Message -----
>> >> From: "Venkata Krishnan" <[EMAIL PROTECTED]>
>> >> To: <[email protected]>
>> >> Sent: Sunday, December 03, 2006 10:08 PM
>> >> Subject: Re: Pass-by-value support for remotable interfaces
>> >>
>> >>
>> >> > Hi Raymond,
>> >> >
>> >> > I'm interested in helping with this. It will give me a
>> chance to
>> work
>> >> > with
>> >> > the service invocation paths of the core. Let me know if
>> there is
>> >> > something
>> >> > that I help with.
>> >> >
>> >> > Thanks.
>> >> >
>> >> > - Venkat
>> >> >
>> >> > On 11/30/06, Raymond Feng <[EMAIL PROTECTED]> wrote:
>> >> >>
>> >> >> ----- Original Message -----
>> >> >> From: "Mike Edwards" <[EMAIL PROTECTED]>
>> >> >> To: <[email protected] >
>> >> >> Sent: Wednesday, November 29, 2006 7:07 AM
>> >> >> Subject: Re: Pass-by-value support for remotable interfaces
>> >> >>
>> >> >>
>> >> >> > Raymond,
>> >> >> >
>> >> >> > First point I need to make is that just because two
>> components are
>> >> >> > in
>> >> >> the
>> >> >> > same composite does not mean that they are automatically
>> running
>> in
>> >> the
>> >> >> > same VM or even the same operating system process.
>> Composites can
>> >> span
>> >> >> > components running on different nodes (node = machine and/
>> or o/s
>> >> >> process).
>> >> >> >
>> >> >>
>> >> >> Good catch.
>> >> >>
>> >> >> > Consider a composite which had component A implemented in
>> Java and
>> >> >> > component B implemented in C++. Not likely that they
>> would run in
>> >> the
>> >> >> > same runtime process (certainly not with the current
Tuscany
>> >> runtime).
>> >> >> > This is perfectly OK as long as any interface between
them is
>> >> >> "remotable".
>> >> >> >
>> >> >> > Second, more general point to make, is that there may be
>> implied
>> >> >> semantics
>> >> >> > for the interface that depend on the binding used to
>> connect the
>> >> >> reference
>> >> >> > to the service. Consider the case where the interface
>> involves an
>> >> >> > operation with a message having two references to the same
>> object.
>> >> >> > When
>> >> >> > this is sent from consumer to provider (say), does the
>> provider
>> >> receive
>> >> >> 2
>> >> >> > separate copies of the object or just one - assuming the
>> consumer
>> >> >> started
>> >> >> > with only 1.
>> >> >> >
>> >> >> > The answer is "it depends on the binding" - RMI-IIOP says
>> there is
>> >> only
>> >> >> 1
>> >> >> > copy. Web Services says there are 2 copies...
>> >> >> >
>> >> >> > I don't think that SCA can hide these subtle differences,
>> much
>> >> >> > though
>> >> >> > we
>> >> >> > may like to do so. However, what we must guarantee is
>> that the
>> >> >> behaviour
>> >> >> > matches the binding type - if the internal wire uses
>> binding.ws,
>> for
>> >> >> > example, then we provide Web services semantics. This
>> must be
>> true
>> >> for
>> >> >> > any optimisations we may like to use in the case where
>> both ends
>> of
>> >> the
>> >> >> > wire are in 1 process - since for a remotable interface
this
>> >> proximity
>> >> >> is
>> >> >> > "accidental" and could be changed by a subtle change in
>> deployment.
>> >> >> >
>> >> >> > That leaves open what to do in the case of binding.ws. We
>> may
>> need
>> >> >> > a
>> >> >> way
>> >> >> > for the composition to indicate the type of semantics
>> required -
>> or
>> >> we
>> >> >> > could default to one form (eg Web services...)
>> >> >> >
>> >> >>
>> >> >> Should this be clarified by the SCA spec on pass-by-value?
>> >> >>
>> >> >> >
>> >> >> > Yours, Mike.
>> >> >> >
>> >> >> > Raymond Feng wrote:
>> >> >> >> Hi,
>> >> >> >>
>> >> >> >> I'm talking about the following:
>> >> >> >>
>> >> >> >> componentA.reference --> componentB.service1
>> >> >> >> non-SCA client --> componentB.service1
>> >> >> >>
>> >> >> >> In the cases above, componentA and componentB are in the
>> same
>> >> >> >> composite
>> >> >>
>> >> >> >> (in the same VM). Both the service and reference are
>> declared
>> with
>> >> >> >> a
>> >> >> >> remotable interface. We need to have an interceptor to
>> deal with
>> >> >> >> the
>> >> >> >> pass-by-value.
>> >> >> >>
>> >> >> >> For the following wirings:
>> >> >> >>
>> >> >> >> .. --> composite.reference
>> >> >> >> composite.service --> ...
>> >> >> >>
>> >> >> >> I assume the binding implementation for the composite
>> >> >> >> reference/service
>> >> >> >> will handle the pass-by-value naturally over the
transport.
>> >> >> >>
>> >> >> >> Thanks,
>> >> >> >> Raymond
>> >> >> >>
>> >> >> > <snip>
>> >> >> >
>> >> >> >
>>
---------------------------------------------------------------------
>> >> >> > To unsubscribe, e-mail: tuscany-dev-
[EMAIL PROTECTED]
>> >> >> > For additional commands, e-mail: tuscany-dev-
>> [EMAIL PROTECTED]
>> >> >> >
>> >> >>
>> >> >>
>> >> >>
>>
---------------------------------------------------------------------
>> >> >> To unsubscribe, e-mail: tuscany-dev-
[EMAIL PROTECTED]
>> >> >> For additional commands, e-mail: tuscany-dev-
[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]
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
