Distributed Object-Based System : CORBA (Common Object Request Broker Architecture )

Object Model CORBA follows an interface based approach to objects: Compared to the objects, interfaces play important role An object may implement one or more interfaces Interface descriptions can be stored in an interface repository, and looked up at runtime It has a traditional remote object model in which an object residing at an object server is remote accessible through proxies

Object Request Broker connects clients, objects, and services

Object Model The pre-compiled code of Proxy and Skeleton takes care of marshaling and un-marshaling involved in invocations and returning the associated results Dynamic Invocation Interface allows clients to construct invocation requests at runtime A request object represents one invocation on one method of a CORBA object.

To make two invocations on the same method, one need to create two request objects.
Object adapter is a server side code that handles incoming invocation requests.

To invoke a method, one need to have an object reference to the object that contains the method. Using the object reference a request object is created populating the required arguments to the created object. The created object sends the request, wait for the reply, and obtain the result from the request. The following steps are involved while invoking an interface dynamically:
Step Description 1 Load the CORBA interfaces into the Interface Repository. 2 Obtain an object reference for the CORBA object on which one want to invoke methods. 3 Create a request object for the CORBA object. 4 Send the DII request and retrieve the results. 5 Delete the request.

Using the Interface Repository with DII A CORBA client application can create, populate, and send requests for objects that were not known to the CORBA client application when it was built.
An application has not been linked with stub code which performs the remote operation invocation. Using the Classes associated with DII, applications may invoke operations on any CORBA object by determining the object's interface dynamically. To determine the information of the methods implemented by the remote object, the client application uses the Interface Repository It creates an object populating the information obtained to send the object request Thus the CORBA client application uses DII to send the requests, since it does not have client stubs for the interfaces.

Interface & Implementation Repositories Interface repository:

Database containing interface definitions implemented by the remote objects which can be queried at runtime
Whenever an interface definition is compiled at the server side, the IDL compiler assigns a repository identifier to that interface. Implementation repository:

Database containing the information related to the implementation of methods by the remote objects
Given an object reference, an object adaptor could contact the implementation repository to find out exactly what needs to be done.

Services in CORBA The ORB is the core element within the OMG Object Management Architecture. ORB also implements interfaces for lower level Object Services and higher level Common Facilities for building robust applications and systems. A legacy application, such as an accounting system, is wrapped in code with CORBA interfaces and opened up to clients on the network Some of the examples of CORBA interfaces are naming service for locating objects, event service for subscribing to and publishing messages, security, transaction support, and object license and metering etc

CORBA Object Services CORBA services commonly needed in distributed applications:

Naming Service Concurrency Service Event Service Logging Service Scheduling Service Security Service Trading Service: for locating a service by the type (instead of by name) Time Service: a service for time-related events Notification Service Object Transaction Service

Naming Service In CORBA, clients can use object names to obtain handles to objects sitting on remote servers. The name to object references are referred as name bindings The Naming Service provides the ability to bind a name to an object relative to a naming context. A naming context is an object that contains a set of name bindings in which each name is unique. To resolve a name is to determine the object associated with the name in a given context.

To invoke the remote object instance, the client first obtains its object reference. There are many ways to do this, but the easy ways include the Naming Service and the Trader Services

Naming service implementations can be application specific or be based on a variety of naming systems currently available on system platforms: An URL facilitates the localization of a resource exposed on the Web. e.g., abc.net.in means it is likely to be an Indian entity? A consistent and uniform naming helps processes in a distributed system to interoperate and manage resources. e.g., commercials use .com; non-profit organizations use .org Naming Services are not only useful to locate resources but also to gather additional information about them such as attributes

The CORBA Name Service provides: An implementation of the Object Management Group (OMG) Interoperable Name Service (INS) specification.

A CORBA server puts references to CORBA objects inside a naming service so that clients can query the naming service and obtain the object reference and then call operations on the CORBA objects.
Typically, a client queries the naming service once, then caches the object reference Naming services are typically arranged in a hierarchy so that names can be given context or scope. Object references which are mapped into an hierarchical naming structure is referred as a namespace

The naming service is available in two major versions: (1) The original CORBA Naming Service. The full name of an object, including all the associated naming contexts, is known as a compound name Naming contexts and name bindings are created using methods provided in the Naming Service interface (2) The CORBA Interoperable Naming Service (INS). This is an extension and revision of the original naming service. The semantics of certain operations are specified more precisely. A string format and a URL format are defined for names. New operations are declared in the interface.

Trading Services

Trading activities are described through a design pattern that represent the roles of importer, exporter and trader

The object in trader role supports a repository of offers. Each offer describes properties of an entity. The offers are produced by objects in exporter roles. When an exporter sends an offer for a trader to be stored, it is said to export. When an exporter requests an offer to be deleted, it is said to withdraw an offer.

The objects in importer roles make queries to the offer repository. The query and the response to the query form an interaction called import. The import request has a basic form that is similar to a database query: the request specifies criteria for selecting the offers to be included to the response. The objects that use the traded information are not necessarily the importers or exporters themselves. The clients and servers that use the information are therefore drawn as separate roles in the figure

The Java IDL

IDL is part of the Java 2 Platform

The Java IDL facility includes a CORBA Object Request Broker (ORB), an IDL-to-Java compiler, and a subset of CORBA standard services Java also provides a number of CORBA compliant facilities, including RMI over IIOP (Internet Inter-ORB Protocol), which allows a CORBA application to be written using the RMI syntax and semantics Key Java IDL packages provide interfaces and classes to map into Java programming languages, interfaces and classes which provides naming services for Java IDL Java IDL provides a set of tools needed for developing a CORBA application such as compiler and command line interface

Object Clients & Object Servers Object Servers: The server side of CORBA begins with the specification of an interface in IDL. IDL is an object-oriented declarative language used to specifying server interfaces. It is not a programming language.

An IDL compiler is used to generate a server stub, also referred to as a skeleton, which gets linked to the server program.
Server implementations are not written in IDL. Rather, IDL interface descriptions are mapped to a programming language for implementing the server. In IDL an interface corresponds to a class. The server stub provides static interfaces to call methods of an object implementation. It un-marshals parameters that come from the client via the ORB

interface Account {attribute float balance; readonly attribute string owner; void makeDeposit(in float amount, out float newBalance); void makeWithdrawal(in float amount, out float newBalance);} A property is defined as an attribute, which is mapped by the IDL compiler to get and set methods; Declaring an attribute is logically equivalent to declaring a pair of accessor functions, one to read the value of the attribute, and one to write it A read only attribute maps to a get method only. An operation corresponds to a method; parameters must be specified as in & out.

An IDL compiler is used to generate a server stub, also referred to as a skeleton, which gets linked to the server program.
The server stub provides static interfaces to call methods of an object implementation. The IDL compiler also generates a native language interface for implementing the server, as well as a client side stub.

CORBA also supports a dynamic skeleton interface (DSI), which is a run-time binding mechanism for creating server interfaces on the fly. An example where this could be used is for a schema mapper that dynamically generates implementation classes from a source schema such as a relational database, and then exports IDL interfaces for the classes using the DSI. The Dynamic Skeleton Interface (or DSI) allows applications to provide implementations of the operations on CORBA objects to construct a request dynamically. It is the server-side equivalent of the Dynamic Invocation Interface.

An important component of the ORB is the object adapter, which is responsible for managing server objects and related object references. It uses the CORBA implementation repository to locate a server name, identify the activation mode, and determine the access permissions. Server activation modes define the run-time characteristics of a server, including whether a server process can contain one or more objects and if multiple clients are permitted to access the same object.

According to the CORBA specification, an object adapter is responsible for the following functions: Generation and interpretation of object references Method invocation Security of interactions Object and implementation activation and deactivation

Mapping object references to the corresponding object implementations

Registration of implementations

Object Adapters

An object adapter assists an ORB in delivering a client request to an object implementation

When an ORB receives a clients request, it locates the object adapter associated with the object and forwards the request to the adapter The adapter interacts with the object implementations skeleton, which performs data marshalling and invokes the appropriate method in the object The Portable Object Adapter, or POA, is a particular type of object adapter that is defined by the CORBA specification

An object adapter that is a POA allows an object implementation to function with different ORBs

Server Side Process: 1) Specify the server interface in IDL. 2) Run the IDL description through an IDL compiler, which generates a native language interface, server stub, and client stub. The server and client stubs can be for different programming languages.

During this step, the IDL compiler can optionally write a compiled interface description to the interface repository.
3) Implement the server.

Server Side Process: 3) Compile the server program and link in the server stub that was generated by the IDL compiler. The result is an executable server program that can accept method invocations via CORBA. 4) Register the server in the implementation repository, specifying server name, launch command, activation mode, and launch and access permissions. The server is now available for activation.

Client Servers: The IDL compiler generates a client stub that gets linked to a program wishing to statically invoke a server method through the associated interface. The client stub maps a CORBA server side object to a native object in the client Operating Systems language. It acts as a proxy for remote server objects, marshaling methods and parameters to be transmitted via the ORB CORBA also supplies the dynamic invocation interface (DII) for client programs to discover server interfaces at run-time. The CORBA interface repository contains compiled IDL descriptions that can be interrogated via the DII.

A client can locate a server object by obtaining an object reference directly from a server, by requesting an object by name via the CORBA naming service, or by asking the CORBA trader service to return references to objects that match some criteria The CORBA standard specifies a format for an interoperable object reference (IOR) which can be passed across different ORB implementations. After obtaining an object reference, a client can invoke methods on a server object using the following call modes: Synchronous, One-way / Poll, One-way / Call-back or One-way / Event Service

call modes Synchronous: The client sends a request and blocks until it receives a reply from the server. One-way / Poll: The client sends a request, but does not await a reply. Rather, the client polls until the server has completed servicing the request.

One-way / Call-back: The client sends a request, passing a callback object reference to the server. When the server is done, it invokes a method on the client Operating Systems call-back object. The implication of this approach is that the client acts like an event-driven server with an IDL interface.
One-way / Event Service: The publish-subscribe model can be employed using the CORBA event service. The client first asks to be notified by the event service when a completion message is dispatched. The client then sends a request to the server. When the server completes processing, it sends a completion message to the event service, which in turn notifies the client.

Client Side Process: 1) Implement the client. The programmer writes server object method calls as though they are local using the syntax and conventions of the client Operating Systems native programming language. 2) Compile the client program and link in the client stub that was generated by the IDL compiler.

3) When the client is executing, it uses the ORB to bind to the server object and obtain an object reference.
4) Using the object reference, the client invokes server object methods.

CORBA Architecture

Standard Interface

Per-Object Type Generated Interface

ORB Dependent Interface

Client

Object Implementation

Interface Repository

Dynamic Invocation

IDL Stubs

ORB Interface

Static IDL Skeleton

Dynamic Skeleton

Implementatio Repository Object Adapter

ORB core

PHP5 extension to use CORBA objects

PHP: Hypertext Preprocessor, an open source, server-side, HTML embedded scripting language used to create dynamic Web pages.
CORBA for PHP is a PHP5 extension to use CORBA objects in PHP. The purpose of this extension is to provide an IDL-to-PHP language mapping specification; an IDL-to-PHP language compiler(idl2php); a full CORBA 2.4 compliant extension.
Prior to PHP 5.3.9, a class could not implement two interfaces that specified a method with the same name, since it would cause ambiguity. More recent versions of PHP allow this as long as the duplicate methods have the same signature.