CORBA IDL

CORBA IDL

These are preceded by definitions of two structs, which are used as parameter types in defining the methods. Note in particular that GraphicalObject is defined as a struct , whereas it was a class in the Java RMI example. A component whose type is a struct has a set of fields containing values of various types like the instance variables of an object, but it has no methods.

Parameters and results in CORBA IDL:

Each parameter is marked as being for input or output or both, using the keywords in , out or inout illustrates a simple example of the use of those keywords

The semantics of parameter passing are as follows:

Passing CORBA objects:

Any parameter whose type is specified by the name of an IDL interface, such as the return value

Shape in line 7, is a reference to a CORBA object and the value of a remote object reference is passed.

Passing CORBA primitive and constructed types:

Arguments of primitive and constructed types are copied and passed by value. On arrival, a new value is created in the recipient’s process. For example, the struct GraphicalObject passed as argument (in line 7) produces a new copy of this struct at the server.

Type Object :

Object is the name of a type whose values are remote object references. It is effectively a common supertype of all of IDL interface types such as Shape and ShapeList.

Exceptions in CORBA IDL:

CORBA IDL allows exceptions to be defined in interfaces and thrown by their methods. To illustrate this point, we have defined our list of shapes in the server as a sequence of a fixed length (line 4) and have defined FullException (line 6), which is thrown by the method newShape (line 7) if the client attempts to add a shape when the sequence is full.

Invocation semantics:

Remote invocation in CORBA has at-most-once call semantics as the default. However, IDL may specify that the invocation of a particular method has maybe semantics by using the oneway keyword. The client does not block on oneway requests, which can be used only for methods without results.

The CORBA Naming service

It is a binder that provides operations including rebind for servers to register the remote object references of CORBA objects by name and resolve for clients to look them up by name. The names are structured in a hierarchic fashion, and each name in a path is inside a structure called a

NameComponent . This makes access in a simple example seem rather complex.

CORBA pseudo objects

Implementations of CORBA provide interfaces to the functionality of the ORB that programmers need to use. In particular, they include interfaces to two of the components in the ORB core and the Object Adaptor

CORBA client and server example

This is followed by a discussion of callbacks in CORBA. We use Java as the client and server languages, but the approach is similar for other languages. The interface compiler idlj can be applied to the CORBA interfaces to generate the following items:

The equivalent Java interfaces – two per IDL interface. The name of the first Java interface ends in Operations – this interface just defines the operations in the IDL interface. The Java second interface has the same name as the IDL interface and implements the operations in the first interface as well as those in an interface suitable for a CORBA object.

The server skeletons for each idl interface. The names of skeleton classes end in POA , for example ShapeListPOA.

The proxy classes or client stubs, one for each IDL interface. The names of these classes end in Stub , for example _ShapeListStub\

A Java class to correspond to each of the structs defined with the IDL interfaces. In our example, classes Rectangle and GraphicalObject are generated. Each of these classes contains a declaration of one instance variable for each field in the corresponding struct and a pair of constructors, but no other methods.

Classes called helpers and holders, one for each of the types defined in the IDL interface. A helper class contains the narrow method, which is used to cast down from a given object reference to the class to which it belongs, which is lower down the class hierarchy. For example, the narrow method in ShapeHelper casts down to class Shape . The holder classes deal with out and inout arguments, which cannot be mapped directly onto Java.

Server program

The server program should contain implementations of one or more IDL interfaces. For a server written in an object-oriented language such as Java or C++, these implementations are implemented as servant classes. CORBA objects are instances of servant classes.

When a server creates an instance of a servant class, it must register it with the POA, which makes the instance into a CORBA object and gives it a remote object reference. Unless this is done, the CORBA object will not be able to receive remote invocations. Readers who studied Chapter 5 carefully may realize that registering the object with the POA causes it to be recorded in the CORBA equivalent of the remote object table.

The client program

It creates and initializes an ORB (line 1), then contacts the Naming Service to get a reference to the remote ShapeList object by using its resolve method (line 2). After that it invokes its method allShapes (line 3) to obtain a sequence of remote object references to all the Shapes currently held at the server. It then invokes the getAllState method (line 4), giving as argument the first remote object reference in the sequence returned; the result is supplied as an instance of the

GraphicalObject class.

Callbacks

Callbacks can be implemented in CORBA in a manner similar to the one described for Java RMI For example, the WhiteboardCallback interface may be defined as follows:

interface WhiteboardCallback { oneway void callback(in int version); };

This interface is implemented as a CORBA object by the client, enabling the server to send the client a version number whenever new objects are added. But before the server can do this, the client needs to inform the server of the remote object reference of its object. To make this possible, the ShapeList interface requires additional methods such as register and deregister, as follows:

int register(in WhiteboardCallback callback); void deregister(in int callbackId);

After  a client  has obtained a  reference to the  ShapeList  object and created  an instance  of

WhiteboardCallback, it uses the register method of ShapeList to inform the server that it is interested in receiving callbacks. The ShapeList object in the server is responsible for keeping a list of interested clients and notifying all of them each time its version number increases when a new object is added.

The architecture of CORBA

The architecture is designed to support the role of an object request broker that enables clients to invoke methods in remote objects, where both clients and servers can be implemented in a variety of programming languages. The main components of the CORBA architecture are illustrated in Figure

CORBA provides for both static and dynamic invocations. Static invocations are used when the remote interface of the CORBA object is known at compile time, enabling client stubs and server skeletons to be used. If the remote interface is not known at compile time, dynamic invocation must be used. Most programmers prefer to use static invocation because it provides a more natural programming model.

ORB core ◊ The role of the ORB core is similar to that of the communication module . In addition, an ORB core provides an interface that includes the following:

operations enabling it to be started and stopped;

operations to convert between remote object references and strings;

operations to provide argument lists for requests using dynamic invocation.

Object adapter

The role of an object adapter is to bridge the gap between CORBA objects with IDL interfaces and the programming language interfaces of the corresponding servant classes. This role also includes that of the remote reference and dispatcher modules. An object adapter has the following tasks:

it creates remote object references for CORBA objects;

it dispatches each RMI via a skeleton to the appropriate servant;

it activates and deactivates servants.

An object adapter gives each CORBA object a unique object name, which forms part of its remote object reference. The same name is used each time an object is activated. The object name may be specified by the application program or generated by the object adapter. Each CORBA object is registered with its object adapter, which may keep a remote object table that maps the names of CORBA objects to their servants.

Portable object adapter

The CORBA 2.2 standard for object adapters is called the Portable Object Adapter. It is called portable because it allows applications and servants to be run on ORBs produced by different developers [Vinoski 1998]. This is achieved by means of the standardization of the skeleton classes and of the interactions between the POA and the servants. The POA supports CORBA objects with two different sorts of lifetimes:

those whose lifetimes are restricted to that of the process their servants are instantiated in;

those whose lifetimes can span the instantiations of servants in multiple processes.

Skeletons

Skeleton classes are generated in the language of the server by an IDL compiler. As before, remote method invocations are dispatched via the appropriate skeleton to a particular servant, and the skeleton unmarshals the arguments in request messages and marshals exceptions and results in reply messages.

Client stubs/proxies

These are in the client language. The class of a proxy (for object oriented languages) or a set of stub procedures (for procedural languages) is generated from an IDL interface by an IDL compiler for the client language. As before, the client stubs/proxies marshal the arguments in invocation requests and unmarshal exceptions and results in replies.

Implementation repository

An implementation repository is responsible for activating registered servers on demand and for locating servers that are currently running. The object adapter name is used to refer to servers when registering and activating them.

An implementation repository stores a mapping from the names of object adapters to the pathnames of files containing object implementations.

Object implementations and object adapter names are generally registered with the implementation repository when server programs are installed.

When object implementations are activated in servers, the hostname and port number of the server are added to the mapping.

Interface repository

The role of the interface repository is to provide information about registered IDL interfaces to clients and servers that require it. For an interface of a given type it can supply the names of the methods and for each method, the names and types of the arguments and exceptions. Thus, the interface repository adds a facility for reflection to CORBA

Dynamic invocation interface

The dynamic invocation interface allows clients to make dynamic invocations on remote CORBA objects. It is used when it is not practical to employ proxies. The client can obtain from the interface repository the necessary information about the methods available for a given CORBA object. The client may use this information to construct an invocation with suitable arguments and send it to the server.

Dynamic skeletons

If a server uses dynamic skeletons, then it can accept invocations on the interface of a CORBA object for which it has no skeleton. When a dynamic skeleton receives an invocation, it inspects the contents of the request to discover its target object, the method to be invoked and the arguments. It then invokes the target.

Legacy code

The term legacy code refers to existing code that was not designed with distributed objects in mind. A piece of legacy code may be made into a CORBA object by defining an IDL interface for it and providing an implementation of an appropriate object adapter and the necessary skeletons.

CORBA Interface Definition Language

The CORBA Interface Definition Language, IDL, provides facilities for defining modules, interfaces, types, attributes and method signatures. IDL has the same lexical rules as C++ but has additional keywords to support distribution, for example interface, any, attribute, in, out, inout, readonly, raises. It also allows standard C++ preprocessing facilities.

IDL Modules

The module construct allows interfaces and other IDL type definitions to be grouped in logical units. A module defines a naming scope, which prevents names defined within a module clashing with names defined outside it.

IDL interface

An IDL interface describes the methods that are available in CORBA objects that implement that interface. Clients of a CORBA object may be developed just from the knowledge of its IDL interface.

IDL methods

The general form of a method signature is:

[oneway] <return_type> <method_name> (parameter1,..., parameterL) [raises (except1,..., exceptN)] [context (name1,..., nameM)]

where the expressions in square brackets are optional. For an example of a method signature that contains only the required parts, consider:

void getPerson(in string name, out Person p);

IDL types

IDL supports fifteen primitive types, which include short (16-bit), long (32- bit), unsigned short, unsigned long, float (32-bit), double (64-bit), char, Boolean (TRUE, FALSE), octet (8-bit), and any (which can represent any primitive or constructed type).

Attributes

IDL interfaces can have attributes as well as methods. Attributes are like public class fields in Java. Attributes may be defined as readonly where appropriate. The attributes are private to CORBA objects, but for each attribute declared, a pair of accessor methods is generated automatically by the IDL compiler, one to retrieve the value of the attribute and the other to set it. For readonly attributes, only the getter method is provided. For example, the PersonList interface defined in Figure 5.2 includes the following definition of an attribute: readonly attribute string listname;

Inheritance

IDL interfaces may be extended. For example, if interface B extends interface A, this means that it may add new types, constants, exceptions, methods and attributes to those of A. An extended interface can redefine types, constants and exceptions, but is not allowed to redefine methods. A value of an extended type is valid as the value of a parameter or result of the parent type. For example, the type B is valid as the value of a parameter or result of the type A.

interface A { }; 

interface B: A{ }; 

interface C {}; 

interface Z : B, C {};