a comparison of jini and corba andrew see liyuan yu zhongying wang michael collins
TRANSCRIPT
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 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
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
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.
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
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); };
};
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.
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