A Comparison of Jini
and CORBA
Andrew See
Liyuan Yu
Zhongying Wang
Michael Collins
Outline

Introduction
 Motivation
 Overview

Jini
 Background
 Design/Implementation

CORBA
 Background
 Design/Implementation

Comparisons
 Architectural Comparison
 Ease of use
 Performance
 Reusability
Motivation




Middleware is important for distributed
computing
Jini & CORBA are two solutions
Jini & CORBA differ in subtle ways
We want to compare Jini and CORBA:
 Conceptual

Architectural Comparison
 Practical


Performance study
Reusability of an example system.
Overview


Game project
Develop text based distributed game system
 Limited
time: no fancy graphics
 Fair comparison: easy to express in both Jini &
CORBA  use strings only


Variety of games in same network.
Use name service of Jini & CORBA
Jini
Jini Background
Embedded hardware is network-centric,
not disk-centric
 Networks are dynamic; so is Jini
 Object interface; not network protocol
 Service: A network-accessible device that
provides a useful function
 Client: Any user who requests services

Runtime Architecture

Federation of services
 No

central authority
Lookup Service
 Directory
of currently available services
 Services can be searched by clients
 Execution of services is independent of Jini
 As backup, Jini also allows network protocol
How Jini Works
Separation of Interface &
Implementation

Services may grant varying access to
clients
 Entire
service is downloaded and run locally
 Service object is a proxy to remote server

Methods are remote calls to service, which actually
does the work
 Both
local and remote objects share work
Separation of Interface &
Implementation


Client is not required to know network protocol
between proxy & service
Service responsible for service object; may
communicate using RMI, CORBA, DCOM, etc.
Jini Program Design

Player
 One

player for all Games
Games
 Separate
communication from game specific
rules
 Generalize common game tasks
Add/remove a player
 Take a turn
 Update Player state

Design – Games
Interface
GameProxy
Interface
Game
Interface
RemoteGame
BasicGameProxy
AbstractGame
TurnBasedGame
HangmanProxy BlackjackProxy
GuessingGame
Hangman
Blackjack
Design – Players
Interface
Player
PlayerImpl
(terminal based)
GuiPlayer
(GUI based)
Terminal and GUI
based clients have
same functionality.
Implementation
Lease
Jini
name service
Register
GameProxy
GameProxy
Lookup
Server
Remote Game
Player
addPlayer,
TakeTurn
addPlayer,
GameProxy TakeTurn
(local processing)
Implementation – Code samples
 Creating the server-side object:
Game impl = new GuessingGame();
RemoteGame implProxy =
(RemoteGame)exporter.export(impl);
 Creating the proxy:
smartProxy = new BasicGameProxy(implProxy);
 Registering the proxy:
ServiceItem item = new ServiceItem(null, smartProxy,
attrs);
…
reg = registrar.register(item, Lease.FOREVER);
Implementation – Code samples
(cont.)

Player taking a turn:
Player:
protected void takeTurn(String action){
game.takeTurn(action,id); }
 GameProxy – this version just forwards to remote
implementation:
public void takeTurn(String action, Object id)
throws RemoteException {
impl.takeTurn(action,id); }
…
player.setGameData(data);


The rules for the game could be in the RemoteGame
implementation, or the Game Proxy, or split between
them.
CORBA
What is CORBA?



Common Object Request Broker Architecture
(CORBA) specification defines a framework for
object-oriented distributed applications..
It is an open standard for heterogeneous
computing.
Allows distributed programs in different
languages and different platforms to interact as
though they were in a single programming
language on one computer
Object Request Broker (ORB)

A software component that mediates transfer of
messages from a program to an object located
on a remote host.
0. Invocation ( with an
Client
ORB
Network
ORB
Server
object reference)
1.
Locate CORBA objects
and marshal parameters
invocation
0
1
CORBA Object
2.
Network Delay
3.
Unmarshal parameters
4.
Method Execution
5.
Result marshal
6.
Network Delay
7.
Result unmarshal
2
3
5
4
execution
6
7
CORBA Objects and IDL

Each CORBA object has a clearly defined interface
specified in CORBA interface definition language
(IDL).


Distributed objects are identified by object references,
which are typed by the IDL interfaces.
The interface definition specifies the member functions
available to the client without any assumption about the
implementation of the object.
Example of IDL
stockMarket.idl
module stockMarket{
interface StockServer {
float getStockValue (in string stockName);
void setStockValue (in string stockName, in long value);
}
…………..
}
No Implementation details in IDL
Stub and Skeleton

“Glue” that connects language-independent IDL interface
specifications to language –specific implementation
Client
Object
Object
Stub
Client
Stub
ORB

Automatically generated by IDL compiler
Design of the Game Project with CORBA

Centralized Version:
locate service
return server reference
locate service
Naming Service
return server reference
Player1
Player2
play
register Service
play
play
Game Server
Two Games:

Guess Game:
Two Games (Cont.)

HangMan:
Design Details--IDL
module GameApp{
interface Player
{
void displayMessage(in string m);
string getPlayerID();
};
interface GuessPlayer: Player
{
};
interface HangmanPlayer: Player
{
void drawMan(in long numWrong);
};
interface Server
{
void addPlayer(in Player p);
void removePlayer(in string playerID);
void startGame(in string playerID);
void QuitGame(in string playerID);
void takeTurn(in string playerID);
};
interface GuessServer: Server
{
void takeTurn(in long number, in string
playerID);
};
interface HangmanServer: Server
{
void takeTurn(in char w,in string word,
in string playerID);
};
};
Design Details--UML
<<interface>>
GuessPlayer
<<interface>>
HangmanPlayer
<<interface>>
GuessServer
<<interface>>
HangmanServer
+takeTurn()
+takeTurn()
<<interface>>
Interface1
<<interface>>
Player
+addPlayer()
+removePlayer()
+StartGame()
+QuitGame()
+takeTurn()
+getPlayerID()
+displayMessage()
implements
Automatically generated
by IDLtoJAVA compiler
implements
Java Implementation
GameServerImpl
PlayerImpl
+addPlayer()
+removePlayer()
+StartGame()
+QuitGame()
+takeTurn()
+getPlayerID()
+DisplayMessage()
GuessPlayer
HangmanPlayer
GuessServerImpl
HangmanServerImpl
+DrawMan()
+takeTurn()
+takeTurn()
Design of the Game Project with
CORBA

Decentralized Version
play
Player1
return server info
locate service
return server info
Naming Service
Player2
locate service
register Service
Return partner info
Create playerlist
Game Server
Return partner info
Design Details-IDL
module GameApp
{
interface Player
{
void receiveMessage(in string m);
string getPlayerID();
void startGame(in string data);
void startNewGame(in string data);
void QuitGame();
void response(string number, in string data);
void takeTurn();
};
interface Server
{
string addPlayer(in string p, in string ncRef);
};
};
Design Details- UML
Interface generated
By IDL Compile
Implement by
programmer
Notes for CORBA decentralized
version



The server do an only job: to find the partner
for each client. This function also can be
implemented by Name Service, So server is
not essential component.
The client need implement all the functions
for communicate each other and playing the
game
Adding more games, or changing the game
rules, need to Change class PlayerImpl,
which implements main functions for client,
and class server, and some minor changes to
other classes.
Comparison

Architectural comparison

Ease of use

Performance

Reusability
Architectural Comparison


CORBA used RMI
Jini uses anything



rmi, corba, tcp, etc.
Jini uses Sun’s services
CORBA uses many ORBs & separate services

Jini uses Java only
CORBA uses any language + IDL

Jini allows pass-by-value and pass-by-reference




pass-by-value uses object serialization
pass-by-reference uses RMI
CORBA only does pass-by-reference
Architectural Comparison –
Example


Events:
Jini


CORBA




sending event same as a method call to a RemoteEventListener
separate EventChannel is used to relay events
can be Push based or Pull based.
Push and Pull and interoperate
Conclusion:


Jini is simpler
CORBA is more powerful for events
Comparison – Events
Jini:
Register
Event
Source
CORBA:
Event
Source
RemoteEvent
Listener
notify(RemoteEvent)
connect
connect
Event
Channel
push
push
pull
pull
RemoteEvent
Listener
Ease of use


Similarities:
Registering with name service:
 Find
name server
 Add binding
 About the same in Jini & CORBA

Looking up a service/object
 Also

same in Jini & CORBA
Error Handling
 Code
needs to deal with possible network problems
Ease of use


Differences: Networking
In CORBA:
 IDL compiler does all network handling
 Interfaces are created for building the service

In Jini:
 Programer needs to make network
 Often put into configuration files

decisions
This reflects a difference in philosophy
 CORBA wants
remote objects to look same as local
objects
 Jini wants programmer to deal with network efficiently.
Performance
Simulated user input driven program:
 10 rounds of 100 method calls
 Jini version downloads code and runs
locally

Jini
Ave. Time w/ Ave. Time
lookup
w/o lookup
1958 ms
109 ms
CORBA
1163ms
241ms
Performance
Centralized Guessing game test
 Not randomized. Played 100 times

Time
Memory
Jini
CORBA
User
System
0.948
0.0625
2.73s
0.46s
Elapsed
Player
4.17
13MB
5.98
49MB
Server
Naming
13MB
12MB
48MB
54MB
Reusability

Method:




In both cases little change was needed
In CORBA:




methods added to IDL
game rules modified in Java
Networking and book-keeping did not change
In Jini:



Start with Guessing game
Reuse code to make a new game
Abstract classes dealt with networking and book-keeping
Subclasses implemented game rules
Conclusions:

Both Jini and CORBA facilitate reusable code