1
`
`GOOGLE-1019
`Google Inc. v. Micrografx LLC
`IPR2014-00532
`
`

`

`5,475,817
`Page 2
`
`01‘HER PUBLICATIONS
`
`“The Eden System: ATechnical Review”, G. T. Almes, et al.,
`IEEE Trans. on Software Engineering, vol. SE—ll, Jan.
`1985, pp.
`“Distribution and Abstract Types in Emerald“, A. Black, et
`al., IEEE Trans. on Software Engineering, vol. SE—13, Jan.
`1987, pp. 65—76.
`“The Eden Programming Language”, A. P. Black, Tech. Rep.
`85—09—01, Dept. of Computer Science, University of Wash-
`ington, Seattle, Wash, Sep. 1985(rev. Dec. 1985).
`“Supporting Distributed Applications: Experience with
`Eden”, A. P. Black, Tech. Rep. 85—O3~02, Dept. of Com-
`puter Science, University of Wash, Seattle, Wash, Sep.
`1985.
`“UIDs as Internal Names in a Distributed File System," P. J.
`Leach, et al, Proc. of the Symposium on Principles of
`Distributed Computing, Ottawa, Canada, Aug. 1982, pp.
`34—4].
`
`UNIX Programmer’s Ref. Manual, 4.3 BSD Virtual
`
`VAX—l] Version, Univ. of Calif., Berkeley, Apr. 1986, Sel.
`pp.(MAN pp on INETD,GETPROTOENT, GETSERVENT.
`SERVJp. PSlzfi—l4) Apr. 1986.
`“Request for Comments 1034: Domain Names—Concepts
`and Facilities", P. V. Mockapetris, 181 Network Working
`Group, Nov. 1987.
`E. Jul et al., ”Fine~Grained Mobility in the Emerald Sys-
`tem,” ACM Transactions on Computer Systems. vol. 6, No.
`1, (Feb. 1988): 109—133.
`
`“Object Data Manager,” IBM Technical Disclosure Bulletin.
`vol. 32, No. 10A (Mar. 1990): 55—57.
`A. Benkiran et al., “A Communication System Architecture
`for the Office," Proceedings Eighth Annual Joint Conference
`of the IEEE Computer and Communications Societies, vol.
`11, Apr. 23—27, 1989, 382—392.
`S. Blount, “Distributed Computing Is Demanding New
`Technologies,” Technology Review, vol. 10, No. 5. (Apr.
`1990): 21725.
`
`2
`
`

`

`US. Patent
`
`Dec. 12, 1995
`
`Sheet 1 of 4
`
`5,475,817
`
`.830
`
`550:4
`
`33:22
`
`5523
`
`6930
`
`5098.2
`
`8:83
`
`9.63262
`
`E30
`
`Sacco—2
`
`mmsiom
`
`3
`
`

`

`US. Patent
`
`Dec. 12, 1995
`
`Sheet 2 of 4
`
`5,475,817
`
`\
`
`Mochinel Egg
`
`MachineZ fl
`
`Object
`
`Object
`(sending
`object)
`
`DOMF
`
`DOMF
`
`Object
`(receiving
`object)
`
`.
`
`Objed
`
`rumime . runtime
`
`4
`
`

`

`US. Patent
`
`Dec. 12, 1995
`
`Sheet 3 of 4
`
`5,475,817
`
`
`030k3903030%
`
`02809:6
`
`\«xm
`
`332:30.2
`
`
`005.6%3000.3
`32c_o%cmn§mamm
`
`6.mm
`
`2.900003
`
`£20305
`
`\
`
`22030:0
`
`2-30003
`
`
`
`2.0000032.000003
`
`
`
`2.9032.3003
`
`
`
`
`
`\ILV_OO&MMOUOHQGEO—Egg“
`
`
`
`
`
`mmSon.389302233
`
`5
`
`
`
`
`
`
`

`

`US. Patent
`
`Dec. 12, 1995
`
`Sheet 4 of 4
`
`5,475,817
`
`Register-
`_______ -. _endpoims
`
`
`
`
`
`Runiime
`g:
`
`
`Genobj Process 55
`
`
`
`
`
`GeLclasanfo
`
`
`Class
`
`Expert {31
`
`
`
`
`393.319
`
`6
`
`

`

`1
`OBJECT ORIENTED DISTRIBUTED
`COMPUTING SYSTEM PROCESSING
`REQUEST TO OTHER OBJECT MODEL
`WITH CODE MAPPING BY OBJECT
`MANAGERS LOCATED BY MANAGER OF
`OBJECT MANAGERS
`
`This is a continuation of application Ser. No. 07I660,478
`filed on, Feb. 25. 199], now abandoned.
`
`BACKGROUND OF THE INVENTION
`
`“Distributed computing” is a well known concept in the
`field of computer processing. Basically, distributed comput-
`ing 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 com-
`puting 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 commu-
`nicate 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. Con-
`ceptually 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 charac—
`ters". “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)
`
`5,475,817
`
`2
`
`managing the persistent state of objects, (ii) mapping opera-
`tions 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 comput-
`ing 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 sys-
`tem. The management apparatus employs a location service
`for locating desired objects in system on behalf of requesting
`objects or processes (i.e. requesters). Arequestcr need not be
`coded to have any awareness of the location service (much
`less the details of the location service).
`
`the location service is automatically con-
`Specifically,
`tacted when a requester makes a request
`to a service—
`providing object i.e “target object”. The preferred embodi—
`ment 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 map-
`ping means.
`In accordance with one aspeet of the present invention a
`common generic interface allowing a common means of
`communication with and among the object managers, man-
`agers of object managers, object region managers and map-
`ping 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 inter-
`face 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 asso
`ciation as a group instead of individually. Further, preferably
`the object managers provide deactivation of processes in
`
`5
`
`10
`
`20
`
`25
`
`3O
`
`35
`
`40
`
`45
`
`50
`
`55
`
`60
`
`65
`
`7
`
`

`

`5,475,817
`
`3
`automatic response to the system needing resources.
`In accordance with another aspect of the present invention
`the management apparatus further employs means for scr-
`vicing a request for a target object independent of associa—
`tion 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 comput—
`ing 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 conse-
`quence, 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 diiferent views. The drawings are not nec-
`essarily to scale, emphasis instead being placed upon illus-
`trating the principles of the invention.
`FIG. 1 is a schematic diagram of an object oriented
`distributed computing system embodying the present inven-
`tion.
`
`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 distrib-
`uted 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. I 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 man-
`agement apparatus 15 of the present invention. By way of
`overview. apparatus 15 handles the following object behav-
`ior:
`
`(1) registers all existing objects 13 in system 11;
`(2) enables objects 13a to issue requests to other objects
`13b (that are potentially in ditferent 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
`
`5
`
`10
`
`15
`
`20
`
`25
`
`30
`
`35
`
`45
`
`50
`
`55
`
`60
`
`65
`
`4
`in the network. The object or process (i.e., requester 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 diflerent 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 sup-
`ported, including broadcast networks such as many local
`area networks (LANs) and connection—oriented networks.
`such as many wide area networks (WAN s).
`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 difi'erent 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 per-
`forming 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 cflicicntly on a stand—alone singlevuser 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 mecha-
`nism for issuing and delivering requests among objects 13.
`The communication services layer 19 enables requests to be
`delivered among objects by. among other operations, con—
`verting data representations when the requester object and
`the target object are on diflerent kinds of computers. Secu-
`rity 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 difierent 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 deac-
`tivation. 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
`
`8
`
`

`

`5
`
`6
`
`5,475,817
`
`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 what-
`ever 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 automati-
`cally 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 runt-
`ime 27 contacts location services 21 to find a target object
`13b and sends messages from object 13 to object 131) 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.
`
`10
`
`15
`
`20
`
`25
`
`30
`
`35
`
`45
`
`50
`
`55
`
`60
`
`65
`
`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 man—
`ager based on a different object model 24 as discussed in
`detaii 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 1312. 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 communi-
`cate 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 diiferent 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 opera-
`tion 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:
`
`9
`
`

`

`5,475,817
`
`7
`
`retumgtype
`Operation_ Namer
`objref_t
`type
`
`type
`
`):
`
`targetiobject.
`Pararnl,
`
`ParamN
`
`An opaque handle referred to as an objrefit is used to
`identify the object to which the request is to be sent (i.e.,
`target object). In the preferred embodiment, oberfit is a
`pointer to a system defined structure which is implementa-
`tion dependent. The internal structure of such handles are
`not visible or available to users of the system 11. Users of
`the system 11 create and delete objref_t handles through
`calls to the runtime library 27.
`Some parameters are conceptually passed by reference;
`that
`is,
`they have the status of output or inputvoutput
`parameters. The first parameter to all operations is a system
`defined object references to the target object
`that
`is to
`receive the request. If the method invoked by the call returns
`a simple value, that value is returned as the return value for
`the operation. If the method returns multiple values, those
`values are returned in the parameters to the operation which
`are capable of returning values. Also, all management appa-
`ratus 15 operations are defined to return a status value,
`which can be used to determine whether the operation
`succeeded. If the operation fails, the status value indicates
`the nature of the failure.
`An interface is a non-empty set of operations that are
`logically related and form a semantic unit. The management
`apparatus 15 makes the following requirement regarding
`interfaces: if an object class supports any operation in an
`interface, it must support all of the members of the set of
`operations that constitute that interface. Further, each inter-
`face is identified by an interface identifier that is assigned by
`the implementor who originally designed the interface.
`A method is the code that implements an operation. For a
`given operation that code may vary from one object 13 to
`another because of differences in computer architecture or
`for other reasons. An operation is used to specify the action
`that is to be performed on an object 13. A request made of
`an object 13 is mapped to a method on that object 13. This
`mapping associates a particular implementation with the
`operation defined in an interface supported by the object 13.
`It is the responsibility of the class implementor to ensure that
`the method associated with the operation request performs
`the appropriate actions to give the intended semantics to the
`request.
`in response to an object
`According to the foregoing,
`operation call from a requester, the MOM of the target
`object’s object manager interacts with the object manager to
`forward the request to the target object 13b. The object
`manager 23 associated with the target object 131; receiving
`the operation call also ensures that the target object 13b is
`capable of receiving the request.
`The managers of object managers (MOMS) 29 are
`designed to allow the addition of multiple object managers
`23 over the life of the computing system 11. This is
`accomplished by a common generic interface supported by
`object managers 23 managed by a common MOM 29, such
`that the MOM 29 is able to communicate with each object
`managers 23 without explicit knowledge of the object model
`on which the object manager is based. The exact way in
`which the MOM 29 and a particular object manager 23
`communicate is the same for any particular implementation
`
`8
`of the manager of object managers 29, but may vary from
`implementation to implementation.
`The separation of the managers of object managers
`(MOMS) 29 and the individual object managers 23 allows
`objects 13 with very different attributes to coexist within the
`computing system 11 without limiting the ability of those
`objects 13 to interoperate. The separation also allows the
`MOMS 29 to know about the communications services used
`throughout the system 11, while the individuai object manA
`agers 23 know the particulars of the objects 13 that are
`associated with them.
`
`Moreover, this splitting of knowledge allows the MOMS
`29 to receive requests for any type of object 13. In response
`to receipt of a request, the MOM 29 determines if the target
`object 13b of the request is one which is managed by one of
`the object managers 23 associated with that MOM 29. In
`turn, the individual object manager 23 of the target object
`i3!) ensures that the target object 13b is ready to receive the
`request. The object manager is able to accomplish this by
`having or aquiring specific knowledge of the target object
`13!) being managed. In one case, ensuring that a target object
`13b is ready to receive a request requires that the associated
`object manager 23 activate the target object 1317. This, in
`turn, requires that the associated object manager 23 know
`the execution model and persistent storage scheme used by
`the target object.
`The net effect of the foregoing separation of responsibility
`between the managers of object managers (MOMS) 29 and
`the individual object managers 23 can be restated as follows.
`The MOM 29 acts as a well known receiving point and a
`forwarding agent for requests, while the object managers
`associated with the MOM 29 act as the object model-specific
`activators and manipulators of objects 13b.
`To function in the distributed computing system defined
`by the management apparatus 15, objects 13 support certain
`operations. In the preferred embodiment, all objects 13
`support the following functions.
`
`l
`getiacu
`obijJ
`status_t
`
`are]
`
`J;
`
`object.
`“status
`
`The function getgacl returns an access control list associA
`ated with the object referred to by the parameter "object”.
`
`boolean
`set;acl(
`objref_t
`aclAt
`status_|
`
`);
`
`object,
`to_ar:1,
`*status
`
`list
`The function setiacl associates the access control
`referred to by to ac] with the object referred to by the
`parameter “object". The function returns the value “true" if
`the setting is successful, and “false" otherwise. Note that the
`access control list currently associated with the parameter
`“object" must allow the sender of the request the rights to set
`the access control list for the operation to be successful.
`
`10
`
`15
`
`20
`
`25
`
`3O
`
`35
`
`40
`
`45
`
`50
`
`55
`
`60
`
`65
`
`hoolean
`
`10
`
`10
`
`

`

`5,475,817
`
`10
`
` -continued
`set_class_id(
`object.
`objref
`t
`to_class,
`classidit
`*status
`statusit
`);
`
`
`
`objref_t
`ornLdup_objref(
`to_dup.
`objref_t
`*status
`status a t
`);
`
`The function set_class_fiid changes the class identifier asso-
`ciated with the object referred to by the parameter “object”
`to the value specified in to__class. The function returns the
`value “true” if the setting was successful; otherwise the
`function returns a value of “false".
`
`
`boolean
`intholncatiom
`of__objeet.
`objrefwt
`withmobjeet,
`cbjref ,
`t
`*status
`status_t
`);
`
`The function ing_colocation asks of the object referred to
`by of_object if it is colocated with the object referred to by
`with_ object. The function returns “true" if the objects are
`colocated; otherwise the function returns ‘Talse". Note that
`the sematics of colocation are dependent on the persistent
`storage mechanism and/or object manager associated with
`the objects.
`During runtime, calls or operation requests are processed
`as follows. The runtime library 27 is bound to all objects 13.
`It serves both as the departure point for sending requests and
`the final destination for receiving requests. As part of this
`function, runtime library 27 provides an interface to con-
`struct object references, which are basic entities in the
`Location Services 21. The runtime 27 also provides an
`interface to the Persistent Storage Manager, which allows
`objects to manage their persistent state with the aid of the
`default object manager 25 as discussed later.
`The sending and receiving of requests is transparent to the
`user of the system 11 and the writer of objects 13, or more
`accurately, classes of objects. Request
`transmission is
`defined by the internal runtime functionality and by the stubs
`(i.e., interface code fragments) generated by an interface
`compiler when it processes the class’s operation interfaces.
`However, three functions are exported from the runtime 27.
`The first function allows the comparison of two object
`reference handles to determine if they refer to the same
`object. The second function allows the creation of an object
`reference to a class object. The third function allows the
`destruction of an object reference handle.
`The first exported runtime function in the preferred
`embodiment is as follows:
`
`
`boolean
`omf objref,,equal[
`refl,
`nbjrefét
`ref2,
`objref_t
`*status
`status
`1
`);
`
`The function omf_objref__,equal returns the value “true” if
`the object reference handles of refl and ref2 each refer to the
`same object; otherwise the function returns the value “false”.
`The second exported runtime function in the preferred
`embodiment is as follows:
`
`The omf__ref,robjref call creates a duplicate of the object
`reference supplied by the parameter toridup. The resulting
`object reference can be given to other objects.
`The third exported runtimc function in the preferred
`embodiment is:
`
`
`void
`omffifi'ee_objref(
`to_l'nee.
`objreLt
`'status
`5111111571
`);
`
`The function omfafreeiobjrcf deletes from storage an
`object reference handle.
`Other functions employed in the runtime interface are as
`follows:
`
`
`
`objrefvt
`emficreatd
`objmclass,
`classidm
`group_with,
`objref_t
`in, _ tran