Hi I want to implement a web service on a remote application server that will perform write actions to the database. Another application running on another application server will be consuming those web services that are exposed. How would I go about doing this? I was reading the Spring documentation and there is talk of using contract first web services and using the MessageDispatcherServlet. Then in another section called “remoting”, I read about Hessian and Burlap which communicate over HTTP.
There are so many options, which one should I choose?
the answer, as with so many things, depends.
if both your client and your server are only Java, and will not be anything else, and you have the ability to deploy new versions of the jars for both the client and the server at the same time (e.g., you can restart both the client and the server whenever a change in the java classes occurs), then consider Spring’s RPC “remoting” support. The remoting support basically works by taking the interface of an object and interacting with it from another machine. It is tightly coupled to that interface. But, this approach has the benfit of being convenient to use and it requires very little to take an existing POJO and export it as a service. Additionally, RPC mechanisms tend to not rely on the HTTP protocol, so if you’re serious about speed and you feel like you can’t afford to even have the hTTP exchange on the wire in your invocations, then consider one of the “remoting” options. Spring core supports RMI, HTTP-Invoker, Burlap and Hessian. I’ve implemented support for numerous other exporters that use more contemporary RPC technologies like Thrift, MessagePack, JBoss Remoting, and Avro. All of these technologies offer their own “serialization” technique which in turn comes with its own advantages and drawbacks, just as RMI, Hessian and Burlap do.
All that said, the “remoting” support is probably not the safest option because the client and the server are tightly coupled: if you change the java class used on the server, youll need to change the Java class used on the client.
Instead, prefer a “document-oriented” approach like REST, or Spring’s contract-first web services.In these technologies, you have two steps for the minimal web service: you define your Java service(s) with their associated return types and objects, and then you define the interface in terms of HTTP endpoints and the associated documents you’re prepared to handle at those endpoints. The “documents” you send, for example, over REST, may be XML documents, or they may be JSON documents, or any of a number of types of encoding. The point is that they are transmitted using HTTP and there must be machinery in place, like Spring MVC, to receive those documents and transform them into objects that are meaningful to your application. The nice part about doing things this way is that you can evolve the actual java service and the clients – who consume the HTTP endpoints and not the Java interface – are none the wiser.
The REST support in Spring MVC 3 is very, very powerful and easy to get started with. Spring uses an SPI interface called HttpMessageConverter to transform HTTP requests from JSON or XML into Java objects that you can interface with in your code, and to transform objects from your code into documents that can be sent as HTTP responses. Spring MVC automatically registers a HttpMessageConverter if you have the Jackson JSON library on the classpath, and it registers JAXB support if you have JAXB on your classpath. Using JAXB, for example, is definitely out of the scope of this question, but you can look it up pretty readily. Spring will automatically respond to an HTTP request based on the type of the HTTP request’s “Accept” header. If you specify, “Accept=application/xml” then it’ll look for the appropriately registered HttpMessageConverter to transform the result into XML. It does the same for other “Accept” header values.
RESTful web services, or SOAP-based, contract-first are of course subject to the speed of the underlying HTTP exchange. Additionally, SOAP or REST XML documents or even JSOn documents can be bloated, and inefficient across the wire. So, you can implement more efficient HttpMessageConverters. I have provided a HttpMessageConverter that lets you do RESTful exchanges using Avro, Thrift, Snappy (a compression library), Google Protocol Buffers, and MessagePack. Now, of course, even with these, you’re still subject to the latency intrinsic to HTTP, but at least the payloads themselves can be as efficient as possible. The message converters are effectively different ways of serializing, or encoding, the payloads. Instead of JSON, or XML, you simply use one of these instead. For examples, consult the tests in that package. For good, getting started examples check out hte Spring MVC showcase