You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@river.apache.org by Peter Firmstone <ji...@zeus.net.au> on 2010/05/26 07:42:37 UTC
Service API, class visibility, isolation and garbage collection -
ClassLoaders
IDENTICAL TO ANOTHER MESSAGE IN THREAD: Re: Maven repository Entry was
Re: Codebase service?
Note: A permission will be required to allow a proxy to introduce new
Service API during unmarshalling to prevent against denial of service
attacks.
Hi Dennis,
It sounds like you remain unconvinced or don't have a need to use common
interfaces for your service proxy's?
So I guess it's a tread lightly approach, make the feature available to
those that want common Service API (The same interface instance for all
proxy's implementing that interface, so they can be used in collections
or batch operations), for maximum sharing of proxy's with differing
implementations, but let those that don't want to publish their API
continue doing what they usually do. A configuration parameter should
be able to set the desired behaviour.
The approach I've taken is a simple approach to a complex problem,
alternative approaches leave the complexity in the hands of the
implementer, my approach will enable them to practically ignore it.
Before you write it off though, to answer your earlier question, I'll
further explain the ClassLoader structure between multiple nodes.
CLIENT NODE
________________________________________________
| |
| System |
| ClassLoader |
| | |
| Extension |
| ClassLoader |
| | |
| Jini Platform & |
| Service API |
| ClassLoader |
| | |
| _________|___ |
| | | |
| Application Smart Proxy |
| ClassLoader ClassLoader's |
|________________________________________________|
SERVICE NODE
________________________________________________
| |
| System |
| ClassLoader |
| | |
| Extension |
| ClassLoader |
| | |
| Jini Platform & |
| Service API |
| ClassLoader |
| | |
| _________|_____________________ |
| | | | |
| Service Imp Smart Proxy Parameter Impl |
| ClassLoader ClassLoader's ClassLoader's |
|________________________________________________|
All Proxy and Service implementations are free to vary at will, proxy
instances can be shared in collections or iterative operations based on
common Service API supertype's All Proxy's and Services are isolated in
their own Domain, the only way to communicate externally is by using
interfaces and classes in upper level ClassLoaders, they can utilise as
many third party libraries jar archives as they need, these will all be
loaded into a single ClassLoader unique to that Service or Proxy's
Codebase and Principles. The Service or Proxy's namespace will be
totally separate from Application or other Proxy implementation's,
except in the case where sharing is permitted for identical
implementations by the implementation developer.
Service API should be carefully considered and designed, it forms the
basis of network Dependency Injection, you can discover ANY Service
implementation variant using the same Service API.
The Service API may include other Service API or Java platform classes.
public interface SimpleBookService {
public Book get( Library lib, String name);
}
In the SimpleBookService above, given a Library and String name of a
Book, a Book instance is returned by the proxy.
The contents of simpleBookService-api.jar:
SimpleBookService.class
Book.class
Library.class
Let's say a client has extended the Library, with a class called
PrivateLibrary, this class is an implementation class by the client,
that the Service knows nothing about, the Service only uses the Library
API, but it needs the PrivateLibrary.class
The client makes an archive containing the PrivateLibrary.class publicly
available in an archive called privateLibrary-param.jar. This archive
depends on simpleBookService-api.jar The jar URL is marshalled with the
class when the parameters are sent back to the service. When it gets to
the service implementation, privateLibrary-param.jar is given it's own
ClassLoader and ProtectionDomain and isn't given any Permissions. It is
used by a SimpleBookService implementation to decide which Book to
return to the client, after which, it's garbage collected, eventually if
PrivateLibrary isn't used again its ClassLoader is garbage collected too.
Each SimpleBookService proxy implementation will have their own
ClassLoader namespace, but Client Application classes can still use any
Service implementation or as many Service implementations as it can
handle at the same time, all the while treating them as the same Type.
One SimpleBookService implementation proxy, contains its own
implementation of Book, and while the client is reading the book, it
remains available from the proxy ClassLoader via the Service API Book
interface, when finished reading the book, the proxy, book and
ClassLoader can be garbage collected. Tomorrow, the client might read a
book from another SimpleBookService
Most Service API will be relatively small bytecodes as most will be
abstract or have simple implementations, the fact they're not garbage
collected, doesn't matter much if the function of the node doesn't
change, the API will remain limited to the subset in use, by the node.
Note that Jini Platform service implementations like Reggie, Outrigger
etc, will exist in Service Impl ClassLoaders and Smart Proxy
ClassLoaders, only the api will be in the Jini Platform ClassLoader.
Think of it as an expandable platform, everything is shared using
implementations of Service API classes.
It's actually a good policy to be liberal with interfaces when building
the Service API classes, even with parameters and return types. Since
extending interfaces is relatively straight forward, you new interfaces
will be discovered by older client software as the old interface while
new implementation code discovers the new interface of your service.
Older nodes will load your new interface classes into the Service API
space when your new proxy versions are unmarshalled. That's why it's
important to maintain backward compatibility in the Service API space.
So best practise would be to create an experimental djinn group until
your interfaces are stabilised and be prepared to restart your
experimental group on a regular basis.
I have thought about using OSGi for Service API classes to be served up
so they can be garbage collected, this might work for serialization too
using the context ClassLoader. I have also thought about using
ClassLoader Tree's using bytecode dependency analysis as per Tim
Blackman's research. These things start to get very complicated, just
to be able to flush the Service API classes. Wouldn't it just be better
to use mutiple services that are load balanced, enabling the jvm to be
restarted if we want to?
There are other ways to make the Service API classes garbage
collectable, such as having a tier filled with Service API ClassLoaders
where each Service and Proxy lives in a child ClassLoader in the tree,
however this presents the problem of what if an application wants to use
many Service API's or a combination, the different Service API classes
couldn't see each other from separate ClassLoaders.
Something to consider, best regards,
Peter.
Dennis Reedy wrote:
> On May 25, 2010, at 710PM, Peter Firmstone wrote:
>
>
>> 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.
>>
>
> Right now the JVM doesnt need to be shut down at all, services can be loaded with different versions, unloaded, etc ... I think you're making assumptions here.
>
>
>> 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.
>>
>
> Right, which is why service implementations get loaded into their own class loader. You define the 'platform' as whatever that needs to be for your case. For Rio it includes requisite bootstrapping and infrastructure technology. For River it most likely just includes the River 'platform', or nothing at all.
>
> Consider ServiceStarter and the class loader created from that bootstrapping process. Please explain what is missing from that approach? Each service has it's own security policy. Why does this need to change? What and how does your approach improve on? To my eyes it seems overly complicated.
>
>
>> 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?
>>
>
> Common API? The service proxies dont share anything. They are each loaded from an implementation of RMIClassLoaderApi
>
>
>> This forces you to load both proxy's into the same ClassLoader, making their implementations visible to each other and the client.
>>
>
> Not so sure about that Peter.
>
>
>> By separating the API into, in your case the CommonClassLoader,
>>
>
> APIs are not added to the CommonClassLoader, and I would argue that it should not happen. You generally do not want to add classes into a class loader that does not get GC'd.
>
>
>> 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.
>>>
>>>
>
>
>
Re: Service API, class visibility, isolation and garbage
collection - ClassLoaders
Posted by Greg Trasuk <tr...@stratuscom.com>.
Comments below...
Cheers,
Greg.
On Wed, 2010-05-26 at 07:27, Peter Firmstone wrote:
> Hi Dennis,
>
> Looking back at my earlier reply when you presented the ClassLoader
> structure for Rio, I was unintentionally insensitive.
>
> I didn't mean to pull it apart, probably not the right approach, Rio is
> a success in it's own right!
>
> What I should have said and I may not have communicated too well is that
> I'm introducing a way for Service Proxy's to utilise ClassLoader
> visibility for maximum API class sharing. It is a new feature, to give
> Service implementers the power to share their Service API's, with as
> much local JVM visibility as the Jini Platform Service API's have.
>
Um.. why? API classes are the client's problem. The service
implementer just makes a few interfaces, and possibly a few domain
classes (data types) available, and if the client wants to use them,
includes the api-jar in its classpath. I'd argue that in almost all
cases, the client is compiled against a particular api, so can go ahead
and include those jars in its runtime classpath as well. If a proxy has
its own classes, the codebase classloading mechanism (along with
preferred classes) just puts those classes into their own classloader,
and will garbage-collect the whole classloader if the proxy instance
becomes unreferenced. Surely, even smart proxies will not be so huge
that a little duplication is a problem.
Now, if you're after a generic, portable module mechanism, like OSGi but
with remotely specifiable modules, that's fine, but I'm not convinced
that's in Jini/River's purview.
> As I pointed out there is a compromise, that Service API classes cannot
> be garbage collected. I think that if this can be well managed, using a
> Permission, then it should not affect uptime for critical applications.
>
I'm hard pressed to think of a case where an api class changes without
requiring a redeployment of its clients, which, even if you're in an
application container, would trigger garbage collection of the whole
classloader. Can you give an example?
> With great power comes great responsibility... yada yada yada.
>
In my books, simplicity always wins.
> Cheers,
>
> Peter.
>
> Peter Firmstone wrote:
> > Peter Firmstone wrote:
> >> IDENTICAL TO ANOTHER MESSAGE IN THREAD: Re: Maven repository Entry
> >> was Re: Codebase service?
> >>
> >> Note: A permission will be required to allow a proxy to introduce new
> >> Service API during unmarshalling to prevent against denial of service
> >> attacks.
> > However in the absence of this permission, the additional ServiceAPI
> > jar could be downloaded into the proxy's own ClassLoader, that would
> > require a ClassLoader even for a dumb proxy with an interface you
> > didn't want to load into your Service API space. This would enable
> > unmarshalling of that Proxy. If you, at a later point decided to load
> > that interface into your Service API space, I think you still wouldn't
> > be able to interact with this particular proxy using it, since the
> > interface class identity would be different.
> >
> > Denial of service here means unfairly growing a JVM's use of non
> > garbage collectable classes. Any ideas how to control download proxy
> > memory consumption.
> >>
> >> Hi Dennis,
> >>
> >> It sounds like you remain unconvinced or don't have a need to use common
> >> interfaces for your service proxy's?
> >>
> >> So I guess it's a tread lightly approach, make the feature available to
> >> those that want common Service API (The same interface instance for all
> >> proxy's implementing that interface, so they can be used in collections
> >> or batch operations), for maximum sharing of proxy's with differing
> >> implementations, but let those that don't want to publish their API
> >> continue doing what they usually do. A configuration parameter should
> >> be able to set the desired behaviour.
> >>
> >> The approach I've taken is a simple approach to a complex problem,
> >> alternative approaches leave the complexity in the hands of the
> >> implementer, my approach will enable them to practically ignore it.
> >>
> >> Before you write it off though, to answer your earlier question, I'll
> >> further explain the ClassLoader structure between multiple nodes.
> >>
> >> CLIENT NODE
> >> ________________________________________________
> >> | |
> >> | System |
> >> | ClassLoader |
> >> | | |
> >> | Extension |
> >> | ClassLoader |
> >> | | |
> >> | Jini Platform & |
> >> | Service API |
> >> | ClassLoader |
> >> | | |
> >> | _________|___ |
> >> | | | |
> >> | Application Smart Proxy |
> >> | ClassLoader ClassLoader's |
> >> |________________________________________________|
> >>
> >>
> >> SERVICE NODE
> >> ________________________________________________
> >> | |
> >> | System |
> >> | ClassLoader |
> >> | | |
> >> | Extension |
> >> | ClassLoader |
> >> | | |
> >> | Jini Platform & |
> >> | Service API |
> >> | ClassLoader |
> >> | | |
> >> | _________|_____________________ |
> >> | | | | |
> >> | Service Imp Smart Proxy Parameter Impl |
> >> | ClassLoader ClassLoader's ClassLoader's |
> >> |________________________________________________|
> >>
> >>
> >> All Proxy and Service implementations are free to vary at will, proxy
> >> instances can be shared in collections or iterative operations based on
> >> common Service API supertype's All Proxy's and Services are isolated in
> >> their own Domain, the only way to communicate externally is by using
> >> interfaces and classes in upper level ClassLoaders, they can utilise as
> >> many third party libraries jar archives as they need, these will all be
> >> loaded into a single ClassLoader unique to that Service or Proxy's
> >> Codebase and Principles. The Service or Proxy's namespace will be
> >> totally separate from Application or other Proxy implementation's,
> >> except in the case where sharing is permitted for identical
> >> implementations by the implementation developer.
> >>
> >> Service API should be carefully considered and designed, it forms the
> >> basis of network Dependency Injection, you can discover ANY Service
> >> implementation variant using the same Service API.
> >>
> >> The Service API may include other Service API or Java platform classes.
> >>
> >> public interface SimpleBookService {
> >>
> >> public Book get( Library lib, String name);
> >>
> >> }
> >>
> >> In the SimpleBookService above, given a Library and String name of a
> >> Book, a Book instance is returned by the proxy.
> >>
> >> The contents of simpleBookService-api.jar:
> >>
> >> SimpleBookService.class
> >> Book.class
> >> Library.class
> >>
> >> Let's say a client has extended the Library, with a class called
> >> PrivateLibrary, this class is an implementation class by the client,
> >> that the Service knows nothing about, the Service only uses the Library
> >> API, but it needs the PrivateLibrary.class
> >>
> >> The client makes an archive containing the PrivateLibrary.class publicly
> >> available in an archive called privateLibrary-param.jar. This archive
> >> depends on simpleBookService-api.jar The jar URL is marshalled with the
> >> class when the parameters are sent back to the service. When it gets to
> >> the service implementation, privateLibrary-param.jar is given it's own
> >> ClassLoader and ProtectionDomain and isn't given any Permissions. It is
> >> used by a SimpleBookService implementation to decide which Book to
> >> return to the client, after which, it's garbage collected, eventually if
> >> PrivateLibrary isn't used again its ClassLoader is garbage collected
> >> too.
> >>
> >> Each SimpleBookService proxy implementation will have their own
> >> ClassLoader namespace, but Client Application classes can still use any
> >> Service implementation or as many Service implementations as it can
> >> handle at the same time, all the while treating them as the same Type.
> >>
> >> One SimpleBookService implementation proxy, contains its own
> >> implementation of Book, and while the client is reading the book, it
> >> remains available from the proxy ClassLoader via the Service API Book
> >> interface, when finished reading the book, the proxy, book and
> >> ClassLoader can be garbage collected. Tomorrow, the client might read a
> >> book from another SimpleBookService
> >>
> >> Most Service API will be relatively small bytecodes as most will be
> >> abstract or have simple implementations, the fact they're not garbage
> >> collected, doesn't matter much if the function of the node doesn't
> >> change, the API will remain limited to the subset in use, by the node.
> >>
> >> Note that Jini Platform service implementations like Reggie, Outrigger
> >> etc, will exist in Service Impl ClassLoaders and Smart Proxy
> >> ClassLoaders, only the api will be in the Jini Platform ClassLoader.
> >>
> >> Think of it as an expandable platform, everything is shared using
> >> implementations of Service API classes.
> >>
> >> It's actually a good policy to be liberal with interfaces when building
> >> the Service API classes, even with parameters and return types. Since
> >> extending interfaces is relatively straight forward, you new interfaces
> >> will be discovered by older client software as the old interface while
> >> new implementation code discovers the new interface of your service.
> >> Older nodes will load your new interface classes into the Service API
> >> space when your new proxy versions are unmarshalled. That's why it's
> >> important to maintain backward compatibility in the Service API space.
> >>
> >> So best practise would be to create an experimental djinn group until
> >> your interfaces are stabilised and be prepared to restart your
> >> experimental group on a regular basis.
> >>
> >> I have thought about using OSGi for Service API classes to be served up
> >> so they can be garbage collected, this might work for serialization too
> >> using the context ClassLoader. I have also thought about using
> >> ClassLoader Tree's using bytecode dependency analysis as per Tim
> >> Blackman's research. These things start to get very complicated, just
> >> to be able to flush the Service API classes. Wouldn't it just be better
> >> to use mutiple services that are load balanced, enabling the jvm to be
> >> restarted if we want to?
> >>
> >> There are other ways to make the Service API classes garbage
> >> collectable, such as having a tier filled with Service API ClassLoaders
> >> where each Service and Proxy lives in a child ClassLoader in the tree,
> >> however this presents the problem of what if an application wants to use
> >> many Service API's or a combination, the different Service API classes
> >> couldn't see each other from separate ClassLoaders.
> >>
> >> Something to consider, best regards,
> >>
> >> Peter.
> >>
> >> Dennis Reedy wrote:
> >>> On May 25, 2010, at 710PM, Peter Firmstone wrote:
> >>>
> >>>
> >>>> 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.
> >>>>
> >>>
> >>> Right now the JVM doesnt need to be shut down at all, services can
> >>> be loaded with different versions, unloaded, etc ... I think you're
> >>> making assumptions here.
> >>>
> >>>> 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.
> >>>>
> >>>
> >>> Right, which is why service implementations get loaded into their
> >>> own class loader. You define the 'platform' as whatever that needs
> >>> to be for your case. For Rio it includes requisite bootstrapping and
> >>> infrastructure technology. For River it most likely just includes
> >>> the River 'platform', or nothing at all.
> >>> Consider ServiceStarter and the class loader created from that
> >>> bootstrapping process. Please explain what is missing from that
> >>> approach? Each service has it's own security policy. Why does this
> >>> need to change? What and how does your approach improve on? To my
> >>> eyes it seems overly complicated.
> >>>
> >>>
> >>>> 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?
> >>>>
> >>>
> >>> Common API? The service proxies dont share anything. They are each
> >>> loaded from an implementation of RMIClassLoaderApi
> >>>
> >>>> This forces you to load both proxy's into the same ClassLoader,
> >>>> making their implementations visible to each other and the client.
> >>>>
> >>>
> >>> Not so sure about that Peter.
> >>>
> >>>
> >>>> By separating the API into, in your case the CommonClassLoader,
> >>>>
> >>>
> >>> APIs are not added to the CommonClassLoader, and I would argue that
> >>> it should not happen. You generally do not want to add classes into
> >>> a class loader that does not get GC'd.
> >>>
> >>>
> >>>> 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.
> >>>
> >>>
> >>>
> >>
> >>
> >>
> >
> >
--
Greg Trasuk, President
StratusCom Manufacturing Systems Inc. - We use information technology to
solve business problems on your plant floor.
http://stratuscom.com
Re: Service API, class visibility, isolation and garbage collection
- ClassLoaders
Posted by Peter Firmstone <ji...@zeus.net.au>.
Dennis Reedy wrote:
> On May 27, 2010, at 451AM, Peter Firmstone wrote:
>
>
>> Hi Dennis,
>>
>> I can live with Compile time only Service API's (not dynamically loaded), as has been identified, the API is known prior by the application.
>>
>
> I'm sorry for not answering your question directly, I want to make sure I understand you correctly.
>
> By compile time, are you thinking of an environment that only deals with classes that are loaded at JVM start time?
>
> Or, since a client needs to have some a-priori knowledge of what it wants to discover and use, that means the class(es) are known by the client in advance. And those classes are included in the classpath of the client. Is that what you mean by compile time?
>
The latter.
>
>> We should encourage developers to maker their Service API publicly available on Maven repository's, for others to implement.
>>
>
> Well, it would be for others to 'use'. Typically artifacts are published to repositories so you can use them. You may be able to obtain the sources, and depending on the license (or other criteria) of the project create derivative implementation(s). But in general the issue is not one of creating implementations, but one of use and inclusion into the systems that you create.
>
>
>> So we can implement any Service API, whether we have the source or not, confident that it cannot obtain any Permission's, we can guarantee this by using static immutable ProtectionDomain's for Service API, where Policy checks are excluded. Is this the best policy? Or should we allow dynamic Permission grants for ServiceAPI too? We can always relax our policy later, to make it stricter would risk breaking code if we had to reverse the decision.
>>
>>
>> Service Implementers produce jar archives for:
>>
>> Smart Proxy's:
>>
>> Implementation jar: service.jar (depends on service-api.jar)
>> API jar: service-api.jar (unless implemented already)
>> Smart proxy jar: service-proxy.jar (depends on service-api.jar)
>> The proxy can depend on other jar's too.
>>
>> Dumb Proxy's:
>>
>> Implementation jar: service.jar (depends on service-api.jar)
>> API jar: service-api.jar
>>
>>
>> Client's must produce the following jar archive, if extending Parameters:
>>
>> Client Parameter extensions: AnyNameYouLike-param.jar
>>
>>
>
> Why do we need the -param.jar again?
>
If we have multiple organisations, entities or companies, cooperating
using River, a Services API, might have some parameter classes that are
interfaces or extendible classes. Where a service is used as a means of
exchanging Objects between the two companies, the client developer and
the Service developer are independent parties.
If the client developer wishes to extend some parameter classes, he
would need to make those available for the Service implementation. The
client might initially use some default parameter classes provided by
the Service, but later decide to extend these classes for whatever reason.
It enables the client to extend or change these parameter classes
dynamically.
It's a separation of concerns, an optional package produced by the
client developer.
Cheers,
Peter.
Re: Service API, class visibility, isolation and garbage collection
- ClassLoaders
Posted by Peter Firmstone <ji...@zeus.net.au>.
Dennis Reedy wrote:
>> We should encourage developers to maker their Service API publicly available on Maven repository's, for others to implement.
>>
>
> Well, it would be for others to 'use'. Typically artifacts are published to repositories so you can use them. You may be able to obtain the sources, and depending on the license (or other criteria) of the project create derivative implementation(s). But in general the issue is not one of creating implementations, but one of use and inclusion into the systems that you create.
>
Yes, but I'd like to build a reusable public library of Service API's
for developers to utilise. Who know's some standard interfaces for
commerce etc, might crop up.
Do you think this would be better served as a Subproject? Would anyone
be interested in contributing Service API?
I suppose the thought may frighten some, as there is some benefit in an
attacker not knowing a Service API. Security by obscurity is foolhardy,
if they're determined, they can find it using bytecode analysis, or
reflection.
We can use other measures such as Delayed Unmarshalling, Download
Permission, Authentication, Integrity, Privacy (encryption), Trust and
Isolation (Permissions, ProtectionDomains & ClassLoader vis) to secure
public distributed programmes over untrusted networks.
Regards,
Peter.
>
>> So we can implement any Service API, whether we have the source or not, confident that it cannot obtain any Permission's, we can guarantee this by using static immutable ProtectionDomain's for Service API, where Policy checks are excluded. Is this the best policy? Or should we allow dynamic Permission grants for ServiceAPI too? We can always relax our policy later, to make it stricter would risk breaking code if we had to reverse the decision.
>>
>>
>> Service Implementers produce jar archives for:
>>
>> Smart Proxy's:
>>
>> Implementation jar: service.jar (depends on service-api.jar)
>> API jar: service-api.jar (unless implemented already)
>> Smart proxy jar: service-proxy.jar (depends on service-api.jar)
>> The proxy can depend on other jar's too.
>>
>> Dumb Proxy's:
>>
>> Implementation jar: service.jar (depends on service-api.jar)
>> API jar: service-api.jar
>>
>>
>> Client's must produce the following jar archive, if extending Parameters:
>>
>> Client Parameter extensions: AnyNameYouLike-param.jar
>>
Re: Service API, class visibility, isolation and garbage collection - ClassLoaders
Posted by Dennis Reedy <de...@gmail.com>.
On May 27, 2010, at 451AM, Peter Firmstone wrote:
> Hi Dennis,
>
> I can live with Compile time only Service API's (not dynamically loaded), as has been identified, the API is known prior by the application.
I'm sorry for not answering your question directly, I want to make sure I understand you correctly.
By compile time, are you thinking of an environment that only deals with classes that are loaded at JVM start time?
Or, since a client needs to have some a-priori knowledge of what it wants to discover and use, that means the class(es) are known by the client in advance. And those classes are included in the classpath of the client. Is that what you mean by compile time?
>
> We should encourage developers to maker their Service API publicly available on Maven repository's, for others to implement.
Well, it would be for others to 'use'. Typically artifacts are published to repositories so you can use them. You may be able to obtain the sources, and depending on the license (or other criteria) of the project create derivative implementation(s). But in general the issue is not one of creating implementations, but one of use and inclusion into the systems that you create.
>
> So we can implement any Service API, whether we have the source or not, confident that it cannot obtain any Permission's, we can guarantee this by using static immutable ProtectionDomain's for Service API, where Policy checks are excluded. Is this the best policy? Or should we allow dynamic Permission grants for ServiceAPI too? We can always relax our policy later, to make it stricter would risk breaking code if we had to reverse the decision.
>
>
> Service Implementers produce jar archives for:
>
> Smart Proxy's:
>
> Implementation jar: service.jar (depends on service-api.jar)
> API jar: service-api.jar (unless implemented already)
> Smart proxy jar: service-proxy.jar (depends on service-api.jar)
> The proxy can depend on other jar's too.
>
> Dumb Proxy's:
>
> Implementation jar: service.jar (depends on service-api.jar)
> API jar: service-api.jar
>
>
> Client's must produce the following jar archive, if extending Parameters:
>
> Client Parameter extensions: AnyNameYouLike-param.jar
>
Why do we need the -param.jar again?
Re: Service API, class visibility, isolation and garbage collection
- ClassLoaders
Posted by Peter Firmstone <ji...@zeus.net.au>.
Hi Dennis,
I can live with Compile time only Service API's (not dynamically
loaded), as has been identified, the API is known prior by the application.
We should encourage developers to maker their Service API publicly
available on Maven repository's, for others to implement.
Does anyone have any recommendations for ClassLoader structure or how to
set it up, based on the following information?
1. Public Service API, we've assumed cannot be trusted.
2. Service API must be in a Parent ClassLoader relative to Client's,
Service Proxy's and Implementation's, so the Service API's
ProtectionDomain can be removed from the stack when the proxy or
the client need to make a SecurityManager sm.checkPermission()?
While the Service API is on the call stack with no Permission's,
the Permissions of proxy's, service implementation's or client's
cannot be elevated.
3. It isn't safe to remove the Service API's ProtectionDomain from
the stack if your classes are visible to that Service API,
otherwise it could gain Permissions.
4. The service API must not see our implementations, so it cannot
take advantage of the fact that we remove it's ProtectionDomain
from our security checks in child ClassLoaders.
5. This also means that if we implement an interface that requires a
security check and the Service API can see that interface, the
Service API must not be removed from the stack during
checkPermission(). The higher up the ClassLoader tree the Service
API is, the better, there's less to worry about.
6. For ClassLoader domains visible to the Service API, the Service
API ProtectionDomain cannot be removed from the stack.
So we can implement any Service API, whether we have the source or not,
confident that it cannot obtain any Permission's, we can guarantee this
by using static immutable ProtectionDomain's for Service API, where
Policy checks are excluded. Is this the best policy? Or should we
allow dynamic Permission grants for ServiceAPI too? We can always relax
our policy later, to make it stricter would risk breaking code if we had
to reverse the decision.
Service Implementers produce jar archives for:
Smart Proxy's:
Implementation jar: service.jar (depends on service-api.jar)
API jar: service-api.jar (unless implemented already)
Smart proxy jar: service-proxy.jar (depends on service-api.jar)
The proxy can depend on other jar's too.
Dumb Proxy's:
Implementation jar: service.jar (depends on service-api.jar)
API jar: service-api.jar
Client's must produce the following jar archive, if extending Parameters:
Client Parameter extensions: AnyNameYouLike-param.jar
If we want to provide a publicly available Service, we can publish these
artefacts on Maven's repository and anyone can use it.
My apologies to the list for sending the last message 4 times! Poor
mobile reception was the culprit.
Cheers,
Peter.
Dennis Reedy wrote:
> On May 26, 2010, at 609PM, Peter Firmstone wrote:
>
>> Dennis Reedy wrote:
>>> Peter,
>>>
>>> No worries. Although I think there is still a misunderstanding on how the class loader structure works,
>> Ok, I think I see it now, your ClassLoader structure represents your container. Containers are free to come and go in Rio during the life of the application?
>
> No, services are. BTW, this is a very similar structure to what ServiceStarter produces, the big difference is the addition of the common class loader that contains platform jars that are basically immutable, and not counted on to be changing during the lifecycle of the JVM.
>
>
Re: Service API, class visibility, isolation and garbage collection - ClassLoaders
Posted by Dennis Reedy <de...@gmail.com>.
On May 26, 2010, at 609PM, Peter Firmstone wrote:
> Dennis Reedy wrote:
>> Peter,
>>
>> No worries. Although I think there is still a misunderstanding on how the class loader structure works,
>
> Ok, I think I see it now, your ClassLoader structure represents your container. Containers are free to come and go in Rio during the life of the application?
No, services are. BTW, this is a very similar structure to what ServiceStarter produces, the big difference is the addition of the common class loader that contains platform jars that are basically immutable, and not counted on to be changing during the lifecycle of the JVM.
Re: Service API, class visibility, isolation and garbage collection
- ClassLoaders
Posted by Peter Firmstone <ji...@zeus.net.au>.
Dennis Reedy wrote:
> Peter,
>
> No worries. Although I think there is still a misunderstanding on how the class loader structure works,
Ok, I think I see it now, your ClassLoader structure represents your
container. Containers are free to come and go in Rio during the life of
the application?
If I've got that correct, this is very useful.
I wasn't thinking about containers, only a bare metal JVM.
What you have could be very useful to me.
> its water under the bridge - lets move on.
>
> What I cant figure out is if you want to share classes across downloaded proxies, why the classes are not part of the API jar the client has in it's classpath. This allows downloaded proxies access to these classes, since the classloader they are loaded with delegates to the classloader that the API jar has been loaded with.
>
Thinking about dynamic application assembly, not all the API is known at
compile time, it has to be discovered later.
> It seems you are creating an edge condition where an implementor would like downloaded proxies to share a class across implementations, but in order to do that that class needs to be injected into a parent class loader. Do I have this right?
>
Yes.
> IMO, in this scenario, I would advise that the class(es) in question should be added to the API jar.
>
> AppCL
>
Yes agreed, I just want to delay it until after startup, not known at
compile time.
I think what I have as ServiceImpCL and SmartProxyCL and ParamterImpCL
all map quite well to your Service-nCL'
N.B. I'm not a Programmer, so you'll have to bear with me I'm afraid,
while I'm probably out of my depth, I couldn't let River die, I don't
know why programmers can't see Jini's strengths.
In my job we undertake seemingly impossible tasks, Construction & Heavy
(5000T) Machinery Overhauls we always end up figuring it out however.
Thanks Peter.
>
> On May 26, 2010, at 727AM, Peter Firmstone wrote:
>
>
>> Hi Dennis,
>>
>> Looking back at my earlier reply when you presented the ClassLoader structure for Rio, I was unintentionally insensitive.
>>
>> I didn't mean to pull it apart, probably not the right approach, Rio is a success in it's own right!
>>
>> What I should have said and I may not have communicated too well is that I'm introducing a way for Service Proxy's to utilise ClassLoader visibility for maximum API class sharing. It is a new feature, to give Service implementers the power to share their Service API's, with as much local JVM visibility as the Jini Platform Service API's have.
>>
>> As I pointed out there is a compromise, that Service API classes cannot be garbage collected. I think that if this can be well managed, using a Permission, then it should not affect uptime for critical applications.
>>
>> With great power comes great responsibility... yada yada yada.
>>
>> Cheers,
>>
>> Peter.
>>
>> Peter Firmstone wrote:
>>
>>> Peter Firmstone wrote:
>>>
>>>> IDENTICAL TO ANOTHER MESSAGE IN THREAD: Re: Maven repository Entry was Re: Codebase service?
>>>>
>>>> Note: A permission will be required to allow a proxy to introduce new Service API during unmarshalling to prevent against denial of service attacks.
>>>>
>>> However in the absence of this permission, the additional ServiceAPI jar could be downloaded into the proxy's own ClassLoader, that would require a ClassLoader even for a dumb proxy with an interface you didn't want to load into your Service API space. This would enable unmarshalling of that Proxy. If you, at a later point decided to load that interface into your Service API space, I think you still wouldn't be able to interact with this particular proxy using it, since the interface class identity would be different.
>>>
>>> Denial of service here means unfairly growing a JVM's use of non garbage collectable classes. Any ideas how to control download proxy memory consumption.
>>>
>>>> Hi Dennis,
>>>>
>>>> It sounds like you remain unconvinced or don't have a need to use common
>>>> interfaces for your service proxy's?
>>>>
>>>> So I guess it's a tread lightly approach, make the feature available to
>>>> those that want common Service API (The same interface instance for all
>>>> proxy's implementing that interface, so they can be used in collections
>>>> or batch operations), for maximum sharing of proxy's with differing
>>>> implementations, but let those that don't want to publish their API
>>>> continue doing what they usually do. A configuration parameter should
>>>> be able to set the desired behaviour.
>>>>
>>>> The approach I've taken is a simple approach to a complex problem,
>>>> alternative approaches leave the complexity in the hands of the
>>>> implementer, my approach will enable them to practically ignore it.
>>>>
>>>> Before you write it off though, to answer your earlier question, I'll
>>>> further explain the ClassLoader structure between multiple nodes.
>>>>
>>>> CLIENT NODE
>>>> ________________________________________________
>>>> | |
>>>> | System |
>>>> | ClassLoader |
>>>> | | |
>>>> | Extension |
>>>> | ClassLoader |
>>>> | | |
>>>> | Jini Platform & |
>>>> | Service API |
>>>> | ClassLoader |
>>>> | | |
>>>> | _________|___ |
>>>> | | | |
>>>> | Application Smart Proxy |
>>>> | ClassLoader ClassLoader's |
>>>> |________________________________________________|
>>>>
>>>>
>>>> SERVICE NODE
>>>> ________________________________________________
>>>> | |
>>>> | System |
>>>> | ClassLoader |
>>>> | | |
>>>> | Extension |
>>>> | ClassLoader |
>>>> | | |
>>>> | Jini Platform & |
>>>> | Service API |
>>>> | ClassLoader |
>>>> | | |
>>>> | _________|_____________________ |
>>>> | | | | |
>>>> | Service Imp Smart Proxy Parameter Impl |
>>>> | ClassLoader ClassLoader's ClassLoader's |
>>>> |________________________________________________|
>>>>
>>>>
>>>> All Proxy and Service implementations are free to vary at will, proxy
>>>> instances can be shared in collections or iterative operations based on
>>>> common Service API supertype's All Proxy's and Services are isolated in
>>>> their own Domain, the only way to communicate externally is by using
>>>> interfaces and classes in upper level ClassLoaders, they can utilise as
>>>> many third party libraries jar archives as they need, these will all be
>>>> loaded into a single ClassLoader unique to that Service or Proxy's
>>>> Codebase and Principles. The Service or Proxy's namespace will be
>>>> totally separate from Application or other Proxy implementation's,
>>>> except in the case where sharing is permitted for identical
>>>> implementations by the implementation developer.
>>>>
>>>> Service API should be carefully considered and designed, it forms the
>>>> basis of network Dependency Injection, you can discover ANY Service
>>>> implementation variant using the same Service API.
>>>>
>>>> The Service API may include other Service API or Java platform classes.
>>>>
>>>> public interface SimpleBookService {
>>>>
>>>> public Book get( Library lib, String name);
>>>>
>>>> }
>>>>
>>>> In the SimpleBookService above, given a Library and String name of a
>>>> Book, a Book instance is returned by the proxy.
>>>>
>>>> The contents of simpleBookService-api.jar:
>>>>
>>>> SimpleBookService.class
>>>> Book.class
>>>> Library.class
>>>>
>>>> Let's say a client has extended the Library, with a class called
>>>> PrivateLibrary, this class is an implementation class by the client,
>>>> that the Service knows nothing about, the Service only uses the Library
>>>> API, but it needs the PrivateLibrary.class
>>>>
>>>> The client makes an archive containing the PrivateLibrary.class publicly
>>>> available in an archive called privateLibrary-param.jar. This archive
>>>> depends on simpleBookService-api.jar The jar URL is marshalled with the
>>>> class when the parameters are sent back to the service. When it gets to
>>>> the service implementation, privateLibrary-param.jar is given it's own
>>>> ClassLoader and ProtectionDomain and isn't given any Permissions. It is
>>>> used by a SimpleBookService implementation to decide which Book to
>>>> return to the client, after which, it's garbage collected, eventually if
>>>> PrivateLibrary isn't used again its ClassLoader is garbage collected too.
>>>>
>>>> Each SimpleBookService proxy implementation will have their own
>>>> ClassLoader namespace, but Client Application classes can still use any
>>>> Service implementation or as many Service implementations as it can
>>>> handle at the same time, all the while treating them as the same Type.
>>>>
>>>> One SimpleBookService implementation proxy, contains its own
>>>> implementation of Book, and while the client is reading the book, it
>>>> remains available from the proxy ClassLoader via the Service API Book
>>>> interface, when finished reading the book, the proxy, book and
>>>> ClassLoader can be garbage collected. Tomorrow, the client might read a
>>>> book from another SimpleBookService
>>>>
>>>> Most Service API will be relatively small bytecodes as most will be
>>>> abstract or have simple implementations, the fact they're not garbage
>>>> collected, doesn't matter much if the function of the node doesn't
>>>> change, the API will remain limited to the subset in use, by the node.
>>>>
>>>> Note that Jini Platform service implementations like Reggie, Outrigger
>>>> etc, will exist in Service Impl ClassLoaders and Smart Proxy
>>>> ClassLoaders, only the api will be in the Jini Platform ClassLoader.
>>>>
>>>> Think of it as an expandable platform, everything is shared using
>>>> implementations of Service API classes.
>>>>
>>>> It's actually a good policy to be liberal with interfaces when building
>>>> the Service API classes, even with parameters and return types. Since
>>>> extending interfaces is relatively straight forward, you new interfaces
>>>> will be discovered by older client software as the old interface while
>>>> new implementation code discovers the new interface of your service.
>>>> Older nodes will load your new interface classes into the Service API
>>>> space when your new proxy versions are unmarshalled. That's why it's
>>>> important to maintain backward compatibility in the Service API space.
>>>>
>>>> So best practise would be to create an experimental djinn group until
>>>> your interfaces are stabilised and be prepared to restart your
>>>> experimental group on a regular basis.
>>>>
>>>> I have thought about using OSGi for Service API classes to be served up
>>>> so they can be garbage collected, this might work for serialization too
>>>> using the context ClassLoader. I have also thought about using
>>>> ClassLoader Tree's using bytecode dependency analysis as per Tim
>>>> Blackman's research. These things start to get very complicated, just
>>>> to be able to flush the Service API classes. Wouldn't it just be better
>>>> to use mutiple services that are load balanced, enabling the jvm to be
>>>> restarted if we want to?
>>>>
>>>> There are other ways to make the Service API classes garbage
>>>> collectable, such as having a tier filled with Service API ClassLoaders
>>>> where each Service and Proxy lives in a child ClassLoader in the tree,
>>>> however this presents the problem of what if an application wants to use
>>>> many Service API's or a combination, the different Service API classes
>>>> couldn't see each other from separate ClassLoaders.
>>>>
>>>> Something to consider, best regards,
>>>>
>>>> Peter.
>>>>
>>>> Dennis Reedy wrote:
>>>>
>>>>> On May 25, 2010, at 710PM, Peter Firmstone wrote:
>>>>>
>>>>>
>>>>>
>>>>>> 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.
>>>>>>
>>>>>>
>>>>> Right now the JVM doesnt need to be shut down at all, services can be loaded with different versions, unloaded, etc ... I think you're making assumptions here.
>>>>>
>>>>>
>>>>>> 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.
>>>>>>
>>>>>>
>>>>> Right, which is why service implementations get loaded into their own class loader. You define the 'platform' as whatever that needs to be for your case. For Rio it includes requisite bootstrapping and infrastructure technology. For River it most likely just includes the River 'platform', or nothing at all.
>>>>> Consider ServiceStarter and the class loader created from that bootstrapping process. Please explain what is missing from that approach? Each service has it's own security policy. Why does this need to change? What and how does your approach improve on? To my eyes it seems overly complicated.
>>>>>
>>>>>
>>>>>
>>>>>> 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?
>>>>>>
>>>>>>
>>>>> Common API? The service proxies dont share anything. They are each loaded from an implementation of RMIClassLoaderApi
>>>>>
>>>>>
>>>>>> This forces you to load both proxy's into the same ClassLoader, making their implementations visible to each other and the client.
>>>>>>
>>>>>>
>>>>> Not so sure about that Peter.
>>>>>
>>>>>
>>>>>
>>>>>> By separating the API into, in your case the CommonClassLoader,
>>>>>>
>>>>>>
>>>>> APIs are not added to the CommonClassLoader, and I would argue that it should not happen. You generally do not want to add classes into a class loader that does not get GC'd.
>>>>>
>>>>>
>>>>>
>>>>>> 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.
>>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>
>
>
Re: Service API, class visibility, isolation and garbage collection
- ClassLoaders
Posted by Peter Firmstone <ji...@zeus.net.au>.
Dennis Reedy wrote:
> Peter,
>
> No worries. Although I think there is still a misunderstanding on how the class loader structure works,
Ok, I think I see it now, your ClassLoader structure represents your
container. Containers are free to come and go in Rio during the life of
the application?
If I've got that correct, this is very useful.
I wasn't thinking about containers, only a bare metal JVM.
What you have could be very useful to me.
> its water under the bridge - lets move on.
>
> What I cant figure out is if you want to share classes across downloaded proxies, why the classes are not part of the API jar the client has in it's classpath. This allows downloaded proxies access to these classes, since the classloader they are loaded with delegates to the classloader that the API jar has been loaded with.
>
Thinking about dynamic application assembly, not all the API is known at
compile time, it has to be discovered later.
> It seems you are creating an edge condition where an implementor would like downloaded proxies to share a class across implementations, but in order to do that that class needs to be injected into a parent class loader. Do I have this right?
>
Yes.
> IMO, in this scenario, I would advise that the class(es) in question should be added to the API jar.
>
> AppCL
>
Yes agreed, I just want to delay it until after startup, not known at
compile time.
I think what I have as ServiceImpCL and SmartProxyCL and ParamterImpCL
all map quite well to your Service-nCL'
N.B. I'm not a Programmer, so you'll have to bear with me I'm afraid,
while I'm probably out of my depth, I couldn't let River die, I don't
know why programmers can't see Jini's strengths.
In my job we undertake seemingly impossible tasks, Construction & Heavy
(4000T) Machinery Overhauls we always end up figuring it out however.
Thanks Peter.
>
> On May 26, 2010, at 727AM, Peter Firmstone wrote:
>
>
>> Hi Dennis,
>>
>> Looking back at my earlier reply when you presented the ClassLoader structure for Rio, I was unintentionally insensitive.
>>
>> I didn't mean to pull it apart, probably not the right approach, Rio is a success in it's own right!
>>
>> What I should have said and I may not have communicated too well is that I'm introducing a way for Service Proxy's to utilise ClassLoader visibility for maximum API class sharing. It is a new feature, to give Service implementers the power to share their Service API's, with as much local JVM visibility as the Jini Platform Service API's have.
>>
>> As I pointed out there is a compromise, that Service API classes cannot be garbage collected. I think that if this can be well managed, using a Permission, then it should not affect uptime for critical applications.
>>
>> With great power comes great responsibility... yada yada yada.
>>
>> Cheers,
>>
>> Peter.
>>
>> Peter Firmstone wrote:
>>
>>> Peter Firmstone wrote:
>>>
>>>> IDENTICAL TO ANOTHER MESSAGE IN THREAD: Re: Maven repository Entry was Re: Codebase service?
>>>>
>>>> Note: A permission will be required to allow a proxy to introduce new Service API during unmarshalling to prevent against denial of service attacks.
>>>>
>>> However in the absence of this permission, the additional ServiceAPI jar could be downloaded into the proxy's own ClassLoader, that would require a ClassLoader even for a dumb proxy with an interface you didn't want to load into your Service API space. This would enable unmarshalling of that Proxy. If you, at a later point decided to load that interface into your Service API space, I think you still wouldn't be able to interact with this particular proxy using it, since the interface class identity would be different.
>>>
>>> Denial of service here means unfairly growing a JVM's use of non garbage collectable classes. Any ideas how to control download proxy memory consumption.
>>>
>>>> Hi Dennis,
>>>>
>>>> It sounds like you remain unconvinced or don't have a need to use common
>>>> interfaces for your service proxy's?
>>>>
>>>> So I guess it's a tread lightly approach, make the feature available to
>>>> those that want common Service API (The same interface instance for all
>>>> proxy's implementing that interface, so they can be used in collections
>>>> or batch operations), for maximum sharing of proxy's with differing
>>>> implementations, but let those that don't want to publish their API
>>>> continue doing what they usually do. A configuration parameter should
>>>> be able to set the desired behaviour.
>>>>
>>>> The approach I've taken is a simple approach to a complex problem,
>>>> alternative approaches leave the complexity in the hands of the
>>>> implementer, my approach will enable them to practically ignore it.
>>>>
>>>> Before you write it off though, to answer your earlier question, I'll
>>>> further explain the ClassLoader structure between multiple nodes.
>>>>
>>>> CLIENT NODE
>>>> ________________________________________________
>>>> | |
>>>> | System |
>>>> | ClassLoader |
>>>> | | |
>>>> | Extension |
>>>> | ClassLoader |
>>>> | | |
>>>> | Jini Platform & |
>>>> | Service API |
>>>> | ClassLoader |
>>>> | | |
>>>> | _________|___ |
>>>> | | | |
>>>> | Application Smart Proxy |
>>>> | ClassLoader ClassLoader's |
>>>> |________________________________________________|
>>>>
>>>>
>>>> SERVICE NODE
>>>> ________________________________________________
>>>> | |
>>>> | System |
>>>> | ClassLoader |
>>>> | | |
>>>> | Extension |
>>>> | ClassLoader |
>>>> | | |
>>>> | Jini Platform & |
>>>> | Service API |
>>>> | ClassLoader |
>>>> | | |
>>>> | _________|_____________________ |
>>>> | | | | |
>>>> | Service Imp Smart Proxy Parameter Impl |
>>>> | ClassLoader ClassLoader's ClassLoader's |
>>>> |________________________________________________|
>>>>
>>>>
>>>> All Proxy and Service implementations are free to vary at will, proxy
>>>> instances can be shared in collections or iterative operations based on
>>>> common Service API supertype's All Proxy's and Services are isolated in
>>>> their own Domain, the only way to communicate externally is by using
>>>> interfaces and classes in upper level ClassLoaders, they can utilise as
>>>> many third party libraries jar archives as they need, these will all be
>>>> loaded into a single ClassLoader unique to that Service or Proxy's
>>>> Codebase and Principles. The Service or Proxy's namespace will be
>>>> totally separate from Application or other Proxy implementation's,
>>>> except in the case where sharing is permitted for identical
>>>> implementations by the implementation developer.
>>>>
>>>> Service API should be carefully considered and designed, it forms the
>>>> basis of network Dependency Injection, you can discover ANY Service
>>>> implementation variant using the same Service API.
>>>>
>>>> The Service API may include other Service API or Java platform classes.
>>>>
>>>> public interface SimpleBookService {
>>>>
>>>> public Book get( Library lib, String name);
>>>>
>>>> }
>>>>
>>>> In the SimpleBookService above, given a Library and String name of a
>>>> Book, a Book instance is returned by the proxy.
>>>>
>>>> The contents of simpleBookService-api.jar:
>>>>
>>>> SimpleBookService.class
>>>> Book.class
>>>> Library.class
>>>>
>>>> Let's say a client has extended the Library, with a class called
>>>> PrivateLibrary, this class is an implementation class by the client,
>>>> that the Service knows nothing about, the Service only uses the Library
>>>> API, but it needs the PrivateLibrary.class
>>>>
>>>> The client makes an archive containing the PrivateLibrary.class publicly
>>>> available in an archive called privateLibrary-param.jar. This archive
>>>> depends on simpleBookService-api.jar The jar URL is marshalled with the
>>>> class when the parameters are sent back to the service. When it gets to
>>>> the service implementation, privateLibrary-param.jar is given it's own
>>>> ClassLoader and ProtectionDomain and isn't given any Permissions. It is
>>>> used by a SimpleBookService implementation to decide which Book to
>>>> return to the client, after which, it's garbage collected, eventually if
>>>> PrivateLibrary isn't used again its ClassLoader is garbage collected too.
>>>>
>>>> Each SimpleBookService proxy implementation will have their own
>>>> ClassLoader namespace, but Client Application classes can still use any
>>>> Service implementation or as many Service implementations as it can
>>>> handle at the same time, all the while treating them as the same Type.
>>>>
>>>> One SimpleBookService implementation proxy, contains its own
>>>> implementation of Book, and while the client is reading the book, it
>>>> remains available from the proxy ClassLoader via the Service API Book
>>>> interface, when finished reading the book, the proxy, book and
>>>> ClassLoader can be garbage collected. Tomorrow, the client might read a
>>>> book from another SimpleBookService
>>>>
>>>> Most Service API will be relatively small bytecodes as most will be
>>>> abstract or have simple implementations, the fact they're not garbage
>>>> collected, doesn't matter much if the function of the node doesn't
>>>> change, the API will remain limited to the subset in use, by the node.
>>>>
>>>> Note that Jini Platform service implementations like Reggie, Outrigger
>>>> etc, will exist in Service Impl ClassLoaders and Smart Proxy
>>>> ClassLoaders, only the api will be in the Jini Platform ClassLoader.
>>>>
>>>> Think of it as an expandable platform, everything is shared using
>>>> implementations of Service API classes.
>>>>
>>>> It's actually a good policy to be liberal with interfaces when building
>>>> the Service API classes, even with parameters and return types. Since
>>>> extending interfaces is relatively straight forward, you new interfaces
>>>> will be discovered by older client software as the old interface while
>>>> new implementation code discovers the new interface of your service.
>>>> Older nodes will load your new interface classes into the Service API
>>>> space when your new proxy versions are unmarshalled. That's why it's
>>>> important to maintain backward compatibility in the Service API space.
>>>>
>>>> So best practise would be to create an experimental djinn group until
>>>> your interfaces are stabilised and be prepared to restart your
>>>> experimental group on a regular basis.
>>>>
>>>> I have thought about using OSGi for Service API classes to be served up
>>>> so they can be garbage collected, this might work for serialization too
>>>> using the context ClassLoader. I have also thought about using
>>>> ClassLoader Tree's using bytecode dependency analysis as per Tim
>>>> Blackman's research. These things start to get very complicated, just
>>>> to be able to flush the Service API classes. Wouldn't it just be better
>>>> to use mutiple services that are load balanced, enabling the jvm to be
>>>> restarted if we want to?
>>>>
>>>> There are other ways to make the Service API classes garbage
>>>> collectable, such as having a tier filled with Service API ClassLoaders
>>>> where each Service and Proxy lives in a child ClassLoader in the tree,
>>>> however this presents the problem of what if an application wants to use
>>>> many Service API's or a combination, the different Service API classes
>>>> couldn't see each other from separate ClassLoaders.
>>>>
>>>> Something to consider, best regards,
>>>>
>>>> Peter.
>>>>
>>>> Dennis Reedy wrote:
>>>>
>>>>> On May 25, 2010, at 710PM, Peter Firmstone wrote:
>>>>>
>>>>>
>>>>>
>>>>>> 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.
>>>>>>
>>>>>>
>>>>> Right now the JVM doesnt need to be shut down at all, services can be loaded with different versions, unloaded, etc ... I think you're making assumptions here.
>>>>>
>>>>>
>>>>>> 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.
>>>>>>
>>>>>>
>>>>> Right, which is why service implementations get loaded into their own class loader. You define the 'platform' as whatever that needs to be for your case. For Rio it includes requisite bootstrapping and infrastructure technology. For River it most likely just includes the River 'platform', or nothing at all.
>>>>> Consider ServiceStarter and the class loader created from that bootstrapping process. Please explain what is missing from that approach? Each service has it's own security policy. Why does this need to change? What and how does your approach improve on? To my eyes it seems overly complicated.
>>>>>
>>>>>
>>>>>
>>>>>> 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?
>>>>>>
>>>>>>
>>>>> Common API? The service proxies dont share anything. They are each loaded from an implementation of RMIClassLoaderApi
>>>>>
>>>>>
>>>>>> This forces you to load both proxy's into the same ClassLoader, making their implementations visible to each other and the client.
>>>>>>
>>>>>>
>>>>> Not so sure about that Peter.
>>>>>
>>>>>
>>>>>
>>>>>> By separating the API into, in your case the CommonClassLoader,
>>>>>>
>>>>>>
>>>>> APIs are not added to the CommonClassLoader, and I would argue that it should not happen. You generally do not want to add classes into a class loader that does not get GC'd.
>>>>>
>>>>>
>>>>>
>>>>>> 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.
>>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>
>
>
Re: Service API, class visibility, isolation and garbage collection
- ClassLoaders
Posted by Peter Firmstone <ji...@zeus.net.au>.
Peter Firmstone wrote:
> So client Proxy trust is currently:
>
> 1. Download the Proxy codebase.
> 2. Unmarshall the Proxy.
> 3. Ask the Proxy for the Proxy verifier.
> 4. Ask the Server if it trusts the proxy.
> 5. Grant trust to the proxy ClassLoader.
>
Another minor clarification, I missed out Authentication above, which
comes before proxy Verification.
Re: ServiceRegistrar
Posted by Peter Firmstone <ji...@zeus.net.au>.
Thanks you comments are all much appreciated.
I'm having some thoughts about a ServiceRegistrar that is only a
downloadable proxy without a server, that contains only the marshalled
smart proxy instances of Services, that a single host provides, decided
prior to deployment. Sort of like an advertising medium found using
discovery.
In other words, a static ServiceRegistrar smart proxy.
This would allow all languages to participate in providing services, in
untrusted uncontrolled networks, using any Protocol they want. To work
where Surrogate doesn't, in environments, where there may be no
Registrar at all.
It would require a standard tool for developers to create the Serialized
form of the Registrar, containing the Marshalled Proxy's of the Services
that are going to be advertised. We could provide a standard download
codebase for the Static Registrar, the implementing developer would need
to create codebases for his / her service smart proxy's.
The problem of course is, how do you provide security for the client,
when you don't know what protocol the Service is using. I'm thinking
that it is simpler to deny trust. The codebases, however they are
attained, would need to advertise their size, in an Entry. The codebase
download would be aborted if the codebase size exceeded the advertised size.
Even without trust, and a restriction on codebase size, a misbehaving
Service Proxy can enter an endless loop, perhaps it should be
encapsulated inside a Security Layer Delegate, that runs a time limited
thread that executes the Proxy methods on the clients behalf, if the
proxy doesn't return within a set time limit, it terminates the proxy's
thread and throws an IOException.
When you think about the possibility of Permission's being advertised in
the jar file, if it was signed by a trusted developer, and there was a
way for the codebase to also indicate if it uses, a communication
protocol with privacy and integrity (another Entry?), you could grant
that codebase some Permission's but you still couldn't trust who or what
was on the Server end of that proxy, even if the communication was
private. However it does allow enough trust to be established to
authenticate the Service
You might say that there's a flaw in the above, a protocol that is
considered secure at the time of development may no longer be secure
when the client access the Service.
There is a simple way to fix this without un-abstracting the underlying
protocol used, it is simply another service that developers use to
advertise codebase implementations with security flaws, with a list of
permissions that if revoked, will prevent the security attack.
Of course you'll need to look at the code from my latest commit to see
how this is possible ;)
Thoughts? What have I missed?
Cheers,
Peter.
Gregg Wonderly wrote:
> I agree, doing both would be the best choice of implementation.
>
> Gregg Wonderly
>
> Christopher Dolan wrote:
>> Best would be to block on both client and server side. Client to
>> help performance and server to prevent malicious intent. Server side
>> would be the minimum implementation.
>>
>> Chris
>>
>> -----Original Message-----
>> From: Patrick Wright [mailto:pdoubleya@gmail.com] Sent: Monday, June
>> 28, 2010 3:17 AM
>> To: river-dev@incubator.apache.org
>> Subject: Re: ServiceRegistrar
>>
>> On Mon, Jun 28, 2010 at 10:11 AM, Tom Hobbs <tv...@googlemail.com>
>> wrote:
>>> Does this not hook into the security discussions on internet-visible
>>> services?
>>>
>>> You can satisfy your use case with authorisation levels and just not
>>> give
>>> "everyone" the authority to register services. To my mind, this seems
>>> cleaner (although not necessarily better or easier), than having two
>>> breeds
>>> of ServiceRegistrar.
>>
>> Just a thought--it seems to me you would want to block this on the
>> client side, to prevent DDOS attacks on the LUS if the LUS is visible
>> "globally". Block all attempts to register with a locally-generated
>> and thrown exception (via smart proxy returned by LUS on lookup).
>>
>>
>> Patrick
>>
>
>
Re: ServiceRegistrar
Posted by Gregg Wonderly <gr...@wonderly.org>.
I agree, doing both would be the best choice of implementation.
Gregg Wonderly
Christopher Dolan wrote:
> Best would be to block on both client and server side. Client to help performance and server to prevent malicious intent. Server side would be the minimum implementation.
>
> Chris
>
> -----Original Message-----
> From: Patrick Wright [mailto:pdoubleya@gmail.com]
> Sent: Monday, June 28, 2010 3:17 AM
> To: river-dev@incubator.apache.org
> Subject: Re: ServiceRegistrar
>
> On Mon, Jun 28, 2010 at 10:11 AM, Tom Hobbs <tv...@googlemail.com> wrote:
>> Does this not hook into the security discussions on internet-visible
>> services?
>>
>> You can satisfy your use case with authorisation levels and just not give
>> "everyone" the authority to register services. To my mind, this seems
>> cleaner (although not necessarily better or easier), than having two breeds
>> of ServiceRegistrar.
>
> Just a thought--it seems to me you would want to block this on the
> client side, to prevent DDOS attacks on the LUS if the LUS is visible
> "globally". Block all attempts to register with a locally-generated
> and thrown exception (via smart proxy returned by LUS on lookup).
>
>
> Patrick
>
RE: ServiceRegistrar
Posted by Christopher Dolan <ch...@avid.com>.
Best would be to block on both client and server side. Client to help performance and server to prevent malicious intent. Server side would be the minimum implementation.
Chris
-----Original Message-----
From: Patrick Wright [mailto:pdoubleya@gmail.com]
Sent: Monday, June 28, 2010 3:17 AM
To: river-dev@incubator.apache.org
Subject: Re: ServiceRegistrar
On Mon, Jun 28, 2010 at 10:11 AM, Tom Hobbs <tv...@googlemail.com> wrote:
> Does this not hook into the security discussions on internet-visible
> services?
>
> You can satisfy your use case with authorisation levels and just not give
> "everyone" the authority to register services. Â To my mind, this seems
> cleaner (although not necessarily better or easier), than having two breeds
> of ServiceRegistrar.
Just a thought--it seems to me you would want to block this on the
client side, to prevent DDOS attacks on the LUS if the LUS is visible
"globally". Block all attempts to register with a locally-generated
and thrown exception (via smart proxy returned by LUS on lookup).
Patrick
Re: ServiceRegistrar
Posted by Patrick Wright <pd...@gmail.com>.
On Mon, Jun 28, 2010 at 10:11 AM, Tom Hobbs <tv...@googlemail.com> wrote:
> Does this not hook into the security discussions on internet-visible
> services?
>
> You can satisfy your use case with authorisation levels and just not give
> "everyone" the authority to register services. Â To my mind, this seems
> cleaner (although not necessarily better or easier), than having two breeds
> of ServiceRegistrar.
Just a thought--it seems to me you would want to block this on the
client side, to prevent DDOS attacks on the LUS if the LUS is visible
"globally". Block all attempts to register with a locally-generated
and thrown exception (via smart proxy returned by LUS on lookup).
Patrick
Re: ServiceRegistrar
Posted by Tom Hobbs <tv...@googlemail.com>.
Does this not hook into the security discussions on internet-visible
services?
You can satisfy your use case with authorisation levels and just not give
"everyone" the authority to register services. To my mind, this seems
cleaner (although not necessarily better or easier), than having two breeds
of ServiceRegistrar.
Just a thought.
Tom
On Sun, Jun 27, 2010 at 1:29 AM, Peter Firmstone <ji...@zeus.net.au> wrote:
> For a ServiceRegistrar implementation where you don't want to register
> Services (A static ServiceRegistrar used only for lookup) would returning a
> null ServiceRegistration suffice? Or is this fraught with danger, has
> anyone ever tried it?
>
> Use case: You've got an internet facing Registrar and you don't want
> external Services to register.
>
> Cheers,
>
> Peter.
>
>
>
>
ServiceRegistrar
Posted by Peter Firmstone <ji...@zeus.net.au>.
For a ServiceRegistrar implementation where you don't want to register
Services (A static ServiceRegistrar used only for lookup) would
returning a null ServiceRegistration suffice? Or is this fraught with
danger, has anyone ever tried it?
Use case: You've got an internet facing Registrar and you don't want
external Services to register.
Cheers,
Peter.
Re: Service API, class visibility, isolation and garbage collection
- ClassLoaders
Posted by Peter Firmstone <ji...@zeus.net.au>.
Peter Firmstone wrote:
> We can base Codebase trust on:
>
> 1. Certificates[] "Who wrote it?"
> 2. CodeSource "Who wrote it and the name of the Codebase?"
Just a minor clarification, a CodeSource object's state, is the URL and
the signer Certificates[], so it's currently "Who signed it, where it
comes from and its name", I'd like to change that to "Who signed it,
what's its name and version" Lets hope the original developer signs it
or the people who do sign it can "vet the code" so we can equate
developers with Certificates[]. I'd like to take location out of the
equation for systems like Maven and OSGi.
Cheers,
Peter.
Re: Service API, class visibility, isolation and garbage collection
- ClassLoaders
Posted by Peter Firmstone <ji...@zeus.net.au>.
Thanks Gregg, much appreciated.
Gregg Wonderly wrote:
> Getting back around to some of these, hopefully no confusion...
Yea, can be difficult to express things using only text communication,
especially with something so complex. Replies inline below.
>
> Peter Firmstone wrote:
>> Hi Gregg,
>>
>> Sorry I missed this earlier, have a look at my latest messages, they
>> might provide some more background to my thoughts.
>>
>> Mike Warres has a good example of when the existing mechanism causes
>> codebase annotation loss and type conflicts on page 23 of his paper
>> "Class Loading Issues in Java RMI and Jini Network Technology".
>>
>> https://issues.apache.org/jira/secure/attachment/12413650/Java+Classloader+issues+relating+to+Jini+smli_tr-2006-149.pdf
>>
>> Because the Service API is loaded from the local file system and
>> isn't dynamically downloaded, it may not have an annotation, I'm
>> thinking about creating a new URL scheme, that provides information
>> about all Jar files, whether local or downloaded dynamically, such as
>> jar name and version annotation. This should help people who wish to
>> provision their codebases.
>
> For me, the important thing to understand about class
> resolution/loading, is that there are two distinct issues. First, do
> you have the correct version of the class somewhere in the class
> loading system in use, and Second, if the right version or no version
> is available, do you have a way to go look for a definition that would
> be the right version to use?
>
> ClassLoaders have historically been the domain of issue #1. Issue #2
> has been dealt with in a surprisingly large number of ways.
> Serialization annotations that MarshalledObject et.al. provide one way
> to deal with #2. But we also have later development of things like
> OSGi, Maven and other packaging systems which include ways to declare
> or facilitate resolution of missing dependencies.
>
> RMIClassLoaderSPI is the pluggable way to deal with the String
> annotations on classes. It can facilitate a wide number of
> possibilities. The predominate issues is that it doesn't include an
> "implementation" indication in concert with the String value, so you
> don't know how to "delegate" to other mechanisms to make use of that
> String value in a "varied" way.
>
> It seems to me that if we do something with a new RMIClassLoaderSPI
> implementation. My changes add no real value other than facilitating
> the addition of another implementation that is offered remotely or
> through some other path. What we really need is the ability to look
> at the annotation and use it intelligently to ask a factory mechanism
> to use it to create a class loader.
>
>> Note I haven't had any thoughts about removing
>> PreferredClassProvider, but I'm thinking about another ClassLoader
>> structure, although I'm prone to changing my mind as I struggle to
>> understand it all. I haven't got any implementations, yet, still
>> working it all out.
>
> PreferredClassLoading allows you to fix code that is generally used
> across an application "suite", by overriding the use of something in
> the classpath with something you provide in your -dl.jar (or other
> codebase content) by making it preferred.
Ok, this is something I'm trying to fix using a different approach with
Classloaders. If the Application code is not visible to the proxy, the
proxy can have it's own independent classes, with no class sharing
between the proxy and application other than platform and API classes.
I'd like a way to define classes for loading into an application or
service classloader too, similar to a classpath. Smart Proxy's can
utilise their own libraries without conflicting with the application's
library versions.
This is sort of what I'm thinking, evolved since last post, based on
comments:
CLASS LOADER VISIBILITY
_______________________________________________________________________
| |
| Platform & API ClassLoader (incl Dumb Proxy Objects) |
|----------------|------------------------------------------------------|
| _________|________________________________ |
| | | | | |
| ServiceUI | Smart Proxy Extended Service API |
| ClassLoader | (incl ServiceUI) & Dumb Proxy ClassLoader |
| (UI that uses | ClassLoader's | |
| Dumb Proxy's) | ___________________|___________ |
| |_________ | | | |
| | | | ServiceUI Smart Proxy |
| | Parameter Imp ClassLoader's ClassLoader's |
| | ClassLoader's (for Dumb Proxy's) |
| | (Server side) |
|----------------|------------------------------------------------------|
| | |
| Common Classloader (As Per Dennis' comments) |
| _________|________________________ |
| | | |
| Service Imp Application |
| ClassLoader's ClassLoader |
| (incl Parameter Imp classes) |
|_______________________________________________________________________|
Everything between the two --- lines is downloaded dynamically, cached
or provisioned.
Dumb Proxy's have no download archives or classes other than those in
the API,
so can be safely loaded into the Platform API ClassLoader or Extended
Service API
ClassLoader. These classloaders will be available via a weak reference
index.
All classes in child ClassLoaders can see all parent ClassLoaders above
in the tree, but classes in parent ClassLoaders cannot see the classes
below them in child ClassLoaders. For example, classes in the Platform
& API CL, Common CL are visible to the Application CL classes.
This visibility, between ClassLoader's mapped out above, prevents
implementations from interfering with each other, they can only
cooperate between each other using common API classes. No more worries
about versioning conflicts etc. Versions can be specified by
implementations to allow codebase caching and provisioning to ensure
that Serialization and implementation compatibility remains between the
Server and it's Proxy.
This may cause some libraries to become duplicated in memory, however we
must ensure a particular version is only downloaded once.
Something that has my attention about security is, currently we've based
proxy security on the ClassLoader. However when the AccessController
checks permission, it allows only the permissions common to all
ProtectionDomains on the Stack (see AccessControlContext). Permissions
really should be dynamically granted to ProtectionDomains, not the
ClassLoader.
A ProtectionDomain, might represent a Principal, or it might represent a
downloaded codebase, any number of which may exist in a single
ClassLoader (so long as classes are not duplicated, this should be
avoided since duplicate classes cannot be loaded into a ClassLoader).
Hence if a number of Services use the same codebases for their smart
proxy's then that codebases ProtectionDomain will need the required
Permissions and so will the ProtectionDomain for a Principal in order
for those Permissions to become effective. So we can preserve security
and have multiple Services share the same proxy code. But to do so we
must forget about ClassLoader based Permission grants.
We can base Codebase trust on:
1. Certificates[] "Who wrote it?"
2. CodeSource "Who wrote it and the name of the Codebase?"
We can base Principal trust on:
1. Principals[] "Who are you?"
When a ProtectionDomain is created with the constructor:
public ProtectionDomain(CodeSource codesource,
PermissionCollection permissions,
ClassLoader classloader,
Principal[] principals)
The permissions granted to the ProtectionDomain will be dynamic and the
current Policy will always be asked prior to the PermissionCollection
passed into the constructor (Performance Hint: make sure permissions is
null, use the Policy only)
The Principal[] can be java.security.acl.Group[] objects (Group extends
Principal), then your free to add and remove Principals to that Group
and hence the Group's ProtectionDomain, that associated with the
CodeSource of the Proxy. A group might represent each type of Service.
ProtectionDomains representing each will be on the stack and only the
Permissions common to all ProtectionDomains on the stack will be granted.
Some observations:
1. Codebases should advertise their required Permissions if trust is
required.
2. Codebases should be signed if trust is required.
3. Utility Library Codebases can be released and signed for others to
"trust" to be utilised in proxy's. You might not trust unknown
proxy code, but you might trust the utility library that provides
trusted functionality for it.
So client Proxy trust is currently:
1. Download the Proxy codebase.
2. Unmarshall the Proxy.
3. Ask the Proxy for the Proxy verifier.
4. Ask the Server if it trusts the proxy.
5. Grant trust to the proxy ClassLoader.
We can optionally do this too instead (feel free to correct any poorly
conceived assumptions):
1. Download the Proxy codebase (unless cached or downloaded prior)
2. Record the Permissions required by the CodeSource advertised in
the jar file.
3. If Permissions are required, Create a Group and Create a
ProtectionDomain for that CodeSource, passing the new Group
(Principal) to the constructor (on first use of the codebase). A
Group might be specific a particular Service Interface and may
already exist.
4. Unmarshall the Proxy
5. Check Constraints.
6. Authenticate the Service if required.
7. Authenticate the Client if required.
8. Ask the Proxy for the Proxy Verifier.
9. Does the Server trust the Proxy?
10. Add the Service's Principal (or it's Group) to the Group, in the
ProtectionDomain.
11. Grant trust
1. Using grantCodeSource(CodeSource cs, Principal[] groups,
Permission[] permissions)
2. OR grantProtectionDomain(Class cl, Permission[] permissions)
3. OR grant(Class cl, Principal[] principals, Permission[]
permissions) - ClassLoader grant.
4. OR grant(Certificate[] certs, Principal[] principals,
Permission[] permissions)
Notes:
* The permissions granted are limited to those declared in the jar file.
* If the Trust grant is performed using 11.3. then permission grants
are the same as the current ClassLoader based behaviour, all other
libraries in with the proxy will be loaded into that ClassLoader
and also receive those permissions.
* Permissions granted using 11.4 are granted based on the codebase
signers (developers) and Principals (groups) and may be granted at
any time prior.
* Permissions granted using 11.2 are granted directly to the proxy
ProtectionDomain and only apply to the proxy's Code source, not
bundled libraries or other jar archives distributed with the proxy.
* Permissions granted using 11.1 are granted directly to the
CodeSource and Principals (groups) and may be applied prior to
downloading the code source.
* Other proxy objects from different services, with identical proxy
CodeSource may share the ProtectionDomain and class files, in this
case the trust sequence is limited to steps 4 to 10 as the
CodeSource itself is already trusted, the only thing that remains
is to verify the proxy and perform authentication if required.
These Dynamic Grants have been implemented in
DynamicConcurrentPolicyProvider. Permissions granted to Groups differ
from current Policy implementations that test Principals for equality
only, this new Policy implementation also implies true when Principals
are members of Groups that have been granted Permissions.
It might help to provide a Principal and Group framework implementation
to make Authentication easier.
So this does actually point to a use for Patrick's suggested Codebase
Entry? Yes, for example if many services existed on the internet that
utilise the same codebase versions, then a client could specify only a
particular version, to ensure it only downloads one codebase, once for
all matching instances of a Service. It might first get the Codebase
Entry's for a particular Service type, then lookup by each codebase
version and deal with them in compatible batches. Waiting for the
Codebase URL annotation would be too late, filtering would be performed
at the client rather than by the ServiceRegistrar.
We do need to implement something like RMIClassLoaderSPI, where
ClassLoaders are created based on the names of jar archives *proxy.jar,
*ext-api.jar, *ui.jar and *param.jar. Where versioning is taken into
consideration and a new URL format is created that allows for the needed
flexibility. Then of course class resolution needs to be figured out
with the new URL annotation.
This may take some time to digest. Please see the code in:
https://svn.apache.org/repos/asf/incubator/river/jtsk/trunk/src/org/apache/river/
Cheers,
Peter.
> I find this mechanism extremely useful in my service UI client that
> has the same classes as all my UIs use for Swing and AWT stuff. If I
> need additional functionality or to fix something that only the UI of
> a service needs, then I can make that class preferred and not have to
> update all of my service UI client instances. Mobile code solutions
> are very convenient.
>
> Gregg Wonderly
>
>> Gregg Wonderly wrote:
>>> I have a Jini based application that is a content based router
>>> system for satellite networks. There are multiple servers running
>>> with comms cards, and the ServiceUI needs to see all of them at
>>> once, because I use transactions to commit data changes to all
>>> servers. In this case, one clients ServiceUI must lookup all of the
>>> services, ignoring itself, and then get the service proxies to work
>>> with. All of the services proxies need to share interfaces and data
>>> classes that are commonly exchanged.
>>>
>>> I didn't need a different kind of classloader tree, I just needed to
>>> make sure that the parent class loader of the RMIClassLoaderSPI was
>>> the ClassLoader of the client (The context ClassLoader which is a
>>> PreferredClassLoader), which was already happening. All the other
>>> service instance unmarshalling would in fact make use of the
>>> PreferredClassLoader, so that versioning could be done by preferring
>>> classes, for example, and each services preferred classes would be
>>> honored.
>>>
>>> There is only one -dl.jar involved in the commonality aspects of the
>>> involved Classes. I could break the common classes into a separate
>>> jar, but I have not done that, yet.
>>>
>>> This type of application must be restarted fairly rarely, so class
>>> compatibility is a very key issue.
>>>
>>> Peter, can you provide a more specific example of when you think the
>>> structure you are proposing would be valuable, i.e. the existing
>>> mechanism would break?
>>>
>>> Gregg Wonderly
>>>
>>
>>
>
>
Re: Service API, class visibility, isolation and garbage collection
- ClassLoaders
Posted by Gregg Wonderly <ge...@cox.net>.
Getting back around to some of these, hopefully no confusion...
Peter Firmstone wrote:
> Hi Gregg,
>
> Sorry I missed this earlier, have a look at my latest messages, they
> might provide some more background to my thoughts.
>
> Mike Warres has a good example of when the existing mechanism causes
> codebase annotation loss and type conflicts on page 23 of his paper
> "Class Loading Issues in Java RMI and Jini Network Technology".
>
> https://issues.apache.org/jira/secure/attachment/12413650/Java+Classloader+issues+relating+to+Jini+smli_tr-2006-149.pdf
>
> Because the Service API is loaded from the local file system and isn't
> dynamically downloaded, it may not have an annotation, I'm thinking
> about creating a new URL scheme, that provides information about all Jar
> files, whether local or downloaded dynamically, such as jar name and
> version annotation. This should help people who wish to provision their
> codebases.
For me, the important thing to understand about class resolution/loading, is
that there are two distinct issues. First, do you have the correct version of
the class somewhere in the class loading system in use, and Second, if the right
version or no version is available, do you have a way to go look for a
definition that would be the right version to use?
ClassLoaders have historically been the domain of issue #1. Issue #2 has been
dealt with in a surprisingly large number of ways. Serialization annotations
that MarshalledObject et.al. provide one way to deal with #2. But we also have
later development of things like OSGi, Maven and other packaging systems which
include ways to declare or facilitate resolution of missing dependencies.
RMIClassLoaderSPI is the pluggable way to deal with the String annotations on
classes. It can facilitate a wide number of possibilities. The predominate
issues is that it doesn't include an "implementation" indication in concert with
the String value, so you don't know how to "delegate" to other mechanisms to
make use of that String value in a "varied" way.
It seems to me that if we do something with a new RMIClassLoaderSPI
implementation. My changes add no real value other than facilitating the
addition of another implementation that is offered remotely or through some
other path. What we really need is the ability to look at the annotation and
use it intelligently to ask a factory mechanism to use it to create a class loader.
> Note I haven't had any thoughts about removing PreferredClassProvider,
> but I'm thinking about another ClassLoader structure, although I'm prone
> to changing my mind as I struggle to understand it all. I haven't got
> any implementations, yet, still working it all out.
PreferredClassLoading allows you to fix code that is generally used across an
application "suite", by overriding the use of something in the classpath with
something you provide in your -dl.jar (or other codebase content) by making it
preferred. I find this mechanism extremely useful in my service UI client that
has the same classes as all my UIs use for Swing and AWT stuff. If I need
additional functionality or to fix something that only the UI of a service
needs, then I can make that class preferred and not have to update all of my
service UI client instances. Mobile code solutions are very convenient.
Gregg Wonderly
> Gregg Wonderly wrote:
>> I have a Jini based application that is a content based router system
>> for satellite networks. There are multiple servers running with comms
>> cards, and the ServiceUI needs to see all of them at once, because I
>> use transactions to commit data changes to all servers. In this case,
>> one clients ServiceUI must lookup all of the services, ignoring
>> itself, and then get the service proxies to work with. All of the
>> services proxies need to share interfaces and data classes that are
>> commonly exchanged.
>>
>> I didn't need a different kind of classloader tree, I just needed to
>> make sure that the parent class loader of the RMIClassLoaderSPI was
>> the ClassLoader of the client (The context ClassLoader which is a
>> PreferredClassLoader), which was already happening. All the other
>> service instance unmarshalling would in fact make use of the
>> PreferredClassLoader, so that versioning could be done by preferring
>> classes, for example, and each services preferred classes would be
>> honored.
>>
>> There is only one -dl.jar involved in the commonality aspects of the
>> involved Classes. I could break the common classes into a separate
>> jar, but I have not done that, yet.
>>
>> This type of application must be restarted fairly rarely, so class
>> compatibility is a very key issue.
>>
>> Peter, can you provide a more specific example of when you think the
>> structure you are proposing would be valuable, i.e. the existing
>> mechanism would break?
>>
>> Gregg Wonderly
>>
>
>
Re: Service API, class visibility, isolation and garbage collection
- ClassLoaders
Posted by Peter Firmstone <ji...@zeus.net.au>.
Hi Gregg,
Sorry I missed this earlier, have a look at my latest messages, they
might provide some more background to my thoughts.
Mike Warres has a good example of when the existing mechanism causes
codebase annotation loss and type conflicts on page 23 of his paper
"Class Loading Issues in Java RMI and Jini Network Technology".
https://issues.apache.org/jira/secure/attachment/12413650/Java+Classloader+issues+relating+to+Jini+smli_tr-2006-149.pdf
Because the Service API is loaded from the local file system and isn't
dynamically downloaded, it may not have an annotation, I'm thinking
about creating a new URL scheme, that provides information about all Jar
files, whether local or downloaded dynamically, such as jar name and
version annotation. This should help people who wish to provision their
codebases.
Note I haven't had any thoughts about removing PreferredClassProvider,
but I'm thinking about another ClassLoader structure, although I'm prone
to changing my mind as I struggle to understand it all. I haven't got
any implementations, yet, still working it all out.
Gregg Wonderly wrote:
> I have a Jini based application that is a content based router system
> for satellite networks. There are multiple servers running with comms
> cards, and the ServiceUI needs to see all of them at once, because I
> use transactions to commit data changes to all servers. In this case,
> one clients ServiceUI must lookup all of the services, ignoring
> itself, and then get the service proxies to work with. All of the
> services proxies need to share interfaces and data classes that are
> commonly exchanged.
>
> I didn't need a different kind of classloader tree, I just needed to
> make sure that the parent class loader of the RMIClassLoaderSPI was
> the ClassLoader of the client (The context ClassLoader which is a
> PreferredClassLoader), which was already happening. All the other
> service instance unmarshalling would in fact make use of the
> PreferredClassLoader, so that versioning could be done by preferring
> classes, for example, and each services preferred classes would be
> honored.
>
> There is only one -dl.jar involved in the commonality aspects of the
> involved Classes. I could break the common classes into a separate
> jar, but I have not done that, yet.
>
> This type of application must be restarted fairly rarely, so class
> compatibility is a very key issue.
>
> Peter, can you provide a more specific example of when you think the
> structure you are proposing would be valuable, i.e. the existing
> mechanism would break?
>
> Gregg Wonderly
>
Re: Service API, class visibility, isolation and garbage collection
- ClassLoaders
Posted by Gregg Wonderly <gr...@wonderly.org>.
I have a Jini based application that is a content based router system for
satellite networks. There are multiple servers running with comms cards, and
the ServiceUI needs to see all of them at once, because I use transactions to
commit data changes to all servers. In this case, one clients ServiceUI must
lookup all of the services, ignoring itself, and then get the service proxies to
work with. All of the services proxies need to share interfaces and data
classes that are commonly exchanged.
I didn't need a different kind of classloader tree, I just needed to make sure
that the parent class loader of the RMIClassLoaderSPI was the ClassLoader of the
client (The context ClassLoader which is a PreferredClassLoader), which was
already happening. All the other service instance unmarshalling would in fact
make use of the PreferredClassLoader, so that versioning could be done by
preferring classes, for example, and each services preferred classes would be
honored.
There is only one -dl.jar involved in the commonality aspects of the involved
Classes. I could break the common classes into a separate jar, but I have not
done that, yet.
This type of application must be restarted fairly rarely, so class compatibility
is a very key issue.
Peter, can you provide a more specific example of when you think the structure
you are proposing would be valuable, i.e. the existing mechanism would break?
Gregg Wonderly
Dennis Reedy wrote:
> Peter,
>
> No worries. Although I think there is still a misunderstanding on how the class loader structure works, its water under the bridge - lets move on.
>
> What I cant figure out is if you want to share classes across downloaded proxies, why the classes are not part of the API jar the client has in it's classpath. This allows downloaded proxies access to these classes, since the classloader they are loaded with delegates to the classloader that the API jar has been loaded with.
>
> It seems you are creating an edge condition where an implementor would like downloaded proxies to share a class across implementations, but in order to do that that class needs to be injected into a parent class loader. Do I have this right?
>
> IMO, in this scenario, I would advise that the class(es) in question should be added to the API jar.
>
> AppCL
>
>
> On May 26, 2010, at 727AM, Peter Firmstone wrote:
>
>> Hi Dennis,
>>
>> Looking back at my earlier reply when you presented the ClassLoader structure for Rio, I was unintentionally insensitive.
>>
>> I didn't mean to pull it apart, probably not the right approach, Rio is a success in it's own right!
>>
>> What I should have said and I may not have communicated too well is that I'm introducing a way for Service Proxy's to utilise ClassLoader visibility for maximum API class sharing. It is a new feature, to give Service implementers the power to share their Service API's, with as much local JVM visibility as the Jini Platform Service API's have.
>>
>> As I pointed out there is a compromise, that Service API classes cannot be garbage collected. I think that if this can be well managed, using a Permission, then it should not affect uptime for critical applications.
>>
>> With great power comes great responsibility... yada yada yada.
>>
>> Cheers,
>>
>> Peter.
>>
>> Peter Firmstone wrote:
>>> Peter Firmstone wrote:
>>>> IDENTICAL TO ANOTHER MESSAGE IN THREAD: Re: Maven repository Entry was Re: Codebase service?
>>>>
>>>> Note: A permission will be required to allow a proxy to introduce new Service API during unmarshalling to prevent against denial of service attacks.
>>> However in the absence of this permission, the additional ServiceAPI jar could be downloaded into the proxy's own ClassLoader, that would require a ClassLoader even for a dumb proxy with an interface you didn't want to load into your Service API space. This would enable unmarshalling of that Proxy. If you, at a later point decided to load that interface into your Service API space, I think you still wouldn't be able to interact with this particular proxy using it, since the interface class identity would be different.
>>>
>>> Denial of service here means unfairly growing a JVM's use of non garbage collectable classes. Any ideas how to control download proxy memory consumption.
>>>> Hi Dennis,
>>>>
>>>> It sounds like you remain unconvinced or don't have a need to use common
>>>> interfaces for your service proxy's?
>>>>
>>>> So I guess it's a tread lightly approach, make the feature available to
>>>> those that want common Service API (The same interface instance for all
>>>> proxy's implementing that interface, so they can be used in collections
>>>> or batch operations), for maximum sharing of proxy's with differing
>>>> implementations, but let those that don't want to publish their API
>>>> continue doing what they usually do. A configuration parameter should
>>>> be able to set the desired behaviour.
>>>>
>>>> The approach I've taken is a simple approach to a complex problem,
>>>> alternative approaches leave the complexity in the hands of the
>>>> implementer, my approach will enable them to practically ignore it.
>>>>
>>>> Before you write it off though, to answer your earlier question, I'll
>>>> further explain the ClassLoader structure between multiple nodes.
>>>>
>>>> CLIENT NODE
>>>> ________________________________________________
>>>> | |
>>>> | System |
>>>> | ClassLoader |
>>>> | | |
>>>> | Extension |
>>>> | ClassLoader |
>>>> | | |
>>>> | Jini Platform & |
>>>> | Service API |
>>>> | ClassLoader |
>>>> | | |
>>>> | _________|___ |
>>>> | | | |
>>>> | Application Smart Proxy |
>>>> | ClassLoader ClassLoader's |
>>>> |________________________________________________|
>>>>
>>>>
>>>> SERVICE NODE
>>>> ________________________________________________
>>>> | |
>>>> | System |
>>>> | ClassLoader |
>>>> | | |
>>>> | Extension |
>>>> | ClassLoader |
>>>> | | |
>>>> | Jini Platform & |
>>>> | Service API |
>>>> | ClassLoader |
>>>> | | |
>>>> | _________|_____________________ |
>>>> | | | | |
>>>> | Service Imp Smart Proxy Parameter Impl |
>>>> | ClassLoader ClassLoader's ClassLoader's |
>>>> |________________________________________________|
>>>>
>>>>
>>>> All Proxy and Service implementations are free to vary at will, proxy
>>>> instances can be shared in collections or iterative operations based on
>>>> common Service API supertype's All Proxy's and Services are isolated in
>>>> their own Domain, the only way to communicate externally is by using
>>>> interfaces and classes in upper level ClassLoaders, they can utilise as
>>>> many third party libraries jar archives as they need, these will all be
>>>> loaded into a single ClassLoader unique to that Service or Proxy's
>>>> Codebase and Principles. The Service or Proxy's namespace will be
>>>> totally separate from Application or other Proxy implementation's,
>>>> except in the case where sharing is permitted for identical
>>>> implementations by the implementation developer.
>>>>
>>>> Service API should be carefully considered and designed, it forms the
>>>> basis of network Dependency Injection, you can discover ANY Service
>>>> implementation variant using the same Service API.
>>>>
>>>> The Service API may include other Service API or Java platform classes.
>>>>
>>>> public interface SimpleBookService {
>>>>
>>>> public Book get( Library lib, String name);
>>>>
>>>> }
>>>>
>>>> In the SimpleBookService above, given a Library and String name of a
>>>> Book, a Book instance is returned by the proxy.
>>>>
>>>> The contents of simpleBookService-api.jar:
>>>>
>>>> SimpleBookService.class
>>>> Book.class
>>>> Library.class
>>>>
>>>> Let's say a client has extended the Library, with a class called
>>>> PrivateLibrary, this class is an implementation class by the client,
>>>> that the Service knows nothing about, the Service only uses the Library
>>>> API, but it needs the PrivateLibrary.class
>>>>
>>>> The client makes an archive containing the PrivateLibrary.class publicly
>>>> available in an archive called privateLibrary-param.jar. This archive
>>>> depends on simpleBookService-api.jar The jar URL is marshalled with the
>>>> class when the parameters are sent back to the service. When it gets to
>>>> the service implementation, privateLibrary-param.jar is given it's own
>>>> ClassLoader and ProtectionDomain and isn't given any Permissions. It is
>>>> used by a SimpleBookService implementation to decide which Book to
>>>> return to the client, after which, it's garbage collected, eventually if
>>>> PrivateLibrary isn't used again its ClassLoader is garbage collected too.
>>>>
>>>> Each SimpleBookService proxy implementation will have their own
>>>> ClassLoader namespace, but Client Application classes can still use any
>>>> Service implementation or as many Service implementations as it can
>>>> handle at the same time, all the while treating them as the same Type.
>>>>
>>>> One SimpleBookService implementation proxy, contains its own
>>>> implementation of Book, and while the client is reading the book, it
>>>> remains available from the proxy ClassLoader via the Service API Book
>>>> interface, when finished reading the book, the proxy, book and
>>>> ClassLoader can be garbage collected. Tomorrow, the client might read a
>>>> book from another SimpleBookService
>>>>
>>>> Most Service API will be relatively small bytecodes as most will be
>>>> abstract or have simple implementations, the fact they're not garbage
>>>> collected, doesn't matter much if the function of the node doesn't
>>>> change, the API will remain limited to the subset in use, by the node.
>>>>
>>>> Note that Jini Platform service implementations like Reggie, Outrigger
>>>> etc, will exist in Service Impl ClassLoaders and Smart Proxy
>>>> ClassLoaders, only the api will be in the Jini Platform ClassLoader.
>>>>
>>>> Think of it as an expandable platform, everything is shared using
>>>> implementations of Service API classes.
>>>>
>>>> It's actually a good policy to be liberal with interfaces when building
>>>> the Service API classes, even with parameters and return types. Since
>>>> extending interfaces is relatively straight forward, you new interfaces
>>>> will be discovered by older client software as the old interface while
>>>> new implementation code discovers the new interface of your service.
>>>> Older nodes will load your new interface classes into the Service API
>>>> space when your new proxy versions are unmarshalled. That's why it's
>>>> important to maintain backward compatibility in the Service API space.
>>>>
>>>> So best practise would be to create an experimental djinn group until
>>>> your interfaces are stabilised and be prepared to restart your
>>>> experimental group on a regular basis.
>>>>
>>>> I have thought about using OSGi for Service API classes to be served up
>>>> so they can be garbage collected, this might work for serialization too
>>>> using the context ClassLoader. I have also thought about using
>>>> ClassLoader Tree's using bytecode dependency analysis as per Tim
>>>> Blackman's research. These things start to get very complicated, just
>>>> to be able to flush the Service API classes. Wouldn't it just be better
>>>> to use mutiple services that are load balanced, enabling the jvm to be
>>>> restarted if we want to?
>>>>
>>>> There are other ways to make the Service API classes garbage
>>>> collectable, such as having a tier filled with Service API ClassLoaders
>>>> where each Service and Proxy lives in a child ClassLoader in the tree,
>>>> however this presents the problem of what if an application wants to use
>>>> many Service API's or a combination, the different Service API classes
>>>> couldn't see each other from separate ClassLoaders.
>>>>
>>>> Something to consider, best regards,
>>>>
>>>> Peter.
>>>>
>>>> Dennis Reedy wrote:
>>>>> On May 25, 2010, at 710PM, Peter Firmstone wrote:
>>>>>
>>>>>
>>>>>> 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.
>>>>>>
>>>>> Right now the JVM doesnt need to be shut down at all, services can be loaded with different versions, unloaded, etc ... I think you're making assumptions here.
>>>>>
>>>>>> 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.
>>>>>>
>>>>> Right, which is why service implementations get loaded into their own class loader. You define the 'platform' as whatever that needs to be for your case. For Rio it includes requisite bootstrapping and infrastructure technology. For River it most likely just includes the River 'platform', or nothing at all.
>>>>> Consider ServiceStarter and the class loader created from that bootstrapping process. Please explain what is missing from that approach? Each service has it's own security policy. Why does this need to change? What and how does your approach improve on? To my eyes it seems overly complicated.
>>>>>
>>>>>
>>>>>> 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?
>>>>>>
>>>>> Common API? The service proxies dont share anything. They are each loaded from an implementation of RMIClassLoaderApi
>>>>>
>>>>>> This forces you to load both proxy's into the same ClassLoader, making their implementations visible to each other and the client.
>>>>>>
>>>>> Not so sure about that Peter.
>>>>>
>>>>>
>>>>>> By separating the API into, in your case the CommonClassLoader,
>>>>>>
>>>>> APIs are not added to the CommonClassLoader, and I would argue that it should not happen. You generally do not want to add classes into a class loader that does not get GC'd.
>>>>>
>>>>>
>>>>>> 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.
>>>>>
>>>>>
>>>>
>>>>
>>>
>
>
Re: Service API, class visibility, isolation and garbage collection
- ClassLoaders
Posted by Peter Firmstone <ji...@zeus.net.au>.
Dennis Reedy wrote:
> Peter,
>
> No worries. Although I think there is still a misunderstanding on how the class loader structure works,
Ok, I think I see it now, your ClassLoader structure represents your
container. Containers are free to come and go in Rio during the life of
the application?
If I've got that correct, this is very useful.
I wasn't thinking about containers, only a bare metal JVM.
What you have could be very useful to me.
> its water under the bridge - lets move on.
>
> What I cant figure out is if you want to share classes across downloaded proxies, why the classes are not part of the API jar the client has in it's classpath. This allows downloaded proxies access to these classes, since the classloader they are loaded with delegates to the classloader that the API jar has been loaded with.
>
Thinking about dynamic application assembly, not all the API is known at
compile time, it has to be discovered later.
> It seems you are creating an edge condition where an implementor would like downloaded proxies to share a class across implementations, but in order to do that that class needs to be injected into a parent class loader. Do I have this right?
>
Yes.
> IMO, in this scenario, I would advise that the class(es) in question should be added to the API jar.
>
> AppCL
>
Yes agreed, I just want to delay it until after startup, not known at
compile time.
I think what I have as ServiceImpCL and SmartProxyCL and ParamterImpCL
all map quite well to your Service-nCL'
N.B. I'm not a Programmer, so you'll have to bear with me I'm afraid,
while I'm probably out of my depth, I couldn't let River die, I don't
know why programmers can't see Jini's strengths.
In my job we undertake seemingly impossible tasks, Construction & Heavy
(5000T) Machinery Overhauls we always end up figuring it out however.
Thanks Peter.
>
> On May 26, 2010, at 727AM, Peter Firmstone wrote:
>
>
>> Hi Dennis,
>>
>> Looking back at my earlier reply when you presented the ClassLoader structure for Rio, I was unintentionally insensitive.
>>
>> I didn't mean to pull it apart, probably not the right approach, Rio is a success in it's own right!
>>
>> What I should have said and I may not have communicated too well is that I'm introducing a way for Service Proxy's to utilise ClassLoader visibility for maximum API class sharing. It is a new feature, to give Service implementers the power to share their Service API's, with as much local JVM visibility as the Jini Platform Service API's have.
>>
>> As I pointed out there is a compromise, that Service API classes cannot be garbage collected. I think that if this can be well managed, using a Permission, then it should not affect uptime for critical applications.
>>
>> With great power comes great responsibility... yada yada yada.
>>
>> Cheers,
>>
>> Peter.
>>
>> Peter Firmstone wrote:
>>
>>> Peter Firmstone wrote:
>>>
>>>> IDENTICAL TO ANOTHER MESSAGE IN THREAD: Re: Maven repository Entry was Re: Codebase service?
>>>>
>>>> Note: A permission will be required to allow a proxy to introduce new Service API during unmarshalling to prevent against denial of service attacks.
>>>>
>>> However in the absence of this permission, the additional ServiceAPI jar could be downloaded into the proxy's own ClassLoader, that would require a ClassLoader even for a dumb proxy with an interface you didn't want to load into your Service API space. This would enable unmarshalling of that Proxy. If you, at a later point decided to load that interface into your Service API space, I think you still wouldn't be able to interact with this particular proxy using it, since the interface class identity would be different.
>>>
>>> Denial of service here means unfairly growing a JVM's use of non garbage collectable classes. Any ideas how to control download proxy memory consumption.
>>>
>>>> Hi Dennis,
>>>>
>>>> It sounds like you remain unconvinced or don't have a need to use common
>>>> interfaces for your service proxy's?
>>>>
>>>> So I guess it's a tread lightly approach, make the feature available to
>>>> those that want common Service API (The same interface instance for all
>>>> proxy's implementing that interface, so they can be used in collections
>>>> or batch operations), for maximum sharing of proxy's with differing
>>>> implementations, but let those that don't want to publish their API
>>>> continue doing what they usually do. A configuration parameter should
>>>> be able to set the desired behaviour.
>>>>
>>>> The approach I've taken is a simple approach to a complex problem,
>>>> alternative approaches leave the complexity in the hands of the
>>>> implementer, my approach will enable them to practically ignore it.
>>>>
>>>> Before you write it off though, to answer your earlier question, I'll
>>>> further explain the ClassLoader structure between multiple nodes.
>>>>
>>>> CLIENT NODE
>>>> ________________________________________________
>>>> | |
>>>> | System |
>>>> | ClassLoader |
>>>> | | |
>>>> | Extension |
>>>> | ClassLoader |
>>>> | | |
>>>> | Jini Platform & |
>>>> | Service API |
>>>> | ClassLoader |
>>>> | | |
>>>> | _________|___ |
>>>> | | | |
>>>> | Application Smart Proxy |
>>>> | ClassLoader ClassLoader's |
>>>> |________________________________________________|
>>>>
>>>>
>>>> SERVICE NODE
>>>> ________________________________________________
>>>> | |
>>>> | System |
>>>> | ClassLoader |
>>>> | | |
>>>> | Extension |
>>>> | ClassLoader |
>>>> | | |
>>>> | Jini Platform & |
>>>> | Service API |
>>>> | ClassLoader |
>>>> | | |
>>>> | _________|_____________________ |
>>>> | | | | |
>>>> | Service Imp Smart Proxy Parameter Impl |
>>>> | ClassLoader ClassLoader's ClassLoader's |
>>>> |________________________________________________|
>>>>
>>>>
>>>> All Proxy and Service implementations are free to vary at will, proxy
>>>> instances can be shared in collections or iterative operations based on
>>>> common Service API supertype's All Proxy's and Services are isolated in
>>>> their own Domain, the only way to communicate externally is by using
>>>> interfaces and classes in upper level ClassLoaders, they can utilise as
>>>> many third party libraries jar archives as they need, these will all be
>>>> loaded into a single ClassLoader unique to that Service or Proxy's
>>>> Codebase and Principles. The Service or Proxy's namespace will be
>>>> totally separate from Application or other Proxy implementation's,
>>>> except in the case where sharing is permitted for identical
>>>> implementations by the implementation developer.
>>>>
>>>> Service API should be carefully considered and designed, it forms the
>>>> basis of network Dependency Injection, you can discover ANY Service
>>>> implementation variant using the same Service API.
>>>>
>>>> The Service API may include other Service API or Java platform classes.
>>>>
>>>> public interface SimpleBookService {
>>>>
>>>> public Book get( Library lib, String name);
>>>>
>>>> }
>>>>
>>>> In the SimpleBookService above, given a Library and String name of a
>>>> Book, a Book instance is returned by the proxy.
>>>>
>>>> The contents of simpleBookService-api.jar:
>>>>
>>>> SimpleBookService.class
>>>> Book.class
>>>> Library.class
>>>>
>>>> Let's say a client has extended the Library, with a class called
>>>> PrivateLibrary, this class is an implementation class by the client,
>>>> that the Service knows nothing about, the Service only uses the Library
>>>> API, but it needs the PrivateLibrary.class
>>>>
>>>> The client makes an archive containing the PrivateLibrary.class publicly
>>>> available in an archive called privateLibrary-param.jar. This archive
>>>> depends on simpleBookService-api.jar The jar URL is marshalled with the
>>>> class when the parameters are sent back to the service. When it gets to
>>>> the service implementation, privateLibrary-param.jar is given it's own
>>>> ClassLoader and ProtectionDomain and isn't given any Permissions. It is
>>>> used by a SimpleBookService implementation to decide which Book to
>>>> return to the client, after which, it's garbage collected, eventually if
>>>> PrivateLibrary isn't used again its ClassLoader is garbage collected too.
>>>>
>>>> Each SimpleBookService proxy implementation will have their own
>>>> ClassLoader namespace, but Client Application classes can still use any
>>>> Service implementation or as many Service implementations as it can
>>>> handle at the same time, all the while treating them as the same Type.
>>>>
>>>> One SimpleBookService implementation proxy, contains its own
>>>> implementation of Book, and while the client is reading the book, it
>>>> remains available from the proxy ClassLoader via the Service API Book
>>>> interface, when finished reading the book, the proxy, book and
>>>> ClassLoader can be garbage collected. Tomorrow, the client might read a
>>>> book from another SimpleBookService
>>>>
>>>> Most Service API will be relatively small bytecodes as most will be
>>>> abstract or have simple implementations, the fact they're not garbage
>>>> collected, doesn't matter much if the function of the node doesn't
>>>> change, the API will remain limited to the subset in use, by the node.
>>>>
>>>> Note that Jini Platform service implementations like Reggie, Outrigger
>>>> etc, will exist in Service Impl ClassLoaders and Smart Proxy
>>>> ClassLoaders, only the api will be in the Jini Platform ClassLoader.
>>>>
>>>> Think of it as an expandable platform, everything is shared using
>>>> implementations of Service API classes.
>>>>
>>>> It's actually a good policy to be liberal with interfaces when building
>>>> the Service API classes, even with parameters and return types. Since
>>>> extending interfaces is relatively straight forward, you new interfaces
>>>> will be discovered by older client software as the old interface while
>>>> new implementation code discovers the new interface of your service.
>>>> Older nodes will load your new interface classes into the Service API
>>>> space when your new proxy versions are unmarshalled. That's why it's
>>>> important to maintain backward compatibility in the Service API space.
>>>>
>>>> So best practise would be to create an experimental djinn group until
>>>> your interfaces are stabilised and be prepared to restart your
>>>> experimental group on a regular basis.
>>>>
>>>> I have thought about using OSGi for Service API classes to be served up
>>>> so they can be garbage collected, this might work for serialization too
>>>> using the context ClassLoader. I have also thought about using
>>>> ClassLoader Tree's using bytecode dependency analysis as per Tim
>>>> Blackman's research. These things start to get very complicated, just
>>>> to be able to flush the Service API classes. Wouldn't it just be better
>>>> to use mutiple services that are load balanced, enabling the jvm to be
>>>> restarted if we want to?
>>>>
>>>> There are other ways to make the Service API classes garbage
>>>> collectable, such as having a tier filled with Service API ClassLoaders
>>>> where each Service and Proxy lives in a child ClassLoader in the tree,
>>>> however this presents the problem of what if an application wants to use
>>>> many Service API's or a combination, the different Service API classes
>>>> couldn't see each other from separate ClassLoaders.
>>>>
>>>> Something to consider, best regards,
>>>>
>>>> Peter.
>>>>
>>>> Dennis Reedy wrote:
>>>>
>>>>> On May 25, 2010, at 710PM, Peter Firmstone wrote:
>>>>>
>>>>>
>>>>>
>>>>>> 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.
>>>>>>
>>>>>>
>>>>> Right now the JVM doesnt need to be shut down at all, services can be loaded with different versions, unloaded, etc ... I think you're making assumptions here.
>>>>>
>>>>>
>>>>>> 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.
>>>>>>
>>>>>>
>>>>> Right, which is why service implementations get loaded into their own class loader. You define the 'platform' as whatever that needs to be for your case. For Rio it includes requisite bootstrapping and infrastructure technology. For River it most likely just includes the River 'platform', or nothing at all.
>>>>> Consider ServiceStarter and the class loader created from that bootstrapping process. Please explain what is missing from that approach? Each service has it's own security policy. Why does this need to change? What and how does your approach improve on? To my eyes it seems overly complicated.
>>>>>
>>>>>
>>>>>
>>>>>> 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?
>>>>>>
>>>>>>
>>>>> Common API? The service proxies dont share anything. They are each loaded from an implementation of RMIClassLoaderApi
>>>>>
>>>>>
>>>>>> This forces you to load both proxy's into the same ClassLoader, making their implementations visible to each other and the client.
>>>>>>
>>>>>>
>>>>> Not so sure about that Peter.
>>>>>
>>>>>
>>>>>
>>>>>> By separating the API into, in your case the CommonClassLoader,
>>>>>>
>>>>>>
>>>>> APIs are not added to the CommonClassLoader, and I would argue that it should not happen. You generally do not want to add classes into a class loader that does not get GC'd.
>>>>>
>>>>>
>>>>>
>>>>>> 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.
>>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>
>
>
Re: Service API, class visibility, isolation and garbage collection
- ClassLoaders
Posted by Peter Firmstone <ji...@zeus.net.au>.
Dennis Reedy wrote:
> Peter,
>
> No worries. Although I think there is still a misunderstanding on how the class loader structure works,
Ok, I think I see it now, your ClassLoader structure represents your
container. Containers are free to come and go in Rio during the life of
the application?
If I've got that correct, this is very useful.
I wasn't thinking about containers, only a bare metal JVM.
What you have could be very useful to me.
> its water under the bridge - lets move on.
>
> What I cant figure out is if you want to share classes across downloaded proxies, why the classes are not part of the API jar the client has in it's classpath. This allows downloaded proxies access to these classes, since the classloader they are loaded with delegates to the classloader that the API jar has been loaded with.
>
Thinking about dynamic application assembly, not all the API is known at
compile time, it has to be discovered later.
> It seems you are creating an edge condition where an implementor would like downloaded proxies to share a class across implementations, but in order to do that that class needs to be injected into a parent class loader. Do I have this right?
>
Yes.
> IMO, in this scenario, I would advise that the class(es) in question should be added to the API jar.
>
> AppCL
>
Yes agreed, I just want to delay it until after startup, not known at
compile time.
I think what I have as ServiceImpCL and SmartProxyCL and ParamterImpCL
all map quite well to your Service-nCL'
N.B. I'm not a Programmer, so you'll have to bear with me I'm afraid,
while I'm probably out of my depth, I couldn't let River die, I don't
know why programmers can't see Jini's strengths.
In my job we undertake seemingly impossible tasks, Construction & Heavy
(5000T) Machinery Overhauls we always end up figuring it out however.
Thanks Peter.
>
> On May 26, 2010, at 727AM, Peter Firmstone wrote:
>
>
>> Hi Dennis,
>>
>> Looking back at my earlier reply when you presented the ClassLoader structure for Rio, I was unintentionally insensitive.
>>
>> I didn't mean to pull it apart, probably not the right approach, Rio is a success in it's own right!
>>
>> What I should have said and I may not have communicated too well is that I'm introducing a way for Service Proxy's to utilise ClassLoader visibility for maximum API class sharing. It is a new feature, to give Service implementers the power to share their Service API's, with as much local JVM visibility as the Jini Platform Service API's have.
>>
>> As I pointed out there is a compromise, that Service API classes cannot be garbage collected. I think that if this can be well managed, using a Permission, then it should not affect uptime for critical applications.
>>
>> With great power comes great responsibility... yada yada yada.
>>
>> Cheers,
>>
>> Peter.
>>
>> Peter Firmstone wrote:
>>
>>> Peter Firmstone wrote:
>>>
>>>> IDENTICAL TO ANOTHER MESSAGE IN THREAD: Re: Maven repository Entry was Re: Codebase service?
>>>>
>>>> Note: A permission will be required to allow a proxy to introduce new Service API during unmarshalling to prevent against denial of service attacks.
>>>>
>>> However in the absence of this permission, the additional ServiceAPI jar could be downloaded into the proxy's own ClassLoader, that would require a ClassLoader even for a dumb proxy with an interface you didn't want to load into your Service API space. This would enable unmarshalling of that Proxy. If you, at a later point decided to load that interface into your Service API space, I think you still wouldn't be able to interact with this particular proxy using it, since the interface class identity would be different.
>>>
>>> Denial of service here means unfairly growing a JVM's use of non garbage collectable classes. Any ideas how to control download proxy memory consumption.
>>>
>>>> Hi Dennis,
>>>>
>>>> It sounds like you remain unconvinced or don't have a need to use common
>>>> interfaces for your service proxy's?
>>>>
>>>> So I guess it's a tread lightly approach, make the feature available to
>>>> those that want common Service API (The same interface instance for all
>>>> proxy's implementing that interface, so they can be used in collections
>>>> or batch operations), for maximum sharing of proxy's with differing
>>>> implementations, but let those that don't want to publish their API
>>>> continue doing what they usually do. A configuration parameter should
>>>> be able to set the desired behaviour.
>>>>
>>>> The approach I've taken is a simple approach to a complex problem,
>>>> alternative approaches leave the complexity in the hands of the
>>>> implementer, my approach will enable them to practically ignore it.
>>>>
>>>> Before you write it off though, to answer your earlier question, I'll
>>>> further explain the ClassLoader structure between multiple nodes.
>>>>
>>>> CLIENT NODE
>>>> ________________________________________________
>>>> | |
>>>> | System |
>>>> | ClassLoader |
>>>> | | |
>>>> | Extension |
>>>> | ClassLoader |
>>>> | | |
>>>> | Jini Platform & |
>>>> | Service API |
>>>> | ClassLoader |
>>>> | | |
>>>> | _________|___ |
>>>> | | | |
>>>> | Application Smart Proxy |
>>>> | ClassLoader ClassLoader's |
>>>> |________________________________________________|
>>>>
>>>>
>>>> SERVICE NODE
>>>> ________________________________________________
>>>> | |
>>>> | System |
>>>> | ClassLoader |
>>>> | | |
>>>> | Extension |
>>>> | ClassLoader |
>>>> | | |
>>>> | Jini Platform & |
>>>> | Service API |
>>>> | ClassLoader |
>>>> | | |
>>>> | _________|_____________________ |
>>>> | | | | |
>>>> | Service Imp Smart Proxy Parameter Impl |
>>>> | ClassLoader ClassLoader's ClassLoader's |
>>>> |________________________________________________|
>>>>
>>>>
>>>> All Proxy and Service implementations are free to vary at will, proxy
>>>> instances can be shared in collections or iterative operations based on
>>>> common Service API supertype's All Proxy's and Services are isolated in
>>>> their own Domain, the only way to communicate externally is by using
>>>> interfaces and classes in upper level ClassLoaders, they can utilise as
>>>> many third party libraries jar archives as they need, these will all be
>>>> loaded into a single ClassLoader unique to that Service or Proxy's
>>>> Codebase and Principles. The Service or Proxy's namespace will be
>>>> totally separate from Application or other Proxy implementation's,
>>>> except in the case where sharing is permitted for identical
>>>> implementations by the implementation developer.
>>>>
>>>> Service API should be carefully considered and designed, it forms the
>>>> basis of network Dependency Injection, you can discover ANY Service
>>>> implementation variant using the same Service API.
>>>>
>>>> The Service API may include other Service API or Java platform classes.
>>>>
>>>> public interface SimpleBookService {
>>>>
>>>> public Book get( Library lib, String name);
>>>>
>>>> }
>>>>
>>>> In the SimpleBookService above, given a Library and String name of a
>>>> Book, a Book instance is returned by the proxy.
>>>>
>>>> The contents of simpleBookService-api.jar:
>>>>
>>>> SimpleBookService.class
>>>> Book.class
>>>> Library.class
>>>>
>>>> Let's say a client has extended the Library, with a class called
>>>> PrivateLibrary, this class is an implementation class by the client,
>>>> that the Service knows nothing about, the Service only uses the Library
>>>> API, but it needs the PrivateLibrary.class
>>>>
>>>> The client makes an archive containing the PrivateLibrary.class publicly
>>>> available in an archive called privateLibrary-param.jar. This archive
>>>> depends on simpleBookService-api.jar The jar URL is marshalled with the
>>>> class when the parameters are sent back to the service. When it gets to
>>>> the service implementation, privateLibrary-param.jar is given it's own
>>>> ClassLoader and ProtectionDomain and isn't given any Permissions. It is
>>>> used by a SimpleBookService implementation to decide which Book to
>>>> return to the client, after which, it's garbage collected, eventually if
>>>> PrivateLibrary isn't used again its ClassLoader is garbage collected too.
>>>>
>>>> Each SimpleBookService proxy implementation will have their own
>>>> ClassLoader namespace, but Client Application classes can still use any
>>>> Service implementation or as many Service implementations as it can
>>>> handle at the same time, all the while treating them as the same Type.
>>>>
>>>> One SimpleBookService implementation proxy, contains its own
>>>> implementation of Book, and while the client is reading the book, it
>>>> remains available from the proxy ClassLoader via the Service API Book
>>>> interface, when finished reading the book, the proxy, book and
>>>> ClassLoader can be garbage collected. Tomorrow, the client might read a
>>>> book from another SimpleBookService
>>>>
>>>> Most Service API will be relatively small bytecodes as most will be
>>>> abstract or have simple implementations, the fact they're not garbage
>>>> collected, doesn't matter much if the function of the node doesn't
>>>> change, the API will remain limited to the subset in use, by the node.
>>>>
>>>> Note that Jini Platform service implementations like Reggie, Outrigger
>>>> etc, will exist in Service Impl ClassLoaders and Smart Proxy
>>>> ClassLoaders, only the api will be in the Jini Platform ClassLoader.
>>>>
>>>> Think of it as an expandable platform, everything is shared using
>>>> implementations of Service API classes.
>>>>
>>>> It's actually a good policy to be liberal with interfaces when building
>>>> the Service API classes, even with parameters and return types. Since
>>>> extending interfaces is relatively straight forward, you new interfaces
>>>> will be discovered by older client software as the old interface while
>>>> new implementation code discovers the new interface of your service.
>>>> Older nodes will load your new interface classes into the Service API
>>>> space when your new proxy versions are unmarshalled. That's why it's
>>>> important to maintain backward compatibility in the Service API space.
>>>>
>>>> So best practise would be to create an experimental djinn group until
>>>> your interfaces are stabilised and be prepared to restart your
>>>> experimental group on a regular basis.
>>>>
>>>> I have thought about using OSGi for Service API classes to be served up
>>>> so they can be garbage collected, this might work for serialization too
>>>> using the context ClassLoader. I have also thought about using
>>>> ClassLoader Tree's using bytecode dependency analysis as per Tim
>>>> Blackman's research. These things start to get very complicated, just
>>>> to be able to flush the Service API classes. Wouldn't it just be better
>>>> to use mutiple services that are load balanced, enabling the jvm to be
>>>> restarted if we want to?
>>>>
>>>> There are other ways to make the Service API classes garbage
>>>> collectable, such as having a tier filled with Service API ClassLoaders
>>>> where each Service and Proxy lives in a child ClassLoader in the tree,
>>>> however this presents the problem of what if an application wants to use
>>>> many Service API's or a combination, the different Service API classes
>>>> couldn't see each other from separate ClassLoaders.
>>>>
>>>> Something to consider, best regards,
>>>>
>>>> Peter.
>>>>
>>>> Dennis Reedy wrote:
>>>>
>>>>> On May 25, 2010, at 710PM, Peter Firmstone wrote:
>>>>>
>>>>>
>>>>>
>>>>>> 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.
>>>>>>
>>>>>>
>>>>> Right now the JVM doesnt need to be shut down at all, services can be loaded with different versions, unloaded, etc ... I think you're making assumptions here.
>>>>>
>>>>>
>>>>>> 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.
>>>>>>
>>>>>>
>>>>> Right, which is why service implementations get loaded into their own class loader. You define the 'platform' as whatever that needs to be for your case. For Rio it includes requisite bootstrapping and infrastructure technology. For River it most likely just includes the River 'platform', or nothing at all.
>>>>> Consider ServiceStarter and the class loader created from that bootstrapping process. Please explain what is missing from that approach? Each service has it's own security policy. Why does this need to change? What and how does your approach improve on? To my eyes it seems overly complicated.
>>>>>
>>>>>
>>>>>
>>>>>> 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?
>>>>>>
>>>>>>
>>>>> Common API? The service proxies dont share anything. They are each loaded from an implementation of RMIClassLoaderApi
>>>>>
>>>>>
>>>>>> This forces you to load both proxy's into the same ClassLoader, making their implementations visible to each other and the client.
>>>>>>
>>>>>>
>>>>> Not so sure about that Peter.
>>>>>
>>>>>
>>>>>
>>>>>> By separating the API into, in your case the CommonClassLoader,
>>>>>>
>>>>>>
>>>>> APIs are not added to the CommonClassLoader, and I would argue that it should not happen. You generally do not want to add classes into a class loader that does not get GC'd.
>>>>>
>>>>>
>>>>>
>>>>>> 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.
>>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>
>
>
Re: Service API, class visibility, isolation and garbage collection - ClassLoaders
Posted by Dennis Reedy <de...@gmail.com>.
Peter,
No worries. Although I think there is still a misunderstanding on how the class loader structure works, its water under the bridge - lets move on.
What I cant figure out is if you want to share classes across downloaded proxies, why the classes are not part of the API jar the client has in it's classpath. This allows downloaded proxies access to these classes, since the classloader they are loaded with delegates to the classloader that the API jar has been loaded with.
It seems you are creating an edge condition where an implementor would like downloaded proxies to share a class across implementations, but in order to do that that class needs to be injected into a parent class loader. Do I have this right?
IMO, in this scenario, I would advise that the class(es) in question should be added to the API jar.
AppCL
On May 26, 2010, at 727AM, Peter Firmstone wrote:
> Hi Dennis,
>
> Looking back at my earlier reply when you presented the ClassLoader structure for Rio, I was unintentionally insensitive.
>
> I didn't mean to pull it apart, probably not the right approach, Rio is a success in it's own right!
>
> What I should have said and I may not have communicated too well is that I'm introducing a way for Service Proxy's to utilise ClassLoader visibility for maximum API class sharing. It is a new feature, to give Service implementers the power to share their Service API's, with as much local JVM visibility as the Jini Platform Service API's have.
>
> As I pointed out there is a compromise, that Service API classes cannot be garbage collected. I think that if this can be well managed, using a Permission, then it should not affect uptime for critical applications.
>
> With great power comes great responsibility... yada yada yada.
>
> Cheers,
>
> Peter.
>
> Peter Firmstone wrote:
>> Peter Firmstone wrote:
>>> IDENTICAL TO ANOTHER MESSAGE IN THREAD: Re: Maven repository Entry was Re: Codebase service?
>>>
>>> Note: A permission will be required to allow a proxy to introduce new Service API during unmarshalling to prevent against denial of service attacks.
>> However in the absence of this permission, the additional ServiceAPI jar could be downloaded into the proxy's own ClassLoader, that would require a ClassLoader even for a dumb proxy with an interface you didn't want to load into your Service API space. This would enable unmarshalling of that Proxy. If you, at a later point decided to load that interface into your Service API space, I think you still wouldn't be able to interact with this particular proxy using it, since the interface class identity would be different.
>>
>> Denial of service here means unfairly growing a JVM's use of non garbage collectable classes. Any ideas how to control download proxy memory consumption.
>>>
>>> Hi Dennis,
>>>
>>> It sounds like you remain unconvinced or don't have a need to use common
>>> interfaces for your service proxy's?
>>>
>>> So I guess it's a tread lightly approach, make the feature available to
>>> those that want common Service API (The same interface instance for all
>>> proxy's implementing that interface, so they can be used in collections
>>> or batch operations), for maximum sharing of proxy's with differing
>>> implementations, but let those that don't want to publish their API
>>> continue doing what they usually do. A configuration parameter should
>>> be able to set the desired behaviour.
>>>
>>> The approach I've taken is a simple approach to a complex problem,
>>> alternative approaches leave the complexity in the hands of the
>>> implementer, my approach will enable them to practically ignore it.
>>>
>>> Before you write it off though, to answer your earlier question, I'll
>>> further explain the ClassLoader structure between multiple nodes.
>>>
>>> CLIENT NODE
>>> ________________________________________________
>>> | |
>>> | System |
>>> | ClassLoader |
>>> | | |
>>> | Extension |
>>> | ClassLoader |
>>> | | |
>>> | Jini Platform & |
>>> | Service API |
>>> | ClassLoader |
>>> | | |
>>> | _________|___ |
>>> | | | |
>>> | Application Smart Proxy |
>>> | ClassLoader ClassLoader's |
>>> |________________________________________________|
>>>
>>>
>>> SERVICE NODE
>>> ________________________________________________
>>> | |
>>> | System |
>>> | ClassLoader |
>>> | | |
>>> | Extension |
>>> | ClassLoader |
>>> | | |
>>> | Jini Platform & |
>>> | Service API |
>>> | ClassLoader |
>>> | | |
>>> | _________|_____________________ |
>>> | | | | |
>>> | Service Imp Smart Proxy Parameter Impl |
>>> | ClassLoader ClassLoader's ClassLoader's |
>>> |________________________________________________|
>>>
>>>
>>> All Proxy and Service implementations are free to vary at will, proxy
>>> instances can be shared in collections or iterative operations based on
>>> common Service API supertype's All Proxy's and Services are isolated in
>>> their own Domain, the only way to communicate externally is by using
>>> interfaces and classes in upper level ClassLoaders, they can utilise as
>>> many third party libraries jar archives as they need, these will all be
>>> loaded into a single ClassLoader unique to that Service or Proxy's
>>> Codebase and Principles. The Service or Proxy's namespace will be
>>> totally separate from Application or other Proxy implementation's,
>>> except in the case where sharing is permitted for identical
>>> implementations by the implementation developer.
>>>
>>> Service API should be carefully considered and designed, it forms the
>>> basis of network Dependency Injection, you can discover ANY Service
>>> implementation variant using the same Service API.
>>>
>>> The Service API may include other Service API or Java platform classes.
>>>
>>> public interface SimpleBookService {
>>>
>>> public Book get( Library lib, String name);
>>>
>>> }
>>>
>>> In the SimpleBookService above, given a Library and String name of a
>>> Book, a Book instance is returned by the proxy.
>>>
>>> The contents of simpleBookService-api.jar:
>>>
>>> SimpleBookService.class
>>> Book.class
>>> Library.class
>>>
>>> Let's say a client has extended the Library, with a class called
>>> PrivateLibrary, this class is an implementation class by the client,
>>> that the Service knows nothing about, the Service only uses the Library
>>> API, but it needs the PrivateLibrary.class
>>>
>>> The client makes an archive containing the PrivateLibrary.class publicly
>>> available in an archive called privateLibrary-param.jar. This archive
>>> depends on simpleBookService-api.jar The jar URL is marshalled with the
>>> class when the parameters are sent back to the service. When it gets to
>>> the service implementation, privateLibrary-param.jar is given it's own
>>> ClassLoader and ProtectionDomain and isn't given any Permissions. It is
>>> used by a SimpleBookService implementation to decide which Book to
>>> return to the client, after which, it's garbage collected, eventually if
>>> PrivateLibrary isn't used again its ClassLoader is garbage collected too.
>>>
>>> Each SimpleBookService proxy implementation will have their own
>>> ClassLoader namespace, but Client Application classes can still use any
>>> Service implementation or as many Service implementations as it can
>>> handle at the same time, all the while treating them as the same Type.
>>>
>>> One SimpleBookService implementation proxy, contains its own
>>> implementation of Book, and while the client is reading the book, it
>>> remains available from the proxy ClassLoader via the Service API Book
>>> interface, when finished reading the book, the proxy, book and
>>> ClassLoader can be garbage collected. Tomorrow, the client might read a
>>> book from another SimpleBookService
>>>
>>> Most Service API will be relatively small bytecodes as most will be
>>> abstract or have simple implementations, the fact they're not garbage
>>> collected, doesn't matter much if the function of the node doesn't
>>> change, the API will remain limited to the subset in use, by the node.
>>>
>>> Note that Jini Platform service implementations like Reggie, Outrigger
>>> etc, will exist in Service Impl ClassLoaders and Smart Proxy
>>> ClassLoaders, only the api will be in the Jini Platform ClassLoader.
>>>
>>> Think of it as an expandable platform, everything is shared using
>>> implementations of Service API classes.
>>>
>>> It's actually a good policy to be liberal with interfaces when building
>>> the Service API classes, even with parameters and return types. Since
>>> extending interfaces is relatively straight forward, you new interfaces
>>> will be discovered by older client software as the old interface while
>>> new implementation code discovers the new interface of your service.
>>> Older nodes will load your new interface classes into the Service API
>>> space when your new proxy versions are unmarshalled. That's why it's
>>> important to maintain backward compatibility in the Service API space.
>>>
>>> So best practise would be to create an experimental djinn group until
>>> your interfaces are stabilised and be prepared to restart your
>>> experimental group on a regular basis.
>>>
>>> I have thought about using OSGi for Service API classes to be served up
>>> so they can be garbage collected, this might work for serialization too
>>> using the context ClassLoader. I have also thought about using
>>> ClassLoader Tree's using bytecode dependency analysis as per Tim
>>> Blackman's research. These things start to get very complicated, just
>>> to be able to flush the Service API classes. Wouldn't it just be better
>>> to use mutiple services that are load balanced, enabling the jvm to be
>>> restarted if we want to?
>>>
>>> There are other ways to make the Service API classes garbage
>>> collectable, such as having a tier filled with Service API ClassLoaders
>>> where each Service and Proxy lives in a child ClassLoader in the tree,
>>> however this presents the problem of what if an application wants to use
>>> many Service API's or a combination, the different Service API classes
>>> couldn't see each other from separate ClassLoaders.
>>>
>>> Something to consider, best regards,
>>>
>>> Peter.
>>>
>>> Dennis Reedy wrote:
>>>> On May 25, 2010, at 710PM, Peter Firmstone wrote:
>>>>
>>>>
>>>>> 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.
>>>>>
>>>>
>>>> Right now the JVM doesnt need to be shut down at all, services can be loaded with different versions, unloaded, etc ... I think you're making assumptions here.
>>>>
>>>>> 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.
>>>>>
>>>>
>>>> Right, which is why service implementations get loaded into their own class loader. You define the 'platform' as whatever that needs to be for your case. For Rio it includes requisite bootstrapping and infrastructure technology. For River it most likely just includes the River 'platform', or nothing at all.
>>>> Consider ServiceStarter and the class loader created from that bootstrapping process. Please explain what is missing from that approach? Each service has it's own security policy. Why does this need to change? What and how does your approach improve on? To my eyes it seems overly complicated.
>>>>
>>>>
>>>>> 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?
>>>>>
>>>>
>>>> Common API? The service proxies dont share anything. They are each loaded from an implementation of RMIClassLoaderApi
>>>>
>>>>> This forces you to load both proxy's into the same ClassLoader, making their implementations visible to each other and the client.
>>>>>
>>>>
>>>> Not so sure about that Peter.
>>>>
>>>>
>>>>> By separating the API into, in your case the CommonClassLoader,
>>>>>
>>>>
>>>> APIs are not added to the CommonClassLoader, and I would argue that it should not happen. You generally do not want to add classes into a class loader that does not get GC'd.
>>>>
>>>>
>>>>> 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.
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>
>>
>
Re: Service API, class visibility, isolation and garbage collection
- ClassLoaders
Posted by Peter Firmstone <ji...@zeus.net.au>.
Hi Dennis,
Looking back at my earlier reply when you presented the ClassLoader
structure for Rio, I was unintentionally insensitive.
I didn't mean to pull it apart, probably not the right approach, Rio is
a success in it's own right!
What I should have said and I may not have communicated too well is that
I'm introducing a way for Service Proxy's to utilise ClassLoader
visibility for maximum API class sharing. It is a new feature, to give
Service implementers the power to share their Service API's, with as
much local JVM visibility as the Jini Platform Service API's have.
As I pointed out there is a compromise, that Service API classes cannot
be garbage collected. I think that if this can be well managed, using a
Permission, then it should not affect uptime for critical applications.
With great power comes great responsibility... yada yada yada.
Cheers,
Peter.
Peter Firmstone wrote:
> Peter Firmstone wrote:
>> IDENTICAL TO ANOTHER MESSAGE IN THREAD: Re: Maven repository Entry
>> was Re: Codebase service?
>>
>> Note: A permission will be required to allow a proxy to introduce new
>> Service API during unmarshalling to prevent against denial of service
>> attacks.
> However in the absence of this permission, the additional ServiceAPI
> jar could be downloaded into the proxy's own ClassLoader, that would
> require a ClassLoader even for a dumb proxy with an interface you
> didn't want to load into your Service API space. This would enable
> unmarshalling of that Proxy. If you, at a later point decided to load
> that interface into your Service API space, I think you still wouldn't
> be able to interact with this particular proxy using it, since the
> interface class identity would be different.
>
> Denial of service here means unfairly growing a JVM's use of non
> garbage collectable classes. Any ideas how to control download proxy
> memory consumption.
>>
>> Hi Dennis,
>>
>> It sounds like you remain unconvinced or don't have a need to use common
>> interfaces for your service proxy's?
>>
>> So I guess it's a tread lightly approach, make the feature available to
>> those that want common Service API (The same interface instance for all
>> proxy's implementing that interface, so they can be used in collections
>> or batch operations), for maximum sharing of proxy's with differing
>> implementations, but let those that don't want to publish their API
>> continue doing what they usually do. A configuration parameter should
>> be able to set the desired behaviour.
>>
>> The approach I've taken is a simple approach to a complex problem,
>> alternative approaches leave the complexity in the hands of the
>> implementer, my approach will enable them to practically ignore it.
>>
>> Before you write it off though, to answer your earlier question, I'll
>> further explain the ClassLoader structure between multiple nodes.
>>
>> CLIENT NODE
>> ________________________________________________
>> | |
>> | System |
>> | ClassLoader |
>> | | |
>> | Extension |
>> | ClassLoader |
>> | | |
>> | Jini Platform & |
>> | Service API |
>> | ClassLoader |
>> | | |
>> | _________|___ |
>> | | | |
>> | Application Smart Proxy |
>> | ClassLoader ClassLoader's |
>> |________________________________________________|
>>
>>
>> SERVICE NODE
>> ________________________________________________
>> | |
>> | System |
>> | ClassLoader |
>> | | |
>> | Extension |
>> | ClassLoader |
>> | | |
>> | Jini Platform & |
>> | Service API |
>> | ClassLoader |
>> | | |
>> | _________|_____________________ |
>> | | | | |
>> | Service Imp Smart Proxy Parameter Impl |
>> | ClassLoader ClassLoader's ClassLoader's |
>> |________________________________________________|
>>
>>
>> All Proxy and Service implementations are free to vary at will, proxy
>> instances can be shared in collections or iterative operations based on
>> common Service API supertype's All Proxy's and Services are isolated in
>> their own Domain, the only way to communicate externally is by using
>> interfaces and classes in upper level ClassLoaders, they can utilise as
>> many third party libraries jar archives as they need, these will all be
>> loaded into a single ClassLoader unique to that Service or Proxy's
>> Codebase and Principles. The Service or Proxy's namespace will be
>> totally separate from Application or other Proxy implementation's,
>> except in the case where sharing is permitted for identical
>> implementations by the implementation developer.
>>
>> Service API should be carefully considered and designed, it forms the
>> basis of network Dependency Injection, you can discover ANY Service
>> implementation variant using the same Service API.
>>
>> The Service API may include other Service API or Java platform classes.
>>
>> public interface SimpleBookService {
>>
>> public Book get( Library lib, String name);
>>
>> }
>>
>> In the SimpleBookService above, given a Library and String name of a
>> Book, a Book instance is returned by the proxy.
>>
>> The contents of simpleBookService-api.jar:
>>
>> SimpleBookService.class
>> Book.class
>> Library.class
>>
>> Let's say a client has extended the Library, with a class called
>> PrivateLibrary, this class is an implementation class by the client,
>> that the Service knows nothing about, the Service only uses the Library
>> API, but it needs the PrivateLibrary.class
>>
>> The client makes an archive containing the PrivateLibrary.class publicly
>> available in an archive called privateLibrary-param.jar. This archive
>> depends on simpleBookService-api.jar The jar URL is marshalled with the
>> class when the parameters are sent back to the service. When it gets to
>> the service implementation, privateLibrary-param.jar is given it's own
>> ClassLoader and ProtectionDomain and isn't given any Permissions. It is
>> used by a SimpleBookService implementation to decide which Book to
>> return to the client, after which, it's garbage collected, eventually if
>> PrivateLibrary isn't used again its ClassLoader is garbage collected
>> too.
>>
>> Each SimpleBookService proxy implementation will have their own
>> ClassLoader namespace, but Client Application classes can still use any
>> Service implementation or as many Service implementations as it can
>> handle at the same time, all the while treating them as the same Type.
>>
>> One SimpleBookService implementation proxy, contains its own
>> implementation of Book, and while the client is reading the book, it
>> remains available from the proxy ClassLoader via the Service API Book
>> interface, when finished reading the book, the proxy, book and
>> ClassLoader can be garbage collected. Tomorrow, the client might read a
>> book from another SimpleBookService
>>
>> Most Service API will be relatively small bytecodes as most will be
>> abstract or have simple implementations, the fact they're not garbage
>> collected, doesn't matter much if the function of the node doesn't
>> change, the API will remain limited to the subset in use, by the node.
>>
>> Note that Jini Platform service implementations like Reggie, Outrigger
>> etc, will exist in Service Impl ClassLoaders and Smart Proxy
>> ClassLoaders, only the api will be in the Jini Platform ClassLoader.
>>
>> Think of it as an expandable platform, everything is shared using
>> implementations of Service API classes.
>>
>> It's actually a good policy to be liberal with interfaces when building
>> the Service API classes, even with parameters and return types. Since
>> extending interfaces is relatively straight forward, you new interfaces
>> will be discovered by older client software as the old interface while
>> new implementation code discovers the new interface of your service.
>> Older nodes will load your new interface classes into the Service API
>> space when your new proxy versions are unmarshalled. That's why it's
>> important to maintain backward compatibility in the Service API space.
>>
>> So best practise would be to create an experimental djinn group until
>> your interfaces are stabilised and be prepared to restart your
>> experimental group on a regular basis.
>>
>> I have thought about using OSGi for Service API classes to be served up
>> so they can be garbage collected, this might work for serialization too
>> using the context ClassLoader. I have also thought about using
>> ClassLoader Tree's using bytecode dependency analysis as per Tim
>> Blackman's research. These things start to get very complicated, just
>> to be able to flush the Service API classes. Wouldn't it just be better
>> to use mutiple services that are load balanced, enabling the jvm to be
>> restarted if we want to?
>>
>> There are other ways to make the Service API classes garbage
>> collectable, such as having a tier filled with Service API ClassLoaders
>> where each Service and Proxy lives in a child ClassLoader in the tree,
>> however this presents the problem of what if an application wants to use
>> many Service API's or a combination, the different Service API classes
>> couldn't see each other from separate ClassLoaders.
>>
>> Something to consider, best regards,
>>
>> Peter.
>>
>> Dennis Reedy wrote:
>>> On May 25, 2010, at 710PM, Peter Firmstone wrote:
>>>
>>>
>>>> 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.
>>>>
>>>
>>> Right now the JVM doesnt need to be shut down at all, services can
>>> be loaded with different versions, unloaded, etc ... I think you're
>>> making assumptions here.
>>>
>>>> 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.
>>>>
>>>
>>> Right, which is why service implementations get loaded into their
>>> own class loader. You define the 'platform' as whatever that needs
>>> to be for your case. For Rio it includes requisite bootstrapping and
>>> infrastructure technology. For River it most likely just includes
>>> the River 'platform', or nothing at all.
>>> Consider ServiceStarter and the class loader created from that
>>> bootstrapping process. Please explain what is missing from that
>>> approach? Each service has it's own security policy. Why does this
>>> need to change? What and how does your approach improve on? To my
>>> eyes it seems overly complicated.
>>>
>>>
>>>> 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?
>>>>
>>>
>>> Common API? The service proxies dont share anything. They are each
>>> loaded from an implementation of RMIClassLoaderApi
>>>
>>>> This forces you to load both proxy's into the same ClassLoader,
>>>> making their implementations visible to each other and the client.
>>>>
>>>
>>> Not so sure about that Peter.
>>>
>>>
>>>> By separating the API into, in your case the CommonClassLoader,
>>>>
>>>
>>> APIs are not added to the CommonClassLoader, and I would argue that
>>> it should not happen. You generally do not want to add classes into
>>> a class loader that does not get GC'd.
>>>
>>>
>>>> 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.
>>>
>>>
>>>
>>
>>
>>
>
>
Re: Service API, class visibility, isolation and garbage collection
- ClassLoaders
Posted by Peter Firmstone <ji...@zeus.net.au>.
Peter Firmstone wrote:
> IDENTICAL TO ANOTHER MESSAGE IN THREAD: Re: Maven repository Entry was
> Re: Codebase service?
>
> Note: A permission will be required to allow a proxy to introduce new
> Service API during unmarshalling to prevent against denial of service
> attacks.
However in the absence of this permission, the additional ServiceAPI jar
could be downloaded into the proxy's own ClassLoader, that would require
a ClassLoader even for a dumb proxy with an interface you didn't want to
load into your Service API space. This would enable unmarshalling of
that Proxy. If you, at a later point decided to load that interface
into your Service API space, I think you still wouldn't be able to
interact with this particular proxy using it, since the interface class
identity would be different.
Denial of service here means unfairly growing a JVM's use of non garbage
collectable classes. Any ideas how to control download proxy memory
consumption.
>
> Hi Dennis,
>
> It sounds like you remain unconvinced or don't have a need to use common
> interfaces for your service proxy's?
>
> So I guess it's a tread lightly approach, make the feature available to
> those that want common Service API (The same interface instance for all
> proxy's implementing that interface, so they can be used in collections
> or batch operations), for maximum sharing of proxy's with differing
> implementations, but let those that don't want to publish their API
> continue doing what they usually do. A configuration parameter should
> be able to set the desired behaviour.
>
> The approach I've taken is a simple approach to a complex problem,
> alternative approaches leave the complexity in the hands of the
> implementer, my approach will enable them to practically ignore it.
>
> Before you write it off though, to answer your earlier question, I'll
> further explain the ClassLoader structure between multiple nodes.
>
> CLIENT NODE
> ________________________________________________
> | |
> | System |
> | ClassLoader |
> | | |
> | Extension |
> | ClassLoader |
> | | |
> | Jini Platform & |
> | Service API |
> | ClassLoader |
> | | |
> | _________|___ |
> | | | |
> | Application Smart Proxy |
> | ClassLoader ClassLoader's |
> |________________________________________________|
>
>
> SERVICE NODE
> ________________________________________________
> | |
> | System |
> | ClassLoader |
> | | |
> | Extension |
> | ClassLoader |
> | | |
> | Jini Platform & |
> | Service API |
> | ClassLoader |
> | | |
> | _________|_____________________ |
> | | | | |
> | Service Imp Smart Proxy Parameter Impl |
> | ClassLoader ClassLoader's ClassLoader's |
> |________________________________________________|
>
>
> All Proxy and Service implementations are free to vary at will, proxy
> instances can be shared in collections or iterative operations based on
> common Service API supertype's All Proxy's and Services are isolated in
> their own Domain, the only way to communicate externally is by using
> interfaces and classes in upper level ClassLoaders, they can utilise as
> many third party libraries jar archives as they need, these will all be
> loaded into a single ClassLoader unique to that Service or Proxy's
> Codebase and Principles. The Service or Proxy's namespace will be
> totally separate from Application or other Proxy implementation's,
> except in the case where sharing is permitted for identical
> implementations by the implementation developer.
>
> Service API should be carefully considered and designed, it forms the
> basis of network Dependency Injection, you can discover ANY Service
> implementation variant using the same Service API.
>
> The Service API may include other Service API or Java platform classes.
>
> public interface SimpleBookService {
>
> public Book get( Library lib, String name);
>
> }
>
> In the SimpleBookService above, given a Library and String name of a
> Book, a Book instance is returned by the proxy.
>
> The contents of simpleBookService-api.jar:
>
> SimpleBookService.class
> Book.class
> Library.class
>
> Let's say a client has extended the Library, with a class called
> PrivateLibrary, this class is an implementation class by the client,
> that the Service knows nothing about, the Service only uses the Library
> API, but it needs the PrivateLibrary.class
>
> The client makes an archive containing the PrivateLibrary.class publicly
> available in an archive called privateLibrary-param.jar. This archive
> depends on simpleBookService-api.jar The jar URL is marshalled with the
> class when the parameters are sent back to the service. When it gets to
> the service implementation, privateLibrary-param.jar is given it's own
> ClassLoader and ProtectionDomain and isn't given any Permissions. It is
> used by a SimpleBookService implementation to decide which Book to
> return to the client, after which, it's garbage collected, eventually if
> PrivateLibrary isn't used again its ClassLoader is garbage collected too.
>
> Each SimpleBookService proxy implementation will have their own
> ClassLoader namespace, but Client Application classes can still use any
> Service implementation or as many Service implementations as it can
> handle at the same time, all the while treating them as the same Type.
>
> One SimpleBookService implementation proxy, contains its own
> implementation of Book, and while the client is reading the book, it
> remains available from the proxy ClassLoader via the Service API Book
> interface, when finished reading the book, the proxy, book and
> ClassLoader can be garbage collected. Tomorrow, the client might read a
> book from another SimpleBookService
>
> Most Service API will be relatively small bytecodes as most will be
> abstract or have simple implementations, the fact they're not garbage
> collected, doesn't matter much if the function of the node doesn't
> change, the API will remain limited to the subset in use, by the node.
>
> Note that Jini Platform service implementations like Reggie, Outrigger
> etc, will exist in Service Impl ClassLoaders and Smart Proxy
> ClassLoaders, only the api will be in the Jini Platform ClassLoader.
>
> Think of it as an expandable platform, everything is shared using
> implementations of Service API classes.
>
> It's actually a good policy to be liberal with interfaces when building
> the Service API classes, even with parameters and return types. Since
> extending interfaces is relatively straight forward, you new interfaces
> will be discovered by older client software as the old interface while
> new implementation code discovers the new interface of your service.
> Older nodes will load your new interface classes into the Service API
> space when your new proxy versions are unmarshalled. That's why it's
> important to maintain backward compatibility in the Service API space.
>
> So best practise would be to create an experimental djinn group until
> your interfaces are stabilised and be prepared to restart your
> experimental group on a regular basis.
>
> I have thought about using OSGi for Service API classes to be served up
> so they can be garbage collected, this might work for serialization too
> using the context ClassLoader. I have also thought about using
> ClassLoader Tree's using bytecode dependency analysis as per Tim
> Blackman's research. These things start to get very complicated, just
> to be able to flush the Service API classes. Wouldn't it just be better
> to use mutiple services that are load balanced, enabling the jvm to be
> restarted if we want to?
>
> There are other ways to make the Service API classes garbage
> collectable, such as having a tier filled with Service API ClassLoaders
> where each Service and Proxy lives in a child ClassLoader in the tree,
> however this presents the problem of what if an application wants to use
> many Service API's or a combination, the different Service API classes
> couldn't see each other from separate ClassLoaders.
>
> Something to consider, best regards,
>
> Peter.
>
> Dennis Reedy wrote:
>> On May 25, 2010, at 710PM, Peter Firmstone wrote:
>>
>>
>>> 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.
>>>
>>
>> Right now the JVM doesnt need to be shut down at all, services can be
>> loaded with different versions, unloaded, etc ... I think you're
>> making assumptions here.
>>
>>> 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.
>>>
>>
>> Right, which is why service implementations get loaded into their own
>> class loader. You define the 'platform' as whatever that needs to be
>> for your case. For Rio it includes requisite bootstrapping and
>> infrastructure technology. For River it most likely just includes the
>> River 'platform', or nothing at all.
>> Consider ServiceStarter and the class loader created from that
>> bootstrapping process. Please explain what is missing from that
>> approach? Each service has it's own security policy. Why does this
>> need to change? What and how does your approach improve on? To my
>> eyes it seems overly complicated.
>>
>>
>>> 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?
>>>
>>
>> Common API? The service proxies dont share anything. They are each
>> loaded from an implementation of RMIClassLoaderApi
>>
>>> This forces you to load both proxy's into the same ClassLoader,
>>> making their implementations visible to each other and the client.
>>>
>>
>> Not so sure about that Peter.
>>
>>
>>> By separating the API into, in your case the CommonClassLoader,
>>>
>>
>> APIs are not added to the CommonClassLoader, and I would argue that
>> it should not happen. You generally do not want to add classes into a
>> class loader that does not get GC'd.
>>
>>
>>> 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.
>>>>
>>
>>
>>
>
>
>