Overall figure of remoting

Cluster4Spring was designed to be very similar to the existing remoting subsystem offered by Spring framework to simplify transition and adoption of it.

Due to it, it uses the same scheme as Spring framework (and, in general, any remoting implementation):

Overall scheme of remoting

There is remote service implementation that resides on the server. On the client side there is a proxy of that remote service which has the same interface as remote service. Caller code invokes methods of proxy and responsibility of proxy implementation is to perform necessary remote communications, to invoke methods of remote service and return results to the caller code.

Cluster4Spring utilizes the same transparent approach to remoting as Spring does - remoting is transparent for caller code and caller code is only aware of remote service interface. Since all magic of remote calls is hidden in proxy, it is possible to use different remoting implementations without affecting application code simply by using various configurations of Spring context.

Supported remoting schemes

One of the major features of Cluster4Spring is support of different remoting schemes. These schemes are:

  • One-to-one;
  • One-to-many static;
  • One-to-many with dynamic discovering;

All these schemes are completely transparent for application code and only are defined by the appropriate configuration of remoting-related functionality of application described in Spring configuration files.

Selection of particular remoting scheme depends on the specifics and needs of particular application.

Here we consider possible remoting schemes in more detail.

One-to-one

This is the simplest scheme and it is the only one supported by remoting subsystem of Spring framework.

One-to-one remoting scheme

The diagram above illustrates one-to-one remoting scheme. Such scheme assumes that there is one known location of remote service and client can access only that remote instance using that predefined and known service location.

Quick configuration example

This is a quick example of minimal configuration for client-side proxy factory bean for one-to-one remoting scheme if RMI is used as underlying remoting protocol:

<bean name="TestService"
����� class="org.softamis.cluster4spring.rmi.RmiSingleUrlProxyFactoryBean">
  <property name="serviceInterface"
            value="org.softamis.cluster4spring.example.Service"/>
  <property name="serviceUrl"
            value="rmi://localhost:1099/TestService"/>
</bean>

It is enough to have Cluster4Spring proxy on client side and use ordinary Spring exporter for remoting service on server to use such scheme of remoting (however, exporter which is included into Cluster4Spring provides extended functionality compared to that of Spring).

Static one-to-many

This scheme is more complex yet more powerful. It can be used to create distributed systems with high-level fault tolerance and (if appropriate policy for selecting servers is used) to divide the load among several servers.

Such scheme assumes that there is one client and several servers with known locations that are specified as part of remote proxy configuration. Based on appropriate policy, client may select one of these services for actual invocation of remote service methods.

One-to-many remoting scheme with static services

The figure above illustrates static one-to-many remoting scheme.

In addition, if some server becomes inaccessible or some network issues occur while performing remote call to it, the client proxy (optionally, if specified by configuration) may select another instance of remote service (in other words, another server) and re-invoke the corresponding method from it.

Quick configuration example

This is a quick example of the minimal configuration for client-side proxy factory bean for static one-to-many remoting scheme if RMI is used as underlying remoting protocol:

<bean name="TestService"
���� �class="org.softamis.cluster4spring.rmi.RmiUrlListProxyFactoryBean">
  <property  name="serviceInterface"
            value="org.softamis.cluster4spring.example.Service"/>
 �<property name="serviceURLs">
  ���<list>
  �����<value>rmi://host1:1097/TestService</value>
  �����<value>rmi://host2:1098/TestService</value>
       <value>rmi://host3:1099/TestService</value>
    </list>
  </property>
</bean>

It can be enough to have Cluster4Spring proxy on client side and use ordinary Spring exporter for remoting service on server to use such scheme of remoting.

One-to-many with dynamic services discovering

In general, such scheme can be considered to be a further evolution of one-to-many scheme.

Exactly as to static one-to-one scheme, such a scheme of remoting also includes one (or more) client that can invoke remote service from one of available locations. However, unlike the previous scheme, available locations of remote service are dynamically discovered.

The figure below illustrates dynamic one-to-many remoting scheme.

One-to-many remoting with dynamic services discovering

Dynamic discovering of services is performed with the use of appropriate distribute registry which contains information on all locations of particular remote service. To let the service be dynamically discovered, server publishes information on it in distributed registry, so the client is able to access that registry and locate all instances of remote service there.

If such scheme of remoting is used, it is necessary to have Cluster4Spring proxy on client side and exported and publisher on server side (these notions will be described below).

Quick configuration example

This is a quick example of minimal configuration for client-side proxy factory bean for dynamic one-to-many remoting scheme if RMI is used as underlying remoting protocol: 

<bean name="TestService"
  ����������class="org.softamis.cluster4spring.rmi.RmiDiscoveringProxyFactoryBean">
� <property name="serviceInterface"
            value="org.softamis.cluster4spring.example.Service"/>
� <property name="serviceName"
            value="TestService"/>
� <property name="clientServicesRegistry" value="_ClientServicesRegistry"/>
</bean>

The "_ClientServicesRegistry" is ID of bean that represents client part of distributed registry. Cluster4Spring comes with ready to use implementation of distributed services registry, but, if necessary, it is possible to use custom implementation of such registry.

And this is a sample of server side configuration for exporters and publisher for remote service:

  <bean class="org.softamis.cluster4spring.rmi.RmiServiceExporter">
   <property name="registry" ref="_RMIRegistry"/>
  � <property name="service">
    � <bean class="org.softamis.cluster4spring.example.ServiceImpl"/>
  � </property>
  � <property name="serviceInterface" value="org.softamis.cluster4spring.example.Service"/>
  � <property name="serviceName" value="TestService"/>
  </bean>

  <bean id="RMIServicesPublisher"
        class="org.softamis.cluster4spring.rmi.RmiServicePublisher">�
    <property name="servicesRegistry" ref="_ServerServicesRegistry"/>
  </bean>
  SourceForge.net Logo   Support This Project