Remoting

In this chapter, you’ll learn about some of the mechanisms available in Spring, and you’ll look at a simple example of remote access from a Spring-based client application to a service l

■ ■ ■

Remoting

From time to time, you will want to transfer data between Java application processes

Sometimes these will be running on the same machine, but typically they will be running

on physically distant machines Remoting is the general term for the technologies that allow

you to invoke methods on Java classes residing in other processes and on distant machines

Various remoting mechanisms can collectively be used to transfer data between

appli-cation servers—from server to client, from client to server, and from client to client In this

chapter, you’ll learn about some of the mechanisms available in Spring, and you’ll look at

a simple example of remote access from a Spring-based client application to a service layer

running in a Spring-based application server

Remoting Mechanisms

Java provides innate support for a good selection of remoting mechanisms, and the Spring

framework provides comprehensive support for them Where possible, Spring provides

the minimal amount of intrusion into your application architecture; in ideal circumstances,

the configuration merely amounts to the initialization of an additional bean, but some

protocols, particularly those that are not specific to the Java platform, require you to provide

additional information in configuration files

The need to provide mappings between Java classes and interfaces and the protocol

arises from the differences of capabilities of various languages For example, the

multiple-inheritance capabilities of C++ do not exactly correspond to the single-multiple-inheritance-of-

single-inheritance-of-functionality and multiple-inheritance-of-interfaces model supported by Java In these

circumstances, the translation between the two models must be made tediously explicit

When a Java-specific protocol is used, configuration can be simpler, but if custom

objects are to be passed over the link, both ends must have access to implementation

classes In several of our examples, we will pass our entity objects over the link, and so it is

necessary to have a copy of the core library available to both the client and the server

implementations

Figure 9-1 shows the relationships among the main libraries (timesheet-core, timesheet-client, and timesheet-webapp) in our example application, highlighting that the two instances of the core library implementation communicate only via the client and web application components.

Figure 9-1 The relationships between the libraries

RMI

The Java remote method invocation (RMI) protocol is available as a standard part of the JSE environment For the Java developer, RMI is probably the default choice in any situation where you can guarantee that the applications at both ends of the connection will always

be Java based

Spring’s support for RMI-based remoting is particularly convenient To make an interface accessible over RMI, you will need to configure an additional bean to create an RMI registry and associate it with the service bean Any objects passed into or returned from the exported service methods must be made serializable (RMI uses serialization to pass param-eter values over TCP socket connections)

The benefit of RMI in Spring is its simplicity of implementation Its deficiency is that this is not an especially portable mechanism (Java RMI is not compatible with C# RMI, for example), so this is not a good choice if you want to make a service available to indepen-dently developed client applications

Because of this ease of implementation, a common usage of RMI services is to create rich administrative applications This allows administrative staff to have a desktop applica-tion for updating a web application Because the RMI client calls into the same service layer that is being used by the web front end, the amount of software development required

is reduced, and the scope for introducing new problems (and corrupting data in unexpected ways) is also limited

It is possible to “tunnel” the RMI wire protocol (JRMP) over an HTTP connection, but this feature is only infrequently used because some aspects of the service behavior will then be dependent on intervening network infrastructure such as proxy servers and firewalls

Implementing an RMI Server

The server application is, largely, the existing timesheet web application We will be exposing

only one small part of it, the user account service, the methods of which are defined by the

UserAccountService interface This is shown in Listing 9-1

Listing 9-1 The User Account Service to Be Made Available by RMI

public interface UserAccountService {

UserAccount findUser(String username);

void createUser(UserAccount account);

void deleteUser(UserAccount account);

void updateUser(UserAccount account);

List<UserAccount> listUsers();

}

We will be calling into the listUsers() method of Listing 9-1, which returns a list of

UserAccount entities You should note that the UserAccount entity has been made serializable

in order to support this behavior However, in practice, the requirements of serializability

are completely compatible with the requirements for Hibernate-persisted entities, so only

trivial changes (if any) are normally necessary in our type of environment

Aside from the objects to be passed into or returned from the service, the rest of the

implementation is irrelevant; the implementation bean is exposed via RMI, but the client

needs only a copy of the interface and the implementation of the parameter objects

Listing 9-2 shows the addition to the applicationContext.xml configuration file to

import the configuration of the RMI server capability

Listing 9-2 Importing the Spring RMI Configuration

<import resource="classpath:timesheet-remote.xml"/>

Listing 9-3 shows the configuration of the bean that then achieves this

Listing 9-3 The Configuration of the RMI Service Exporter

<bean class="org.springframework.remoting.rmi.RmiServiceExporter">

<property name="serviceName" value="UserAccountService"/>

<property name="service" ref="userAccountService"/>

<property name="serviceInterface"

value="com.apress.timesheets.service.UserAccountService"/>

<property name="registryPort" value="1001"/>

</bean>

The RMI service exporter configured in Listing 9-3 performs two tasks: creating and

instantiating the RMI registry and registering the user account service bean with it by a

given name

The serviceName property defines the name by which clients will access the service This has no connection with the class names or the bean IDs used by Spring The service property references the bean implementation to be exported.

The service interface references the interface whose methods are to be made available over RMI This must be explicitly specified, and your bean implementation must therefore implement at least one interface in order to be made into an RMI service If this is not compatible with your design for some reason, you will have to create an additional bean implementation honoring a suitable interface that delegates method calls to the original service bean Spring cannot autodetect and export service methods because of the risk of accidentally exposing inappropriate (insecure or privileged) methods such as property setters to untrusted external parties The interface is the only mechanism by which you can define the basic set of methods to be exported

Finally, the registryPort specifies the port on which the registry will accept queries from RMI clients When a client connects, it will connect to the registry on this port and negotiate with it for a channel to the service in question

Implementing an RMI Client

The client application should have access to the same interface definitions as the server, and to the same parameter implementations In the example application, you will see that

I have achieved this by giving the client Maven project a dependency on the core project containing these implementations Although this actually gives us access to the service implementation also, we do not use these local copies of the service, as you will see if you reconfigure the client and the server to execute on physically different networked machines!

■ Note Strictly speaking, it is possible to avoid the need to have copies of the interface and parameter objects

in the client’s classpath; it is possible to configure RMI to download these upon demand However, for most purposes, this introduces unnecessary complexity, and I do not recommend the approach

Listing 9-4 shows the remarkably simple context configuration necessary to make the user account service exported from the server available from the client Spring uses Java’s proxying facility to hide the RMI method calls behind a generated object that implements the specified interface

Listing 9-4 The Client Proxy to the Service Bean

<bean id="userAccountService"

class="org.springframework.remoting.rmi.RmiProxyFactoryBean">

<property name="serviceUrl"

value="rmi://localhost:1001/UserAccountService"/>

<property name="serviceInterface"

value="com.apress.timesheets.service.UserAccountService"/>

</bean>

</beans>

The serviceUrl property defines the network location of the service we are connecting

to This is composed of the protocol (RMI), the hostname (localhost in my example, but

you can site the client and server on different platforms if you change this configuration

detail), and the port upon which you are connecting, which must correspond to the registry

port specified in Listing 9-3 (both the client and the server will default to port 1099 if none

is explicitly specified) The final part of the URL is the name of the service configured with

the serviceName property in Listing 9-3 This is arbitrarily selected by the person

config-uring the service

The serviceInterface property specifies the fully qualified class name of the interface

defining the API to the service The implementation of this interface must be present on

the client as well as on the server because it is the template used to create the proxy object

that will represent the remote implementation

Listing 9-5 shows an implementation of the client

Listing 9-5 The RMI Client Application

public class RmiExample {

public static void main(String args) {

// Get the local configured context

final ApplicationContext ctx =

new ClassPathXmlApplicationContext("timesheet-client.xml");

// Retrieve a bean (the proxy to the remote service)

final UserAccountService service =

(UserAccountService)ctx.getBean("userAccountService");

// Extract data from the bean (via the remote service)

final List<UserAccount> users = service.listUsers();

This uses a single context configuration file named timesheet-client.xml that configures the single bean of Listing 9-4 This implementation uses the RMI service to obtain a list of the UserAccount objects known to the remote system (the process of serializing a Hibernate entity will force the loading of any lazily loaded properties) and then iterates over the list displaying the usernames of the accounts.

Spring’s Own HTTP-Based Remoting Mechanism

Spring provides its own mechanism for remoting: the HTTP invoker As this name suggests, this is available purely for the purpose of building web services Its sole advantages over RMI are that it is marginally simpler to configure and is explicitly intended for use over HTTP In principle, it is also possible for third-party clients to invoke Spring’s mechanism, but in practice, its relative obscurity and its use of the Java serialization mechanism in encoding objects sent over the network makes this a more theoretical than practical feature.Even among Java developers, those who are unfamiliar with Spring are unlikely to have encountered Spring’s HTTP invoker It also requires the client implementation to use Spring libraries—although this is a relatively minor issue because the Spring IOC approach makes Spring’s own implementations easy to integrate with other frameworks regardless

of their architectural philosophies

Implementing a Spring HTTP Invoker Server

The Spring HTTP invoker receives incoming HTTP requests from the client, parses them into its internal format, converts them to service invocations, makes the invocation, and encodes the results as a response page for processing by the client

To get access to the incoming requests, the invoker must therefore be mapped to URLs

in the web application’s namespace This is done in the normal Spring manner by uring a DispatcherServlet to pass the incoming Java EE web requests to the Spring request handlers

config-In principle, we could use the same dispatcher servlet that we established for handling conventional web requests in Chapter 6, but this would add some complexity to the URL-mapping configuration and require us to intermingle the web controllers with the remoting request handlers Instead, as shown in Listing 9-6, we configure a custom dispatcher for these requests and map it to incoming requests on the invoker path of the application context

Listing 9-6 Configuring the Dispatcher for the Invoker Service

<servlet>

<servlet-name>invoker</servlet-name>

<servlet-class>

Individual services are mapped to paths beneath this one, so that our eventual URL will

have the form http://server:port/context/invoker/service.

Listing 9-7 shows the mapping of the service name within this path to the

HttpInvokerServiceExporter implementation that will handle the incoming requests and

forward them to the service

Listing 9-7 Configuring the Invoker Service Exporter

<bean name="/userAccountService" class=

We supply this with a reference to the service that we are exporting, which is again the

user account service We also supply the service interface that we are exporting—again, as

with RMI, this is mandatory because otherwise we might accidentally expose inappropriate

service methods to the caller

The path on which the service is accessed is defined by the web application context

bean name and is appended to the dispatcher path Assuming that the server is running

locally on port 8080, and that the web application context is timesheet, the full path to this

service will therefore be http://localhost:8080/timesheet/invoker/userAccountService

This is how we will configure the client in the next section

Implementing a Spring HTTP Invoker Client

The Spring HTTP invoker client establishes an HTTP connection to the remote server,

transmits the encoded service call, and awaits a response from the server The client

creates a proxy object to represent the remote service that implements the supplied interface

(corresponding to the remote service interface) The class used to instantiate these proxy objects behaves as a standard Spring factory bean, so we can use it to populate other beans’ properties with instances of the service, or obtain implementations directly from the Spring context.

Listing 9-8 shows the configuration of the Spring HTTP invoker client We define an HttpInvokerProxyFactoryBean bean and supply it with the path to remote service and the interface to implement

Listing 9-8 Configuring the Spring Invoker Client Proxy Factory

<bean id="invokerUserAccountService" class=

"org.springframework.remoting.httpinvoker.HttpInvokerProxyFactoryBean">

<property name="serviceUrl"

value="http://localhost:8080/timesheet/invoker/userAccountService"/> <property name="serviceInterface"

value="com.apress.timesheets.service.UserAccountService"/>

</bean>

Listing 9-9 shows the usage of the factory bean Here we are obtaining a bean instance from the application context by calling the context’s getBean method, but we could alter-natively inject a reference to the factory into any UserAccountService bean property

Listing 9-9 Invoking the Remote HTTP Invoker Service from the Client

final UserAccountService service =

(UserAccountService)ctx.getBean("invokerUserAccountService");

final List<UserAccount> users = service.listUsers();

System.out.println("(Invoker) User List");

System.out.println("===================");

for( final UserAccount user : users ) {

System.out.println(user.getAccountName());

}

Hessian and Burlap

Hessian and Burlap are remoting mechanisms created by Caucho Technology, creators of the Resin application server Hessian is based around binary data, and Burlap around XML data Both were designed for the provision of web services over HTTP and HTTPS, but both can now be used over ordinary TCP sockets Burlap’s implementation has a particularly small footprint with no reliance on external libraries, so it is simple to deploy and well suited to constrained memory environments (such as JME devices)

Hessian and Burlap provide something of a halfway house between the complexity of

SOAP and the simplicity of RMI These protocols are not as well known among Java developers

as RMI, and they are much less prominent in general than SOAP The ease of configuration

of the client and server components is comparable with RMI The cross-platform support

(for clients) is comprehensive

In my opinion, Burlap is a good choice when the client device is memory constrained

Hessian is a good choice if you want to publish a web service, at minimal inconvenience to

yourself, but which can still be supported by developers of third-party clients

Implementing a Hessian Server

Hessian is similar in design to the Spring HTTP invoker and is therefore configured in a

similar manner Again, for convenience we give it its own dispatcher servlet (configured in

Listing 9-10) to allow its services to have their own bean definition context and their own

Hessian does not use Java serialization to transmit custom objects across the network

connection Normally this would not present a problem, but Hibernate’s use of proxy

collection objects in conjunction with lazy loading can cause some problems, because the

unpopulated lazily loaded collection object can be materialized on the client link—without

access to the Hibernate session—resulting in a LazyInitializationException when its

contents are accessed There are three basic ways this problem can be addressed:

• If the Hibernate JAR file is not made available on the client, no attempt will be made

to use Hibernate’s custom implementations, and the collection contents will be forcibly materialized as they are sent over the link

• The user can use the Hibernate class’s static initialize() methods to “manually” materialize the contents of collections within service methods before they are returned

to the client This is potentially inefficient if the same service methods will be used internally by the server where no such workaround is required

• An alternative service class can be implemented to avoid returning Hibernate objects, either by returning all data as standard types, or by creating custom data transfer objects (DTOs) to wrap the data that would otherwise be passed as Hibernate entities

We will use the last of these three methods The alternative interface that will be mented to provide the service on the server, and for which a proxy will be generated on the client, is shown in Listing 9-11

imple-Listing 9-11 Defining the Remote Service Interface for Hessian

public interface HessianUserAccountService extends Remote {

public List<String> listUserNames() throws RemoteException;

}

This simple interface will be implemented by a wrapper delegating to the existing UserAccountService bean as shown in Listing 9-12 Calls to the listUserNames() method will return the accountName property of the accounts returned by the wrapped service’s listUsers() method

Listing 9-12 The Hessian Service Implementation

public class HessianUserAccountServiceImpl

implements HessianUserAccountService

{

private UserAccountService service;

public List<String> listUserNames() {

final List<UserAccount> list = service.listUsers();

final List<String> names = new ArrayList<String>();

for( final UserAccount account : list ) {

names.add(account.getAccountName());

}

return names;

}

This delegating bean is configured within the servlet-specific bean definition file shown

in Listing 9-13 Its sole configuration parameter is a reference to the service bean that it wraps

Listing 9-13 Configuring the Hessian Service Bean and Exporter

Listing 9-13 also shows the configuration of the exporter This Spring wrapper for the

Hessian server component is near identical to the corresponding exporter for Spring’s

HTTP invoker mechanism The pathname is defined by the bean name The exporter

passes incoming requests to a specified service bean that must implement the specified

service interface The only significant difference in configuration is our use of a service

wrapper and corresponding interface to avoid the conflict with Hibernate lazy loading

Implementing a Hessian Client

The Hessian client configuration also corresponds closely to the HTTP invoker’s client

configuration The client bean is provided with the path to the remote service, and calls to

the factory materialize proxy instances that implement the supplied service interface

Listing 9-14 shows this configuration

Listing 9-14 Configuring the Hessian Client Proxy Factory