Dimension 2: Logical Tiers

The interacting software components of distributed enterprise applications can be viewed as residing in a number of logical tiers. These tiers represent the logical and physical independence of software components based on the nature of the services they provide.

The logical tier dimension of solution architecture is illustrated in the following figure.

Figure 2–4 Dimension 2: Logical Tiers for Distributed Enterprise Applications

For the most part, logical tier architectures represent the distributed enterprise application layer of Figure 1–1 . The Java ES system service components discussed in Infrastructure Service Levels provide support to application components in all of the logical tiers shown in Figure 2–4. While logical tier concepts apply mostly to custom enterprise applications, they also apply to collaboration services provided by Sun Java Communications Suite components and some portal services.

Description of Logical Tiers

This section provides brief descriptions of the four logical tiers shown in Figure 2–4. The descriptions refer to application components implemented using the J2EE platform component model. However, other distributed component models, such as CORBA, also support this architecture.

• Client tier. The client tier consists of application logic accessed directly by an end user through a user interface. The logic in the client tier could include browser-based clients, Java components running on a desktop computer, or Java^TM 2 Platform, Micro Edition (J2ME^TM platform) mobile clients running on a handheld device.

• Presentation tier. The presentation tier consists of application logic that prepares data for delivery to the client tier and processes requests from the client tier for delivery to back-end business logic. The logic in the presentation tier typically consists of J2EE components such as Java servlet or JSP components that prepare data for delivery in HTML or XML format or receive requests for processing. This tier might also include a portal service that can provide personalized, secure, and customized access to business services in the business service tier.

• Business service tier. The business service tier consists of logic that performs the main functions of the application: processing data, implementing business rules, coordinating multiple users, and managing external resources such as databases or legacy systems. Typically, this tier consists of tightly coupled components that conform to the J2EE distributed component model, such as Java objects, EJB components, or message-driven beans. Individual J2EE components can be assembled to deliver complex business services, such as an inventory service or a tax calculation service. Individual components and service assemblies can be encapsulated as loosely coupled web services within a service oriented architecture model that conform to Simple Object Access Protocol (SOAP) interface standards. Business services can also be built as stand-alone servers, such as an enterprise calendar server or messaging server.

• Data tier. The data tier consists of services that provide persistent data used by business logic. The data can be application data stored in a database management system or it can be resource and directory information stored in a Lightweight Directory Access Protocol (LDAP) data store. The data services can also include data feeds from external sources or data accessible from legacy computing systems.

Logical and Physical Independence

The architectural dimension illustrated in Figure 2–4 emphasizes the logical and physical independence of components, represented by four separate tiers. These tiers signify the partitioning of application logic across various computers in a networked environment:

• Logical independence. The four tiers in the architectural model represent logical independence: You can modify application logic in one tier (for example, in the business service tier) independently of the logic in other tiers. You can change your implementation of business logic without having to change or upgrade logic in the presentation or client tier. This independence means, for example, that you can introduce new types of client components without having to modify business service components.

• Physical independence. The four tiers also represent physical independence: You can deploy the logic in different tiers on different hardware platforms (that is, different processor configurations, chip sets, and operating systems). This independence allows you to run distributed application components on the computers best suited to their individual computing requirements and best suited to maximizing network bandwidth.

  How you map application components or infrastructure components to a hardware environment (that is, your deployment architecture) depends on many factors, depending on the scale and complexity of your software solution. For very small deployments, a deployment architecture might involve only a few computers. For large-scale deployments, the mapping of components to a hardware environment might take into account factors such as the speed and power of different computers, the speed and bandwidth of network links, security and firewall considerations, and component replication strategies for high availability and scalability.

Tiered Architecture Applied to System Components

As shown in Figure 2–3, Java ES infrastructure service components provide the underlying infrastructure support for distributed software solutions. Some of these solutions include application-level services provided by Sun Java Communications Suite components and some Java ES components. These solutions use logical tier design approaches.

For example, the email communication services provided by Messaging Server are implemented using a number of logically distinct configurations of Messaging Server. These distinct configurations each provide a distinct set of services. When designing messaging solutions, these distinct configurations are represented as separate components that are situated in different logical tiers, as shown in the following figure where lines connecting components represent interactions.

The following figure is not meant to be a complete logical architecture. A number of Java ES components are omitted to simplify the illustration.

Figure 2–5 Messaging Server: Example of Tiered Architecture

Communications components are not part of Java ES but are often deployed with Java ES components and used within Java ES architectures. These communications components are part of the Sun Java Communications Suite and are referenced in this document for illustrative purposes only.

The logical separation of Messaging Server functions into different tiers allows the logically distinct configurations of Messaging Server to be deployed on different computers in a physical environment. The physical separation allows for flexibility in meeting quality of service requirements (see Dimension 3: Quality of Service). For example, it provides for different availability solutions for the different instances, and different security implementations for different Messaging Server functions.