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

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.

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