Data processing: database and file management or data structures – Database design – Data structure types
Reexamination Certificate
1999-02-01
2002-09-17
Robinson, Greta L. (Department: 2177)
Data processing: database and file management or data structures
Database design
Data structure types
C707S793000
Reexamination Certificate
active
06453320
ABSTRACT:
FIELD OF THE INVENTION
The field of the invention is distributed object technology; more specifically, the invention relates to managing the location, activation and invocation of objects in a distributed object environment including object request brokers.
BACKGROUND
The Common Object Request Broker Architecture (CORBA) of the Object Management Group (OMG) is a set of specifications defining a language-independent distributed object architecture including Object Request Brokers (ORBs) for transparently managing the details of making requests and receiving responses of remote objects. Details on CORBA, including the complete specification, may be had from the Object Management Group, 492 Old Connecticut Path, Framingham, MA 01701 (www.omg.org).
In order for CORBA object implementations to interact with CORBA ORBs, object adapters (OAs) are used. Object adapters provide a 'standardized interface for object implementations, but themselves communicate with, ORBs via vendor-specific interfaces. Object adapters are responsible for demultiplexing requests from remote clients and dispatching the requests to appropriate servant object implementations, activating and deactivating objects and generating object references among other functions.
ORB clients in the CORBA environment use Interoperable Object References (IORs) generated by servers to request operations on target objects. The CORBA specification describes a structural framework for CORBA IORs, comprising a set of profiles. Profiles may include a portion called the object key that may be included in client request messages to identify the target object of the request. The object key format is not specified by CORBA and may be opaque (not parsed or interpreted) to applications developers and to client side ORBs. Because they are used to locate and invoke objects in a distributed computing environment, implemented CORBA IOR profiles have conventionally included location information such as the computer host name or port number as well as an object identifier for locating and invoking the target object.
Shortcoming in earlier CORBA object adapter definitions led to the introduction of the Portable Object Adapter (POA) in CORBA 2.2. The Portable Object Adapter is described in Chapter 9 of the CORBA version 2.2 specification, and in a series of articles by Douglas C. Schmidt of Washington University and Steve Vinoski of IONA Technologies, Inc. appearing in SIGS C++ Report magazine beginning in October 1997, and in Advanced CORBA Programming with C++ by Michi Henning and Steve Vinoski (Addison Wesley Longman, 1999, ISBN 0-201-37927-9).
POAs may be either transient or persistent. Persistent objects in CORBA ((including objects implemented using persistent POAs) are objects whose lifetimes are independent of the lifetimes of any processes in which they are activated. Transient objects are objects whose lifetimes are constrained by the lifetimes of the processes in which they are created. In the context of a POA (and as used in this application), “persistence” refers principally to the a persistent object's persistence across multiple process activations. It does not necessarily imply persistent state (as, for example, objects in an object database have persistent state) and persistent POAs need not have persistent state.
Conventional CORBA systems use IORs that are not well suited to use with persistent CORBA objects that outlive the processes in which they are activated, or objects that may require changes to services provided or used to access them during their lifetimes, because such changes have typically required changes to the IORs for those objects. Clients holding such an IOR will find the reference invalid, or inefficient to use because additional services are required for invocations with the IOR. Conversely, the existence of such IORs limits the administrative flexibility of the system because trade-offs must be made between desired administrative actions and the risks posed by compromising existing IORs. Additional administrative burdens are imposed by the substantial configuration and address allocation requirements of conventional CORBA systems.
The present invention overcomes these and other limitations of conventional CORBA systems.
SUMMARY
Object migration is facilitated by a location service. References to objects are exported that contain the information needed to communicate with the locator rather than directly with the server in which they are implemented. The location service is configured to always listen for requests at the same set of addresses, which are advertised in these references. Servers then can listen for requests at addresses that are dynamically assigned each time a server program is executed, eliminating the need to administratively configure fixed addresses for each server, and allowing the server to migrate between hosts. When a server is executed, it sends its current address to the locator. When clients attempt to communicate with the object, they use the information in the exported reference to establish communications with the locator. The locator then returns the current server address to the client (referred to as location forwarding), enabling the client to communicate directly with the server.
In one aspect of the present invention, the location service is preferably provided by exchanging object references between the server and the locator. The server constructs a prototype object reference, referred to as a prototype direct IOR, that includes the information needed by a client to communicate directly with that server. The locator similarly constructs a prototype object reference, referred to as a prototype:indirect IOR, with the information needed to communicate directly with a location agent.
These prototype references are exchanged between the server and the locator. The server exports the objects it implements using object references constructed by inserting those objects identities into the prototype reference received from the locator. When the client sends a request to the locator, the locator extracts the target object's identity from the request, and inserts that identity into the prototype reference obtained from the server, and returns the resulting reference to the client.
The server and the location service may use different sets of plug-in transports and other services for communicating with client ORBs. For example, client ORBs communicating with the server using direct IORs may use plug-in transports or other services which need not be available to the location service. Similarly, client ORBs communicating with the location service may use plug-in transports or other services which need not be available to the server, and may use different security or quality of service Information.
In another aspect of the invention, scalability to large numbers of objects is preferably enhanced by maintaining location information for groups of objects, referred to as “endpoints”, rather than for individual objects. An object's identity is split into two portions: an endpoint identity and an object identity relative to that endpoint. In a preferred implementation, the locator maintains current location information for each endpoint by exchanging prototype references with the server for each endpoint. When the locator receives a request for a target object, it maps the endpoint identity portion of the object's identity to the information needed to generate the object reference to return to the client, and inserts the object identity that was receive from the client.
In another aspect of the invention, CORBA POA instances are treated as endpoints, and the POA is a unit of object migration. The fully qualified POA name is used as part of the endpoint identifier. Policy objects associated with the POA instance affect what transports and ORB services it supports, and the information needed by a client to use these transports and ORB services is then advertised in the “prototype” object reference generated for that POA and exchanged with the loca
Kukura Robert Allen
Salamone Julie Ann
Witham, Jr. Ronald Clarke
IONA Technologies Inc.
Pennie & Edmonds LLP
Robinson Greta L.
LandOfFree
Method and system for providing object references in a... 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 system for providing object references in a..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Method and system for providing object references in a... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-2840947