Have we been doing codebase annotations wrong?
Could RMIClassLoader have been better conceived?
Could a simpler alternative be utilised instead?
For example, classes are resolved differently during deserialization than
how classes are resolved at runtime. At runtime a ClassLoader delegates to
its parent ClassLoader, or in the case of modular systems, ClassLoader’s of
imported modules. RMIClassLoader, doesn’t look to resolve classes through
ClassLoader hierarchies, but instead tries to locate each ClassLoader
directly based on an annotation.
The problem with this approach is not all ClassLoader’s provide codebase
annotations, and class resolution may be different at distinct nodes in the
network.
Currently codebase annotations may change when marshalling between nodes,
depending on where each class is resolved.
Refer to: http://sorcersoft.org/resources/jini/smli_tr-2006-149.pdf
A much simpler approach.
We can define the ClassLoader at each endpoint.
In JERI, a ServerEndpoint can be assigned a default ClassLoader, by
passing it as a parameter to its InvocationLayerFactory. The client
Endpoint’s default ClassLoader is the ClassLoader of its dynamic proxy
instance (the ClassLoader where the java.lang.reflect.Proxy dynamically
generated instance is loaded).
So if a service has a smart proxy, it’s codebase should be present in a
ClassLoader at both the ServerEndpoint and the client Endpoint, so the
default ClassLoader’s at both Endpoint’s contain that codebase.
The default ClassLoader at each Endpoint now has responsibility for
resolution of classes, no longer is RMIClassLoader required. In fact
codebase annotations no longer need to be annotated with every class in the
stream either.
But what about client parameter objects, or exported remote handback
objects passed as parameters, I hear you ask?
Simple, we use a marker interface, so these objects can identify
themselves to the stream, a bootstrap proxy can be provided by the stream,
that uses only local classes, present at both endpoints, the original
object can be stored into a MarshalledInstance and serialized with the
bootstrap proxy to the remote Endpoint, that allows the originator to be
authenticated, it’s codebase provisioned into a ClassLoader which becomes
the default loader of the MarshalledInstance to deserialize the object in
question. The identity key of the ClassLoader will be a combination of the
bootstrap proxy’s InvocationHandler identity and it’s codebase annotation,
so it can be cached. If a remote object which is contained within the
MarshalledInstance, its JERI Endpoint will use the default ClassLoader
passed to the MarshalledInstance as its default loader.
Note: If we’re in a traditional java hierarchical ClassLoader system (not
modular), we’d want the current stream’s default loader to be the parent
loader of the resolved or provisioned ClassLoader passed to the
MarshalledInstance.
So now you don’t get codebase annotation loss, ServerEndpoint and client
Endpoint’s have ClassLoader’s with compatible class resolution. The
codebase annotation becomes a configuration concern of the service.
In addition, MethodConstraints can also be applied to exported objects
nested within other services. It can be passed using the stream context.
This ensures that minimum principal authentication, integrity and
confidentiality apply to all nested objects.
The good news is that most of the mechanisms are already present and
backward compatibility can be preserved allowing eventual migration.
Remember that a smart proxy can have no real server back end communication
at all (except for providing the codebase), it’s just an object that gets
serialized around different nodes, in this case the bootstrap proxy is
still used to provide the codebase annotation and as trust verification.
How does trust work in this system?
Provided you still trust the bootstrap proxy’s service, after method
constraints that ensure confidentiality and minimum principal
authentication have been applied , it provides the codebase annotation, and
if integrity constraint is true, then the codebase scheme is checked for
integrity, or if it’s signed, the jar is validated by a provider. (The
signers can be anonymous and advised by the bootstrap proxy). You now trust
that the code will validate input during deserialization, and if the
de-serialized object implements RemoteMethodControl apply MethodConstraints
to it as well. The object bytes in serial form may have originated from a
third party (also with MethodConstraints applied, but possibly not trusted
by the original node), in any case it’s important for the input to be
validated during deserialization.
Note this system would also utilise a Service Provider Interface to
communicate with the bootstrap proxy and preferred classes can still be
supported, simply by using a PreferredClassLoader when loading the codebase.
This system also allows support for modular environments like OSGi to be
relatively simple when compared to RMIClassLoaderSpi. Additonally it allows
an OSGi node to interact with traditional nodes / services, provided jar
files have bundle manifests and the configured codebase annotation string
contains all required jar files, including dependencies (the OSGi provider
can ignore the dependencies, provided the first jar is the proxy bundle).
I've currently got a prototype I'm working on if anyone's interested.
Regards,
Peter.
