A Comparison of Jini and CORBA

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

2. Outline • Introduction • Motivation • Overview • Jini • Background • Design/Implementation • CORBA • Background • Design/Implementation • 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 • 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 • 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

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

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

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 = newBasicGameProxy(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 0 CORBA Object 1 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. Client Object Object Stub Client Stub ORB Stub and Skeleton • “Glue” that connects language-independent IDL interface specifications to language –specific implementation • Automatically generated by IDL compiler

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

25. Two Games: • Guess Game:

26. Two Games (Cont.) • HangMan:

27. 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--IDL

28. Design Details--UML

29. Design of the Game Project with CORBA Decentralized Version play return server info return server info Player1 Player2 locate service locate service Return partner info Create playerlist Return partner info Game Server 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: • 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

40. Performance • Centralized Guessing game test • Not randomized. Played 100 times

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