Internet Connection

This section deals with the ins and outs of web-based EJB clients. We will look at two conceptually quite different approaches. Since we are dealing with a special form of the client view, which we have already considered in some detail, we shall not go further into the implementation details. It seems to us important, nevertheless, to discuss the need for a web client and its implications.

Originally, simple services were offered over the Internet (e-mail, FTP, HTML publishing), but today, complex transactions are carried out over this medium (for example, Internet banking). Security in a variety of forms (access security, consistency of data, etc.) plays an important role. The developer of web-based applications is confronted with a multiplicity of technical challenges.

As a basis for communication, HTTP (hypertext transfer protocol), which is primitive in comparison to other protocols, remains available for a browser's communication with an HTTP server. It is stateless and supports only a very limited number of operations. A (standard) HTTP server has no persistence interface, no application framework, and no transaction monitor, which is as it should be, since HTTP was developed not as a communications basis for transaction-oriented web-based application systems, but for the transfer of hypertext files (that is, files that contain HTML pages).

The technology for the implementation of applications runs from server-side C programs, Perl, Python, and Unix shell scripts (which are addressed over the CGI interface of an HTTP server) to proprietary HTTP server extensions (such as the NSAPI for the Netscape HTTP server and the ISAPI for Microsoft's Internet information server). And then there are servlets (CGI for Java) and technologies for server-side dynamic generation of HTML pages (active server pages from Microsoft and Java server pages from Sun). Many providers of databases offer HTTP interfaces for their products, where the database server can act directly as a web server and also web pages can be generated dynamically via proprietary APIs from the databases for the representation and modification of data. On the client side, pure HTML, dynamic HTML (Javascript), Java applets, and proprietary browser interfaces and libraries can be used.

Each of the above-named technologies has its purpose in particular application areas. Nevertheless, there is a serious problem in all this specialization. In the pioneer days of the Internet (which are not quite at an end even now), many web applications were originally planned as local solutions to small problems, but they soon developed into applications implemented throughout an entire enterprise. This development resulted in greatly changed demands on the application, and the technology chosen for the implementation did not always have the required flexibility. Today, many web applications possess a crucial importance for the success of an enterprise. The architecture of these applications should reflect their importance.

An application server is available as a platform that offers various services (persistence, user management, transactions, etc.), various communications protocols (HTTP, HTTPS, RMI, IIOP, etc.), and an EJB container. It offers all the capabilities that are expected today from a reliable application platform, which are nonetheless lacking in a (standard) HTTP server. Moreover, the technology portfolio is limited, which has a positive effect on maintainabilty and reusability. It is precisely the security mechanisms of the programming language Java (see also Chapter 2) that are at an advantage in the Internet arena. In Chapters 2 and 3 we mentioned that Sun Mircrosystems takes this into account through the Java 2 platform Enterprise Edition.

Frequently, native clients of an application system are extended (or even replaced) by web clients to make applications usable over the Internet (for example, so that one can use such enterprise applications as business expense calculation and recording of working hours). Likewise, applications are developed particularly with the Internet in mind (for example, e-commerce applications). One might also imagine applications based on web technologies operating in an intranet, such as for personnel without a fixed work place. Furthermore, this could reduce costs for installation and updating of client software. Often, however, limited, fast, and easy-to-implement alternative versions of applications are offered (for example, a simple working hours logging program for personnel who work on an hourly basis, or infoterminals for quick access to attendance lists, quality statistics in manufacturing, flextime balance, etc.).

We would like to discuss two approaches for the implementation of a web client for applications based on Enterprise JavaBeans that are quite different conceptually, but are both conceived for the Java 2 platform, Enterprise Edition. One of these involves an applet-based web client, the other, a purely HTML client that is supported by the servlet technology.

Java Applets

A client applet sent to the client embedded in an HTML page by the server using the HTTP protocol offers the user an interface of the type to which he or she is already accustomed from proprietary clients (see Figure 9-14). The look and feel and user prompting of an applet-based client reflect those of traditional applications. As soon as it is loaded, the applet generally communicates directly with the application server. The implementation of the applet is not much different from that of a normal client. With an applet, one must pay attention to the size of the generated code in order to minimize the download time. An applet and a normal client are able to share large parts of the implementation. In the extreme case, the applet and the native client can be identical (an applet can be relatively easily transformed into an application). What can be problematic in this scenario is the use of the Java 2 platform. Current browsers support only JDK 1.1, though they can be adapted to Java 2 with plug-ins. Because of this limitation, applets are most successfully used in controlled deployment environments such as corporate intranets.

Figure 9-14: Internet connection with applets.

HTML and Servlets

As an alternative to an applet, one can use a pure HTML client (see Figure 9-15). On the server side a servlet (see [18]) is used to execute Enterprise Bean calls resulting from client requests and to generate HTML pages dynamically for the representation of results and the receipt of user input. This approach has the advantage over the applet solution of avoiding long download times for the applet code. Furthermore, the browser does not have to support Java. Thus the problem of users who have deactivated Java support on their browsers due to security concerns is also eliminated.

Figure 9-15: Internet connection with servlets.

HTML clients do not have the typical look and feel or the user prompting of a traditional application (determined by the server roundtrip, typical of HTML, in order to update the view after a user action). With the use of pictures the appearance can be greatly customized. A further significant difference between the two approaches is in the management of the state of an application. The applet, like the native client, can save the state until the next call of a server-side operation (for example, to collect user input data, manage undo lists, store references to Enterprise Beans) and in general communicate directly with the application server. A pure HTML client cannot store a state. It must rely on the support of the servlet. An HTML page in a browser contains only information about representation and no logic (ignoring here the use of client-side Java scripts). The servlet makes the logic available to arbitrarily many browsers. The servlet then has the following tasks:

• Manage the states of all clients that use it in parallel;

• Receive requests from the browser;

• Relate the requests to a session (that is, to a particular application state);

• Execute the requests of Enterprise Bean calls;

• Generate for the browser as reply a new HTML page (which represents the results of the bean call).

The issues discussed in this section apply equally well to the use of Java server pages (JSP) (see [18]). Java server pages are based on the servlet architecture and thus obey the same behavioral principles.

Summary

The two approaches are fundamentally different and to a certain extent represent opposite poles. Through the use of other technologies and combinations of them (for example, client or server-side JavaScript, proprietary browser interfaces) one can conceive of an infinite variety of approaches. What is important here is that an existing system based on Enterprise JavaBeans can be extended relatively easily through web-based clients. The implementation effort for the web client is then relatively little if during implementation of the application system one keeps in mind a consistent realization of the three-tier architecture (see Chapter 2). In this case, the entire functionality and application logic are available in the form of Enterprise Beans. Only the view scenarios of thin clients must be developed anew. For applications that are developed exclusively for Internet use (e-commerce applications) Enterprise JavaBeans is also a platform of interest. With Enterprise JavaBeans it is possible to achieve high quality, security, and maintainability in Internet applications relatively easily. Furthermore, developers do not have to be experts in Internet technologies (these are needed only for development of client scenarios).

Finally, one should not forget the fact that security considerations become significantly more important when an application is opened to an intranet or internet. Encrypted data transfer between web client and application server, a firewall concept, and various other security mechanisms should be considered as an extension of the security requirements described in the Enterprise JavaBeans specification.