----- 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.
