Object oriented distributed computing system processing request to other object model with code mapping by object managers located by manager of object managers

Abstract

An object oriented distributed computing system is provided. Processing means call a location service within automatically generated stubs in response to a request for a service provided by a particular object. The location service is automatically called on behalf of the requester to locate the target object when the request is issued. Multiple Object Managers reflecting multiple Object Models are permitted in the system. Programmers and users do not need to know the Object Model adhered to by an Object Manager. A request to any object in the system is independent of the Object Model of the sought object's Object Manager. A generic interface enables new Object Managers reflecting new Object Models to be easily added to the system. Availability of the target object is independent of association of the target object with a process at the time the request was issued. Deactivation of processes is automatically accomplished in response to the system needing resources.

Claims

We claim:

1. An object oriented distributed computing system supporting a plurality of object models, each object model being defined by the way the persistent state of the model's objects is managed and the way operations on the model's objects are mapped into code to perform the operations, said mapping into code being the execution model of the model's objects, comprising:

a first computer,

a second computer,

a manager of object managers located on the first computer,

a manager of object managers located on the second computer,

a plurality of object managers located on the first computer, each based on a different object model,

at least one object manager located on the second computer, based on an object model,

objects of one object model, including a persistent state and an execution model, communicating operation requests to objects of a different object model by making calls in the system, each request including (i) an object identifier indicating a target object and (ii) an indication of an operation desired to be performed by the target object, each object manager supporting operation and existence of objects associated with that object manager according to the object model of that object manager, and each manager of object managers communicating with respective associated object managers in a manner free of preprogrammed code in the operation call, of the respective object models of the object managers to locate objects to which operation requests are to be communicated, such that a request by a first object managed by a first object manager on the first computer to perform an operation on a second object managed by a second object manager on the same computer is communicated from the first object to the manager of object managers on the first computer and then to the second object manager, the manager of object managers on the first computer being responsive to the first object and (i) based On the second objects identifier but independent of the second object type and independent of object model of the second object manager, determines whether the second object is managed by the second object manager and (ii) communicates the request to the second object manager, the second object manager, in accordance with its object model, obtains the persistent state and execution model of the second object and therefrom activates the second object and delivers the request to the second object, and

a request by the first object managed by the first object manager on the first computer to perform an operation on a third object managed by a third object manager on the second computer is communicated from the first object to the manager of object managers on the second computer and then to the third object manager, the manager of object managers on the second computer being responsive to the first object and (i) based on the third objects identifier but independent of the third object type and independent of object model of the third object manager, determines whether the third object is managed by the third object manager and (ii) communicates the request to the third object manager, the third object manager, in accordance with its object model, obtains the persistent state and execution model of the third object and therefrom activates the third object and delivers the request to the third object.

2. The object oriented distributed computing system of claim 1 in which each manager of object managers uses a common interface to communicate with each of the object managers located on the same computer.

Description

BACKGROUND OF THE INVENTION

"Distributed computing" is a well known concept in the field of computer processing. Basically, distributed computing allows processes on different computers in a network of computers to communicate with each other and provide services for each other. The computers in the network may have distinct machine architectures and operating systems.

The most common paradigm of distributed computing is known as the "client-server model". Consumers of services i.e. clients, make requests of service providers i.e. servers.

Various disadvantages in client server distributed computing exists. For example, current systems require clients processes to be coded so as to explicitly acquire (or "know") the locations of servers they wish to use. Further, if a server changes location while a client is using it, the client must be coded so as to perform a relocation of the server. Without such relocation the client will fail in its attempt to communicate with the server.

Most systems also require a server to be active prior to any attempted use by a client. A client trying to use an inactive server will fail in its attempt to obtain the service it needs.

Other distributed computing systems either have no notion of computer programming entities called "objects", or require objects to conform to a particular object model dictated by the system. Because there is at most one object model in a given system and no common models across systems, such distributed computing systems are unduly limiting. That is, such systems are limited in their ability to incorporate new technology and to extend to problem domains for which the system was not originally designed.

As used herein an "object" is a programming entity comprising some state and a set of defined behaviors. The state is represented by data maintained by the object. The behavior is specified in terms of operations the object can perform. Operations are realized by executable code. Conceptually the data and the code are inextricably bound together in the object. Objects may be "persistent", that is they may continue to exist even though they are inactive or the computer on which they exist has failed or been turned off. Further, objects may issue requests for services to other objects as well as supply services.

As used herein "class" refers to an object's type and specifies what kind of object it is. For example, Garfield and Snoopy while distinct "objects" are both "cartoon characters". "Cartoon character" is the class of each. A different kind of entity say, the World Trade Center, would have a different class (in this case perhaps "building") .

As used herein an "object manager" is an entity which manages groupings of objects supporting each object's existence and operation.

Also, as used herein, "object model" is an abstraction of the activities a particular class of object manager performs and the way it performs them. These activities include (i) managing the persistent state of objects, (ii) mapping operations on objects into code.

According to the foregoing, improvements in distributed computing are needed.

SUMMARY OF THE INVENTION

The present invention provides a distributed computing system that solves the problems of prior art. In particular, the present invention provides an object oriented distributed computing system which, unlike other distributed computing systems, does not require clients of services to be coded so as to know or acquire the locations of service providers. Futher, this system, unlike other object-oriented computing systems, recognizes objects that conform to various object models.

In particular, the present invention provides management apparatus for an object oriented distributed computing system. The management apparatus employs a location service for locating desired objects in system on behalf of requesting objects or processes (i.e. requesters). A requester need not be coded to have any awareness of the location service (much less the details of the location service).

Specifically, the location service is automatically contacted when a requester makes a request to a service-providing object i.e "target object". The preferred embodiment employs processing means for calling the location service within automatically generated stubs. Further, the location service locates objects based on the identity of the object where each object has a unique identity in the system. This unique identity encodes an indication of the computer on which the object was created.

The location service comprises various kinds of entities in the system. There are Object Managers each of which supports the existence and operation of the objects that are associated with it; Managers of Object Managers, each of which manages a grouping of Object Managers; Object Region Managers each of which tracks the location of objects with respect to computers in the system. A distinct object region is defined for each different grouping of computers, where each region has its own Object Region Manager. To provide a mapping between computers and Object Region Managers the location service employs mapping means.

In accordance with one aspect of the present invention a common generic interface allowing a common means of communication with and among the object managers, managers of object managers, object region managers and mapping means is employed.

In addition, object managers are based on respective object models. Objects associated with an object manager based on one object model are able to transmit requests to objects associated with a respective object manager based on a different object model.

Further, in one embodiment there exists a generic interface supported by object managers managed by a common Manager of object managers such that the Manager of object managers is able to communicate with each of its object managers in a manner free of explicit knowledge of the respective object model of the object manager.

Preferably each object manager treats groupings of objects associated with it as respective equivalence classes. To that end, the object manager tracks object process association as a group instead of individually. Further, preferably the object managers provide deactivation of processes in automatic response to the system needing resources.

In accordance with another aspect of the present invention the management apparatus further employs means for servicing a request for a target object independent of association of the target object with a process at the time of the request. To that end, all objects in the system appear to be available for processing requests even though a given target object may not be associated with a process at the time of the request.

Said another way, an object oriented distributed computing system of the present invention provides computer means for implementing operations and data of a target object, in one process of the plural processes of the system, in response to a request to the target object. As a consequence, availability of each object is defined independent of the association of the object with a process at the time of the request.

BRIEF DESCRIPTIONS OF THE DRAWINGS

The foregoing and other objects, features and advantages of the invention will be apparent from the following more particular description of preferred embodiments of the invention, as illustrated in the accompanying drawings in which like reference characters refer to the same parts throughout the different views. The drawings are not necessarily to scale, emphasis instead being placed upon illustrating the principles of the invention.

FIG. 1 is a schematic diagram of an object oriented distributed computing system embodying the present invention.

FIG. 2 is a block diagram of object/process management apparatus of the present invention employed in the system of FIG. 1.

FIGS. 3a and 3b each illustrate object activation in the present invention.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

Illustrated in FIGS. 1 and 2 is an object oriented distributed computing system 11 embodying the present invention. The system 11 comprises a plurality of loosely coupled computers 37 which form a network. On each computer 37 their may be one or more processes 39 in which various objects 13 perform respective operations. The objects 13 in FIG. 1 reside in the same or different process 39 on the same or different computers 37 of the network defining the object oriented distributed computing system 11.

At the heart of the system 11 is an object/process management apparatus 15 of the present invention. By way of overview, apparatus 15 handles the following object behavior:

(1) registers all existing objects 13 in system 11;

(2) enables objects 13a to issue requests to other objects 13b (that are potentially in different address spaces and/or computers); and

(3) delivers the requests and manages their execution.

The apparatus 15 does not require that objects 13 be compiled or linked together before one may issue a request of the other. An object 13 may issue a request to any other object 13 in the system provided it has a reference to that object.

Further, the invention apparatus 15 supports distribution of objects 13 among processes in the system 11. An object or a process can issue requests to objects on other computers in the network. The object or process (i.e., requestor or client) issuing the request does not need to be aware on which computer the target object is to be found, or even whether the target object is on a different computer. The invention apparatus 15 determines location of the target object in an automatic manner on behalf of a client without explicit human coding of client calls to a location service (discussed later). Different kinds of networks can be supported, including broadcast networks such as many local area networks (LANs) and connection-oriented networks, such as many wide area networks (WANs).

In addition, the apparatus 15 supports heterogeneity. Different types of computers may be mixed in the network. The invention apparatus 15 manages any differences between the computers containing the object issuing the request (the sender) and the object executing the request (the receiver). A common problem occurs when two computers have different processors that represent data differently. Motorola 68xxx series processors and Intel 80xxx series processors, for example, store integers differently in memory. The invention apparatus 15 manages the translation of the parameters of the requests between the formats of the two computers when necessary.

The invention apparatus 15 also supports multiple user sessions simultaneously. The apparatus 11 can manage objects on a single user computer such as a personnel computer or single-user workstation. Equally, the apparatus 15 can manage objects on a multi-user computer. Objects managed by the apparatus 15 may simultaneously be performing services on behalf of several different users. The apparatus 15 contains a security mechanism to protect against unauthorized use of services.

Further, the apparatus 15 is scaleable. In the network of computers, each computer runs an implementation of the invention apparatus 15. At the low end, the apparatus 15 can function efficiently on a stand-alone single-user computer. At the high end, the apparatus 15 can operate efficiently on each machine in an entire network that includes all the computers of a large multinational corporation.

To accomplish the foregoing the invention apparatus 15 has a two layer structure. The lower layer is formed of communication services 19 which provide a uniform mechanism for issuing and delivering requests among objects 13. The communication services layer 19 enables requests to be delivered among objects by, among other operations, converting data representations when the requester object and the target object are on different kinds of computers. Security mechanisms are also provided to prevent unauthorized access to objects. The communications services 19 also isolates the rest of the management apparatus 15 and objects 13 from the effects of different network topologies, protocols and software.

An upper layer of the management apparatus 15 is formed of the object management services 17 which include object managers 23, 25 and a location service 21. Object managers 23, 25 provide services such as object activation and deactivation, and object class installation. The location service 21 enables the apparatus to determine a communication path to a particular object 13. Thus, the object management services layer 17 manages an object's life cycle (creation, instantiation, and deletion) and location.

In the preferred embodiment the communications services 19 and object management services 17 are implemented by a runtime library 27, object managers 23, manager of object managers 29 and location service 21 shown in FIG. 2. The runtime library 27 resides in the address spaces of the objects 13 being managed by the computing system 11 and can be thought of as part of all of those objects. The runtime library 27 provides a basic interface used by all objects 13 in communicating within the system 11. Preferably the runtime library 27 contains code that allows communication with the persistent storage manager (described later) and code that allows the creation of object references used by the location services 21.

The object managers 23 are responsible for directly managing objects 13, activating and deactivating objects, delivering messages to objects, and keeping track of whatever state is needed for those activities. To that end, each object 13 is associated with an object manager 23 such that different pluralities of objects are managed by different object managers. The present invention provides as least one default object manager 25 in the management apparatus 15. A minimal subset of the operation interfaces of the default object manager 25 define the services that must be provided by all other object managers 23. Following these interfaces and a common generic interface used by a manager of object managers 29 (discussed below), new object managers are allowed to be subsequently added.

Each object manager 23 is associated with a manager of object managers (MOM) 29. Also, associated with such MOM 29 is a default object manager 25. Each manager of object managers (MOM) 29 is responsible for receiving messages that are directed to objects 13 associated with the object managers 23 that it (the MOM) manages. Each MOM 29 is also responsible for finding the object manager 23 with which a given object is associated, thus the MOM 29 serves as the local clearing house for requests. Said another way, the MOM 29 is designed as a well known receiving point for requests coming in for any of the objects that are managed by any of the object managers 23 which are in turn managed by (associated with) the manager of object managers (MOM) 29.

The location services 21 are responsible for finding the current location of any object 13 within the system 11. These services 21 are used by the system 11 in an automatic manner and are completely hidden to programmers who are writing applications within the system 11 or users who are using objects 13 within the system 11. In particular, the present invention provides processing means for automatically calling location services 21 on behalf of the requesting object (or process), in response to a request on a target object. As a result, requesting objects (or processes) do not have to be explicitly coded to call the location services 21 as required in the prior art.

The runtime library and the manager of object managers (MOM) 29 operate in both the communication services layer 19 of management apparatus 15 and object management layer 17. In the communication services layer 19, the runtime library 27 handles the passing of messages from one object 13 to another, and the manager of object managers (MOM) 29 acts as the lowest level object location service. In the object management services layer 17 the runtime library 27 along with the set of object managers 23 deals primarily with the object lifecycle.

Communication from the objects 13 point of view occurs through the runtime component of layers 17, 19. The runtime 27 contacts location services 21 to find a target object 13b and sends messages from object 13 to object 13b as discussed next. It is noted that the location services 21 run on some computer or computers in the overall system 11. From the point of view of the object 13, however, those services 21 are not located on any particular computer 37. Hence, FIGS. 1 and 2 show these services 21 as existing but not located on a particular machine 37.

Referring to FIG. 2, the location services 21 employ a hierarchy of elements. As previously mentioned objects 13 operate in a process or processes 39 of a computer or different computers 37. A plurality or group of objects 13 are associated with an object manager 23 which is responsible for managing those objects 13. In turn, the object managers 23 are grouped and associated with a manager of object managers (MOM) 29. Each object manager 23 is based on a respective object model 24, there being any number of object models 24 in the system 11. Object managers 23 of different object models 24 are able to be managed by a common MOM 29 through a generic interface discussed later. In addition, objects associated with an object manager 23 based on one object model 24 are able to transmit requests to objects associated with a respective object manager based on a different object model 24 as discussed in detail below.

Further each MOM 29 is associated with an object region manager 31 as follows. Different object regions are defined by sets of computers 37 which are grouped together for administrative purposes. For each object region there is an object region manager 31. The role of the object region manager 31 is to map object references to a (possibly empty) set of manager of object managers (MOM) 29 that might know about target objects 13b. An object region manager 31 comprises a single database and a set of processes that allow inquiry into and manipulation of that database. Preferably, a logically single object region manager 31 is replicated within the region for purposes of high availability. Each region has its own distinct object region manager 31.

In the next level of the hierarchy of elements in location services 21 are meta object region managers 33. These managers map object references to the identifier of the appropriate object region manager 31 that knows about that object. Distinct meta object region managers 33 communicate with each other to allow location of objects 13 between object regions. Like the object region managers 31, each meta object region manager 33 comprises a single database and a set of processes which inquire into and manipulate that database. Each logically single meta object region manager 33 may be replicated. Each system has its own distinct meta object region manager 31.

on the terminal level of the hierarchy are sibling meta object region managers 35 which maintain a list of two or more distinct meta object region managers 33.

In the preferred embodiment, there is a common generic interface between the different entities of the foregoing hierarchy. The common generic interface allows a common means of communication with and among object managers 23, MOM's 29, object region managers 31 and mapping managers 33.

Interaction among objects 13 is by means of requests sent from one requestor (i.e., object or process) to a target object asking for some operation on the target object. Operation calls are the basic form of communication between objects 13 that reside in the framework defined by the management apparatus 15 of the present invention. Basically, an operation is a way to request that a target object supply some information, undertake some manipulation of its own state and/or make operations on other objects. An operation is defined by its call signature. The signature consists of a return type (possibly null), a list of parameter specifications and whether the operation is synchronous (the default) or asynchronous.

The management apparatus 15 of the present invention defines its operation calls to objects as all having the following syntactic form:

    ______________________________________
    return.sub.-- type
     Operation.sub.-- Name(
      objref.sub.-- t    target.sub.-- object,
      type               Param1,
       . . . ,
      type               ParamN
    );
    ______________________________________

    ______________________________________
    acl.sub.-- t
     get.sub.-- acl(
      objref.sub.-- t    object,
      status.sub.-- t    *status
    );
    ______________________________________

    ______________________________________
    boolean
     set.sub.-- acl(
      objref.sub.-- t    object,
      acl.sub.-- t       to.sub.-- acl,
      status.sub.-- t    *status
    );
    ______________________________________

    ______________________________________
    boolean
     set.sub.-- class.sub.-- id(
      objref.sub.-- t    object,
      classid.sub.-- t   to.sub.-- class,
      status.sub.-- t    *status
    );
    ______________________________________

    ______________________________________
    boolean
     inq-colocation(
      objref.sub.-- t    of.sub.-- object,
      objref.sub.-- t    with.sub.-- object,
      status.sub.-- t    *status
    );
    ______________________________________

    ______________________________________
    boolean
     omf.sub.-- objref.sub.-- equal(
      objref.sub.-- t       ref1,
      objref.sub.-- t       ref2,
      status.sub.-- t       *status
    );
    ______________________________________

    ______________________________________
    objref.sub.-- t
     omf.sub.-- dup.sub.-- objref(
      objref.sub.-- t      to.sub.-- dup,
      status.sub.-- t      *status
    );
    ______________________________________

    ______________________________________
    void
     omf.sub.-- free.sub.-- objref(
      objref.sub.-- t      to.sub.-- free,
      status.sub.-- t      *status
    );
    ______________________________________

    ______________________________________
    objref.sub.-- t
     omf.sub.-- create(
      classid.sub.-- t   obj.sub.-- class,
      objref.sub.-- t    group.sub.-- with,
      tid.sub.-- t       in.sub.-- trans,
      status.sub.-- t    *status
    );
    ______________________________________

    ______________________________________
    boolean
     omf.sub.-- delete(
      objref.sub.-- t    to.sub.-- delete,
      tid.sub.-- t       trans.sub.-- id,
      status.sub.-- t    *status
    );
    ______________________________________

    ______________________________________
    boolean
     omf.sub.-- change.sub.-- identity(
      objref.sub.-- t      object,
      tid.sub.-- t         trans.sub.-- id,
      objref.sub.-- t      new.sub.-- id,
      status.sub.-- t      *status
    );
    ______________________________________

    ______________________________________
    FILE*
     psm.sub.-- create(
      objref.sub.-- t    location,
      tid.sub.-- t       trans.sub.-- id,
      objref.sub.-- t    *obj.sub.-- created,
      objref.sub.-- t    group.sub.-- with,
      classid.sub.-- t   obj.sub.-- class.sub.-- id,
      acl.sub.-- t       init.sub.-- acl,
      mode.sub.-- t      cr.sub.-- mode,
      status.sub.-- t    *status
    );
    ______________________________________

    ______________________________________
    FILE*
     psm.sub.-- open(
      objref.sub.-- t    object,
      tid.sub.-- t       trans.sub.-- id,
      mode.sub.-- t      open.sub.-- mode,
      status.sub.-- t    *status
    );
    ______________________________________

    ______________________________________
    boolean
     psm.sub.-- delete(
      objref.sub.-- t    object,
      tid.sub.-- t       trans.sub.-- id,
      status.sub.-- t    *status
    );
    ______________________________________

    ______________________________________
    objref.sub.-- t
     psm.sub.-- create.sub.-- link(
      objref.sub.-- t     to.sub.-- object,
      tid.sub.-- t        in.sub.-- trans,
      oid.sub.-- t        class.sub.-- id,
      acl.sub.-- t        init.sub.-- acl,
      status.sub.-- t     *status
    );
    ______________________________________

    ______________________________________
    acl.sub.-- t
     psm.sub.-- get.sub.-- acl(
      objref.sub.-- t    for.sub.-- object,
      status.sub.-- t    *status
    );
    ______________________________________

    ______________________________________
    boolean
     psm.sub.-- set.sub.-- acl(
      objref.sub.-- t    for.sub.-- object,
      acl.sub.-- t       new.sub.-- acl,
      status.sub.-- t    *status
    );
    ______________________________________

    ______________________________________
    boolean
     psm.sub.-- change.sub.-- identity(
      objref.sub.-- t      object,
      tid.sub.-- t         trans.sub.-- id,
      objref.sub.-- t      new.sub.-- id,
      status.sub.-- t      *status
    );
    ______________________________________

    ______________________________________
    boolean
     psm.sub.-- inq.sub.-- colocation(
      objref.sub.-- t       object,
      status.sub.-- t       *status
    );
    ______________________________________

    ______________________________________
    char*
     psm.sub.-- get.sub.-- path(
      objref.sub.-- t      object,
      status.sub.-- t      *status
    );
    ______________________________________

• Inventors
  Waldo, James H.; Arnold, Kenneth C.; Erdos, Marlena E.; Robinson, Douglas B.; Hoffman, D. Jeffrey; Smith, Lamar D.; Showman, Peter S.; Cannon, Michael J.; Seaborne, Andrew F.; McBride, Brian W.; Harrison, Brian D.;
• Assignee
  Hewlett-Packard Company (Palo Alto, CA)
• Published
  Dec-12-1995
• Current US Classes:
  719/316
• Application #
  159764
• International Classes
  G06F 015/16
• Field of Search
  395/200 395/500 395/600 395/650
• Examiner
  Kim; Ken S.
• US Patent References:
  4814970
  5008853
  5079695
  5088032
  5095522
  5126932
  5136712
  5146559
  5179715
  5261080