Custom Protocols

XML-RPC is vastly underpowered for many tasks (for example, any that require strings in a language other than English), whereas SOAP is perhaps overcomplicated for many jobs. There is, however, a convenient middle ground. The truly key idea for both SOAP and XML-RPC is that you can pass an XML document over the Web using HTTP POST. The exact format of that data doesn't really matter much, as long as both client and server agree on what it is and what it means.

For example, if an online broker such as Ameritrade wanted to provide its clients specialized trading software, it could use any XML format it wanted to send the data back and forth. It might choose to ignore the SOAP envelope completely and just send the getQuote and Buy elements I've been placing in the body of the SOAP requests .

There are still many advantages to using a standard format for exchanging data rather than rolling your own every time you need one. Most important, a standard format such as XML-RPC or SOAP makes it much easier for other developers to integrate their systems with yours. Furthermore, if your system can be easily modeled as a set of procedure calls, then choosing XML-RPC or SOAP allows you to pick from a variety of implementations that take care of many of the details for you. Therefore, you shouldn't go the custom protocol route without some serious thought as to whether it's truly appropriate. Nonetheless, if a custom XML vocabulary does seem to suit your problem, feel free to define one.

Summary

XML protocols allow widely distributed systems to communicate with each other over standard HTTP. These protocols have many advantages compared with traditional RPC systems such as CORBA and RMI, including simplicity, transparency, and platform independence. Using HTTP allows clients and servers to run on very disparate systems. Using XML allows the data exchanged to achieve any necessary level of complexity. There are very few situations where XML does not provide an obvious means of encoding information. Using schemas even allows XML's fundamentally text-based format to assign data types to elements so that nontext data such as floating point numbers and dates can be exchanged.

Some XML protocols are based on custom XML applications. Slashdot's Backslash is one example. Others use standard formats such as RSS, XML-RPC, and SOAP. RSS is limited to distributing news headlines and summaries. XML-RPC is more general, allowing the transmission of method calls and arguments to remote systems that invoke those methods and return a value. SOAP is the most general of all, allowing the exchange of XML elements of arbitrary complexity, which may or may not be treated as method calls and arguments.

Throughout the rest of this book, we're going to build multiple servers and clients for RSS, XML-RPC, SOAP, and custom systems. We'll use Java's networking classes to hide the fact that the XML documents we're working with are coming from and going to the network. We're going to focus on the contents of those documents, and how to access and manipulate those contents from inside our own Java programs.

Chapter 3. Writing XML with Java

No one ever believes me when I tell them how easy it is to develop programs that write XML documents. In fact, writing a program to output an XML document is unbelievably trivial. It's something an eight-year-old typing BASIC in his or her first class at computer camp can do. In Java, it's even easier than that due to Java's strong Unicode support. You don't need to know any special APIs like DOM, or SAX, or JDOM. All you need to know is how to System.out.println() . If you want to store your XML document in a file, you can use the FileOutputStream class instead. If you want to serve the document dynamically over a network, it helps to know something about servlets; but in the end, it all reduces to writing bytes onto an output stream.

In this chapter, I'm going to develop a program that writes Fibonacci numbers into an XML document. I chose this example because the Fibonacci numbers are a well-known series and are very easy to generate algorithmically so that the examples will be nicely self-contained. However, the principles of XML you learn here will be much more broadly applicable to other, more complex systems. The key idea is that data arrives from some source, is encoded in XML, and is then output. The source of the datawhether an algorithm, a file, a network socket, user input, or some other sourcereally doesn't concern us here.

I'm going to show you how to use classes you're already familiar with, such as OutputStreamWriter , String , and HTTPServlet , to generate XML documents. I am going to beat this idea into the ground until you are absolutely convinced that there is nothing special about XML documents that requires any fancy tricks to produce them. Once you've finished this chapter, you'll be thoroughly immunized against the snake-oil peddlers who want to sell you multi-hundred-thousand-dollar software to do what you can do with your existing systems for free.