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

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 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 [4].

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

 1)Enables communication between objects. Communication between the ORBs happen via an abstract protocol GIOP (General InterORB Protocol)
 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 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 [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.

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. Lets discuss two 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.

Proxy design pattern through Stubs

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 [10]. In such situations developers use "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[11]. The client can make use of this single object through which it can resolve names of various objects and use these objects.

Distributed garbage collection in CORBA: not implemented so far..

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 8. http://sourcemaking.com/design_patterns/proxy - proxy design pattern 9. factory pattern and CORBA - Supplementing the Well-Known Factory Pattern for Distributed Object-Oriented Systems

  Markus Aleksy, Axel Korthaus University of Mannheim, Germany {aleksy|korthaus}@wifo3.uni-mannheim.de

10. http://gsraj.tripod.com/design/creational/factory/factory.html 11. http://documentation.progress.com/output/Iona/orbix/gen3/33/html/orbixnames33_pguide/Introduction.html