Designing and Implementing J2EE Clients
This chapter is from the book
This chapter is from the book
This chapter is from the book
From a developer's point of view, a J2EE application can support many types of clients. J2EE clients can run on laptops, desktops, palmtops, and cell phones. They can connect from within an enterprise's intranet or across the World Wide Web, through a wired network or a wireless network or a combination of both. They can range from something thin, browser-based and largely server-dependent to something rich, programmable, and largely self-sufficient.
From a user's point of view, the client is the application. It must be useful, usable, and responsive. Because the user places high expectations on the client, you must choose your client strategy carefully, making sure to consider both technical forces (such as the network) and non-technical forces (such as the nature of the application). This chapter presents guidelines for designing and implementing J2EE clients amidst these competing forces.
This chapter cites examples from the Java Pet Store sample application, an online outlet for selling pets, and the Java Smart Ticket sample application, an e-commerce movie ticket service. The code for these sample applications is available on the Java BluePrints Web site. See "References and Resources" on page 73 for more information.
3.1 Client Considerations
Every application has requirements and expectations that its clients must meet, constrained by the environment in which the client needs to operate.
Your users and their usage patterns largely determine what type of client or interface you need to provide. For example, desktop Web browser clients are popular for e-mail and e-shopping because they provide a familiar interface. For another example, wireless handheld clients are useful for sales force automation because they provide a convenient way to access enterprise resources from the field in real time. Once you have decided what type of interface you need, you should design your client configuration with network, security, and platform considerations in mind.
3.1.1 Network Considerations
J2EE clients may connect to the enterprise over a wide array of networks. The quality of service on these networks can vary tremendously, from excellent on a company intranet, to modest over a dialup Internet connection, to poor on a wireless network. The connectivity can also vary; intranet clients are always connected, while mobile clients experience intermittent connectivity (and are usually online for short periods of time anyway).
Regardless of the quality of service available, you should always keep in mind that the client depends on the network, and the network is imperfect. Although the client appears to be a stand-alone entity, it cannot be programmed as such because it is part of a distributed application. Three aspects of the network deserve particular mention:
- Latency is non-zero.
- Bandwidth is finite.
- The network is not always reliable.
A well-designed enterprise application must address these issues, starting with the client. The ideal client connects to the server only when it has to, transmits only as much data as it needs to, and works reasonably well when it cannot reach the server. Later, this chapter elaborates on strategies for achieving those goals.
3.1.2 Security Considerations
Different networks have different security requirements, which constrain how clients connect to an enterprise. For example, when clients connect over the Internet, they usually communicate with servers through a firewall. The presence of a firewall that is not under your control limits the choices of protocols the client can use. Most firewalls are configured to allow Hypertext Transfer Protocol (HTTP) to pass across, but not Internet Inter-Orb Protocol (IIOP). This aspect of firewalls makes Web-based services, which use HTTP, particularly attractive compared to RMI- or CORBA-based services, which use IIOP.
Security requirements also affect user authentication. When the client and server are in the same security domain, as might be the case on a company intranet, authenticating a user may be as simple as having the user log in only once to obtain access to the entire enterprise, a scheme known as single sign on. When the client and server are in different security domains, as would be the case over the Internet, a more elaborate scheme is required for single sign on, such as that proposed by the Liberty Alliance, an industry collaboration spearheaded by Sun Microsystems.
The authentication process itself needs to be confidential and, usually, so does the client-server communication after a user has been authenticated. Both the J2EE platform and the client types discussed in this chapter have well-defined mechanisms for ensuring confidentiality. These mechanisms are discussed in Chapter 9.
3.1.3 Platform Considerations
Every client platform's capabilities influence an application's design. For example, a browser client cannot generate graphs depicting financial projections; it would need a server to render the graphs as images, which it could download from the server. A programmable client, on the other hand, could download financial data from a server and render graphs in its own interface.
Another aspect of the platform to consider is form factor. Desktop computers offer a large screen, a keyboard, and a pointing device such as a mouse or trackball. With such clients, users are willing to view and manipulate large amounts of data. In contrast, cell phones have tiny screens and rely on button-based interactions (usually thumb-operated!). With such clients, users can't (and don't want to) view or manipulate large amounts of data.
Applications serving multiple client platforms pose additional challenges. Developing a client for each platform requires not only more resources for implementation, testing, and maintenance but also specialized knowledge of each platform. It may be easier to develop one client for all platforms (using a browser- or a Java technology-based solution, for example), but designing a truly portable client requires developers to consider the lowest common denominator. Consequently, such a client implementation cannot take advantage of the various capabilities unique to each platform.