Remoting semantics of Spring slightly changed

Time passes too quickly, already a month passed since my last blog entry :-(.
We slightly adapted the remoting semantics of Spring. Here's a picture that shows how it works:


In the picture there are 2 JVMs: one has the client and one has the server role. We show the spring application context of each JVM. The rectangles with rounded corners are spring beans (Java objects created by Spring). The normal rectangles are normal Java objects. Arrows are normal Java references. Spring beans with a dashed ring around have an auto proxy (so you could e.g. add interceptors to them).
In the server JVM, to publish POJOs via a remoting protocol, you define an exporter spring bean (this requires no code, only a short Spring configuration). This exporter bean references another spring bean that represents the protocol (this protocol bean fully configures what protocol to use and settings for the protocol). By changing settings on the protocol spring bean, you can fully control how all the linked exporter beans are exported.
In the client JVM, to get access to a remotely published POJO (either via Spring or other remoting), you just define an importer spring bean. This importer spring bean can be accessed like any other spring bean. We tend to share the protocol configuration between the client and the server JVM.

For simpler testing, one could even deploy the spring beans of the client and those of the server in one JVM (omitting the importer and exporter).

Why did we change the semantics of the Spring remoting?

• It's easier to switch remoting protocols. The protocol definition and the fact that we remote is completely orthogonal.
  
• You can also remote 2.0/2.1 EJB beans without writing custom delegator classes (as Spring proposes it)
• You can optionally enable implicit context passing (this is a topic for another blog entry, you may want to check out my article decribing this if you are impatient).
• It allows for easy set up of load-balancing
  

The following picture illustrates our load-balancing feature:



The load balancing protocol is a so-called composite protocol. It applies the Composite Design Pattern and thus allows the user to compose several of the atomic protocols (i.e., a non-composite protocol such as RMI) into this composite protocol. To the outside, it behaves like an atomic protocol. Note that the load balancing protocol is only used on the client side of a (remote) invocation and requires no modifications to existing remoting protocols.

The load balancing protocol attempts to establish an initial connection to a particular server. If this connection attempt fails, it will ask for the next server from the policy bean and attempt to connect to this server. It repeats this behavior until it succeeds to connect, or no more servers are available. In the latter case, it throws a ch.elca.el4j.services.remoting.protocol.loadbalancing.NoProtocolAvailableException.

Different policies can be plugged to govern the sequence in which protocol instances are invoked.