CSC/ECE 517 Fall 2010/ch6 6i CB

Introduction

CORBA is an acronym for Common Object Request Broker Architecture. It is a vendor independent architecture and infrastructure that computer applications use to work together over networks. A Corba based program from any vendor, on almost any computer, operating system, programming language can interact with a corba based program from any vendor on any computer, operating system, programming language. It uses IIOP protocol to form the communication between two Corba based programs.

Need for CORBA

The recent advances in the technology have resulted in evolution of many different computing architectures. In today's scenario interaction of computer applications in a distributed system is of prime importance. Allowing one computer to access application present on another computer is an example of need of a distributed system that manages these resources. The Common Object Request Broker Architecture is an effective resource in allowing interoperability of heterogeneous systems in a distributed systems. CORBA is emerging as a standard of distributed computing and has lot of advantages that make use of distributed computing.

CORBA Architecture

The Following picture depicts the major components in CORBA

ORB Core

In the OMA object model, objects provide services and clients issues requests for those services to be performed on their behalf. The purpose of ORB is to deliver requests to objects and return the results to the clients. The ORB services necessary to accomplish this are completely transparent to the client. Client need not know where on the network the object resides, how they communicate, how they are implemented etc. Before a client can issue a request to an object, he/she should hold a reference to that object. An ORB uses object references to identify and locate objects so that it can pass requests to them. As long as the referenced object exists, the ORB allows the object holder to request services from it. The Corba specifies two different ways in which client can issue requests to objects

  Static Invocation via Interface-Specific STUBS
  Dynamic Invocation via the ORB dynamic invocation interface DII

Regardless to which of these methods the client uses to make a request, the ORB locates the object, activates it and passes the request. The Object does not know whether the request came from a static stub or from a dynamic invocation interface. It just takes the request and delivers the output to the ORB.

Interface Definition Language

Even though an object reference identifies a particular object, it does not necessarily describe anything about the objects interface. Before an application makes use of an object, it should know what are all the services provided by that object. In CORBA object interfaces are defined in IDL. IDL is a declarative language, with syntax similar to c++. IDL provides basic data, constructed and template types. These are used in operation declarations to define argument types and return types. In turn operations are used in interface declarations to define the services provided by the objects. IDL also provides module construct that can hold interfaces, type definitions and other modules for name scoping purposes. Of all the types provided by IDL, interfaces are the most important. In addition to describing CORBA objects, they are also used to define object reference types. Operations can be declared to return object references and to take object references as arguments by simply using the interface names as follows :

interface MailMsg; interface Mailbox {

   MailMsg nextMessage();

};

In this example, a client of Mailbox object can use the return value of MailMsg operation to invoke operations on a MailMsg object, since the return value is an object reference.

Dynamic Invocation Interface

To invoke an operation on a CORBA object an application needs an object reference, the name of the operation and a list of the parameters. In addition the application must know whether the operation is one-way, what user-defined exceptions it may throw, any user-context strings which must be supplied, a `context' to take these values from and the type of the returned value. This information is given by the IDL interface declaration, and so is normally made available to the application via the stub code. In the DII this information is encapsulated in the CORBA::Request pseudo-object.

To perform an operation invocation the application must obtain an instance of a Request object, supply the information listed above and call one of the methods to actually make the invocation. If the invocation causes an exception to be thrown then this may be retrieved and inspected, or the return value on success.

Interface Repository

Another service supported by the object interface and hence all object references in the get_interface() operation. This operation returns an object reference to an interface definition that describes the Object's interface. The interface definition is stored in the interface repository which provides persistent storage for IDL interface declarations. The services offered by Interface Repository allow navigation of Objects inheritance hierarchy and provide description of all operations the object supports. Some of these services return references to other Interface Repository objects such as Operation Definition that describe operations and Exception definitions that describe user-defined exception types.

Interface repositories can be used for several purposes. Interface browsers can traverse Interface Repository information to help application developers locate potentially re-usable software components. ORB's could use them to check operation parameter types at run time. The primary function of the Interface Repository is to provide the type information necessary to issue requests using the dynamic invocation interface.

Object Adapters

This is where the Adapter Pattern comes into play. Objects written in a particular programming language need to interact with objects written in other languages. A basic object adapter provides the means by which various objects can interact with the ORB. For example it provides Object reference generation, Object method invocation, security, activation and deactivation of objects and implementations. Object Adapter can either choose to provide these services by delegating them to the ORB or it can provide them by itself. In any case Objects does not know about the differences between other objects as they interface only to the Object Adapter. Each ORB provides a basic object adapter. It supports objects implemented as separate programs. It is expected that most object implementations can work with Basic Object Adapter because it supports various object implementations.

Features

CORBA was designed by Object Management Group to provide an object oriented interoperability of applications in a distributed systems. The use of Object Oriented Design, analysis and design using CORBA allows for great re-usability across systems. Advantages of Object Oriented Features such as inheritance, encapsulation and dynamic binding are implemented in CORBA.