Raymond/Mike,

Thank you for your responses.

I like the idea that it is the responsibility of the binding provider to
ensure that data is correctly copied for cross-classloader calls. But will
that require the default binding.sca to be aware of classloaders? I will
have to look at the code in more detail (my next free weekend) to understand
how this will fit in.



On 5/12/08, Mike Edwards <[EMAIL PROTECTED]> wrote:
>
> 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.
>



-- 
Thank you...

Regards,

Rajini

Reply via email to