Let me try to propose the following fix:
1) Add new interface such as PassByValueProvider (please help me with a
better name) to the SPI.
public interface PassByValueProvider {
/**
* Indicate if the provider will enforce the pass-by-value semantics
*/
boolean isPassByValueEnforced(Operation op);
}
The ReferenceBindingProvider, ImplementationProvider and
ServiceBindingProvider can optionally implement this interface to express
its capability for PBV (I'm trying to avoid the changes of the Provider
SPIs). For example, the binidng.ws reference binding provider should return
true as it always exchange data over SOAP and the PBV semantics is enforced.
Another example is that the implementation.java provider can return true if
the corresponding method has @AllowsPassByReference annotation.
2) The PBV RuntimeWireProcessor will query the providers to decide if it
should add the PassByValueInterceptor for a remotable interface. For the
reference wire, the ReferenceBindingProvider will be queried. For the
service wire, both the ServiceBindingProvider and ImplementationProvider
will be queried. Add a flag to the InvocationChain to indicate if such an
invocation will garauntee the copy is passed by value.
3) Other RuntimeWireProcessor (such as the DataBindingRuntimeWireProcessor)
can configure the InvocationChain by setting the isPassByValueEnforced flag.
4) The PBV interceptor will not be added or it could be NO-OP if the
InvocationChain returns true for the isPassByValueEnforced flag.
Thanks,
Raymond
----- Original Message -----
From: "Raymond Feng" <[EMAIL PROTECTED]>
To: <tuscany-dev@ws.apache.org>
Sent: Monday, February 04, 2008 9:50 AM
Subject: Re: Bypassing unnecessary transforms by Tuscany databinding
framework
Hi,
I think we should further understand what roles the core, binding and
implementation can play to enforce the pass-by-value semantics.
Implementation extension: knows the setting of @AllowsPassByReference,
might know if the implement code would modify the input data and if the
output data could be changed by the client side (for example,
implementation.bpel and implementation.xquery probably never mutate the
client data).
Binding extension: knows if the underlying protocol copies the
input/output data so that the target implementation would be isolated from
direct data references to the client side (for example, the binding.ws,
binding.jms or binding.rmi will always marshal/unmarshal the data accross
the transport and pass-by-value is naturally achieved). knows the context
(such as classloader) to copy/transform the data if necessary.
Core: knows if the interface is remote (pass-by-value only applies to
remotable interfaces), can interact with the binding/implementation to
decide if it should add a pass-by-value interceptor to enforce the
semantics. knows if the data would be transformed by databinding layer
(the data will be copied if it happens).
If we agree on the above, we can then reflect these roles in the different
layers (maybe SPI as well).
Thanks,
Raymond
----- Original Message -----
From: "Jean-Sebastien Delfino" <[EMAIL PROTECTED]>
To: <tuscany-dev@ws.apache.org>
Sent: Saturday, February 02, 2008 11:03 PM
Subject: Re: Bypassing unnecessary transforms by Tuscany databinding
framework
Scott Kurz wrote:
Some examples of what I meant..
For the service instance I'm invoking I'd like to know:
* target JVM is it the same as the client instance? (is this a
"Node" in Tuscany terms?, sorry of my ignorance)
* target classloader (if it's not the same or a child I can't do PBR)
* target DB (if it's the same maybe I can do PBR)
* is target annotated with @AllowsPBR
It looks like these are things that a binding knows about.
So, is it fair to say that it would be better to not have a magic
databinding interceptor added automatically to the invocation chain and
instead let the binding decide to copy or not or transform or not based
on its knowledge of the target that it's talking to?
--
Jean-Sebastien
---------------------------------------------------------------------
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]
