Raymond Feng wrote:
<snip>
There is one more player: binding. The remote interaction is controlled
by the binding protocol. When the source and target components are
running under different context (such as classloader), the binding
provider should be responsible to make sure the data are correctly
marshalled/unmarshalled. If the binding decides to optimize for the
co-located cases (in same VM), it needs to take care of the
cross-context data mapping. It is similar that RMI/IIOP copies the data
for the co-located services.
<snip>
Maybe the binding should handle the cross-classloader data mapping
instead of the implementation.osgi.
I think you're getting close to the right behaviour here. IF the interface is marked as remotable,
then it is expected that the data is copied between client and service provider. Where there is
serialization to a "real" wire protocol, this is obvious. Where the client and the provider live in
the same VM, it is possible to *optimise* and avoid formal serialization, but it should really be
the binding layer that makes this decision as other factors like security and other policies may
come into play.
So, data copying between client SDO and provider SDO is one approach.
"AllowsPassByReference" is a feature worth thinking about. The idea is this is a yet further
optimisation that allows passing of object(s) between client and provider when they live in the same
VM. This clearly requires that the classes on both sides share the same classloader. I'm not sure
how the bindings are meant to work this out for the Tuscany runtime.
Finally there is the question of local interfaces. These are meant to be by-reference and the same
classloader considerations apply as for the last paragraph.
Does your brain hurt yet??
Yours, Mike.
