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

1,261
views

Published on

Published in: Technology

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
1,261
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
75
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 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 http://www.omg.org 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 – www.javasoft.com/products/jdk/rmi • Object Management Group (OMG) – www.omg.org • CORBA FAQ – www.cerfnet.com/~mpcline/corba-faq Brian Gilstrap 38
  • 39. Useful Newsgroups/email lists • rmi-users@java.sun.com • comp.lang.java.* • comp.object • comp.object.corba • general CORBA mailing list? Brian Gilstrap 39
  • 40. Questions/Comments • Now • Later: gilstrap@inlink.com Brian Gilstrap 40