| The number of logical tiers in an enterprise solution has been an evolutionary process. Originally applications were huge monolithic programming structures, mainframe applications that were accessed through terminals. Because the terminal was essentially free of any logicjust a viewing deviceall presentation and business logic as well as all data access mechanisms typically resided as one extremely large application on one application infrastructurethe mainframe. Such an approach had advantages, the principal of these being that only one application infrastructure needed to be maintained and trained upon. However, mainframe systems, which are a classic example of a single- tier system model, posed many challenges in the areas of application modification, maintenance, and scalability because the applications were designed as very large and complex monolithic systems. Client/server applications later standardized the two-tier system model; the data resided on a server and the presentation and business logic were tightly coupled in the context of a client application, which communicated with the data server via ODBC or native database access mechanisms. This two-tier system model enabled the central sharing and management of data through bespoke applications. However, in addition to the single-tier challenges that still existed, the two-tier system gave rise to some new challenges: -
The application was still large and complex. -
The residency of the application had shifted from a mainframe system environment to a desktop system environmentthe desktop was now the workhorse for the application. -
The task of modifying an application was dependent on the complexity of the business and presentation logic and proportional to the number of applications rolled-out. -
The monitoring of the applications had shifted from one application infrastructure, the mainframe, to the desktop, for which a distributed (desktop) solution needed to be designed and developed and centrally maintained. -
Inter-application communication had now shifted to a distributed desktop environment and was dependent on the capabilities of the technologies used to develop the applications (Visual Basic, C, C++, and PowerBuilder). Only after a long void were capabilities such as DCOM and technology-based proxy objects available to enable inter-application communication. After a lot of application modification, maintenance, and scalability pains, the next logical step was very clear and simple: -
The application interface had to be separated from the business logic. -
The business logic needed to exist as self-contained functional units of code (business objects or components ). -
Scalability needed to be addressed at the business logic level, enabling business objects or components to reside transparently on server machines that were suited to the type and performance of business processing required. The result was a three-tier system model consisting of a user interface layer, a business logic layer,, and a data layer, respectively. This approach promotes the capability to modify each layer independently without cascading the changes to the other layers . The evolution of designing applications still continues. For example, in most cases an enterprise application accessed through an intranet or extranet or the Internet is implemented with a minimum of four tiers as follows : -
A user's Web browser, for viewing and interacting with the application. -
A Web server, for data entry validation and dynamic Web page creation. -
An application server, such as the WebLogic Server, which acts as a secure, scalable, and highly available container for the business and presentation logic associated with an application and a provider of services the logic might require during its execution. -
A data tier, which is typically comprised of an enterprise relational database management system from such vendors as Oracle, Sybase, or Microsoft. Note The responsibilities of any one tier may not be concrete. For example, some business logic may exist at the Web server or data layer for performance reasons. Though it is to be avoided, you might have to compromise the model to serve the customer.
These four tiers mesh well with Sun's J2EE architecture diagram in version 1.3 of the J2EE specification, as shown in Figure 5.1. Figure 5.1. Sun's representation of the architecture of a J2EE application.  Referencing Figure 5.1: -
A J2EE user interface is typically a thin client comprised of a Java-enabled Web browser that can execute applets or a Java application client. -
Applets are, by design, small client-oriented Java applications that can run inside the Java virtual machine (JVM) of a Web browser. An online connection to a Web server is initially required to download and load the applet into the Web browser. The J2EE specification outlines a methodology for hosting applets inside a standardized applet container environment with added support for acting as J2EE-based clients to J2EE-based servers. For more information on applets, please refer to http://java.sun.com/applets/. Note All leading Web browsers today have an associated Java virtual machine (JVM) plug-in that provides a runtime environment for applets.
-
Application clients are Java-based clients that typically run in a desktop environment in the context of a JVM. They offer a heavier and richer GUI experience than the thin client approach of a Web browser and are typically developed using the Java Swing or Abstract Window Toolkit (AWT) APIs. Java application clients do not need a Web or J2EE server connection to execute, and can be updated automatically once deployed using the Java Network Launching Protocol and API (JNLP). Also, as long as there are no firewall issues, a Java application can use the Remote Method Invocation (RMI) communication mechanism to interact with an EJB container. When firewalls are a concern, the Java client must use the HTTP and HTTPS protocols to communicate with the Web container. Note You will find that most enterprise software vendors are using a Java-based application client for the development of portable multi-platform interfaces, such as administration consoles.
-
The Web server can be associated with the J2EE Web container, whose role is to manage all the Web- related interactions of a J2EE application via the HTTP, HTTPS, and Wireless Application Protocol (WAP) communication protocols. The Web container is also an environment that supports the presentation logic associated with the application interface. The Web container delivers both static and dynamic Web content to requesting clients. The static content is HTML, XML, or other MIME types, whereas the dynamic content is served by Java servlets and JavaServer Pages (JSP). Note MIME stands for Multipurpose Internet Mail Extensions, which are used to transfer different formats of data over the Internet and with electronic mail.
-
The J2EE application server, such as WebLogic Server, can be associated with the J2EE EJB Container, which provides a runtime environment for distributed Java objects called Enterprise JavaBeans (EJBs). . EJB components represent application-specific business logic components, usually built by a developer or a third-party vendor. According to EJB Specification 2.0 (part of J2EE v1.3), there are three types of EJBsSession EJB, Entity EJB, and Message Driven Bean (MDB): -
Once invoked through its methods , a session bean is dedicated to serving the business processing requests of its calling client (Java application client, Applet client, or JSP/Servlet client). A session bean is not persistent, implying that when its invoking client terminates, it also appears to terminate and is no longer associated with the client. For this reason, a session bean implements business logic similar to an interactive session. -
Entity beans model the permanent data in a system that is usually persisted in a database. Entity beans do not contain business process logic; they model the data. Typically, each entity bean has an underlying table in a relational database, and each instance of the bean corresponds to a row in that table. Entity beans are usually called by the session beans to interact with a relational database system. -
A Message Driven Bean (MDB), introduced by the EJB 2.0 specification, offers the integration between the Java Messaging Service (JMS) and Enterprise JavaBean (EJB) specification. The main role of an MDB is to act as a JMS message listener, receiving and processing messages asynchronously. Note Session and entity beans only enable synchronous message processing.
-
The database represents the data tier. Depending on the data or information source to the J2EE application, the data tier can also be referred to as the Enterprise Information System tier, which can comprise database management systems such as Oracle, mainframe applications, CORBA servers, MQSeries applications, and any other legacy application used to service requests from the J2EE server. Even though most J2EE applications can conceptually consist of four tiers, as illustrated in Figure 5.1, J2EE applications are considered to be three-tiered applications. This is because in practice, J2EE applications are distributed over three physical domains of machines: -
The client machine(s) -
A J2EE-compliant multithreaded application server machine(s), which implements the Web and EJB containers -
The enterprise information system machine(s) that supports databases, legacy systems, or other informational resources pertaining to the J2EE application This J2EE three-tier system model is illustrated in Figure 5.2. Figure 5.2. The J2EE representation of the three-tier system model.  |
