case study on corba

8/3/2019 Case Study on Corba

http://slidepdf.com/reader/full/case-study-on-corba 1/23

CASE STUDY ON CORBA TECHNOLOGY

Made by:

Priyanka Asrani(D10-3)

Pratiksh Jain(D10-8)Mandar Kambli(D10-23)

Gaurav Keswani(D10-25)



Introduction:

The Common Object Request Broker Architecture (CORBA) is a standard defined by the Object

Management Group (OMG) that enables software components written in multiple computer

languages and running on multiple computers to work together (i.e., it supports multiple

platforms).

CORBA provides a platform-independent, language-independent way to write applications that

can invoke objects that live across the room or across the planet.

CORBA enables separate pieces of software written in different languages and running on

different computers to work with each other like a single application or set of services. More

specifically, CORBA is a mechanism in software for normalizing the method-call semantics

between application objects residing either in the same address space (application) or remote

address space (same host, or remote host on a network).

Common Object Request Broker Architecture enables separate pieces of software written in

different languages to interact with each other.

It uses an Interface Definition language (IDL) to specify the interfaces which objects present to

the outer world. CORBA specification tells there should be an ORB (Object Request Blockers)

through which an application would interact with other objects.

In practice, the application simply initialize the ORB and access an interact object Adapter which

maintains things like reference counting, object installation policies and object lifetime policy.

CORBA uses an interface definition language (IDL) to specify the interfaces which objects

present to the outer world. CORBA then specifies a mapping from IDL to a specificimplementation language like C++ or Java. Standard mappings exist for Ada, C, C++, Lisp, Ruby,

Smalltalk, Java, COBOL, PL/I and Python. There are also non-standard mappings for Perl, Visual

Basic, Erlang, and Tcl implemented by object request brokers (ORBs) written for those

languages. Currently the OMG is working on a new IDL to C++11 language mapping.

What is the OMG?

Designers of CORBA

Consortium of 700+ companies

± Not including Microsoft

Members: platform vendors database vendors

software tool developers

corporate developers software application vendors



Basic CORBA architecture:

REQUEST RESPONSE

OBJECT BUS

ORB (Object Request Broker):y Handles all communication among objects

y Each host (machine) has its own ORB

y ORBs know how to talk to each other

y ORB also provides basic services to client

Functions of the Object Request Broker:y Find the object implementation for the request

y Prepare the object implementation to receive the request

y Communicate the data making up the request

y Retrieve results of request

Stubs and skeletons:

y Stub

lives on client

pretends to be remote object

Java objects call stub methods and the stubs communicate with CORBAobjects and vice versa

y Skeleton

lives on server

receives requests from stub and talks to true remote object

delivers response to stub

Client Server

ORB ORB



What is Corba good for?y Developing distributed applications

y Locating remote objects on a network

y Sending messages to those objects

y Common interface for transactions, security, etc.

Client vs Server:y In CORBA, a client is a client relative to a particular object i.e. an object with a reference

to a server object

y

A client may also act as a server if it has an IDL and stubs and skeletonsy Technically, a CORBA server contains one or more CORBA objects

Basic working:



Main components

The main components or CORBA are:

y The ORB (object request broker)

o Enables the communication between clients, and objects located at various

clientsy CORBA objects

o A "virtual" entity capable of being located by an ORB. Allows requests to beinvoked on it

y Servants

o The programming language entity that implements one or more CORBA objectsy Object Adapters

o The "glue" between servants and the ORB

Distributed object model CORBA objects are binary components that can reside anywhere in a network. CORBA objects (components) can be transactional, secure, lockable, and persistent.

Remote clients can access server objects without knowledge of their location, platform

type, operating system, or implementation language. Interfaces are specified in a neutral Interface Definition Language (IDL)

Interface Repository

contains interface definitions for registered CORBA server components. Interfaces are represented in a metadata format so that they can be discovered

dynamically at run time.

The Object request Broker (ORB)

functions as an object bus, facilitating location independent communication among

CORBA objects provides a range of distributed services the CORBA standard provides a specification

for ORB services it is up to individual vendors and/or third parties to provide implementations for varius

platforms/operating systems

ORB Services:

o programming language bindings

o method invocations

static (compile time) dynamic (run-time)

o interface repository

o local/remote transparency within a process, among different processes on same machine and across heterogeneous

networks

o Internet Inter-ORB Protocol (IIOP)o Transaction processing

o security

Note that CORBA supports a true object model--i.e operations are invoked on specifictarget objects.

o allows polymorphism Can encapsulate existing (non-OO) applications through IDL interfaces to function as

CORBA objects



Types of Corba technology and business objects:

CORBA basic typesMost of the CORBA types map directly onto C++ types and can be used transparently to

C++. The following basic C++ types map directly into CORBA types:

y Atomic data types:

o Boolean

o Charo Double

o Float o Long

o Octet (hexadecimal)

o Short

o ULong (unsigned long)

o UShort (unsigned short)

y Enum (enumerations)y LongLong (long long)

y Struct y ULongLong (unsigned long long)

y WChar (wide character)

All of these types are scoped to the CORBA class and must be declared accordingly.

Their use in C++ is transparent and straightforward. For example:

CORBA::Short aShortvariable;

...aShortVariable = 12;

...

CORBA types that return object references

Other CORBA types are not as straightforward to use because they return object references to the caller. The following CORBA types return object references to the

caller:

y Any

y Array

y Sequence

y String

y Union

y

WString (wide string)It is the responsibility of the caller to manage the object references and their associated

memory. There are two facilities provided by CORBA to do this:

A_var:

This is the facility most frequently used by client code because it is a smart

pointer that automatically releases its object reference when it is deallocated or

assigned a new object reference. This is the safest and most straightforward

approach to managing these types.



A_ptr:

This is a pointer type that provides the most basic object reference, which has

similar semantics to a standard C++ pointer.

Note: Avoid declaring C++ Static variables as _var. The _var holds a reference to an

object. During the end of the process, this object might reference another object that was removed before end processing completes for this static type. As a result,

the _var might reference an inappropriate address or null pointer and thereby

cause an undesirable ending.



Application:

An n-tier design with Corba technology:

CORBA Services

Another important part of the CORBA standard is the definition of a set of distributed

services to support the integration and interoperation of distributed objects. As

depicted in the graphic below, the services, known as CORBA Services or COS, aredefined on top of the ORB. That is, they are defined as standard CORBA objects with IDL

interfaces, sometimes referred to as "Object Services."

There are several CORBA services. The popular ones are described in detail in another

module of this course. Below is a brief description of each:

Service Description

Object life cycle Defines how CORBA objects are created, removed, moved,



and copied

Naming Defines how CORBA objects can have friendly symbolic

names

Events Decouples the communication between distributed objects

Relationships Provides arbitrary typed n-ary relationships between

CORBA objects

Externalization Coordinates the transformation of CORBA objects to and

from external media

Transactions Coordinates atomic access to CORBA objects

Concurrency Control Provides a locking service for CORBA objects in order to

ensure serializable access

Property Supports the association of name-value pairs with CORBA

objects

Trader Supports the finding of CORBA objects based on properties

describing the service offered by the object

Query Supports queries on objects

CORBA Products

CORBA is a specification; it is a guide for implementing products. Several vendors

provide CORBA products for various programming languages. The CORBA products that

support the Java programming language include:ORB Description

The Java 2 ORB The Java 2 ORB comes with Sun's Java 2 SDK. It is

missing several features.

VisiBroker for Java A popular Java ORB from Inprise Corporation.

VisiBroker is also embedded in other products. For

example, it is the ORB that is embedded in the Netscape

Communicator browser.

OrbixWeb A popular Java ORB from Iona Technologies.

WebSphere A popular application server with an ORB from IBM.

Netscape Communicator Netscape browsers have a version of VisiBroker

embedded in them. Applets can issue request on CORBA

objects without downloading ORB classes into the

browser. They are already there.



Various free or shareware

ORBs

CORBA implementations for various languages are

available for download on the web from various

sources.

Providing detailed information about all of these products is beyond the scope of this

introductory course. This course will just use examples from both Sun's Java 2 ORB and

Inprise's VisiBroker 3.x for Java products.

The Stock Application

The stock trading application is a distributed application that illustrates the Java

programming language and CORBA. In this introductory module only a small simple

subset of the application is used. Feel free to expand upon the application to enhance it

once you are more comfortable with CORBA.

The stock application allows multiple users to watch the activity of stocks. The user is

presented with a list of available stocks identified by their stock symbols. The user can

select a stock and then press the "view" button.

Selecting the "view" button results in a report about the stock, indicating the name of the company, the stock symbol, the current price, the last time it was updated, the

trading volume, and a graph that shows the stock price over some interval. This report

is automatically updated as new stock data becomes available.



The stock report also lets the user set an alarm by pressing the "Alarm" button. The

alarm can be set to activate when the price of the stock falls below a certain price or

when it exceeds a certain price.

When the price of the stock satisfies the alarm's condition, it activates and the user is

notified.

Later the application could be extended to allow users to buy and sell stocks.

Some Objects in the Stock Application

From the above description, you can easily identify the following distributed objects in

the application.

Stock A distributed object that represents a particular stock.

StockPresentation A distributed object in the GUI that presents the stock

data to the user for a particular stock.

Alarm A distributed object that represents the alarm set by the

user.

AlarmPresentation A distributed object in the GUI that presents the alarm

going off to the user.

The Stock object is now used to illustrate the CORBA distributed object model.



Benefits of Corba technology:

y Maturity

y Open standard

y Wide platform support

y Wide language support

y Efficiency

y Scalability

y CORBA Success Stories

Above it was mentioned that CORBA is a type of middleware, but that there are other types of middleware too. This naturally raises the question of why you might wish to use CORBA instead

of a different middleware technology. The reason, as I discuss in this chapter, is that CORBA

offers numerous important benefits. You may find some of these benefits in other middleware

technologies, but you will be hard pressed to find another middleware technology that offers all of these benefits.

2.1 Maturity

The original version of the CORBA standard was defined in 1991. This first version of the

specification was deliberately limited in scope. The OMGs philosophy was to define a small

standard, let implementors gain experience and then slowly expand the standard to incorporate

more and more capabilities. This slow but sure approach has been remarkably successful. In

particular, there have been few backwards-incompatible changes to the CORBA specification.Instead, new versions of the specification have tended to add new functionality rather than

modify existing functionality. Today, CORBA is extremely feature-rich, supporting numerous

programming languages, operating systems, and a diverse range of capabilitiessuch as

transactions, security, Naming and Trading services, messaging and publish-subscribe

servicesthat are essential for many enterprise-level applications. Many newer middleware

technologies claim to be superior to CORBA but actually have to do a lot of catching up just to

match some of the capabilities that CORBA has had for a long time.

2.2 Open standard

CORBA is an open standard rather than a proprietary technology. This is important for a variety

of reasons.

First, users can choose an implementation from a variety of CORBA vendors (or choose one of

the freeware implementations). You might think that switching from one CORBA product toanother would involve a lot of work. However, the amount of work involved is likely to be much

less than you might think, particularly if you follow the practical advice in Chapter 25 about how

to increase the portability of CORBA-based applications. In contrast, if you use a proprietarymiddleware system then switching to another proprietary middleware vendor is much more

challenging.

Second, the competition between different CORBA vendors helps to keep software prices down.Finally, many proprietary middleware technologies are designed with the assumption that

developers will build all their applications using that particular middleware technology, and so

they provide only limited support for integration with other technologies. In contrast, CORBAwas designed with the goal of making it easy to integrate with other technologies. Indeed, the

CORBA specification explicitly tackles integrations with TMN, SOAP, Microsofts (D)COM and

DCE (a middleware standard that was popular before CORBA). Furthermore, many parts of

J2EE borrow heavily from concepts in CORBA, which makes it relatively easy to integrate J2EEand CORBA. Some vendors sell gateways between CORBA and J2EE that make such integration



even easier. Several CORBA vendors sell COM-to-CORBA and/or .NET-to-CORBA gateways. This

provides a very pragmatic solution to organizations that wish to write GUI applications in, say,Visual Basic on Windows that act as clients to server applications on a different type of computer, such as UNIX or a mainframe. The Visual Basic GUI can be written as a COM/.NET

client that thinks it is talking to a COM/.NET server, but in fact communicates with a gateway

that forwards on requests to a CORBA server.

2.3 Wide platform support

CORBA implementations are available for a wide variety of computers, including IBM OS/390and Fujitsu Global Server mainframes, numerous variants of UNIX (including Linux), Windows,

AS/400, Open VMS, Apples OS X and several embedded operating systems. There are very fewother middleware technologies that are available on such a wide range of computers.

2.4 Wide language support

CORBA defines standardized language mappings for a wide variety of programming languages,

such as C, C++, Java, Smalltalk, Ada, COBOL, PL/I, LISP, Python and IDLScript. Some small

organizations might use a single programming language for all their projects, but as an

organization increases in size, it becomes increasingly likely that the organization will make useof several programming languages. Likewise, the older an organization is, the higher thelikelihood becomes that some of its legacy (older) applications are implemented in one

programming language and newer applications are implemented in a different programming

language. For these organizational reasons, it is important for a middleware system to support

many programming languages; unfortunately, not all middleware systems do so. One extremecase of this is J2EE, which supports only Java. Another extreme case is the SOAP middleware

standard. SOAP applications can be built with a variety of programming languages but, at the

time of writing, the SOAP standard defines only one language mapping (for Java). There may be

several vendors who support, say, C++ development of SOAP applications, but each of thosevendors provides their own proprietary C++ APIs. This means that there is no source-code

portability of non-Java SOAP applications across different vendor products.

2.5 Efficiency

The on-the-wire protocol infrastructure of CORBA (discussed in Chapter 11) ensures that

messages between clients and servers are transmitted in a compact representation. Also, most

CORBA implementations marshal data (that is, convert data from programming-language types

into a binary buffer that can be transmitted) efficiently. Many other middleware technologiesalso use a similarly compact format for transmitting data and have efficient marshaling

infrastructure.However, there are some notable exceptions, as I now discuss.

SOAP uses XML to represent data that is to be transmitted. The verbosity of XML results in

SOAP using much more network bandwidth than CORBA.1 SOAP-based applications also incur

considerable CPU overhead involved in formatting programming-language types into

XML format and later parsing the XML to extract the embedded programming-languages types.

Some other middleware technologies, such as IBM MQ Series, transmit only binary data, whichis efficient. However, this requires that developers write the marshaling code that copies

programming-language types into the binary buffers prior to transmission, and theunmarshaling code to extract the programming-language types from a binary buffer. In contrast,

a CORBA IDL compiler generates the marshaling and unmarshaling code, so that developers do

not need to write (and maintain) such low-level code.



2.6 Scalability

The flexible, server-side infrastructure of CORBA (Chapter 5) makes it feasible to developservers that can scale from handling a small number of objects up to handling a virtually

unlimited number of objects. Obviously, scalability varies from one CORBA implementation to

another but, time and time again, real-world projects have demonstrated that a CORBA server

can scale to handle not just a huge amount of server-side data, but also high communicationloads from thousands of client applications. Most CORBA vendors will likely know of customers

who have tried a different middleware technology, found that it could not scale sufficiently well

and then switched to CORBA.

2.7 CORBA Success Stories

With such an impressive list of benefits as those discussed in this chapter, it is little wonder that

CORBA is being used successfully in many industries, including aerospace, consulting,

education, e-commerce, finance, government, health-care, human resources, insurance, ISVs,manufacturing, military, petrochemical, publishing, real estate, research, retail,

telecommunications, and utilities.

CORBA is used in everything from billing systems and multi-media news delivery to airport

runway illumination, aircraft radio control and the Hubble space telescope. Most of the worldstelephone systems, as well as the truly mission-critical systems operated by the worlds biggest banks, are built on CORBA.

A discussion about real-world projects that have benefitted from the use of CORBA is outside

the scope of this book.However, many CORBA success stories are available on various web

sites. For example, you can find over 300 CORBA success stories on www.corba.org. The websites of some CORBA vendors also contain more detailed success stories.



Implementation Steps:

CORBA object implementations are completely invisible to their clients. A client can

only depend on the IDL interface. In the Java programming language, or C++, this is not

the case. The user of an object declares variables by a class name; doing so makes thecode depend on much more than just the interface. The client depends on the object

implementation programming language, the name of the class, the implementation class

hierarchy, and, in C++, even the object layout.

The complete encapsulation for CORBA objects means the object implementor has much

more freedom. Object implementations can be provided in a number of supportedprogramming languages. This is not necessarily the same one the clients are written in.

(Of course, here everything is in the Java programming language, but CORBA doesnotrequire this.)

The same interface can be implemented in multiple ways. There is no limit. In the stock

example, the following are possible implementations of the Stock interface:

y A stock implementation class written in the Java programming language that

obtains values from a commercial feedy A stock implementation class written in C++ that accesses a database on the Internet

y A stock implementation written in Smalltalk that guesses stock prices

Step 1: Define the interface:

Hello.idl

moduleHelloApp {

interfaceHello {

string sayHello();

};};

Step 2: Map Hello.idl to Java:Use the idlj compiler (J2SE 1.3)

idlj fall Hello.idl

This will generate:

_HelloImplBase.java (server skeleton)

HelloStub.java (client stub, or proxy)Hello.java

HelloHelper.java,HelloHolder.java

HelloOperations.java

Step 3: Implement the interface:

Implement the servant:

import HelloApp.*;classHelloServant extends _HelloImplBase {

public String sayHello() {return \nHello There\n;

}

}

Step 4: Implement the server:

Import statements:



import org.omg.CosNaming.*;

import org.omg.CosNaming.NamingCotextPackage.*;import org.omg.CORBA.*;

classHelloServer {

public static void main(String argv[]) {

try {

Create and initialize the ORB:

ORB orb = ORB.init(argv, null);

Create the servant and register it with ORBHelloServant helloRef = newHelloServant();

orb.connect(helloRef);

Get the root NamingConext:org.omg.CORBA.Object objRef =

orb.resolve_initial_references(NameService);

NamingContext ncRef =

NamingContect Helper.narrow(objRef);

Bind the object reference in naming

NameComponent nc = new

NameComponent("Hello", " ");

NameComponent path[] = {nc};ncRef.rebind(path, helloRef);

Wait for invocations from clients:

java.lang.Object sync =new java.lang.Object();

synchronized(sync) {

sync.wait();}

Catch the exceptions

} catch(Exception e) {

System.err.println("ERROR: " + e);

e.printStackTrace(System.out);} // end catch

} // end main()

} // end class

Step 5: Write a client:

Import statements:

import HelloApp.*;import org.omg.CosNaming.*;

import org.omg.CORBA.*;classHelloClient {

public static void main(String argv[]){

try {

Create and initialize the ORB:

ORB orb = ORB.init(argv, null);



Create the root naming context:

org.omg.CORBA.Object objRef =orb.resolve_initial_references("NameService");NamingContext ncRef =

NamingContext Helper.narrow(objRef);

Resolve the object reference in naming:NameComponent nc =

new NameComponent("Hello", " ");

NameComponent path[] = {nc};

Hello helloRef =

HelloHelper.narrow(ncRef.resolve(path));

Call the object:

StringHello = helloRef.sayHello();

System.out.println(Hello);

Catch exception:

} catch(Exception e) {

System.out.println("ERROR : " + e);e.printStackTrace(System.out);} } } // end catch, main, class

Step 6: Run the application:Run the naming service:

prompt> tnameserver

Run the server

prompt> javaHelloServerRun the client

prompt> javaHelloClient

Hello There prompt>



Java RMI & CORBA

A comparison of two competing technologies

With the introduction of CORBA support to Java (as of version 1.2), developers now face thequestion of whether to continue to use remote method invocation (RMI), or make a move to

CORBA. The choice is made more difficult if your applications are already written in RMI -

considerable effort might have to be made to convert to CORBA. Is it worth the move? Thisarticle discusses the pros and cons, and evaluates the potential of these two technologies.What is Remote Method Invocation?

Remote method invocation allows Java developers to invoke object methods, and have them

execute on remote Java Virtual Machines (JVMs). Under RMI, entire objects can be passed andreturned as parameters, unlike many remote procedure call based mechanisms which require

parameters to be either primitive data types, or structures composed of primitive data types.That means that any Java object can be passed as a parameter - even new objects whose class

has never been encountered before by the remote virtual machine.

This is an exciting property, because it means that new code can be sent across a network and

dynamically loaded at run-time by foreign virtual machines. Java developers have a greaterfreedom when designing distributed systems, and the ability to send and receive new classes is

an incredible advantage. Developers don't have to work within a fixed codebase - they cansubmit new classes to foreign virtual machines and have them perform different tasks.When

working with remote services, RMI clients can access new versions of Java services as they are

made available - there's no need to distribute code to all the clients that might wish to connect.While code can be accessed from a local or remote file-system, it can also be accessed via a web

server, making distribution easier. RMI also supports a registry, which allows clients to perform

lookups for a particular service. The following diagram shows the interaction between different

components of an RMI system. Clients that know about a service can look up its location from aregistry and access the service. If a new class is required, it can be downloaded from a web

server.

Client connects to a registry server, accesses a RMI service, and downloads new code as

required from a web server.

Remote method invocation has a lot of potential, from remote processing and load sharing of

CPU's to transport mechanisms for higher level tasks, such as mobile agents which execute onremote machines(Reilly, 1998). Because of the flexibility of remote method invocation, it has

become an important tool for Java developers when writing distributed systems. However,there are many legacy systems written in C/C++, Ada, Fortran, Cobol, and other exoticlanguages. If legacy systems need to interface with your RMI systems, or your RMI systems need

to interface with them, problems can occur. RMI is Java specific, and you'll need to write a

bridge between older systems. Additionally, if you or your company plans on using otherlanguages in the future, you may also find yourself in a bind because of RMI's tie to Java - one

day Java itself may become a legacy platform.Writing interfaces to legacy systems isn't my idea

of fun programming!



What is CORBA?

Common Object Request Broker Architecture (CORBA) is a competing distributed systemstechnology that offers greater portability than remote method invocation. Unlike RMI, CORBAisn't tied to one language, and as such, can integrate with legacy systems of the past written in

older languages, as well as future languages that include support for CORBA. CORBA isn't tied to

a single platform (a property shared by RMI), and shows great potential for use in the future.

That said, for Java developers, CORBA offers less flexibility, because it doesn't allow executablecode to be sent to remote systems.

CORBA services are described by an interface, written in the Interface Definition Language

(IDL). IDL mappings to most popular languages are available, and mappings can be written forlanguages written in the future that require CORBA support. CORBA allows objects to make

requests of remote objects (invoking methods), and allows data to be passed between tworemote systems. Remote method invocation, on the other hand, allows Java objects to be passed

and returned as parameters. This allows new classes to be passed across virtual machines for

execution (mobile code). CORBA only allows primitive data types, and structures to be passed -

not actual code.Under communication between CORBA clients and CORBA services, method calls are passed to

Object Request Brokers (ORBs). These ORBs communicate via the Internet Inter-ORB Protocol

(IIOP). IIOP transactions can take place over TCP streams, or via other protocols (such as

HTTP), in the event that a client or server is behind a firewall. The following diagram shows aclient and a servant communicating.

CORBA client sends a request through its

local ORB to a remote ORB's servant

CORBA servant sends back a response to a

remote ORB

RMI vs CORBA

Comparing RMI and CORBA doesn't reveal an optimum solution - one is not "better" than the

other. The properties of these two technologies lend themselves to different situations. Acomparison of RMI and CORBA helps to highlight individual strengths and weaknesses, but the

applicability of one technology over the other depends largely on the purposes for which it is tobe used, the experience of the developers who will design, implement and maintain the

distributed system, and whether non-Java systems are intended to access the system now or in

the future.

RMI pros and cons

Remote method invocation has significant features that CORBA doesn't possess - most notably

the ability to send new objects (code and data) across a network, and for foreign virtual

machines to seamlessly handle the new objects (Reilly, D). Remote method invocation has beenavailable since JDK 1.02, and so many developers are familiar with the way this technologyworks, and organizations may already have systems using RMI. Its chief limitation, however, is

that it is limited to Java Virtual Machines, and cannot interface with other languages.

Remote method invocation

Pros Cons

Portable across many platforms Tied only to platforms with Java support



Can introduce new code to foreign JVMs Security threats with remote code execution,and limitations on functionality enforced by

security restrictions

Java developers may already have experiencewith RMI (available since JDK1.02)

Learning curve for developers that have noRMI experience is comparable with CORBA

Existing systems may already use RMI - thecost and time to convert to a new technology

may be prohibitive

Can only operate with Java systems - nosupport for legacy systems written in C++, Ada,

Fortran, Cobol, and others (including futurelanguages).

CORBA pros and cons

CORBA is gaining strong support from developers, because of its ease of use, functionality, and

portability across language and platform (Reilly, D). CORBA is particularly important in largeorganizations, where many systems must interact with each other, and legacy systems can't yet

be retired. CORBA provides the connection between one language and platform and another - its

only limitation is that a language must have a CORBA implementation written for it. CORBA alsoappears to have a performance increase over RMI, which makes it an attractive option for

systems that are accessed by users who require real-time interaction (Morgan, 1997).

Common Object Request Broker Architecture

Pros Cons

Services can be written in many different

languages, executed on many different

platforms, and accessed by any language with

an interface definition language (IDL) mapping.

Describing services require the use of an

interface definition language (IDL) which must

be learned. Implementing or using services

require an IDL mapping to your requiredlanguage - writing one for a language that isn't

supported would take a large amount of work.

With IDL, the interface is clearly separated

from implementation, and developers cancreate different implementations based on the

same interface.

IDL to language mapping tools create code

stubs based on the interface - some tools maynot integrate new changes with existing code.

CORBA supports primitive data types, and awide range of data structures, as parameters

CORBA does not support the transfer of objects, or code.

CORBA is ideally suited to use with legacy

systems, and to ensure that applicationswritten now will be accessible in the future.

The future is uncertain - if CORBA fails to

achieve sufficient adoption by industry, thenCORBA implementations become the legacysystems.

CORBA is an easy way to link objects and

systems together

Some training is still required, and CORBA

specifications are still in a state of flux.

CORBA systems may offer greater performance Not all classes of applications need real-time

performance, and speed may be traded off

against ease of use for pure Java systems.

Summary

Functionality to some degree, they each possess strengths that outshine the other for particular

tasks. A careful evaluation of the intended use of RMI or CORBA is required, to determine which

technology is the most appropriate. There aren't any hard and fast rules that can be applied, andthere is no clear victor in the battle for the minds and hearts of developers. Time will tell which

technology (if any) becomes the more dominant, and in the immediate future both will An

examination of these two technologies shows that, while they do overlap in continue to play a

role.



COMPARISON B/W CORBA AND OTHER TECHNOLOGY:-

In the beginning there was RPC..

The first distributed computing technology to gain widespread use was the Remote Procedure

Call (RFC 1831) commonly known as RPC. RPC is designed to be as similar to making local

procedure calls as possible. The idea behind RPC is to make a function call to a procedure in

another process and address space either on the same processor or across the network on

another processor without having to deal with the concrete details of how this should be done

besides making a procedure call.

CORBA

A CORBA application usually consists of an Object Request Broker (ORB), a client and a server.

An ORB is responsible for matching a requesting client to the server that will perform the

request, using an object reference to locate the target object.When the ORB examines the object

reference and discovers that the target object is remote, it marshals the arguments and routes

the invocation out over the network to the remote object's ORB. The remote ORB then invokes

the method locally and sends the results back to the client via the network. There are many

optional features that ORBs can implement besides merely sending and receiving remote

method invocations including looking up objects by name, maintaining persistent objects, and

supporting transaction processing. A primary feature of CORBA is its interoperability between

various platforms and programming languages.

DCOM/COM+

Distributed Component Object Model (DCOM)is the distributed version of Microsoft's COM

technology which allows the creation and use of binary objects/components from languages

other than the one they were originally written in, it currently supports Java(J++),C++, Visual

Basic, JScript, and VBScript. DCOM works over the network by using proxy's and stubs. When

the client instantiates a component whose registry entry suggests that it resides outside the

process space, DCOM creates a wrapper for the component and hands the client a pointer to the

wrapper. This wrapper, called a proxy, simply marshals methods calls and routes them across

the network. On the other end, DCOM creates another wrapper, called a stub, which unmarshals

methods calls and routes them to an instance of the component.

Java RMI

Remote Method Invokation (RMI) is a technology that allows the sharing of Java objects

between Java Virtual Machines (JVM) across a network. An RMI application consists of a server

that creates remote objects that conform to a specified interface, which are available for method

invocation to client applications that obtain a remote reference to the object. RMI treats a

remote object differently from a local object when the object is passed from one virtual machine

to another. Rather than making a copy of the implementation object in the receiving virtual

machine, RMI passes a remote stub for a remote object. The stub acts as the local representative,

or proxy, for the remote object and basically is, to the caller, the remote reference. The caller

invokes a method on the local stub, which is responsible for carrying out the method call on the

remote object. A stub for a remote object implements the same set of remote interfaces that the

remote object implements. This allows a stub to be cast to any of the interfaces that the remote



object implements. However, this also means that only those methods defined in a remote

interface are available to be called in the receiving virtual machine.



The Future Scope of CORBA and CORBA Research

We believe the future of CORBA is very promising, particularly for real-time systems. Real-time

system development strategies will migrate towards those used for ``mainstream'' systems to

achieve lower development cost and faster time to market.W

e have seen real-time softwaredevelopment projects that have lagged in terms of design and development methodologies (and

languages) by decades. These projects are extremely costly to evolve and maintain. They are so

specialized that they cannot be adapted to meet new market opportunities.

The flexibility and adaptability offered by CORBA make it very attractive for use in RT systems.

If the real-time challenges can be overcome, and our progress so far shows that they can, then

the use of Real-time CORBA is compelling. Moreover, the solutions to these challenges will be

sufficiently complex, yet general, that it will be well worth re-applying them to other projects.

In addition, CORBA can be adapted to ``niche'' markets, e.g., the RTOS market, that aren't well

covered by more traditional major players, e.g., Sun, Microsoft, IBM. In this sense, CORBA has an

advantage over other DOC technologies (such as DCOM and Java RMI) since it can be integrated

into a wider range of platforms, i.e., it's open!

case study on corba

Documents