river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Firmstone <j...@zeus.net.au>
Subject Re: Maven repository Entry was Re: Codebase service?
Date Tue, 25 May 2010 23:10:05 GMT
This is a good question, which gets to the heart of the Jini's pattern.

I think the proposed ClassLoader structure will benefit Rio, by enabling 
increased API commonality and class sharing among Services and their 
clients.

You can get around having to shutdown your jvm if you manage evolution 
of your API interfaces correctly, set up a separate testing Registrar, 
to keep new API interfaces out of your deployment, until they have 
stabilised.

Classes, once loaded into a ClassLoader, cannot be garbage collected, 
but if your API classes don't change there is no problem, when was the 
last time ServiceRegistrar changed it's public API?   Unlike Jini's 
platform classes which are set in stone, new API classes can be 
introduced into older environments.

Lets take Jini Platform services as an example, in Rio's ClassLoader 
tree below, the Interfaces for the Platform services exist in the 
CommonClassLoader, all classes in the CommonClassLoader are visible to 
any class in any child ClassLoader below in the tree.

Platform services can be shared freely among all child ClassLoaders.

Now take Service-1CL and Service-2CL, lets imagine for a moment that 
these two services both provide the same service, from different or the 
same node, it doesn't matter, let's imagine now another node with the 
same ClassLoader tree structure, which consumes these services.

These services have their service interfaces bundled with their 
CodeSources, both on the client and at the Service, lets say that 
Service-2CL provides the same service, but has a different 
implementation.  Now there's a client service that consumes these 
services, performs an operation then discards the service.

Now which common API do the two service proxy's share?  This forces you 
to load both proxy's into the same ClassLoader, making their 
implementations visible to each other and the client.

By separating the API into, in your case the CommonClassLoader, each 
with their own ProtectionDomains, all Services and clients in that node, 
share the same API classes and can be isolated in their own 
ClassLoader's and can have different implementations but share the same 
common API types.

The client service-param.jar is for clients who create new 
implementations / extend parameters in API methods, the Service server 
node will require these classes to unmarshall the parameters.  Client 
parameter classes will never be granted permissions.

I'll make up some separate ClassLoader tree diagrams showing the client 
node, the service node and the relationships between remote ClassLoaders.

Peter.

Dennis Reedy wrote:
> If I understand correctly I think this is the crux of the issue. I 
> dont understand why you need to load all API classes with the same 
> class loader. FWIW, in Rio we handle the loading (and unloading) of 
> services with the following structure 
> (http://www.rio-project.org/apidocs/org/rioproject/boot/package-summary.html#package_description):
>                   AppCL
>                     |
>             CommonClassLoader (http:// URLs of common JARs)
>                     +
>                     |
>                     +
>             +-------+-------+----...---+
>             |               |          |
>         Service-1CL   Service-2CL  Service-nCL
>         
>
> AppCL - Contains the main() class of the container. Main-Class in manifest points to
com.sun.jini.start.ServiceStarter
> Classpath:  boot.jar, start.jar, jsk-platform.jar
> Codebase: none
>
> CommonClassLoader - Contains the common Rio and Jini technology classes (and other declared
common platform JARs) to be made available to its children.
> Classpath: Common JARs such as rio.jar
> Codebase: Context dependent. The codebase returned is the codebase of the specific child
CL that is the current context of the request.
>
> Service-nCL - Contains the service specific implementation classes.
> Classpath: serviceImpl.jar
> Codebase: "serviceX-dl.jar rio-dl.jar jsk-lib-dl.jar"
>
> Certainly not as sophisticated as OSGi (or what you are targeting), but it meets the
requirements of allowing multiple service versions, applying security context per class loader
using the same approach as ActivateWrapper, and allows the JVM to stay running. 
>
>   


Mime
View raw message