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