It's no surprise that since my last turn on the Soapbox, the hype surrounding SOAP has continued to rise. Microsoft is praising the protocol in its .NET platform, Apache proclaims it the be-all and end-all for messaging (at least in the XML circles I run in), and everyone wants to get it. Services for SOAP are being developed at Enhydra and jBoss (two popular open-source application servers), as well as at many of the commercial application server companies. So what has changed with the SOAP story since the last article? To be honest, almost nothing. SOAP is like a large rock that has gained momentum as it starts to roll down a hill. The question is whether you are running along with it, or standing under it looking up, hoping it doesn't overpower you. I'll clear away all the marketing hype, and give you the tools you need to make a clear assessment of whether or not SOAP is for you. In other words, I'll help you make sure you aren't crushed by that big rock!

This article takes up where I left off in my first Soapbox, which was an in-depth look at SOAP, in particular its underpinnings in RPC and XML-RPC. Here I'll compare SOAP to its biggest competitor for communication in the Java space, RMI (remote method invocation). RMI has been used for communication between components across a network in Java for quite some time, and it has continued to gain popularity with its use in technologies such as Enterprise JavaBeans (EJB). I'll examine how RMI differs from SOAP -- both SOAP the reality, and SOAP the future promise. Finally, I'll take a look at what I call "working-class SOAP," meaning what you can download today from Microsoft and IBM. This part of the article moves away from the conceptual toward a concrete consideration of the real question developers are asking: "What can SOAP do for me, today, right now?"

RMI or RPC?

In the first article in this two-part series, I examined SOAP, describing exactly what it is and, just as important, what it isn't. In particular, I looked at RPC, XML-RPC, and SOAP, dissecting what is included with each technology. You may have been surprised to discover that many of SOAP's "features" actually are XML-RPC features that are not intrinsic to SOAP. You may have also learned that your business needs could be met by using a simpler package than SOAP, like one of the XML-RPC libraries found at the Userland XML-RPC site (see Resources). Or you may have determined that, with its enveloping mechanism and the ease with which it can encode application-specific data types, SOAP is exactly what you need. In any case, with the information I provided in my first Soapbox article, you should be armed with enough knowledge about SOAP and RPC to compare it to its primary rival in programming today, RMI. There are good reasons to use RMI over RPC, but there are also good reasons to use RPC over RMI. (Isn't this always the case?) In the following section, I discuss the major factors necessary to making a choice among the three options: SOAP, RPC, or RMI.

It depends on the language

The decision to use SOAP, RPC, or RMI will have its basis in the programming language you use. If you're a Java programmer, you've got RMI right there as part of the Java API -- and it is easily accessible and well documented. If you're not a Java programmer, then RMI isn't an automatic option. In fact, you non-Java programmers will find that SOAP is an extremely attractive solution, even more so than for Java developers. SOAP offers a much easier means of messaging and communication than does CORBA and other remote protocols. Additionally, the encoding it provides for XML is handy: While some C and Perl XML parsers are available, generally these are coming along a bit more slowly (development-wise) than the Java efforts in the same area. SOAP, therefore, not only adds messaging to your toolbox, but also removes the burden of having to parse XML with tools that may not be as mature as their Java counterparts.

In practice, it's mostly Java programmers who are using SOAP anyway, so it's back to the original question of whether to use RPC or RMI. What if you are a Java developer who must communicate with non-Java applications or components? These other players in your application space probably can't send or receive RMI communication. It's probably safe to say they don't want to deal with the hassles of IIOP or CORBA. But they could certainly receive the nice, simple payload that SOAP delivers. Decoding the payload and responding in kind (using a SOAP API in their own language) makes communication across the "programming language barrier" simple -- and it makes SOAP appealing.

So what does this mean for you as a developer? If you code Java, talk to Java, and never need anything but Java, SOAP loses some of its appeal; RMI is much more accepted than SOAP and can be easier for developers to learn and use. While SOAP still has some advantages (which I'll look at next) for the true Java-phile, it just isn't as attractive. If you aren't working in a Java environment, or you need to communicate to non-Java environments, then SOAP begins to shine. It uses XML, which is vendor- and language-neutral, and is easy to parse in Perl, C, Ada, and even COBOL (although why you would use COBOL is the subject of another rant). SOAP provides an attractive alternative to heavy-duty paradigms like CORBA and RMI-IIOP. And, as SOAP is a highly popular technology right now, the SOAP APIs for these other languages are coming along very quickly. In these cases, consider SOAP a real friend to messaging. But there is certainly more to SOAP than just messaging, and I'll now show how clients interact with SOAP, and how they interact with RMI.

Invocation vs. request and response

In determining whether to use RMI over RPC or vice versa, it's important to look at the means of interaction the two employ. The RMI model of interaction is entirely different from the one used in RPC: there is a notable difference in how the remote object is operated on. In fact, in RPC and SOAP, a remote object is not directly operated on at all! To clarify this point, I'll take a closer look at the models.

In RMI, a remote object is acted upon as though it is local. The client application invokes methods directly on a remote object's stub. Through the magic of RMI and Java, this stub has the method invocation encoded across the network, and the end result is that an object on another machine has a method invoked. The result is then similarly encoded and sent back to the stub, which then returns the result. To the client, it is as though there were no involvement by a remote object. Perhaps the biggest advantage to using this means of interaction is that type-safety and the direct use of method names is possible. In other words, normal Java conventions are followed: A method is invoked, and a compile-time error occurs if the arguments are incorrect. However, I must inform you that there's a downside to this. Many exceptions end up being wrapped in java.rmi.RemoteException. So you do have to make sure there is some knowledge in the calling application of an RMI object, or you could lose the wrapped information in a RemoteException (perhaps a NumberFormatException). The result is a lack of information about things that went wrong.

The alternative, an RPC-style call, follows a much different path. Rather than it involving a method being invoked, you have a message being sent, which is essentially a request to a remote server. Then, a response is formulated and returned. The client in this case never invokes a method directly. A request generally consists of the name of the method to invoke on the remote server, and the arguments. However, these are all encoded. Take the code fragment shown in Listing 1, which requests the reservation and purchase of airline tickets.

Now I know you may be feeling cheated here, as this is an article about SOAP, and you are getting an XML-RPC code sample. So for the sake of completeness, look at the same call using SOAP, in Listing 2.

For now, it doesn't matter whether you use XML-RPC or SOAP as compared to RMI; the interaction between client and server is the same in both XML-RPC and SOAP, and both differ dramatically from RMI. What you see in these listings is that the method name and parameters are encoded as Java Strings or Parameters (depending on what technology is used). You also see that a lookup must occur by name -- rather than by getting a handle to an actual java.lang.reflect.Method in the Java Virtual Machine, as in RMI. More things can go wrong in this RPC style of coding: The method could be missing on the server, or the method could be spelled incorrectly on the client. Other problems you may encounter are that the arguments are the incorrect type, the argument names are specified incorrectly; or the server may not be running. All of these become run-time problems with RPC, where they would be compile-time problems using RMI (with the exception of the server being down). Generally, it's better to catch these at compile time rather than at runtime. The point is that using RPC or SOAP costs you a lot of the conveniences of the Java compiler.

The RPC style does offer some advantages. First, it allows for greater independence between the client and server. Unlike RMI, it is not necessary to generate stub classes and pass them to client machines. A server can be shut down and replaced entirely without the client knowing it. (You can do this in RMI, but it is much more difficult to achieve.) In fact, classes and methods on the server can be upgraded and recompiled between calls, without interrupting client processing. And with SOAP (as opposed to XML-RPC alone), you can use the SOAP fault mechanism, a standard part of the API, to relay to the client extensive information about problems that might occur.

Once again, I'll let you make your own judgments regarding the use of RMI, RPC, and SOAP in your work. In some areas, SOAP is clearly superior: It is great for asynchronous communication and for loosely coupling the client and server. But these advantages incur penalties. A greater amount of runtime checking has to be done, and developers lose many of the compile-time conveniences of ensuring that methods and parameters are correct. If you've read my first turn on the Soapbox, I'm sure you know what I'm going to say: evaluate your business needs. Use what you need, and throw away what you don't. You'll most likely find that in some cases, firing off a SOAP call and letting a remote server calmly chug along works great; in other cases, you'll want to use RMI for Java-to-Java communication and for ensuring type safety at compile time.

Back to top

Working-class SOAP

I've compared SOAP to RPC, XML-RPC, and RMI, examining the differences among them and the pros and cons. It's not time to close up shop just yet; I still need to consider some issues about SOAP itself. Up to this point, my discussions about SOAP have focused on "conceptual implementations" of the technology; I have shown how the APIs would behave if the specification were implemented "as is." In reality, there's no such thing as a perfect implementation. Remember, the toolkits were developed by humans! With this in mind, in the next section I look at the actual SOAP implementations -- the "working-class SOAP" as it were, to see how, and if, they deliver on the promise of SOAP.

Practice vs. promise: SOAP from IBM and Microsoft

How do the implementations and the specifications measure up to each other? Two major SOAP implementations are in development, one from Apache, as part of IBM's Apache XML project, and one from Microsoft, as part of its .NET platform. In both cases, the implementations are less than a year old in terms of public release, which brings up the question of the maturity of the implementations.

Perhaps the most anticipated release from Apache XML, the Apache SOAP effort, is an extension of IBM's original work on SOAP4J. While Apache's SOAP has been given the version number "2.0", it is hardly equivalent to many other 2.0 products, which generally are robust. The specification contains an extensive list of items that have yet to be added to SOAP 2.0; However, many of these are not needed in most applications. The downside to this is that these minor, often unused, items must be supported for specification compliance. And while you don't use them until they are implemented, the SOAP toolkit may not be performance tuned, as work is still being done on features. So you pay a price for those seldom-used features, unfortunately.

Microsoft's SOAP implementation, a core piece of the .NET platform, is nearly identical in terms of functionality and compliance to the SOAP submission to the W3C. This will most likely continue to be true, as SOAP is the means by which most communication will occur in the .NET platform. The ability for components to speak to each other through SOAP -- both in development and in production -- is one of the major features of .NET, so don't expect Microsoft's SOAP implementation to falter. At the same time, you should also expect many proprietary features to make it into the Microsoft implementation. With these "hooks," Microsoft-driven products will be able to take advantage of shortcuts specific to the .NET platform. If you're using Microsoft across the board, these hooks are great; however, if you're trying to use a vanilla SOAP implementation, beware!

The bottom line is that SOAP is still in a period of rapid growth and that SOAP as it exists today is not quite the SOAP being promised in the future: The implementations from IBM and Microsoft are still being worked out and completed. Don't expect to start using SOAP (through one of these projects) today and be able to upgrade seamlessly to a new version of it in a few months; features will change, functionality will change, and some general chaos will ensue, often causing changes to the rest of your applications. Additionally, if SOAP is accepted by the W3C as a new specification, several revisions will occur before a final recommendation is delivered. And these revisions will lead to additional changes in SOAP implementations, which of course means more upgrades to your development environment.

With all that said, SOAP has a lot going for it in the current implementations. If you don't get mired in the implementation details and you're willing to be flexible when upgrades come out, you can learn a lot from using today's SOAP implementations from IBM and Microsoft. You can investigate how RPC calls work, how remote methods can be located, and how the SOAP envelope and fault mechanism behave. In other words, at the point when complete and stable implementations of SOAP do arrive, you can be well ahead of the game.

Back to top

A note about XML: All you need?

With respect to SOAP providers, a final word of warning is in order: don't bet the farm on XML. I'm sure I'll be misquoted on this, so hear me out. XML is here to stay. But XML is best used in the context of a larger application, with a real programming language such as Java to support it. There are some who say, "XML is enough." With things like SOAP, XML-RPC, RSS (RDF Site Summary), and other XML vocabularies entering further into the realm of actual applications, XML is being advocated as a programming language itself. Using Apache Cocoon, XSL, XSLT, SOAP, and an XML database, it's conceivable one would never have to write a line of Java code and still be able run an entire application. (To be fair, no one at Cocoon actually suggests this; it's just an example.)

This premise, that nothing but XML is needed, is intrinsically flawed. XML comes with a price: It takes longer to encode than binary formats and is much larger to send across a network. The advantage of XML is that it can be understood across programming languages, across platforms. But if you don't need this across-the-board functionality, then XML doesn't make much sense! For example, using XML to communicate between a servlet and an EJB in the same application is a bad idea. It takes time to process the XML and resources to transport the XML, and nothing is gained.

SOAP is a tool. It should be used only as a tool, assisting in messaging and data representation by applications. These applications require more than XML. While I can understand that some folks advocate not being tied to Java -- especially as Sun has shown an unwillingness to create an open standards process for the language -- trying to use XML as a replacement for Java simply is not practical. So take SOAP, and XML, as one more wrench in the toolbox. While it's a multifaceted, extremely powerful wrench, it's still just a wrench.

Back to top

Summary

In this two-part series, I've examined SOAP under many lights. I've poked and prodded it, held it up against its ancestors RPC and XML-RPC, and compared it to its chief competitor, RMI. I've also looked at the SOAP implementations that are available versus the actual SOAP note from the W3C. Even if you're still undecided about SOAP, at this point you should be able to recognize its merits and its problems.

I hope you've started to form your own opinions about the state of SOAP. If you're waiting for some sort of edict that tells you whether SOAP is "thumbs up" or "thumbs down," it's not going to happen. Frankly, I can't tell you whether or not you should use SOAP. I can tell you that in many cases in which developers are using SOAP today, using XML-RPC instead would be sufficient and easier to program to. In addition, XML-RPC libraries are much more mature than SOAP libraries. At the same time, some programmers struggle daily with communications between Perl and C components, and C and Java components. These developers could gain a lot from moving to a SOAP-based or XML-RPC-based communication model. On the other side of the coin, Java developers who never move outside of that language could move to RMI instead of using SOAP, and they'd see tremendous performance improvements.

I'll leave you with the basic advice I keep repeating: "Use what you need, and throw out what you don't." Before you get too excited about SOAP, make sure it fits your business needs. If it doesn't, don't be afraid to be less technically "current" than your peers; your satisfaction at having a simple, successful application will far outweigh the troubles you gain from using a technology like SOAP just for the sake of having the newest buzzword technology in your application. In either case, keep an eye on the developerWorks XML zone, as I'll closely monitor and cover any new developments related to SOAP. And other developers will be taking their turns on the Soapbox.

Resources

• Bone up on SOAP by reading the note at the W3C: SOAP 1.1 Note.
  
  
• Get the implementation from XML Apache at xml.apache.org.
  
  
• Compare IBM's SOAP implementation with Microsoft's in these two articles: MS SOAP SDK vs IBM SOAP4J and MS SOAP SDK vs. IBM/Apache XML-SOAP.
  
  
• Get the lowdown on XML-RPC at the Userland XML-RPC Web site, where you can find several XML-RPC libraries.
  
  
• Read more from Brett on XML and related technologies in his book, Java and XML .
  
  
• Find articles, tutorials, standards, and other technical resources in the developerWorks SOA and Web services zone.
  
  

About the author

Brett McLaughlin (brett@oreilly.com) specializes in distributed systems architecture. He is author of Java and XML (O'Reilly). He is involved in technologies such as Java servlets, Enterprise JavaBeans technology, XML, and business-to-business applications. Along with Jason Hunter, he recently founded the JDOM project, which provides a simple API for manipulating XML from Java applications. He is also an active developer on the Apache Cocoon project, EJBoss EJB server, and a co-founder of the Apache Turbine project.

Comments (Undergoing maintenance)

Back to top

Trademarks  |  My developerWorks terms and conditions

Table of contents

• RMI or RPC?
• Working-class SOAP
• A note about XML: All you need?
• Summary
• Resources
• About the author
• Comments

Next steps from IBM

Rational Tester for SOA Quality is an automated web services testing and SOA testing tool that supports Web services SOAP, HTTP(S), JMS, WS-Security, UDDI, and RESTful standards.

---

• Try: The no-charge Rational Service Tester for SOA Quality helps quality assurance professionals validate web service based SOA application..
• Article: See the whats new with Rational Service Tester for SOA Quality, and its Generic Service Client, which provides a single client to interact with any SOA service type.
• Tutorial: Get hands-on experience with this Transport for SOAP feature tutorial using Rational Tester for SOA Quality.
• Buy: Rational Service Tester for SOA Quality

My developerWorks community

Dig deeper into XML on developerWorks

Rate a product. Write a review.

Write a review for Rational products today!

Special offers