This chapter is from the book
This chapter is from the book
This chapter is from the book
J2EE Components
The J2EE environment is based on the concept of a software component—an abstract object that operates within some type of environment. The specific component that J2EE technology is built on is the distributed software component, a component that can be invoked remotely and can accept and receive parameters and return values.
This ability to build applications with components provides a great deal of flexibility in constructing and deploying an application and is one of the primary reasons for the interest in J2EE technology. A distributed component can be deployed on a single server and made available to multiple applications that have access to the server. The component can thus be deployed in a centralized fashion, allowing information technology (IT) management control over the operating environment of the critical business services provided by the application components.
The J2EE specification provides for different types of components that can be used to create an application. While for many the focus of a J2EE application is on the middle tiers (the presentation tier, the business tier, and the integration tier), there are J2EE components that can be used on the client tier. Most of these components are Java objects that operate within a logical container, an environment that provides a number of services for the component. The following sections identify these components.
Client Tier Components
The client tier represents the portion of the application that interacts with the user. For Web applications, this would be whatever component is running within the Web browser, potentially a simple HTML page, an HTML page with JavaScript, an HTML page running a Java applet, or a Java WebStart component.
The HTML Page
The HTML page is the most common form of interacting with the end user in a Web application. From its fairly simple, modest birth at CERN in the late 1980s, HTML and the accompanying HTTP have provided the framework for a burgeoning Web economy.
HTML is adequate for simple presentation of material but is limited in the GUI controls it can use. The basic GUI controls are available—the listbox, the radio button, the checkbox—but more sophisticated controls such as sliders and number wheels are beyond its abilities. HTML also does not allow immediate reaction to the user's actions; should a user enter a Q in a field that is designated Sex' and expects an entry of M or F, the most common approach is to allow this information to be posted back to the server, where it will be examined, and if there is an error, an error page is returned to the browser. Editing complex input pages with HTML can be a tedious experience for the user.
There are some alternatives to basic HTML. The Dynamic HTML (DHTML) standard expands upon HTML, and JavaScript provides a scripting language that most browsers support (though with a subtle variation of maddening differences). But the support for these languages varies among browser types and versions so that using them entails some risk.
The applet Component
The applet was the first Java component. The applet runs within a container provided by the browser. The container is an abstraction that provides a number of services for the applet, such as lifecycle management (starting and stopping the applet) and security (limiting the applet from accessing local resources by default).
At one time applets were considered to be the choice tool for expanding the capabilities of the Web browsers, but limitations of the GUI and the bandwidth required to download large applets led to limited usage of these components. Today many of the limitations of the GUI have been addressed (with Swing JApplet), and bandwidth is continuing to improve. Though not as commonly used as JSPs or servlets, the Java applet still represents a viable technology for applications that require a more robust interface than that of an HTML page with JavaScript.
A Java applet is effectively a class that is downloaded each time it is used. If this class uses other classes, as is common, those classes are also downloaded. As the size and complexity of the applet grows, the size of the download may also grow. A moderately complex applet could easily be 200 to 400 kilobytes in size, requiring a 2- or 3-minute download on a connection using a 56-K modem. For users used to 20-second start times for PC-based applications, running an applet of this size could appear painfully slow.
The Java applet was also designed to be secure. Since it can be downloaded over an open network, it is relatively easy for a malicious user to introduce applets that could circulate among client machines and damage them. By default, applets had restrictive security; they could not access local machine resources such as the hard disk or the printer, and they could access network resources only on the machine from which they were downloaded. While these restrictions on applets did provide solid security, they also severely limited the general usefulness of the applet (which could not send output to the printer or save a file to disk).
The initial version of the Java applet used the Java Abstract Windowing Toolkit (AWT) for the creation of the GUI, a set of widgets that was limited and paled in comparison to what was in the Microsoft Foundation Classes. The Java applet has now become the Java Swing applet, or JApplet, which provides access to a more mature set of GUI widgets. These applets, however, require the Java 2 Web server plug-in to be installed in the browser.
The Java WebStart Component
The Java WebStart component is similar to that of the applet. But unlike Java applets, the developer of the WebStart application can choose to have the application downloaded once and then stored on disk. Java WebStart can make deploying an application a much simpler process.
The Java WebStart application requires a plug-in be installed in the Web browser and can optionally install updates to all classes in the application or only to certain classes. This allows robust, client/server applications to be created and installed on a central site and then updated to client machines on an intelligent basis, updating only those classes that need to be changed. A Java WebStart application can also be run offline, without access to the server from which it was downloaded.
Java WebStart applications run in a dedicated Java runtime environment and use a default security model that is restrictive. Security involves the use of signed JAR (Java ARchive) files using digital signatures that can help insure that the code being executed by the client is the code received from the host server and not a trojan horse intruder with malicious intent. WebStart applications may or may not use this restrictive security model, and WebStart application applets may also be digitally signed, in which case they are considered "trusted" and are able to run in a less restrictive environment.
The GUI Client
The client application could also be a standalone application that uses a graphical user interface (GUI) to interact directly with the end user. Though this type of application is used less and less these days because of deployment and support issues, the GUI interface is still superior in terms of functionality of controls and performance to what can be delivered using a Web browser working with HTML and JavaScript.
Sun has aggressively improved the Swing API over the past few years and today a number of notable GUI applications including Integrated Development Environments (IDE) and OOAD modeling tools have been developed as cross-platform applications using Swing. For applications that require a more robust user interface, developing the application in Java Swing may be the preferred alternative. We demonstrate the use of the Swing GUI in Chapter 30 and 31.