Documentation

Project Documentation

Custom Request Handler Creation

By default, Apache XML-RPC creates a new object for processing each request received at the server side. For example, in the Calculator example, each time a new request is received, a new Calculator object is created to handle the request. This has some advantages such as requiring no built-in synchronization mechanisms inside the processor class. On the other hand, in many cases it is necessary to share some state between the requests or access non-static resources inside the host application. Some of this can be addressed by use of static resources (e.g. Singleton design pattern) but this can complicate code. Further, it gets even more complicated to handle this when several XML-RPC servers need to be started inside one JVM, each expecting unique state, or when request specific processing and state is needed based on some request parameter values. Effectively addressing these types of scenarios requires having custom control over the creation of the processor objects. With Apache XML-RPC, this is supported by extending the org.apache.xmlrpc.server.RequestProcessorFactoryFactory class.

Consider the following example of an Echo service. We have a simple service interface that we want to invoke called EchoService and its implementation:

Re-running the example now with the new server and the old client we get the following output:

1: Hello
2: World

This is because all invocations will now share the same non-static implementation object of EchoServiceImpl. This can access non-static objects if so configured and share state between requests.

That?s it for customizing the creation of processor objects. It is possible to customize the process in different ways, such as selecting a different processor based on request parameters, starting several servers with different processors or whatever. Through the processor objects it is also possible to access any non-static state of the overall system itself.

It is also possible to have the factory check if it is asked for the factory for ?Echo? class or something else, and resort to the default Apache XML-RPC factory in these cases. In the example this is not needed as only the Echo class is registered and supported.

ABSTRACTION

Using custom processor object factories can have a benefit from abstraction perspective as well. An additional change is also visible in the modified server above that was not yet discussed. This is the use of the interface class in the definition of the PropertyHandler:

phm.addHandler(EchoService.class.getName(), EchoService.class);

This allows one to more clearly parameterize the server with the processor object to be given to the factory as any implementation of the interface. With the default implementation giving an interface as a second parameter to the addHandler() call will result in an exception such as

For the customized factory this is not a problem. With the default implementation it is still possible to parameterize this through the service class type but the interface approach can make for cleaner code. This can be useful, for example, for unit testing with services stubs.