CSC/ECE 517 Fall 2010/ch6 6i CB

CORBA

CORBA is the acronym for Common Object Request Broker Architecture. It is an industry standard developed by Object Management Group to provide the object oriented interoperability of applications in distributed systems.

Before diving into the world of CORBA, we need to know the importance of distributed application and it's purpose.

Purpose of Distributed Applications

CORBA can be viewed as a framework for developing and running distributed applications. But the general question to be raised is about the purpose of distributed application. Can’t it be possible to make an application a standalone one everytime?

In most cases the answer is NO. This may be because one or more of the following reasons.

• The data used by the application are distributed.

• The Users of the application are distributed

• The computation is distributed

Data are distributed

There may be situations where we want the data to be stored on multiple computers for ownership or administrative reasons and so applications should execute on multiple computers. There may also be the cases where data cannot be co-located and must execute on multiple heterogeneous systems.

Users are distributed

Generally, the Users of the distributed application are distributed, geographically, across different parts. Users of the application communicate and interact with each other via the application by executing a piece of application on his or her computer and shared objects which typically run on one or more servers. A typical architecture is illustrated below

Computation is distributed

To utilize the advantage of parallel computing some applications execute on multiple computers. Some applications may want to execute on multiple computers to utilize a unique feature of that particular system.

Introduction to CORBA

A CORBA-based system is a collection of objects that isolates the clients (one who request a service) and the servers (one who provide a response to the request) by a well-defined encapsulating interface. This is possible because CORBA allows applications to be built in a standard manner using building blocks such as objects.

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.

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.

Difference between CORBA objects and other objects

• CORBA objects can run on any platform.

• CORBA objects can be written in any language that has IDL mapping

• CORBA objects can be located anywhere across the network.

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 an application present in 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 lots of advantages that make use of distributed computing.

CORBA Architecture

The Following picture depicts the major components in CORBA

ORB Core

The software that implements the CORBA specification is called the Object Request Broker. This is the core of CORBA and is responsible for the following tasks, whenever it gets the request from the client.

• It will find the appropriate object implementation for the request
• It will prepare the object implementation to receive the request
• It will transfer the data making up the request.

Some of the examples for ORB are JavaIDL from JavaSoft, ORBIX from IONA Technologies etc.

Every request from the client will be handled by ORB independent of the fact that it is a local invocation or a global one.

• If it is a local invocation, then the request will be directly passed to the sole ORB.
• If it is a remote invocation, then the invocation will be passed from ORB of the client to ORB of the server.

Once the ORB gets the appropriate request from the client It will prepare the corresponding Object Implementation and communicates the data.

Vendor Specific ORB

From the above discussion and examples, it is evident that CORBA may have more than one implementation and each implementation may be different from different vendors. So, the commonly raised question is can ORB objects from different vendors be able to communicate with each other?

The answer is yes, if the CORBA implementation is 2.0 and above since all the ORBs that are compatible with CORBA 2.0 and above are able to inter-operate via IIOP protocol. This was not true for CORBA 1.0 products.

Interface Definition Language

The OMG Interface Definition Language IDL supports the specification of Object Interfaces. The interface of any object describes the actions (operations) that are supported by the object. It does not deal with their implementation details. IDL interfaces are programming language neutral even though they share some syntax notations from C, C++, and Java etc.

From an IDL definition, a particular Object Implementation tells the Client about the available operations and their invocation details. According to these definitions, the objects are mapped to different programming languages, Say C, C++, Java etc. Since mapping of an object to a particular language is completed, you can use any programming language to make requests to that object if you want to use it. Some of the data types that are supported by the IDL are short, long, float, string, any etc. and the data structures like struct, union, enum, and sequence etc.

So, using IDL, the following details holds well without regards to any programming language

• Object Interfaces
• Actions and the attributes that are supported by that object
• Operation’s Return value, it’s Data Type, it’s parameters etc.,
• Exceptions raised by the Operation

Example

Sample functions and attributes of a product in any catalog.

module productcatalog{
 struct product{
   float weight;
   double price;
 };
 exception Unknown();
interface product_details{
 float get_price();
 void set_price();
};

}; The Module block defines the scope of the attributes. Data Structure product and exception are defined and then used in product_details interface.

All these IDL declarations are compiled with an IDL compiler and these are converted to their corresponding representations in target programming languages.

An IDL interface can be defined in terms of other IDL interfaces.

Interface CatFamily: Cat, Tiger {
};

A CatFamily object supports all of the operations and attributes that are defined by Cat interface as well as those defined by Tiger interface. In other words, the Cat Family interface inherits both Cat and Tiger interfaces.

CORBA products provide an IDL compiler that converts IDL into the Java Programming Language. idltojava is the compiler available for Java 2 SDK.

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.

Cohesion and Coupling in Distributed Systems

Cohesion and Coupling are two of the important concepts that have to be taken care of while designing an object oriented system.

Cohesion

The Distributed system that we build consists of a set of subsystems. Each subsystem consists of a set of distributed objects to support the functionality of that subsystem. Those objects that are present on different systems but belong to a same subsystem interact through CORBA. To come up with a good design a set of guiding principles have to be followed. By design, the subsystem should be cohesive. When we produce a cohesive distributed object model, we find that each of the interface represents essential concepts. Each object is easier to understand and the system is more maintainable, and the components that comprise the system are easy to reuse. All of this contributes to reducing the overall cost of the system. In order to build a distributed object model comprising of functionally cohesive interfaces, the following guidelines should be followed.

1 . Each interface should represent a concept and all elements should be strongly related to that abstraction.

2 . Every method should perform a single coherent task.

3 . Each of the subsystems of the distributed architecture should themselves be cohesive. For a subsystem to be cohesive, all the interfaces that comprise that subsystem should also be cohesive.

Coupling

Coupling is a measure of the strength of dependency between different software modules. The stronger the coupling, the stronger the inter dependency between the modules in the system. A design is considered to be bad when there is strong coupling between different modules. It is not possible to completely eliminate coupling, but we should try to minimize it as much as possible. Strongly coupled distributed objects affects the flexibility of our system. In an object oriented system, four types of coupling can occur.

NIL Coupling - No dependency between two classes

Export Coupling - A class is dependent on only the public interface of an other class

Overt Coupling - A class is dependent on implementation details of other class but with permission

Covert Coupling - A class is dependent on implementation details of other class but no permission was given

It is not possible to build a distributed system without Export Coupling as an object will need to interact with another object on a distributed system by making use of the semantics defined by the object interfaces. It is the other types of couplings that prevent us from building a loosely coupled system. However in a distributed system Covert Coupling cannot take place as Interface Definition Language only expresses the public interface of a distributed object and internals are not exposed. We can also avoid Overt Coupling by defining all the interfaces in a subsystem at the same level of abstraction.

References

[1] An overview of Corba [Online]. http://www.cs.wustl.edu/~schmidt/corba-overview.html

[2] Distributed Object Architectures by Balen, Henry [Print.]

[3] A tutorial on Corba [Online]. http://www-cdfonline.fnal.gov/daq/CORBAXXX/tutorial.html

[4] A Distributed Object computing using Corba [Print.]

[5] Wikipedia. Common Object Request Broker Architecture [Online]. http://en.wikipedia.org/wiki/Common_Object_Request_Broker_Architecture