PRACTICAL-12

AIM: Case study of Real Time Distributed System: Corba. CORBA

We start our study of distributed object-based systems by taking a look at the Common Object Request Broker Architecture, simply referred to as CORBA. As its name suggests, CORBA is not so much a distributed system but rather the specification of one. These specifications have been drawn up by the Object Management Group (OMG), a nonprofit organization with over 800 members, primarily from industry. An important goal of the OMG with respect to CORBA was to define a distributed system that could overcome many of the interoperability problems with integrating networked applications. The first CORBA specifications became available in the beginning of the 1990s. At present, implementations of CORBA version 2.4 are widely deployed, whereas the first CORBA version 3 systems are becoming available. Like many other systems that are the result of the work of committees, CORBA has features and facilities in abundance. The core specifications consist of well over 700 pages, and another 1,200 are used to specify the various services that are built on top of that core. And naturally, each CORBA implementation has its own extensions because there is always something that each vendor feels cannot be missed but was not included in the specifications. CORBA illustrates again that making a distributed system that is simple may be a somewhat overwhelmingly difficult exercise. Overview of CORBA The global architecture of CORBA adheres to a reference model of the OMG that was laid down in (OMG, 1997). This reference model, shown in Fig., consists of four groups of architectural elements connected to what is called the Object Request Broker (ORB). The ORB forms the core of any CORBA distributed system; it is responsible for enabling communication between objects and their clients while hiding issues related to distribution and heterogeneity. In many systems, the ORB is implemented as libraries that are linked with a client and server application, and that offers basic communication services. We return to the ORB below when discussing CORBAs object model. Besides objects that are built as part of specific applications, the reference model also distinguishes what are known as CORBA facilities. Facilities are constructed as compositions of CORBA services (which we discuss below), and are split into two different groups. Horizontal facilities consist of general purpose high-level services that are independent of application domains. Such services currently include those for user interfaces, information management, system management, and task management (which is used to define workflow systems). Vertical facilities consist of high-level services that are targeted to a specific application domain such as electronic commerce, banking, manufacturing, etc.

Page No:

The global architecture of CORBA. Object Model CORBA uses the remote-object model that we described in Chap. 2. In this model, the implementation of an object resides in the address space of a server. It is interesting to note that the CORBA specifications never explicitly state that objects should be implemented only as remote objects. However, virtually all CORBA systems support only this model. In addition, the specifications often suggest that distributed objects in CORBA are actually remote objects. Later, when discussing the Globe object model, we show how a completely different model of an object could, in principle, be equally well supported by CORBA. Objects and services are specified in the CORBA Interface Definition Language (IDL). CORBA IDL is similar to other interface definition languages in that it provides a precise syntax for expressing methods and their parameters. It is not possible to describe semantics in CORBA IDL. An interface is a collection of methods, and objects specify which interfaces they implement. Interface specifications can be given only by means of IDL. As we shall see later, in systems such as Distributed COM and Globe, interfaces are specified at a lower level in the form of tables. These so-called binary interfaces are by their nature independent of any programming language. In CORBA, however, it is necessary to provide exact rules concerning the mapping of IDL specifications to existing programming languages. At present, such rules have been given for a number of languages, including C, C++, Java, Smalltalk, Ada, and COBOL. Given that CORBA is organized as a collection of clients and object servers, the general organization of a CORBA system is shown in Fig.

The general organization of a CORBA system. Underlying any process in CORBA, be it a client or server, is the ORB. The ORB can best be seen as the runtime system that is responsible for handling the basic communication between a client and an object. This basic communication consists of ensuring that an invocation is sent to the objects server and that the reply is passed back to the client. From the perspective of a process, the ORB offers only a few services itself. One of these services is manipulating object references. Such references are generally dependent on a particular ORB. An ORB will therefore offer operations to marshal and unmarshal object references so that they can be exchanged between processes, as well as operations for comparing references.

Page No:

Besides the ORB interface, clients and servers see hardly anything of the ORB. Instead, they generally see only stubs for handling method invocations for specific objects. A client application usually has a proxy available that implements the same interface as each object it is using. A proxy is a client-side stub that merely marshals an invocation request and sends that request to the server. A response from that server is unmarshaled and passed back to the client. Note that the interface between a proxy and the ORB does not have to be standardized. Because CORBA assumes that all interfaces are given in IDL, CORBA implementations offer an IDL compiler to developers that generate the necessary code to handle communication between the client and server ORB. Interface and Implementation Repository To allow the dynamic construction of invocation requests, it is important that a process can find out during runtime what an interface looks like. CORBA offers an interface repository, which stores all interface definitions. In many systems, the interface repository is implemented by means of a separate process offering a standard interface to store and retrieve interface definitions. An interface repository can also be viewed as that part of CORBA that assists in runtime type checking facilities. Whenever an interface definition is compiled, the IDL compiler assigns a repository identifier to that interface. This repository ID is the basic means to retrieve an interface definition from the repository. The identifier is by default derived from the name of the interface and its methods, implying that no guarantees are given with respect to its uniqueness. If uniqueness is required, the default can be overridden. Besides an interface repository, a CORBA system generally offers also an implementation repository. Conceptually, an implementation repository contains all that is needed to implement and activate objects. Because such functionality is intimately related to the ORB itself and the underlying operating system, it is difficult to provide a standard implementation. CORBA Services An important part of CORBAs reference model is formed by the collection of CORBA services. A CORBA service is best thought of as being general purpose and independent of the application for which CORBA is being used. As such, CORBA services strongly resemble the types of services commonly provided by operating systems. There is a whole list of services specified for CORBA, as shown in Fig. Unfortunately, it is not always possible to draw a clear line between the different services, as they often have overlapping functionality. Let us briefly describe each service so that we can later make a better comparison to services as offered by DCOM and Globe. The collection service provides the means to group objects into lists, queues, stacks, sets, and so on. Depending on the nature of the group, various access mechanisms are offered. For example, lists can be inspected element wise through what is generally referred to as an iterator. There are also facilities to select objects by specifying a key value. In a sense, the collection service comes close to what is generally offered by class libraries for object-oriented programming languages. There is also a separate query service that provides the means to construct collections of objects that can be queried using a declarative query language. A query may return a reference to an object or to a collection of objects. The query service augments the collection service with

Page No:

advanced queries. It differs from the collection service in that the latter offers various types of collections.

Overview of CORBA services There is also a concurrency control service. It offers advanced locking mechanisms by which clients can access shared objects. This service can be used to implement transactions, which are offered by a separate service. The transaction service allows a client to define a series of method invocations across multiple objects in a single transaction. The service supports flat and nested transactions. Summary The main component of CORBA is the Object Request Broker or ORB, which allows clients written in one language to invoke operations in remote objects (called CORBA objects) written in another language. CORBA addresses other aspects of heterogeneity as follows: The CORBA General Inter-ORB protocol (GIOP) includes an external data representation called CDR, which makes it possible for clients and servers to communicate irrespective of their hardware. It also specifies a standard form for remote object references. GIOP also includes a specification for the operations of a request-reply protocol that can be used irrespective of the underlying operating system. The Internet Inter-ORB Protocol (IIOP) implements the request-reply protocol over TCP. IIOP remote object references include the domain name and port number of a server.
Page No:

A CORBA object implements the operations in an IDL interface. All that clients need to know to access a CORBA object is the operations available in its interface. The client program accesses CORBA objects via proxies or stubs, which are generated automatically from their IDL interfaces in the language of the client. Server skeletons for CORBA objects are generated automatically from their IDL interfaces in the language of the client. The object adapter is an important component of CORBA servers. Its roles include activating and deactivating servants, creating remote object references and forwarding request messages to the appropriate servants. The CORBA architecture allows CORBA objects to be activated on demand. This is achieved by a component called the implementation repository, which keeps a database of implementations indexed by their object adapter names. When a client invokes a CORBA object, it can be activated if necessary in order to carry out the invocation. An interface repository is a database of IDL interface definitions indexed by repository IDs. Since the IOR of a CORBA object contains the repository ID of its interface, the appropriate interface repository can be used to get the information about the methods in its interface which is required for dynamic method invocations. CORBA services provide functionality above RMI, which may be required by distributed applications, allowing them to use additional services such as naming and directory services, event notifications, transactions or security as required.

Page No: