1.1 From a Two-Tier to a J2EE Architecture

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 Architecture

With 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 Architecture

graphics/01fig01.gif

Before 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.

  • It is easy to compromise database integrity. Because each client program embeds the business logic, an error or bug in the client program can easily compromise the integrity of the corporate database.

  • It is difficult to administer in a large enterprise. In this architecture, the application is deployed on the client machines, and the information technology (IT) department of the corporation must maintain the application. If a business process changes, the IT department must replace all copies of the old version of the application with a new version of the application. This is a difficult task in a corporation with tens of thousands of PCs, especially when many of them may be "unmanaged" laptop machines.

  • It is difficult to maintain the code. The two-tier architecture does not support modular programming, making it difficult to maintain application code. Maintenance difficulty increases exponentially for larger organizations, which typically use more programmers to code and maintain applications.

  • It exposes the applications to security violations. A skillful programmer may "hack" the application installed on the PC to alter the business process that the application implements.

  • Its scalability is limited; it is difficult to scale to a large number of users. Each running application typically needs a connection to the corporate database. Because the number of open connections is typically limited by the database product, it may not be possible for all users to run the application at the same time.

  • It requires a homogeneous client architecture. Before the advent of the Java language, the two-tier architecture typically required the client machines to be homogeneous. For example, it typically required all client machines to be PCs running the same type of operating system.

  • It ties the application to one particular presentation type. Because the same application implements not only the business processes but also the presentation, it may not be possible to reuse the implementation of the business process with a different presentation type, such as a browser or intelligent cell phone.

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 Architecture

The 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 Architecture

graphics/01fig02.gif

The 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.

  • Complexity Developing a three-tier application is more complex than developing a two-tier application. For example, the programmer must deal with distribution, multithreading, security, and so forth. Distributed applications introduce substantial system-level programming complexities with which the developer must deal. Also, distributed applications require the customer IT department to compensate for the lack of application deployment and administration support. In an attempt to reduce the complexity of distributed applications, vendors resorted to using application frameworks, such as transaction processing (TP) monitors. ERP vendors used the concept of an application server. The intention of the application frameworks was to free the application programmer from having to deal with these complexities. Today, application server is the most frequently used term for a distributed application framework.

  • Lack of application portability Because each vendor of an application framework for the three-tier platform uses different application program interfaces (APIs) in its framework, it is not possible for independent software vendors (ISVs) to write applications that are deployable on application servers provided by other vendors.

  • Vendor incompatibility It is difficult to integrate applications from multiple vendors, because each vendor uses a different set of protocols, and there is no standard interoperability among protocols.

  • Limited adoption ISVs have no incentive to write applications for multiple competing frameworks that are not widely adopted. Although tools exist to support distributed applications, these tools work only on the frameworks for which they were developed. Many tools do not work across most frameworks. As a result, there is limited support for a consistent set of tools. Likewise, programmers' knowledge of tools and frameworks is also limited.

  • Incompatibility with the Web The traditional three-tier architecture does not work directly with the Web. The three-tier architecture uses a proprietary protocol for the communication between the client and the application running on the server, and this proprietary protocol does not work with the Web. Although many application framework vendors have added support for Web clients as a front end to their existing products, the resultant architecture still suffers from the other drawbacks listed here.

1.1.3 Early Web-Based Application Architecture

The 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:

  • Cgi-bin scripts do not provide well-structured encapsulation of the underlying business process or of a business entity.

  • Cgi-bin scripts are difficult to develop, maintain, and manage. High-level application development tools do not provide good support for the development of cgi-bin scripts.

  • Cgi-bin scripts intertwine the implementation of business processes with the implementation of the presentation logic. When it is necessary to change one part of the implementation, such as a business process, the other part may be changed inadvertently.

  • Cgi-bin script implementations do not foster the maintenance of the integrity of business rules. The implementation of an enterprise's business rules is scattered across the cgi-bin scripts deployed on numerous Web servers in the enterprise. Therefore, it is difficult for the enterprise to maintain the integrity of its business rules.

1.1.4 J2EE Application Architecture

J2EE 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 Applications

graphics/01fig03.gif

Figure 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 Applications

graphics/01fig04.gif

J2EE 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 Applications

graphics/01fig05.gif

Figure 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 Applications

graphics/01fig06.gif

The 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 Applets

graphics/01fig07.gif

The J2EE platform consists of four programming environments, called containers:

  1. EJB container Provides the environment for the development, deployment, and runtime management of enterprise beans. Enterprise beans are components that implement business logic, which consists of business processes and entities.

  2. Web container Provides the environment for the development, deployment, and runtime management of servlets and JavaServer Pages™ (JSP). The servlets and JSP are grouped into deployable units called Web applications. A Web application implements the presentation logic of an enterprise application.

  3. Application-client container Provides the environment for executing J2EE application clients. This environment is essentially J2SE.

  4. Applet container Provides the environment for executing Java applets. This environment is typically embedded in a Web browser.

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.



Applying Enterprise Javabeans
Applying Enterprise JavaBeans(TM): Component-Based Development for the J2EE(TM) Platform
ISBN: 0201702673
EAN: 2147483647
Year: 2003
Pages: 110

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net