|PREV NEXT||FRAMES NO FRAMES|
|net.gloin.resource||Provides the public the JRAP public API .|
|net.gloin.resource.util||Provides the public the JRAP public API .|
|org.gloin.example.jrap.useresourceservice||Provides an example JRAP application.|
|org.gloin.resource||Provides the JRAP prototype implementation.|
|org.gloin.resource.misc||Provides the JRAP prototype implementation.|
|org.gloin.resource.protocol.jrap||Provides the JRAP protocol handler prototype implementation.|
Please keep in mind that this project is only in prototype form. The documentation is not complete and the included functionality is still in a state of change. The included code and utilites are functional and already provide powerful functionality, but you may easily run into problems.
I welcome user feedback on the existing utilities. I am most interested in knowing what functionality is important to add next. Please let me know your opinions.
Please send feedback to firstname.lastname@example.org
Dynamic class loading using RMI
John Mcclain's Codebase Presentation
The JRAP project focuses on providing enhancements for RMI class loading as it is used by Jini clients and services. The project provides the following functionality that handles arbitrary named resources stored as byte arrays:
Restriction: Jini code senders that use RMI have to be preconfigured with the
address of the machine that will support their codebase annotation
(to set the system property
VMs sending bytes codes for marshalled objects must
be preconfigured with the name of the host on which a code server
Enhancement: Senders can annotate proxy objects with jrap urls which do not need to change on application deployment.
JRAP URLs can be used to enable a Jini service to automatically discover resource services to use as a codebase annotation. As a result, system administrators do not have to pre-configure Jini services with static codebase annotations that refer to an explicit host.
Please note: Its possible to take advantage of the resource service functionality with out using JRAP URLs at all. Just start up the resource service and register bytes with it. Use one of the URLs returned by the register method as a VM annotation.
Jini services are often designed so that the byte codes for their proxies are always downloaded on first use in the VM of a requesting service. Always downloading code has several major advantages:
Restriction: Unfortunately always downloading code can waste network resources. Ideally, clients should only download code when updated proxy versions have been deployed.
Enhancement: The JRAP URL protocol handler can cache resources locally on disk but still load them as if they had originated from a remote JRAP url (e.g. make resources appear as if they had been downloaded).
Warning: local resource caching is not yet implemented in prototype 0.01.
Some Jini service proxies may wish to survive VM restart even after a host looses network connectivity. But leveraging the dynamic upgrade capabilities of Jini under such requirements is quite difficult. Java class loading does not currently support cross VM caching which is upgradeable on demand.
The local caching capabilities of the JRAP protocol handler may be able to help solve this conflict. See resource caching above.
Currently RMI codebase annotations use ftp or http urls. These two kinds of URLs require the explicit naming of a codeserver host and port.
Enhancement: JRAP URLs can easily be made fault tolerant by simply adding multiple resource services addressable by the same URL to a federation. Additional resource redundancy schemes may also be employed.
Note that the fault tolerance afforded by JRAP urls does not
require any semantic differences between tolerant and
intolerant resource loading. By contrast, the fail over
mechanism employed by
URLClassLoader does cause
semantic differences when a failure in one URL causes the
class loader to search other urls for a resource.
Enhancement: JRAP urls are designed to be independent of particular ip addresses or DNS hostnames. Since JRAP URLs dont refer to a particular host, the same JRAP annotation can be accessible on any network.
Restriction: Using http and ftp urls for codebase annotations ties code serving to a particular wire protocol.
Enhancement: JRAP urls add a layer of indirection into resource access.
ResourceAccess proxies enable custom
downloading protocols to be employed on the fly.
Add local resource caching that supports as needed downloading of code with new versions.
|PREV NEXT||FRAMES NO FRAMES|