Browse Prior Art Database

Distributed Object Activation and Communication Protocols

IP.com Disclosure Number: IPCOM000113216D
Original Publication Date: 1994-Jul-01
Included in the Prior Art Database: 2005-Mar-27
Document File: 4 page(s) / 174K

Publishing Venue

IBM

Related People

Banda, VP: AUTHOR [+6]

Abstract

Disclosed is a set of object activation and communication protocols for a distributed object-oriented system. The system provides location transparency and allows processes to access objects located in remote address spaces which may be located in the same or other host machines. The system conforms to a standard called Common Object Request Broker Architecture (CORBA) which is described in "The Common Object Request Broker: Architecture and Specification", published by the Object Management Group and X/Open.

This text was extracted from an ASCII text file.
This is the abbreviated version, containing approximately 41% of the total text.

Distributed Object Activation and Communication Protocols

      Disclosed is a set of object activation and communication
protocols for a distributed object-oriented system.  The system
provides location transparency and allows processes to access objects
located in remote address spaces which may be located in the same or
other host machines.  The system conforms to a standard called Common
Object Request Broker Architecture (CORBA) which is described in "The
Common Object Request Broker: Architecture and Specification",
published by the Object Management Group and X/Open.

      Distributed SOM (DSOM) is implemented using the protocols
disclosed in this article.  DSOM is an extension to the System Object
Model (SOM).  Whereas SOM is a single address space object model,
DSOM allows a client process to access a remote object using the same
interfaces used to access a local object.  DSOM transmits the request
from the client process to the process of the target object and
returns the results back to the client process.  See "SOMobjects
Developer Toolkit Users Guide" for additional information on SOM and
DSOM.

      The system protocols can be divided into four control flows.
They are bootstrapping communications with the server process,
activating the server process, creating objects in the server process
and invoking operations on objects in the server process.

      Fig. 1 illustrates bootstrapping communications with the server
process.  Upon activation or perhaps during processing, the client
process determines that it needs access to objects, in this case a
printer, which may be located on a separate host.  In the preferred
embodiment, every client process has a Distributed SOM Object
Manager, SOMD_ObjectMgr, which is responsible for locating servers
according to various attributes.  A typical attribute utilized by the
client process is object class, such as type of printer.  The client
process queries the SOMD_ObjectMgr for class LaserPrinter by a
somdFindAnyServerByClass call.  The SOMD_ObjectMgr then queries the
Implementation Repository to determine whether a server has been
registered which supports objects of the requested class.  The
Implementation Repository is a centralized database that provides
server information such as host name, program name and classes of
objects supported.  If such a server is found, the SOMD_ObjectMgr
constructs a proxy object in the client address space which
represents the SOMDServer object in the server address space.  The
SOMDServer object provides basic object services for the server
process.  At this point, there has been no determination whether the
server process is currently executing or not.  However, the client
process now has an interface to activate the server process (if
necessary) and invoke operations on objects in the remote process.

      In the preferred embodiment, a proxy object is built by
creating an instance of a class that inherits from a ge...