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 specific implementation 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:

Client
REQUEST

Server
RESPONSE

re

OBJECT BUS

ORB

ORB

ORB (Object Request Broker):

y y y y Handles all communication among objects Each host (machine) has its own ORB ORBs know how to talk to each other ORB also provides basic services to client

Functions of the Object Request Broker:

y y y y Find the object implementation for the request Prepare the object implementation to receive the request Communicate the data making up the request 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 CORBA objects and vice versa y Skeleton  lives on server  receives requests from stub and talks to true remote object  delivers response to stub

What is Corba good for?

y y y y Developing distributed applications Locating remote objects on a network Sending messages to those objects Common interface for transactions, security, etc.

Client vs Server:
y y y In CORBA, a client is a client relative to a particular object i.e. an object with a reference to a server object A client may also act as a server if it has an IDL and stubs and skeletons 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 clients y CORBA objects o A "virtual" entity capable of being located by an ORB. Allows requests to be invoked on it y Servants o The programming language entity that implements one or more CORBA objects y 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 specific target 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 types Most 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 Char o 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, are defined 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 Object life cycle Description Defines how CORBA objects are created, removed, moved,

and copied Naming Defines how CORBA objects can have friendly symbolic names Decouples the communication between distributed objects Provides arbitrary typed n-ary relationships between CORBA objects Coordinates the transformation of CORBA objects to and from external media Coordinates atomic access to CORBA objects Provides a locking service for CORBA objects in order to ensure serializable access Supports the association of name-value pairs with CORBA objects Supports the finding of CORBA objects based on properties describing the service offered by the object Supports queries on objects

Events Relationships

Externalization

Transactions Concurrency Control

Property

Trader

Query

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 The Java 2 ORB Description The Java 2 ORB comes with Sun's Java 2 SDK. It is missing several features. 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. A popular Java ORB from Iona Technologies. A popular application server with an ORB from IBM. 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.

VisiBroker for Java

OrbixWeb WebSphere Netscape Communicator

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 StockPresentation A distributed object that represents a particular stock. A distributed object in the GUI that presents the stock data to the user for a particular stock. A distributed object that represents the alarm set by the user. A distributed object in the GUI that presents the alarm going off to the user.

Alarm

AlarmPresentation

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

Benefits of Corba technology:

y y y y y y y

Maturity Open standard Wide platform support Wide language support Efficiency Scalability 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 OMG s 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 capabilities such as transactions, security, Naming and Trading services, messaging and publish-subscribe services that 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 to another 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 proprietary middleware 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, CORBA was designed with the goal of making it easy to integrate with other technologies. Indeed, the CORBA specification explicitly tackles integrations with TMN, SOAP, Microsoft s (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 J2EE and 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/390 and Fujitsu Global Server mainframes, numerous variants of UNIX (including Linux), Windows, AS/400, Open VMS, Apple s OS X and several embedded operating systems. There are very few other 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 use of several programming languages. Likewise, the older an organization is, the higher the likelihood 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 extreme case 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 those vendors 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 marshaldata (that is, convert data from programming-language types into a binary buffer that can be transmitted) efficiently. Many other middleware technologies also 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, which is efficient. However, this requires that developers write the marshaling code that copies programming-language types into the binary buffers prior to transmission, and the unmarshaling 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 develop servers 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 communication loads 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 world s telephone 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 web sites 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 the code 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 supported programming 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 does notrequire 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 feed y 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 module HelloApp { interface Hello { 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.*; class HelloServant 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.*; class HelloServer { 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 ORB HelloServant helloRef = new HelloServant(); orb.connect(helloRef); Get the root NamingConext: org.omg.CORBA.Object objRef = orb.resolve_initial_references( NameService ); NamingContext ncRef = NamingContectHelper.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.*; class HelloClient { 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 = NamingContextHelper.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: String Hello = 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> java HelloServer Run the client prompt> java HelloClient 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 the question 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? This article 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 and returned 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 greater freedom 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 can submit 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 a registry 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 on remote 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 exotic languages. 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 other languages 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 systems technology that offers greater portability than remote method invocation. Unlike RMI, CORBA isn'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 executable code 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 for languages 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 two remote 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 a client and a servant communicating.

CORBA client sends a request through its CORBA servant sends back a response to a local ORB to a remote ORB's servant 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. A comparison 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 to be 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 been available since JDK 1.02, and so many developers are familiar with the way this technology works, 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 Portable across many platforms Cons 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 Learning curve for developers that have no RMI experience is comparable with CORBA Can only operate with Java systems - no support for legacy systems written in C++, Ada, Fortran, Cobol, and others (including future languages).

Java developers may already have experience with RMI (available since JDK1.02) Existing systems may already use RMI - the cost and time to convert to a new technology may be prohibitive

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 large organizations, 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 also appears 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 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. Cons 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 required language - writing one for a language that isn't supported would take a large amount of work. IDL to language mapping tools create code stubs based on the interface - some tools may not integrate new changes with existing code. CORBA does not support the transfer of objects, or code. The future is uncertain - if CORBA fails to achieve sufficient adoption by industry, then CORBA implementations become the legacy systems. Some training is still required, and CORBA specifications are still in a state of flux.

With IDL, the interface is clearly separated from implementation, and developers can create different implementations based on the same interface. CORBA supports primitive data types, and a wide range of data structures, as parameters CORBA is ideally suited to use with legacy systems, and to ensure that applications written now will be accessible in the future. CORBA is an easy way to link objects and systems together

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, and there 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. We have seen real-time software development 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!