Sun Java logo     Previous      Contents      Index      Next     

Sun logo
Sun Java Enterprise System 2004Q2 Technical Overview 

Chapter 2
Java Enterprise System Architecture

This chapter provides an overview of the architectural concepts upon which Java Enterprise System deployments are based.

The chapter describes a framework in which Java Enterprise System deployment architectures is analyzed along three dimensions: logical tiers, infrastructure service levels, and quality of service. These three dimensions, shown schematically as orthogonal axes in the following figure, help to clarify the architectural functions of Java Enterprise System components. The three-dimensional framework is key to designing successful deployment architectures for business software solutions.

Figure 2-1  Three Dimensions of Java Enterprise System Architectural Framework

Diagram showing three orthogonal axes, representing three dimensions of architectural framework: logical tiers, infrastructure service levels, and quality of service.

This chapter explores each of the three dimensions shown in Figure 2-1 independently, followed by a synthesis of the three dimensions into a single framework. The chapter contains the following sections:

Dimension 1: Logical Tiers

The standard architecture for distributed applications separates application logic into a number of tiers. These tiers signify a logical and physical organization of components into an ordered chain of service providers and consumers. Components within a tier typically consume the services provided by components in an adjacent provider tier and provide services to one or more components in an adjacent consumer tier.

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

Figure 2-2  Dimension 1: Logical Tiers for Distributed Enterprise Applications

Diagram showing four logical tiers, left to right, client tier, presentation tier, business service tier, and data tier.

Description of Logical Tiers

This section provides brief descriptions of the four logical tiers shown in Figure 2-2. The descriptions, for the sake of example, refer to components implemented using the Java 2 Platform, Enterprise Edition (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 2 Platform, Micro Edition (J2ME™ 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 components or JSP components that prepare data for HTML or XML delivery or that 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.

Presentation tier components are often reusable components that can be customized and plugged into an application. You can also replicate presentation services for failover and scalability, and you can map these services to computing nodes in a way that optimizes network bandwidth and computing resources.

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 EJB components or message-driven beans (MDBs). Individual J2EE components can be assembled to deliver complex business services, such as an inventory service or tax calculation service. Individual components and service assemblies can be encapsulated as loosely-coupled web services that conform to Simple Object Access Protocol (SOAP) interface standards. Business services can also be built as standalone servers, such as an enterprise calendar server.

The various implementations of business services encapsulate specific application functions that can reside and run on a particular computing node. This approach allows for reusable components that you can customize and plug into an application. As with presentation tier logic, you can replicate these business service providers for failover and scalability, and you can map these service providers to computing nodes in a way that optimizes network bandwidth and computing resources.

Data Tier

The data tier consists of data used by business logic. The data can be persistent 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 can also include data feeds from external sources or data accessible from legacy computing systems.

Logical and Physical Independence

The services shown in the presentation and business service tiers of Figure 2-2 are the centerpiece of this model. These services are multi-threaded software processes capable of supporting large numbers of clients. These clients can be either end-user clients or other services.

The architectural dimension illustrated in Figure 2-2, emphasizes the logical and physical independence of the four tiers, facilitating the partitioning of application logic across the various computing nodes in a networked environment:

Example of Tiered Architecture

The e-mail communication services provided by Messaging Server are an example of the use of logical tiers in architectural design. E-mail services are implemented using a number of Messaging Server components, as shown in the following figure.

Figure 2-3  Messaging Server: Example of Tiered Architecture

Diagram showing Messaging Server components distributed among the four logical tiers.[D]

The logical separation of Messaging Server functions into independent components allows these components to be distributed across different computing nodes in a physical environment. The physical separation allows for easy replication of these components, allows for different availability solutions for the different components, and enables different approaches to the security of different components.

Dimension 2: Infrastructure Service Levels

The interacting software components of distributed enterprise applications require an underlying set of infrastructure services that allows the distributed components to communicate with each other, coordinate their work, implement secure access, and so forth. This set of distributed services constitutes an infrastructure upon which distributed components can be built.

Distributed Infrastructure Services

Distributed infrastructure services can be conceptualized as a set of distributed services at many different levels. These services constitute the infrastructure service levels dimension of deployment architecture as illustrated in the following figure.

Figure 2-4  Dimension 2: Distributed Infrastructure Service Levels

Diagram showing distributed service levels from lowest level operating system platform services to highest level integration services.

The levels in Figure 2-4 reflect a general dependence of the various distributed services on one another, from the lowest-level operating system services to the highest-level application and integration services. Each service generally depends on services below it and supports services above it.

However, higher-level services can directly interact with lower-level services without depending on intermediate levels. For example, some runtime services might depend directly on platform services without requiring any of the service levels in between. Also, the levels represented in Figure 2-4 are not strictly prescribed. Other service levels, such as a monitoring or management service, might also be included in this conceptual illustration.

In general, the services shown in Figure 2-4 fall into three broad groupings: low-level platform services, high-level application services, and a group of middleware services, so named for their location between the other two groupings.

The following paragraphs briefly describe the different services, with reference, where relevant, to Java programming language artifacts. The services are described from lowest to highest, as shown in Figure 2-4:

Java Enterprise System Implementation

Java Enterprise System implements the distributed infrastructure services dimension shown in Figure 2-4. The positioning of Java Enterprise System components within the different levels is shown in the following illustration:

Figure 2-5  Java Enterprise System: Distributed Infrastructure Services

Diagram showing positioning of Java Enterprise System components against the various levels in the distributed infrastructure services, previously described.[D]

The Java Enterprise System implementation of distributed infrastructure services shown in Figure 2-5 consists of discrete software servers (system servers) that provide services at various levels within the distributed infrastructure service stack. These service providers are multi-threaded server process capable of supporting a large number of clients.


A number of Java Enterprise System components are not shown in Figure 2-5 because they do not directly provide distributed infrastructure services. Rather, these components provide the following support functions:

  • Portal Server Mobile Access provides access to Portal Server from wireless clients.
  • Portal Server Secure Remote Access provides access to Portal Server from browser-based clients outside an enterprise firewall.
  • Directory Proxy Server provides access to Directory Server from browser-based clients outside an enterprise firewall.
  • Sun Cluster provides high availability to infrastructure services and is discussed under the quality of service dimension of architecture (see Example: Sun Cluster).

Java Enterprise System Servers

Java Enterprise System servers collectively implement all of the levels shown in Figure 2-5. Each system server provides a particular service or set of services in support of distributed enterprise applications. These system services are what uniquely characterize each server (see Table 1-1 for a brief description of the services provided by each system server).

Dependencies Between System Servers

In general, each system server depends on servers below it in the infrastructure and supports servers above it. Table 2-1 shows the specific dependencies between the different Java Enterprise System servers, listed from top to bottom, as shown in Figure 2-5.

Table 2-1  Java Enterprise System Server Interdependencies  

Java Enterprise System Component

Provides Support To

Depends On

Portal Server


Identity Server

Application Server or Web Server

Directory Server

If configured to use Portal Server Channels:

Calendar Server
Messaging Server
Instant Messaging

Messaging Server

Calendar Server (for e-mail notifications)

Portal Server (for messaging channel)

Identity Server (for single sign-on)

Web Server (Web interface)

Directory Server

Instant Messaging

Portal Server (for instant messaging channel)

Identity Server (for single sign-on)

Directory Server

Calendar Server

Portal Server (for calendar channel)

Messaging Server (for e-mail notification service)

Identity Server (for single sign-on)

Web Server (Web interface)

Directory Server

Identity Server

Portal Server

If configured for single sign-on:

Calendar Server
Instant Messaging
Messaging Server

Application Server or Web Server

Directory Server

Application Server

Portal Server

Identity Server

Message Queue

Directory Server (optional)

Message Queue

Application Server

Directory Server (optional)

Web Server

Portal Server

Identity Server

Identity Server (optional: access control)

Directory Server

Portal Server

Calendar Server

Messaging Server

Instant Messaging

Identity Server


Anatomy of a System Server

Despite the different services each Java Enterprise System server provides, all system servers share some common characteristics. In general, each system server employs the following kinds of software components or subcomponents:

These subcomponents are shown schematically in the following figure and are described briefly in the sections that follow.

Figure 2-6  Java Enterprise System Server Anatomy

Diagram showing the kinds of components and subcomponents that make up a Java Enterprise System server, subsequently described.[D]

System Services Subcomponents

Table 1-1 summarizes the main system services provided by each of the Java Enterprise System servers.

Each server has its own way of implementing the services it provides. Some servers are written in the Java language, others in C or C++. Some use a single subcomponent to implement their unique system services, others use a number of subcomponents. For example, Portal Server uses Rewriter, Desktop, and NetMail subcomponents to provide the main system services of the Portal Server.

Support Services Subcomponents

Each system server contains a number of subcomponents that provide various support services upon which the system services depend. The support services shown in Figure 2-6 typically correspond to distributed infrastructure services provided by Java Enterprise System. For example:

In some cases, support services are provided externally by other Java Enterprise System servers. In many cases, however, the implementation of support services is internal to the server. The goal of the Java Enterprise System is to extract common internal services and implement them as system-level services, such as a logger service or communication services, and so forth.

Shared Components

In addition to support services, most Java Enterprise System servers also depend upon a number of local services, often used to provide portability across different operating systems. These services are libraries installed locally as shared components that all system servers running on a particular computing node can use. Examples of Java Enterprise System shared components include: Java 2 Platform, Standard Edition (J2SE™ platform), Netscape Portable Runtime (NSPR), Network Security Services (NSS), Network Security Services for Java (JSS), and so forth. For a complete list, see Shared Components.

Dimension 3: Quality of Service

The previous two architectural dimensions (logical tiers and infrastructure service levels) largely define the logical aspects of architecture, namely which components are needed to interact in what way to deliver services to end users. However, an equally important dimension of any deployed solution is the ability of the solution to meet quality of service requirements.

As internet and E-commerce services have become more critical to business operations, the performance, availability, security, scalability, and serviceability of these services has become a key requirement of large-scale, high-performance deployment architectures.

In other words, meeting business requirements regarding a number of important service qualities has become an important dimension of deployment architecture. The qualities most often used to specify quality of service requirements are summarized in the table below.

Table 2-2  Dimension 3: Service Qualities Impacting Deployment Architecture

System Qualities



The measurement of response time and latency with respect to user load conditions.


A measure of how often a system’s resources and services are accessible to end users, often expressed as the uptime of a system.


A complex combination of factors that describe the integrity of a system and its users. Security includes authentication and authorization of users as well as the secure transport of information.


The ability to add capacity (and users) to a deployed system over time. Scalability typically involves adding resources to the system but should not require changes to the deployment architecture.

Latent Capacity

The ability of a system to handle unusual peak load usage without additional resources.


The ease by which a deployed system can be maintained, including tasks such as monitoring the system, repairing problems that arise, and upgrading hardware and software components.

The system qualities that affect deployment architecture are closely interrelated. Requirements for one system quality might affect the requirements and design for other system qualities. For example, higher levels of security might affect performance, which in turn might affect availability. Adding additional servers to address availability issues might affect maintenance costs (serviceability).

Understanding how system qualities are interrelated and which trade-offs to make is key to designing architectures that satisfy both business requirements and business constraints.

Applying Quality of Service Requirements

Quality of service requirements for the system qualities shown in Table 2-2 are normally stated on a system-wide level, that is, they apply to the system as a whole. However, the overall functioning of a software system is the result of complicated interactions among the various application and infrastructure components in the system.

For this reason, quality of service requirements generally apply to all tiers at all infrastructure service levels within an architecture. These requirements often apply on a component by component basis.

For example, if a system is supposed to be highly available, you need to consider the most likely points of failure in the system and focus first on those failures that would have the most impact. A high availability solution for such high-risk components might be more demanding than a high availability solution for components that are less frequently used or which do not cause overall system failure.

Similar issues come into play when considering performance, security, and scalability. A good deal of analysis is required to understand potential weak points or bottlenecks in a system and to incorporate architectural solutions that make sense for each component in a system.

Example: Sun Cluster

One Java Enterprise System component specifically addresses the quality of service architectural dimension: Sun Cluster.

Sun Cluster software provides high availability and scalability services for the Java Enterprise System as well as for applications based on Java Enterprise System infrastructure.

A cluster is a set of loosely coupled computing nodes that collectively provides a single client view of services, system resources, and data. Internally, the cluster uses redundant computing nodes, interconnects, data storage, and network interfaces to provide high availability to cluster-based services and data. Cluster software continuously monitors the health of member nodes and other cluster resources, and uses the internal redundancy to provide near-continuous access to these resources even when failure occurs.

In addition, Cluster agents continuously monitor software services hosted by the cluster. In case of failure, these software agents act to fail over or restart the services they monitor. Cluster agents are available for all of the Java Enterprise System servers, and you can write custom Cluster agents for any distributed components or service implementations that run on top of the Java Enterprise System infrastructure. In this way, Cluster software provides for highly available services. (This availability is at the service level, and does not provide for session-level failover.)

Because of the control afforded by Cluster software, a cluster can also provide for scalable services. By leveraging a cluster’s global file system and the ability of multiple nodes in a cluster to run infrastructure or application services, increased demand on these services can be balanced among multiple concurrent instances of the services. When properly configured, Cluster software can therefore provide for both high availability and scalability in a distributed enterprise application.

Because of the redundancy necessary to support Cluster services, inclusion of these services in a solution has a large impact on your computing environment. Inclusion of Cluster services substantially increases the number of computing nodes and network links required in your physical topology.

Unlike the services provided by Java Enterprise System servers, Cluster services are distributed peer-to-peer services. Cluster software therefore needs to be installed on every computing node in a cluster.

Three Dimensional Synthesis

The three architectural dimensions discussed separately in the preceding sections, when pulled together, provide a framework within which to understand the role of any application or infrastructure component within an architectural design.

Basically, distributed components in each logical tier of a deployment architecture (the first dimension) need to be supported by appropriate infrastructure services (the second dimension). Each component within that two dimensional matrix must be deployed so as to meet quality of service requirements (the third dimension).

The synthesis of these three dimensions is conceptually represented in the following figure.

Figure 2-7  Three Dimensional Synthesis of Java Enterprise System Architecture

Diagram showing three dimensional framework as a cube with logical tiers, infrastructure service levels, and qualities of service as 3D faces.[D]

Within this framework, for example, Directory Server would be categorized as a back-end, low-level Java Enterprise System component. Consequently, many other components depend on Directory Server, and therefore, its failure would have a tremendous impact on a business system. This signifies that Directory Server must be highly available.

Because Directory Server is used to store sensitive user or configuration information, a breach of security would also have a tremendous impact. This signifies that Directory Server and all communication channels that interact with it should be highly secure.

It is beyond the scope of this book to outline design methodologies for using the architectural framework in Figure 2-7. However, the three-dimensional architecture highlights aspects of Java Enterprise System that are important to understand in using Java Enterprise System to deliver distributed enterprise deployments.

Previous      Contents      Index      Next     

Copyright 2004 Sun Microsystems, Inc. All rights reserved.