1. A Comparison of Jini and CORBA
Andrew See
Liyuan Yu
Zhongying Wang
Michael Collins

2. Outline Introduction Jini CORBA Comparisons Motivation Overview
Background
Design/Implementation
CORBA
Comparisons
Architectural Comparison
Ease of use
Performance
Reusability

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

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

5. Jini

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

7. Runtime Architecture Federation of services Lookup Service
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

8. How Jini Works

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

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

11. Jini Program Design Player Games One player for all Games
Separate communication from game specific rules
Generalize common game tasks
Add/remove a player
Take a turn
Update Player state

12. Design – Games Interface GameProxy Interface Game Interface RemoteGame
BasicGameProxy
AbstractGame
TurnBasedGame
HangmanProxy
BlackjackProxy
GuessingGame
Hangman
Blackjack

13. Design – Players Interface Player PlayerImpl (terminal based)
GuiPlayer
(GUI based)

14. Terminal and GUI based clients have same functionality.

15. Implementation Lease Jini name service Register GameProxy GameProxy
Server
Lookup
Remote Game
Player
addPlayer,
TakeTurn
addPlayer,
TakeTurn
GameProxy
(local processing)

16. 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);

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

18. CORBA

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

20. 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 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
Client
ORB
ORB
Server
Network
invocation 1
CORBA Object 2 3 4
execution 5 6 7

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

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

23. Stub and Skeleton
“Glue” that connects language-independent IDL interface specifications to language –specific implementation
Automatically generated by IDL compiler
Client
ORB
Object
Stub

24. Design of the Game Project with CORBA
Centralized Version:

25. Two Games:
Guess Game:

26. Two Games (Cont.)
HangMan:

27. 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);

28. Design Details--UML

29. Design of the Game Project with CORBA
Decentralized Version
Player1
return server info
locate service
Game Server
Player2
Return partner info
Create playerlist
play
Naming Service
register Service

30. 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);

31. Design Details- UML Interface generated By IDL Compile Implement by
programmer

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

33. Comparison Architectural comparison Ease of use Performance
Reusability

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

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

36. Comparison – Events Jini: Register Event Source RemoteEvent Listener
notify(RemoteEvent)
connect
connect
CORBA:
Event
Channel
RemoteEvent
Listener
Event
Source
push
push
pull
pull

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

38. Ease of use Differences: Networking In CORBA: In Jini:
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.

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

40. 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
48MB
Naming
12MB
54MB

41. Reusability Method: In both cases little change was needed In CORBA:
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