Process control methods and apparatus with distributed object management

• US 6,687,761 B1
• Filed: 02/19/1998
• Issued: 02/03/2004
• Est. Priority Date: 02/20/1997
• Status: Expired due to Fees

• Current Assignee: Invensys Systems Incorporated (Invensys PLC)
• Original Assignee: Invensys Systems Incorporated (Invensys PLC)
• Inventors: Collins, William J., Canna, Bruce S.
• Primary Examiner(s): Follansbee, John
• Assistant Examiner(s): BULLOCK JR, LEWIS ALEXANDER
• Application Number:
  US09/026,008
• Time in Patent Office: 2,175 Days
• Field of Search: 709/315, 709/316
• US Class Current: 719/315
• CPC Class Codes: G06F 2209/463 Naming
• CPC Class Codes: G06F 9/465 Distributed object oriented systems remote method invocation [RMI] G06F9/548
• CPC Class Codes: G06F 9/541 via adapters, e.g. between incompatible applications

Abstract

The invention provides improved digital data processing systems with distributed object management for use, e.g., in process control. These systems are of the type having servers and, more particularly, object request brokers (ORB'"'"'s) that route requests generated by one or more clients to implementation objects maintained by a server application. Routing is based on a binding table (or other such store) that identifies dispatching procedures, or “skeletons,” that invoke requested services on implementation objects specified in the requests. Such systems may be CORBA-compatible, though the improvements provided by o the invention are applicable to distributed object management systems having other architectures, as well. The improvements are characterized by the utilization of a single entry in the binding table (or other such store) to route requests to a plurality of different implementation objects, e.g., representing process control blocks and parameters, maintained by the server. In a related aspect, the improvements can be characterized as providing an CORBA-compatible ORB or, more particularly, (basic) object adapter (OA), that permits requests to be routed to implementations that are not listed in the binding table.

Claims

1. In a digital data processing system with distributed object management, the system having a server that routes requests generated by one or more clients to implementation objects that are maintained by a server, where the routing is based on an information store maintained by the server that identifies request dispatchers, the improvement wherein

the server utilizes an entry in the information store to route requests to a plurality of different implementation objects maintained by the server,

the server generates a first object reference (OR) corresponding to a first implementation object, the first OR including the first OID, and the server generates a second OR corresponding to a second implementation object, the second OR including the first and second OID'"'"'s, the second OID being generated as a function of the first OID,

a client generates a request that includes the first OID and the second OID, the client determining the first and second OIDs for inclusion in the request from a copy of the second OR,

the server is responsive to an information store entry matching a first OID in a request for applying at least a portion of the request to a first request dispatcher,

the first request dispatcher responds to at least a portion of a request applied thereto for applying at least a portion of the request to a second request dispatcher, the second request dispatcher being associated with the second OID included in that request,

the second request dispatcher responds to at least a portion of the request applied thereto by invoking a requested service on an implementation object identified by the second OID included in that request.

2. In a system according to claim 1, the improvement wherein at least selected requests include an identification of the second request dispatcher.

3. In a system according to claim 1, the improvement wherein a plurality of requests for invocation of services on different respective implementation objects have the same first OID.

4. In a system according to claim 3, the further improvement wherein that same first OID is included in an information store entry identifying a first request dispatcher to which the server applies at least portions of those requests.

5. In a system according to claim 4, the further improvement wherein the first request dispatcher applies portions of the requests to second respective request dispatchers, each associated with the second OID included in the respective requests.

6. In a system according to claim 5, the further improvement wherein the second request dispatchers invoke requested services on respective implementation objects identified by the respective second OID'"'"'s included in the requests.

7. In a method for digital data processing system with distributed object management, the method utilizing a server that routes requests generated by one or more clients to implementation objects that are maintained by the server and that are identified in the requests, where the routing based on a binding table that identifies skeletons for invocation of requested services on the implementation objects, the improvement comprising

generating with the server a first object reference (OR) corresponding to the first implementation object, the first OR including a first object identifier (OID) corresponding to an addressable location of the first implementation object,

generating with the server a second OR, corresponding to a second implementation object, the second OR including the first and second OID'"'"'s, the server generating the second OR in response to a request for an accessor service of the first implementation object, the request identifying a type of the second implementation object,

storing in the binding table an identification of a skeleton associated with the first OID,

passing the second OR from the server to the client,

generating with the client at least selected requests including a first object identifier (OID) and a second OID, where the client determines the first OID and the second OID from the second OR,

utilizing a single binding table entry to route requests to the first and second implementation objects.