Name service for transparent container objects6701382Abstract The invention relates to a software object, more particularly a software Name Service object providing facilities for supporting transparent container objects. The software container objects contain a group of software objects herein referred to as fine grain objects, the fine grain objects communicating with external objects through the container's interface. This invention permits objects in the distributed system to communicate with specific ones of the fine grain objects within containers without requiring the Name Service to store an entry for each fine grain object. This allows a reduction in the size of the data structures within the Name Service and an improved usage of system resources. The Name Service stores an entry for a given container object including a range of fine grain objects implemented within the given container. The Name Service also provides a module for addressing a fine grain object within a container through the use of a computed index that is transparent to the objects in the system. This invention further provides a method for reducing the number of entries in a Name Service object as well as a computer readable medium containing a Name Service object program. This invention is particularly useful in the context of the Common Object Request Broker Architecture (CORBA). Claims We claim: Description FIELD OF THE INVENTION
Persistent Name
Kind Identifier Index
User 555-1111 111
User 555-1224 224
User 555-1345 345
User 555-1894 894
User 555-1986 986
The persistent name allows objects to communicate with other objects in the network domain irrespective of the objects location in that domain. In general, to communicate with a software object, the location of that object in the network domain must be resolved into an object reference. The object reference is the software reference of the object. Amongst other information, the object reference may include information about the node on which the object is located or other information to help locate the object in the system. A Name Service unit resolves an object's persistent name into an object reference that can be used to communicate with that object. In a preferred embodiment, as shown in FIG. 9, the Name Service 950 includes an interface module 900, a data structure 902 and a set of functional modules 904. The interface 900 allows the Name Service to communicate with other objects in the system by providing input and output channels. The data structure 902 contains information relating to the mapping of persistent names with object references. The data structure permits the persistent name to be associated to a single (independent) object or to a range of objects as for designating containers. The set of functional modules 904 permits the manipulation of the data structure 902. For example, these modules allow adding a new entry in the data structure, removing an entry from the data structure, updating an object reference or other functions. In a preferred embodiment, the functional modules further provide facilities for the extraction of an index from a given persistent name. The Name Service is an entity that is located at a well-known location in the distributed system and keeps an entry for certain objects in the system. Upon initialization, each object in the software system may register with the Name Service 950 by sending its persistent name, object reference and other relevant information to the Name Service in the form of a registration message. Preferably, when an object is deactivated, the Name Service 950 updates its data structure 902 accordingly to remove the entry relative to the deactivated object. The Name Service 950 keeps track of the mode of operation of the object (active/inactive), its location in the system and may assign a unique identifier to each object. Most preferably, the Name Service keeps a list of the objects with their location and other parameters that may be queried by external entities. The Name Service should also be able to add an entry, modify a parameter in an entry or supply information about an entry. In a specific example, the Name Service data structure 902 can be a simple lookup table with a set of functions or methods 904 to interact with the table. When sending a message, an object may query the Name Service to obtain the object reference of the entity. In a typical interaction, an object in the system that queries the Name Service, herein referred to as a client, sends a message to the Name Service requesting the location of another object. The message contains the persistent name of the object sought. The Name Service interface 900 upon receipt of the message interacts with the functional modules 904. The functional modules 904 map the object reference to the persistent name by using the table. The Name service interface 900 then sends a reply message to the client, the message containing the object reference (or a pointer to the object reference) of the entity sought. The Name Service provides support for Container Objects. More specifically, for each entry in the data structure 902, the Name Service stores a Kind value, an Identifier range value and an object reference. The Kind field identifies the Kind of the object corresponding to the entry. The Identifier range, specified by lower and upper limits, identifies the Identifier range within the corresponding container. For Independent objects, the lower and upper limits of the range are equal. In a preferred embodiment, the Name Service functional modules 904 provide a module implementing an algorithm to resolve a specific Identifier into an index value. In a preferred embodiment, the Name Service includes a single index resolution algorithm for all the objects in the Name Service. In a preferred embodiment, the index resolution algorithm is an arithmetic operation or a series of arithmetic operations. In a specific example, the index resolution algorithm is a subtraction operation, the lower limit of the identifier range being subtracted from the identifier portion of the persistent name of the object being looked-up. In an alternative embodiment, the Name Service includes a set of index resolution algorithms, each algorithm of said set being associated to a respective Kind. A given algorithm may be assigned to more than one Kind without detracting from the spirit of the invention. In another alternative embodiment, when a container object registers with the Name Service, it sends the Name Service an index resolution algorithm or an identifier data element indicating a particular index resolution algorithm. An algorithm may be sent as executable code, for example in the form of a Java program. Alternatively an algorithm identifier is used to select an algorithm from a set of algorithms already accessible by the Name Service. In a preferred embodiment of the invention, the container object is assigned an object reference. The object reference of fine grain objects is the same as that of their container with their index value added on. In a preferred embodiment, the index used to identify an object within a container is small compared to the complete object reference. Optionally, to further reduce the overhead of storing object references, object references for each fine grain object within a particular container may be composed by storing the index value for the particular fine grain object, plus a pointer to a shared copy of the full object reference of the container. Therefore a single copy of the object reference can be stored for all the fine grain objects within a container. This single copy method is advantageous if an object reference is large compared with a pointer, as is commonly the case with CORBA object references. Objects operating in a software system making use of this invention each register their object reference and persistent name with the Name Service. In a preferred embodiment, the container object registers with the Name Service directly. When a container registers with the Name Service, it registers its object reference and the range of names that it contains. Each container owns a name range unique within the system, and may contain thousands of objects. Preferably, no two containers of the same Kind anywhere in a system may have overlapping Identifier ranges. An independent object registers a single name, which is in effect a range whose upper and lower limits are identical. An independent object's name should not overlap any registered name range. The Table below shows an example of the entries in the Name Service table for container objects and for Independent objects.
Object
Entry Reference
# Kind Identifier Range (pointer)
1 USER 555-0000; 555-0999 A452C67
2 USER 555-1000; 555-1999 B56345E
. . . . . . . . . . . .
K TERMINAL V01; V49 AFE5270
K + 1 TERMINAL V50; V99 BF35516
K + 2 PRINTER LAZER1; LAZER1 EEEEEEE
The container object includes a registration unit 376 designed to effect the necessary data exchange with the Name Service to complete the registration function. The registration unit 376 receives a registration message from the fine grain objects within the container as well as performs the registration functions of the container itself with the Name service. In a preferred embodiment, objects in the system attempt to register with the Name Service upon initialization. In a typical interaction, as shown in FIG. 6, a container 602 first initializes itself and sends a message 652 to the system 650 requesting that an interface be created for it. The system 650 receives the message, creates the interface and sends an acknowledgement message 654 to the container 602 along with an object reference associated with the interface created. The container 602 then sends a registration message 624 to the Name Service 600. The registration message 624 includes the persistent name of the container including the range of identifiers within the container. Optionally, the registration message may include an index resolution algorithm identifier for allowing the Name Service to select and algorithm. The Name Service 600 then acknowledges the registration 626. Fine grain objects are then initialized. A fine grain object 604 sends a message 660 to the container 602 requesting that an interface be created. In a specific example, object 604 is coded as if it is communicating with the system and its message 660 is in the same format as the container's interface creation message 652. However when initialized the object 604 is given an interface address belonging to the container rather than an interface address specific to the fine grain object. Preferably, the fact that a fine grain object is within a container is transparent to the fine grain object 604. In a specific example, to provide this transparency feature, the container 602 offers an interface similar in form to the system's interface used to create object interfaces. The container 602 returns to the fine grain object 604 the container's own object reference. In effect, this allows fine grain objects within a given container to use the container's interface. Following this, the fine grain object 604 attempts to register with the Name Service 600 by sending a registration message 608. The registration message includes the persistent name and the object reference of the fine grain object 604. This message 608 is placed within the outgoing message queue 610. When the message reaches the front of the queue, the outgoing processing interface 610 processes it. The processing interface recognizing that the message is for registration, intercepts this message and sends it to the registration unit which registers the fine grain object with the container object 612. Optionally, the outgoing message 608 is directly processed by the outgoing processing unit and the output queue is omitted from the container object. In either option, the effect is similar to that described above for interface creation. The code of the fine grain object 604 is written as if that object were an independent object registering with the system's Name Service, but in fact this registration is delivered to an interface of the container 602 which is similar in form to the system's corresponding interface. In a specific example, no change is required in the code of the fine grain object 604 in order to implement that object within a container rather than as an independent object. During the registration procedure 612, the container 602 creates a new entry in its data structure and assigns an index value to the object in order to allow incoming messages to identify the object by its index value. The container 602 then sends an acknowledgement message 614 to the fine grain object 604. Preferably, the message 614 contains the container's object reference to which is appended the index assigned to the fine grain object. Typically, the internal format of an object reference is opaque to objects using the object reference and therefore the fine grain object is not aware that its object reference has been modified by appending an index. This procedure is repeated for each fine grain object with a container. Alternatively the container may assign an index to a fine grain object when the container's registration unit receives message 660, in order that that the object reference returned in message 662 may comprise the container's object reference and the fine grain object's index. The container may use other methods to assign an index to a fine grain object without detracting from the spirit of this invention. The container object comprises a removal unit 380. When a fine grain object is deactivated, as shown in FIG. 10, the fine grain object 1006 sends a removal message 1008 to the Name Service. In a specific example, the message 1008 contains the persistent name and object reference values of the object to remove. Preferably, appended to this object reference in a manner transparent to the fine grain object is that object's index. The removal message 1008 is placed in the outgoing message queue 1014 and is intercepted by the container 1004. The container removal unit 380 removes the entry 1016 corresponding to the fine grain object from its data structure 378 and sends an acknowledgement message 1018 to the fine grain object 1006. When all fine grain objects have been removed from the container object 1004, the container object 1004 may be deactivated. In a typical interaction, the removal unit 380 of the container object sends a message 1020 to the Name Service 1002 requesting that its entry be removed. The Name Service 1002 locates the entry and removes it from its list of entries. It then sends an acknowledgement message 1022 to the container object 1004. The container 1004 receives the acknowledgement message 1022 and if all the other housekeeping activities are complete, it is deactivated. The removal unit 380 may not be present in certain embodiments of the present invention and the absence of this unit does not detract from the spirit of the invention. Once an object is registered, it may communicate with other objects in the system using the Name Service. When a message is sent to any fine grain object in a container, the system uses a two-part object reference. One part is a standard object reference, which the system manages and which identifies the container. The other is an index, which is managed by the container system and by the Name Service supporting fine grain objects. In a preferred embodiment, the index is embedded in the object reference and the use of the index is transparent to objects in the system. In the specific example of the CORBA system, this may require an extension of the CORBA run time system, but little or no change to the CORBA compiler or the main parts of the CORBA run time system. In a typical interaction, as shown in FIG. 4, an external object 400 sends a message 408 to the Name Service 402 requesting the object reference of an entity. The request message 408 contains the persistent name including the Kind and Identifier of the entity sought. The persistent name may be the name of a standalone object, or of an object in a container. The Name Service 402 receives the message 408 and looks up the object reference 410. In looking up the persistent name reference, the Name Service identifies the Kind of the object and checks if the identifier portion of the persistent name is in the Identifier range of any registered container object. If the object is within a container's range of identifiers, the name service calculates an index value for the object within its container using a pre-determined algorithm. In a specific example, for a standalone object the index value is zero. A specific example will better illustrate this process. An external object sends a message to the Name Service requesting the object reference of the object with the persistent name "USER; 555-1757". The Name Service looks up this reference by checking for each persistent name entry with a Kind "USER" to see if the identifier "555-1757" is in the range. A portion of the look-up table of the Name Service is shown below.
Entry Object
# Kind Identifier Range Reference
1 USER 555-0000; 555-0999 A452C67
2 USER 555-1000; 555-1999 B56345E
. . . . . . . . . . . .
K TERMINAL V01; V49 AFE5270
K + 1 TERMINAL V50; V99 BF35516
K + 2 PRINTER LAZER1; LAZER1 EEEEEEE
The Name Service finds that entry #2 satisfies the query. Following this, the Name Service applies an algorithm to the Identifier "555-1757" to determine its corresponding index. In a specific example, the algorithm is a simple subtraction of the lower bound of the range of identifier with the identifier being sought namely, (555-1757) minus (555-1000)=757=index. This index will be used to identify the particular fine grain object within the container. Following this, the Name Service 402 sends an acknowledgement message 412 to the external object 400 containing the object reference of the container object including an index value corresponding to the fine grain object sought. The external object 400 receives the object reference which includes the container's object reference and the index from the Name Service and sends a message 414 to the fine grain object using the container object reference with the index. In a specific example, the external object 400 is not aware that the persistent name it has supplied is the name of an object that is implemented within a container, nor is it aware of the presence of an index in the object reference returned. Thus as with the fine grain object itself, the existence of containers and their use does not require alteration in the coding of an external object which may from time to time communicate with objects that are implemented within containers. The interface of Container 404 receives this message in the usual way and places it in the incoming queue 416. When the message reaches the front of the queue, the message is processed by the container interface 416 processing. This processing may involve translating the message into a specific format, adding or removing certain items of information or other types of processing. In a specific example, containers are implemented with CORBA and the interface processing is performed in the usual CORBA interface manner. In a preferred embodiment, CORBA is aware of the existence of the container, since the container's interface is a CORBA interface, so CORBA delivers the message to the container. Preferably CORBA is not aware of the existence of fine grain objects within the container. The container is aware of the possible presence of an index in the object reference, and makes use of that index to locate the fine grain object using its data structure 378. Following this, the processed message 418 is delivered to the fine grain object 406 in the container corresponding to the index. The fine grain object 406 then processes the message 420. Preferably, a special index value may be reserved to allow the sending of messages specifically to a container rather than to any fine grain object within that container. Preferably this same special value may also be used as the index of an independent object. Messages to the container may be used by software which manages the operation of a system, for example to verify the number of fine grain objects present within a container. In a preferred embodiment of the invention, the container object provides a means for fine grain objects to send messages to external objects. In a typical interaction, as shown in a FIG. 5, to send a message, the fine grain object 506 first sends a locate message 508 to the Name Service 502. The locate message includes the persistent name of the external object to locate. The message 508 is intercepted by the container object and placed in the output queue 510. When the message reaches the front of the queue, it is processed by the outgoing processing interface. The processed message 512 is then sent to the Name Service 502. The Name Service processes the request 514 and returns an acknowledgment message containing the object reference including the index of the external object sought. The external object can be either a fine grain object or an independent object. Preferably, in either case object 506 is not aware which kind of external object it has found. The acknowledgment message is directed to the fine grain object but is first intercepted by the container 504 which places the acknowledgment message in the input queue 518. When the message reaches the front of the queue it is processed by the incoming interface processing 518. The processed message 520 is then sent to the fine grain object 506. The fine grain object makes use of the received object reference and index to send a message to the external object 500. Again the message is intercepted by the container and placed in the output queue and processed by the outgoing processing when it reaches the front of the queue 524. Following this, the message 526 is transmitted to the external object 500. Preferably, the external object is not aware that the sender is a fine grain object when it receives the message. The external object 500 can return a reply to the sender 506 (provided that the message system comprises the general capability to reply to the sender of a message) without knowing that it is replying to a fine grain object. This capability is inherent in the incorporation of an index in each object reference that is exported from the container on behalf of a fine grain object within the container. A fine grain object within a container may also communicate with other fine grain objects that are within the same container. In a particular example, if the persistent name in message 508 is a name within the range of names belonging to the container object 504, then the object reference returned in message 520 comprises the object reference of container object 504 and an index which identifies a particular fine grain object within that container. When that object reference is used in sending message 522, the message system (such as CORBA) directs the message to the interface of container object 504 in the usual fashion. On arrival at that interface the message is processed in a manner similar to the message 414 in FIG. 4. Because the use of container objects is transparent to both the senders and receivers of messages, this special case of a message within the same container does not require any unusual handling anywhere in the system. In a variant of the invention, the output queue processing 524 may recognize that the container object reference in message 522 is the object reference of its own container, and may pass the message directly to the input queue processing of container 504, avoiding the processing involved in passing the message through a message system such as CORBA. This improvement is particularly advantageous in a system where many messages are local, for example in telephony where local calls are more common than long distance calls. The systems that can make use of the invention may be a single discrete computing apparatus or be of a distributed nature. In a distributed system, as shown in FIG. 7, different parts of a software application run on different computing machines that are interconnected to form a network. These physical machines, herein designated as nodes 700702704706, may reside in geographically remote locations, and communicate using a set of predefined protocols. The objects and software modules described in this specification operate on these nodes. FIG. 8, shows in block form a node 800 containing container objects 802804806 and Independent objects 808810812. The node may also contain the Name Service or a local Name Service which may be a copy of or a part of the main Name Service. Because there are far fewer containers than objects, it is practical in some situations for the Name Service to distribute the name ranges of all of publicly registered containers to every node in a cluster. This allows location of any named object in the cluster without sending an off-node lookup message resulting in reduced processing/waiting time. This preferred method of distributing registrations within the Name Service is an example of the benefits of registering containers rather than individual fine grain objects, but other implementations of a Name Service supporting named containers are possible without detracting from the spirit of this invention. The objects 802804806808810812 may communicate with each other or with objects in other nodes through the ATM link 814. The set of nodes 700702704706 are grouped into a cluster 708. A cluster is a group of nodes which are able to communicate with one another and the world outside the cluster. The nodes in the cluster may share resources and may perform functions in cooperation with one another. A set of clusters 708710712714 and 716 are in turn interconnected through an ATM network 718. The ATM network 718 may be a private or public network. Protocols such as TCP/IP, client/server architecture and message passing are all possible methods of achieving communication between objects in a distributed computing environment. In addition to these communication protocols a standard communication interface is used, such as those defined by the Object Management Group (OMG,) to allow access to the various objects in the system. For more information on distributed processing, the reader is invited to consult Operating Systems by William Stallings, Prentice Hall 2.sup.nd edition 1995, whose content is hereby incorporated by reference. The preferred embodiment of this invention uses the C++ programming language with a CORBA (Common Object Request Broker Architecture) interface. Other programming languages may be used in the context of the present invention and the use of such a language does not deter from the spirit of this invention. Although the present invention has been described in considerable detail with reference to certain preferred versions thereof, other versions are possible. Therefore, the spirit and scope of the appended claims should not be limited to the description of the preferred versions contained herein.
|
Same subclass Same class Consider this |
||||||||||