Jini Resource Access 0.01 (pre-alpha)

See:
Description

Packages

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.

Background

The JRAP project attempts to provide at least the following enhancements for Jini and RMI class loading:

• Eliminate static code sender preconfiguration
• Local resource caching that can survive VM incarnations
• Off-line service operation
• Hostname independent urls
Fault tolerant class loading
Stale marshalled objects
• Resource serving customization

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 lairdd@sourceforge.net

Before proceeding, please read the following prerequisite documents on Jini and RMI class loading:

Dynamic class loading using RMI

John Mcclain's Codebase Presentation

Suggested specification reading order

Goals

Jini Network Technology enables a highly dynamic and distributed computing environment. Jini clients and services need little apriori knowledge of each other to interoperate because of the following functionality:

• Jini clients and services use an automatic discovery protocol to find each other. No manual location configuration is required. Network interaction is spontaneous and on demand.
• Java brings homogeneity to network computing - Java code runs anywhere Java is installed. Jini clients and services capitalize on this capability of Java to dynamically send byte codes to teach each other how to work together.

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:

• resource service - provides a remote interface for creating, downloading, and listing network resources.
• resource management - interfaces to upload resource bytes
• resource access - interface to obtain bytes for a particular named resource.
• JRAP URL protocol format - a specification for a URL type associated with the string "jrap:///". JRAP urls do not refer to specific machines but instead provide information to lookup Jini resource access services.

Motivation

The JRAP project attempts to provide enhancements for a large number of Jini class loading issues. The most important benefits of the resource services and JRAP URL protocol are listed below:

• Sender Preconfiguration:

  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 java.rmi.server.codebase). VMs sending bytes codes for marshalled objects must be preconfigured with the name of the host on which a code server is running.

  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 resource downloading provides no caching that persists over multiple VM incarnations.

  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:

  • Instead of statically deploying proxy code in a way that is not dynamically upgradeable, clients always get the most up to date version of service proxies.
  • Clients can dynamically accept proxy versions from completely different implementations of the same service interface.
  • Code is always downloaded under from URLs associated with a particular service. Security permissions associated with a given piece of dynamic code, remain consistent instead of possibly attaining permissions associated with the system class loader.
  • For various reasons, preferred classes are always required to be downloaded. See project overture, preferred classes section.

  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.

• Off-line service operation

  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.

• Host name independent URLs

  Currently RMI codebase annotations use ftp or http urls. These two kinds of URLs require the explicit naming of a codeserver host and port.

  • Restriction: The host:port requirement makes fault tolerant class loading schemes difficult to implement. Round robin DNS is the most commonly applied solution to solve this problem.

  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.

  • Restriction: The host:port requirement can also lead to "stale" marshalled objects. Databases (e.g. rmid, JavaSpaces) of inert serialized marshalled objects will contain many codebase annotations. When unmarshalling stored objects, inaccessible codebase annotations will produce unmarshal exceptions. Additionally, moving stored marshalled objects to a network where a codebase hostname may not be accessible will also produce unmarshal exceptions.

  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.

• Resource serving customization

  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. Downloaded ResourceAccess proxies enable custom downloading protocols to be employed on the fly.

Suggested reading order:

ResourceAccess
ResourceService
ResourceServiceEntry
ResourceHandle
ResourceRegistration
JrapURLParser
JrapURLConnection

Future Enhancements:

Add local resource caching that supports as needed downloading of code with new versions.

Add leasing of resources stored in resource service. All byte resources registered with the code service should be leased. Direct support for Lease.FOREVER should be supported to handle marshalled objects that reside in databases for extended periods. Add functionality to enable the resource service to double as a lease renewal service Make it possible to use the local resource caching of JRAP without requiring use of lookup/discovery to run on the network. Thinking about using JRAP URL host:ports for this special case. Startup programs to run on windows (.bat files or .exes). May add unique identifiers to jrap urls to unambiguously reference a set of resource bytes.