Having multiple servers talk to one another

So far, we have only introduced a sender and a receiver. When it comes to remoting, the sender is the Client side and the receiver is the Server side. But what if you want to be able to send requests back and forth? In other words, what if both sides are both senders and receivers? They both want to send requests to themselves (local listeners) as well as to the other side (remote listeners). Well, the The key is the fact that each DefaultRequestResponseBus can talk to as many RequestDispatchers as you like and requests will be sent to all of them, so they will be received by all Listeners. Below is an image that will clarify things (it uses RMI as an example, but it works just as well with the other available remoting protocols).

The first step is to set up a ListenerObjectCreator, a ListenerObjectRetriever and a ListenerObjectExecutor on both sides. This works exactly the same as usual and each side is responsible for its own listeners. Then, on each side, you share the ListenerObjectRetriever and the ListenerObjectExecutor to both a local and a remote RequestProcessor. The local RequestProcessor will handle requests from its own server, whereas the remote RequestProcessor will handle requests from the other server.

Finally, you set up a LocalRequestDispatcher to connect to your own LocalRequestProcessor and a remote RequestDispatcher (specific implementation depends on desired protocol) to connect to the remote RequestProcessor on the other server.

This approach does not just work with 2 servers, you can connect as many servers as you like. Each server to server connection requires a separate RequestDispatcher/RequestProcessor pair. Not all servers may need to connect to every other server, so you don't necessarily have to set up connections between each possible pair of servers. There is no limit to the amount of RequestDispatchers per DefaultRequestResponseBus. There is also no limit to how many RequestProcessors can use a ListenerObjectRetriever or a ListenerObjectExecutor.

Serializability

When you use RRiBbit Remoting, it will work completely similarly to when you use it locally. The only requirement here is that the parameters that you give to the RequestResponseBus's send-methods are Serializable and that the return values are Serializable too. You can get away with non-Serializable requests and responses when you use RRiBbit locally (i.e. using the LocalRequestDispatcher and the LocalRequestProcessor), but when choosing one of the Remote implementations, Serializability is a requirement.

When you use JMS as a protocol, the parameters must be Serializable, but you will always get an empty response back, because JMS is one-way only by nature.