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: [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]
