>
> Thanks
>
> - Venkat
>
>
> On 12/7/06, Raymond Feng <[EMAIL PROTECTED]> wrote:
>>
>> Hi, Venkat.
>>
>> I'll review the path. Please see my comments below.
>>
>> Thanks,
>> Raymond
>>
>> ----- Original Message -----
>> From: "Venkata Krishnan" <[EMAIL PROTECTED]>
>> To: <[email protected]>
>> 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: <[email protected] >
>> >> >> > >> >> >> Sent: Monday, December 04, 2006 4:16 PM
>> >> >> > >> >> >> Subject: Re: Pass-by-value support for remotable
>> >> >> interfaces
>> >> >> > >> >> >>
>> >> >> > >> >> >>
>> >> >> > >> >> >> > Hi Raymond,
>> >> >> > >> >> >> >
>> >> >> > >> >> >> > Thanks. I have started with this and here are a
>> >> >> couple of
>> >> >> > >> >> >> questions
>> >> >> > >> >> >> that
>> >> >> > >> >> >> > I
>> >> >> > >> >> >> > need help with.
>> >> >> > >> >> >> >
>> >> >> > >> >> >> > I believe the PassByValue Interceptor is good
>> to be
>> >> >> on the
>> >> >> > >> >> Inbound
>> >> >> > >> >> >> > Invocation chain of the server component.
>> Accordingly
>> I
>> >> >> > >> looked
>> >> >> > >> >> >> up the
>> >> >> > >> >> >> > DataBindingWirePostProcessor's method -
>> >> >> > >> >> >> > "public void process(OutboundWire source,
>> InboundWire
>> >> >> > >> target)"
>> >> >> > >> >> >> to do
>> >> >> > >> >> >> this.
>> >> >> > >> >> >> >
>> >> >> > >> >> >> > Over here I added the PassbyValue interceptor
>> to the
>> >> >> > >> 'target'.
>> >> >> > >> >> >> But this
>> >> >> > >> >> >> > did
>> >> >> > >> >> >> > not invoke the interceptor. If I added it to the
>> >> >> source then
>> >> >> >
>> >> >> > >> >> the
>> >> >> > >> >> >> > interceptor gets invoked. So, am I missing
>> something
>> >> >> here?
>> >> >> > >> >> >> >
>> >> >> > >> >> >> > I understand that the interceptor that you have
>> >> >> attached is
>> >> >> > >> >> for the
>> >> >> > >> >> >> > default
>> >> >> > >> >> >> > Java binding case. I will work on the databinding
>> >> >> dependent
>> >> >> > >> >> >> case once I
>> >> >> > >> >> >> > get
>> >> >> > >> >> >> > this default stuff working.
>> >> >> > >> >> >> >
>> >> >> > >> >> >> > Thanks
>> >> >> > >> >> >> >
>> >> >> > >> >> >> > - Venkat
>> >> >> > >> >> >> >
>> >> >> > >> >> >> >
>> >> >> > >> >> >> >
>> >> >> > >> >> >> > On 12/4/06, Raymond Feng <[EMAIL PROTECTED] >
>> wrote:
>> >> >> > >> >> >> >>
>> >> >> > >> >> >> >> Hi, Venkat.
>> >> >> > >> >> >> >>
>> >> >> > >> >> >> >> Thank you for volunteering. I opened a JIRA
>> >> >> > >> >> >> >> http://issues.apache.org/jira/browse/
>> TUSCANY-969 and
>> >> >> > >> >> attached some
>> >> >> > >> >> >> >> prototype
>> >> >> > >> >> >> >> code there. Hopefully it can get you started.
>> >> >> > >> >> >> >>
>> >> >> > >> >> >> >> Thanks,
>> >> >> > >> >> >> >> Raymond
>> >> >> > >> >> >> >>
>> >> >> > >> >> >> >> ----- Original Message -----
>> >> >> > >> >> >> >> From: "Venkata Krishnan" < [EMAIL PROTECTED]>
>> >> >> > >> >> >> >> To: <[email protected]>
>> >> >> > >> >> >> >> Sent: Sunday, December 03, 2006 10:08 PM
>> >> >> > >> >> >> >> Subject: Re: Pass-by-value support for remotable
>> >> >> interfaces
>> >> >> > >> >> >> >>
>> >> >> > >> >> >> >>
>> >> >> > >> >> >> >> > Hi Raymond,
>> >> >> > >> >> >> >> >
>> >> >> > >> >> >> >> > I'm interested in helping with this. It
>> will give
>> >> >> me a
>> >> >> > >> >> >> chance to
>> >> >> > >> >> >> work
>> >> >> > >> >> >> >> > with
>> >> >> > >> >> >> >> > the service invocation paths of the core.
>> Let me
>> >> >> know if
>> >> >> > >> >> >> there is
>> >> >> > >> >> >> >> > something
>> >> >> > >> >> >> >> > that I help with.
>> >> >> > >> >> >> >> >
>> >> >> > >> >> >> >> > Thanks.
>> >> >> > >> >> >> >> >
>> >> >> > >> >> >> >> > - Venkat
>> >> >> > >> >> >> >> >
>> >> >> > >> >> >> >> > On 11/30/06, Raymond Feng <[EMAIL PROTECTED]>
>> >> >> wrote:
>> >> >> > >> >> >> >> >>
>> >> >> > >> >> >> >> >> ----- Original Message -----
>> >> >> > >> >> >> >> >> From: "Mike Edwards"
>> >> >> <[EMAIL PROTECTED] >
>> >> >> > >> >> >> >> >> To: <[email protected] >
>> >> >> > >> >> >> >> >> Sent: Wednesday, November 29, 2006 7:07 AM
>> >> >> > >> >> >> >> >> Subject: Re: Pass-by-value support for
>> remotable
>> >> >> > >> interfaces
>> >> >> > >> >> >> >> >>
>> >> >> > >> >> >> >> >>
>> >> >> > >> >> >> >> >> > Raymond,
>> >> >> > >> >> >> >> >> >
>> >> >> > >> >> >> >> >> > First point I need to make is that just
>> because
>> >> >> two
>> >> >> > >> >> >> components are
>> >> >> > >> >> >> >> >> > in
>> >> >> > >> >> >> >> >> the
>> >> >> > >> >> >> >> >> > same composite does not mean that they are
>> >> >> > >> automatically
>> >> >> > >> >> >> running
>> >> >> > >> >> >> in
>> >> >> > >> >> >> >> the
>> >> >> > >> >> >> >> >> > same VM or even the same operating system
>> process.
>> >> >> > >> >> >> Composites can
>> >> >> > >> >> >> >> span
>> >> >> > >> >> >> >> >> > components running on different nodes
>> (node =
>> >> >> > >> machine and/
>> >> >> > >> >> >> or o/s
>> >> >> > >> >> >> >> >> process).
>> >> >> > >> >> >> >> >> >
>> >> >> > >> >> >> >> >>
>> >> >> > >> >> >> >> >> Good catch.
>> >> >> > >> >> >> >> >>
>> >> >> > >> >> >> >> >> > Consider a composite which had component A
>> >> >> > >> implemented in
>> >> >> > >> >> >> Java and
>> >> >> > >> >> >> >> >> > component B implemented in C++. Not likely
>> >> >> that they
>> >> >> > >> >> >> would run in
>> >> >> > >> >> >> >> the
>> >> >> > >> >> >> >> >> > same runtime process (certainly not with the
>> >> >> current
>> >> >> > >> >> Tuscany
>> >> >> > >> >> >> >> runtime).
>> >> >> > >> >> >> >> >> > This is perfectly OK as long as any
>> interface
>> >> >> between
>> >> >> > >> >> them is
>> >> >> > >> >> >> >> >> "remotable".
>> >> >> > >> >> >> >> >> >
>> >> >> > >> >> >> >> >> > Second, more general point to make, is
>> that there
>> >> >> > >> may be
>> >> >> > >> >> >> implied
>> >> >> > >> >> >> >> >> semantics
>> >> >> > >> >> >> >> >> > for the interface that depend on the binding
>> >> >> used to
>> >> >> > >> >> >> connect the
>> >> >> > >> >> >> >> >> reference
>> >> >> > >> >> >> >> >> > to the service. Consider the case where the
>> >> >> interface
>> >> >> > >> >> >> involves an
>> >> >> > >> >> >> >> >> > operation with a message having two
>> references to
>> >> >> > >> the same
>> >> >> > >> >> >> object.
>> >> >> > >> >> >> >> >> > When
>> >> >> > >> >> >> >> >> > this is sent from consumer to provider
>> (say),
>> >> >> does the
>> >> >> > >> >> >> provider
>> >> >> > >> >> >> >> receive
>> >> >> > >> >> >> >> >> 2
>> >> >> > >> >> >> >> >> > separate copies of the object or just one -
>> >> >> assuming
>> >> >> > >> the
>> >> >> > >> >> >> consumer
>> >> >> > >> >> >> >> >> started
>> >> >> > >> >> >> >> >> > with only 1.
>> >> >> > >> >> >> >> >> >
>> >> >> > >> >> >> >> >> > The answer is "it depends on the binding"
>> - RMI-
>> >> >> IIOP
>> >> >> > >> says
>> >> >> > >> >> >> there is
>> >> >> > >> >> >> >> only
>> >> >> > >> >> >> >> >> 1
>> >> >> > >> >> >> >> >> > copy. Web Services says there are 2
>> copies...
>> >> >> > >> >> >> >> >> >
>> >> >> > >> >> >> >> >> > I don't think that SCA can hide these subtle
>> >> >> > >> differences,
>> >> >> > >> >> >> much
>> >> >> > >> >> >> >> >> > though
>> >> >> > >> >> >> >> >> > we
>> >> >> > >> >> >> >> >> > may like to do so. However, what we must
>> >> >> guarantee is
>> >> >> > >> >> >> that the
>> >> >> > >> >> >> >> >> behaviour
>> >> >> > >> >> >> >> >> > matches the binding type - if the
>> internal wire
>> >> >> uses
>> >> >> > >> >> >> binding.ws,
>> >> >> > >> >> >> for
>> >> >> > >> >> >> >> >> > example, then we provide Web services
>> >> >> semantics. This
>> >> >> > >> >> >> must be
>> >> >> > >> >> >> true
>> >> >> > >> >> >> >> for
>> >> >> > >> >> >> >> >> > any optimisations we may like to use in the
>> >> >> case where
>> >> >> > >> >> >> both ends
>> >> >> > >> >> >> of
>> >> >> > >> >> >> >> the
>> >> >> > >> >> >> >> >> > wire are in 1 process - since for a
>> remotable
>> >> >> interface
>> >> >> >
>> >> >> > >> >> this
>> >> >> > >> >> >> >> proximity
>> >> >> > >> >> >> >> >> is
>> >> >> > >> >> >> >> >> > "accidental" and could be changed by a
>> subtle
>> >> >> change in
>> >> >> >
>> >> >> > >> >> >> deployment.
>> >> >> > >> >> >> >> >> >
>> >> >> > >> >> >> >> >> > That leaves open what to do in the case of
>> >> >> > >> binding.ws. We
>> >> >> > >> >> >> may
>> >> >> > >> >> >> need
>> >> >> > >> >> >> >> >> > a
>> >> >> > >> >> >> >> >> way
>> >> >> > >> >> >> >> >> > for the composition to indicate the type of
>> >> >> semantics
>> >> >> > >> >> >> required -
>> >> >> > >> >> >> or
>> >> >> > >> >> >> >> we
>> >> >> > >> >> >> >> >> > could default to one form (eg Web
>> services...)
>> >> >> > >> >> >> >> >> >
>> >> >> > >> >> >> >> >>
>> >> >> > >> >> >> >> >> Should this be clarified by the SCA spec on
>> pass-by-
>> >> >> > >> value?
>> >> >> > >> >> >> >> >>
>> >> >> > >> >> >> >> >> >
>> >> >> > >> >> >> >> >> > Yours, Mike.
>> >> >> > >> >> >> >> >> >
>> >> >> > >> >> >> >> >> > Raymond Feng wrote:
>> >> >> > >> >> >> >> >> >> Hi,
>> >> >> > >> >> >> >> >> >>
>> >> >> > >> >> >> >> >> >> I'm talking about the following:
>> >> >> > >> >> >> >> >> >>
>> >> >> > >> >> >> >> >> >> componentA.reference -->
>> componentB.service1
>> >> >> > >> >> >> >> >> >> non-SCA client --> componentB.service1
>> >> >> > >> >> >> >> >> >>
>> >> >> > >> >> >> >> >> >> In the cases above, componentA and
>> componentB
>> are
>> >> >> > >> in the
>> >> >> > >> >> >> same
>> >> >> > >> >> >> >> >> >> composite
>> >> >> > >> >> >> >> >>
>> >> >> > >> >> >> >> >> >> (in the same VM). Both the service and
>> >> >> reference are
>> >> >> > >> >> >> declared
>> >> >> > >> >> >> with
>> >> >> > >> >> >> >> >> >> a
>> >> >> > >> >> >> >> >> >> remotable interface. We need to have an
>> >> >> interceptor to
>> >> >> >
>> >> >> > >> >> >> deal with
>> >> >> > >> >> >> >> >> >> the
>> >> >> > >> >> >> >> >> >> pass-by-value.
>> >> >> > >> >> >> >> >> >>
>> >> >> > >> >> >> >> >> >> For the following wirings:
>> >> >> > >> >> >> >> >> >>
>> >> >> > >> >> >> >> >> >> .. --> composite.reference
>> >> >> > >> >> >> >> >> >> composite.service --> ...
>> >> >> > >> >> >> >> >> >>
>> >> >> > >> >> >> >> >> >> I assume the binding implementation for the
>> >> >> composite
>> >> >> > >> >> >> >> >> >> reference/service
>> >> >> > >> >> >> >> >> >> will handle the pass-by-value naturally
>> over the
>> >> >> > >> >> transport.
>> >> >> > >> >> >> >> >> >>
>> >> >> > >> >> >> >> >> >> Thanks,
>> >> >> > >> >> >> >> >> >> Raymond
>> >> >> > >> >> >> >> >> >>
>> >> >> > >> >> >> >> >> > <snip>
>> >> >> > >> >> >> >> >> >
>> >> >> > >> >> >> >> >> >
>> >> >> > >> >> >>
>> >> >> > >> >>
>> >> >> > >>
>> >> >>
>> ---------------------------------------------------------------------
>> >> >> >
>> >> >> > >> >> >> >> >> > To unsubscribe, e-mail: tuscany-dev-
>> >> >> > >> >> [EMAIL PROTECTED]
>> >> >> > >> >> >> >> >> > For additional commands, e-mail: tuscany-
>> dev-
>> >> >> > >> >> >> [EMAIL PROTECTED]
>> >> >> > >> >> >> >> >> >
>> >> >> > >> >> >> >> >>
>> >> >> > >> >> >> >> >>
>> >> >> > >> >> >> >> >>
>> >> >> > >> >> >>
>> >> >> > >> >>
>> >> >> > >>
>> >> >>
>> ---------------------------------------------------------------------
>> >> >> > >> >> >> >> >> To unsubscribe, e-mail: tuscany-dev-
>> >> >> > >> >> [EMAIL PROTECTED]
>> >> >> > >> >> >> >> >> For additional commands, e-mail: tuscany-dev-
>> >> >> > >> >> [EMAIL PROTECTED]
>> >> >> > >> >> >> >> >>
>> >> >> > >> >> >> >> >>
>> >> >> > >> >> >> >> >
>> >> >> > >> >> >> >>
>> >> >> > >> >> >> >>
>> >> >> > >> >> >> >>
>> >> >> > >> >> >>
>> >> >> > >> >>
>> >> >> > >>
>> >> >>
>> ---------------------------------------------------------------------
>> >> >> > >> >> >> >> To unsubscribe, e-mail: tuscany-dev-
>> >> >> > >> [EMAIL PROTECTED]
>> >> >> > >> >> >> >> For additional commands, e-mail: tuscany-dev-
>> >> >> > >> [EMAIL PROTECTED]
>> >> >> > >> >> >> >>
>> >> >> > >> >> >> >>
>> >> >> > >> >> >> >
>> >> >> > >> >> >>
>> >> >> > >> >> >>
>> >> >> > >> >> >>
>> >> >> > >> >>
>> >> >> > >>
>> >> >>
>> ---------------------------------------------------------------------
>> >> >> > >> >> >> To unsubscribe, e-mail: 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]
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
