Web applications are significantly different in structure from other types of interactive applications. Because of the stateless nature of HTTP (the underlying communication protocol between web browsers and web servers), the server is constantly "picking up the pieces" of a conversation with the client.

This is complicated further in a high-volumes systems that utilizes load balancing and fail over. In these cases, the server is expected to pick up a conversation started by some other server.

The Java Servlet API provides a base for managing the client - server interactions, by providing the HttpSession object, which is used to store server-side state information for a particular client.

Tapestry picks up from there, allowing the application engine, pages and components to believe (with just a little bit of work) that they are in continuous contact with the client web browser.

At the center of this is the request cycle. This request cycle is so fundamental under Tapestry that a particular object represents it, and it is used throughout the process of responding to a client request and creating an HTML response.

Each application service makes use of the request cycle in its own way. We'll describe the three common application services (page, action and direct), in detail.

In most cases, it is necessary to think in terms of two consecutive request cycles. In the first request cycle, a particular page is rendered and, along the way, any number of URLs are generated and included in the HTML. The second request cycle is triggered by one of those service URLs.