Spring’s Support of Remoting
Spring tries to address the problems faced and sticks to its goals in providing the application developers with a good integration support without necessitating sticking onto a particular programming model. It does all this by abstracting the nitty-gritty’s of remoting and allows developers to concentrate on writing business logic.
Proxies form an integral part of Spring Remoting. All proxies are created with an instance of org.springframework.aop.framework.ProxyFactory and an implementation of org.aopalliance.intercept.MethodInterceptor.
Client end of the remote call is formed by a proxy and MethodInterceptor. The proxy is created with the exposed service’s interface. The MethodInterceptor instance deals with the communication part, extra processing/behavior and object serialization/deserialization. The server end of the remote service is formed by an exporter that deals with the specific communication protocol and serialization/deserialization mechanism.
Following Spring’s philosophy, if you would like to extend Spring Remoting to support a new protocol, a new exporter has to be written for the server end and a method-interceptor has to be written for the client side.
Some of the support provided by Spring Framework for remoting can be summarized as shown below:
- Ability to produce lightweight remoting which is simple and easy to use
- Ability to produce POJO-based remoting over a wide range of protocols available in the market
- Ability to exposure beans as HTTP-based remote services—e.g. Hessian, Burlap, HTTP invoker
- Ability to integrate with Web Services via JAX-RPC—e.g. Apache Axis
Gong beyond the basics, the following sections explain some very important Spring remoting concepts and terminologies. I have in my introduction to Spring’s support on remoting given some terms like service exporters and client proxies. We will now see these important components of Spring remoting in detail.
Service Exporters
Service providers are provided by Spring Framework to handle server-side requirements arising while exposing a service using Spring remoting. It is used to bind the service to a registry and to expose the service as an end-point. It is service exporter’s role to confirm to particular set of programming model and to conform to it. These exporters are the one which are complexly coupled with the programming model and spring uses these as a layer of separation from your programming code to the actual implementation. Figure 19-2 shows the role of a typical service exporter in the Spring remoting ecosystem in action.
Figure 19-2. Role of service exporter in Spring remoting
Client Proxies
To handle the various client side requires while exposing a service a using Spring remoting, Spring generates client side proxies with the help from FactoryBeans. These proxies are responsible for communicating with the server-side end-point. One of the very important functionality provides by these proxies are that they convert or rather translate the remote exceptions raised by various remote technologies to a standard and consistent runtime exceptions which need not be handled by the client calling the service. Figure 19-3 shows the role of the client proxy in the Spring remoting ecosystem in action.
Figure 19-3. Role of client proxy in Spring remoting
Architecture of Spring Remoting
Now that you have understood the various components in spring remoting, you will understand the architecture of the Spring Remoting as pictorially shown below in Figure 19-4.
Figure 19-4. Spring remoting architecture in whole
This Figure 19-4 above puts all the various components in a typical application using Spring remoting in the right context and also shows these components interaction in action pictorially to make you understand the concepts easily.
Page Visitors: 4585
Tomcy John
Latest posts by Tomcy John (see all)
- A Guide to Continuous Improvement for Architects - February 2, 2023
- Cloud-first Architecture Strategy - January 26, 2023
- Architecture Strategy and how to create One - January 24, 2023