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