Using spring to use remote access and Web Services (reprint)

The original post is reproduced in: http://avery-leo.javaeye.com/blog/206188

The article is very good, to help the author propaganda. using spring to use remote access and Web services

Spring provides classes for integrating various remote access technologies. This support for remote access can reduce the difficulty of developing your remote access business with POJO implementations. Currently, Spring provides support for the following four types of remote access technologies:

Remote method call (RMI). Support for traditional RMI by using Rmiproxyfactorybean and rmiserviceexporter,spring (using Java.rmi.Remote interfaces and java.rmi.RemoteException) and transparent remote calls through the RMI caller (which can use any Java interface).

The HTTP caller of spring. Spring provides a special remote invocation policy that supports any Java interface (like the RMI caller), which allows Java serialization to be delivered over HTTP. The corresponding support classes are Httpinvokerproxyfactorybean and Httpinvokerserviceexporter.

Hessian. By using Hessianproxyfactorybean and Hessianserviceexporter, you can use the lightweight HTTP based binary protocol provided by Caucho to transparently deliver your business.

Burlap. Burlap is xml-based, and it can completely replace Hessian. The support classes provided by spring are Burlapproxyfactorybean and burlapserviceexporter.

Jax RPC (TODO).

When we discuss spring's support for remote access, we will use the following domain model and the corresponding business:

Account domain object Public
class account implements serializable{
  private String name;

  Public String getName ();
  public void SetName (String name) {
    this.name = name;
  }
}
			

Account Service Public
interface Accountservice {public

  void Insertaccount (account ACC);
  
  Public List getaccounts (String name);
}
			

... and corresponding implement doing nothing in the moment public
class Accountserviceimpl implements Accountserv Ice {public

  void Insertaccount (account ACC) {
    /* something
  } public
  
  List getaccounts (String name ) {
    //do Something
  }
}
			

We first demonstrate the use of RMI to provide business to remote customers, and will talk about the drawbacks of using RMI. We will then continue to demonstrate a hessian example. 16.2. Use RMI to provide business

With spring's RMI support, you can transparently provide your business through RMI. After you have configured spring's RMI support, you will see a configuration similar to a remote EJB, with no standard support for security context delivery and remote transaction delivery. When using the RMI caller, Spring provides capture for these additional invocation contexts, so you can insert your security framework or security trust logic. 16.2.1. Provide business with Rmiserviceexporter

Using Rmiserviceexporter, we can output the Accountserver object as a RMI object. This interface can be accessed using Rmiproxyfactorybean, or as a traditional RMI service using simple RMI. Rmiserviceexporter supports the provision of any non-RMI business through RMI callers.

Of course, we first have to set up our business in spring's beanfactory:

<bean id= "Accountservice" class= "Example". Accountserviceimpl ">
    <!--any additional properties, maybe a DAO?-->
</bean>
				

Next, we use Rmiserviceexporter to provide our business:

<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 have replaced the RMI registered port. Normally, your application server will maintain RMI registration, and we'd better not interfere with it. The business name is used to bind the business. So now the business is tied to the rmi://host:1199/accountservice. We will use URLs at the client to connect the business.

Note: We omitted an attribute, which is the Serviceport property, which defaults to 0. This means that the business uses anonymous port traffic. Of course you can also specify a port. 16.2.2. Client Connection Services

Our client is a simple object that uses the Accountservice management account:

public class Simpleobject {
  private accountservice accountservice;
  public void Setaccountservice (Accountservice accountservice) {
    this.accountservice = Accountservice;
  }
}
				

To connect the business at the client, we build another bean factory that contains the configuration information for this simple object and the business connection:

<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>
				

This is what we need to do to access the remote account business on the client side. Spring transparently creates a caller, providing an account business remotely via Rmiserviceexporter. On the client side, we use Rmiproxyfactorybean to use the business. 16.3. Use Hessian or burlap to remotely invoke business via HTTP

Hessian provides a binary remote protocol based on HTTP. It is created by Caucho, and more information about Hessian can be accessed by http://www.caucho.com. 16.3.1. Establish Dispatcherservlet for Hessian

Hessian uses a specific servlet to communicate over HTTP. With the Dispatcherservlet concept of spring, you can easily create such a servlet to provide your business. First we have to create a new servlet in your application (from Web.xml below):

<servlet>
	<servlet-name>remote</servlet-name>
	<servlet-class> Org.springframework.web.servlet.dispatcherservlet</servlet-class>
	<load-on-startup>1</ Load-on-startup>
</servlet>
				

You may be familiar with the dispatcherservlet concept of spring, and if so, you have to create an application context in the Web-inf directory, Remote-servlet.xml. This application context is used in the next section. 16.3.2. Use Hessianserviceexporter to provide your bean

In this new application context Remote-servlet.xml, we will create a hessianserviceexporter to export your business:

<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>
				

We are now ready to connect this business on the client side. Using beannameurlhandlermapping, we do not need to specify a processor mapping to map the request (URL) to the business, so the business is provided on the Http://HOST:8080/AccountService. 16.3.3. Client Connection Services

We use Hessianproxyfactorybean to connect to the business at the client. The same principle as in the RMI example. We will create a separate bean factory or application context where the following beans will be mentioned where Simpleobject uses 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>
				

It's that simple. 16.3.4. Use burlap

We're not talking about burlap here, it's just a Hessian xml-based implementation. Because it is configured in the same way as the example above Hessian. As long as you replace Hessian to burlap. 16.3.5. Applying HTTP Basic Authentication in a business that is exported through Hessian or burlap

One of the advantages of Hessian and burlap is that we can easily apply HTTP authentication because both are HTTP based protocols. For example, the normal HTTP server security mechanism can be easily applied by using the Web.xml security feature. Typically, you do not create a different security trust for each user, but rather define shareable trusts (similar to JDBC DataSource) in the Hessian/burlap Proxyfactorybean.

<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>
				

In this example, we used the beannameurlhandlermapping and set up an interceptor that only allows administrators and operators to invoke the bean in this application context.

Note: Of course, this example does not demonstrate a flexible security facility. If you are considering more flexible security settings, you can go to the Acegi system,http://acegisecurity.sourceforge.net. 16.4. Use HTTP caller to output business

In contrast to burlap and Hessian lightweight protocols that use their own serialization mechanisms, the Spring HTTP caller uses the standard Java serialization mechanism to export the business through HTTP. If your argument or return value is a complex type and cannot be serialized through the serialization mechanism of the Hessian and burlap, the HTTP caller has an advantage (see the next section for considerations when choosing remote technology).

In fact, spring can implement HTTP calls using the standard functionality provided by J2SE or Commons httpclient. If you need more advanced and better features, use the latter. You can refer to jakarta.apache.org/commons/httpclient. 16.4.1. Output business Object

Setting the HTTP caller for a business object is similar to the way you use it in Hessian or burlap. Just as Hessian provides Hessianserviceexporter, Spring's HTTP caller provides a org.springframework.remoting.httpinvoker.HttpInvokerServiceExporter. To output Accountservice, use the following configuration:

    <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>

16.4.2. Connecting to business at the client

Similarly, connecting to a business from a client is similar to what you do when you use Hessian or burlap. With a proxy, spring can translate your call into an HTTP POST request to a URL that points to the output business.

	
	<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 above, you can choose to use the HTTP client you want to use. By default, Httpinvokerpropxy uses the J2SE HTTP feature, but you can also choose to use Commons HttpClient by setting the Httpinvokerrequestexecutor property:

<property name= "Httpinvokerrequestexecutor" >
	<bean class= " Org.springframework.remoting.httpinvoker.CommonsHttpInvokerRequestExecutor "/>
</property>

16.5. Some considerations in the selection of these technologies

Each of the techniques mentioned here has its drawbacks. When choosing these technologies, you should carefully consider your needs, the business you are exporting, and the objects that you transmit during remote access.

When using RMI, accessing an object via the HTTP protocol is not possible unless you use HTTP to wrap the RMI stream. RMI is a very heavy protocol because he supports full object serialization, which is important in requiring complex data structures to be transmitted remotely. However, RMI-JRMP can only be bound to a Java client: It is a Java-to-java scheme for remote access.

Spring's HTTP caller is a good choice if you need HTTP based remote access and also requires Java serialization. It uses the same infrastructure as the RMI caller and uses only HTTP as a means of transmission. Note The HTTP caller is not only used for Java-to-java remote access, but also must use spring on both the client and server side. (The RMI caller provided by spring for non-RMI interfaces also requires the client and server side to use spring)

When in heterogeneous environments, Hessian and burlap are very useful. Because they can be used on non-Java clients. However, there is still a limit to non-Java support. Known issues include serialization of Hibernate objects that contain deferred initialization of collection objects. If you have a data structure like this, consider using RMI or HTTP callers instead of Hessian.

Last but not least, EJB is superior to RMI because it supports standard role-based authentication and authorization, as well as remote transaction delivery. It is possible to support the delivery of security contexts with the RMI caller or HTTP caller, although this is not provided by core spring: it is addressed by a third party or by inserting interceptors into a custom solution.