On Dec 5, 2006, at 10:51 PM, Venkata Krishnan wrote:
> Hi,
>
> I think I managed to figure this out now. After your explanation I
> could
> follow the Connector a little better. Its just that the outbound
> (of the
> source component) and inbound chains (of the target component) are
> fused
> thro the bridge interceptor.
>
> Given this if I added an interceptor to the begining of the
> target's inbound
> chain then I must have to reset the source's tail interceptor to
> point this
> this added interceptor as its next. (Infact I found this code
> marked as
> "HACK" further down the DataBindingWirePostProcessor). This is what I
> intend to do.
We probably should do something to make this less error-prone in the
fabric...I'll take a look.
>
> On the other hand if I were to add an intercetpr to the end of the
> target's
> inbound chain then I end with an exception because the tail is
> already an
> InvokerInterceptor and nothing can be added beyond that.
The pass-by-reference interceptor needs to come first since
interceptors could modify a the payload of a message. This can
violate pass-by-value semantics if a copy is not made beforehand.
> So in this case I
> have to probably iterate thro all interceptors and then insert just
> before
> the InvokerInterceptor.
>
> So.. I am moving forward for now. Thanks for the help.
>
Can you post a testcase so I can see how best to make this less error-
prone as mentioned above? Thanks.
Jim
> - Venkat
>
>
>
>
>
> On 12/5/06, Jim Marino <[EMAIL PROTECTED]> wrote:
>>
>>
>> On Dec 5, 2006, at 1:34 AM, Venkata Krishnan wrote:
>>
>> > Hi Jim,
>> >
>> > Thanks for helping :). Well, let me ask away very simply....
>> >
>> > What I am doing here is just about trying to insert an
>> interceptor for
>> > enforcing pass-by-value semantics in the case of compoments
>> > implementing a
>> > Remotable interface - i.e. an interceptor to take care of making
>> > copies of
>> > arguments and return values.
>> >
>> > Since I understand that the best place to perform such a copying
>> > would be
>> > just before the serving (or provider) component actually gets to
>> > service the
>> > request, I had thought of inserting this interceptor into the
>> > InboundInvocation chain of the server component.
>> >
>> > For example if component A that has a reference to Component B
>> whose
>> > interface is remotable. Then I am trying to insert this
>> > interceptor into
>> > Component B's Inbound wire's invocation chain. This I do in the
>> > DataBindingWirePostProcessor.process(OutboundWire source,
>> InboundWire
>> > target) wherein 'target' is the wire where I am doing the
>> insertion.
>> Pass-by-val should probably be enforced in another wire processor
>> since it is a separate concern (this isn't related to the problem
>> though)
>> > (Component A being the source and Component B being the target).
>> > When I
>> > tested this, the interceptor seemed to not get invoked.
>> >
>> > However, when I added this interceptor to the source component's
>> > outbound
>> > chain i.e. in DataBindingWirePostProcessor.process(OutboundWire
>> > source,
>> > InboundWire target) to the invocation chain of the 'source',
>> then the
>> > interceptor got invoked.
>> >
>> > So right now, I am wondering how to get the interceptor invoked
>> > from the
>> > Inbound invocation chain of Component B.
>> >
>> It sounds like something is not being setup properly
>>
>> > If I am still not clear please let me know and probably testcase is
>> > the only
>> > way out.
>> >
>> This would be the easiest way (you can probably copy the testcase I
>> pointed to, so it's not that much work). Such a testcase will allow
>> you to set a breakpoint and see if the target chains have been
>> sequenced properly. It sounds like upon insertion your interceptor
>> is not being pointed to by the previous one in the chain. It is
>> possible that there is a problem in the wiring infrastructure that is
>> causing this to happen.
>>
>> Jim
>>
>>
>>
>> > Thanks
>> >
>> > - Venkat
>> >
>> >
>> >
>> >
>> > On 12/5/06, Jim Marino <[EMAIL PROTECTED]> wrote:
>> >>
>> >> 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: 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]
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
