CORBACommon object Request

Broker-- Priyanka Patil ME(COMPS)

Why We Need CORBA?Need a solution to develop, deploy, and integrate systems in a distributed heterogeneous environment.

• Diverse OS – Unix, Windows, MacOS etc.

• Diverse Network – TCP/IP, Ethernet, ATM, etc.

• Diverse Programming Language – applicationsprogrammed in C++, JAVA, COBOL etc.

• Diverse Hardware Platform.

• Coexist with legacy systems.

Architecture for interoperable distributed computing Developed by the OMG (Object Management Group)

Goal To develop, adopt, and promote standards for the development and deployment of applications in distributed heterogeneous environments.

CORBA – Common Object Request Broker Architecture

Middleware that provides the necessary framework and API for developing distributed applications Middleware :- Middleware is the software that resides ‘in the middle' between applications working on different operating systems

WHAT IS CORBA?

CORBA

•It is a Middleware Technology used for the communication of heterogeneous Distributed Objects of a distributed application.

•CORBA is standard for distributed object created by OMG

•Goal of OMG:•Reusability •Portability•Interoperability of object based software in distributed environment

•There are two types of OMG models:•OMG Object Model•OMG reference Model

CORBA ARCHITECTURE

Common Object Request Broker Architecture

operation() Object : Interface X: Client

Middleware

OMG object model OMG reference model

1.Object transparently send /receive request/response in distributed environment. 2.Provides error handling, security policies & integration to legacy application 3.uniform access service & discovery of resources

Collection of services which support basic function for using & implementing object eg. Naming & trading services for search by name & properties resp.

Collection of services that many

applications can share eg .email

Similar to object services & common facilities but

domain specific eg. (CORBATel)telecomm

Developed specifically for given application. User

defined, application specific

OMG reference model

CORBA Components• OMG provides specification to encapsulate application data &

business logic within object in distributed environment • These objects are called as component s• Each component is significant portion of an overall system• Interaction between component is called component

collaboration • CORBA component is like a normal reusable object which

provides inheritance, polymorphism , and encapsulation• Unlike normal object it is independent of language, OS,

hardware, location, network

CORBA Components

Characteristics of CORBA component are as follows:• Independent development: • Independent business entity• Packagable• Buildable• Rapid development• Extensible• Configurable• Scalable• Flexible• Extended object

CORBA Architecture

CORBA Architecture • CORBA ORBs deliver client requests to servants (server

objects) and return responses to clients. • CORBA automates many common network programming tasks

such as – objects registration, location and activation, request demultiplexing,

error-handling, parameter marshalling and demarshalling and operation dispatching.

• It allows applications to communicate with one another in a uniform way, – transparent to the object location, hardware, operating system ,

programming language and communication protocol.

CORBA Architecture 1. Object Request Broker (ORB): ORB provides the communication and activation infrastructure for

distributed object applications. To make a request, the client specifies the target object by using an object

reference (OR).ORB core facilitates the following transparencies in client-server communication:• Object Location: Here the client has no knowledge of weather the target

object is in-process or out-process · • Object implementation: Here the client does not know the language,

platform of hardware in which object is implemented. • Object execution state: Here the client does not know whether the object

active or inactive. ORB transparently activates object when required by client.• Object communication mechanism: ORB can use memory, RPC and TCP/IP for

communication.

CORBA Architecture 2. OMG Interface Definition language (OMG IDL): An object’s interface specifies the operation and types that the object

supports. Hence it defines the requests that can be made on the object. • OMG IDL is a declarative language and not a programming language, it forces

a clear separation of interfaces from object implementations. OMG IDL is a language in which only classes (i.e. modules) interfaces an methods can be

declared.3. Interface Repository (IFR): • The CORBA IFR allows the IDL-type system to be accessed and written

programmatically at run-time. So it is used in dynamic object invocation.4. IDL Compiler: It is a tool which generates static stubs (Static Invocation Interface (SII)) and

skeletons (Static Skeleton Interface (SSI)) from the interface definition.

CORBA Architecture 5. Stubs and Skeletons: OMG IDL language compilers generate programming language type

interfaces, client-side stubs and server-side skeletons. • A stub is a mechanism that effectively creates and issues requests on

behalf of a client, • a skeleton is a mechanism that delivers requests to the CORBA object

implementation.• As they are interface-specific, dispatching through stubs and skeletons is

called static invocation.6. Dynamic Interface Invocation (DII): The DII allows clients to generate requests at run-time.

It is useful when an application has no compile-time knowledge of the interface it accesses.

CORBA Architecture 7. Object Adepter (OA): • It serves as the glue between CORBA object implementations and the

ORB. • It is an object that adapts the interface of an object to the interface

expected by a caller. • OAs provide services such as object registration, generation and

interpretation of object references, method invocation. • There are two categories of OA: Basic Object Adepter (BOA) and Portable

Object Adapter (POA).– BOA defines an object adapter which can be used for most conventional object

implementations. The POA specifications provide portability for CORBA server code.

8. ORB Interface: This OR interface provides standard operations to initialize and shutdown

the ORB, convert object references to strings and back, and create argument lists of requests made through the DII.

CORBA Architecture 9. Inter-ORB Protocols: To support interoperability, CORBA proposes General Interoperable Protocol

(GIOP) and Interoperable OR(IOR).• It describes a Common/Character Data Representation (CDR) format and

message formats for sending requests and responses between ORBs. • GIOP is defined independently of any particular transport protocol in

order to accommodate a wide range of networking infrastructures.• Internet Interoperable protocol (IIOP) provides full-duplex, connection-

oriented communication channel through the TCP/IP protocol. 10. Implementation Repository (IMR): IMR contains the information that allows an ORB to activate servers on

demand.

Method invocation in CORBA

Method invocation in CORBA• The invocation of the remote CORBA object is done as follows:1. The remote CORBA object registers itself in the CORBA naming server. It

provides a mapping for the remote object name and IOR.2. The client refers the CORBA naming service using the object name.3. The CORBA naming service returns the IOR of the remote object.4. Client procedure calls client stub using a local procedure call.

Conceptually, a client stub contains a set of functions with the same name as the remote function. Stubs can be generated automatically using the IDL compilers and are included in code during compilation.

5. The client stub calls the network routines using system calls.6. In this step, the local kernel sends the message to the remote kernel.7. Once the message is successfully received by the remote kernel, it is

transferred to the OA.8. OA then transfers the call to the server skeleton.

Method invocation in CORBA

Method invocation in CORBA9. Once the control is handed to the server skeleton, it unpacks the

parameters and calls the server procedure. This process is called as unmarshalling.

10. Server does the work and returns the result to the skeleton.11. The skeleton then packs the results in a message to OA.12. OA contacts the RPC layer protocol (ORB core).13. ORB then transmits the results to the client.14. The client’s kernel gives the results to the client stub.15. The client stub unpacks the results and returns them to the client

procedure.

Static and Dynamic CORBA

• CORBA provides two different interfaces for clients to communicate with servers:

1. Static Invocation Interface (SII) –• -- is provided by static stubs generated by a CORBA IDL compiler and is

useful when client applications know the interface offered by the server at compile-time.

2. Dynamic Invocation Interface (DII) – • -- is provided by an ORB’s dynamic messaging mechanism and is useful

when client applications do not have compile-time knowledge of the interfaces offered by servers.

Components of Dynamic CORBA 1. TypeCode: which provides a structural type representation

(a) Portion of IDL showing declaration of the structure “bar” and (b) TypeCodeformat for structure “bar”.

Components of Dynamic CORBA2.Any: which represents a value in dynamic CORBA applications,

3. Named Value/NVList: which provide a dynamic representation of operation arguments and signatures

Components of Dynamic CORBA4. Dynamic Invocation Interface (DII):

which defines the client-side interface for dynamic CORBA applications,5. Dynamic Skeleton Interface (DSI):

which works as DII at the server-side 6. TypeCodeFactory:

which is used to create types dynamically 7. Dynamic Any: which is used to create and examine values in dynamic CORBA applications8. Interface Repository (IFR):

which is a distributed service that provides run-time access to CORBA type information

9. IFR loader:which populates the Interface Repository with entries that correspond to IDL declarations.

Working of Dynamic CORBA

Working of Dynamic CORBA1. Registering IFR in the naming service.2. IFR loader gets the interface details from the IDL file & stores it in

IFR.3. IFR loader gets the operation details from the IDL file & stores it

in IFR.4. Client looks up & identifies the location of IFR.5. Client looks up for the interfaces details from IFR.6. Client looks up for the operation details from IFR.7. Client gets argument types details from IFR.8. IFR creates TypeCode using TypeCodeFactory.9. Client returns the TypeCode to the client.

Working of Dynamic CORBA

Working of Dynamic CORBA10. The following sequence of actions is performed at the client side.

A. Client uses DynamicAnyFactory to create DynamicAny type.B. Client stores the inout values in this type & forms the Any type.C. The DIIRequestObject is formed by the client.D. The Any type parameters are stored in the RequestObject.E. The target object is now invoked using this RequestObject.

11. The response is now sent by the target object to the client.12. The DIIRequestObject receives this response & returns the result

to the client.

CORBA IDL• The CORBA Interface Definition Language (IDL) is used to

define interfaces to objects in your network.• The first step in developing a CORBA application is to define

the interfaces to the objects required in your distributed system.

• To define these interfaces, you use CORBA IDL.• To implement an IDL interface you must:1. Define a Java class that can be accessed through the IDL

interface.2. Create objects of that class within an Orbix Java server

application.

CORBA IDL• Characteristics of IDL:• Multiple language binding: a software interface can bound

different languages C,C++,java, smallTalk, Perl, etc• Platform independent• Increased reuse • Implementation independence

CORBA IDL• Notation used in CORBA IDL:1. Comments:

– It can be represented in two forms as in java– Single line: //– Multiline: /* and */

2. IDL modules:• interface and other IDL type definitions into logical name spaces. When writing IDL

definitions, always use modules to avoid possible name clashes.The following example illustrates the use of modules in IDL:// IDLmodule finance {interface account {...};};

3. IDL Interfaces• An IDL interface describes the functions that an object supports in a

distributed application. Interface definitions provide all the information that clients need to access the object across a network.

• Consider the example of an interface that describes objects that implement bank accounts in a distributed

• application.//IDLmodule finance {interface account {// The account owner and balance.readonly attribute string owner;readonly attribute float balance;// Operations available on the account.void makeLodgement(in float amount,out float newBalance);void makeWithdrawal(in float amount,out float newBalance);}; };

• Inheritance of IDL Interfaces• IDL supports inheritance of interfaces. An IDL interface can inherit all the elements of one or more other• interfaces.• For example, the following IDL definition illustrates two interfaces• called checkingAccount and savingsAccount. Both of these inherit from an interface named account:// IDLmodule finance {interface account {... };interface checkingAccount : account {readonly attribute overdraftLimit;boolean orderChequeBook ();};interface savingsAccount : account {float calculateInterest ();}; };

4. Overview of the IDL Data Types• In addition to IDL module, interface, and exception types, there are four

main categories of data type in• IDL:• · Basic types• · Constructed types

• IDL Constructed Types• IDL provides three constructed data types:· enum· struct· union5. IDL constants: eg. SEP=‘/’ allows definition of constant vaules

6. IDL Exception:ORB returns exception for eg. SYSTEM_EXCEPTION, OBJECT_NOT_EXIST 7. Pre complier directives:Required for C , C++ language

Interface repository• The Interface Repository is the component of the ORB that provides

persistent storage of interface• definitions—it manages and provides access to a collection of object

definitions specified in OMG IDL.• An ORB provides distributed access to a collection of objects using the

objects’ publicly defined interfaces specified in OMG IDL• The Interface Repository provides for the storage, distribution, and

management of a collection of related objects’ interface definitions• Some of the entities in an interface repository are:• 1. Repository IDs: They uniquely identify modules, interfaces, constants,

typedefs, exceptions, attributes, and operations.• 2. TypeCodes: It determines the complete structure of the type.

3. Interface Repository Objects (IRO): They determine the IDL definitions. Some examples of interface

repository objects are RepositoryDef, ModuleDef, InterfaceDef, ValueDef, OperationDef, TypedefDef, ConstantDef.

Deployment of CORBA• 1. WEATHER FORECAST INFORMATION

USING CORBA• Weather.idl :module WeatherForecast{interface Weather{double get_celsius(in string symbol);};};

•WeatherForecastImpl.java :import org.omg.CORBA.*;import WeatherForecast.*;public class WeatherForecastImpl extends _WeatherImplBase {public double get_celsius(String symbol) {double celsius = Double.parseDouble(symbol);double fahrenheit = 1.8 * celsius+32;return fahrenheit;}public WeatherForecastImpl(){super();}}

• WeatherForecastClient.java :import org.omg.CORBA.*;import org.omg.CosNaming.*;import WeatherForecast.*;import java.io.*;public class WeatherForecastClient{public static void main(String args[]) {try{ORB orb=ORB.init(args,null);NamingContext ncRef =NamingContextHelper.narrow(orb.resolve_initial_references("NameService"));NameComponent path[]={new NameComponent("FORECAST","")};Weather weather = WeatherHelper.narrow(ncRef.resolve(path));System.out.println("Enter the celsius");BufferedReader br = new BufferedReader(new InputStreamReader(System.in));String cel = br.readLine();System.out.println("Temperature of my city in Fahrenheit is " +weather.get_celsius(cel));}catch(Exception e){ e.printStackTrace(); }} }

• WeatherForecastServer.java :import org.omg.CORBA.*;import org.omg.CosNaming.*;import WeatherForecast.*;public class WeatherForecastServer{public static void main(String args[]){try{ORB orb = ORB.init(args,null);WeatherForecastImpl weatherForecastImpl = new WeatherForecastImpl();orb.connect(weatherForecastImpl);org.omg.CORBA.Object objRef =orb.resolve_initial_references("NameService");NamingContext ncRef = NamingContextHelper.narrow(objRef);NameComponent nc=new NameComponent("FORECAST","");NameComponent path[]={nc};ncRef.rebind(path,weatherForecastImpl);System.out.println("The WeatherForecast Server is up and ready..");Thread.currentThread().join();}catch(Exception e) {e.printStackTrace();}} }

on command prompt 1

On command prompt 2

On command prompt 3

References

• CORBA” Middleware & Enterprise Integration Technologies” G.sudha sadasivam , Radha shankarmani ”Wiley Precise Textbook”