| Content of these pages are owned and copyrighted by the poster. | |
| Hosted by: |
|
[ ResearchPages ] [ ResourceManagementDiscussion ]
Every operating system has methods for referencing resources, whether it's hardware resources, local file resources, remote FTP resources, and so on. This project attempts to find a universal way to access all resources.
The problem that traditional OSs encountered was a lack of a way to retrieve an unknown resource. UNIX was able to unify how data is handled (through streams), and performed several unique advances in unifying resources (network and shared process data streams as File System Nodes). The Web, its combination of URIs, Mime-types, and other related technologies, helped to unify many more resource types and the resource sources into single calls. Sun's version of Java built on top of this web infrastructure, giving it a shared platform on which the applications can run. This project is building on top of Java and other current technologies to create a resource system capable of "handling" everything that an Application may need which exists outside of itself.
The term "resource" is used here in the broadest sense of the word. It is a piece of software, a piece of hardware on the local computer, database meta-data, a remote computer, a piece of software on a remote computer, and anything else Application software may need in order to work well.
After all, isn't it the primary task of the Operating System to provide Applications with the means to access and create resources?
Every project needs goals in order to figure out where it's headed, and to give a good idea of when it can turn form beta to production. The generated API and related standard for this project should:
Like any project, this one needs requirements.
Unified Access and Unified Registration allows any kind of resource to be registered, and to find any other kind of registered resource.
By basing this project on open standards, it makes less work for us. We just need to find the right combination of technologies to give us what we need. Hopefully, then, we would just need to create "glue" code, and the less, the better.
Security and safety are critical in terms of location independence.
Management, in terms of location independence, allows for remote administration of machines. In terms of the AutonomousComputing articles published by IBM, the closer we get to a unified method for maintaining software and hardware, the easier it will be to allow software to do that maintenance.
Safety implies building robustness into the framework. This is a large umbrella for many hidden "features" of distributed computing, which includes technologies such as TransactionalServices, Leases, and BackupServices.
The big open issues with the requrements as-is are Security, Safety, and Open. Who can say when a software package is "Secure" or "Safe"? All we can do is utilize technology which is shown to aid in solving some of the larger issues with these requirements. These requirements should be well-defined in terms of what necessitates a "Secure" and "Safe" system.
JNDI, or Java Naming and Directory Interface, is a good generic way to reference any kind of resource.
Jini
Jini, in the context of a Java-based system, provides many qualities which meet this project's requirements. It uses JavaSpaces, Leasing, RMI (which can be used over SSL to provide security), and many other technologies.
One thing <a href="mailto:groboclown@users.sourceforge.net">I</a> don't like about Jini is the heavy legal issues Sun has put up around the technology (see http://www.sun.com/jini/faqs/#licensing). Fortunately, Sun is very willing to cooperate with both Corporations and NonProphet organizations in getting Jini in use. The licensing issues are there mainly to have legal backing to force anyone who claims to support Jini to prove that they actually support Jini.
Another beef I have with Jini is its service lookup API.
RMI
Sun built RMI in such a way that its underlying transport mechanism is pluggable. By default, it uses Sockets, but these could easily be switched out in favor of SSL (SecureSocketLayer), which provides point-to-point security across data transmissions.
In and of itself, it is not a solution. However, it provides ResourceHandles through the Stub/Skeleton pattern, security via SSL, LocationIndependence, and a limited form of universal resource naming/access.
It does not provide security in the form of authentication, nor does it provide any form of safety besides pull methods (make a 'ping' request to see if a RemoteException is thrown). The resource naming and access is limited as-is.
Jini vs. JXTA
Here's an interesting snippet from the Jini FAQ:
"Jini technology defines a way of organizing networks of services and clients of those services around the idea of mobile Java objects, where services advertise themselves and find other services by using the Java type system. The result is a flexible system that is protocol independent but tied to the Java platform, requiring at least one machine on the network capable of running a full Java technology-enabled environment.
"In contrast, JXTA describes a method that allows network participants to find other network participants which when found can join and collaborate in specific ways as defined by an application. While JXTA does not require that a particular platform be supported by any of the participants of the network, it does specify the form and content of the messages that will be exchanged for network participants to find each other."
The biggest problem with a universal resource management system is incompatible APIs. There is no longer a unifying API for a subset of resources, but instead any resource can implement any API. So a Cannon printer's resource may have a completely different way to access it than, say, a Hewlett-Packard printer. The hope is that a combination of robust meta-data and standards-based APIs for devices will help to aleviate this issue, but it will never solve the issue. The only way to get past this point is to either force every resource to be an instance of one of several well-defined types, or to force a "Certification" program ala Microsoft's device drivers.
| Content of these pages are owned and copyrighted by the poster. | |
| Hosted by: |
|