WO2002027430A2

WO2002027430A2 - Constraint-based location and binding of software components

Info

Publication number: WO2002027430A2
Application number: PCT/US2001/030142
Authority: WO
Inventors: Christopher E. Barber; Christopher J. Terman
Original assignee: Curl Corporation
Priority date: 2000-09-28
Filing date: 2001-09-27
Publication date: 2002-04-04
Also published as: AU2001294753A1; WO2002027430A3

Abstract

Apparatus and methods are disclosed for locating and binding software components (52, 53, 54,55, 56, 57) based on a specified set of constraints (77). Each component is associated with a set of meta-data (64) that contains information on attributes of the component. Components are located by matching a specified set of constraints against the meta-data associated with the components. If more than one matching component is found, a set of selection criteria are used to choose one of the matching components. The component location method may search for matching components on a local computer (20, 22, 24), and one or more component servers computers (26, 36) connected to a network (30).

Description

CONSTRAINT-BASED LOCATION AND BINDING OF SOFTWARE COMPONENTS

Field of the Invention

The present invention relates to methods and apparatus for developing and deploying software. More particularly, the present invention provides a means for locating and binding software components based on a set of constraints.

Background of the Invention As software systems have increased in power and sophistication, a variety of programming languages, development tools, and software design and development techniques have been created to assist software developers to manage this increasing complexity. At present, most software is being developed using an object-oriented approach, in which systems are represented by a set of objects, each object encapsulating a related set of data and functionality. Typically, each object is an instance of a class, which describes the behavior and data of objects of that class. Examples of object-oriented programming languages include C++ and Java^™ (Java is a trademark of Sun Microsystems, Inc. of Palo Alto, California) . Although this object-oriented approach has helped in managing the complexity of software systems, most object-oriented systems do not adequately address software reuse. Typical object-oriented programs use objects of many different classes. These classes are often interrelated (e.g., by inheritance), in ways that may make it difficult or impossible to separate the code into portions that may be reused in other programs. Additionally, typical object-oriented systems encapsulate functionality and data at the level of classes, and provide only limited information-hiding capabilities for encapsulating software at higher levels of granularity, such as modules that contain numerous classes. To provide a greater degree of reusability and extensibility, and to better handle the complexity of software systems, many software developers are employing component-based development techniques. Using these techniques, complex software systems can be constructed by combining numerous software components. A software system that uses components is said to "import" the components that it uses.

Generally, software components (or "components") are units of code that are independently deployable, and that may be used with other components by a third party to build software systems, such as applications or other components . For a component to be independently deployable, it should be well- separated from its environment and from other components. To be used by a third party (i.e. someone other than the developer of the component) , a component should be self-contained, and should have a well- defined interface. The interface of a component typically includes a set of definitions of the publically accessible features of the component, such as functions, classes, or global variables. Depending on the component architecture, these interfaces may be specified in an interface definition language, which is machine-parsable, and may be used by the component architecture to produce a standard binary representation of each interface. Additionally, interfaces may be annotated by human-readable text that provides more detail on how components are supposed to behave, and that may be used in generating documentation for the components. Generally, it is possible to create multiple, interchangeable components that satisfy the same set of interfaces.

Components can be large units of code, such as an entire database server, or much smaller units of code, such as code for handling a single data type. Generally, components are distributed in a pre-compiled form, but may be distributed in other forms, such as source code or partially-compiled code, depending on the features of the environment in which the components will be used.

Importing a component may be done statically, when the program is linked, or dynamically, at runtime, when the component is to be used. In either case, it is necessary to identify and locate the component that is to be imported.

One simple method that has been used to identify a component is using a file name in which the component can be found. Locating components that are identified by file name typically involves looking for the file name in a particular directory or set of directories on a computer. This simple approach is generally inadequate, since a file in a directory can easily be replaced with a different file, containing a different and incompatible component, but with the same file name. Identifying components by file name cannot guarantee that the component that is imported is the same as the component that the developer intended to be imported.

To address this difficulty, some component architectures provide more flexible and complex component location methods. For example, in the

Component Object Model (COM) architecture, by Microsoft Corporation, of Redmond, Washington, each component has a unique identifier. This unique identifier is stored in a simple database, called a "registry", along with information on where the component may be found (e.g., file name and directory) . When importing a component, the developer may specify the unique identifier of the component that he desires, and the system will locate and bind a component with that unique identifier, assuming that a component having the specified unique identifier is listed in the registry. By using a unique identifier to name and locate a component, COM attempts to insure that the correct component is imported. A slightly different approach is taken in

Java^™, which uses a component or class name to identify and locate components. Typically, a component or class name m Java consists of a series of identifiers separated by dots. For example, "App.Name.Example" could specify the name of a Java^™ component or class. The mechanism used to locate classes is left up to individual implementations, but all implementations use only the class name to locate classes. The naming and location mechanisms available in Java^™ and COM rely on the uniqueness of the identifier or name that is used to specify the desired component to insure that the correct component is being imported. Unfortunately, use of such strong identifiers may prevent a system from having the flexibility to choose a "best" component from among numerous components that would meet its requirements . For example, a system may be compatible with both version 1 and version 2 of a component. In most cases, it would probably be desirable to load version 2 of the component, since it is likely to have improved on version 1 (though this is not always the case) . If version 1 and version 2 have unique identifiers, and the software system locates a component to be imported using the unique identifier for version 1, then version 2 will not be located and imported.

Similarly, it may be desirable to use information about a component other than its unique identifier or name to determine which component should be imported. For example, information on how a component was compiled, who the author of the component was, or what it costs to use a component may all be important in specifying a component to be imported. While a unique identifier may be used to specify a component that a developer has determined has the proper^' characteristics, if any of these characteristics later change, the system will continue importing the component with the specified unique identifier — even if a "better" component is available.

Such information about a component is referred to as component meta-data. Although some systems, such as Java^™, permit limited types of metadata, such as the vendor or version of a specification or implementation, to be associated with a component, these are pre-determined items, and typically cannot be extended. Existing systems, such as COM and Java^™ do not provide mechanisms for associating arbitrary eta- data with a component, or for locating and importing (or binding) components based on such meta-data.

Component location can become more difficult in a networked environment, in which components may be stored on computers that are accessible over the network, rather than being stored locally. Java^™, for example, uses different methods for using local components (i.e. components located on the computer that is importing the component) than for remote components (i.e. components located on a remote computer) .

In COM, component locations in the registry may specify locations for components on remote computers, and a registry may be shared by multiple computers on a local area network (LAN) . If a needed component is not found in the registry, however, there is no facility for searching for the component on a network. This problem is addressed in U.S. Patent No. 5,761,499, to Sondregger, which describes a method for extending COM so that if a component is not found in the registry on the local computer or LAN, the system may search for the component on a component server computer that is accessible on the LAN, or over a wide area network (WAN), such as the Internet. This search is performed using a unique identifier for the component. If a component with the same unique identifier is found on the component server, then the component may be transferred as needed, and registered in the registry of the local computer or LAN. Since the searches performed by the system described in Sondregger use a unique component identifier, they lack flexibility, as discussed hereinabove. The flexibility to locate a component based on a set of criteria or constraints, rather than on a single unique component identifier becomes even more desirable in a networked environment, where there may be access to a wide range of components that match a given set of criteria. In view of the above, it would be desirable to provide methods and apparatus that permit a component to be located based on a set of specified criteria or constraints.

It would further be desirable to provide apparatus and methods that permit a variety of metadata useful for selecting a component to be associated with a component.

It also would be desirable to provide apparatus and methods that locate and bind components either locally or across a network based on a set of specified criteria or constraints.

Summary of the Invention

It is an object of the present invention to provide methods and apparatus that permit a component to be located based on a set of specified criteria or constraints.

It is further an object of the present invention to provide apparatus and methods that permit a variety of meta-data useful for selecting a component to be associated with a component.

It also is an object of the present invention to provide apparatus and methods that locate and bind components either locally or across a network based on a set of specified criteria or constraints.

These and other objects of the present invention are achieved by providing apparatus and methods that locate and bind components based on matching a specified set of constraints with a set of meta-data that is associated with each component. This matching process may be performed on a local computer, or across a LAN or WAN. In a preferred embodiment of the present invention, each component is associated with a set of meta-data that may be useful, among other things, for selecting a component to be imported. This meta-data may include information common to many component architectures, such as a unique identifier or component name. Additionally, the meta-data may include information such as the author of the component, a version number, information on the time and manner in which the' component was compiled, and any other information that is associated with the component. Location and binding of components is achieved by specifying a set of constraints on the component that is to be located and bound, and then performing a search for components that have meta-data that matches the specified set of constraints. If more than one component matches the specified set of constraints, then one or more selection criteria may be used to choose the component that will be bound. Examples of selection criteria include choosing the ^• component with the highest version number, or the latest compilation time.

The meta-data associated with each component is stored in a component index, which may comprise a database. Additionally, the components themselves may be stored in a component repository, along with the component index. Alternatively, the location of each component may be stored in the component index, and the components themselves may be stored in any accessible location. A local computer may have numerous component indices or component repositories. Additionally, component servers may provide access to component indices and component repositories over a LAN or WAN, such as the Internet. In a preferred embodiment, each process is associated with a component repository (or component cache) that stores the components that are in use by that process, as well as a component index that stores the meta-data associated with those components. In addition, the runtime environment is associated with a shared component repository that includes the components that are being used by all the executing processes, and a component index containing meta-data for those components. Additionally, the runtime environment may keep a list of locations (both local and on a LAN or WAN) that may be searched for components. Finally, when a set of constraints are specified, the developer may provide location hints that specify locations that may be searched for a matching component. All of these locations may be searched in a predefined order to locate a component that matches the specified set of constraints.

The present invention also provides a two- phase location and binding method that uses dependencies between components, as well as the specified constraints, to determine which set of components to bind. An object-oriented framework for implementing the present invention, as well as a computer system and networked environment in which the present invention may be used are also described.

Brief Description of the Drawings

The above and other objects and advantages of the present invention will be apparent upon consideration of the following detailed description taken in conjunction with the accompanying drawings, in which like characters refer to like parts throughout, and in which: FIG. 1 is a diagram of a networked environment in which the methods and apparatus of the present invention could be used;

FIG. 2 is a diagram of a computer system on which the methods of the present invention could be used;

FIG. 3 is a diagram of a sample software system built using components;

FIG. 4 shows the structure of a component in accordance with the present invention; FIG. 5 shows the structure of meta-data that may be associated with a component in accordance with the present invention;

FIG. 6 is a diagram of a component repository, that is used for storing components and their associated meta-data;

FIG. 7 shows the structure of a component selection specification in accordance with the present invention;

FIG. 8 is a flowchart of a component location method designed in accordance with the principles of the present invention;

FIG. 9 is a diagram showing the component caches and locator list that are used to provide a search order for component location in a preferred embodiment of the present invention;

FIG. 10 is a flowchart showing the search order for component location in a preferred embodiment of the present invention;

FIG. 11 is a diagram demonstrating the utility of using component dependencies to determine which set of components should be bound;

FIG. 12 is a flowchart of a two-phase method that uses component dependencies to determine which set of components should be bound; and

FIGS 13A - 13D show classes that may be used in an object-oriented implementation of the methods of the present invention.

Detailed Description of the Invention

Referring to FIG. 1, an example of a computing environment in which the methods and apparatus of the present invention may be used is described. Computers 20, 22, and 24, and server 26 are connected to local area network (LAN) 30. Each of computers 20, 22, and 24 may execute a variety of software, all or part of which may be stored locally on computers 20, 22, or 24, or may be stored on server 26, and accessed over LAN 30. LAN 30 is connected to a wide area network

(WAN) 32, such as the Internet, through gateway 34, which may be a dedicated device, or may be a computer or server, similar to computers 20, 22, and 24, or server 26. By sending communications across WAN 32, any of the devices connected to LAN 30 may communicate with remote server 36, or with other devices or networks connected to WAN 32. Computers 20, 22, and 24 may gain access to information and software through WAN 32.

It will be understood by one skilled in the art that the above-described environment is for illustration, and that the present invention may be used under a variety of conditions. For example, the methods and apparatus of the present invention could be used on a single stand-alone computer, but would then be unable to access information or software over LAN 30 or WAN 32. Generally, the present invention may be used with any configuration of one or more computers, which may be interconnected on one or more networks.

It will further be understood by one skilled in the art that LAN 30 may include a variety of devices other than computers. For example, LAN 30 may include printers (not shown) , scanners (not shown) , disk arrays (not shown) , or any other type of device that may be connected to a network.

Referring now to FIG. 2, a computer system, such as computers 20, 22, or 24, suitable for use with the present invention is described. Computer system 40 includes at least processor 42, for processing information according to programmed instructions, memory 44, for storing information and instructions for processor 42, and storage system 46, such as a magnetic or optical disk system, for storing large amounts of information and instructions on a relatively long-term basis. Processor 42, memory 44, and storage system 46 are coupled to bus 48, which preferably provides a high-speed means for devices connected to bus 48 to communicate with each other.

It will be apparent to one of ordinary skill in the art that computer system 40 is illustrative, and that alternative systems and architectures may be used with the present invention. It will further be understood that many other devices, such as a display system (not shown) , a network interface (not shown) , and a variety of other input and output devices (not shown) may be included in computer system 40.

In accordance with the principles of the present invention, software and content for use on the above-described computer systems and environments may be constructed using one or more components. As used herein, a component (or software component) , is an independently deployable unit of software or content that may be used ("imported") by other software or content. Components preferably have well-defined interfaces, so that one or more components can be interconnected to form applications or content, without requiring detailed knowledge of the inner workings of the components.

Although the examples of components used herein generally involve components referred to as "packages", that contain software routines or objects that perform various functions, components may have other types of content. For example, a component may contain an interface definition, a document or a portion of a document, data, digital media,^' or any other type of independently deployable content that may be used alone or in combination to build applications or content for use on a computer. ^■ A component typically encapsulates a collection of related data or functionality, and may comprise one or more files. A program or other object that uses components is said to "import" the components that it uses. A programmer or content developer may specify which components are to be imported by a piece of software in the source code for the software, using an import construct, such as an import statement in the programming language being used. Alternatively the components to be imported may be specified using development tools or a development environment. A component that is loaded and ready for use is said to be "bound" to the object that loaded it, and the process of loading the component and linking it to the program or other object that uses it is referred to as "binding." It will be understood by one skilled in the art that binding can be performed when a program or other content is compiled, by a linker or other development tool. Alternatively, binding can be done at run time, when a program or object is loaded, or when the component is needed. Referring now to FIG. 3, the structure of an example game program built using components is described. Game program 50 is an adventure game, in which a player explores various "dungeons". The game uses two-dimensional graphics, and accepts input from a keyboard. For purposes of this example, the game may be separated into four main functional categories: game graphics code, that displays the game state and includes code for handling keyboard input; game representation code, that includes classes for representing dungeons, monsters, treasure, etc.; driver code, that ties everything together and runs the game; and specific dungeons (here, dungeon A and dungeon B) , which include the data and any specialized code for specific dungeon adventures. All this is initialized and tied together by a main program.

As shown in FIG. 3, main program 51 imports game driver component 52, dungeon A component 53, and dungeon B component 54. Driver component 52 imports game graphics component 55, which in turn imports standard graphics component 56, containing standard two-dimensional graphics classes. Driver component 52, game graphics component 55, dungeon A component 53, and dungeon B component 54 all import game representation component 57. All of the components may also import a "standard library" component (not shown) , that provides access to a set of objects or routines that are common to the run-time environment in which game program 50 executes. By combining a set of components, each of which may be separately distributed, a relatively complex software system may be built. Advantageously, as long as the interface the components remains the same, it is relatively easy to replace components with different implementations or newer versions. For example, if a new version of standard graphics component 56 becomes available, as long as it has an interface that is consistent with the old version, it may be substituted for the old version without requiring any substantial changes in the rest of game program 50. If component location and binding are handled statically at compile time or when the program is released, it may be necessary to re-link and/or re- release game program 50 to incorporate an updated version of standard graphics component 56. If component location and binding are handled dynamically, at run-time, such steps would typically not be required.

Referring now to FIG. 4, the structure of a component according to the principles of the present invention is shown. Component 60 comprises content 62 and meta-data 64. Content 62 may include code, data, an interface specification, or any other content that may be distributed as a component. Meta-data 64 includes a variety of information about component 60. This information should minimally include a component name, and a unique component identifier. Meta-data 64 may also include a variety of other information, as described in detail hereinbelow. Parts of meta-data 64 may be specified by a programmer or content developer at the time the component is written, while other parts must be computed, and added to meta-data 64. For example, the unique ID of the component may be computed by using a secure hash function, as described in detail in commonly owned, copending U.S. Patent Application No. [CURL-004] . Similarly, meta-data such as the time at which a component was compiled or released would typically be computed and added to meta-data 64 by a release tool or by a development environment.

As shown in FIG. 5, meta-data 64 comprises a series of key-value pairs. Keys 66a - 66d identify particular items of meta-data by name. For example, a unique identifier may use "id" as a key, while a metadata item containing the name of the author of a component may use "author" as a key. Values 68a - 68d are meta-data values associated with keys 66a - 66d. These values contain information pertaining to the particular component with which the meta-data is associated.

In a preferred embodiment, for use with the Curl programming language, meta-data 64 may include the items listed in table 1. It will be understood that the meta-data associated with a component may vary, and that some systems will use a different set of meta-data than that shown in FIG. 1. Additionally, it will be understood that some of the meta-data items listed in table 1, such as the name of the component, may be stored separately from other key-value pairs, due to their presence in almost all components, or the frequency with which they are accessed. Certain of the meta-data items listed in Table 1, such as "author", and "name", will be given values by the programmer or content developer, while others, such as "compilation- time" and "id" will be generated by a compiler or development environment.

Numerous components and component meta-data may be stored in a component repository, such as is shown in FIG. 6. Component repository 70 comprises component index 72 and component store 74. Component store 74 contains zero or more components. In accordance with the principles of the present invention, meta-data for each of the components in component store 74 is placed in component index 72. To access a component, component index 72 may be used to identify a component, which may then be accessed from component store 74. In a preferred embodiment, component store 74 comprises a directory on a storage system, such as storage system 46. Each component in component store 74 comprises a file in the directory, with a file name corresponding to the component's unique ID. Component index 72 may comprise a separate index file in the directory, or a database that stores the meta-data for each of the components in the component repository. Alternatively, both the meta-data in component index 72 and the components in component store 74 may be kept in a database.

A component repository, such as component repository 70, may reside on the same computer that is using the components, or may be accessible over a network. For example, for the LAN shown in FIG. 1, a component repository for all of computers 20, 22, and 24 may reside on server 26, and be accessible over LAN 30. Similarly, a component repository may reside on a remote server, such as remote server 36, and be accessible over a WAN, such as the Internet. a computer on a LAN or a WAN that provides access to a component repository may be referred to herein as a component server. It should be noted that a component repository may be present on a local computer, on one or more servers on a LAN, and on one or more servers on a WAN, such that if a process running on the local computer is unable to locate a needed component on the local computer, it may search for the component on the servers on the LAN or WAN.

In addition to having searchable component repositories on numerous servers, there may be numerous component repositories available on a single computer. For example, a particular process running on a single computer may keep its own separate component repository for components needed by that process. Other processes running on the same computer may keep their own separate component repositories on the same computer. A component repository that is associated with a single process or set of processes, and that is designed to give the processes with which it is associated rapid access to needed components may be referred to herein as a component cache. Since a component cache typically contains only those components that have already been loaded and are present in memory, a component cache generally does not store components or component meta-data on a file system. A component cache may, for example, use structures that are kept in memory for keeping track of the loaded components and component meta-data for each process.

In an alternative embodiment, component store 74 may be located on a different computer than component index 72, or may be distributed across several computers on a LAN or WAN. In such an embodiment, the meta-data in component index 72 would include information on which server is able to provide each component. Instead of using a file name to specify the location of a component, a locator such as a URL (Uniform Resource Locator) , which specifies the name of the server as well as the name used to access a particular file on the server may be used.

In another alternative embodiment, component store 74 may be absent from component repository 70. In this embodiment, entries in component index 72 include a location pointer, such as a URL at which each component accessible through the component store may be found. By keeping only the index and the locations of the components, a component repository according to this embodiment may be compact, since the components themselves are not kept in the component repository.

It may be desirable to establish one or more "central" component repositories or component servers on the Internet, which keep a component index for a large number of components. Whenever a developer releases a new component, it could be registered with the central component servers, which would record the meta-data for the component, and information on the component's location in a component index database, such as component index 72. This would provide a limited set of authoritative locations that could be searched for released components if other searches fail. The present invention involves using the meta-data that is associated with a component for the purpose of location and binding. As described hereinabove, location of components has typically been based on a component name or ID. In accordance with the principles of the present invention, components can be located based on any of their meta-data. Rather than specifying the name or unique identifier of a component, the present invention uses a set of constraints that specify desired values for the metadata to choose a particular component to be imported or bound.

Referring to FIG. 7, the structure of a set of constraints used for component selection is described. Component selection specification 75 comprises constraint list 77 and location hints 79. Constraint list 77 is similar to meta-data 64 of FIG. 5, and comprises keys 76a - 76d, and constraints 78a - 78d. Keys 76a - 76d are similar to meta-data keys

66a - 66d of FIG. 5. Each of keys 76a - 76d specifies a key in the component meta-data for which the value must match the corresponding constraint. Constraints 78a - 78d specify a value to be matched in the meta- data. Component selection specification 75 may also comprise optional location hints 79, which specify the location of one or more component repositories that may be searched for a matching component.

Generally, a key-constraint pair in component selection specification 75 matches a key-value pair in meta-data 64 if the keys are identical, and the value associated with the key in meta-data 64 matches the constraint associated with the key in component selection specification 75. In a preferred embodiment, a value matches a constraint if the value and constraint are identical. Alternatively, a constraint may be specified using regular expressions or some other form that may match a range of values. For example, a constraint such as "a*" would match any value that begins with "a" (i.e. "a" followed by zero or more characters) . Other forms of constraints, such as ranges of values could also be used without departing from the invention. Thus, a constraint of "2.3 <= version <= 5.2" applied to the "version" key might match any value of "version" between 2.3 and 5.2, inclusive. It will be apparent to one of ordinary skill in the art that the syntax used to specify these constraints may vary, and that any means of expressing a constraint may be used in accordance with the present invention.

A component selection specification, such as component selection specification 75, matches a component if for each key in the component selection specification, there is an identical key in the component meta-data, and if for each key in the component selection specification, the constraint associated with that key matches the value associated with that key in the component meta-data. The location and binding methods of the present invention locate components within one or more component repositories by matching a component selection specification, such as component selection specification 75, against all the component meta-data stored in the component index portion of one or more component repositories. This matching may be performed on the computer that is attempting to import a component, or it may be performed over a network by a component server. Typically, when performed over a network, the computer that is attempting to import a component sends a component selection specification to a component server over the network, and the component server performs the matching procedure, and returns a list of matching components.

FIG. 8 shows a flowchart of a method of locating components in accordance with the principles of the present invention. As explained hereinabove, the location and binding methods of the present invention may be used at the time a piece of software or content that imports a component is compiled or linked (compile time) , at the time the software or content is executed or used (run time) , or at other times, through use of a development environment or development tools, such as a release tool.

At step 1001, one or more constraints to be matched are specified. These constraints may be specified in a statement in the source code of a program or other content that imports a component, or they may be specified in a development environment.

The constraints are used to specify the component to be located and bound.

At step 1002, the constraints are matched against the meta-data for one or more components. This step may comprise matching the constraints against meta-data for all of the components in one or more component repositories, either on the computer that is attempting to import a component, or in a component repository that is accessible over a LAN or WAN. If no components having meta-data that matches the constraints are found (step 1003), at step 1004, the system may report an error, and end the location and binding process. If only one component with meta-data that matches the specified constraints is found (step 1005) , then the method returns that component, which may then be bound into the program or content that was importing the component (step 1006) . It is also possible, depending on the constraints and the available components, that more than one component will have meta-data that matches the constraints. If this occurs, it is necessary to select only one of the matching components to be bound. At step 1007, selection criteria are used to select one of the components that have matching meta-data. Selection criteria may include rules that specify that the component with the highest version number should be used, or the component with the most recent compile time, or the component with the most recent release time, or that a statically compiled component should be chosen over a dynamically compiled (e.g., JIT-compiled) component. It will be understood that many other selection criteria or rules could be used to select a single component from a set of components. If all selection criteria fail, or none are specified, a component could be chosen at random or by any arbitrary means from the set of components that match the constraints .

The selection criteria used in step 1007 may either be built into the system, or may be specified by a developer or user. If the criteria are specified by a developer or user, they may be specified in the source code of the program or content that imports a component, or in a development environment. Additionally, a developer or user may optionally be able to specify different selection criteria for each set of constraints to be matched (i.e., for each component that is imported) . Once a single component is selected from the set of components with meta-data that matches the specified constraints, at step 1008, that component is returned, and may be bound. It should be noted that when the methods of the present invention are used to search for a component in more than one component repository, the order in which the component repositories are searched plays an important role in determining which component is selected. Generally, the system will search component repositories in a specified order, and will stop searching as soon as one or more matching components are found.

In a preferred embodiment, the order in which component repositories are searched when locating a component will cause components that have already been located and loaded by the system to be searched first. Referring to FIG. 9, the component repositories that may be searched in a preferred embodiment and a preferred search order are described. In the preferred embodiment discussed with reference to FIG. 9, component location and binding occurs at run-time, so that the programs that are importing components are locating and binding the components when they are actually imported.

Processes 80, 82, and 84 are independent processes executing on a computer under the same runtime environment 92. Each of processes 80, 82, and 84 contains a set of loaded components (86, 88, and 90, respectively) , preferably in the form of a component cache, that contains the set of components that are currently in use by that process. This process- specific loaded component cache is the first place that a process should search for a matching component. Thus, when importing a component, process 80 would first search in loaded component cache 86, process 82 would search in loaded component cache 88, and process 84 would search in loaded component cache 90. By searching such a process-specific loaded component cache first, a process may avoid loading and binding components that have already been loaded by that ^•process, and that may be shared.

If a component with meta-data that matches the specified constraints is not found in a process- specific loaded component cache, then shared component cache 94, associated with runtime environment 92, may be searched for matching components. Shared component cache 94 contains meta-data and references to all of the components that have been loaded by all the currently executing processes running under runtime environment 92. If a component with meta-data that matches the specified constraints is found in shared component cache 94, the system may avoid reloading the component, since the component is already loaded, and may be shared.

If no matching component is found in shared component cache 94, the system next uses locator list 96 to locate a matching component. Locator list 96 contains a list of component locators, each of which may search component repositories on the local computer, on a LAN, or on a WAN, such as the Internet, for matching components. The system may send search requests to each of the component locators in locator list 96 in order, or may simultaneously send search requests to numerous of the component locators in locator list 96.

If no matching component is found in any of the component repositories searched by the component locators in locator list 96, the system may use any location hints specified with the component selection specification, such as component selection specification 75, that is being used to search for a matching component. As explained hereinabove, the location hints may contain the locations of one or more component repositories that may be searched for a matching component. Optionally, search requests may be sent to the component repositories specified in the location hints before locator list 96 is used to locate a matching component .

A flowchart of this multi-stage search process is shown in FIG. 10. At step 2001, a process- specific loaded component cache, such as component caches 86, 88, and 90, is searched for components with meta-data that matches the constraints in a component selection specification. If no match is found, at step 2002, a shared component cache, such as shared component cache 96, associated with the runtime environment is searched. If no match is found in the shared component cache, at step 2003, the system searches for components with meta-data that matches the constraints by using component locators specified in a locator list, such as locator list 96. If there are still no matching components, at step 2004, the system searches for matching components at the locations specified in locations hints that are optionally part of a component selection specification.

Finally, if no matching components were found, then at step 2005, the system generates an error, and the component location and binding process ends. Otherwise, if one or more matching components were found in any of steps 2001, 2002, 2003, or 2004, at step 2006 the system returns the matching components, and may proceed to select a single matching component, load the matching component, and bind the component (see steps 1006 - 1008, described with reference to FIG. 8) . In addition to the search order affecting the component location process, dependencies between components may also affect the component location process. This is illustrated with reference to FIG. 11, which shows program 100, which imports components 102 and 104. Component 102 imports a component referred to as "component A", and does not specify a version of "component A" that is needed in the constraints of the component selection specification that is used to locate a matching component for "component A". Therefore, both component 106, which represents version 1 of "component A", and component 108, which represents version 2 of "component A" will match the constraints. Since there are two matching components, using typical selection rules which favor the more recent version, component 108, representing version 2 of "component A" will probably be selected.

Component 104 requires version 1 of "component A", and specifies version 1 in the constraints of the component selection specification that it uses to locate a matching component. Since version 1 has been specified in the constraints, only component 106, which represents version 1 of "component A" will match the constraints.

Without a system that takes dependencies between the components into consideration, it is possible that the system will load and bind both versions 1 and 2 of "component A". This presents a problem, since there may be implicit assumptions built into program 100 that the version of "component A" obtained through component 104 is the same as the version of "component A" obtained through component 106. Even if no such assumptions are present, it is wasteful to load both versions, since version 1 of "component A" is the only version that is required, and could be shared by components 102 and 104.

If location and binding of components is done at run-time, these difficulties may be avoided if we are lucky, and component 104 loads component 106 (version 1 of "component A") before component 102 loads component 108 (version 2 of "component A") . This is because once component 106 is loaded, it will be present in a process-specific component cache, and will be matched when component 102 attempts to locate a matching version of "component A". On the other hand, if component 102 loads component 108 first, then component 104 will still need to load component 108.

These problems can be solved by using a two- phase location and binding process, as illustrated in FIG. 12. It should be noted that the two-phase approach shown in FIG. 12 may be used for location and binding that is done at compile time, at run-time, or by a development environment or release tool.

In the first phase, step 3001, the system collects all of the dependencies for the components that are being imported. These dependencies may be stored in the component meta-data, or it may be necessary to scan the source code of any imported components to determine what components they import, and to gather the constraints that they use to import these components. This process is performed recursively, so that the entire tree of dependencies is collected. Each of these dependencies is associated with a set of constraints that are used to specify which component is to be imported.

Once all of the dependencies are known, in the second phase, step 3002, the constraints used to locate each of the components to be imported are analyzed, along with the set of meta-data for all matching components, to determine the minimum set of components that have meta-data that matches all of the constraints. Since this two-phase approach may be computationally expensive, it may be preferable to have the inefficiency associated with loading multiple versions of the same component, rather than incur the computational expense of performing the two-phase analysis described with reference to FIG. 12. This is particularly true if location and binding is done at run-time, when the computational expense associated with the analysis may cause long delays in the execution or loading of a program or other content. Thus, this two phase approach is most likely to be used in embodiments of the present invention that perform location and binding of components at compile time, or as part of a "release" or "freezing" process in a development environment in which such processes are performed only when a program or other content is ready to be released.

In a preferred embodiment, the methods of the present invention are supported directly in a programming language, that preferably includes syntax for associating arbitrary meta-data with components, and for importing components by specifying meta-data to be matched. A preferred embodiment of the present invention uses a language based on the Curl programming language, developed at the Massachusetts Institute of Technology (Curl; A Gentle Slope Language for the Web, M. Hostetter, D. Kranz, C. Seed, C. Terman, S. Ward, MIT Laboratory for Computer Science World Wide Web Journal, Volume 11. II, Issue 2, Spring 1997). In this preferred embodiment based on Curl, a software component may contain a "package herald" that contains arbitrary meta-data. An example of a syntactic construct for specifying such a package herald is:

{package COM. CURL. MATH. TRIG, {files

"trig, curl ", "bi twise , curl ", "scientific, curl " } author = "Joe Soap" version = "1 . 0 "}

This package herald specifies the name of the package (COM.CURL.MATH.TRIG) , the subsidiary files of the package, and two meta-data items — an author, and a version. Other arbitrary meta-data items could be specified by adding their keys and values in the same manner that the author and version meta-data items were specified. Some meta-data items, such as the unique ID for the component, are not specified by a programmer as part of the package herald, but are calculated later, by the compiler or development environment.

For locating and binding components, a preferred embodiment of the present invention based on the Curl language supports an import construct in the form of an "import" statement in which an arbitrary list of meta-data items to be matched may be specified. An example of such an import statement is: {import COM. CURL. MATH. TRIG, location="http: //www. curl , com/math/ trig, curl ", version="l . 0", author="Joe Soap"}

This import statement will cause the system to search for the COM.CURL.MATH.TRIG component having meta-data that includes a "version" key with a value of "1.0", and an "author" key having a value of "Joe Soap". In a preferred embodiment, the system will search for the component in an order similar to the one described hereinabove with reference to FIG. 9. The "location" value specifies a location hint, that may be used to locate the component of searches in local component caches and repositories, and in standard locations specified in a locator list are unsuccessful. In this example, the location hint is in the form of a URL that specifies a file where the component may be found. Alternatively, the location hint may specify the location of one or more component repositories that may be searched.

The methods of the present invention are preferably implemented as a set of classes in an object-oriented system. Instances of these classes are used to specify component meta-data, to build component selection specifications, to locate matching components, and to load or bind components into a program or other content. Examples of the classes that are used for these purposes in a preferred embodiment are shown in FIGS. 13A - 13D. These figures show the names of the classes, along with the methods and variables that are encapsulated by the classes. Variables and methods that are common to all objects, or that are used for bookkeeping, streaming output, or other purposes common to object-oriented environments, and not related to the present invention have been omitted.

FIG. 13A shows a specification for ComponentMetaData class 120. Objects of ComponentMetaData class 120 are used to store and manipulate the meta-data associated with each component, in accordance with the principles of the present invention.

ComponentMetaData class 120 comprises meta- data variable 122, which comprises a list of key-value pairs, as described hereinabove with reference to FIG. 5. Meta-data variable 122 stores all of the meta-data that is associated with a component. Optionally, certain required meta-data items, such as the component name and unique ID may be stored in separate variables (not shown), for faster access.

The methods of ComponentMetaData class 120 include set method 124, set? method 126, unset method 128, get method 130, matches? method 132, and keys-to- iterator method 134. Set method 124 takes a key and a value as parameters, and adds a key- alue pair corresponding to the key and value parameters to key- value list maintained in meta-data variable 122. If the key specified in the key parameter is already present in meta-data variable 122, then set method 124 replaces the value associated with that key with the value parameter. Typically, the key will be a string of characters, though other types may be used. Value parameters may be of various types, and will typically be of a built-in type supported by the language.

Set? method 126 takes a key as a parameter, and returns a boolean value indicating whether a value has been set for the key specified in the key parameter. If there is a key- alue pair in meta-data variable 122 that corresponds to the key parameter, then set? method 126 returns true. Otherwise, set? method 126 returns false.

Unset method 128 takes a key as a parameter, and unsets an existing value for the key specified in the key parameter. This may be achieved by removing the key-value pair having the specified key from metadata variable 122.

Get method 130 takes a key as a parameter, and returns the value associated with that key in the list of key-value pairs stored in meta-data variable 122. If the key specified in the parameter is not found in meta-data variable 122, get method 130 may return an error value, or throw an exception. Matches? method 132 takes an object of class

ComponentMetaData (or any subclass of ComponentMetaData) as a parameter, and returns a boolean value that indicates whether the parameter matches the ComponentMetaData object on which the method was invoked. In a preferred embodiment, matches? method 132 will return true if for each key in current object, a corresponding key in the parameter object has the same value. Otherwise, matches? method 132 will return false. Alternatively, the values being matched could be specified as regular expressions or ranges, as explained hereinabove with reference to FIG. 7.

Keys-to-Iterator method 134 returns an iterator over the keys in meta-data variable 122. This permits a user of an object of class ComponentMetaData to write code that uses meta-data in a loop that iterates over each key in the meta-data.

Referring now to FIG. 13B, the structure of ComponentSelector class 140 is. shown. ComponentSelector class 140 inherits from ComponentMetaData class 120, so that all of the methods and variables of ComponentMetaData class 120 are also present in ComponentSelector class 140. This inheritance relationship between ComponentMetaData class 120 and ComponentSelector class 140 is a convenience, but is not required for the design. It will be understood by one skilled in the art that the same results could be achieved without this inheritance relationship.

ComponentSelector class 140 is used for building a component selection specification, for locating matching components, as explained hereinabove with reference to FIG. 7. The meta-data variable 122 that is inherited from ComponentMetaData class 120 is used to specify a list of key-constraint pairs in objects of ComponentSelector class 140.

In addition to all of the variables and methods of ComponentMetaData class 120, ComponentSelector class 140 comprises location-hints variable 142, and add-location-hint method 144. Location-hints variable 142 stores a list of location hints that are used to specify locations that may be searched for a component that matches the constraints specified in the meta-data variable of an object of class ComponentSelector. The use of these location hints is described hereinabove with reference to FIGS. 7 and 9. Add-location-hint method 144 takes a location hint as a parameter, and adds the location hint to the list of location hints in location-hints variable 142. ComponentLoader class 150, shown in FIG. 13C, is an abstract class that is used for loading and binding components. As an abstract class, ComponentLoader class 150 specifies the interface that must be met by concrete implementation classes, rather than providing an implementation itself. Generally, an "object" of an abstract class, such as ComponentLoader class 150 will actually be an object or instance of a subclass of the abstract class that implements at least the interface specified in the abstract class.

For each component to be loaded, there will be an object of ComponentLoader class 150 (as explained above, this is really an object of a subclass) that loads that component. Additionally, an object of ComponentLoader class 150 contains some basic information on the component that it loads.

ComponentLoader class 150 includes component- id variable 152, which stores the unique ID of the component, component-name variable 154, which stores the name of the component, and meta-data variable 156, which is an object of ComponentMetaData class 120 that stores the meta-data for the component. ComponentLoader class also includes load-component method 158, which loads an instance of the identified component.

FIG. 13D shows the structure of ComponentLocator class 160. Like ComponentLoader class 150, ComponentLocator class 160 is an abstract class, that specifies an interface that must be satisfied by implementation classes.

Objects of ComponentLocator class 160 (these are actually objects of a subclass of abstract ComponentLocator class 160) are used to locate components in accordance with the present invention. ComponentLocator class 160 includes locate-components- with method 162, which takes an object of ComponentSelector class 140 as input, and returns a list of zero or more objects of ComponentLoader class 150, which are configured to load the components that have meta-data that matches the constraints specified in the ComponentSelector parameter, locate-components- with method 162 uses the methods of the present invention, as described hereinabove, to locate components having meta-data that matches the specified constraints.

Advantageously, by creating subclasses of ComponentLocator class 160 and ComponentLoader class 150, it is possible to build gateways to other distributed programming environments, such as CORBA or Microsoft's COM. By creating such subclasses, previously known component technologies, as well as component technologies that may be developed in the future may be integrated into a system that supports the component location and binding methods of the present invention.

While preferred illustrative embodiments of the present invention are described above, it will be evident to one skilled in the art that various changes and modifications may be made without departing from the invention. For example, if the methods of the present invention are not implemented in an object- oriented programming language or system, the class definitions shown in FIGS. 13A - 13D would not be applicable, and the methods shown in those figures would be replaced by similar procedures or functions. It is intended in the appended claims to cover all such changes and modifications which fall within the true spirit and scope of the invention.

Claims

What Is Claimed Is:

1. A method of building a component for use on a computer, the method comprising: associating a collection of meta-data with component content, the collection of meta-data comprising a plurality of meta-data items, including a name meta-data item, that stores a name of the component, an ID meta-data item, that stores a unique identifier of the component, and one or more arbitrary meta-data items, that permit any information related to the component to be stored as meta-data; and storing the collection of meta-data in a component index.

2. The method of claim 1, wherein associating a collection of meta-data with component content comprises associating the component content with a collection of meta-data wherein each meta-data item in the plurality of meta-data items comprises a key-value pair.

3. The method of claim 1, wherein storing the collection of meta-data in a component index _ further comprises storing the component in a component repository, the component repository containing the component index.

4. The method of claim 1, wherein storing the collection of meta-data in a component index comprises storing the collection of meta-data in a component index on a server that is accessible over a network.

5. The method of claim 1, wherein storing the collection of meta-data in a component index comprises storing the collection of meta-data in a component index that includes locations of the components .

6. The method of claim 1, wherein storing the collection of meta-data in a component index comprises storing the collection of meta-data in a component index that comprises a database.

7. A method of locating a desired component in a plurality of components, each component in the plurality of components comprising a collection of meta-data that includes a plurality of meta-data items, the method comprising: specifying a set of constraints; matching the set of constraints against the collection of meta-data for each component in the plurality of components to produce a set of matching components; and selecting the desired component from the set of matching components if the set of matching components is not empty.

8. The method of claim 7 wherein each metadata item in the plurality of meta-data items comprises a key-value pair, and wherein specifying a set of constraints comprises specifying one or more key- constraint pairs.

9. The method of claim 8, wherein matching the set of constraints against the collection of metadata comprises: for each key-constraint pair in the one or more key-constraint pairs, matching the key-constraint pair with a corresponding key-value pair in the collection of meta-data.

10. The method of claim 9, wherein matching the key-constraint pair with a corresponding key-value pair comprises matching a key of the key-constraint pair with a key of the key-value pair and matching a constraint of the key-constraint pair with a value of the key-value pair.

11. The method of claim 10, wherein matching a key of the key-constraint pair with a key of the key- value pair comprises determining that the key of the key-constraint pair is identical to the key of the key- value pair.

12. The method of claim 10, wherein matching a constraint of the key-constraint pair with a value of the key-value pair comprises determining that the constraint of the key-constraint pair is identical to the value of the key-value pair.

13. The method of claim 7, wherein selecting the desired component from the set of matching components comprises using one or more selection criteria to select the desired component.

14. The method of claim 13, wherein using one or more selection criteria to select the desired component comprises using one or more selection criteria chosen from a set of selection criteria consisting of: selecting the component having the highest version number; selecting the component having the latest release time; selecting the component having the latest compile time; and selecting the component according to whether the component was statically compiled or dynamically compiled.

15. The method of claim 7, wherein matching the set of constraints against the collection of metadata for each component in the plurality of components comprises matching the set of constraints against the collection of meta-data stored in a component index.

16. The method of claim 15, wherein matching the set of constraints against the collection of metadata stored in a component index comprises matching the set of constraints against the collection of meta-data stored in a component index of a process specific loaded component cache, which stores meta-data for components that have been loaded by a process.

17. The method of claim 15, wherein matching the set of constraints against the collection of metadata stored in a component index comprises matching the set of constraints against the collection of meta-data stored in a component cache of a shared component cache, that stores meta-data for components that are currently loaded by all processes executing in a runtime environment.

18. The method of claim 15, wherein matching the set of constraints against the collection of metadata stored in a component index comprises matching the set of constraints against the collection of meta-data stored in one or more locations identified in a location list.

19. The method of claim 18, wherein matching the set of constraints against the collection of metadata stored in one or more locations identified in a location list comprises matching the set of constraints against the collection of meta-data stored on one or more component servers that are accessible over a network.

20. The method of claim 15, wherein specifying a set of constraints further comprises specifying one or more location hints, and wherein matching the set of constraints against the collection of meta-data stored in a component index comprises matching the set of constraints against the collection of meta-data stored in one or more locations identified in the one or more location hints.

21. The method of claim 20, wherein matching the set of constraints against the collection of metadata stored in one or more locations identified in the one or more location hints comprises matching the set of constraints against the collection of meta-data stored on one or more component servers that are accessible over a network.

22. A method of determining a set of components to be bound by an object, the method comprising: collecting a set of dependencies for the components that are being imported by the object, each dependency in the set of dependencies comprising a set of constraints; analyzing the set of dependencies and the set of constraints associated with each dependency in the set of dependencies to determine a minimum set of components that will satisfy all constraints.

23. A computer system that locates a desired component in a plurality of components, each component in the plurality of components comprising a collection of meta-data that includes a plurality of meta-data items, the computer system comprising: a processor that executes programmed instructions; and a memory that stores programmed instructions and data, wherein the processor executes instructions that cause the computer system to: cause a specified set of constraints to be matched against the collection of meta-data for each component in the plurality of components to produce a set of matching components; and select the desired component from the set of matching components if the set of matching components is not empty.

24. The computer system of claim 23 wherein each meta-data item in the plurality of meta-data items comprises a key-value pair, the specified set of constraints comprises one or more key-constraint pairs, and the processor executes programmed instructions that cause the computer system to match the set of constraints against the collection of meta-data by matching each key-constraint pair in the one or more key-constraint pairs with a corresponding key-value pair in the collection of meta-data.

25. The computer system of claim 23, wherein the processor executes programmed instructions that cause the computer system to select the desired component from the set of matching components by using one or more selection criteria to select the desired component .

26. The computer system of claim 25, wherein the one or more selection criteria are chosen from a set of selection criteria consisting of: selecting the component having the highest version number; selecting the component having the latest release time; selecting the component having the latest compile time; and selecting the component according to whether the component was statically compiled or dynamically compiled.

27. The computer system of claim 23, wherein the computer system further comprises a storage system, the storage system storing a component index, and wherein the processor executes programmed instructions that cause the computer system to cause a specified set of constraints to be matched against the collection of meta-data by matching the specified set of constraints against a collection of meta-data stored in the component index.

28. The computer system of claim 23, wherein the memory further stores a component index, and wherein the processor executes programmed instructions that cause the computer system to cause a specified set of constraints to be matched against the collection of meta-data by matching the specified set of constraints against a collection of meta-data stored in the component index .

29. The computer system of claim 23, wherein the computer system is connected to a network, and wherein the processor executes programmed instructions that cause the computer system to cause a specified set of constraints to be matched against the collection of meta-data by sending the specified set of constraints to a component server connected to the network, the component server matching the specified set of constraints against the collection of meta-data.

30. A set of component handling classes in an object-oriented system, the set of component handling classes comprising: a component meta-data class, an instance of which is associated with each component, an object of the component meta-data class comprising a list of key- value pairs that contain component meta-data; a component selector class, an object of the component selector class comprising a list of key- constraint pairs, each of which stores a key and a constraint associated with that key; an abstract component loader class, an object of a subclass of the abstract component loader class containing data that identifies the component to be loaded, the subclass of the abstract component loader class comprising a method that causes an instance of an identified component to be loaded; and an abstract component locator class, a subclass of the abstract component locator class comprising a method that locates components matching the list of key-constraint pairs in a specified object of the component selector class, the method returning an object of a subclass of the abstract component loader class for each matching component.

31. A computer language comprising: a meta-data construct that is used to specify a plurality of meta-data items associated with a component, the plurality of meta-data items including one or more arbitrary meta-data items that are not predefined in the computer language; and an import construct that is used to specify a component to be located and bound based on matching one or more meta-data items listed in the import construct with meta-data items for components stored in a component repository.

32. The computer language of claim 31, wherein the meta-data construct specifies the plurality of meta-data items using a list of key-value pairs.

33. The computer language of claim 31, wherein the one or more meta-data items listed in the import construct include a key-value pair.

34. The computer language of claim 31, wherein the import construct includes a construct that permits a location hint to be specified, the location hint specifying a location that may be searched for a component that matches the one or more meta-data items listed in the import construct.

35. The computer language of claim 34, wherein the location hint comprises a Uniform Resource Locator (URL) .