Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

RMI and CORBA Why both are valuable tools


Published on

Published in: Technology
  • Be the first to comment

RMI and CORBA Why both are valuable tools

  1. 1. RMI and CORBA Why both are valuable tools by Brian Gilstrap with thanks to Mark Volkmann Brian Gilstrap 1
  2. 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. 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. 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. 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. 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. 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. 8. RMI Features/Limitations (Cont) • Simple to use - sending objects – implement “Serializable” interface – optionally specify codebase – automatic version mismatch detection Brian Gilstrap 8
  9. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 38. Useful URL’s • RMI pages at Javasoft – • Object Management Group (OMG) – • CORBA FAQ – Brian Gilstrap 38
  39. 39. Useful Newsgroups/email lists • •* • comp.object • comp.object.corba • general CORBA mailing list? Brian Gilstrap 39
  40. 40. Questions/Comments • Now • Later: Brian Gilstrap 40