Spring Study Notes - Copyright © 2010 Gavin Lasnitzki Index   Notes   Objectives
Spring Remoting (including Web Services)

17. Remoting and web services using Spring

17.1. Introduction Key

Objectives: 8.1 Goals of Spring Remoting , 8.2 Remoting Overview

Spring supports four remoting technologies: Question

  • Remote Method Invocation (RMI).
    Through the use of the RmiProxyFactoryBean and the RmiServiceExporter.
    Spring supports both traditional RMI (with java.rmi.Remote interfaces and java.rmi.RemoteException) and transparent remoting via RMI invokers (with any Java interface).
  • Spring's HTTP invoker.
    Spring provides a special remoting strategy which allows for Java serialization via HTTP, supporting any Java interface (just like the RMI invoker). The corresponding support classes are HttpInvokerProxyFactoryBean and HttpInvokerServiceExporter.
  • Hessian & Burlap.
    Hessian - By using Spring's HessianProxyFactoryBean and the HessianServiceExporter you can transparently expose your services using the lightweight binary HTTP-based protocol provided by Caucho.
    Burlap - Burlap is Caucho's XML-based alternative to Hessian. Spring provides support classes such as BurlapProxyFactoryBean and BurlapServiceExporter.
  • Web Services
    JAX-RPC - Spring provides remoting support for web services via JAX-RPC (J2EE 1.4's web service API).
    JAX-WS - Spring provides remoting support for web services via JAX-WS (the successor of JAX-RPC, as introduced in Java EE 5 and Java 6).
    JMS - Remoting using JMS as the underlying protocol is supported via the JmsInvokerServiceExporter and JmsInvokerProxyFactoryBean classes.

17.2. Exposing services using RMI Key

Objectives: 8.3 Supported Protocols

You can transparently expose your services through the RMI infrastructure.
This configuration is similar to remote EJBs without the standard support for security context propagation, remote transaction propagation, etc.

17.2.1. Exporting the service using the RmiServiceExporter Key

17.2.2. Linking in the service at the client Key

17.3. Using Hessian or Burlap to remotely call services via HTTP

Objectives: 8.3 Supported Protocols

17.3.1. Wiring up the DispatcherServlet for Hessian and co. Key

Hessian communicates via HTTP and does so using a custom servlet.

Using Spring's DispatcherServlet principles
Create a new servlet in your application (this an excerpt from 'web.xml'):

 

Create a Spring container configuration resource named 'remoting-servlet.xml' (after the name of your servlet) in the 'WEB-INF' directory.

 

Using Spring's HttpRequestHandlerServlet
Alternatively, use of Spring's simpler HttpRequestHandlerServlet, which allows you to embed the remote exporter definitions in your root application context with individual servlet definitions pointing to specific exporter beans. Each servlet name needs to match the bean name of its target exporter in this case.

 

17.3.2. Exposing your beans by using the HessianServiceExporter

17.3.3. Linking in the service on the client Key

17.3.4. Using Burlap

Similar to Hessian. Replace Hessian with Burlap in above examples..

17.3.5. Applying HTTP basic authentication to a service exposed through Hessian or Burlap

Your normal HTTP server security mechanism can easily be applied through using the web.xml security features.

17.4. Exposing services using HTTP invokers

Objectives: 8.3 Supported Protocols

Spring Http invokers use the standard Java serialization mechanism to expose services through HTTP.
Handles complex arguments and return types (not serialized by Hessian / Burlap).

17.4.1. Exposing the service object

Similar to Hessian. Replace Hessian with HttpInvoker in the above examples.

17.4.2. Linking in the service at the client

17.5. Web services

Spring provides full support for exposing and accessing standard Java web services using JAX-RPC (JDK 1.4) and JAX-WS (Java 5). Question

Spring Web Services is a solution for contract-first, document-driven web services.

17.5.1. Exposing servlet-based web services using JAX-RPC Key

Spring provides a convenience base class for JAX-RPC servlet endpoint implementations - ServletEndpointSupport Question

17.5.2. Accessing web services using JAX-RPC

Create JAX-RPC web service proxies using either LocalJaxRpcServiceFactoryBean or JaxRpcPortProxyFactoryBean. Question

 

By supplying an RMI interface (via the portInterface) and non-RMI interface (via the serviceInterface) we can get rid of the checked RemoteException (as Spring supports automatic conversion to its corresponding unchecked RemoteException).

The JaxRpcPortProxyFactoryBean can also switch to "Dynamic Invocation Interface", which does not require a RMI-compliant port interface.

17.5.3. Registering JAX-RPC Bean Mappings

Extend JaxRpcPortProxyFactoryBean to register bean mappings on the client side.

17.5.4. Registering your own JAX-RPC Handler

Spring has at this time of writing no declarative support for registering handlers so JaxRPCPortProxyFactoryBean needs to be extended and postProcessJaxRpcService(..) overridden.

17.5.5. Exposing servlet-based web services using JAX-WS Key

Spring provides a convenient base class for JAX-WS servlet endpoint implementations - SpringBeanAutowiringSupport.

17.5.6. Exporting standalone web services using JAX-WS Key

The built-in JAX-WS provider that comes with Sun's JDK 1.6 supports exposure of web services using the built-in HTTP server that's included in JDK 1.6 as well.
Spring's SimpleJaxWsServiceExporter detects all @WebService annotated beans in the Spring application context, exporting them through the default JAX-WS server (the JDK 1.6 HTTP server).

In this scenario, the endpoint instances are defined and managed as Spring beans themselves.
They will be registered with the JAX-WS engine but their lifecycle will be up to the Spring application context. This means that Spring functionality like explicit dependency injection may be applied to the endpoint instances.

 

The AccountServiceEndpoint may derive from Spring's SpringBeanAutowiringSupport but doesn't have to if the endpoint is a fully Spring-managed bean.

17.5.7. Exporting web services using the JAX-WS RI's Spring support

17.5.8. Accessing web services using JAX-WS

17.5.9. Exposing web services using XFire

17.6. JMS

17.6.1. Server-side configuration

17.6.2. Client-side configuration

17.7. Auto-detection is not implemented for remote interfaces

17.8. Considerations when choosing a technology Key Question

RMI
(Con) Not possible to access the objects through the HTTP protocol, unless you're tunneling the RMI traffic.
(Pro) RMI is a fairly heavy-weight protocol in that it support full-object serialization which is important when using a complex data model.
(Con) It is a Java-to-Java remoting solution.

Hessian and/or Burlap
(Pro) Allow for non-Java clients (however this is limited).
(Con) Know issues with full object serialization.

HttpInvoker
(Pro) HTTP based protocol.
(Pro) Supports full object serialization.

JMS
(Pro) JMS can be useful for providing clusters of services and allowing the JMS broker to take care of load balancing, discovery and auto-failover.
(Pro) By default Java serialization is used when using JMS remoting but the JMS provider could use a different mechanism for the wire formatting.

EJB
Last but not least, EJB has an advantage over RMI in that it supports standard role-based authentication and authorization and remote transaction propagation.