river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter <j...@zeus.net.au>
Subject Re: Distributed Garbage Collection & Security - InvocationConstraints
Date Mon, 01 Aug 2011 01:30:55 GMT

----- Original message -----
> On 7/31/2011 5:35 AM, Peter Firmstone wrote:
> > I think this would be useful in an internet environment, where a developer
> > wants to export an object and hand it as a parameter to another service, and
> > have it unexported automatically when no longer required.
>
> This is why I make my smart proxy classes be InvocationHandlers and then embed
> the real remote object and a lease into the marshalled object.  With deferred
> unmarshalling, then others who unmarshall it for use, apply a
> LeaseRenewalManager on the lease as well so that everyone using it is making
> sure the server is not releasing it.
>
> Endpoints as they exist today, are not mobile because of code contamination and
> lost-code-base issues that occur when a remote object is remarshalled to send
> across the wire.
>
> Multiple unmarshalling activities in the same JVM might not be safe if there is
> static class initialization that should of been per-instance.
>
> I think this is an area that needs some investigation for sure.
>
> Gregg

Spot on, I think we can fix this by defining the jini platform that should be available on
the classpath then stick to it.  Anything else required (apart from service api) must go into
child classloaders.

Anything that's serializable in the platform must remain backward compatible (serialized form)
and must be present in all nodes.

We should attempt to put implementation into a child classloader, so it isn't resolved prior
to proxy classloader class resolution, allowing proxy's to have their own implementations.

Instead of using the current preferred classes mechanism, the order of class resolution would
be:

Proxy classloader, delegates first to the application classloader. (classpath), which delegates
to the extension and system classloaders, then finally it try's the proxy classloader own
codebase.

If a class is still unresolved then we could try the Platform Implementation classloader,
which could be obtained by a static class reference.  Alternatively, platform implementation
classes shouldn't be serializable.

Services shouldn't be visible in the application classloader, only their service api.

We can provide abstract classes and interfaces for the platform, for various implementations
to cooperate with, while preserving implementation codebase annotations and proxy and service
implementations separated in their own classloaders (because these classes don't exist in
the parent classloader).  

Different implementations can coexist in separate classloaders and cooperate using common
superclasses and interfaces in the application, extension or system classloaders. 

Shared state can be managed in abstract classes using protected static methods with synchronization
and security checks, all static fields private.  Abstract object state can be similarly manged
with protected methods and private fields.

We have the advantage that service api already utilise interfaces.  

Along with a rename of the com.sun namespace, this is an opportunity to fix some long standing
issues that have discouraged wider adoption.

It should be possible to pass on distributed objects to any node without issues, this is the
fundamental value of Jini over java rmi.

Ideally: There is no dependency on implementation, only api.  Implementation shouldn't be
known until runtime.

This isn't an easy exercise, but I think that Dennis' recent work with Rio might provide some
insight.

Separating the platform from service implementations, and providing libraries for service
implementers to deploy and developing these separately will make it clearer what developers
can change without worrying about backward compatibility. Eg libraries should be free to change.
 The platform should be stable and evolve with backward compatibility in mind.

This is difficult, but possible, it will take time and cooperation to figure out the right
solutions, on a case by case basis.

If we can figure out these fundamental issues, we just possibly might hold the future of distributed
computing in our hands.

Cheers,

Peter.



Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message