A Comparison of Jini and CORBA

Andrew SeeLiyuan YuZhongying WangMichael 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 servicesNo central authority

Lookup ServiceDirectory of currently available servicesServices can be searched by clientsExecution of services is independent of JiniAs backup, Jini also allows network protocol

How Jini Works

Separation of Interface & Implementation

Services may grant varying access to clientsEntire service is downloaded and run locallyService 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

PlayerOne player for all Games

GamesSeparate communication from game specific rulesGeneralize common game tasks

Add/remove a player Take a turn Update Player state

Design – Games Interface

Game

InterfaceRemoteGame

InterfaceGameProxy

AbstractGameBasicGameProxy

TurnBasedGame

GuessingGame Hangman Blackjack

HangmanProxy BlackjackProxy

Design – Players

InterfacePlayer

PlayerImpl(terminal based)

GuiPlayer(GUI based)

Terminal and GUI based clients have same functionality.

Implementation

Server

Jininame service

Register

Lease

Remote Game

GameProxy

Player

Lookup

GameProxy

GameProxy

addPlayer,

TakeTurn

addPlayer,

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.

Network Server

12

3execution

4

5

67

0invocation

ORB ORBClient

0. Invocation ( with an object reference)

1. Locate CORBA objects and marshal parameters

2. Network Delay

3. Unmarshal parameters

4. Method Execution

5. Result marshal

6. Network Delay

7. Result unmarshal

CORBA Object

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 IDLstockMarket.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

Automatically generated by IDL compiler

Client

ORB

Object

ObjectStub

ClientStub

Design of the Game Project with CORBA

Centralized Version:

Nami ng Servi ce

Game Server

Pl ayer1

l ocate servi ce

return server reference

pl ay

pl ay

Pl ayer2

return server reference

regi ster Servi cepl ay

l ocate servi ce

Two Games: Guess Game:

Two Games (Cont.) HangMan:

Design Details--IDLmodule 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

+getPl ayerI D()+Di spl ayMessage()

PlayerImpl

GuessPl ayer

+DrawMan()

HangmanPlayer

+addPl ayer()+removePl ayer()+StartGame()+Qui tGame()+takeTurn()

GameServerImpl

+takeTurn()

GuessServerImpl

+takeTurn()

HangmanServerImpl

Automati cal l y generatedby I DLtoJ AVA compi l er

+getPl ayerI D()+di spl ayMessage()

<<i nterface>>Player

<<i nterface>>GuessPl ayer

<<i nterface>>HangmanPlayer

J ava I mpl ementat i on

+takeTurn()

<<i nterface>>GuessServer

+takeTurn()

<<i nterface>>HangmanServer

+addPl ayer()+removePl ayer()+StartGame()+Qui tGame()+takeTurn()

<<i nterface>>Interface1

i mpl ements i mpl ements

Design of the Game Project with CORBA

Decentralized Version

Naming Service

register Service

Player1 return server info return server info

locate service

Game Server

Player2

locate service

Return partner infoCreate playerlistReturn partner info

play

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 generatedBy 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

sending event same as a method call to a RemoteEventListener CORBA

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

Event Source

RemoteEventListener

Register

notify(RemoteEvent)

Jini:

Event Source

RemoteEventListener

CORBA:

EventChannel

connect

push

connect

push

pullpull

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 decisions Often put into configuration files

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

Ave. Time w/ lookup

Ave. Time w/o lookup

Jini 1958 ms 109 ms

CORBA 1163ms 241ms

Performance Centralized Guessing game test Not randomized. Played 100 times

Jini CORBA

Time User 0.948 2.73s

System 0.0625 0.46s

Elapsed 4.17 5.98

Memory Player 13MB 49MB

Server 13MB 48MB

Naming 12MB 54MB

Reusability Method:

Start with Guessing game Reuse code to make a new game

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: Abstract classes dealt with networking and book-keeping Subclasses implemented game rules

Conclusions: Both Jini and CORBA facilitate reusable code