Your SlideShare is downloading. ×
RMI and CORBA Why both are valuable tools
Upcoming SlideShare
Loading in...5

Thanks for flagging this SlideShare!

Oops! An error has occurred.


Introducing the official SlideShare app

Stunning, full-screen experience for iPhone and Android

Text the download link to your phone

Standard text messaging rates apply

RMI and CORBA Why both are valuable tools


Published on

Published in: Technology

  • Be the first to comment

  • Be the first to like this

No Downloads
Total Views
On Slideshare
From Embeds
Number of Embeds
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

No notes for slide


  • 1. RMI and CORBA Why both are valuable tools by Brian Gilstrap with thanks to Mark Volkmann Brian Gilstrap 1
  • 2. Introduction • This talk is about RMI and CORBA, not “RMI vs CORBA” • It’ about using the right tool for the job s • RMI and CORBA have different “design centers”; as a result, they are good for solving different (but overlapping) sets of problems • This talk centers around Java Brian Gilstrap 2
  • 3. RMI & CORBA Characteristics RMI CORBA • Pure Java • Multi-language • Free • $$$ • Simple to use • Harder to use • Integrated into platform • Add-on • Object-oriented communication • Structured • Dynamic codebase communication • Performance is not as good • Static codebase (depending on application) • Performance is better • Less mature (but learned from (depending on application) CORBA issues/mistakes) • More mature (but 1st of its kind in the industry) • Maturing quickly • Maturing slowly Brian Gilstrap 3
  • 4. These characteristics result in Design Centers Free $$$$ Pure Java multi-language integrated into Java distributed add-on to Java object-oriented structured o-o communication communication dynamic codebase static codebase Brian Gilstrap 4
  • 5. RMI features/limitations • Pure Java – RMI is pure Java (no other languages), but it supports distributed OO computing in Java very well – Can still mix in socket communication and native code (JNI) to access non-Java (e.g. legacy) systems • this may be easier or harder than using CORBA, depending on the problem Brian Gilstrap 5
  • 6. RMI features/limitations (cont) • Free – comes as part of the Java Development Kit (JDK) and is part of the Java Runtime Environment (JRE) – no runtime costs, developer costs, etc. Brian Gilstrap 6
  • 7. RMI Features/Limitations (Cont) • Simple to use - providing remote access – extend “Remote” interface & handle exceptions – use the “rmic” utility to generate stubs & skeletons (produces ‘ .class’files) – registry provides bootstrap for finding remote objects • must know host Brian Gilstrap 7
  • 8. RMI Features/Limitations (Cont) • Simple to use - sending objects – implement “Serializable” interface – optionally specify codebase – automatic version mismatch detection Brian Gilstrap 8
  • 9. RMI Features/Limitations (Cont) • Integrated into platform – standard way of using RMI – source code is the same for any platform – bytecode is cross-platform just like other Java – remote method calls are nearly identical to normal method calls – distributed garbage collection preserves automatic memory management Brian Gilstrap 9
  • 10. RMI Features/Limitations (Cont) • Object-oriented communication – can easily send references to remotely accessible objects to other VMs • using the “Remote” interface – can easily send copies of objects to other VMs • using “Serializable” interface – can get more sophisticated • overriding “read/writeObject” • using “Externalizable” Brian Gilstrap 10
  • 11. RMI Features/Limitations (Cont) • Object-oriented communication (continued) – distributed garbage collection • allows server VMs to garbage collect unused objects/resources when those objects/resources are no longer needed Brian Gilstrap 11
  • 12. RMI Features/Limitations (Cont) • Dynamic codebase – can send not only the state information (field values) but also the implementation (bytecode) of objects across the network – very powerful • send code to be executed by the server as part of performing work – example: a search object for searching a datastore • send an agent to a remote site to do work • send an object to a server to be stored persistently • etc. Brian Gilstrap 12
  • 13. RMI Features: Dynamic Codebase VM 1 method call passing VM 2 “aFoo” 1 aFoo “I need class ‘Foo’” 2 here’ implementation s for class ‘Foo’ 3 Foo.class Foo.class codebase codebase Brian Gilstrap 13
  • 14. RMI Features: Dynamic Codebase (cont) VM 1 method call passing VM 2 “aFoo” 1 aFoo “I need class ‘Foo’” 2 here’ implementation s for class ‘Foo’ 3 Foo.class extends codebase to include remote sources of classes Foo.class codebase codebase Brian Gilstrap 14
  • 15. RMI Features/Limitations (Cont) • Performance – for designs which pass data only (no objects), and for which version mismatch detection is not needed, RMI performs more slowly that CORBA • exact numbers depend upon many things – platform – Java JIT/no-JIT – ORB vendor – problem domain – etc. – for designs which pass objects, RMI is currently the only ticket in town (CORBA can’ pass objects) t Brian Gilstrap 15
  • 16. RMI Features/Limitations (Cont) • Performance (continued) – performance can be improved by custom serialization code • allows default implementation with targeted tuning for the 80/20 rule – BUT • using RMI features to solve problems produces a different design and can reduce or eliminate performance differences • passing objects, version mismatch, and distributed garbage collection are important issues when building distributed systems Brian Gilstrap 16
  • 17. RMI Features/Limitations (Cont) • RMI is Maturing quickly 1/97 6/97 1/98 6/98 JDK 1.1; JDK 1.2b2; JDK 1.2; RMI RMI v2 beta RMI v2 (expected) Brian Gilstrap 17
  • 18. CORBA Features/Limitations • Multi-language – C (requires layering object-oriented concepts on top) – C++ – Smalltalk – Java - not yet standardized – COBOL – Ada Brian Gilstrap 18
  • 19. CORBA Features/Limitations (cont) • Not free – costs can be substantial • developer licenses (-$800+ per developer) • runtime licenses (cost varies with vendor) – standardized extensions (“Object services” in OMG-speak) add more costs Brian Gilstrap 19
  • 20. CORBA Features/Limitations (cont) • Harder to use – must • write IDL to provide interfaces and define data structures for passing information • transform IDL to Java stub & skeleton source code • compile stub/skeleton code to bytecode – different vendor’ stub/skeleton bytecodes s (‘.class’files) are not compatible – details of using CORBA are different for each vendor: changing ORB vendors requires changing source code (eek!) Brian Gilstrap 20
  • 21. CORBA Features/Limitations (cont) • Harder to use (continued) – more source code required to perform same tasks (vs. RMI) – no standard way to bootstrap communication • some vendor-specific options exist, but nothing standard across different vendors – no support for detecting software version mismatches • wing it or hand build it • most often, this isn’ handled and problems arise at t runtime, sometimes resulting in silent errors Brian Gilstrap 21
  • 22. CORBA features/limitations (cont) • Add-on to the language – does not dovetail with standard Java features • breaks the object-oriented model when doing distributed communication • no built-in support for flattening objects onto/off of the wire – must use pseudo-objects or do the flattening/inflating by hand • no distributed garbage collection – e.g. don’ know when server objects & resources are no t longer needed Brian Gilstrap 22
  • 23. CORBA features/limitations (cont) • Add-on to the language (continued) – BUT: Allows implementing in multiple languages • good for accessing legacy systems – especially if Java is not supported on the legacy platform • good for extending existing CORBA-based systems with Java • good for leveraging expertise in other languages – as long as there is a CORBA binding for that language Brian Gilstrap 23
  • 24. CORBA features/limitations (cont) • Structured communication – must define pseudo-objects using IDL and translated to data structures – can’ send objects t Brian Gilstrap 24
  • 25. CORBA features/limitations (cont) • Structured communication (continued) – there is substantial hand-coding to flatten/inflate a group of objects when sending their state information to a remote location stuff state IDL-defined inflate state A pA structures pA A’ B C pB pC pB pC B’ C’ IIOP D D’ pD pD Brian Gilstrap 25
  • 26. CORBA features/limitations (cont) • Structured communication (continued) – lack of support for sending objects hampers design options and results in more remote calls across the wire Book Order 1 remote call Book Order RMI Book 1 ... Book n Book 1 ... Book n “submit( aBookOrder )” “create BookOrder” bo1 • (n + 2) remote calls Book Order “add Book 1 to order bo1” ... IIOP ... “add Book n to order bo1” Book 1 Book n “submit order bo1” Brian Gilstrap 26
  • 27. CORBA features/limitations (cont) • Structured communication (continued) – assume an order for 3 books – we include marshalling/unmarshalling time – if 1 RMI call takes an average of 35 milliseconds (ms) – if 1 CORBA call takes • 21 ms => CORBA is •105 ms & RMI is 35 ms • 10 ms => CORBA is •50 ms & RMI is 35 ms • 6 ms => CORBA is •35 ms & RMI is 35 ms (numbers are illustrative only) Brian Gilstrap 27
  • 28. CORBA features/limitations (cont) • Static codebase – can’ send implementations across the wire, t therefore • can’ send previously unknown types of objects t where they are needed to make computation more efficient • can’ dynamically extend the behavior of running t VM – using DII only allows discovering new remote types and making remote method calls upon them Brian Gilstrap 28
  • 29. CORBA features/limitations (cont) • Performance – performance of CORBA IIOP is not as good as custom protocols provided by ORB vendors • this talk only discusses IIOP because inter-vendor support is important – traditional client/server speed is better in ORB implementations than in RMI/JDK 1.1.x. • how much better varies, depending on how the application is structured, what OS you are running, etc. Brian Gilstrap 29
  • 30. CORBA features/limitations (cont) • Performance (continued) – Compared to RMI, CORBA limits possible designs and removes at least some of the performance gain when including time for • marshalling/unmarshalling of objects into/out of IDL structures • more calls across the wire, which are substantially more costly than local calls • code to perform version mismatch detection • distributed garbage collection issues Brian Gilstrap 30
  • 31. CORBA features/limitations (cont) • CORBA is Maturing slowly CORBA IIOP support 1992 1.1 supported 1994 1996 appears 1998 } } CORBA 1.1 CORBA 2.0 CORBA 3.0? (IIOP) (pass by-value) Brian Gilstrap 31
  • 32. The Future of RMI (JDK 1.2) • Support for mixing different reference types – secure, multi-cast, etc. • Performance improvements – RMI-specific improvements – JDK improvements: HotSpot + VM/library tuning • Better control over (de)serialization of objects and ability to unexport a “Remote” object in your VM • Activation of server objects – launching a VM to run a server object Brian Gilstrap 32
  • 33. The Future of RMI (2.0?) • RMI over IIOP – there is an initiative by the OMG and Javasoft to extend CORBA’ IIOP to support features s needed to run RMI over IIOP – no known availability date – requires OMG’ “pass by-value” (see next s slide) Brian Gilstrap 33
  • 34. The Future of CORBA • (3.0?) OMG is looking into supporting pass by-value – first response to first RFP was completed end of January – no known availability date • (???) Other proposed features which have varying degrees of vendor support – see Brian Gilstrap 34
  • 35. The Future of CORBA (Cont) • There are hard problems to be solved in order to support pass by-value in a heterogeneous environment – different languages at each end (e.g. C++ vs. COBOL) • Might only allow passing state, not implementation – introduces new failure modes – appears to be current OMG direction (except for Java) • If only passing state, might fail if appropriate implementation not available at receiving end – introduces new failure modes – what about security? • no security “sandbox” except in Java Brian Gilstrap 35
  • 36. The Future of CORBA (Cont) • Supporting pass by-value (continued) – almost all languages don’ support dynamic code t inclusion in a running program (e.g. C, COBOL, C++) • introduces new failure modes – version mismatch problem must be solved for a multi- language environment. If not implemented • systems development becomes much more error prone • can result in “silent” errors (bad computation) • would introduce new failure modes Brian Gilstrap 36
  • 37. The Future - CORBA continued • Therefore: don’ expect pass by-value to t become standardized and supported on top of IIOP very soon (my guess: not before 1Q’ more likely 99, 3Q’ or later) 99 Brian Gilstrap 37
  • 38. Useful URL’s • RMI pages at Javasoft – • Object Management Group (OMG) – • CORBA FAQ – Brian Gilstrap 38
  • 39. Useful Newsgroups/email lists • •* • comp.object • comp.object.corba • general CORBA mailing list? Brian Gilstrap 39
  • 40. Questions/Comments • Now • Later: Brian Gilstrap 40