Exposing services using RMI

4.3.9.RELEASE Spring Framework 669 the implementation doing nothing at the moment public class AccountServiceImpl implements AccountService { public void insertAccountAccount acc { do something... } public ListAccount getAccountsString name { do something... } } We will start exposing the service to a remote client by using RMI and talk a bit about the drawbacks of using RMI. We’ll then continue to show an example using Hessian as the protocol.

28.2 Exposing services using RMI

Using Spring’s support for RMI, you can transparently expose your services through the RMI infrastructure. After having this set up, you basically have a configuration similar to remote EJBs, except for the fact that there is no standard support for security context propagation or remote transaction propagation. Spring does provide hooks for such additional invocation context when using the RMI invoker, so you can for example plug in security frameworks or custom security credentials here. Exporting the service using the RmiServiceExporter 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 container: 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 property name = service ref = accountService property name = serviceInterface value = example.AccountService -- defaults to 1099 -- property name = registryPort value = 1199 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 The servicePort property has been omitted it defaults to 0. This means that an anonymous port will be used to communicate with the service. 4.3.9.RELEASE Spring Framework 670 Linking in the service at the client Our client is a simple object using the AccountService to manage accounts: public class SimpleObject { private AccountService accountService; public void setAccountServiceAccountService accountService { this .accountService = accountService; } additional methods using the accountService } To link in the service on the client, we’ll create a separate Spring container, containing the simple object and the service linking configuration bits: bean class = example.SimpleObject property name = accountService ref = accountService bean bean id = accountService class = org.springframework.remoting.rmi.RmiProxyFactoryBean property name = serviceUrl value = rmi:HOST:1199AccountService property name = serviceInterface value = example.AccountService 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 .

28.3 Using Hessian or Burlap to remotely call services via HTTP