The Real World (Java & XML, 2nd Edition)

I'll conclude this chapter with a short look at some important details of using XML-RPC in the real world. This continues the focus on allowing you to use XML not because it is the newest and neatest technology, but because it is the best for solving certain situations. All of the knowledge within this book, the XML specifications, and other XML books will not make your application operate as well as it could if you do not know when and how to use XML and XML-RPC correctly! This section highlights some of the common issues that arise in using XML-RPC.

POST /RPC2 HTTP/1.1 User-Agent: Tomcat Web Server/3.1 Beta (Sun Solaris 2.6) Host: newInstance.com Content-Type: text/xml Content-length: 234 <?xml version="1.0"?> <methodCall> <methodName>hello.sayHello</methodName> <params> <param> <value><string>Brett</string></value> </param> </params> </methodCall>

HTTP/1.1 200 OK Connection: close Content-Type: text/xml Content-Length: 149 Date: Mon, 11 Apr 2000 03:32:19 CST Server: Tomcat Web Server/3.1 Beta-Sun Solaris 2.6 <?xml version="1.0"?> <methodResponse> <params> <param> <value><string>Hello Brett</string></value> </param> </params> </methodResponse>

11.4.2. Shared Instances

In the examples, I looked at using static data objects to share data across multiple instances of the same class. However, there are times when an instance itself is shared. This may not be because of an XML-RPC need, but because of a need to use the class differently on the server. For example, the singleton design pattern in Java mandates that only one instance of a class ever be created, and that instance is shared across all applications. This is usually accomplished by using a static method called getInstance( ) instead of constructing the object:

Scheduler scheduler;

// Get the single instance, which is managed in the Scheduler class
scheduler = Scheduler.getInstance( );

// Add an event for right now
scheduler.addEvent("Picnic", new Date( ));

To ensure that no classes directly instantiate the Scheduler class, the constructor is usually made private or protected. While this forces clients to use this code to get an instance, it can also cause confusion when using the class as an XML-RPC handler. Remember that registering a handler has always been accomplished with the instantiation of the handler class. However, the WebServer class requires only a valid instance as a parameter, not necessarily a new instance. For example, the following code is a perfectly acceptable way to add a handler:

WebServer server = new WebServer(8585);

// Create a handler class
HelloHandler hello = new HelloHandler( );
server.addHandler("hello", hello);

The server class does not distinguish between these methodologies, as long as the handler class is instantiated when it gets passed into the addHandler( ) method. So you can make a small change to this code if you want to add an instance of the singleton Scheduler class described previously:

WebServer server = new WebServer(8585);

// Pass in the singleton instance
server.addHandler("scheduler", Scheduler.getInstance( ));

This passes in the shared instance just as if the class were being instantiated through a constructor with the new keyword, and preserves any information shared across the singleton class. Many classes used in services such as XML-RPC are built as singletons to avoid the use of static data variables, as a shared instance allows the data to be stored in member variables; the single instance then operates upon those member variables for all client requests.

11.4. The Real World

11.4.1. Where's the XML in XML-RPC?

Example 11-10. XML for XML-RPC request

Example 11-11. XML underlying an XML-RPC response

11.4.2. Shared Instances

11.4.3. To Servlet or Not To Servlet