Using the RmiServiceExporter, we can expose the interface of our AccountService object as RMI object. The interface can be accessed by using RmiProxyFactoryBean, or via plain RMI in case of a traditional RMI service. The RmiServiceExporter explicitly supports the exposing of any non-RMI services via RMI invokers.

Of course, we first have to set up our service in the Spring BeanFactory:

<bean id="accountService" class="example.AccountServiceImpl">
    <!-- any additional properties, maybe a DAO? -->
</bean>
				

Next we'll have to expose our service using the RmiServiceExporter:

<bean class="org.springframework.remoting.rmi.RmiServiceExporter">
	<!-- does not necessarily have to be the same name as the bean to be exported -->
	<property name="serviceName"><value>AccountService</value></property>
	<property name="service"><ref bean="accountService"/></property>
	<property name="serviceInterface"><value>example.AccountService</value></property>
	<!-- defaults to 1099 -->
	<property name="registryPort"><value>1199</value></property>
</bean>
				

As you can see, we're overriding the port for the RMI registry. Often, your application server also maintains an RMI registry and it is wise to not interfere with that one. Furthermore, the service name is used to bind the service under. So right now, the service will be bound at rmi://HOST:1199/AccountService. We'll use the URL later on to link in the service at the client side.

Note: We've left out one property, i.e. the servicePort property, which is 0 by default. This means an anonymous port will be used to communicate with the service. You can specify a different port if you like.

Our client is a simple object using the AccountService to manage accounts:

public class SimpleObject {
  private AccountService accountService;
  public void setAccountService(AccountService accountService) {
    this.accountService = accountService;
  }
}
				

To link in the service on the client, we'll create a separate bean factory, containing the simple object and the service linking configuration bits:

<bean class="example.SimpleObject">
	<property name="accountService"><ref bean="accountService"/></bean>
</bean>

<bean id="accountService" class="org.springframework.remoting.rmi.RmiProxyFactoryBean">
	<property name="serviceUrl"><value>rmi://HOST:1199/AccountService</value></property>
	<property name="serviceInterface"><value>example.AccountService</value></property>
</bean>
				

That's all we need to do to support the remote account service on the client. Spring will transparently create an invoker and remotely enable the account service through the RmiServiceExporter. At the client we're linking it in using the RmiProxyFactoryBean.

Hessian communicates via HTTP and does so using a custom servlet. Using Spring's DispatcherServlet principles, you can easily wire up such a servlet exposing your services. First we'll have to create a new servlet in your application (this an excerpt from web.xml):

<servlet>
	<servlet-name>remote</servlet-name>
	<servlet-class>org.springframework.web.servlet.DispatcherServlet</servlet-class>
	<load-on-startup>1</load-on-startup>
</servlet>
				

You're probably familiar with Spring's DispatcherServlet principles and if so, you know that know you'll have to create an application context named remote-servlet.xml (after the name of your servlet) in the WEB-INF directory. The application context will be used in the next section.

In the newly created application context called remote-servlet.xml we'll create a HessianServiceExporter exporting your services:

<bean id="accountService" class="example.AccountServiceImpl">
    <!-- any additional properties, maybe a DAO? -->
</bean>

<bean name="/AccountService" class="org.springframework.remoting.caucho.HessianServiceExporter">
    <property name="service"><ref bean="accountService"/></property>
    <property name="serviceInterface">
        <value>example.AccountService</value>
    </property>
</bean>
				

Now we're ready to link in the service at the client. No handler mapping is specified mapping requests (urls) onto services and that's why the BeanNameUrlHandlerMapping will be used, hence the service will be exported at the URL http://HOST:8080/AccountService.

Using the HessianProxyFactoryBean we can link in the service at the client. The same principles apply as with the RMI example. We'll create a separate bean factory or application context and mention the following beans where the SimpleObject is using the AccountService to manage accounts:

<bean class="example.SimpleObject">
    <property name="accountService"><ref bean="accountService"/></property>
</bean>

<bean id="accountService" class="org.springframework.remoting.caucho.HessianProxyFactoryBean">
	<property name="serviceUrl"><value>http://remotehost:8080/AccountService</value></property>
	<property name="ServiceInterface"><value>example.AccountService</value></property>
</bean>
				

That's all there is to it.

We won't discuss Burlap, the XML-based equivalent of Hessian, in detail here, since it is configured and set up in exactly the same way as the Hessian variant explained above. Just replace the word Hessian with Burlap and you're all set to go.

One of the advantages of Hessian and Burlap is that we can easily apply HTTP basic authentication, because both protocols are HTTP-based. Your normal HTTP server security mechanism can easily be applied through using the web.xml security features, for example. Usually, you don't use per-user security credentials here, but rather shared credentials defined at the Hessian/BurlapProxyFactoryBean level (similar to a JDBC DataSource).

<bean class="org.springframework.web.servlet.handler.BeanNameUrlHandlerMapping">
	<property name="interceptors">
		<list>
			<ref bean="authorizationInterceptor"/>
		</list>
	</property>
</bean>

<bean id="authorizationInterceptor" 
	class="org.springframework.web.servlet.handler.UserRoleAuthorizationInterceptor">
	<property name="authorizedRoles">
		<list>
			<value>administrator</value>
			<value>operator</value>
		</list>
	</property>	
</bean>
				

This an example where we explicitly mention the BeanNameUrlHandlerMapping and set an interceptor allowing only administrators and operators to call the beans mentioned in this application context.

Note: Of course, this example doesn't show a flexible kind of security infrastructure. For more options as far as security is concerned, have a look at the Acegi Security System for Spring, to be found at http://acegisecurity.sourceforge.net.

Setting up the HTTP invoker infrastructure for a service objects much resembles the way you would do using Hessian or Burlap. Just as Hessian support provides the HessianServiceExporter, Spring Http invoker support provides the so-called org.springframework.remoting.httpinvoker.HttpInvokerServiceExporter. To expose the AccountService (mentioned above), the following configuration needs to be in place:

    <bean name="/AccountService" class="org.sprfr.remoting.httpinvoker.HttpInvokerServiceExporter">
        <property name="service"><ref bean="accountService"/></property>
        <property name="serviceInterface">
            <value>example.AccountService</value>
        </property>
	</bean>

Again, linking in the service from the client much resembles the way you would do it when using Hessian or Burlap. Using a proxy, Spring will be able to translate your calls to HTTP POST requests to the URL pointing to the exported service.

	
	<bean id="httpInvokerProxy" class="org.sprfr.remoting.httpinvoker.HttpInvokerProxyFactoryBean">
		<property name="serviceUrl">
			<value>http://remotehost:8080/AccountService</value>
		</property>
		<property name="serviceInterface">
			<value>example.AccountService</value>
		</property>
	</bean>

As mentioned before, you can choose what HTTP client you want to use. By default, the HttpInvokerProxy uses the J2SE HTTP functionality, but you can also use the Commons HttpClient by setting the httpInvokerRequestExecutor property:

<property name="httpInvokerRequestExecutor">
	<bean class="org.springframework.remoting.httpinvoker.CommonsHttpInvokerRequestExecutor"/>
</property>