Electrical computers and digital processing systems: multicomput – Computer-to-computer data routing – Least weight routing
Reexamination Certificate
2000-06-01
2004-06-15
Najjar, Saleh (Department: 2157)
Electrical computers and digital processing systems: multicomput
Computer-to-computer data routing
Least weight routing
C709S201000, C709S205000, C709S241000, C709S241000, C709S241000
Reexamination Certificate
active
06751646
ABSTRACT:
BACKGROUND OF THE INVENTION
1. Field of Invention
The invention relates generally to methods and apparatuses for implementing name services in distributed object systems. More particularly, the invention relates to methods and apparatuses for implementing CORBA compliant name services.
2. Description of Relevant Art
Name services are often implemented within distributed object systems to enable distributed objects to be readily identified. One type of a distributed object system which uses name services includes a distributed object system that is defined under the Common Object Request Broker Architecture (CORBA) specification produced by OMG. Distributed object systems which use name services may be in the context of an Object Request Broker (ORB) implemented under the CORBA specification from the OMG, Revision 2.0, Revision 2.1, Revision 2.2 and Revision 2.3, all of which are incorporated herein by reference in their entirety. Specifically, the “CosNaming” module of the CORBA Services specification, as specified in the CORBA specification from the OMG, may be used to implement name services. For purposes of this application, programs compliant with CORBA Revision 2.3, 2.2 , and 2.1, by definition will be viewed as compliant with CORBA Revision 2.0. Unless otherwise specified, a generic reference to the CORBA Services specification will be presumed to be OMG's CORBA Services Revision 2.0. The components of the CORBA Services specification detailed above which address name services will be referred to hereinafter as the CORBA CosNaming Specification.
A name service, which may be associated with a name server, is typically arranged such that, when provided with a name, the name service associates the name with “something,” e.g., an object, an object reference, or a property. The association of the name with an object, for example, may either be transient or persistent. For a transient name service, the association between a name and an object generally disappears once the program which implements the name service terminates. Alternatively, for a persistent name service, the association between a name and an object is stored in a data file, and does not disappear once the program which implements the name service terminates. In general, the implementation of a name service often includes the implementation of a data structure such as a table (or hash table) to hold bindings between names and object references and, in some cases, properties. Such a data structure, in other words, may be used to associate names with object references, as well as properties. Such a data structure is maintained in a data store and accessed through a data store interface, where such data store may be persistent or transient.
Both U.S. Pat. No. 6,044,379 to Callsen, issued Mar. 28, 2000 for “Method and apparatus for efficiently implementing multiple storage mechanism for name services associated with a computer system” and U.S. Pat. No. 5,873,092 to Cheng, et al., issued Feb. 16, 1999 for “Information handling system, method, and article of manufacture including persistent, distributed object name services including shared properties” address efforts to improve naming services and provide detailed background information known to those of skill in the art regarding the operations of naming services. Both of these patents are incorporated herein by reference.
A typical implementation of a name service includes a “main” table. Although the main table may take on a variety of different configurations, the main table is typically a look-up table, or a list, which associates names in a name column of the main table with references in a reference column of the main table. References in the reference column identify, or reference, objects which are associated with names. By way of example, name “X” is associated with reference “x.sub.p”, which is a reference to a specific object. As such, reference “x.sub.p” is essentially an object reference which identifies the specific object. A reference is also referred to as an object reference or simply a reference, which in a CORBA compliant system is typically a relatively extensive IOR. The use of a name service enables a name, such as name “X”, to be remembered, instead of reference “x.sub.p”, when access to the specific object is desired. By using a name as an index into the main table to identify an object, the overhead, and, hence, the complexity associated with locating objects can be reduced.
A look-up table, which is included as a part of a name service, may either be transient or persistent. For a transient name service, local look-up tables, i.e., look-up tables which were created locally during a process, are temporarily stored in volatile memory, and are not stored into a file. As such, when a program which implements the local look-up tables terminates, the local look-up tables, in addition to information contained in local look-up tables, is destroyed. Alternatively, for a persistent name service, the local look-up tables are stored into files, as for example files on a non-volatile memory, such as a disk. Hence, data contained in look-up tables associated with a persistent name service is not destroyed when the program which implements the look-up tables is terminated.
A name may generally be expressed as an array of name components. In a CORBA compliant system, each of the name components comprises a pair of strings (the id string and the kind string). In other words, although a name may be expressed as “/a/b/c/d” (or even “abcd”), when a name is to be processed, e.g., bound or resolved, the name is typically processed as an array of components [a, b, c, d], and for illustrative purposes will be referred to in this fashion. When the name [a, b, c, d] is being “looked up,” or resolved, using a name service, the components of the name are looked up sequentially. The first component of the name, i.e., “a,” is resolved first, while the last component of the name, i.e., “d,” is resolved last. For example, a name service implementation may include multiple look-up tables which may be used to identify a reference to an object that is associated with and, hence, may be identified by name [a, b, c, d]. Such a name service implementation could include a main look-up table which is used to associate a reference “a.sub.p” with a first component “a” of name [a, b, c, d].
Reference “a.sub.p” identifies a second look-up table in which a second component “b” of name [a, b, c, d] may be found. Second component “b” is associated with a reference “b.sub.p” which identifies a third look-up table. The third look-up table is used to find a third component “c” of name [a, b, c, d], which is associated with a reference “c.sub.p” that references a final look-up table. In this example, the final look-up table is the last in a chain of look-up tables associated with name service implementation. However, as will be appreciated by those skilled in the art, the number of look-up tables associated with a name is often dependent upon the number of components in the name.
The final look-up table associates, e.g., binds, component “d” of name [a, b, c, d] with a reference “O.sub.ptr”. In other words, when name [a, b, c, d] is traversed until only component “d” remains, component “d” may then be bound to reference “O.sub.ptr” which references an object which is associated with the overall name “abcd.” When the name service stores look-up tables, either in volatile memory or in non-volatile memory, the four tables are all stored. As will be appreciated by those skilled in the art, typically, either all or none of tables are stored. When all tables are stored, by way of example, the first table is either temporarily stored in volatile memory, such that the first table is destroyed when the program that implements the name service implementation terminates, or the first table is written into a file on a disk. In other words, for a transient name service, the first table is stored in volatile memory, whe
Chow Ivan
Daggubati Ratna K.
Lee Wing K.
Potluri Dora
Najjar Saleh
Sprint Communications Company L.P.
LandOfFree
Method and apparatus for implementing CORBA compliant name... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Method and apparatus for implementing CORBA compliant name..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Method and apparatus for implementing CORBA compliant name... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-3353141