CORBA Basic and Deployment of CORBA

CORBA
Common 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 – applications
programmed 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 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
• 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
9. 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) TypeCode
format for structure “bar”.

2.Any: which represents a value in dynamic CORBA applications,
3. Named Value/NVList:
which provide a dynamic representation
of operation arguments
and signatures

4. 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 applications
8. 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
1. 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
10. 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 */
1. 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:
// IDL
module 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.
//IDL
module 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:
// IDL
module 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
· union
5. 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.CosNaming.*;
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.CosNaming.*;
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();}

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

CORBA Basic and Deployment of CORBA

More Related Content

What's hot (20)

Viewers also liked (16)

Similar to CORBA Basic and Deployment of CORBA (20)

Recently uploaded (20)

CORBA Basic and Deployment of CORBA