O'Reilly logo

Java and SOAP by Robert Englander

Stay ahead with the world's most comprehensive technology and business learning platform.

With Safari, you learn the way you learn best. Get unlimited access to videos, live online training, learning paths, books, tutorials, and more.

Start Free Trial

No credit card required

10.2. Replacing the Provider and Router Classes

In order to make the SOAP header available to our service methods, we'll need to replace the router class with one of our own design. We could modify the org.apache.soap.server.RPCRouter class and rebuild the Apache SOAP source tree, but that's a bit messy; we'd have to go through the process again for every new release of the Apache SOAP engine. Luckily, Apache SOAP makes use of a concept called pluggable providers. This means that you can plug in your own provider to be used with a given service deployment. To use your own provider, you must implement your own provider class. This is just the hook we're looking for. Creating our own provider lets us use our own router, which can pass the SOAP header to our service methods. For instance, if we implement a provider class called BetterRPCJavaProvider, we can associate it with a service deployment by modifying the isd:provider element in the relevant deployment descriptor:

<isd:provider type="javasoap.book.ch10.services.BetterRPCJavaProvider"

This element tells the RPC router servlet to use our new provider class instead of the default provider. That's exactly what we want. So let's write our own provider.

All providers must implement the org.apache.soap.util.Provider interface, which contains locate( ) and invoke( ) methods. The locate( ) method locates the service deployment information in preparation for the method invocation. The invoke( ) method invokes the service method, ...

With Safari, you learn the way you learn best. Get unlimited access to videos, live online training, learning paths, books, interactive tutorials, and more.

Start Free Trial

No credit card required