Discovering Mobile Code

Position Paper

Andreas Vogel
andreas@dstc.edu.au
CRC for Distributed Systems Technology (DSTC)
Brisbane, Australia Hartmut Wittig
wittig@heidelbg.ibm.com
IBM European Networking Center
Heidelberg, Germany

Problem

The immense and increasing size of the Internet makes the discovery of any kind of resources, e.g. information, services or mobile code, very difficult. In the context of this position paper the discovery of Java (byte) code as one class of mobile code will be investigated. Particular consideration will be given to the re-use of existing CORBA technologies.

Approach

The problem of resource discovery in the Internet has been tackled from various sides e.g. robots (Harvest, Alta Vista), protocols (Archie) and directories (Yahoo, Gamelan). To handle the amount of existing resources scalability mechanisms are necessary. So far directories provide the best scaling by introducing hierarchies of categories. However these hierarchies are based on arbitrary, non-standardised categories, for instance Gamelan , the Java directory. When the number of registered entities becomes very large (as in Yahoo ) the navigation through this space becomes rather complicated and not intuitive.

Our approach is based upon introducing a formal typing notation similar to CORBA (defining interface types with OMG IDL). Java's object-oriented language design allows a similar approach to CORBA, the class declaration can be extracted from the source and additionally annotated for human consumption. A good example of such an abstraction and annotation is javadoc, a tools which generates documentation of java code in HTML format from a Java source. Let's call these object abstractions java object types.

To manage Java object types they need to be registered, e.g. with a repository. Such a repository, called Java Object Types Repository, is very similar in purpose and design to the CORBA Interface Repository [1].

A given java object type can possibly have multiple (competing) instances, i.e. various implementations of the same object type or copies of the same object can be hold in multiple locations (e.g. to avoid network congestion). Implementors will want to register their particular instances and users will want to locate them.

CORBA provides the Trading Service [2] satisfying these tasks of registration and location for CORBA based services. Here service providers register their services with the trader, potential service users can search for them. The primary search criteria is on the service type.

A service type for Java code is comprised of the object type and a list of properties to describe non-structural properties. An implementation of the CORBA Trading Services can be directly re-used. The only modification that may be required is because of a different identification of entries in the Java Object Type Repository, compared with the CORBA Interface Repository.

Both technologies are scalable. The interoperability of Interface Repositories has been defined in CORBA 2.0 [1]. The Trading Service specification introduces the concept of links to federate traders.

Conclusion

An approach to discover mobile code has been given which is based on existing CORBA technology: the Interface Repository and the Trading Service. The Java Object Type Repository follows the Interface Repository in purpose and design but needs to be re-implemented due to a different type description language. Trading Service implementations can be re-used directly. To make this approach working a definition of Java object types needs to be standardised.

The outlined approach is extensible to other kind of mobile code as long as the corresponding languages provides means of structural typing and encapsulation.

References

[1]: OMG, "The Common Object Request Broker: Architecture and Specification", Revision 2.0, Object Management Group and X/Open, Framingham, MA, (1995).
[2]: OMG, "Merged Trader/Issue List document", OMG RFP Submission - OMG TC Document os/96-02-02, Object Management Group, Framingham, MA, (1996).