Chapter 8: Lightweight Remoting

Overview

There are two main scenarios where remoting constitutes an important element of the overall architecture:

Client-server remoting: Remote applications that access a backend server, often providing a "rich" user interface, as opposed to a "thin" HTML-based user interface. If such a client application is implemented in Java, it will typically have a Swing user interface and be distributed with Java Web Start. Alternatively, such a client might be implemented in Macromedia Flash or in .NET, talking to backend services implemented in Java. Remote communication in a client-server scenario will usually be HTTP-based because of the ease of setup and to avoid firewall issues.

Intra-server remoting: Communication between various processes within the same server system: for example, for integrating existing backend systems or for distributing workload across multiple machines. The demands and tradeoffs in such a scenario differ significantly from client-server remoting: For example, there are often no firewalls between servers, allowing for non–HTTP-based protocols. Furthermore, the overhead of remote invocations is lower (although always significant).

If none of these scenarios applies, it is likely that your application will not benefit from remoting. However, your requirements might change over time, for example making it necessary to add remoting to an existing web application.

Spring mainly focuses on local middle tiers, managing loosely coupled components within the same process. However, it nevertheless provides powerful remoting support, allowing you to export and consume remote services with ease. Spring offers a consistent, POJO-based programming model, whichever of the many supported remoting protocols you choose.