3.2 General Design Issues and Guidelines

While the J2EE platform encourages thin-client architectures, J2EE clients are not dumb. A J2EE client may handle many responsibilities, including:

• Presenting the user interface--Although a client presents the views to a user, the logic for the views may be programmed on the client or downloaded from a server.
• Validating user inputs--Although the EIS and EJB tier must enforce constraints on model data (since they contain the data), a client may also enforce data constraints by validating user inputs.
• Communicating with the server--When a user requests functionality that resides on a server, the user's client must present that request to the server using a protocol they both understand.
• Managing conversational state--Applications need to track information as a user goes through a workflow or process (effectively conversing with the application). The client may track none, some, or all of this information, known as conversational state.

How you handle these responsibilities on your client can significantly impact your development efforts, your application's performance, and your users' experience. Generally, the more responsibilities you place on the client, the more responsive it will be.

The next two sections consider browser clients and Java clients separately. You do not have to pick one or the other; a J2EE application can accommodate both browser and Java clients. The Java Pet Store sample application, for example, has a Web browser interface for shoppers and a Java application for administrators. Section 4.4.2.2 on page 107 explains how to design the Web tier to support multiple types of clients.