Dr. Miklós Bíró, András Micsik, Dr. Tibor Remzsô
MTA SZTAKI
H-1111 Budapest, Lágymányosi u. 11.
This paper gives an introduction to distributed object management. Objects and classes are explained, and usual relationships between classes are listed. Distributed object management systems provide services for object handling, request-communication and resource management. The Object Management Group is the biggest forum on object technology in the world. We look over their goals and activities. Their CORBA specification also gives an idea about distributed object management. The overview of two DOM products and our experiences conclude the paper.
Supported by OMFB 91-97-11-0005
During the last few years, the computer industry has been filled with news of the coming revolution in objectoriented (OO) software. The development in an OO environment dramatically cuts down the time and effort needed to complete an application. Now after OO technology revealed to be powerful on single machines or on small networks, the next step is to make objects work through large, heterogeneous networks. Computing environments of American and West European companies often include a complex patchwork of incompatible mainframes, minicomputers, personal computers and systems software. Enormous profit could be taken by simplifying the operation of such environments. Distributed object management (DOM) as a new class of OO technology is able to do this work.
The organization of this paper is as follows. In section 2 we quickly look over the fundamental concepts in OO programming. Afterwards we give an overview of desirable properties and usual functionality of a distributed object management system. This section is based on the article of R. S. Chin and S. T. Chanson [1]. Section 3 gives an introduction to the specifications evaluated by the Object Management Group, including the Object Model [4] and the Common Object Request Broker Architecture [2]. Further sources about OMG are [3,5,6]. Section 4 briefly outlines two DOM software, HyperDesk DOMS and Arjuna [7]. Finally in Section 5 we shoot a glance on our development work in the laboratory.
An object encapsulates state information or data, a set of associated operations that manipulate the data, and possibly a thread of control. There is no other way to examine or modify the state of an object than making requests on the operations of the object.
An object may or may not contain processes. If it contains processes, those processes are bound to that object and their activity is limited to servicing the requests made to that object, or to the maintenance of the object`s state. This is called the active object model. On the other hand, in the passive object model, processes execute within several objects during their lifetime. When a process makes an invocation on another object, its execution in the current object is suspended, and the process is mapped into the object space of the other object. After completing the invocation, the process returns to the first object and resumes execution.
Objects can be characterized by their relative size and the relative number of interactions they make with other objects. It is called the granularity of objects. Large-grain objects usually have few interactions with others, and make a lot of processing to service a request. These objects are obvious to use with the active object model. Examples for large-grain objects are an editor window, a single-user database or a spreadsheet. Systems can provide finer granularity than large-grain objects. Then medium and fine-grain objects are contained by large-grain and medium-grain ones, respectively. Medium and fine-grain objects are not worthy to own processes, and can cause big overhead in the program. The benefit of finer granularity is the consistent programming model. Examples for medium-grain object is a spreadsheet cell or a paragraph, and for fine-grain object an integer or a logical value.
Objects that differ only in their state or data, but have the same set of methods are grouped in a class. Reusability and errorsafeness inspire different relationships between classes. Inheritance means that a new class takes the methods and behaviour of an existing class as a starting point, that is the new class specifies only the changes with respect to the old class. Multiple inheritance occurs when a class inherits from more than one class. Another way of reuse is to encapsulate an object of another class into one object. In this case the encapsulating class ties looser to the implementation of the encapsulated class, the latter one can be easily modified unless its specification is changed. Subtyping can also be applied to classes. A subtype is a specialization or a refinement of the supertype. Operationally this means that any object of a subclass can be used in any context which expects an object of the superclass. Another rarely mentioned mechanism is delegation. This mechanism permits an object to delegate responsibility for servicing a request to another object. This differs from inheritance in that it can be class independent. The class does not determine the class and instance of the objects that are delegated by its own objects. All these relationships can be drawn as directed graphs. The properties of these graphs differ from system to system. One thing that makes the chaos even bigger is genericity, or parametrized classes. Generic classes can take classes from a given set as parameters, and they can generate useful structures based on different classes. In fact genericity can be solved using inheritance, but in the other way it is not true. Still the use of generic classes is very comfortable.
The behaviour and meaning of classes also show a big variety in programming environments and object models. Some systems treat classes like objects, so they can have methods and state information. The best example for this is SmallTalk. Other models claim the inverse of this; classes maintain no state and perform no methods, they exist only at compile time, while objects exist at execution time. The most popular OO languages fall into this category, like C++ and Eiffel. Older languages (e.g. ADA, Modula2) support objects as language feature, but they do not support any inheritance mechanism. These are called object based languages. Newer languages with inheritance mechanisms are called object oriented languages.
A distributed object management system is the marriage of an operating system and a programming environment, both object-based or object-oriented. This means that the system must give solutions for the following tasks:
object handling,
communication capabilities between objects,
and resource management.
Furthermore a distributed object management system must provide these features together with a distributed and decentralized computing environment. The environment spreads over several computers, which can be PCs, workstations of various type. The hardware can be very heterogeneous. This is already the case in many computing environments. The main idea is to make all the machines at one site work together. There can be more done than disk and printer sharing. All the processors and every piece of hardware can be combined together.
Users are not interested in the place of the computing or their files or any other details. If they have objects, in a DOMS they can create their objects, get them stored somewhere in the system, and after a while destroy them. In a DOMS one should be able to make requests to objects in a uniform way, whether the object is on another workstation or in secondary storage. This is location transparency. The system may decide on which machine it activates the object. The important things are to be able to find objects that provide the services we want, to be able to find our own objects, and to be able to make restrictions on the use of our objects.
An object is called persistent, if it is automatically stored in secondary storage and thus it is not destroyed after its use or due to a failure. Data integrity in a DOMS means that persistent objects are always in a valid state, that is unsuccessful termination of an operation does not spoil the state of the object.
In order to operate reliably, the system should have mechanisms to reveal the inavailability and failure of objects, and restore the normal state. Reliability advises that none of the computers should play such role in the system, that the failure of that machine could cause the whole system to stop.
Security issues are very important, since a user can access all machines on the network. One should be able to restrict the use of the objects that he created or owns.
The resources can be put fully under the control of the DOMS. It can balance processor loads and memory usage between machines. Large objects are especially suitable for distributing them on several machines, allowing concurrent execution.
This enables objects to be created, maintained and destroyed. Creating an object can be as simple as activating a menu and as compound as writing source code fulfilling a set of system dependent rules. Usually an object management system offers an object-based or object-oriented language and a programming interface for the system.
Typically all parts of the system, from the kernel to the applications are treated as objects. The identification of objects is needed to make references for an object. Security mechanisms can restrict the use of objects. Multiple access to objects is also an aspect which can hardly be avoided in a DOMS.
Last but not least an object should be made persistent. A persistent object has an image in secondary storage. With that image the object can be constructed and made to work by the system when it is requested by other objects. This is called the activation of the object. Persistence gives also a good way to solve fault tolerance. Persistent object failures can be repaired using the stable image. In some systems all objects are persistent, in other systems the owner or the creator of the object can make the object persistent, for example by inheriting persistency properties from a base class.
Besides persistence a DOMS may provide atomicity. The chain of invocations resulting from one request is called an action. A DOMS can provide atomic actions, which means that a unit of computing is indivisible from the programmer's view, it either completes successfully, or has no effect at all. Furthermore the effect of a successful action in a persistent object should be permanent, to avoid loss of computing results and information in case of smaller failures.
Other interesting issue is synchronization and serializability. Concurrently executing actions should be scheduled in such a way that the overall effect is as if they were executed sequentially in some order. This is serializability. The synchronization is needed to keep back actions from observing or modifying the state of an object that has been modified by another atomic action that has not completed yet.
Object replication mechanisms manage multiple copies of the same object on different workstations. This increases availability of the object and makes the system more tolerant to workstation failures.
When an action makes an invocation request, the system must locate the specified object, take the appropriate steps to invoke the specified operation, then possibly return the result.
A DOMS should provide location transparency so a client makes an invocation with a reference to an object, then the system determines which object was invoked and on which workstation it currently resides. The mechanism for locating an object should be flexible enough to allow objects to migrate from one workstation to another. Several such mechanisms exist, for example using name server objects or a cache/broadcast scheme.
The system-level invocation handling depends entirely on the object model of the system. In case of the active object model message passing is used. The parameters of the invocation are packaged into a request message. The server process in the invoked object accepts this message, unpacks the parameters and performs the method. The result is packaged into a reply message which is sent back to the client.
Direct invocation is used with the passive object model. A process will migrate from method to method and from object to object in the order of subsequent invocations of an action.
The most interesting part of invocation handling is detecting invocation failures. A mechanism is needed for both the client and the server to detect the failure of the other. The easiest to detect is when the server object cannot be found. If the client does not notice that its server has aborted, it can wait for indefinitely long time. If the client aborts and the server continues executing, it wastes system resources.
A DOMS like any other distributed operating system must give mechanisms to manage physical resources including memory, secondary storage devices, processors and workstations of the network.
Objects that are lost if the workstation on which they reside fails are said to be volatile. Persistent objects can survive the break-down of their workstations. These objects reside in secondary storage, while the modifications are done on their working copies which reside in memory. When a persistent object has no working copy, it is said to be inactive.
The managing of processor load can be done in two ways. With object scheduling an object is assigned to a processor before activation. Then the object will execute on that processor until deactivated. The assignment can be done explicitly by the user or implicitly by the system. The other way is object migrating, which permits object to be moved from one processor to another, in some cases even while they are in the middle of servicing an invocation. This mechanism attempts to reduce the loads on heavily loaded processors and to minimize the distance of cooperating objects so communication costs can be reduced.
Up to now several experimental DOM systems has been implemented at universities and laboratories. Some efforts were also taken in commercial software products to begin evolving DOM environments. The future is inevitably for DOMS. But the spread of DOM systems is not enough in itself, because these systems may also happen to be so heterogeneous and incompatible as personal computers today. The Object Management Group (OMG) is working toward a common goal: the development of a framework of specifications to maximize the portability, reusability and interoperability of commercial object-oriented software. The OMG membership lists nearly all the significant software or hardware companies in the world. Among the more than 250 names we can find IBM, DEC, NCR, HP, Canon, Apple as well as Borland, Symantec, SunSoft, Lotus or even Microsoft. Since 1990 OMG provides a reference architecture with terms and definitions upon which all specifications are based. This is called Object Management Architecture. This framework (OMA Guide) and other forthcoming specifications are publicly available, and the process of the specification is open and well-documented. Finally, OMG invites lively industry discussion via open forums, education and conferences.
The OMA Guide also contains an object model, which is used by all OMG-compliant technologies such as the CORBA. In section 2 it was revealed, how many opportunities should be cleared up and composed into an object model. This model is very simple, but contains a mechanism for extensions called components. While the Core Object Model serves as the common ground, components may add capabilities that are required for special systems, but not obliged to be supported by all systems. These components are grouped in profiles for technology domains, for example there can be an Object Database profile.
The Core Object Model is based on a small number of basic concepts: objects, operations, types and subtyping. Objects have identifiers (OIDs) to refer to them. The notion of type corresponds to our notion of class. Types describe the operations applicable to objects of that type. Types are arranged into a type hierarchy that forms a directed acyclic graph. The root of this hierarchy is called Object. There can be denotable values other than objects, like in C++ or in CORBA. These are called non-objects and have types, but their types have no hierarchy.
Each operation has a signature. The signature includes the operation's name, list of parameters, and list of return values, if any. There is a special parameter, the controlling parameter, that refers to the object on which the operation is to be executed. The argument passing semantics is pass-by-value. The interface of an object contains the operation signatures of the object`s type.
Subtyping and inheritance are coupled in the Core Object Model. If S is declared to be a subtype of T, then S also inherits from T. Inheritance is applied to all operations of the parent type.
The Object Management Architecture creates a very simple classification of objects and programs, dividing a distributed object environment into four parts.
The basic part of the architecture is the Object Request Broker which communicates requests between objects. With an ORB an object can construct a request, send it to another object using an object reference, and receive the results of the requests.
The second part contains Object Services, which manage the naming, lifecycle and persistence of objects, stores the interfaces and implementation of objects. Essentially it provides services for using and implementing objects.
The third part is called Common Facilities, it is a collection of general objects, useful in many applications.
Application Objects is the last part, the objects of an end-user application.
These parts are using each other in increasing order. Without the ORB objects are isolated from each other. Object Services are also implemented as objects and interfaces, so they use the ORB for communication. An object service may even use another object service, if it is allowed in the specification. The Common Facilities means common building blocks of applications and they can be built using the ORB and Object Services.
The increasing order also shows the flow of standardization. The specification of the ORB, called Common Object Request Broker Architecture (CORBA) is available since the end of 1991. The Object Services specification is in the Request for Proposal state. It will contain lower-level interfaces mostly important for developers. The Common Facilities specification will provide standard interfaces for applications, but there will not be any specification for Application Objects.
In a CORBA-compliant system installed objects are stored in two separate parts; their implementation is stored in the Implementation Repository, their interface is stored in the Interface Repository. The interface description of an object contains enough information for a client to make a request on the object. The Interface Description Language is used to describe the interfaces of objects.
From the viewpoint of the ORB Client and (Object) Implementation are distinguished. There exist several interfaces for both the Client and the Implementation to communicate with the ORB Core. Both the Client and the Implementation can use the ORB interface, which provide general services, and manages object references.
The Client can build requests dynamically with the Dynamic Invocation Interface, using the information of the Interface Repository. There is also a possibility for the Client to call stubs, which is a static and more comfortable way of making requests.
All requests arrive to the Implementation through an Object Adapter, which is an up-call interface. The Object Adapter is responsible for activating the implementation of the object and the object itself. The Implementation may provide so-called skeletons for its methods. The Object Adapter calls the skeleton of the appropriate method to service a request.
The Client needs only an object reference to make a request on that object. With the object reference it queries the interface of the object, creates and fills a parameter list, and then sends it to the ORB. The ORB Core finds the Implementation and delivers the request to the appropriate Object Adapter. If the object is foreign, it passes the request to the ORB or object management system which is the manager of the requested object.
A language mapping contains the mapping of ORB interfaces, stubs and skeletons to a particular programming language. The developer writes the interface of the object in IDL, and the implementation using the language mapping and the routines of the object adapter. Therefore the object is portable to all ORBs which provide the same language mapping and object adapter.
There are a number of ways how an Object Request Broker can be implemented. For example ORB can be provided as a basic service of the operating system or as a server and client programs or simply as a collection of libraries.
Now we are going to see how these specifications of the OMG support the three famous terms, namely portability, interoperability and reusability. These three goals are very close to each other. Each of them holds the essence that the effort to design, implement and operate a software should not be repeated somewhere else in a community. Portability means that fundamental assumptions about the objects of a system are supported across different software or hardware. With other words it is easier to move the software to another system than to reimplement it. In this sense the portability may hold for the design, the source code and the executable code of the object.
Reusability is very similar to portability. Many objects once written could be used in more than one application. This is natural inside the area of one particular OO programming language. In this case the object code is reusable. There could be cases when reusing of objects implemented in different programming languages and operating systems was possible. It can be done either by cross-compiling, or by making requests to the object (interoperating it), or just by reusing the design of the object.
Interoperability is the most ambitious objective of the three. This presumes runtime compatibility between different systems. If we stay in an OO environment, it means that one can perform invocations on objects of different systems probably residing on remote machines. Interoperability can be achieved at different levels. At the lowest level a protocol is enough for making and managing requests. At higher levels there can be common object formats or common object semantics.
A common object model like the one of the OMG ensures that the basic design of a large application will be portable to other systems. So the object model at this stage aims at design reusability and portability.
ORBs can achieve source code portability as well, to other ORBs supporting the same mapping for the programming language in which the source code is written. This is because object interfaces are defined in CORBA IDL, so they can be called through the standard ORB interfaces. How objects call and are called in the programming language is clearly the question of the language mapping. How ORB communicates the request to the implementation depends on an object adapter. Object adapters give the ORB the possibility to target particular groups of object implementations that have similar properties with interfaces tailored to them. So in fact the support of the same object adapters is also needed to source code portability. Therefore it is planned to be a few number of widely available object adapters, and one standard CORBA mapping for each programming language.
An ORB achieves interoperability in a sense that objects in an ORB can be used throughout the workstations that connected to the ORB. In addition by connecting ORBs objects will be able to service clients from different ORBs. On one hand the ORB establishes a protocol for making and managing requests, but this protocol works only in that ORB. To communicate requests between different kind of ORBs the protocols need to be translated. On the other hand the Interface Definition Language gives a common syntax and semantics for the object interfaces.
The OMG Object Model is the basis of the Interface Definition Language. The Object Model defines such fundamental things as object identity, types, classes, inheritance etc. So its role is to provide common object semantics.
The first software to implement an Object Request Broker was the Distributed Object Management System of HyperDesk. HyperDesk is a Data General spinoff that helped found the Object Management Group and was instrumental in the creation of the Common Object Request Broker Architecture. This is not the only product offering an ORB. Digital, IBM, HP and SunSoft are all working on CORBA-based software, but we have no information about these.
The HyperDesk DOMS solves problems of heterogeneous office environments. It enables users of Unix and Microsoft Windows environments to access each other's objects across a network. The system offers a set of basic object types. One can create new object types from these by modifying or subtyping any existing type. The major components of the DOMS are the object request broker, object services including persistent object storage, Windows and Unix clients that can communicate with the object request broker, programming tools and interfaces.
An object can request the execution of operations on other objects inside or outside the system. The ORB Engine is a process that handles requests from clients, and communicates with other ORBs, object databases or any other object managers. When the ORB Engine receives a request, it determines the manager of the requested object. If the Engine can manage the object itself, it locates the appropriate code for the requested operation and invokes the request. Otherwise it forwards the request to the object`s manager. The ORBAPI is the interface to send requests to the ORB Engine and to receive results.
The DOMS have several object services. The Authentication Service provides system security. The Location Service maintains a database of distributed objects. Object Adapters are used to create and manage object references and deliver parameters. The Object Storage gives the basis of the Interface and Implementation Repository.
Tools coming with the system include HD-DOE, a graphical user interface for browsing, creating and modifying objects, and HD-TSL, a scripting tool for testing.
The Arjuna distributed programming system was developed at the University of Newcastle upon Tyne. It is one of the newer systems which already supports inheritance. In fact the major services of the system are provided by a C++ class hierarchy. The system may contain several workstations, with or without disk. The disks are organized as object storage using Unix file system. An instance of the ObjectState class can store the state of any Arjuna object in a format that can be stored in Unix files and transmitted between workstations. Therefore an object can be activated on a remote machine. Arjuna allows multiple access to objects and multiple activation of an object on different nodes. Concurrency control is provided to implement serializability of atomic actions. Operations on remote objects are invoked with remote procedure calls. An underlying remote procedure call system manages the calls and detects failures.
The root class of the class hierarchy supports object activation, deactivation and recovery. User-defined classes are derived from the LockManager class which provides concurrency control. Instances of the AtomicAction class are used to automatically record locks, modifications and remote calls of an atomic action. Then the abort or commit can be performed on that action.
A remote object can be referenced by an object identifier which is opaque for the user. Objects can be searched using the information of name servers. One can fill parts of a node-class-objectname triple, and the name servers try to fill the rest and find the object.
Nowadays commercial systems begin to show more and more features of DOM. For example in Microsoft Windows applications and windows can be considered as objects. Communication between windows can happen in two ways; by sending messages to another window, or by the Dynamic Data Exchange (DDE) protocol. DDE is a facility for applications to share data. Our laboratory has extended the DDE protocol to work between applications on different PCs of the network. This application called NDDE was a move toward making Windows more distributed. A year after our project has completed, Microsoft released Windows for Workgroups which already contained a similar facility to NDDE.
Other efforts we made in implementing DOM facilities are coupled with New Wave, a Hewlett-Packard product. New Wave is a Windows software highly improving the object handling of Windows. New Wave provides an object storage and uniform handling of objects. We contributed to the development of the Black Hole, an object passing tool on network. Afterwards several applications were born based on the Black Hole, one of those to mention is Office Viewer. Office Viewer gave the possibility to a New Wave user to open a window on his desktop in which he could see the desktop of another user. Then that user could move objects between the two desktops by dragging and dropping icons.
[1] Chin, R. S. and Chanson, S. T., Distributed Object-Based Programming Systems, ACM Computing Surveys, March 1991
[2] The Common Object Request Broker: Architecture and Specification, Revision 1.1, OMG TC Document 91.12.1
[3] Dyson, E., Domain of objects: the Object Request Broker, Hotline on Object-Oriented Technology, June 1991
[4] Object Management Architecture Guide, OMG TC Document 92.11.1
[5] Object Services Architecture Revision 6.0, OMG TC Document 92.8.4
[6] Osher, H. M., Software Without Walls, Byte, March 1992
[7] Shrivastava, S. K., Dixon, G. N. and Parrington, G. D., An overview of the Arjuna distributed programming system, IEEE Software, Jan. 1991