Frustration is an industry standard

It's at times like these that I wish corporations were less selfish about their standards. Yes, standards are a good thing, but they're a blatant waste of time if you try to monopolize them. I was screwed over by two companies in this respect: Microsoft for their non-standard JVM and Weblogic for their non-standard RMI.

I found his site while searching Feedster to see if anyone's still using RMI instead of XML-RPC or SOAP. I'm working on the next edition of Sams Teach Yourself Java 2 in 21 Days, and it covers Web services in much more depth than RMI.

To me, it's no contest which one to choose: XML-RPC does everything I'd use RMI for, without the hassle over stubs, skeletons, registries, and binding.

Java · 2003/09/22 · 8 COMMENTS · Link

Comments

Have you rec'd any information about his XML-RPC implementation? I asked and am waiting for insight into his implementation. The other beauty of XML-RPC is that implementations tend to be fairly transparent, and so open to fixing.

#1 · Patrick Logan · 2003/09/22

Yes. XML-RPC is "good enough" in most case. And no, there is no intrinsic limitation in it now that the confusion about character encoding has been lifted... even less a mythical 50 connections limit...

On the other hand, why would you use something that simple and straightforward? Don't you just love it when there are so many hoops to jump through? There is a certain sense of perverse "beauty" in all those traps that some systems excel at throwing at you... ;)

#2 · Zoe · 2003/09/23

"XML-RPC does everything I'd use RMI for, without the hassle over stubs, skeletons, registries, and binding."

Let's be fair about this: it doesn't have the "hassle" of stubs or skeletons because it doesn't support either giving your client code transparency with respect to whether a method call is local or remote, or enforcing type safety. It doesn't have the "hassle" of registries and binding because it offloads the hassle to something else, typically DNS. You still have to publish your web service somehow. You still have to make sure that your client code adheres to whatever XML-RPC API you've chosen to use. And if the API you're remoting is complex enough, you may end up with ClassCastExceptions, NullPointerExceptions, etc. at runtime instead of a compile-time error. I leave it to you as to whether that's a bug or a feature, but regardless, it is a trade-off that can't be safely ignored.

#3 · Paul Snively · 2003/09/23

Re: trade-off

Yes. It's all about trade-off. As usual...

Regarding "registries", Zeroconf DNS Service Discovery provides a very nice alternative.

Regarding protocol adherence (ClassCastExceptions and such), this can be solved very simply if your communication library hides the raw XML-RPC and instead provides a native proxy to interact with the method calls. Take a look at ZOE's RPCProxy for a concrete example.

#4 · Zoe · 2003/09/24

Re: RPC Proxy

Alternatively, and if it's more of your liking, check RPCTestTool for a demonstration of the concept in Objective-C.

http://homepage.mac.com/petite_abeille/

#5 · Zoe · 2003/09/24

It's definitely a trade off, Paul, but I've never had a project where I needed the benefits that accompany the complexity of RMI. Some of this is because my needs are usually pretty trivial, but I suspect that XML-RPC covers a broader range of development situations than RMI.

One thing that keeps me away from RMI: Why am I hassling with stubs, skeletons, and registries at all? Shouldn't that be something the Java 2 library takes care of on its own?

#6 · Rogers Cadenhead · 2003/09/24

Re: Rendez-vous with XML-RPC

As a picture is worth a thousand words, here are two of them:

http://zoe.nu/contents/zoe-rendezvous-win.gif

http://zoe.nu/contents/Rendezvous.jpg

#7 · Zoe · 2003/09/24

Re: takes care of on its own

In that case, try GLUE from the mind electric:

http://www.themindelectric.com/glue/

If you are familiar with Objective-C, their implementation is akin to NSConnection for ease of use.

#8 · Zoe · 2003/09/24

Add a Comment

All comments are moderated before publication. These HTML tags are permitted: <p>, <b>, <i>, <a>, and <blockquote>. This site is protected by reCAPTCHA (for which the Google Privacy Policy and Terms of Service apply).