| CONTENTS | PREV | NEXT | INDEX | J2EE BluePrints |
Web clients usually run inside a browser and use the services of the browser to render content provided by the Web tier. In these clients, the user interface is generated on the server side by the Web tier and communicated via HTML. Applets and JavaScript can be used to enhance the browsing interface. On the client side, a browser or equivalent program renders this user interface and carries out interactions with the user. Data interchange is facilitated through XML.
Web clients use HTTP or HTTPS as the transport protocol. These protocols have several advantages:
- They are widely deployed. Almost every computer now has a browser that can communicate over HTTP. Thus the deployment of the application is simplified.
- They are robust and simple. The protocol is simple and well understood. Good implementations of HTTP servers and clients are widely available.
- They go through firewalls. Due to the extensive use of HTTP, firewalls are typically set up to pass HTTP through. This makes it the protocol of choice on the Internet where the server and the client are separated by a firewall.
At the same time, the simplicity of the protocols presents a couple of minor disadvantages that can largely be overcome:
- They are sessionless. HTTP is a request-response protocol, with no built-in concept of a session. Therefore, individual requests are treated independently. Moreover, there are simple ways to provide session semantics, so in practice this is not an issue.
- They are non-transactional. HTTP is a networking protocol, not designed for general purpose distributed computing. As a result, it has no concept of transaction or security contexts. However, this is not a problem in practice because transactions and security are commonly handled on the server.
The content served over the HTTP protocol is typically the result of an action performed on the server in response to a client request. This result can be formatted using HTML or XML.
3.3.2.1 HTML
HTML content is widely supported by browsers and operating systems. Along with HTML, a server may also provide JavaScript code in the response to enrich the user interface.
This content type is best suited when presentation of the response is generated on the server side and communicated to the browser for display. It should be used as a markup language that instructs the browser how to present the results.
HTML is a good means of encoding static documents. However, presenting complex documents consistently is difficult using HTML. Style sheets and dynamic HTML (DHTML) allow more complex documents to be displayed. However, the various commonly used browsers do not handle style sheets and DHTML consistently, so it is necessary to design different versions of each page or to include browser-specific markup in the pages.
HTML's strength is its wide support in many applications on many platforms. HTML documents that do not rely on browser-specific tags should be similar in appearance on the most commonly used browsers. The combination of HTTP and HTML ensures that a document can be widely viewed on many platforms.
3.3.2.2 XML
The XML (eXtensible Markup Language) standard provides a mechanism for structuring content and data. XML allows applications to transfer both page content and information on how the content is structured.
The structure of the data contained within an XML document is described in a Data Type Definition (DTD). Applications that support XML can communicate and exchange data without any prior knowledge of each other, as long as they share or are capable of interpreting the DTD. For example, the interoperability portion of the sample application sends a list of orders to a Microsoft Excel spreadsheet using XML over HTTP. J2EE servers may also transfer information to other J2EE servers or applications using XML over HTTP. This is not possible with HTML, because of the limited number of tags it provides to identify data.
While DTDs are useful to validate XML documents, they suffer from a number of shortcomings, many of which stem from the fact that a DTD specification is not hierarchical. This affects the ability to name elements relative to one another and the ability to scope comments to sections of a document. Finally, DTDs do not allow you to formally specify field-validation criteria, such as a limitation on the size and content of a zip code field. To remedy these shortcomings, a number of proposals have been made for future versions of XML to provide database-like hierarchical schemas that specify data validation criteria.
XML also allows dynamic data presentation. That is, the same data can be presented differently depending on the style sheet used. Fortunately, the XSL (eXtensible Style Sheet) standard, which provides a standard approach to XML presentation, will be completed and accepted in the near future. Most of the commonly used Web browsers support now, or will soon support, XML. However, since XML is evolving, support by browsers is not as uniform as HTML. This means that an applet, plug-in, or other application component, that handles XML responses might be necessary. In the case of Java applets, this can happen automatically at request time.
Use XML for your responses when:
- The client needs to get data from the server and process it before displaying it to the user.
- The client needs to show multiple views of the same data. When the client downloads XML data from the server, it can generate views on the client side depending on local settings. This saves a round-trip to the server and reduces load on the server by reducing the number of client requests.
For example, consider a stock quote system, where the client wants to see a chart of the last hour's trades, as well as a table of the same data. The client could download the quote data from the server just once, then render that data as either a chart or a table (or both), at the user's requests without resending a request to the server.- The client can pass XML in requests. The HTTP protocol allows for
POSTdata, in any content type, in a request. An XML-aware application component running on the client could usePOSTrequests with XML data to exchange objects with the server.
Most Web clients run inside of or in conjunction with a Web browser. The browser can handle details of HTTP communication and HTML rendering, while an application component can focus on interactions that cannot be expressed in HTML. In fact, a Web browser without any other application component is the simplest, most widespread J2EE Web client. Additional application components such as Java applets, browser plug-ins, or ActiveX components can make the client user interface richer and more featureful. Finally, Web clients can be implemented as stand-alone programs.
3.3.3.1 Web Browsers
The Web browser is the simplest J2EE client. It serves to render HTML content delivered by the Web tier. With more and more browsers supporting JavaScript and DHTML, powerful user interfaces can be created using just a Web browser.
A stand-alone Web browser is the Web client of choice on the Internet. It is widely available, users are familiar with using it, and there are no issues with deployment. Additionally, since Web browsers can be used wherever an Internet connection is available, support for roaming users is possible.
3.3.3.2 Java Applets
Applets are GUI components that typically execute in a Web browser, although they can execute in a variety of other applications or devices that support the applet programming model. Applets can be used to provide a powerful user interface for J2EE applications.
Since applets are Java-based components, they have access to all the features and advantages of the Java platform technology. In a heterogeneous Web environment, it is especially important that client-side components be portable. For the protection of the client machine, it is important to be able to place security restriction on these components and detect security violations. Java applets serve both these needs.
Browser-based applet clients communicate over HTTP. Applets can also communicate over a network using serialized objects or some other type of proprietary protocol.
One advantage of applets is that they provide application with rich GUIs that can be managed at a single location. The main disadvantage with browser-based applets is that they can be difficult to deploy, particularly when the client browsers run a diverse set of embedded Java virtual machines. For this reason, applets may be more successfully deployed where the browser environment is controlled (such as an intranet).
Applets are delivered through applet tags embedded in HTML. The Web browser downloads the code for the applet at request time and executes it in a Java virtual machine on the client machine.
When JSP pages are used to generate HTML, an Application Component Provider can use the jsp:plugin tag to ensure the availability of a specific JVM on the client.
The Java applet programming model protects the user from security violations. All downloaded code is considered untrusted and strict limitations are placed on it. For users to be more comfortable with executing application code downloaded from another computer, vendors should use signed applets. Signed applets provide a secure way to identify the applet's distributor. A signed applet can also request additional permissions from the client machine if it needs access to additional functionality.
When applets communicate with servlets or JSP pages over HTTP they need to manage some details of the HTTP protocol to participate in a session. Sessions over HTTP are managed using HTTP cookies. The server sets the cookie at the beginning of the session; the client then sends the cookie back to the server each time it makes another request. When the applet makes a request, it needs to explicitly make sure that it sends the cookie as part of the request.
3.3.3.3 Browser Plug-ins
In addition to applets, Web browsers often support other embedded components, such as plug-ins in the Netscape browser and ActiveX components in Microsoft's Internet Explorer. These can be used just like applets to enhance the user experience. There are some things to keep in mind when planning to use these component types in a J2EE client:
- Plug-ins are usually written for a particular architecture and operating system. On the Internet, multiple versions of these plug-ins need to be implemented for each kind of client. If the clients run on a homogeneous intranet environment, this is less of an issue.
- Since plug-ins run natively on the browser's platform, security is harder to enforce, which could expose your clients to an unacceptable risk.
3.3.3.4 Stand-Alone Web Clients
The discussion so far has considered Web clients with the application component embedded in a browser. Sometimes, though, it might be desirable to invert this model by embedding the browser in an application client. This type of client is referred to as a stand-alone Web client.
In this configuration, the application client creates a top level window and user interface, then uses a browser-like component to render HTML responses from the server.
This is desirable where the client needs to look like a native application, and provide a more interactive and customized GUI to the user. These clients often use XML over HTTP to communicate with JSP pages or servlets and render the data interchanged in their customized GUI.
A stand-alone Web client suffers from the same drawbacks as other stand-alone applications:
With the availability of tools, some of this work can be automated. However, deploying a stand-alone client remains a complex process.
The user interface of a stand-alone Web client is typically written using the Swing API from the J2SE platform. The Swing API provides a comprehensive set of GUI components (tables, trees, and so on) that can be used to provide a more interactive experience than the typical HTML page. Additionally, Swing supports HTML text components that can be used to display responses from a server. Swing APIs can be used for both applets and stand-alone Java applications.
Stand-alone Web clients can also be written in C++ or in automation languages such as Visual Basic.1 These clients can use their own HTML renderers or third-party browser components to present responses from the server.
Non-Java clients may be desirable where specialized services are made available by the development environment. For example, a chart plotting application might find it useful to take advantage of this fact. If Microsoft Excel is available on the client desktops throughout an enterprise, it might be desirable to use it for rendering charts. A Visual Basic client embedded in Microsoft Excel could communicate with a JSP page and download the chart data using XML. The client could then use specialized services in Excel to render this chart.