METHOD FOR MANAGING GLOBALLY
DISTRIBUTED SOFTWARE COMPONENTS
This application is a continuation of commonly owned U.S. patent application Ser. No. 08/576,647, now U.S. Pat. No. 5,761,499 filed Dec. 21, 1995, for a Method for Managing Globally Distributed Software Components, and on that application's underlying patent provisional application Nos.: 60/000,200, filed Jun. 14, 1995 and 60/003,615 filed Sep. 12, 1995.
FIELD OF THE INVENTION
The present invention relates to a computer-implemented is method for managing software components in a computer network, and more particularly to a method for locating, loading, securing, licensing, or metering JavaTM classes which reside on a local network or on the Internet.
TECHNICAL BACKGROUND OF THE
Modern information technology provides a vast array of software items to meet many different needs. However, after a need is identified, the sheer volume of available technol- 25 ogy makes locating suitable items difficult. Systems or the items they provide may duplicate the functionality of other systems or items. Different pieces of software often behave inconsistently. Accessing and using items is difficult because items are often available only through systems that are not 30 compatible with the system on which the items would be used.
Furthermore, accessing items through the Internet, though tremendously useful, is inherently unsafe and unreliable at 3J present. A location that was uninfected yesterday may be virus-ridden or simply unavailable today. It is difficult to ensure that a virus, a snoop, or other undesired software has not been embedded in or substituted for a component. It is also difficult to track use of components for license and 4Q accounting purposes, so there is less commercial incentive to make Internet software library servers continually available and secure.
As used herein, "Internet server," "Internet client" and like terms refer to a computer that is identified by an Internet 45 address. Internet addresses are discussed in E. Krol, The Whole Internet: User's Guide and Catalog, second edition, ISBN 1-56592-063-5 ("Internet Guide"), pages 23-34.
One approach to reducing these problems relies on the applet feature of the JavaTM programming language and 50 environment. (JAVA is a trademark of Sun Microsystems, Inc.) The Java language and environment are described in The JavaTM Programming Language, by Ken Arnold and James Gosling, ISBN 0-201-63455-4 ("Java Programming Language") and in other commercially available books, 55 CD-ROMs, Web sites and the like. A wide variety of Java software components, Java browser controls, Java automation objects, and related tools are commercially available.
The Java programming language supports miniature application programs called "applets" that are executed 60 while users view World Wide Web pages. Applets are linked or included in Web pages through HTML, much as images and links to other pages are included. When a user selects the highlighted or underlined portion of the Web page that corresponds to the applet, "byte codes" corresponding to the 65 applet are transferred across the Internet to a Java interpreter in the user's Web browser. The Java interpreter "interprets"
the applet byte codes by translating them one (or a few) at a time into binary code that can be executed on the user's computer, executing the binary code, translating the next byte code(s), and so on. Thus, a given applet may run on any machine on which a Java interpreter is available, without any need for revision of the applet by a programmer.
To provide security, however, applets labor under a number of restrictions. Applets are forbidden to read from or write to the local user's hard drive. They are not allowed to read system properties, to run programs, to load dynamic link libraries, or to establish network connections with any site except the site from which the original applet was downloaded.
Programmers will immediately appreciate the difficulties raised in trying to write useful programs that cannot freely access the disk, RAM, and other system resources. The problems inherent in restricting network connectivity are somewhat subtler but also severe. As noted, applets can only look at and download from the site where the applet was originally located. This was designed as a security feature in that the Web site the applet came from is deemed secure, while all other sites are presumed to be insecure. But there is nothing inherently secure about a location just because an applet was downloaded from it.
These severe restrictions are enforced at least in part by the Web browser and its interpreter; applets are not designed to run as stand-alone programs. The applet only displays to a local screen area. The Web browser and/or the interpreter filter out any byte codes in the applet that read from the local disk, write to the local disk, or in general, do anything that leaves permanent results in a client computer's storage medium. In some interpreters, the security features can be disabled, but this makes the client system vulnerable to viruses and the other problems noted above.
The byte codes in applets and other Java programs are organized into "classes" which define "methods" (similar to procedures or functions in other programming languages), "objects" (which are instances of classes), and/or "interfaces" (which declare methods but do not implement them). Java classes, methods, objects, and interfaces are familiar to those of skill in the art.
Only locally loaded classes are available to Java clients; a list of the loaded classes is kept in a local hash table by the computer that loaded the classes. Classes that an applet or Java program or its classes refers to are loaded as needed, unless doing so violates one of the Java security restrictions. An applet or a Java class "refers to" a class definition when it contains a class definition, is capable of reading and/or writing a field that is defined by a class definition, and/or is capable of invoking a method that is defined by a class definition. Java applets, Java applications, and Java classes all refer to Java class definitions. These Java concepts are discussed at length in Java Programming Language and\or other commercially available references.
A given class may be used in many applets or stand-alone Java programs. However, the present Java language and environment provide no well-established way to license and charge for uses of individual classes. For example, if a class were "checked out" of a class library by a user for 16 minutes, ideally 16 minutes of access at a rate suitable for that class would be billed.
Similarly, there is no well-established way to ensure that a user has a valid license for an individual Java class. For example, if a company has a 100-person site license for a given class, a warning or refusal or surcharge would ideally be presented when the 101st concurrent user from that company requests the class.