CSC/ECE 517 Fall 2010/ch6 6i ak

6i. CORBA. An important way of interfacing objects in different systems is the Common Object Request Broker Architecture (CORBA). It is designed to allow objects on one system to run methods of objects on another system. Explain CORBA in terms of topics covered in this course, such as cohesion, coupling, and design patterns. Write a unified narrative, not a set of disjointed paragraphs like appears in the Wikipedia article.

Introduction

Business applications have evolved gradually over time from the ages of monolithic architectures, witnessing a slow transition to the Client-server architecture and then to multitier-client server architecture and culminating with Distributed systems and it still continues to evolve.... So at any point in time, there are different systems involving different architecture and these should still be able to communicate with each other. There is also a possibility that some of the systems have a monolithic architecture, while others have an architecture of recent times. The more diversified the systems are, more is the need for a standard interface encompassing two important features a) Platform Independence b) Language Independence for an effective exchange of information between such systems1.CORBA is an architecture that helps in implementing this utopia! CORBA is one of the the earliest Service Oriented Architectures.

In today's distributed environment, a system exposes its functionalities through objects for other systems to utilize. These objects in turn make use of services provided by other objects within the same system or across systems. CORBA (Common Object Request Broker Architecture) is "an Object oriented architecture from the OMG (Object Management Group) to utilize a plethora of services available from various objects that reside in different systems within same or different networks, in a manner that language and platform independent".

CORBA Architecture:

CORBA Architecture^[3]

Let us take a look at each one of these components and their functions.

Client and Implementation :

As in the 'Client-Server' terminology, Client is a component that requests for a service from the Server. A CORBA object is designated as a 'Server' if it has the implementation of the interface, that is requested by another object, which will act as a 'Client'. But in CORBA the roles are interchangeable as a CORBA object might take part in multiple interactions simultaneously acting both as server and client.

IDL Stub and Skeleton:

IDL stands for "Interface definition Language" and it is the standard language in CORBA for defining the interfaces. As the name suggests it can only be used for defining interfaces between the application components. The language independence feature of CORBA could be attributed to IDL and is achieved through language mapping. Language mapping is available for a number of standard languages like Java, Smalltalk, C++[1].

Client stub and Server skeleton

When such IDL files are compiled the IDL compiler it generates Client Stubs and Server skeletons. Stub is a piece of code, that provides a framework through which a client can access server's interface. Skeleton is also a piece of code that provides a framework on which implementation of the interface is built[2].

Example of IDL interface file: 
------------------------------
      module shapes{
        interface rectangle{
          long area(in long length,long breadth);
          };
      }; 

IDL keywords:

• Module: This is similar to package in java,
• Interface: This is converted to a java interface (through language mapping)
• Long: Datatype in IDL
• In : Direction of data flow (from Client to Server).

DII and DSI:

Dynamic invocation interface facilitates dynamic finding of the server interfaces. Such clients can dynamically discover server interface without using client stubs, that are statically linked to server interfaces. Dynamic skeleton interfaces are the server side counterparts of DII [3]. However the implementation of DII and DSI are really complex and hence should be used only when it is required.

ORB Interface and ORB:

ORB serves the following purpose and is fundamental to the architecture itself:

• Enables communication between objects. Communication between the ORBs happen via an abstract protocol GIOP (General InterORB Protocol)
• Locates a remote object given a object reference
• Marshals parameters to remote method invocation. Marshaling is the process of converting the parameters so that they can be transferred over a network
• Un-marshals parameters from remote method invocation. Reverse process of marshaling

ORB resolution of object requests ^[5]

From the figure we can understand, that the client stubs and the server skeletons interact with each other through the underlying ORB layer.

BOA Interface:

Basic Object Adapter is responsible for interfacing object's implementation with its ORB. It is the API used by the server to register its object implementation. In later CORBA architecture 3.0, the Basic Object adapter has been replaced by Portable Object Adapter(POA), which supports nested POAs per ORB. This helps in implementing simple ORB that can serve for a large number of objects. This was one of the new features added to CORBA [4].

Interface Repository and Implementation interface:

This consists of the type information necessary to issue requests using DII and implementation interface consists of the necessary implementation.

Coupling

Coupling refers to the level of dependency of one module on another for its operations. If we have two modules say A and B and if B's implementation of a function depends on the output from A. Then there is a high coupling between modules A and B. High coupling produces undesirable effects in the program. The most common one is the 'Ripple' effect [5] i.e a change in one module forces a lot of changes in the related modules. But CORBA objects are loosely coupled. A CORBA object can communicate with another one through the simple interfaces available, without having any knowledge about its implementation or the language in which it is implemented. Through the Client stub, interface is created, ORB finds the object that has this implementation and marshals the parameters. The server side ORB unmarshals parameter and invokes the implementation and returns the result as marshaled parameters. For further information on coupling please refer to the wiki chapter that deals extensively with cohesion and coupling

Design Patterns in CORBA

A design pattern is a generic, reusable solution for a recurring design problem in a system. We are aware of lot of design patterns like the Singleton pattern, Adapter pattern, Abstract factory pattern, Proxy design pattern etc. Let us discuss some of the design patterns implemented in CORBA.

Proxy pattern:

'Proxy' is an interface to support distributed, controlled, and an intelligent access to an object. This will be really helpful in an environment where objects are resource hungry. As we saw already, Client stub is an interface for an implementation that is available remotely at the server. Below figure illustrates stubs and skeletons that represents the proxy design pattern [6].

Proxy design pattern through Stubs[5]

Abstract Factory pattern:

In a distributed application that is based on a CORBA architecture, clients may have to instantiate and destroy server objects. But the CORBA client object will not know any details of the implementation details of the server class so that it can just call the 'new' class_name() method. This can be done in a non-distributed environment whereas not in a distributed environment [7]. In such situations developers use "Abstract Factory pattern".

The COS Naming (CORBA object services) service specification is used to associate abstract names to the CORBA objects, that can be used by the clients. NamingContext object is used to resolve the names of other objects in the database that has a list of objects and their associated names. All these contexts are present in the CosNaming.Factory and CosNaming.ExtFactory servers. When the factory server is executed, only a single object implementing CosNaming::NamingContextFactory interface is created. This is the entry point for the naming service [8]. The client can make use of this single object through which it can resolve names of various objects and use these objects. This explains the factory pattern as well as the singleton pattern in CORBA.

Adapter Pattern:

Object Adapter in CORBA implements the adapter design pattern. All CORBA objects are to be registered to the object adapter and it offers the object reference for the registered objects. The object adapter along with the ORB core and underlying OS ensures that the right information which is the object reference, is available to reach an object. Thus the Object adapter acts as an adapter converting the incoming marshaled parameters into an object reference through which the client can invoke operations on that distributed object.

Advantages of CORBA:

• Object location transparency: The client and server objects can communicate, without even knowing where they exist. It can exist in the same network or in a different network. In all cases the client object will be able to utilize the services of the server object.

• Language transparency: The client may be implemented in a different language and server may be written in a different language. As long as the ORB implementations exists and if can interoperate via the IDL.

• Implementation transparency: A Client in CORBA architecture need not be aware of the implementation of the object at the server end.

• Architecture transparency: ORB takes care of marshaling and unmarshaling parameters so the client and server can communicate with each other transparent of the big-endian or little-endian format the underlying architecture uses.

• Operating system transparency: Client can reside in a system that uses a different operating system from the server and these both can still communicate with each other.

Conclusion:

Every technology has its rise and fall, and CORBA was not an exception. Infact, some of its own features turned into a pitfall and led to the fall of CORBA. The most obvious one was Complexity, specifically the complexity of the APIs eg: The Object adapter itself needs more than 200 lines of code, 30 for the actual functionality and remaining 170 for interacting with CORBA runtime [12]. Though CORBA provided a variety of functionalities, it failed to provide two important features:

• Security: Corba's unencrypted traffic can easily be eavesdropped. So, CORBA can only be used within a company's network, which is well protected from the outside world. Though OMG took interest in improving this, all efforts were abandoned due to poor patronage by firewall vendors.
• Versioning: CORBA doesn't have a strong versioning mechanism. It requires the entire application to be replaces at once, which is infeasible.

Above two are the heart of problems that led to the decline of the CORBA. CORBA's use is declining and is no longer a cutting edge technology but just a niche technology.

References

[1] Rosenberger, J., Teach yourself CORBA in 14 Days. Sams Publishers, http://ovir.icp.ac.ru/corba/books/Teach14/index.htm

[2] Exploring the range of CORBA technology, retrieved November 15, 2010 from IBM.Com http://www.ibm.com/developerworks/webservices/library/ws-exploring-corba/

[3] Overview of CORBA, retrieved November 15, 2010 from wustl.edu http://www.cs.wustl.edu/~schmidt/corba-overview.html

[4]Overview of CORBA, retrieved November 15, 2010 from java.sun.com http://java.sun.com/developer/Books/corba/ch11.pdf, pp153

[5] Coupling, retrieved November 15, 2010 from Wikipedia http://en.wikipedia.org/wiki/Coupling_(computer_science)

[6] Proxy Design pattern, retrieved November 15, 2010 from sourcemaking.com http://sourcemaking.com/design_patterns/proxy

[7] Aleksy, M., Korthaus, A., University of Mannheim, Germany Supplementing the Well-Known Factory Pattern for Distributed Object-Oriented Systems. Mannheim, Germany

[8] CORBA Naming Service, retrieved November 15, 2010 from documentation.progress.com http://documentation.progress.com/output/Iona/orbix/gen3/33/html/orbixnames33_pguide/Introduction.html

[9] The Dynamic Skeleton Interface, retrieved November 15, 2010 from Drdobbs.Com http://www.drdobbs.com/184403847

[10] Factory Design pattern in CORBA, retrieved November 15, 2010 from tripod.com http://gsraj.tripod.com/design/creational/factory/factory.html

[11] CORBA for Mainframes orbix, retrieved November 15, 2010 from progress.com http://web.progress.com/en/orbix/orbix_mainframe.html

[12] Henning, M The Rise and Fall of CORBA, retrieved November 19, 2010 from http://queue.acm.org/detail.cfm?id=1142044