You are viewing a plain text version of this content. The canonical link for it is here.

Posted to dev@tuscany.apache.org by Venkata Krishnan <fo...@gmail.com> on 2006/12/04 07:08:19 UTC

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 <en...@gmail.com> wrote:
>
> ----- Original Message -----
> From: "Mike Edwards" <mi...@gmail.com>
> To: <tuscany-dev@ws.apache.org >
> 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-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: Pass-by-value support for remotable interfaces

Posted by Venkata Krishnan <fo...@gmail.com>.

Hi,

This mail thread having got very long, here is a summary of where we stand
and where I seek help from the community.

1) PassByValue is enforced by the way of PassByValueInterceptor that is
added to the inbound chain of the producer / server component.

2) The PassByValueInterceptor copies the arguments / result data objects as
follows : -
   - checks the databinding associated with the arguments / result data
types and invokes the 'copy' method on the associated databinding
implementation.  The databinding is found by introspecting the data type
(using DataBindingRegistry.introspect).
   - if a databinding cannot be assoicated then the interceptor tries to
copy using Java Serialization
   - if the argument / result objects are not java.io.Serializable then an
exception is thrown.

Questions
---------
Is this a good enough policy for data copying i.e. going by the databinding
if detectable or by java.io.Serializability.  Take for example the
echo.databinding sample that has XMLStreamReader as argument for one of the
components service methods. This fails rightaway.  Wonder what other
datatypes could fail as this.

Besides using the databinding, java serialization there is a another way of
copying objects using the various transformers that are available.  For
example in the XMLStreamReader case we could use a round trip transformation
of  XMLStreamReader->String->XMLStreamReader.  Is this something that we
could do?

To me, passing streams / readers as arguments is not so convincing of a lose
coupling of components.  I'd rather pass information based on which the
stream could be constructed by the producer in the producers context.  But
then, this is besides the point as it probably excludes a subset of data
types. To cover all, is there a design / programming model that needs to be
put in place for the types of arguments can be used on Service interfaces
for e.g. do we say that Remotable Interfaces should use arguments that are
either associated with a databinding or is java.io.Serializable ?

Could the community help me with some clarity on this please.  Thanks.

- Venkat

Re: Pass-by-value support for remotable interfaces

Posted by Venkata Krishnan <fo...@gmail.com>.

Hi Raymond,

1) Here is the method that I have done to the DataBinding interface ...
          Object copy(Object source);
At the present moment I cannot think of any context that can also be added
as an argument to this method.  Will do so if it evolves to that as we go
along.

2) I also implmented the 'copy' method in the AxiomDataBinding and
SimpleDataBinding classes to take care of OMElement and Node objects.  I am
using the transformers effectively in this regard.

3) After this I have been able to run the echo.databinding sample (which has
been breaking) half way through.  This time around I am stuck with the
XMLStreamReader which is not serializable and is not taken care of any of
the databindings.  This on one hand and on the other I really cannot make
sense of copying streams or stream readers as part of enforcing
passbyvalue.

All this means that there are going to be some objects types that we should
not be copying and then some that we don't know how to copy.  What is the
'general' strategy to follow on what objects to copy and what not?
  - Would it be like we copy if we know the databindings to which they
conform or if they are serializable java objects.  When we don't know how to
copy do we raise exceptions or do we simply pass thro.
  - What about the list of object types such as XMLStreamReader which
actually may not make sense to copy.  What will be the marker that we can
use to identify these sort of object types.

4) While using the transformers to implement the copy method in the
AxiomDataBinding and SimpleDataBinding I observed that what we are trying to
do here is a round-trip transformation for example to copy OMElement I do a
OMElement2String and then a String2OMElement.  So am wondering if we could
make use of the 'data mediation' always instead of using just when there is
a disparity between source and target databindings. i.e.

- When databindings between source and target are different, currently there
is data mediation that is performed.  When this is perfomed, there is no
need to copy since anyway a new data object is created.
- When datatbindings between source and target are the same, currently there
is 'no' data mediation performed.  But why not do it here also but a round
trip transformation.  So we define a set of 'round trip transformers' that
take you from a source type to a target type and then back to the source
type, returning a copy at the end of it all.

Thanks for reading this far and please let me know your thoughts on all of
this.

- Venkat

On 12/13/06, Venkata Krishnan <fo...@gmail.com> wrote:
>
> Hi Raymond,
>
> Thanks.  Am going ahead with this.
>
> - Venkat
>
> On 12/13/06, Raymond Feng <en...@gmail.com> wrote:
> >
> > Hi, Venkat.
> >
> > You don't have to create a new extension point here as we already have
> > one:
> >
> > org.apache.tuscany.spi.DataBinding
> > org.apache.tuscany.spi.DataBindingRegistry
> >
> > You can just add the copy(...) method to
> > "org.apache.tuscany.spi.DataBinding".
> >
> > Thanks,
> > Raymond
> >
> > ----- Original Message -----
> > From: "Venkata Krishnan" <fo...@gmail.com>
> > To: <tu...@ws.apache.org>
> > Sent: Wednesday, December 13, 2006 2:39 AM
> > Subject: Re: Pass-by-value support for remotable interfaces
> >
> >
> > > Hi Raymond,
> > >
> > > Here is what I have thought about the databinding dependent copying: -
> > >
> > > - Create an interface called 'DataCopier' that has 'copy' and
> > > 'getDataBinding' methods.
> > > - Have various databindings implement this interface.  For example
> > > OMElementCopier, SDOCopier and so on.
> > > - In the PassByValueInterceptor, have 'copier' object. i.e. in the
> > wire
> > > post
> > > processor we look at the databinding of the target and create an
> > > appropriate
> > > copier.  We then configure the PassByValueIntercpetor with this copier
> > > object.  As part of the invoke method the interceptor will call the
> > > Copier's
> > > copy method.
> > > - As in the case of transformers, we can have a registry of copiers
> > keyed
> > > by
> > > their databinding.
> > >
> > > Will this approach work?  Have I missed out something in this
> > ?  Thanks.
> > >
> > > - Venkat
> > >
> > > On 12/8/06, Jim Marino < jmarino@myromatours.com> wrote:
> > >>
> > >> >
> > >> >
> > >> > Well here is what I picked up from the specs and C&I model
> > >> > "The @AllowsPassByReference annotation on the implementation of a
> > >> > remotable
> > >> > service is used to either declare that calls to the whole interface
> > or
> > >> > individual methods allow pass by reference." and  "Either a whole
> > >> > class
> > >> > implementing a remotable service or the individual remotable
> > >> > service method
> > >> > implementation can be annotated using the @AllowsPassByReference
> > >> > annotation.
> > >> > "
> > >> >
> > >> > and then there are samples as well that show the annotations being
> > >> > used in
> > >> > these two ways.  HenceI have stared to think this way.
> > >> >
> > >> Yes they are in there but I believe we changed that and may not have
> > >> updated the spec. At least that was my and Mike Rowley's
> > >> recollection.  Let me check tomorrow. We've changed a number of
> > >> things back and forth so it's quite possible I don't remember where
> > >> we wound up. If it is per operation, that is potentially very error-
> > >> prone so I will take it up with the spec group.
> > >> >
> > >> >
> > >> > I am yet to take a look at the PolicyBuilder related stuff.  Will
> > >> > take this
> > >> > to completion and then migrate to that.   I am most certain it
> > >> > would be no
> > >> > problem fitting this stuff there once I have the basic things
> > >> > working.  What
> > >> > do you feel?
> > >> I don't know but I would hope there are not problems - if not let me
> > >> know and I'll try to help.
> > >>
> > >> Jim
> > >>
> > >>
> > >> ---------------------------------------------------------------------
> > >> 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: Pass-by-value support for remotable interfaces

Posted by Venkata Krishnan <fo...@gmail.com>.

Hi Raymond,

Thanks.  Am going ahead with this.

- Venkat

On 12/13/06, Raymond Feng <en...@gmail.com> wrote:
>
> Hi, Venkat.
>
> You don't have to create a new extension point here as we already have
> one:
>
> org.apache.tuscany.spi.DataBinding
> org.apache.tuscany.spi.DataBindingRegistry
>
> You can just add the copy(...) method to
> "org.apache.tuscany.spi.DataBinding".
>
> Thanks,
> Raymond
>
> ----- Original Message -----
> From: "Venkata Krishnan" <fo...@gmail.com>
> To: <tu...@ws.apache.org>
> Sent: Wednesday, December 13, 2006 2:39 AM
> Subject: Re: Pass-by-value support for remotable interfaces
>
>
> > Hi Raymond,
> >
> > Here is what I have thought about the databinding dependent copying: -
> >
> > - Create an interface called 'DataCopier' that has 'copy' and
> > 'getDataBinding' methods.
> > - Have various databindings implement this interface.  For example
> > OMElementCopier, SDOCopier and so on.
> > - In the PassByValueInterceptor, have 'copier' object. i.e. in the wire
> > post
> > processor we look at the databinding of the target and create an
> > appropriate
> > copier.  We then configure the PassByValueIntercpetor with this copier
> > object.  As part of the invoke method the interceptor will call the
> > Copier's
> > copy method.
> > - As in the case of transformers, we can have a registry of copiers
> keyed
> > by
> > their databinding.
> >
> > Will this approach work?  Have I missed out something in this ?  Thanks.
> >
> > - Venkat
> >
> > On 12/8/06, Jim Marino <jm...@myromatours.com> wrote:
> >>
> >> >
> >> >
> >> > Well here is what I picked up from the specs and C&I model
> >> > "The @AllowsPassByReference annotation on the implementation of a
> >> > remotable
> >> > service is used to either declare that calls to the whole interface
> or
> >> > individual methods allow pass by reference." and  "Either a whole
> >> > class
> >> > implementing a remotable service or the individual remotable
> >> > service method
> >> > implementation can be annotated using the @AllowsPassByReference
> >> > annotation.
> >> > "
> >> >
> >> > and then there are samples as well that show the annotations being
> >> > used in
> >> > these two ways.  HenceI have stared to think this way.
> >> >
> >> Yes they are in there but I believe we changed that and may not have
> >> updated the spec. At least that was my and Mike Rowley's
> >> recollection.  Let me check tomorrow. We've changed a number of
> >> things back and forth so it's quite possible I don't remember where
> >> we wound up. If it is per operation, that is potentially very error-
> >> prone so I will take it up with the spec group.
> >> >
> >> >
> >> > I am yet to take a look at the PolicyBuilder related stuff.  Will
> >> > take this
> >> > to completion and then migrate to that.   I am most certain it
> >> > would be no
> >> > problem fitting this stuff there once I have the basic things
> >> > working.  What
> >> > do you feel?
> >> I don't know but I would hope there are not problems - if not let me
> >> know and I'll try to help.
> >>
> >> Jim
> >>
> >>
> >> ---------------------------------------------------------------------
> >> 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: Pass-by-value support for remotable interfaces

Posted by Raymond Feng <en...@gmail.com>.

Hi, Venkat.

You don't have to create a new extension point here as we already have one:

org.apache.tuscany.spi.DataBinding
org.apache.tuscany.spi.DataBindingRegistry

You can just add the copy(...) method to 
"org.apache.tuscany.spi.DataBinding".

Thanks,
Raymond

----- Original Message ----- 
From: "Venkata Krishnan" <fo...@gmail.com>
To: <tu...@ws.apache.org>
Sent: Wednesday, December 13, 2006 2:39 AM
Subject: Re: Pass-by-value support for remotable interfaces


> Hi Raymond,
>
> Here is what I have thought about the databinding dependent copying: -
>
> - Create an interface called 'DataCopier' that has 'copy' and
> 'getDataBinding' methods.
> - Have various databindings implement this interface.  For example
> OMElementCopier, SDOCopier and so on.
> - In the PassByValueInterceptor, have 'copier' object. i.e. in the wire 
> post
> processor we look at the databinding of the target and create an 
> appropriate
> copier.  We then configure the PassByValueIntercpetor with this copier
> object.  As part of the invoke method the interceptor will call the 
> Copier's
> copy method.
> - As in the case of transformers, we can have a registry of copiers keyed 
> by
> their databinding.
>
> Will this approach work?  Have I missed out something in this ?  Thanks.
>
> - Venkat
>
> On 12/8/06, Jim Marino <jm...@myromatours.com> wrote:
>>
>> >
>> >
>> > Well here is what I picked up from the specs and C&I model
>> > "The @AllowsPassByReference annotation on the implementation of a
>> > remotable
>> > service is used to either declare that calls to the whole interface or
>> > individual methods allow pass by reference." and  "Either a whole
>> > class
>> > implementing a remotable service or the individual remotable
>> > service method
>> > implementation can be annotated using the @AllowsPassByReference
>> > annotation.
>> > "
>> >
>> > and then there are samples as well that show the annotations being
>> > used in
>> > these two ways.  HenceI have stared to think this way.
>> >
>> Yes they are in there but I believe we changed that and may not have
>> updated the spec. At least that was my and Mike Rowley's
>> recollection.  Let me check tomorrow. We've changed a number of
>> things back and forth so it's quite possible I don't remember where
>> we wound up. If it is per operation, that is potentially very error-
>> prone so I will take it up with the spec group.
>> >
>> >
>> > I am yet to take a look at the PolicyBuilder related stuff.  Will
>> > take this
>> > to completion and then migrate to that.   I am most certain it
>> > would be no
>> > problem fitting this stuff there once I have the basic things
>> > working.  What
>> > do you feel?
>> I don't know but I would hope there are not problems - if not let me
>> know and I'll try to help.
>>
>> Jim
>>
>>
>> ---------------------------------------------------------------------
>> 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: Pass-by-value support for remotable interfaces

Posted by Venkata Krishnan <fo...@gmail.com>.

Hi Raymond,

Here is what I have thought about the databinding dependent copying: -

- Create an interface called 'DataCopier' that has 'copy' and
'getDataBinding' methods.
- Have various databindings implement this interface.  For example
OMElementCopier, SDOCopier and so on.
- In the PassByValueInterceptor, have 'copier' object. i.e. in the wire post
processor we look at the databinding of the target and create an appropriate
copier.  We then configure the PassByValueIntercpetor with this copier
object.  As part of the invoke method the interceptor will call the Copier's
copy method.
- As in the case of transformers, we can have a registry of copiers keyed by
their databinding.

Will this approach work?  Have I missed out something in this ?  Thanks.

- Venkat

On 12/8/06, Jim Marino <jm...@myromatours.com> wrote:
>
> >
> >
> > Well here is what I picked up from the specs and C&I model
> > "The @AllowsPassByReference annotation on the implementation of a
> > remotable
> > service is used to either declare that calls to the whole interface or
> > individual methods allow pass by reference." and  "Either a whole
> > class
> > implementing a remotable service or the individual remotable
> > service method
> > implementation can be annotated using the @AllowsPassByReference
> > annotation.
> > "
> >
> > and then there are samples as well that show the annotations being
> > used in
> > these two ways.  HenceI have stared to think this way.
> >
> Yes they are in there but I believe we changed that and may not have
> updated the spec. At least that was my and Mike Rowley's
> recollection.  Let me check tomorrow. We've changed a number of
> things back and forth so it's quite possible I don't remember where
> we wound up. If it is per operation, that is potentially very error-
> prone so I will take it up with the spec group.
> >
> >
> > I am yet to take a look at the PolicyBuilder related stuff.  Will
> > take this
> > to completion and then migrate to that.   I am most certain it
> > would be no
> > problem fitting this stuff there once I have the basic things
> > working.  What
> > do you feel?
> I don't know but I would hope there are not problems - if not let me
> know and I'll try to help.
>
> Jim
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>

Re: Pass-by-value support for remotable interfaces

Posted by Jim Marino <jm...@myromatours.com>.

>
>
> Well here is what I picked up from the specs and C&I model
> "The @AllowsPassByReference annotation on the implementation of a  
> remotable
> service is used to either declare that calls to the whole interface or
> individual methods allow pass by reference." and  "Either a whole  
> class
> implementing a remotable service or the individual remotable  
> service method
> implementation can be annotated using the @AllowsPassByReference  
> annotation.
> "
>
> and then there are samples as well that show the annotations being  
> used in
> these two ways.  HenceI have stared to think this way.
>
Yes they are in there but I believe we changed that and may not have  
updated the spec. At least that was my and Mike Rowley's  
recollection.  Let me check tomorrow. We've changed a number of  
things back and forth so it's quite possible I don't remember where  
we wound up. If it is per operation, that is potentially very error- 
prone so I will take it up with the spec group.
>
>
> I am yet to take a look at the PolicyBuilder related stuff.  Will  
> take this
> to completion and then migrate to that.   I am most certain it  
> would be no
> problem fitting this stuff there once I have the basic things  
> working.  What
> do you feel?
I don't know but I would hope there are not problems - if not let me  
know and I'll try to help.

Jim


---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org

Re: Pass-by-value support for remotable interfaces

Posted by Venkata Krishnan <fo...@gmail.com>.

Hi Jim,

Please see my comments inline.

Thanks

- Venkat

On 12/7/06, Jim Marino <jm...@myromatours.com> wrote:
>
> Hi Venkat,
>
> Comments inline.
> On Dec 7, 2006, at 9:30 AM, Venkata Krishnan wrote:
>
> > Hi Raymond,
> >
> > Thanks.  Will take a look at your comments and get some understanding.
> >
> > Meanwhile I have gone ahead with '@AllowsPassByReference'.  I have
> > been able
> > to get this working for the interface level.  I created an
> > AllowPassByReference implementation processor and am able to deal
> > with this.
> AllowsPassByReference applies to the entire service contract, not per
> operation. A component implementation could, however, offer both
> local and remote services. Also, remember pass-by-ref is the default
> semantics for local services, which are the default type of service
> in SCA.


Well here is what I picked up from the specs and C&I model
"The @AllowsPassByReference annotation on the implementation of a remotable
service is used to either declare that calls to the whole interface or
individual methods allow pass by reference." and  "Either a whole class
implementing a remotable service or the individual remotable service method
implementation can be annotated using the @AllowsPassByReference annotation.
"

and then there are samples as well that show the annotations being used in
these two ways.  HenceI have stared to think this way.

>
> > Now if this annotation is to be at the method level then it seems
> > to be bit
> > tricky to get this information about which method has this stuff
> > from the
> > Implemenation processing phase over to the wire precessors.   I am
> > thinking
> > of having list of methods (with complete signature info) that have the
> > @AllowsPassByReference populated into the componentType and then
> > inject this
> > into the Components during ComponentBulding phase.
> You won't need to do this per the semantics described above.
> >   Finally pull out these
> > components during the wire proecessing (which is our current
> > process(Outbound, Inbound)) and then access the list of methods
> > that have
> > this annotation.  Is there a better way?
> This should be part of the policy builder, not the wire post
> processor I think. The latter deals more with optimizations and
> transformations of an entire wire.


I am yet to take a look at the PolicyBuilder related stuff.  Will take this
to completion and then migrate to that.   I am most certain it would be no
problem fitting this stuff there once I have the basic things working.  What
do you feel?

Jim
>
> >
> > Thanks
> >
> > - Venkat
> >
> >
> > On 12/7/06, Raymond Feng <en...@gmail.com> wrote:
> >>
> >> Hi, Venkat.
> >>
> >> I'll review the path. Please see my comments below.
> >>
> >> Thanks,
> >> Raymond
> >>
> >> ----- Original Message -----
> >> From: "Venkata Krishnan" <fo...@gmail.com>
> >> To: <tu...@ws.apache.org>
> >> Sent: Thursday, December 07, 2006 1:55 AM
> >> Subject: Re: Pass-by-value support for remotable interfaces
> >>
> >>
> >> > Hi Raymond,
> >> >
> >> > I have attached a patch for this in the JIRA
> >> > http://issues.apache.org/jira/browse/TUSCANY-969 as a first
> >> increment.
> >> > Let
> >> > me know if its ok to commit and I will go ahead and do it.  This
> >> is the
> >> > first increment and will add more as I get clarity on the
> >> following: -
> >> >
> >> > - why is the databinding provider dependent copy required?  The
> >> > passbyvalue
> >> > thing happens after the data mediation - when data is already
> >> tranformed
> >> > into consumable java objects for the target component.  So just
> >> need to
> >> > make
> >> > copies of them isn't it.  I guess I am missing some bigger scenario
> >> here.
> >> >
> >>
> >> There are two thoughts behind the databinding-specific copy:
> >>
> >> 1. Data in other bindings such as SDO, JAXB other than the default
> >> java
> >> databinding can have their own way to copy the data, for example,
> >> copy via
> >> XML or even more efficiently, like the SDO cross scope copy. Copy by
> >> serialization is the alogorithm for java.
> >>
> >> 2. There're opportunities for optimization. As we know,
> >> transformation
> >> accross databindings have copied the data and we should be able to
> >> eliminate
> >> the copy() in the pass-by-value interceptor in some cases.
> >>
> >> > - right now I add the passbyvalue interceptor when processing
> >> wires that
> >> > connect two components.. i.e. the outbound of a source (consumer
> >> > component)
> >> > and the inbound of a target (provider component).  i.e. in the
> >> Processor
> >> > that I have implemented I only do this in the process(OutboundWire,
> >> > InboundWire).  I have understood that in the other case of
> >> > 'process(InboundWire, OutboundWire)' this might not be required.
> >> >
> >>
> >> Yes,  'process(InboundWire, OutboundWire)' case is for composite
> >> services
> >> and references. We discussed before and we asume that the binding
> >> implementation could take care of that considering the data will go
> >> accross
> >> some protocol/transport layer.
> >>
> >> > - When a particular service method takes two arguments that
> >> point to the
> >> > same object reference, when copying over we too make just one
> >> copy.  Maybe
> >> > in the consumer component's context of things these two
> >> arguments point
> >> to
> >> > the same object, but in the producers context of the service
> >> these two
> >> > might
> >> > wished to be seen as distinct ones that the producer can deal.
> >> If this
> >> is
> >> > the case then it might so happen that while the producer is
> >> modifying
> >> arg1
> >> > it is actually unaware that it is also changing arg2
> >> implicitly.  Am I
> >> > making sense ?
> >>
> >> This is an issue that Mike Edwards has pointed out. Different
> >> protocols
> >> have
> >> different requirements. RMI requires one copy while web service
> >> requires
> >> two. In the java case, if we serialize/deserilze the top Object[],
> >> we'll
> >> get
> >> the same copy for the elements pointing to the same instance in the
> >> Object[]. But if we serialize/deserialize the elements one by one,
> >> we'll
> >> get
> >> multiple copyies.
> >>
> >> >
> >> > Thanks
> >> >
> >> > - Venkat
> >> >
> >> > On 12/6/06, Jim Marino <jm...@myromatours.com> wrote:
> >> >>
> >> >>
> >> >> On Dec 6, 2006, at 1:52 AM, Venkata Krishnan wrote:
> >> >>
> >> >> > Hi,
> >> >> >
> >> >> > Is there any way I can control the order in which the
> >> >> > WirePostProcessors are
> >> >> > loaded.  For example I would always want the PassByValue
> >> processor
> >> >> > to be
> >> >> > called last so that I ensure that the PassByValue interceptor
> >> is at
> >> >> > the head
> >> >> > of the invocation chain.
> >> >> >
> >> >> The best way to handle this is by implementing a phase
> >> mechanism. I
> >> >> can look into adding this. BTW, why is this a WirePostProcessor
> >> vs. a
> >> >> TargetPolicyBuilder (which has phases)?
> >> >>
> >> >> Jim
> >> >>
> >> >> > Thanks.
> >> >> >
> >> >> > - Venkat
> >> >> >
> >> >> > On 12/6/06, Venkata Krishnan <fo...@gmail.com> wrote:
> >> >> >>
> >> >> >> HI Jim,
> >> >> >>
> >> >> >> Yes, the pass-by-value interceptor will come first exactly
> >> for the
> >> >> >> reasons
> >> >> >> you have mentioned.  I will get a testcase across soon.
> >> >> >>
> >> >> >> Thanks
> >> >> >>
> >> >> >> - Venkat
> >> >> >>
> >> >> >> On 12/6/06, Jim Marino <jm...@myromatours.com> wrote:
> >> >> >> >
> >> >> >> >
> >> >> >> > 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 <jm...@myromatours.com> 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 <jm...@myromatours.com> 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 <en...@gmail.com> 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" <fo...@gmail.com>
> >> >> >> > >> >> >> To: <tuscany-dev@ws.apache.org >
> >> >> >> > >> >> >> 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 <enjoyjava@gmail.com >
> >> 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" < for.svkrish@gmail.com>
> >> >> >> > >> >> >> >> To: <tu...@ws.apache.org>
> >> >> >> > >> >> >> >> 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 <en...@gmail.com>
> >> >> >> wrote:
> >> >> >> > >> >> >> >> >>
> >> >> >> > >> >> >> >> >> ----- Original Message -----
> >> >> >> > >> >> >> >> >> From: "Mike Edwards"
> >> >> >> <mike.edwards.inglenook@gmail.com >
> >> >> >> > >> >> >> >> >> To: <tuscany-dev@ws.apache.org >
> >> >> >> > >> >> >> >> >> 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-
> >> >> >> > >> >> 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
> >> >>
> >> >>
> >> >
> >>
> >>
> >> ---------------------------------------------------------------------
> >> 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: Pass-by-value support for remotable interfaces

Posted by Jim Marino <jm...@myromatours.com>.

Hi Venkat,

Comments inline.
On Dec 7, 2006, at 9:30 AM, Venkata Krishnan wrote:

> Hi Raymond,
>
> Thanks.  Will take a look at your comments and get some understanding.
>
> Meanwhile I have gone ahead with '@AllowsPassByReference'.  I have  
> been able
> to get this working for the interface level.  I created an
> AllowPassByReference implementation processor and am able to deal  
> with this.
AllowsPassByReference applies to the entire service contract, not per  
operation. A component implementation could, however, offer both  
local and remote services. Also, remember pass-by-ref is the default  
semantics for local services, which are the default type of service  
in SCA.
>
> Now if this annotation is to be at the method level then it seems  
> to be bit
> tricky to get this information about which method has this stuff  
> from the
> Implemenation processing phase over to the wire precessors.   I am  
> thinking
> of having list of methods (with complete signature info) that have the
> @AllowsPassByReference populated into the componentType and then  
> inject this
> into the Components during ComponentBulding phase.
You won't need to do this per the semantics described above.
>   Finally pull out these
> components during the wire proecessing (which is our current
> process(Outbound, Inbound)) and then access the list of methods  
> that have
> this annotation.  Is there a better way?
This should be part of the policy builder, not the wire post  
processor I think. The latter deals more with optimizations and  
transformations of an entire wire.

Jim

>
> Thanks
>
> - Venkat
>
>
> On 12/7/06, Raymond Feng <en...@gmail.com> wrote:
>>
>> Hi, Venkat.
>>
>> I'll review the path. Please see my comments below.
>>
>> Thanks,
>> Raymond
>>
>> ----- Original Message -----
>> From: "Venkata Krishnan" <fo...@gmail.com>
>> To: <tu...@ws.apache.org>
>> Sent: Thursday, December 07, 2006 1:55 AM
>> Subject: Re: Pass-by-value support for remotable interfaces
>>
>>
>> > Hi Raymond,
>> >
>> > I have attached a patch for this in the JIRA
>> > http://issues.apache.org/jira/browse/TUSCANY-969 as a first  
>> increment.
>> > Let
>> > me know if its ok to commit and I will go ahead and do it.  This  
>> is the
>> > first increment and will add more as I get clarity on the  
>> following: -
>> >
>> > - why is the databinding provider dependent copy required?  The
>> > passbyvalue
>> > thing happens after the data mediation - when data is already  
>> tranformed
>> > into consumable java objects for the target component.  So just  
>> need to
>> > make
>> > copies of them isn't it.  I guess I am missing some bigger scenario
>> here.
>> >
>>
>> There are two thoughts behind the databinding-specific copy:
>>
>> 1. Data in other bindings such as SDO, JAXB other than the default  
>> java
>> databinding can have their own way to copy the data, for example,  
>> copy via
>> XML or even more efficiently, like the SDO cross scope copy. Copy by
>> serialization is the alogorithm for java.
>>
>> 2. There're opportunities for optimization. As we know,  
>> transformation
>> accross databindings have copied the data and we should be able to
>> eliminate
>> the copy() in the pass-by-value interceptor in some cases.
>>
>> > - right now I add the passbyvalue interceptor when processing  
>> wires that
>> > connect two components.. i.e. the outbound of a source (consumer
>> > component)
>> > and the inbound of a target (provider component).  i.e. in the  
>> Processor
>> > that I have implemented I only do this in the process(OutboundWire,
>> > InboundWire).  I have understood that in the other case of
>> > 'process(InboundWire, OutboundWire)' this might not be required.
>> >
>>
>> Yes,  'process(InboundWire, OutboundWire)' case is for composite  
>> services
>> and references. We discussed before and we asume that the binding
>> implementation could take care of that considering the data will go
>> accross
>> some protocol/transport layer.
>>
>> > - When a particular service method takes two arguments that  
>> point to the
>> > same object reference, when copying over we too make just one
>> copy.  Maybe
>> > in the consumer component's context of things these two  
>> arguments point
>> to
>> > the same object, but in the producers context of the service  
>> these two
>> > might
>> > wished to be seen as distinct ones that the producer can deal.   
>> If this
>> is
>> > the case then it might so happen that while the producer is  
>> modifying
>> arg1
>> > it is actually unaware that it is also changing arg2  
>> implicitly.  Am I
>> > making sense ?
>>
>> This is an issue that Mike Edwards has pointed out. Different  
>> protocols
>> have
>> different requirements. RMI requires one copy while web service  
>> requires
>> two. In the java case, if we serialize/deserilze the top Object[],  
>> we'll
>> get
>> the same copy for the elements pointing to the same instance in the
>> Object[]. But if we serialize/deserialize the elements one by one,  
>> we'll
>> get
>> multiple copyies.
>>
>> >
>> > Thanks
>> >
>> > - Venkat
>> >
>> > On 12/6/06, Jim Marino <jm...@myromatours.com> wrote:
>> >>
>> >>
>> >> On Dec 6, 2006, at 1:52 AM, Venkata Krishnan wrote:
>> >>
>> >> > Hi,
>> >> >
>> >> > Is there any way I can control the order in which the
>> >> > WirePostProcessors are
>> >> > loaded.  For example I would always want the PassByValue  
>> processor
>> >> > to be
>> >> > called last so that I ensure that the PassByValue interceptor  
>> is at
>> >> > the head
>> >> > of the invocation chain.
>> >> >
>> >> The best way to handle this is by implementing a phase  
>> mechanism. I
>> >> can look into adding this. BTW, why is this a WirePostProcessor  
>> vs. a
>> >> TargetPolicyBuilder (which has phases)?
>> >>
>> >> Jim
>> >>
>> >> > Thanks.
>> >> >
>> >> > - Venkat
>> >> >
>> >> > On 12/6/06, Venkata Krishnan <fo...@gmail.com> wrote:
>> >> >>
>> >> >> HI Jim,
>> >> >>
>> >> >> Yes, the pass-by-value interceptor will come first exactly  
>> for the
>> >> >> reasons
>> >> >> you have mentioned.  I will get a testcase across soon.
>> >> >>
>> >> >> Thanks
>> >> >>
>> >> >> - Venkat
>> >> >>
>> >> >> On 12/6/06, Jim Marino <jm...@myromatours.com> wrote:
>> >> >> >
>> >> >> >
>> >> >> > 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 <jm...@myromatours.com> 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 <jm...@myromatours.com> 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 <en...@gmail.com> 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" <fo...@gmail.com>
>> >> >> > >> >> >> To: <tuscany-dev@ws.apache.org >
>> >> >> > >> >> >> 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 <enjoyjava@gmail.com >  
>> 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" < for.svkrish@gmail.com>
>> >> >> > >> >> >> >> To: <tu...@ws.apache.org>
>> >> >> > >> >> >> >> 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 <en...@gmail.com>
>> >> >> wrote:
>> >> >> > >> >> >> >> >>
>> >> >> > >> >> >> >> >> ----- Original Message -----
>> >> >> > >> >> >> >> >> From: "Mike Edwards"
>> >> >> <mike.edwards.inglenook@gmail.com >
>> >> >> > >> >> >> >> >> To: <tuscany-dev@ws.apache.org >
>> >> >> > >> >> >> >> >> 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-
>> >> >> > >> >> 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
>> >>
>> >>
>> >
>>
>>
>> ---------------------------------------------------------------------
>> 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: Pass-by-value support for remotable interfaces

Posted by Venkata Krishnan <fo...@gmail.com>.

Hi Raymond,

Thanks.  Will take a look at your comments and get some understanding.

Meanwhile I have gone ahead with '@AllowsPassByReference'.  I have been able
to get this working for the interface level.  I created an
AllowPassByReference implementation processor and am able to deal with this.

Now if this annotation is to be at the method level then it seems to be bit
tricky to get this information about which method has this stuff from the
Implemenation processing phase over to the wire precessors.   I am thinking
of having list of methods (with complete signature info) that have the
@AllowsPassByReference populated into the componentType and then inject this
into the Components during ComponentBulding phase.  Finally pull out these
components during the wire proecessing (which is our current
process(Outbound, Inbound)) and then access the list of methods that have
this annotation.  Is there a better way?

Thanks

- Venkat


On 12/7/06, Raymond Feng <en...@gmail.com> wrote:
>
> Hi, Venkat.
>
> I'll review the path. Please see my comments below.
>
> Thanks,
> Raymond
>
> ----- Original Message -----
> From: "Venkata Krishnan" <fo...@gmail.com>
> To: <tu...@ws.apache.org>
> Sent: Thursday, December 07, 2006 1:55 AM
> Subject: Re: Pass-by-value support for remotable interfaces
>
>
> > Hi Raymond,
> >
> > I have attached a patch for this in the JIRA
> > http://issues.apache.org/jira/browse/TUSCANY-969 as a first increment.
> > Let
> > me know if its ok to commit and I will go ahead and do it.  This is the
> > first increment and will add more as I get clarity on the following: -
> >
> > - why is the databinding provider dependent copy required?  The
> > passbyvalue
> > thing happens after the data mediation - when data is already tranformed
> > into consumable java objects for the target component.  So just need to
> > make
> > copies of them isn't it.  I guess I am missing some bigger scenario
> here.
> >
>
> There are two thoughts behind the databinding-specific copy:
>
> 1. Data in other bindings such as SDO, JAXB other than the default java
> databinding can have their own way to copy the data, for example, copy via
> XML or even more efficiently, like the SDO cross scope copy. Copy by
> serialization is the alogorithm for java.
>
> 2. There're opportunities for optimization. As we know, transformation
> accross databindings have copied the data and we should be able to
> eliminate
> the copy() in the pass-by-value interceptor in some cases.
>
> > - right now I add the passbyvalue interceptor when processing wires that
> > connect two components.. i.e. the outbound of a source (consumer
> > component)
> > and the inbound of a target (provider component).  i.e. in the Processor
> > that I have implemented I only do this in the process(OutboundWire,
> > InboundWire).  I have understood that in the other case of
> > 'process(InboundWire, OutboundWire)' this might not be required.
> >
>
> Yes,  'process(InboundWire, OutboundWire)' case is for composite services
> and references. We discussed before and we asume that the binding
> implementation could take care of that considering the data will go
> accross
> some protocol/transport layer.
>
> > - When a particular service method takes two arguments that point to the
> > same object reference, when copying over we too make just one
> copy.  Maybe
> > in the consumer component's context of things these two arguments point
> to
> > the same object, but in the producers context of the service these two
> > might
> > wished to be seen as distinct ones that the producer can deal.  If this
> is
> > the case then it might so happen that while the producer is modifying
> arg1
> > it is actually unaware that it is also changing arg2 implicitly.  Am I
> > making sense ?
>
> This is an issue that Mike Edwards has pointed out. Different protocols
> have
> different requirements. RMI requires one copy while web service requires
> two. In the java case, if we serialize/deserilze the top Object[], we'll
> get
> the same copy for the elements pointing to the same instance in the
> Object[]. But if we serialize/deserialize the elements one by one, we'll
> get
> multiple copyies.
>
> >
> > Thanks
> >
> > - Venkat
> >
> > On 12/6/06, Jim Marino <jm...@myromatours.com> wrote:
> >>
> >>
> >> On Dec 6, 2006, at 1:52 AM, Venkata Krishnan wrote:
> >>
> >> > Hi,
> >> >
> >> > Is there any way I can control the order in which the
> >> > WirePostProcessors are
> >> > loaded.  For example I would always want the PassByValue processor
> >> > to be
> >> > called last so that I ensure that the PassByValue interceptor is at
> >> > the head
> >> > of the invocation chain.
> >> >
> >> The best way to handle this is by implementing a phase mechanism. I
> >> can look into adding this. BTW, why is this a WirePostProcessor vs. a
> >> TargetPolicyBuilder (which has phases)?
> >>
> >> Jim
> >>
> >> > Thanks.
> >> >
> >> > - Venkat
> >> >
> >> > On 12/6/06, Venkata Krishnan <fo...@gmail.com> wrote:
> >> >>
> >> >> HI Jim,
> >> >>
> >> >> Yes, the pass-by-value interceptor will come first exactly for the
> >> >> reasons
> >> >> you have mentioned.  I will get a testcase across soon.
> >> >>
> >> >> Thanks
> >> >>
> >> >> - Venkat
> >> >>
> >> >> On 12/6/06, Jim Marino <jm...@myromatours.com> wrote:
> >> >> >
> >> >> >
> >> >> > 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 <jm...@myromatours.com> 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 <jm...@myromatours.com> 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 <en...@gmail.com> 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" <fo...@gmail.com>
> >> >> > >> >> >> To: <tuscany-dev@ws.apache.org >
> >> >> > >> >> >> 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 <enjoyjava@gmail.com > 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" < for.svkrish@gmail.com>
> >> >> > >> >> >> >> To: <tu...@ws.apache.org>
> >> >> > >> >> >> >> 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 <en...@gmail.com>
> >> >> wrote:
> >> >> > >> >> >> >> >>
> >> >> > >> >> >> >> >> ----- Original Message -----
> >> >> > >> >> >> >> >> From: "Mike Edwards"
> >> >> <mike.edwards.inglenook@gmail.com >
> >> >> > >> >> >> >> >> To: <tuscany-dev@ws.apache.org >
> >> >> > >> >> >> >> >> 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-
> >> >> > >> >> 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
> >>
> >>
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>

Re: Pass-by-value support for remotable interfaces

Posted by Venkata Krishnan <fo...@gmail.com>.

HI... I figure this out as something that can be done by setting the 'init'
attribute.  But then what is a safe value to ensure that this is the last
processor called.  Right now, ( to be very safe) I have put it as '10'.  Now
this processor gets invoked lastly.

Thanks.

- Venkat

On 12/6/06, Venkata Krishnan <fo...@gmail.com> wrote:
>
> Hi,
>
> Is there any way I can control the order in which the WirePostProcessors
> are loaded.  For example I would always want the PassByValue processor to be
> called last so that I ensure that the PassByValue interceptor is at the head
> of the invocation chain.
>
> Thanks.
>
> - Venkat
>
> On 12/6/06, Venkata Krishnan <fo...@gmail.com> wrote:
> >
> > HI Jim,
> >
> > Yes, the pass-by-value interceptor will come first exactly for the
> > reasons you have mentioned.  I will get a testcase across soon.
> >
> > Thanks
> >
> > - Venkat
> >
> > On 12/6/06, Jim Marino < jmarino@myromatours.com> wrote:
> > >
> > >
> > > 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 < jmarino@myromatours.com> 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 < jmarino@myromatours.com> 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 <enjoyjava@gmail.com > 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" <fo...@gmail.com>
> > > >> >> >> To: < tuscany-dev@ws.apache.org >
> > > >> >> >> 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 < enjoyjava@gmail.com > 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" < for.svkrish@gmail.com>
> > > >> >> >> >> To: <tuscany-dev@ws.apache.org >
> > > >> >> >> >> 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 < enjoyjava@gmail.com> wrote:
> > > >> >> >> >> >>
> > > >> >> >> >> >> ----- Original Message -----
> > > >> >> >> >> >> From: "Mike Edwards" < mike.edwards.inglenook@gmail.com
> > > >
> > > >> >> >> >> >> To: <tuscany-dev@ws.apache.org >
> > > >> >> >> >> >> 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-
> > > >> >> 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: Pass-by-value support for remotable interfaces

Posted by Raymond Feng <en...@gmail.com>.

Hi, Venkat.

I'll review the path. Please see my comments below.

Thanks,
Raymond

----- Original Message ----- 
From: "Venkata Krishnan" <fo...@gmail.com>
To: <tu...@ws.apache.org>
Sent: Thursday, December 07, 2006 1:55 AM
Subject: Re: Pass-by-value support for remotable interfaces


> Hi Raymond,
>
> I have attached a patch for this in the JIRA
> http://issues.apache.org/jira/browse/TUSCANY-969 as a first increment. 
> Let
> me know if its ok to commit and I will go ahead and do it.  This is the
> first increment and will add more as I get clarity on the following: -
>
> - why is the databinding provider dependent copy required?  The 
> passbyvalue
> thing happens after the data mediation - when data is already tranformed
> into consumable java objects for the target component.  So just need to 
> make
> copies of them isn't it.  I guess I am missing some bigger scenario here.
>

There are two thoughts behind the databinding-specific copy:

1. Data in other bindings such as SDO, JAXB other than the default java 
databinding can have their own way to copy the data, for example, copy via 
XML or even more efficiently, like the SDO cross scope copy. Copy by 
serialization is the alogorithm for java.

2. There're opportunities for optimization. As we know, transformation 
accross databindings have copied the data and we should be able to eliminate 
the copy() in the pass-by-value interceptor in some cases.

> - right now I add the passbyvalue interceptor when processing wires that
> connect two components.. i.e. the outbound of a source (consumer 
> component)
> and the inbound of a target (provider component).  i.e. in the Processor
> that I have implemented I only do this in the process(OutboundWire,
> InboundWire).  I have understood that in the other case of
> 'process(InboundWire, OutboundWire)' this might not be required.
>

Yes,  'process(InboundWire, OutboundWire)' case is for composite services 
and references. We discussed before and we asume that the binding 
implementation could take care of that considering the data will go accross 
some protocol/transport layer.

> - When a particular service method takes two arguments that point to the
> same object reference, when copying over we too make just one copy.  Maybe
> in the consumer component's context of things these two arguments point to
> the same object, but in the producers context of the service these two 
> might
> wished to be seen as distinct ones that the producer can deal.  If this is
> the case then it might so happen that while the producer is modifying arg1
> it is actually unaware that it is also changing arg2 implicitly.  Am I
> making sense ?

This is an issue that Mike Edwards has pointed out. Different protocols have 
different requirements. RMI requires one copy while web service requires 
two. In the java case, if we serialize/deserilze the top Object[], we'll get 
the same copy for the elements pointing to the same instance in the 
Object[]. But if we serialize/deserialize the elements one by one, we'll get 
multiple copyies.

>
> Thanks
>
> - Venkat
>
> On 12/6/06, Jim Marino <jm...@myromatours.com> wrote:
>>
>>
>> On Dec 6, 2006, at 1:52 AM, Venkata Krishnan wrote:
>>
>> > Hi,
>> >
>> > Is there any way I can control the order in which the
>> > WirePostProcessors are
>> > loaded.  For example I would always want the PassByValue processor
>> > to be
>> > called last so that I ensure that the PassByValue interceptor is at
>> > the head
>> > of the invocation chain.
>> >
>> The best way to handle this is by implementing a phase mechanism. I
>> can look into adding this. BTW, why is this a WirePostProcessor vs. a
>> TargetPolicyBuilder (which has phases)?
>>
>> Jim
>>
>> > Thanks.
>> >
>> > - Venkat
>> >
>> > On 12/6/06, Venkata Krishnan <fo...@gmail.com> wrote:
>> >>
>> >> HI Jim,
>> >>
>> >> Yes, the pass-by-value interceptor will come first exactly for the
>> >> reasons
>> >> you have mentioned.  I will get a testcase across soon.
>> >>
>> >> Thanks
>> >>
>> >> - Venkat
>> >>
>> >> On 12/6/06, Jim Marino <jm...@myromatours.com> wrote:
>> >> >
>> >> >
>> >> > 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 <jm...@myromatours.com> 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 <jm...@myromatours.com> 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 <en...@gmail.com> 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" <fo...@gmail.com>
>> >> > >> >> >> To: <tuscany-dev@ws.apache.org >
>> >> > >> >> >> 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 <enjoyjava@gmail.com > 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" < for.svkrish@gmail.com>
>> >> > >> >> >> >> To: <tu...@ws.apache.org>
>> >> > >> >> >> >> 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 <en...@gmail.com>
>> >> wrote:
>> >> > >> >> >> >> >>
>> >> > >> >> >> >> >> ----- Original Message -----
>> >> > >> >> >> >> >> From: "Mike Edwards"
>> >> <mike.edwards.inglenook@gmail.com >
>> >> > >> >> >> >> >> To: <tuscany-dev@ws.apache.org >
>> >> > >> >> >> >> >> 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-
>> >> > >> >> 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
>>
>>
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org

Re: Pass-by-value support for remotable interfaces

Posted by Venkata Krishnan <fo...@gmail.com>.

Hi Raymond,

I have attached a patch for this in the JIRA
http://issues.apache.org/jira/browse/TUSCANY-969 as a first increment.  Let
me know if its ok to commit and I will go ahead and do it.  This is the
first increment and will add more as I get clarity on the following: -

- why is the databinding provider dependent copy required?  The passbyvalue
thing happens after the data mediation - when data is already tranformed
into consumable java objects for the target component.  So just need to make
copies of them isn't it.  I guess I am missing some bigger scenario here.

- right now I add the passbyvalue interceptor when processing wires that
connect two components.. i.e. the outbound of a source (consumer component)
and the inbound of a target (provider component).  i.e. in the Processor
that I have implemented I only do this in the process(OutboundWire,
InboundWire).  I have understood that in the other case of
'process(InboundWire, OutboundWire)' this might not be required.

- When a particular service method takes two arguments that point to the
same object reference, when copying over we too make just one copy.  Maybe
in the consumer component's context of things these two arguments point to
the same object, but in the producers context of the service these two might
wished to be seen as distinct ones that the producer can deal.  If this is
the case then it might so happen that while the producer is modifying arg1
it is actually unaware that it is also changing arg2 implicitly.  Am I
making sense ?

Thanks

- Venkat

On 12/6/06, Jim Marino <jm...@myromatours.com> wrote:
>
>
> On Dec 6, 2006, at 1:52 AM, Venkata Krishnan wrote:
>
> > Hi,
> >
> > Is there any way I can control the order in which the
> > WirePostProcessors are
> > loaded.  For example I would always want the PassByValue processor
> > to be
> > called last so that I ensure that the PassByValue interceptor is at
> > the head
> > of the invocation chain.
> >
> The best way to handle this is by implementing a phase mechanism. I
> can look into adding this. BTW, why is this a WirePostProcessor vs. a
> TargetPolicyBuilder (which has phases)?
>
> Jim
>
> > Thanks.
> >
> > - Venkat
> >
> > On 12/6/06, Venkata Krishnan <fo...@gmail.com> wrote:
> >>
> >> HI Jim,
> >>
> >> Yes, the pass-by-value interceptor will come first exactly for the
> >> reasons
> >> you have mentioned.  I will get a testcase across soon.
> >>
> >> Thanks
> >>
> >> - Venkat
> >>
> >> On 12/6/06, Jim Marino <jm...@myromatours.com> wrote:
> >> >
> >> >
> >> > 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 <jm...@myromatours.com> 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 <jm...@myromatours.com> 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 <en...@gmail.com> 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" <fo...@gmail.com>
> >> > >> >> >> To: <tuscany-dev@ws.apache.org >
> >> > >> >> >> 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 <enjoyjava@gmail.com > 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" < for.svkrish@gmail.com>
> >> > >> >> >> >> To: <tu...@ws.apache.org>
> >> > >> >> >> >> 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 <en...@gmail.com>
> >> wrote:
> >> > >> >> >> >> >>
> >> > >> >> >> >> >> ----- Original Message -----
> >> > >> >> >> >> >> From: "Mike Edwards"
> >> <mike.edwards.inglenook@gmail.com >
> >> > >> >> >> >> >> To: <tuscany-dev@ws.apache.org >
> >> > >> >> >> >> >> 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-
> >> > >> >> 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
>
>

Re: Pass-by-value support for remotable interfaces

Posted by Jim Marino <jm...@myromatours.com>.

On Dec 6, 2006, at 1:52 AM, Venkata Krishnan wrote:

> Hi,
>
> Is there any way I can control the order in which the  
> WirePostProcessors are
> loaded.  For example I would always want the PassByValue processor  
> to be
> called last so that I ensure that the PassByValue interceptor is at  
> the head
> of the invocation chain.
>
The best way to handle this is by implementing a phase mechanism. I  
can look into adding this. BTW, why is this a WirePostProcessor vs. a  
TargetPolicyBuilder (which has phases)?

Jim

> Thanks.
>
> - Venkat
>
> On 12/6/06, Venkata Krishnan <fo...@gmail.com> wrote:
>>
>> HI Jim,
>>
>> Yes, the pass-by-value interceptor will come first exactly for the  
>> reasons
>> you have mentioned.  I will get a testcase across soon.
>>
>> Thanks
>>
>> - Venkat
>>
>> On 12/6/06, Jim Marino <jm...@myromatours.com> wrote:
>> >
>> >
>> > 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 <jm...@myromatours.com> 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 <jm...@myromatours.com> 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 <en...@gmail.com> 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" <fo...@gmail.com>
>> > >> >> >> To: <tuscany-dev@ws.apache.org >
>> > >> >> >> 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 <enjoyjava@gmail.com > 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" < for.svkrish@gmail.com>
>> > >> >> >> >> To: <tu...@ws.apache.org>
>> > >> >> >> >> 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 <en...@gmail.com>  
>> wrote:
>> > >> >> >> >> >>
>> > >> >> >> >> >> ----- Original Message -----
>> > >> >> >> >> >> From: "Mike Edwards"  
>> <mike.edwards.inglenook@gmail.com >
>> > >> >> >> >> >> To: <tuscany-dev@ws.apache.org >
>> > >> >> >> >> >> 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-
>> > >> >> 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

Re: Pass-by-value support for remotable interfaces

Posted by Venkata Krishnan <fo...@gmail.com>.

Hi,

Is there any way I can control the order in which the WirePostProcessors are
loaded.  For example I would always want the PassByValue processor to be
called last so that I ensure that the PassByValue interceptor is at the head
of the invocation chain.

Thanks.

- Venkat

On 12/6/06, Venkata Krishnan <fo...@gmail.com> wrote:
>
> HI Jim,
>
> Yes, the pass-by-value interceptor will come first exactly for the reasons
> you have mentioned.  I will get a testcase across soon.
>
> Thanks
>
> - Venkat
>
> On 12/6/06, Jim Marino <jm...@myromatours.com> wrote:
> >
> >
> > 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 <jm...@myromatours.com> 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 <jm...@myromatours.com> 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 <en...@gmail.com> 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" <fo...@gmail.com>
> > >> >> >> To: <tuscany-dev@ws.apache.org >
> > >> >> >> 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 <enjoyjava@gmail.com > 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" < for.svkrish@gmail.com>
> > >> >> >> >> To: <tu...@ws.apache.org>
> > >> >> >> >> 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 <en...@gmail.com> wrote:
> > >> >> >> >> >>
> > >> >> >> >> >> ----- Original Message -----
> > >> >> >> >> >> From: "Mike Edwards" <mike.edwards.inglenook@gmail.com >
> > >> >> >> >> >> To: <tuscany-dev@ws.apache.org >
> > >> >> >> >> >> 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-
> > >> >> 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: Pass-by-value support for remotable interfaces

Posted by Venkata Krishnan <fo...@gmail.com>.

HI Jim,

Yes, the pass-by-value interceptor will come first exactly for the reasons
you have mentioned.  I will get a testcase across soon.

Thanks

- Venkat

On 12/6/06, Jim Marino <jm...@myromatours.com> wrote:
>
>
> 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 <jm...@myromatours.com> 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 <jm...@myromatours.com> 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 <en...@gmail.com> 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" <fo...@gmail.com>
> >> >> >> To: <tu...@ws.apache.org>
> >> >> >> 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 <en...@gmail.com> 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" <fo...@gmail.com>
> >> >> >> >> To: <tu...@ws.apache.org>
> >> >> >> >> 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 <en...@gmail.com> wrote:
> >> >> >> >> >>
> >> >> >> >> >> ----- Original Message -----
> >> >> >> >> >> From: "Mike Edwards" <mi...@gmail.com>
> >> >> >> >> >> To: <tuscany-dev@ws.apache.org >
> >> >> >> >> >> 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-
> >> >> 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: Pass-by-value support for remotable interfaces

Posted by Jim Marino <jm...@myromatours.com>.

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 <jm...@myromatours.com> 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 <jm...@myromatours.com> 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 <en...@gmail.com> 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" <fo...@gmail.com>
>> >> >> To: <tu...@ws.apache.org>
>> >> >> 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 <en...@gmail.com> 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" <fo...@gmail.com>
>> >> >> >> To: <tu...@ws.apache.org>
>> >> >> >> 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 <en...@gmail.com> wrote:
>> >> >> >> >>
>> >> >> >> >> ----- Original Message -----
>> >> >> >> >> From: "Mike Edwards" <mi...@gmail.com>
>> >> >> >> >> To: <tuscany-dev@ws.apache.org >
>> >> >> >> >> 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-
>> >> 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: Pass-by-value support for remotable interfaces

Posted by Venkata Krishnan <fo...@gmail.com>.

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.

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.  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.

- Venkat





On 12/5/06, Jim Marino <jm...@myromatours.com> 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 <jm...@myromatours.com> 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 <en...@gmail.com> 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" <fo...@gmail.com>
> >> >> To: <tu...@ws.apache.org>
> >> >> 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 <en...@gmail.com> 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" <fo...@gmail.com>
> >> >> >> To: <tu...@ws.apache.org>
> >> >> >> 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 <en...@gmail.com> wrote:
> >> >> >> >>
> >> >> >> >> ----- Original Message -----
> >> >> >> >> From: "Mike Edwards" <mi...@gmail.com>
> >> >> >> >> To: <tuscany-dev@ws.apache.org >
> >> >> >> >> 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-
> >> 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: Pass-by-value support for remotable interfaces

Posted by Jim Marino <jm...@myromatours.com>.

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 <jm...@myromatours.com> 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 <en...@gmail.com> 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" <fo...@gmail.com>
>> >> To: <tu...@ws.apache.org>
>> >> 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 <en...@gmail.com> 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" <fo...@gmail.com>
>> >> >> To: <tu...@ws.apache.org>
>> >> >> 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 <en...@gmail.com> wrote:
>> >> >> >>
>> >> >> >> ----- Original Message -----
>> >> >> >> From: "Mike Edwards" <mi...@gmail.com>
>> >> >> >> To: <tuscany-dev@ws.apache.org >
>> >> >> >> 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- 
>> 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: Pass-by-value support for remotable interfaces

Posted by Venkata Krishnan <fo...@gmail.com>.

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.
(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.

If I am still not clear please let me know and probably testcase is the only
way out.

Thanks

- Venkat




On 12/5/06, Jim Marino <jm...@myromatours.com> 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 <en...@gmail.com> 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" <fo...@gmail.com>
> >> To: <tu...@ws.apache.org>
> >> 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 <en...@gmail.com> 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" <fo...@gmail.com>
> >> >> To: <tu...@ws.apache.org>
> >> >> 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 <en...@gmail.com> wrote:
> >> >> >>
> >> >> >> ----- Original Message -----
> >> >> >> From: "Mike Edwards" <mi...@gmail.com>
> >> >> >> To: <tuscany-dev@ws.apache.org >
> >> >> >> 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-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: Pass-by-value support for remotable interfaces

Posted by Jim Marino <jm...@myromatours.com>.

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 <en...@gmail.com> 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" <fo...@gmail.com>
>> To: <tu...@ws.apache.org>
>> 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 <en...@gmail.com> 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" <fo...@gmail.com>
>> >> To: <tu...@ws.apache.org>
>> >> 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 <en...@gmail.com> wrote:
>> >> >>
>> >> >> ----- Original Message -----
>> >> >> From: "Mike Edwards" <mi...@gmail.com>
>> >> >> To: <tuscany-dev@ws.apache.org >
>> >> >> 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-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: Pass-by-value support for remotable interfaces

Posted by Venkata Krishnan <fo...@gmail.com>.

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.

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 <en...@gmail.com> 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" <fo...@gmail.com>
> To: <tu...@ws.apache.org>
> 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 <en...@gmail.com> 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" <fo...@gmail.com>
> >> To: <tu...@ws.apache.org>
> >> 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 <en...@gmail.com> wrote:
> >> >>
> >> >> ----- Original Message -----
> >> >> From: "Mike Edwards" <mi...@gmail.com>
> >> >> To: <tuscany-dev@ws.apache.org >
> >> >> 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-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: Pass-by-value support for remotable interfaces

Posted by Raymond Feng <en...@gmail.com>.

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" <fo...@gmail.com>
To: <tu...@ws.apache.org>
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 <en...@gmail.com> 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" <fo...@gmail.com>
>> To: <tu...@ws.apache.org>
>> 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 <en...@gmail.com> wrote:
>> >>
>> >> ----- Original Message -----
>> >> From: "Mike Edwards" <mi...@gmail.com>
>> >> To: <tuscany-dev@ws.apache.org >
>> >> 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-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: Pass-by-value support for remotable interfaces

Posted by Venkata Krishnan <fo...@gmail.com>.

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 <en...@gmail.com> 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" <fo...@gmail.com>
> To: <tu...@ws.apache.org>
> 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 <en...@gmail.com> wrote:
> >>
> >> ----- Original Message -----
> >> From: "Mike Edwards" <mi...@gmail.com>
> >> To: <tuscany-dev@ws.apache.org >
> >> 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-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: Pass-by-value support for remotable interfaces

Posted by Raymond Feng <en...@gmail.com>.

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" <fo...@gmail.com>
To: <tu...@ws.apache.org>
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 <en...@gmail.com> wrote:
>>
>> ----- Original Message -----
>> From: "Mike Edwards" <mi...@gmail.com>
>> To: <tuscany-dev@ws.apache.org >
>> 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-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