Hi, Venkat.
I'll review the path. Please see my comments below.
Thanks,
Raymond
----- Original Message -----
From: "Venkata Krishnan" <[EMAIL PROTECTED]>
To: <tuscany-dev@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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> wrote:
>> >> > >>
>> >> > >>
>> >> > >> On Dec 5, 2006, at 1:34 AM, Venkata Krishnan wrote:
>> >> > >>
>> >> > >> > Hi Jim,
>> >> > >> >
>> >> > >> > Thanks for helping :). Well, let me ask away very
simply....
>> >> > >> >
>> >> > >> > What I am doing here is just about trying to insert an
>> >> > >> interceptor for
>> >> > >> > enforcing pass-by-value semantics in the case of
compoments
>> >> > >> > implementing a
>> >> > >> > Remotable interface - i.e. an interceptor to take
care of
>> >> making
>> >> > >> > copies of
>> >> > >> > arguments and return values.
>> >> > >> >
>> >> > >> > Since I understand that the best place to perform such a
>> >> copying
>> >> > >> > would be
>> >> > >> > just before the serving (or provider) component actually
>> >> gets to
>> >> > >> > service the
>> >> > >> > request, I had thought of inserting this interceptor
into the
>> >> > >> > InboundInvocation chain of the server component.
>> >> > >> >
>> >> > >> > For example if component A that has a reference to
Component
B
>> >> > >> whose
>> >> > >> > interface is remotable. Then I am trying to insert this
>> >> > >> > interceptor into
>> >> > >> > Component B's Inbound wire's invocation chain. This
I do
>> >> in the
>> >> > >> > DataBindingWirePostProcessor.process(OutboundWire
source,
>> >> > >> InboundWire
>> >> > >> > target) wherein 'target' is the wire where I am doing
the
>> >> > >> insertion.
>> >> > >> Pass-by-val should probably be enforced in another wire
>> >> processor
>> >> > >> since it is a separate concern (this isn't related to the
>> >> problem
>> >> > >> though)
>> >> > >> > (Component A being the source and Component B being the
>> >> target).
>> >> > >> > When I
>> >> > >> > tested this, the interceptor seemed to not get invoked.
>> >> > >> >
>> >> > >> > However, when I added this interceptor to the source
>> >> component's
>> >> > >> > outbound
>> >> > >> > chain i.e. in DataBindingWirePostProcessor.process
>> >> (OutboundWire
>> >> > >> > source,
>> >> > >> > InboundWire target) to the invocation chain of the
'source',
>> >> > >> then the
>> >> > >> > interceptor got invoked.
>> >> > >> >
>> >> > >> > So right now, I am wondering how to get the interceptor
>> >> invoked
>> >> > >> > from the
>> >> > >> > Inbound invocation chain of Component B.
>> >> > >> >
>> >> > >> It sounds like something is not being setup properly
>> >> > >>
>> >> > >> > If I am still not clear please let me know and probably
>> >> testcase is
>> >> >
>> >> > >> > the only
>> >> > >> > way out.
>> >> > >> >
>> >> > >> This would be the easiest way (you can probably copy the
>> >> testcase I
>> >> > >> pointed to, so it's not that much work). Such a
testcase will
>> >> allow
>> >> > >> you to set a breakpoint and see if the target chains
have been
>> >> > >> sequenced properly. It sounds like upon insertion your
>> >> interceptor
>> >> > >> is not being pointed to by the previous one in the
chain. It is
>> >> > >> possible that there is a problem in the wiring
infrastructure
>> >> that is
>> >> > >> causing this to happen.
>> >> > >>
>> >> > >> Jim
>> >> > >>
>> >> > >>
>> >> > >>
>> >> > >> > Thanks
>> >> > >> >
>> >> > >> > - Venkat
>> >> > >> >
>> >> > >> >
>> >> > >> >
>> >> > >> >
>> >> > >> > On 12/5/06, Jim Marino <[EMAIL PROTECTED]> wrote:
>> >> > >> >>
>> >> > >> >> Comments inline...
>> >> > >> >>
>> >> > >> >> On Dec 5, 2006, at 12:29 AM, Venkata Krishnan wrote:
>> >> > >> >>
>> >> > >> >> > Hi Raymond,
>> >> > >> >> >
>> >> > >> >> > Yes, I am debugging to figure out quite a few things.
>> >> > >> >> >
>> >> > >> >> > I just figured that in the ConnectorImpl.connect
>> >> (OutboundWire
>> >> > >> >> > sourceWire,
>> >> > >> >> > InboundWire targetWire, boolean optimizable) we
set the
>> >> > >> >> > 'targetInvoker' of
>> >> > >> >> > the 'targetComponent' to the outbound chain of the
source.
>> >> > >> Hence I
>> >> > >> >> > guess
>> >> > >> >> > the interceptors of set on the inbound chain of the
>> >> > >> targetComponent
>> >> > >> >> > is not
>> >> > >> >> > getting invoked.
>> >> > >> >> >
>> >> > >> >> > I am looking to see if there is a way where at the
end
>> >> of the
>> >> > >> >> > OutboundWire's
>> >> > >> >> > invocation chain the target invoker triggers off the
target
>> >> > >> >> > component's
>> >> > >> >> > inbound invocation chains.
>> >> > >> >> >
>> >> > >> >> The TargetInvoker's job is to dispatch a request to the
>> >> target
>> >> > >> >> instance *after* the request has been processed by the
>> >> invocation
>> >> > >> >> chain pair. The invoker is cached on the source side to
avoid
>> >> > >> having
>> >> > >> >> to perform target resolution on every invoke in certain
>> >> situations
>> >> > >> >> (e.g. when the target scope is "greater" than the
source,
>> >> e.g.
>> >> > >> >> request--->composite). The invocation handler places
the
>> >> > >> >> TargetInvoker in the message sent down both chains
and it
>> >> is the
>> >> > >> >> responsibility of the last interceptor on the target
side to
>> >> > >> pull the
>> >> > >> >> invoker from the message and call its invoke method.
>> >> > >> >>
>> >> > >> >> The source and target chains are fused by the Connector
>> >> with a
>> >> > >> >> BridgingInterceptor, which may be synchronous or non-
>> >> blocking.
>> >> > >> >>
>> >> > >> >> I'm finding it a little difficult to follow what you
are
>> >> doing
>> >> > >> so do
>> >> > >> >> you have a small testcase you can attach to a JIRA
similar
to
>> >> > >> this:
>> >> > >> >>
>> >> > >> >> https://svn.apache.org/repos/asf/incubator/tuscany/
java/sca/
>> >> > >> kernel/
>> >> > >> >> core/src/test/java/org/apache/tuscany/core/integration/
>> >> > >> conversation/
>> >> > >> >> ConversationStartStopEndTestCase.java
>> >> > >> >>
>> >> > >> >> I can take a look and see what the problem is.
>> >> > >> >>
>> >> > >> >> Jim
>> >> > >> >>
>> >> > >> >> > I am still going at this... let me see if I see
the light.
>> >> > >> >> >
>> >> > >> >> > Meanwhile if I am not on the right track (anybody)
>> >> please advise
>> >> > >> >> me on
>> >> > >> >> > course corrections :)
>> >> > >> >> >
>> >> > >> >> > Thanks.
>> >> > >> >> >
>> >> > >> >> > - Venkat
>> >> > >> >> >
>> >> > >> >> >
>> >> > >> >> >
>> >> > >> >> > On 12/5/06, Raymond Feng <[EMAIL PROTECTED]> wrote:
>> >> > >> >> >>
>> >> > >> >> >> Hi,
>> >> > >> >> >>
>> >> > >> >> >> Can you debug to see how the interceptors are
chained? It
>> >> > >> could be
>> >> > >> >> >> a bit
>> >> > >> >> >> tricky to make sure the new interceptor is added
to the
>> >> correct
>> >> >
>> >> > >> >> >> position.
>> >> > >> >> >>
>> >> > >> >> >> Thanks,
>> >> > >> >> >> Raymond
>> >> > >> >> >>
>> >> > >> >> >> ----- Original Message -----
>> >> > >> >> >> From: "Venkata Krishnan" <[EMAIL PROTECTED]>
>> >> > >> >> >> To: <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 <[EMAIL PROTECTED] >
wrote:
>> >> > >> >> >> >>
>> >> > >> >> >> >> Hi, Venkat.
>> >> > >> >> >> >>
>> >> > >> >> >> >> Thank you for volunteering. I opened a JIRA
>> >> > >> >> >> >> http://issues.apache.org/jira/browse/
TUSCANY-969 and
>> >> > >> >> attached some
>> >> > >> >> >> >> prototype
>> >> > >> >> >> >> code there. Hopefully it can get you started.
>> >> > >> >> >> >>
>> >> > >> >> >> >> Thanks,
>> >> > >> >> >> >> Raymond
>> >> > >> >> >> >>
>> >> > >> >> >> >> ----- Original Message -----
>> >> > >> >> >> >> From: "Venkata Krishnan" < [EMAIL PROTECTED]>
>> >> > >> >> >> >> To: <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 <[EMAIL PROTECTED]>
>> >> wrote:
>> >> > >> >> >> >> >>
>> >> > >> >> >> >> >> ----- Original Message -----
>> >> > >> >> >> >> >> From: "Mike Edwards"
>> >> <[EMAIL PROTECTED] >
>> >> > >> >> >> >> >> 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-
>> >> > >> >> [EMAIL PROTECTED]
>> >> > >> >> >> >> >> > For additional commands, e-mail: tuscany-
dev-
>> >> > >> >> >> [EMAIL PROTECTED]
>> >> > >> >> >> >> >> >
>> >> > >> >> >> >> >>
>> >> > >> >> >> >> >>
>> >> > >> >> >> >> >>
>> >> > >> >> >>
>> >> > >> >>
>> >> > >>
>> >>
---------------------------------------------------------------------
>> >> > >> >> >> >> >> To unsubscribe, e-mail: tuscany-dev-
>> >> > >> >> [EMAIL PROTECTED]
>> >> > >> >> >> >> >> For additional commands, e-mail: tuscany-dev-
>> >> > >> >> [EMAIL PROTECTED]
>> >> > >> >> >> >> >>
>> >> > >> >> >> >> >>
>> >> > >> >> >> >> >
>> >> > >> >> >> >>
>> >> > >> >> >> >>
>> >> > >> >> >> >>
>> >> > >> >> >>
>> >> > >> >>
>> >> > >>
>> >>
---------------------------------------------------------------------
>> >> > >> >> >> >> To unsubscribe, e-mail: tuscany-dev-
>> >> > >> [EMAIL PROTECTED]
>> >> > >> >> >> >> For additional commands, e-mail: tuscany-dev-
>> >> > >> [EMAIL PROTECTED]
>> >> > >> >> >> >>
>> >> > >> >> >> >>
>> >> > >> >> >> >
>> >> > >> >> >>
>> >> > >> >> >>
>> >> > >> >> >>
>> >> > >> >>
>> >> > >>
>> >>
---------------------------------------------------------------------
>> >> > >> >> >> To unsubscribe, e-mail: tuscany-dev-
>> >> [EMAIL PROTECTED]
>> >> > >> >> >> For additional commands, e-mail: tuscany-dev-
>> >> [EMAIL PROTECTED]
>> >> > >> >> >>
>> >> > >> >> >>
>> >> > >> >>
>> >> > >> >>
>> >> > >> >>
>> >> > >>
>> >>
---------------------------------------------------------------------
>> >> > >> >> To unsubscribe, e-mail:
[EMAIL PROTECTED]
>> >> > >> >> For additional commands, e-mail: tuscany-dev-
>> >> [EMAIL PROTECTED]
>> >> > >> >>
>> >> > >> >>
>> >> > >>
>> >> > >>
>> >> > >>
>> >>
---------------------------------------------------------------------
>> >> > >> To unsubscribe, e-mail: tuscany-dev-
[EMAIL PROTECTED]
>> >> > >> For additional commands, e-mail: tuscany-dev-
[EMAIL PROTECTED]
>> >> > >>
>> >> > >>
>> >> >
>> >> >
>> >> >
>> >>
---------------------------------------------------------------------
>> >> > To unsubscribe, e-mail: [EMAIL PROTECTED]
>> >> > For additional commands, e-mail: tuscany-dev-
[EMAIL PROTECTED]
>> >> >
>> >> >
>> >>
>>
>>
>>
---------------------------------------------------------------------
>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
