From google

GWT RPC makes it easy for the client and server to pass Java objects back and forth over HTTP.

When used properly, RPCs give you the opportunity to move all of your UI logic to the client, resulting in greatly improved performance, reduced bandwidth, reduced web server load, and a pleasantly fluid user experience.

The server-side code that gets invoked from the client is often referred to as a service, so the act of making a remote procedure call is sometimes referred to as invoking a service.

Every service ultimately needs to perform some processing to order to respond to client requests. Such server-side processing occurs in the service implementation, which is based on the well-known servlet architecture. A service implementation must extend RemoteServiceServlet and must implement the associated service interface. Note that the service implementation does not implement the asynchronous version of the service interface.

Caveats

• Method parameters and return types must be serializable
• Collection classes such as java.util.Set and java.util.List are tricky because they operate in terms of Object instances. To make collections serializable, you should specify the particular type of objects they are expected to contain. This requires you to use the special Javadoc annotation @gwt.typeArgs.

Architecturally, you can make use of RPC two alternative ways. The difference is a matter of taste and of the architectural needs of your application. The first and most straightforward way to think of service definitions is to treat them as your application’s entire back end. From this perspective, client-side code is your “front end” and all service code that runs on the server is “back end.” If you take this approach, your service implementations would tend to be more general-purpose APIs that are not tightly coupled to one specific application. Your service definitions would likely directly access databases through JDBC or Hibernate or even files in the server’s file system. For many applications, this view is appropriate, and it can be very efficient because it reduces the number of tiers.

In more complex, multi-tiered architectures, your GWT service definitions could simply be lightweight gateways that call through to back-end server environments such as J2EE servers. From this perspective, your services can be viewed of as the “server half” of your application’s user interface. Instead of being general-purpose, services are created for the specific needs of your user interface. Your services become the “front end” to the “back end” classes that are written by stitching together calls to a more general-purpose back-end layer of services, implemented, for example, as a cluster of J2EE servers. This kind of architecture is appropriate if you require your back-end services to run on a physically separate computer from your HTTP server.

Fast tutorials: gwt4nb