Enterprise application architectures have undergone an extensive evolution. The first generation of enterprise applications consisted of centralized mainframe applications. In the late 1980s and early 1990s, most new enterprise applications followed a two-tier, or client/server, architecture. Later, the enterprise architecture evolved to a three-tier architecture and then to a Web-based architecture. The current evolutionary state is now represented by the J2EE application architecture. The J2EE architecture provides comprehensive support for two- and three-tier applications, as well as Web-based and Web services applications. This section discusses the evolution of enterprise application architectures, starting with the two-tier architecture. Because it has little relevance to the material in this book, we do not describe how the architectures evolved from the centralized mainframe architecture to the two-tier architecture. 1.1.1 Two-Tier Application ArchitectureWith a two-tier application, a business system is structured as a collection of operating system level application processes that execute on the client machine: typically, a PC in a corporation. Each such application implements one or several business processes, as well as the GUI (graphical user interface) presentation logic for the interactions between the business processes and the user. (A business process is an encapsulation of a user's interactions with some enterprise information.) The application running on the client PC communicates over the network with a database server storing the corporate databases. The database server stores the corporate data, and the client application typically accesses the data via Structured Query Language (SQL) statements (Figure 1.1). Figure 1.1. Two-Tier Application ArchitectureBefore the existence of the Web, the two-tier architecture worked well for most applications. Its main advantage is that it is easy to develop two-tier applications, particularly because the presentation logic and the business logic reside in the same process, and the developer does not have to deal with the complexity of a distributed application. However, its disadvantages outweigh its advantages. The main disadvantage of the two-tier architecture is that programmers cannot cleanly separate business logic from presentation logic. This results in a number of problems: easily compromised database integrity, difficulties in administration and maintenance, exposure to security violations, limited scalability, restricted client architecture requirements, and limitation to one presentation type.
The onset and growth of the Web changed all the rules. Although the corporation could live with the limitations of the two-tier architecture before the Web, these limitations essentially make the two-tier architecture completely incompatible with the Web, chiefly because Web clients inherently lack intelligence, and because there are so many such clients. In addition, the limitations of the two-tier architecture make it impossible for an enterprise to integrate its business applications with applications from partners, customers, and suppliers. As a result, application developers and their customers have been seeking alternative application architectures. 1.1.2 Traditional Three-Tier Application ArchitectureThe traditional three-tier architecture overcomes some of the limitations of the two-tier architecture. The three-tier architecture splits the presentation logic from the business logic, placing the business logic on a server; only the presentation logic is deployed on the client PCs (Figure 1.2). Figure 1.2. Three-Tier Application ArchitectureThe three-tier architecture brings about a number of improvements. The middle-tier server improves scalability by reusing expensive resources, such as database connections, across multiple clients. Improved scalability results in improved performance. This architecture also improves security and application management. The three-tier architecture has been used in most enterprise resource planning (ERP) systems and in the systems specialized for high-volume transaction processing (CICS, Tuxedo, and others). Although it eliminates some of the flaws of the two-tier architecture, the three-tier architecture too has certain disadvantages: complexity, lack of application portability, vendor incompatibility, limited adoption, and Web incompatibility.
1.1.3 Early Web-Based Application ArchitectureThe introduction and growth of the Web changed everything. Because neither the two-tier nor the traditional three-tier architecture supports the development of Web applications, early Web application developers had to devise another approach. They used various plug-in extensions to Web servers. These extensions invoke on the server programs that dynamically construct HTML (HyperText Markup Language) documents from the information stored in corporate databases. Likewise, the Web server extensions enter information submitted in HTML forms into the corporate database. An example of such an extension is cgi-bin scripts. (CGI, or Common Gateway Interface, is an interface for developing HTML pages and Web applications. CGI applications are commonly referred to as cgi-bin scripts.) Although cgi-bin scripts and similar mechanisms allowed a corporate developer to build simple Web applications, the cgi-bin approach does not scale to more complex enterprise applications, for the following reasons:
1.1.4 J2EE Application ArchitectureJ2EE is a standard architecture specifically oriented to the development and deployment of enterprise Web-oriented applications using the Java programming language. ISVs and enterprises can use the J2EE architecture for not only the development and deployment of intranet applications, thus effectively replacing the two-tier and three-tier models, but also for the development of Internet applications, effectively replacing the cgi-bin-based approach. The J2EE architecture provides a flexible distribution and tiering model that allows enterprises to construct their applications in the most suitable manner. This model encompasses all the generations of application architectures and supports the latest Web services architectures, as shown in the following diagrams. Figure 1.3 illustrates the J2EE application programming model for Web-based applications. This programming model is typically used for e-commerce applications, in which the client is a customer's computer or device on the Internet, as well as for enterprise applications, in which the client is an employee's computer. The figure shows how the EJB and Web tiers may be either colocated in the same application server or distributed across servers. Figure 1.3. J2EE Application Programming Model for Web-Based ApplicationsFigure 1.4 shows how the J2EE architecture may be used for Web service interactions between two enterprises or between two applications within an enterprise. In this scenario, the EJB tier directly provides a Web service view that applications in another enterprise may use over the Internet. Because it supports standard Web service protocols, such as SOAP (Simple Object Access Protocol), and service description formats, such as WSDL (Web Services Description Language), the J2EE architecture can interoperate with non-J2EE applications in other enterprises or within the same enterprise. Figure 1.4. J2EE Application Programming Model for Web Service ApplicationsJ2EE also provides support for two-tier and three-tier applications. Figure 1.5 illustrates the support for two-tier applications. (Note that Application-Client Container refers to the Java 2, Standard Edition [J2SE] programming environment.) Figure 1.5. J2EE Application Programming Model for Two-Tier ApplicationsFigure 1.6 illustrates the support for three-tier applications. Presentation components are kept separate from business logic on two different tiers, whereas a third tier holds the persistent data. Figure 1.6. J2EE Application Programming Model for Three-Tier ApplicationsThe J2EE platform also provides supports for Java applets, small programs loaded from the Web container to the browser, where they reside in an applet container. The Web container hosts the Web application, and the EJB container hosts the business logic. Figure 1.7 illustrates this application programming model. Figure 1.7. J2EE Application Programming Model for Web-Based AppletsThe J2EE platform consists of four programming environments, called containers:
This book focuses mainly on the development and deployment of enterprise beans rather than on the development of the other application parts. We demonstrate fragments of the other parts (Web applications) only to illustrate the interactions between enterprise beans and their clients. Refer to Designing Enterprise Applications with the J2EE™ Platform, Second Edition by Inderjeet Singh, Beth Stearns, Mark Johnson, and the Enterprise Team (Addison-Wesley, 2002) for a more complete description of how to develop these other parts of a J2EE application. Note also that the J2EE platform embraces the Common Object Request Broker Architecture (CORBA). All J2EE containers include a CORBA-compliant Object Request Broker (ORB). The interoperability protocol between EJB containers from multiple vendors is based on CORBA standards, such as remote method invocation over Internet Inter-ORB Protocol (RMI-IIOP) and other CORBA standards for transactions, security, and name services. These interoperable protocols allow application servers from different vendors to interoperate within an enterprise. |