Home   Info   DevZone   Wiki   UsersWeb  |  MainWeb  |  InfoWeb  |  DevZoneWeb  |  SupportWeb
[ ResourceManagementDiscussion ] [ not logged in ] [ Web: Main ] goto:  options [ get info on or edit ] [ login or new user ] [ list of topics, hubs & nodes, or recent changes ]

[ ResearchPages ]

[ Parent: ResourceManagement ]

Notes on the requirements:

• Object handles aren't necessary, but should generally be used. Situations that don't need handles are resources which just perform some kind of computation for the application, without needing to reference some singleton data or hardware.

Technologies that are pretty much set in stone for this:

• RMI should be used for remote communication between a service and its remote handle. Although, if one was so inclined they could create their own skeleton/stub objects by hand. Also, some resources, say a Word Processor Conversion resource, may just send a Serializable instance, since it doesn't need to store any data in a centralized object.

There seem to be two main problems with resource management. One is the generalization of the problem so that resources which are invented long after the application programming interface is written can be integrated fully into the operating system. Like other object-oriented mechanisms, the Java technologies reduces every custom component to an extension of java.lang.Object. The generalization of resources-as-an-object should help simplify the API for custom resources.

This problem is solved with two mechanisms:

1. A program must be able to retrieve resources. It must be able to connect to an arbitary resource. A single entry point in the resource subsystem is a good idea in theory, but not required. Some kind of naming scheme is required so that arbitrary resources can be retrieved through a "naming" convention.
2. There must be a mechanism to add a new resource handler to the resource subsystem. Even resource handlers are resources and can actually exist on any machine. Two resource handlers cannot occupy the same namespace. While a static configuration of resource handlers may be adequate for some applications, a dynamic configuration is better. Dynamic configuration requires its own API.

• This part of the problem is not limited to protocols which are designed with distribution in mind. In fact, many TCP/IP protocols, such as FTP, HTTP, SMB and TELNET, are part of a consistent distribution mechanism.

• Instantiation resources are the kind that always seem to create a new object. This can be illustrated by a HTTP cache when used with an HTTP server. While each request to the HTTP server seems to create a new page, the page may be reused from the HTTP cache.
• Dynamic resources are the kind that always seem to reuse existing objects. This can be illustrated by an HTTP service itself. The HTTP service always seems to be running. Requests for its resources are forwarded to it. And yet, the service may not be running when the first request is recieved, but (re)started automatically.

I've been looking over various docs this last weekend, and I've come across several issues and clarifications. But first, I'll respond to several of Gilbert's notes.

• lack of a way to retrieve an unknown resource: Perhaps I should rewrite this statement, as even with a clarification it's still wrong. Java has many ways to retrieve known resources of a known type, such as java.io.File and java.net.Socket. It even has ways to connect to "unknown" resources (resources of an unknown type) through java.io.URL and the JavaMediaFramework. It even allows for providing resources through the RMI framework. It doesn't, however, provide for a way to provide the necessary requirements each resource may need.
• Resource handlers registered as resources? I can see that. Unix has the TTY entries and sockets registered in the filesystem. TCP/IP uses up a port number on the client side when it connects to a specific server port.
• To distribute or not to distribute: a resource should define whether or not it is accessible through a remote JVM. Indeed, a resource needs to define on its own:
  • if "taken" handlers need to be returned to the manager (if there's a limited number of handlers available), which involves leases or garbage collection or similar technology;
  • if the RMI skeleton/stub pattern is sufficient for remote access (if remote is used at all);
  • if "taking" a resource generates a new instance, or if it returns a handler from a pool;
  • many other decisions related to needs of a resource.
• Dynamic/Instantiation resources: RMI's activation framework is a good example of dynamic resources in Java. Good point, though. This needs to be well defined in the requirements if this should be provided by the manager.

• The ResourceManagement API should define an interface, with the exact implementation details up to, well, the implementation (this will be added to the doc soon). Specifications for what the API does should be provided.

• Multi-JVM OS: What are the implications of a singleton resource warehouse per machine if there are multiple VMs on the machine? We discussed the possibility of allowing different classes to run under different VMs, to allow for JDK x compatibility. If the harddrive is only accessible through this central repository, how will sharing of this resource be handled? Or how about the File class, delegating to the manager to perform I/O operations? Or what about any VM accessing this shared singlegon manager instance? How about:
  • the manager must create RMI Proxies for these classes, or
  • the VMs must allow for instance sharing, or
  • the kernel has shared call-gates to allow for kernel-based object resolution and execution.

Content of these pages are owned and copyrighted by the poster.
Hosted by: