To copy or not to copy, that is the question, was: Pass-by-value interceptor

[Jean-Sebastien Delfino <js...@apache.org>]

Raymond Feng wrote:
> More comments inline.
>
> Thanks,
> Raymond
>
> ----- Original Message ----- From: "Scott Kurz" <sc...@gmail.com>
> To: <tu...@ws.apache.org>
> Sent: Friday, October 05, 2007 1:57 PM
> Subject: Re: Pass-by-value interceptor
>
>
>> Maybe it would help for me to point out that I'd opened 1678,79,80  
>> before
>> the refactoring for
>> TUSCANY-1559 was performed.
>>
>> As I have the time I'll try to understand to what degree if any 1559 may
>> have addressed the issues I mentioned.
>>
>> But Raymond, on the surface it seems like you're suggesting going 
>> back to
>> how it was pre-1559, though with
>> a per-implementation-type extension instead of just the old
>> PassByValueInvoker associated with the Java implementation.
>
> Yes.
>
>>
>> To me it seemed like one not-too-hard change to address  1678 would 
>> be to
>> have a flag in the Message SPI
>> that says, "there's no need to do a copy".  This would be off by 
>> default but
>> a binding impl or databinding transform could switch it on.
>
> We're trying hard to avoid additional fields on the Message unless 
> it's absolutely necessary.
>
>>
>>
>
> I'm not sure if it's a good idea to rely on the pass-by-value 
> interceptor to deal with object marshaling/unmarshaling accross 
> classloaders. To handle the optimization for co-located components 
> (different classloader) in the same VM, we probably should add an 
> "marshaling interceptor" on the client side and "unmarshling 
> interceptor" on the service side.
>
>>
>> On 10/5/07, Raymond Feng <en...@gmail.com> wrote:
>>>
>>> Hi,
>>>
>>> I'm looking into JIRA TUSCANY-1678, TUSCANY-1679, TUCANY-1680. At this
>>> moment, the pass-by-value interceptor is added by the
>>> DataBindingRuntimeWireProcessor. I start to wonder if it's the right
>>> approach. The pass-by-value semantics is somehow 
>>> implementation-specific
>>> and
>>> it also requires some metadata from the Implementation (for example,
>>> @AllowsPassByReference in java components). It seems that the
>>> implementation
>>> type extension will have more knowledge to enforce the pass-by-value.
>>>
>>> Does it make better sense to have implementation type extension be
>>> responsible to set up the pass-by-value interceptor?
>>>
>>> Thanks,
>>> Raymond
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>>>

A few thoughts... If I understand correctly, we're trying to guarantee 
that business data flowing through a remote interface is guaranteed to 
not be changed.

Looking at a number of scenarios, I'm making the following observations:

- Some bindings can guarantee it because they're just writing the data 
to a network connection.

- Other bindings can't guarantee it because they're passing a pointer to 
the data in memory to somebody else.

- Some component implementations can guarantee that, for example if I 
remember correctly a BPEL process will not modify its input data, a 
mediation component if we had one would probably not change its input 
data either.

- Other component implementations will pass a pointer to the data in 
memory to user code, and can't guarantee that the user code won't change it.

- Some component implementations (e.g. Java) have defined a way for the 
application developer to declare that he'll be nice and won't modify the 
data (see @AllowsPassByReference).

- In some cases, whatever the binding or component implementation say, 
the Tuscany databinding machinery must convert the data from one 
representation to another, indirectly protecting the original data 
against any changes.

- The same extends to other types of interceptors, for example an 
encryption or compression interceptor naturally protects the data 
against changes as it passes an encrypted or compressed representation 
of the data in place of the original data.

- Finally, all the above conditions must be evaluated on a business 
operation basis.


Considering all this, I think bindings, implementations, and all 
interceptors in an invocation chain should state if they are going to 
protect data against changes or not, and we need that information on an 
operation basis. I'd suggest to add a method to oat.sca.invocation.Invoker {

  // I'm not sure about the best name for this method.
  boolean allowsPassByReference();
  or
  boolean doesNotChangeInputData();
  or
  boolean protectsInputData();
}

The wire algorithm will have to call that method on the Invokers in an 
invocation chain to decide if it's safe to pass the original data or if 
a copy of the data should be passed instead. If an invoker claims to 
protect the data then we can pass the original data, if no invoker in 
the invocation chain claims to protect the data then we need to copy it.


Now the next question is: Who should perform the copy?

I don't think it's fair to require bindings and implementations to know 
how to copy all the different data representations supported in Tuscany 
:) I think it's better to have a generic CopyInterceptor to do that, 
leveraging the databinding framework.

On the other hand, if a particular implementation recognizes a specific 
data representation and wants to make the copy itself, it can still do 
it simply by having its Invoker.allowsPassByReference() return true.

Thoughts?

-- 
Jean-Sebastien


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

Re: To copy or not to copy, that is the question, was: Pass-by-value interceptor

[Jean-Sebastien Delfino <js...@apache.org>]

Jean-Sebastien Delfino wrote:
> Raymond Feng wrote:
>> More comments inline.
>>
>> Thanks,
>> Raymond
>>
>> ----- Original Message ----- From: "Scott Kurz" <sc...@gmail.com>
>> To: <tu...@ws.apache.org>
>> Sent: Friday, October 05, 2007 1:57 PM
>> Subject: Re: Pass-by-value interceptor
>>
>>
>>> Maybe it would help for me to point out that I'd opened 1678,79,80  
>>> before
>>> the refactoring for
>>> TUSCANY-1559 was performed.
>>>
>>> As I have the time I'll try to understand to what degree if any 1559 
>>> may
>>> have addressed the issues I mentioned.
>>>
>>> But Raymond, on the surface it seems like you're suggesting going 
>>> back to
>>> how it was pre-1559, though with
>>> a per-implementation-type extension instead of just the old
>>> PassByValueInvoker associated with the Java implementation.
>>
>> Yes.
>>
>>>
>>> To me it seemed like one not-too-hard change to address  1678 would 
>>> be to
>>> have a flag in the Message SPI
>>> that says, "there's no need to do a copy".  This would be off by 
>>> default but
>>> a binding impl or databinding transform could switch it on.
>>
>> We're trying hard to avoid additional fields on the Message unless 
>> it's absolutely necessary.
>>
>>>
>>>
>>
>> I'm not sure if it's a good idea to rely on the pass-by-value 
>> interceptor to deal with object marshaling/unmarshaling accross 
>> classloaders. To handle the optimization for co-located components 
>> (different classloader) in the same VM, we probably should add an 
>> "marshaling interceptor" on the client side and "unmarshling 
>> interceptor" on the service side.
>>
>>>
>>> On 10/5/07, Raymond Feng <en...@gmail.com> wrote:
>>>>
>>>> Hi,
>>>>
>>>> I'm looking into JIRA TUSCANY-1678, TUSCANY-1679, TUCANY-1680. At this
>>>> moment, the pass-by-value interceptor is added by the
>>>> DataBindingRuntimeWireProcessor. I start to wonder if it's the right
>>>> approach. The pass-by-value semantics is somehow 
>>>> implementation-specific
>>>> and
>>>> it also requires some metadata from the Implementation (for example,
>>>> @AllowsPassByReference in java components). It seems that the
>>>> implementation
>>>> type extension will have more knowledge to enforce the pass-by-value.
>>>>
>>>> Does it make better sense to have implementation type extension be
>>>> responsible to set up the pass-by-value interceptor?
>>>>
>>>> Thanks,
>>>> Raymond
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>>>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>>>>
>
> A few thoughts... If I understand correctly, we're trying to guarantee 
> that business data flowing through a remote interface is guaranteed to 
> not be changed.
>
> Looking at a number of scenarios, I'm making the following observations:
>
> - Some bindings can guarantee it because they're just writing the data 
> to a network connection.
>
> - Other bindings can't guarantee it because they're passing a pointer 
> to the data in memory to somebody else.
>
> - Some component implementations can guarantee that, for example if I 
> remember correctly a BPEL process will not modify its input data, a 
> mediation component if we had one would probably not change its input 
> data either.
>
> - Other component implementations will pass a pointer to the data in 
> memory to user code, and can't guarantee that the user code won't 
> change it.
>
> - Some component implementations (e.g. Java) have defined a way for 
> the application developer to declare that he'll be nice and won't 
> modify the data (see @AllowsPassByReference).
>
> - In some cases, whatever the binding or component implementation say, 
> the Tuscany databinding machinery must convert the data from one 
> representation to another, indirectly protecting the original data 
> against any changes.
>
> - The same extends to other types of interceptors, for example an 
> encryption or compression interceptor naturally protects the data 
> against changes as it passes an encrypted or compressed representation 
> of the data in place of the original data.
>
> - Finally, all the above conditions must be evaluated on a business 
> operation basis.
>
>
> Considering all this, I think bindings, implementations, and all 
> interceptors in an invocation chain should state if they are going to 
> protect data against changes or not, and we need that information on 
> an operation basis. I'd suggest to add a method to 
> oat.sca.invocation.Invoker {
>
>  // I'm not sure about the best name for this method.
>  boolean allowsPassByReference();
>  or
>  boolean doesNotChangeInputData();
>  or
>  boolean protectsInputData();
> }
>
> The wire algorithm will have to call that method on the Invokers in an 
> invocation chain to decide if it's safe to pass the original data or 
> if a copy of the data should be passed instead. If an invoker claims 
> to protect the data then we can pass the original data, if no invoker 
> in the invocation chain claims to protect the data then we need to 
> copy it.
>
>
> Now the next question is: Who should perform the copy?
>
> I don't think it's fair to require bindings and implementations to 
> know how to copy all the different data representations supported in 
> Tuscany :) I think it's better to have a generic CopyInterceptor to do 
> that, leveraging the databinding framework.
>
> On the other hand, if a particular implementation recognizes a 
> specific data representation and wants to make the copy itself, it can 
> still do it simply by having its Invoker.allowsPassByReference() 
> return true.
>
> Thoughts?
>

More thoughts:

- At the beginning of this thread, Scott was talking about using 
different classloaders in different components in a VM. Since then we've 
started another discussion on classloaders in Tuscany general, see 
http://marc.info/?l=tuscany-dev&m=119210552631425

- My 2c. If a binding allows in-VM in-memory cross-classloader 
communication, it should be responsible for converting data across 
classloaders, possibly using facilities from the Tuscany Databinding 
framework, and/or the facilities offered by the underlying communication 
mechanism that it's using. But before going too quickly into discussing 
a solution, Scott what kind of binding were you thinking about?

-- 
Jean-Sebastien


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