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.

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.

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:

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 tier or client tier. This independence means, for example, that you can introduce new types of clients without having to modify the business logic.

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

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.

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.

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:

Operating system platform. Provides the basic support for any process running on a computing node. The operating system (such as Solaris™ Operating System, Linux, or Windows) manages physical devices as well as memory, threads, and other resources necessary to support the Java Virtual Machine (JVM™ machine).

Network transport. Provides basic networking support for communication between distributed application components running on different computing nodes. These services include support for protocols such as TCP and HTTP. Other higher-level communication protocols (see the Message layer) depend on these basic transport services.

Persistence. Provides support for accessing and storing both static data (such as user, directory, or configuration information) and dynamic application data (information that is frequently being updated).

Messaging. Provides support for both synchronous and asynchronous communication between application components. Synchronous messaging is real-time sending and receipt of messages; it includes remote method invocation (RMI) between J2EE components and SOAP interactions with web services. Asynchronous messaging is communication in which the sending of a message does not depend on the readiness of the consumer to immediately receive it. Asynchronous messaging specifications, for example, Java Message Service (JMS) and ebXML, support guaranteed reliability and other messaging semantics.

Runtime. Provides support required by any distributed component model, such as the J2EE or CORBA models. In addition to the remote method invocation needed for tightly coupled distributed components, runtime services include component state (life-cycle) management, thread pool management, synchronization (mutex locking), persistence services, distributed transaction monitoring, and distributed exception handling. In a J2EE environment, these runtime services are provided by EJB, web, and message-driven bean (MDB) containers in an application server or web server.

Security and policy. Provides support for secure access to application resources. These services include support for policies that govern group or role-based access to distributed resources, as well as single sign-on capabilities. Single sign-on allows a user’s authentication to one service in a distributed system to be automatically applied to other services (J2EE components, business services, and web services) in the system.

User collaboration. Provides services that play a key role in supporting direct communication between users and collaboration among users in enterprise and Internet environments. As such, these services are application-level business services, normally provided by standalone servers (such as an e-mail server or calendar server).

Integration. Provides the services that aggregate existing business services, either by providing a common interface for accessing them, as in a portal, or by integrating them through a process engine that coordinates them within a production workflow. Integration can also take place as business-to-business interactions between different enterprises.

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:

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.



Note	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	None

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.

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	Description
Performance	The measurement of response time and latency with respect to user load conditions.
Availability	A measure of how often a system’s resources and services are accessible to end users, often expressed as the uptime of a system.
Security	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.
Scalability	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.
Serviceability	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.

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
Sun Java Enterprise System 2004Q2 Technical Overview