Distributed Systems
Session 5:
Common Object Request Broker,
(CORBA)
Christos Kloukinas
Dept. of Computing
City University London
© City University London, Dept. of Computing
Distributed Systems / 5 - 1
0.0 Review: RMI

RMI – Remote Method Invocation
» RPC in Java Technology and more
» Concrete programming technology
» Designed to solve the problems of writing and organizing
executable code
» Native to Java, an extension of core language
» Benefits from specific features of Java
– Object serialization
– Portable, downloadable object implementations
– Java interface definitions
© City University London, Dept. of Computing
Distributed Systems / 5 - 2
0.1 RMI: Benefits
Invoke object methods, and have them execute on
remote Java Virtual Machines (JVMs)
 Entire objects can be passed and returned as
parameters

» Unlike many other remote procedure call based
mechanisms requiring either primitive data types as
parameters, or structures composed of primitive data
types

New Java objects can be passed as a parameter
» Can move behavior (class implementations) from client
to server and server to client
© City University London, Dept. of Computing
Distributed Systems / 5 - 3
0.2 RMI: Benefits

Enables use of Design Patterns
» Use the full power of object oriented technology in
distributed computing, such as two- and three-tier systems
(pass behavior and use OO design patterns)

Safe and Secure
» RMI uses built-in Java security mechanisms

Easy to Write/Easy to Use
» A remote interface is an actual Java interface

Distributed Garbage Collection
» Collects remote server objects that are no longer
referenced by any client in the network
© City University London, Dept. of Computing
Distributed Systems / 5 - 4
0.3 RMI: Implementation
© City University London, Dept. of Computing
Distributed Systems / 5 - 5
0.4 Developing RMI

Define a remote interface
» define a remote interface that specifies the signatures of
the methods to be provided by the server and invoked by
clients
» It must be declared public, in order for clients to be able
to load remote objects which implement the remote
interface.
» It must extend the Remote interface, to fulfill the
requirement for making the object a remote one.
» Each method in the interface must throw a
java.rmi.RemoteException.
© City University London, Dept. of Computing
Distributed Systems / 5 - 6
Developing RMI
Implement the remote interface
 Develop the server

Create an instance of the RMISecurityManager and install it
Create an instance of the remote object
Register the object created with the RMI registry

Develop the client
– First obtain a reference to the remote object from the RMI
registry
© City University London, Dept. of Computing
Distributed Systems / 5 - 7
Developing RMI

Running the application
»
»
»
»
Generate stubs and skeletons - rmic
Compile the server and the client - javac
Start the RMI registry - rmiregistry
Start the server and the client
© City University London, Dept. of Computing
Distributed Systems / 5 - 8
Outline

1.0 The Object Management Group and Introduction

2.0 Object Management Architecture

3.0 CORBA Communication

4.0 Implementation, “Hello World” Example

5.0 RMI vs CORBA Comparison
© City University London, Dept. of Computing
Distributed Systems / 5 - 9
Remember: Conceptual Framework

Architecture.

Accessing components from programming
languages.

Interfaces to lower layers.

Component identification.

Service invocation styles.

Handling of failures.
© City University London, Dept. of Computing
Distributed Systems / 5 - 10
CORBA

Object management architecture.

Accessing remote objects.

ORB interface.

Object identification

Activation strategies.

Request vs. notification.

Handling of failures.
© City University London, Dept. of Computing
Distributed Systems / 5 - 11
1.0 The Object Management Group



The OMG is a non-profit consortium created in 1989 with
the purpose of promoting theory and practice of object
technology in distributed computing systems to reduce the
complexity, lower the costs, and hasten the introduction of
new software applications.
Originally formed by 13 companies, OMG membership
grew to over 500 software vendors, developers and users.
OMG realizes its goals through creating standards which
allow interoperability and portability of distributed object
oriented applications. They do not produce software or
implementation guidelines.
© City University London, Dept. of Computing
Distributed Systems / 5 - 12
1.1 CORBA
(Common Object Request Broker Architecture)
Specification by OMG of an OO infrastructure for
Distributed Computing.
 Defines Object Request Broker and IDL
 Enables Software interoperability across languages
and platforms
 Applicable to legacy, commercial-off-the-shelf(COTS)
integration and new software development
 CORBA is just a specification for creating and using
distributed Objects, it is an integration technology
NOT a programming language

© City University London, Dept. of Computing
Distributed Systems / 5 - 13
1.2 CORBA: A Specification
Takes care of cross-language issues
automatically
 Uses OMG IDL (Interface Definition Language


Runs over IIOP
(Internet Inter-Orb
Protocol)
© City University London, Dept. of Computing
Java
Client CORBA/IIOP
C++
Object
Cobol
CORBA/IIOP
Client
Java
Object
Distributed Systems / 5 - 14
1.3 CORBA Concepts

CORBA’s theoretical underpinnings are based on
three important concepts;
» An Object-Oriented Model
» Open Distributed Computing Environment
» Component Integration and Reuse

CORBA Provides
» Uniform access to services
» Uniform discovery of resources and object names
» Uniform error handling methods
» Uniform security policies
© City University London, Dept. of Computing
Distributed Systems / 5 - 15
1.4 . The OMG Object Model

The OMG Object Model defines common object semantics
for specifying the externally visible characteristics of objects
in a standard and implementation-independent way.

In this model clients request services from objects (which will also
be called servers) through a well-defined interface.
This interface is specified in OMG IDL (Interface Definition
Language). A client accesses an object by issuing a request to the
object.
The request is an event, and it carries information including an
operation, the object reference of the service provider, and actual
parameters (if any).


© City University London, Dept. of Computing
Distributed Systems / 5 - 16
© City University London, Dept. of Computing
Distributed Systems / 5 - 17
© City University London, Dept. of Computing
Distributed Systems / 5 - 18
1.5 About CORBA Objects

CORBA objects differ from typical objects in 3 ways
» CORBA objects can run on any platform.
» CORBA objects can be located anywhere
» CORBA Objects can be written in any language that has
an IDL mapping

A CORBA object is a virtual programming entity
that consists of an identity, an interface, and an
implementation which is known as a Servant.
» It is virtual in the sense that it does not really exist unless
it is made concrete by an implementation written in a
programming language
© City University London, Dept. of Computing
Distributed Systems / 5 - 19
1.6 Objects and Applications



CORBA applications are composed of objects.
Typically, there are many instances of an object of a single
type - for example, an e-commerce website would have many
shopping cart object instances, all identical in functionality but
differing in that each is assigned to a different customer, and
contains data representing the merchandise that its particular
customer has selected.
For other types, there may be only one instance. When a
legacy application, such as an accounting system, is wrapped
in code with CORBA interfaces and opened up to clients on
the network, there is usually only one instance.
© City University London, Dept. of Computing
Distributed Systems / 5 - 20
2.0 Object Management Architecture (OMA)
Application
Objects
CORBA
facilities
Object Request Broker
CORBA
services
© City University London, Dept. of Computing
Distributed Systems / 5 - 21
2.1 OMA Model
CORBA is based on the object model, derived
from the abstract core object model of OMG’s
OMA (Object Management Architecture)
 OMA groups objects into four categories

» CORBAservices
» CORBAfacilities
O
» CORBAdomain
M
» Application object
A
© City University London, Dept. of Computing
C
O
R
B
A
Distributed Systems / 5 - 22
2.2 CORBAservices

CORBAservices
» Provide basic functionality, that almost every object needs
– Naming Service-name binding ,associating names and references
– Event Service- asynchronous event notification
– Concurrency Control Service-mediates simultaneous access

CORBAfacilities (sometimes called Horizontal
CORBAfacilities)
» Between CORBAservices and Application Objects
» Potentially useful across business domains
– Printing, Secure Time Facility, Internationalization Facility, Mobile
Agent Facility.
© City University London, Dept. of Computing
Distributed Systems / 5 - 23
2.3 OMA model

Domain (Vertical) CORBAfacilities
» Domain-based and provide functionality for
specific domains such as telecommunications,
electronic commerce, or health care.

Application Objects
» Topmost part of the OMA hierarchy
» Customized for an Individual application, so do not
need standardization
© City University London, Dept. of Computing
Distributed Systems / 5 - 24
2.4 CORBA Architecture
Client
Dynamic
Invocation
Client
Stubs
Object Implementation
ORB
Interface
Server
Skeleton
Object
Adapter
ORB Core
© City University London, Dept. of Computing
Distributed Systems / 5 - 25
CORBA Architecture
Object Implementation
(Servant)
Client
Dynamic
Skeleton
Stub
Dynamic
Invocation
Static
Skeleton
Object
Adapter
ORB
Interface
Object Request Broker (ORB)
Interface identical for all ORB implementations
There maybe multiple object adapters
There are stubs and skeletons for each object type
ORB-dependent interface
© City University London, Dept. of Computing
Up-call interface
Normal call interface
Distributed Systems / 5 - 26
2.5 CORBA Architecture

A general CORBA request structure
A request consists of
•Target object
(identified by unique
object reference)
•Operation.
•Parameters (the input,
output, and in-out
parameters defined for the
operation; maybe specified
individually or as a list
IIOP
Request
•Optional request context
•Results (the results values
returned by operation)
Request from a client to an object implementation
© City University London, Dept. of Computing
Distributed Systems / 5 - 27
2.6 CORBA Architecture

CORBA is composed of five major components;
»
»
»
»
»
»
ORB,
IDL,
Dynamic Invocation Interface (DII),
Interface Repositories (IR),
Object Adapters (OA),
Inter-Orb Protocol (IIOP)

CORBA provides both static and dynamic interfaces to
its services

Happened because two strong proposals from HyperDesk and
Digital based on a Dynamic API & from SUN and HP based on a
static API. “Common” stands for a two-API proposal
© City University London, Dept. of Computing
Distributed Systems / 5 - 28
2.7 Object Request Broker, ORB


Core of CORBA, middleware that establishes the
client/server relationship between objects
This is the object manager in CORBA, the software that
implements the CORBA specification, (implements the
session, transport and network layers), provides object
location transparency, communication and activation, i.e
» Find object implementation for requests (provide location
transparency)
» Prepare the object implementation to receive request
» Communicate the data making up request.
(Vendors & Products: ORBIX from IONA, VisiBroker from Inprise,
JavaIDL from javasoft)
© City University London, Dept. of Computing
Distributed Systems / 5 - 29
2.8 CORBA Architecture: ORB

On the client side the ORB is responsible for
» accepting requests for a remote object
» finding the implementation of the object
» accepting a client-side reference to the remote object (converted to a
language specific form, e.g. a java stub object)
» Routing client method calls through the object reference to the object
implementation

On the Server side
»
»
»
»
lets object servers register new objects
receives requests from the client ORB
uses object’s skeleton interface to invoke the object activation method
Creates reference for new object and sends it back to client.
© City University London, Dept. of Computing
Distributed Systems / 5 - 30
2.9 CORBA Architecture: Stubs,Skeletons

Client Stub
» provides the static interfaces to object services. These precompiled stubs
define how clients invoke corresponding services on the server. From a
client’s perspective, the stub acts like a local call- it’s a local proxy for a
remote server object. Generated by the IDL compiler (there are as many
stubs as there are interfaces!)

Server Skeleton
» provides static interfaces to each service exported by the server.
Performance unmarshalling, and the actual method invocation on the
server object

ORB Interface
» Interface to few ORB operations common to all objects, e.g. operation
which returns an object’s interface type.
© City University London, Dept. of Computing
Distributed Systems / 5 - 31
2.10 CORBA Architecture: Servant
&Clients

Object -- This is a CORBA programming entity that consists of an
identity, an interface, and an implementation, which is known as a
Servant.

Servant -- This is an implementation programming language entity
that defines the operations that support a CORBA IDL interface.
Servants can be written in a variety of languages, including C, C++,
Java, Smalltalk, and Ada.

Client -- This is the program entity that invokes an operation on an
object implementation. Accessing the services of a remote object
should be transparent to the caller. Ideally, it should be as simple as
calling a method on an object. The remaining components help to
support this level of transparency.
© City University London, Dept. of Computing
Distributed Systems / 5 - 32
2.11 CORBA Architecture: DII

Dynamic Invocation Interface (DII)
» Static invocation interfaces are determined at compile
time, and they are presented to the client using stubs
» The DII allows client applications to use server objects
without knowing the type of objects at compile time
– Client obtains an instance of a CORBA object and makes
invocations on that object by dynamically creating requests.
» DII uses the interface repository to validate and retrieve
the signature of the operation on which a request is made
© City University London, Dept. of Computing
Distributed Systems / 5 - 33
2.12 CORBA Architecture: DSI

Dynamic Skeleton Interface (DSI)
» Server-side dynamic skeleton interface
» Allows servers to be written without having skeletons, or
compile time knowledge for which objects will be called
remotely
» Provides a runtime binding mechanism for servers that
need to handle incoming method calls for components
that do not have IDL-based compiled skeletons
» Useful for implementing generic bridges between ORBs
» Also used for interactive software tools based on
interpreters and distributed debuggers
© City University London, Dept. of Computing
Distributed Systems / 5 - 34
2.13 CORBA Architecture: IR

Interface Repository
» allows YOU to obtain and modify the descriptions of all
registered component interfaces(method supported,
parameters i.e method signatures)
» It is a run-time distributed database that contains machine
readable versions of the IDL interfaces
» Interfaces can be added to the interface repository
» Enable Clients to;
– locate an object that is unknown at compile time
– find information about its interface
– build a request to be forwarded through the ORB
© City University London, Dept. of Computing
Distributed Systems / 5 - 35
2.13 CORBA Architecture: OA

Object Adapter (OA) e.g (Basic-BOA or Portable-POA)
» Purpose:interface an object’s implementation with its ORB
» Primary way that an object implementation accesses services provided
by the ORB.
» Sits on top of the ORB’s core communication services and accepts
requests for service on behalf of server objects, passing requests to
them and assigning them IDs (object references)
» Registers classes it supports and their run-time instances with the
implementation repository
» In summary, its duties are:
– Object reference generation, and interpretation, method invocation,
security of interactions, and implementation of object activation and
de-activation
© City University London, Dept. of Computing
Distributed Systems / 5 - 36
2.14 Implementation Repository
Provides a run-time repository of information
about classes a server supports, the objects
that are instantiated and their IDs
 Also serves as a common place to store
additional information associated with
implementations of ORBS

» e.g. trace information, audit trails and other
administrative data
© City University London, Dept. of Computing
Distributed Systems / 5 - 37
2.15 Summary of CORBA Interfaces

Interface and Implementation Repositories
•All objects are defined in IDL by
specifying their interfaces
•Object definitions
(interfaces) are manifested as
objects in the interface
repository, compiled to stubs
and skeletons
Accesses
•Descriptions of object
implementations are
maintained as objects
in the implementation
repository
© City University London, Dept. of Computing
includes
includes
Decsribes
Distributed Systems / 5 - 38
2.16 Accessing Remote Objects
Client
Dynamic
Invocation
Client
Stubs
Object Implementation
ORB
Interface
Server
Skeleton
Object
Adapter
ORB Core
© City University London, Dept. of Computing
Distributed Systems / 5 - 39
2.17 Client Side
Clients perform requests using object references
Client
Clients May issue requests through
object interface stubs (static) or
dynamic invocation interface
(Dynamic)
Clients may access
general ORB services:
•Interface Repository
Dynamic
Invocation
Client
Stubs
ORB
Interface
•Context management
•List Management
•Request Management
© City University London, Dept. of Computing
Distributed Systems / 5 - 40
2.18 Implementation Side (Server side)

Implementations receive requests through
skeletons (without knowledge of invocation
approach)
The object Adapter provides for:
Object Implementation
•Management of references;
•Method invocation;
•authentication
•implementation registration
•activation/deactivation
© City University London, Dept. of Computing
ORB
Interface
Server
Skeleton
Object
Adapter
Distributed Systems / 5 - 41
3.0 CORBA Communication

CORBA Spec Neutral w.r.t network protocols
» CORBA specifies GIOP, a high level standard protocol for
communication between ORBs


Generalized Inter-ORB Protocol (GIOP) is a collection
of message requests an ORB can make over a network
GIOP maps ORB requests to different transports
» Internet Inter-ORB Protocol (IIOP) uses TCP/IP to carry the
messages, hence fits well into Internet world
» Environment Specific Inter-ORB Protocol (ESIOP) complements GIOP
enabling interoperability with environments not having CORBA support
© City University London, Dept. of Computing
Distributed Systems / 5 - 42
3.1 CORBA Communication

GIOP contains specifications for
» Common Data Representation (CDR)
» Message formats (Reply, Request, LocateReply,
LocateRequest, CancelRequest, etc)
» Message transport assumptions
– Connection-Oriented
– Reliable
– A Byte Stream Protocol
© City University London, Dept. of Computing
Distributed Systems / 5 - 43
3.2 Communication: Inter-Orb Architecture
CORBA IDL
Object Request
Semantics
Transfer and
Message Syntax
Transports
General Inter-ORB
Protocol (GIOP)
Internet
Inter-ORB
Protocol
(IIOP)
Others
for example
OSI and
IPX/SPX
TCP/IP
Internet
© City University London, Dept. of Computing
Distributed Systems / 5 - 44
© City University London, Dept. of Computing
Distributed Systems / 5 - 45
3.3 Other Features

CORBA Messaging
» CORBA 2.0 provides three different techniques for
operation invocations:
– Synchronous The client invokes an operation, then pauses,
waiting for a response
– Deferred synchronous The client invokes an operation then
continues processing. It can go back later to either poll or block
waiting for a response
– One-way The client invokes an operation, and the ORB provides
a guarantee that the request will be delivered. In one-way
operation invocations, there is no response
© City University London, Dept. of Computing
Distributed Systems / 5 - 46
3.4 New Features
» Two newer, enhanced mechanisms are introduced
– Callback The client supplies an additional object reference
with each request invocation. When the response arrives,
the ORB uses that object reference to deliver the response
back to the client
– Polling The client invokes an operation that immediately
returns a valuetype that can be used to either poll or wait for
the response
» The callback and polling techniques are available for
clients using statically typed stubs generated from IDL
interfaces (not for DII)
© City University London, Dept. of Computing
Distributed Systems / 5 - 47
4.0 Implementation
Implementation
© City University London, Dept. of Computing
Distributed Systems / 5 - 48
4.0 How to Write CORBA Applications
Create IDL
definition
load
Interface repository
idl
Example Servant
Server Skeleton
Client IDL Stub
is used by
Implement Client
Implement Servant
Object Adapter
instantiates
Implementation
repository
javac
javac
Start client
Start server
© City University London, Dept. of Computing
Server
Client
Distributed Systems / 5 - 49
4.1 Example: Hello world ID
module HelloApp
{
interface Hello
{
string sayHello();
};
};
© City University London, Dept. of Computing
Distributed Systems / 5 - 50
4.2 Example: Hello World Server
import HelloApp.*;
import org.omg.CosNaming.*;
import org.omg.CosNaming.NamingContextPackage.*;
import org.omg.CORBA.*;
Servant
class HelloServant extends _HelloImplBase {
public String sayHello() {
return "\nHello world !!\n";
}
Server Skeleton
}
public class HelloServer {
public static void main(String args[])
{
try{
// create and initialize the ORB
ORB orb = ORB.init(args, null);
// get the root naming context
org.omg.CORBA.Object objRef =
orb.resolve_initial_references("NameService");
NamingContext ncRef =
NamingContextHelper.narrow(objRef);
// bind the Object Reference in Naming
NameComponent nc = new NameComponent("Hello", "");
NameComponent path[] = {nc};
ncRef.rebind(path, helloRef);
Binding
// wait for invocations from clients
java.lang.Object sync = new java.lang.Object();
synchronized (sync) {
sync.wait();
}
// create servant and register it with the ORB
} catch (Exception e) {…}
HelloServant helloRef = new HelloServant(); }
orb.connect(helloRef);
}
© City University London, Dept. of Computing
ORB interface
Distributed Systems / 5 - 51
4.3 Example: Hello World Client
import HelloApp.*; import org.omg.CosNaming.*; import org.omg.CORBA.*;
public class HelloClient {
public static void main(String args[]) {
try{
ORB orb = ORB.init(args, null);
// create and initialize the ORB
// get 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 Hello server object and print results
String hello = helloRef.sayHello();
System.out.println(hello);
} catch (Exception e) {…}
© City}}University London, Dept. of Computing
Service Request
Casting
Distributed Systems / 5 - 52
4.4 Static vs. Dynamic Invocation

Static invocation: IDL operations must have
been defined before client can be developed.

Does not suit every application (Example?)

Dynamic invocation interface enables clients
to define operation invocations at run-time.

Interface repository can be used to ensure
that calls are type safe.
© City University London, Dept. of Computing
Distributed Systems / 5 - 53
4.5 ORB Interface

Object type Object.

Initialisation of object request broker.

Initialisation of client / server applications.

Programming interface to interface repository.
© City University London, Dept. of Computing
Distributed Systems / 5 - 54
4.6 Object Identification
Objects are uniquely identified by object identifiers.
 Object identifiers are persistent.
 Identifiers can be externalised (converted into
string) and internalised.
 Identifiers can be obtained

» from a naming or a trading service,
» by reading attributes,
» from an operation result or
» by internalising an externalised reference.
© City University London, Dept. of Computing
Distributed Systems / 5 - 55
© City University London, Dept. of Computing
Distributed Systems / 5 - 56
© City University London, Dept. of Computing
Distributed Systems / 5 - 57
4.7 Activation Strategies
A
D
A Shared Server
B Unshared Server
C Server per method
D Persistent server
B
C
Basic
Object
Adapter
© City University London, Dept. of Computing
Process
Object
Registration
Activation
Distributed Systems / 5 - 58
3.5 Request vs. Notification
IDL operations are handled synchronously.
 For notifications, it may not be necessary to
await the server, if operation does not

» have a return value,
» have out or inout parameters and
» raise specific exceptions.
Notification can be implemented as oneway
operations in IDL.
 Client continues after notification is delivered.

© City University London, Dept. of Computing
Distributed Systems / 5 - 59
3.5 Notification (Example)
/* person.idl */
enum sex_type {
FEMALE, MALE
};
struct Person {
string first_name;
string last_name;
sex_type sex;
string city;
};
© City University London, Dept. of Computing
interface PersonManager {
oneway void print(in
Person);
long store(in Person
pers);
Person load(in long
pers_id);
};
Distributed Systems / 5 - 60
3.6 Failures

CORBA operation invocations may fail for the
same reasons as RMIs.

Exceptions give detailed account why an
operation has failed.

System vs. application specific exceptions.
© City University London, Dept. of Computing
Distributed Systems / 5 - 61
CORBA AND JAVA
1997: RMI Introduced with JDK1.1
 1998: JavaIDL with JDK1.2 – Java ORB supporting
IIOP. ORB also supports RMI over IIOP  remote
objects written in the Java programming language
accessible from any language via IIOP
 CORBA provides the network transparency, Java
provides the implementation transparency

© City University London, Dept. of Computing
Distributed Systems / 5 - 62
4 Comparison

RMI architecture lacks interface repository (but
has reflection).

IDL and RMI allow for:
» inheritance,
» attributes and
» exceptions. (These three are missing in RPC)

IDL has multiple standardised language
bindings. RMI is part of JAVA, RPC goes with C
and C++
© City University London, Dept. of Computing
Distributed Systems / 5 - 63
4 Comparison (cont´d)

RMIs are lightweight.

Component identification is reflexive in IDL
and RMI, as opposed to RPC.

Basic object adapter provides more flexible
activation strategies.

Oneway operations can be used for
asynchronous notifications.
© City University London, Dept. of Computing
Distributed Systems / 5 - 64
4 Comparison (cont´d)

RMIs may be more efficient than CORBA
operation invocations.

RMI comes with JAVA, whilst you would have
to obtain a CORBA product (open-source
ones exist).
© City University London, Dept. of Computing
Distributed Systems / 5 - 65
6.2 RMI vs CORBA (ctd.)

Relatively speaking, RMI can be easier to master,
especially for experienced Java programmers, than
CORBA. CORBA is a rich, extensive family of
standards and interfaces, and delving into the
details of these interfaces is sometimes overkill for
the task at hand.
© City University London, Dept. of Computing
Distributed Systems / 5 - 67
6.3 RMI vs CORBA (ctd.)

CORBA is a more mature standard than RMI, and
has had time to gain richer implementations. The
CORBA standard is a fairly comprehensive one in
terms of distributed objects, and there are CORBA
implementations out there that provide many more
services and distribution options than RMI or
Java. The CORBA Services specifications, for
example, include comprehensive high-level
interfaces for naming, security, and transaction
services.
© City University London, Dept. of Computing
Distributed Systems / 5 - 68
6.4 The Bottom Line


So which is better, CORBA or RMI? Basically, it depends. If
you're looking at a system that you're building from scratch, with
no hooks to legacy systems and fairly mainstream requirements in
terms of performance and other language features, then RMI may
be the most effective and efficient tool for you to use.
On the other hand, if you're linking your distributed system to
legacy services implemented in other languages, or if there is the
possibility that subsystems of your application will need to
migrate to other languages in the future, or if your system depends
strongly on services that are available in CORBA and not in RMI,
or if critical subsystems have highly-specialized requirements that
Java can't meet, then CORBA may be your best bet.
© City University London, Dept. of Computing
Distributed Systems / 5 - 69