Slashdot Mirror
Java RMI
The Scoop
Remote Method Invocation (RMI) is the object-oriented remote procedure call (ORPC) facility for distributed programming in Java, since the 1.1 days. RMI also served as motivation and a proof-of-concept for jini, javaspaces, and numerous other solid distributed networking technologies. Of course, anyone from the academic distributed programming world knows Wollrath, Waldo, and Riggs.
Yet, despite a myriad of books over the past five years on network programming, RMI always seemed to be the stepchild: relegated to a single chapter (buried on page 496, of course) that always said that RMI was "better" than sockets and "worse" than CORBA. Now, granted that RMI is operationally rather trivial compared with CORBA and was (prior to RMI/IIOP) a unilanguage distributed ORPC technology -- but still. For those of us who have to interoperate with RMI (whether welcome from the Java world or not), the lack of in-depth technical analysis (beyond the spec) has been a hindrance.
Fortunately, this trend is finally starting to buckle with the release of several in-depth RMI books including: Java RMI, Java.rmi, and Mastering RMI: Developing Enterprise Applications in Java and EJB. As evidence of this problem, Grosso states the same in his introduction – and actually pulls it off without sounding self-serving.
I chose Grosso's text because of the cute squirrel (aka the O'Reilly brand), Grosso's recent series of articles on the hashbelt algorithm, and his unadulterated academic knowledge management and mathematics bent. Fortunately, I was rewarded: this animal returns to O'Reilly's pre-bubble quality. Koodoos to both Grosso and his editors (Knudsen, Loukides, and Eckstein) for getting the train back on the track.
What's to Like
Bottom line is that Grosso simply covers the topics and does so with solid conceptual and code coherence – even by O'Reilly standards (over 40 animals grace my shelves). His prose and explanatory patterns make it clear that he has actually gotten into the real-world of RMI, and doesn't hesitate to highlight both good and bad parts. You cannot be dozing off when you read this (at least not if you expect to understand it) -- this is written by someone with solid analytic thinking skills and it shows. After too many years of "there are no caveats" journalism and publishing, this is a nice reversion. Further, I can only imagine that his current employment is a testament to his real-world knowledge of RMI.
Grosso hits on a vein which is not well-appreciated: when not smoothed over by marketing people, RMI is actually a mostly-capable ORPC technology. Certainly activation and RMI/IIOP really began to make things interesting, from Java2 and EJB respectively. Discussion of reference-counted distributed garbage collection, a feature missing from CORBA and other popular ORPC standards, also contributes a nice bonus (although Grosso's ardent attempt to debunk the "RMI doesn't scale" argument is rather weak, even going so far as to rehash the definition of Threads and threadpools – this complexity mismatch is an ugly giveaway that a well-intentioned editor went astray).
What sets this text apart is the tight focus on nitty-gritty implementation details of RMI itself. After all, these RMI texts are way too late to the game to reteach how to write "baby RMI" code: 5 years after the original spec, you either know how to write RMI or you don't. Grosso simply gives you a solid in-depth analysis of all the obscurities of the RMI runtime, custom sockets, dynamic classloading, activation, MarshalledObjects, and HTTP tunneling. In other words, all the interesting real-world topics whose official documentation is poor and which the various RMI tutorials (written many years ago) ignored.
While canonical, the single banking example followed through the text was well-executed, although authors continue to underestimate the prevalence of readers who consume textbooks non-linearly.
What's Not to Like
RMI/IIOP is shaping up to be a fascinating contributor to the "cleanup the EJB mess" discussion. Dedicating a measly 13 pages (beginning on page 503, no less) to this critical topic seems a bit of an oversight – but maybe that is just my CORBA sentiments speaking. Either way, the mechanics of CORBA are sufficiently intricate in real-world deployments that saying "if you can build an RMI system, you can build a CORBA system" (p. 511) is a bit brazen (or naïve) for my tastebuds. I can only chalk up this oversight to deadline pressure, which is probably a Good Thing, since the book was supposedly in production over almost 2 years.
A minor point: the top-level organization of the book (Part I, II, III) is arbitrary, ignore it -- use the chapter organization instead.
The Summary
Quality: solid practical insight into the nitty-gritty operational implementation details of RMI in the real-world. You simply are not going to find solid O'Reilly-quality coverage of the topics elsewhere.
Relevance: If you are responsible for making RMI actually work in production systems, this might well be the next animal on your shelf – either now or later. If you want a breezy afternoon saunter around RMI, skip this. Instead, google one (of the many) free tutorials online."
You can purchase Java RMI from Fatbrain. Want to see your own review here? Just read the book review guidelines, then use Slashdot's handy submission form.
Having come from a background of Servlet/JSP development, I was quite surprised to see that RMI lacked what I consider a basic feature of distributed computing - authentication and session tracking; this forced me to develop my own, but this is obviously a common need and should be handled by the RMI runtime. I haven't worked with CORBA beyond a couple toys to learn the system, but my understanding is that CORBA does have these feature.
The book itself is excellent - I purchased it after starting to work on a large project with RMI, and realizing that a couple online tutorials wouldn't cut it. The advanced section isn't quite as advanced as I had hoped, but overall the book is a decent reference.
take your sig and shove it
Does the author discuss RMI security and RMI over SSL? If he does, it would be a welcome advantage to the book that probably should've been mentioned in the review. RMI over SSL (via JSSE, for example) is one of the new features that Sun offers, for which only very shallow documentation is available.
I think that most of corba/dcom/rni etc. are particularly over complicated. They place a burden on the programmer in the wrong place. It's worth checking out plan9's approach to distributed computing. Authentication is taken care of by an authentication server. Once you've got an authentication ticket then you can access networked resources by binding remote services into your local namespace. Rights are granted by the usual mechanisms of usernames & groups.
The familair paradigm of users and groups has been deliberately leveraged because that's what is familiar, after all it's stood the 30 years test of time. This extends to which processors on the network you an run processes on etc. etc.
It's worth studying if nothing else.
There are places where the networks are not touching,and there are places where they are-Boeing's Lori Gunter
yes, I too found little in the review preview about XML.
I have used both CORBA and RMI. I don't know why they are shown as competitive products.
CORBA is used when you wan't cross language compatibility. (c / Java / C++, etc.)
RMI is used when you want Cross platform compatibility give by JAVA.(windows, Linux, Mac)
DCOM is used when you are working on M$ Windows.(windows, C++)
To me these 3 are complimentary, with CORBA being one of the hardest but most dynamic. So naturally I expected to see in the review a statement about where the XML thingy fit into this puzzle. Why would you mention these 3 technologies without mentioning that?
I have been a java developer for some time. I had the opportunity to use RMI in java to write a distributed client-server pricing solution for a large telecom company. (I'll keep it quiet; I don't want to be sued).
The problem: Run pricing routines on very large CDR (Call Detail Record) sets. This involved a very complicated process of aggregating calls into time slots and then pricing them according to very complicated long-distance contracts. Pricing very large amounts of data sometimes took as much as two days to price and discount.
Solution: The implementation (at least in Java) of the RMI standard is simple. In order to avoid purchasing an expensive CORBA implementation we extended our c++ client program with JNI. The client program then called a local wrapper class that used RMI to spin off the pricing call on the remote RMI server. We had big-iron machines running an in-house RMI application server. The application server really just worked as a multi-threaded container that loaded RMI servers from the disk and registered them, allowing a person to order servers to be loaded and/or dropped from the registry via a console.
The solution was cheap and worked very well.
My $0.02 will always be worth more than your â0.02, so
Enterprise JavaBeans, and Session Beans in particular, provide these services. RMI is used as the transport layer, and the application server (EJB container) handles authentication and session tracking, often along with redundancy, administration, and a host of other goodies...
While I haven't read the book being reviewed, I know that "Mastering RMI" by Rickard Oberg is one of the best resources on the subject. Rickard is one of the brightest people out there, and he's made waves throughout the enterprise Java world. He's responsible for some of the genius of JBoss, among other things (he came up with the dynamic proxy trick that means JBoss doesn't require stub classes). Check his book out, it's worth it.
XML-RPC is just another way to do what RMI and CORBA do--except it uses XML to encapsulate the data (including the call you are making). RMI was nice when it came out, but I haven't seen it mentioned in a long time. Where I'm working right now they would probably just use XML-RPC or SOAP simply because it is open and can be used by a wider variety of systems (like those OpenVMS machine they have sitting around). I personally use XML-RPC and SOAP and they are great if you have to parse things for the web on the other site. I used to pull a ton of RDF feeds from NewsIsFree, but they screwed it up and only started feeding the updates to the channel. I rewrote the calls using their XML-RPC engine which is much better. I then parse the tree and convert it into RDF for my website. Very slick technology.
Judging from the TOC of the book, I'm surprised that the author didn't deal more with the "why should you use RMI over some other technology?" He does cover the CORBA vs. RMI choice, but that was it. I also don't know how "new" this book is--especially if those topics (SOAP, XML-RPC) weren't covered.
-J
It's true that Sun's reference implementation on Windows doesn't scale very well(at all?) with respect to large numbers of simultaneous connections. I am unclear as to whether Sun's I/O improvements made with 1.4 will help RMI's connection handling ability. As with most things dealing with reference implementations though, one usually has to buy something to get performance improvements. Depending on how much one believes weblogic, their implementation of RMI seems to be quite the performer
XML-RPC was the first succesful open standard for an XML-based RPC and SOAP was based on XML-RPC. There are a number of reasons they are interesting technologies. Perhaps the biggest right now is that SOAP is one of open standard technologies at the core of Web Services and Microsoft's .NET.
.NET software out there Real Soon Now [tm] and it will be using SOAP as its fundamental RPC protocol. If you are a developer, then now is a good time to learn this technology.
Love it or hate it, there is a good chance that there will be a lot of
One of the disadvantages of XML-RPC and SOAP in commercial software development is that they are very human-readable: they pass XML documents between systems. Many times this is a good thing, of course, especially when you are debugging your system. But if you are passing confidential information (say your customer's bank records) then you will need to work at obfuscating (and de-obfuscating) the XML that is actually sent.
There are also some overhead concerns with (particularly) SOAP, but careful design and use can overcome these.
Sailing over the event horizon
Why on earth does the XML-RPC spec require HTTP? This, IMO, is one of the stupidest things in the spec. It's right up there with their ASCII requirement for Strings. The XML-RPC protocol should be separate from the transport(HTTP) of that protocol. As for the ASCII string dependence...
SOAP is at a lower level than RMI, and it is designed more for simple method calling. RMI provides complex object graph serialization, remote object reference passing, distributed garbage collection, network failure detection (through the Unreferenced interface), and more.
SOAP is great for loosely bound, occasionally communicating processes. RMI is great for taking a Java application and splitting it into pieces for execution on various machines.
- jon
Ganymede, a GPL'ed metadirectory for UNIX
Yes, RMI has distributed garbage collection.
When one host passes a remote object reference to another, the RMI classes on the receiving host track the remote object reference in a client-side data structure. As long as the user-level client code is referencing the remote object, the client will occasionally 'ping' the server with an RMI message that tells the server that the client is still using/referencing the object.
If the client drops reference to an object, the client will send a release message to the server, which will decrement a distributed reference count. Alternatively, if the client dies, the server's RMI layer will decide after a certain period that it hasn't heard from the client in too long, and will assume that the client dropped off the network.
Programmers can implement an unreferenced() method in remote objects that will be called by the RMI layer on the server when the object is no longer referenced by a client. This can be used to intelligently handle cleanup on client death, etc.
- jon
Ganymede, a GPL'ed metadirectory for UNIX
But if you are passing confidential information (say your customer's bank records) then you will need to work at obfuscating (and de-obfuscating) the XML that is actually sent.
Whoa, that's a bad idea. It is not a security risk to label your data in a clear way; its a security risk to think that 'obfuscating' that data is safe. For example, if you pass this around:
<bankAccount>12345</bankAccount>
it is no less secure than:
<foo>12345</foo>
What you really need to do is encrypt the data somehow, so you end up with:
<bankAccount>encrypted bank account</bankAccount>
Anyway, it doesn't matter if you are sending XML or comma separated values: if you are sending confidential information as clear text, then you are screwed.
-Mike
One other thing to consider is messaging, like that provided by JMS (now part of J2EE). It's a good alternative to the purely synchronous world of RPC (embodied by XML-RPC, SOAP, and the like) because it gets around some of the vagaries of making calls over an unpredictable environment (the Internet). Things like publish-and-subscribe, guaranteed delivery, and asynchronous processing are pretty cool, since synchronous RPCs can get waylaid by part of the network going down, etc.
I've only fooled around with it, never used it in a real project, since message-driven beans are pretty new. Does anyone know of a project that makes extensive use of Java messaging, particularly using message-driven beans?
So what does this mean in shops that produce high-volume, high-throughput, high-userbase apps? You usually find that dist. object implementations have their object-to-object interactions up-levelled (artificially) to ensure that 'messages' (as opposed to granular method calls) become the implemented design-point.
This is why RPCs (home-grown, SOAP/XML, or otherwise) make a lot more sense (to me). The technologies might be new, but the concepts are old and useful. Bottom-line (for me), is that RMI and CORBA do not implement service-based architectures very well. RPC-style solutions are a more natural fit from both the business requirement and technical design perspective.
CrazyLegs
"Pork!!" said the Fish, and we all laughed.
I'm seriously considering using ACE for a cross-platform networking layer in a dstributed system I'm designing. I note that this also has an ORB thingy called TAO (which may just use DCOM/CORBA/RMI depending on the platform). So that may be another option to consider in the interim, i.e. rather than decide which ORB to back right now.
So check out ACE (It's Open Source of course) at http://www.cs.wustl.edu/~schmidt/ACE.html
and TAO at http://www.cs.wustl.edu/~schmidt/TAO.html
.
Here's some blurb:
TAO is an open source product with zero cost licensing.(Development and run time.) TAO is a C++, CORBA 2.3 compliant ORB designed for real-time but equally applicable in general-purpose situations. TAO runs across multiple O/Ss and chip architectures enabling a wide integration capability, for diverse elements, within a single ORB implementation. TAO's baseline design for real time considerations ensures end to deterministic behavior and leverages both system and network characteristics.
- Scheme etc. is better than XSL because it's more consistent and more powerful - no need for escapes to real programming languages as real-world XSL processors like Saxon have to provide
- Programs are data, and advanced IDEs like Eclipse would be a lot easier if they started from LISP heritage (hence EMACS longevity).
- RMI can do things that CORBA, EJB and SOAP cannot, including pass-by-value and code transfer.
These issues come up time after time onI remember looking at Horb in early 1996. The design for Ganymede was inspired by what Horb was promising, but once Sun released RMI, it seemed that all the distributed object support necessary was bundled into every JDK, so why use Horb?
Still, it's exciting to see that Horb has gained and kept an active user community.
- jon
Ganymede, a GPL'ed metadirectory for UNIX
Whoa, that's a bad idea...its a security risk to think that 'obfuscating' that data is safe...What you really need to do is encrypt the data somehow
Ooops, you are absolutely right. I wrote that before I had my morning coffee. I was using "obfuscating" in a very loose sense to encompass "encryption". Sorry, must remember to engage brain before posting...
Sailing over the event horizon
Most of the time, I wind up using command objects to encapsulate remote method calls. I wound up writing a three part series on this techinique for O'Reilly'd java web site.
Yeah, I wound up using the command pattern to handle the Ganymede monitoring console. Actions on the server lead to events being generated. Each attached monitoring console has a thread on the server that loops through command objects on a queue. If the server generates events faster than the monitoring console can handle them, the server will replace obsolete events from the queue with the new version of the data. Other events, such as textual logging, can be coalesced.
Works *great*, lets the monitoring consoles be relatively asynchronous with regards the server, and dramatically improves overall performance.
I don't use the command pattern for everything in Ganymede's use of RMI, but where I do use it, it's absolutely essential.
And, say William, you should get yourself a slashdot account. ;-) Jooooooin us!
- jon
Ganymede, a GPL'ed metadirectory for UNIX