CSC/ECE 517 Fall 2010/ch6 6i ak

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 would be different systems involving different architecture and 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 systems. CORBA is instrumental in implementing this utopia!

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 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

Figure1: CORBA Architecture Let us take a look at each one of these components and their functions.

• Client & 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. 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 & 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++

Client stub and Server skeleton

When such IDL files are compiled the IDL compiler 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. 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 & 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 [4].

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

 1)Enables communication between objects
 2)Locates a remote object given a object reference
 3)Marshals parameters to remote method invocation. Marshaling is the process of converting the parameters so that they can be             transferred over a network
 4)Un-marshals parameters from remote method invocation. Reverse process of marshaling.

ORB resolution of object requests

• BOA Interface: Basic Object Adapter is responsible for interfacing object's implementation with its ORB. API used by the server to register its object implementation
• Interface Repository & 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 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 [6] 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.

References

1.http://en.wikipedia.org/wiki/Transaction_Processing_Facility

2.orbix CORBA http://web.progress.com/en/orbix/orbix_mainframe.html 3.http://www.ibm.com/developerworks/webservices/library/ws-exploring-corba/ 4. DSI and DII http://www.drdobbs.com/184403847 5. http://www.cs.wustl.edu/~schmidt/corba-overview.html 6. Ripple effect - wikipedia 7. coupling Wikipedia