Sun Java Enterprise System 2005Q4 Technical Overview

Chapter 2 Java Enterprise System Solution Architectures

This chapter provides an overview of the architectural concepts upon which Java Enterprise System (Java ES) solutions are based. The chapter demonstrates how Java ES components, both system service components and service quality components, are used to support distributed enterprise solutions.

Java ES solution architectures have two aspects: a logical architecture and a deployment architecture. The logical architecture depicts the interactions between the logical building blocks (the software components) of a solution. The deployment architecture depicts the mapping of the logical architecture to a physical computing environment. Java ES components play important roles in both logical architectures and deployment architectures.

This chapter describes an architectural framework for designing Java ES solution architectures, followed by an example solution architecture based on that architectural framework.

The chapter covers the following topics:

Java Enterprise System Architectural Framework

Java ES components support the deployment of distributed enterprise-strength software solutions.

To achieve the required functionality at the levels of performance, availability, security, scalability, and serviceability mandated by business requirements, these software solutions must be properly designed.

A number of architectural dimensions are involved in designing distributed enterprise-strength software solutions. These dimensions represent different perspectives from which to view the interactions of the many software components used to build such systems. In particular, the design of distributed systems involves the following three architectural dimensions:

These three dimensions of solution architecture are shown in the following figure.

Figure 2–1 Dimensions of &SystemNameShort; Solution Architecture

Diagram showing three dimensional framework with logical tiers,
infrastructure service levels, and qualities of service.

Together these three dimensions represent a single framework that incorporates the relationships between the software components, both application components and infrastructure components, that are needed to achieve the service functions and service quality required of a software solution.

The following sections describe the three dimensions individually, followed by a synthesis of the three dimensions into a unified framework.

Dimension 1: Infrastructure Service Dependencies

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 section explains the key role played by a number of Java ES components in providing these infrastructure services.

Infrastructure Service Levels

In designing a distributed software system, whether it consists mostly of custom-developed components or of out-of-the-box Java ES components, you need to incorporate a number of infrastructure services. These services operate at many levels.

The infrastructure service dependency dimension of solution architecture is illustrated in Figure 2–2. The levels shown in this figure are an expanded view of the infrastructure service layer of Figure 1–1.

The hierarchy of services in Figure 2–2 and the dependencies between them constitute an important dimension of a solution’s logical architecture. These infrastructure services provide the conceptual basis for understanding the role of Java ES system service components (see System Service Components).

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

Figure 2–2 Dimension 1: Infrastructure Service Levels

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

The following paragraphs describe the different infrastructure service levels and refer to Java programming language artifacts, where relevant. The service levels are described from lowest to highest, as shown in Figure 2–2:

The service levels shown in Figure 2–2 reflect a general dependence of the various infrastructure 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.

Figure 2–2, however, does not represent a strict layering of infrastructure services. 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. In addition, other service levels, such as a monitoring or management service, might also be included in this conceptual illustration.

Java Enterprise System Infrastructure Service Components

Java ES components implement the distributed infrastructure service levels shown in Figure 2–2. The positioning of Java ES system service components within the different levels is shown in Figure 2–3.

Figure 2–3 Java ES System Service Components

Diagram showing positioning of Java ES system service components
against the various levels of distributed infrastructure services.

Note –

The operating system platforms shown in Figure 2–3 are not formally part of Java Enterprise System; however, they are included to show the operating system platforms on which Java ES components are supported.

Java Enterprise System Infrastructure Service Dependencies

In general, each Java ES system service component shown in Figure 2–3 depends on components below it in the infrastructure and supports components above it. These dependency and support relationships are a key factor in designing logical architectures.

Table 2–1 shows the specific relationships between the Java ES system service components, listed from top to bottom, as shown in Figure 2–3.

Table 2–1 Relationships Between Java ES System Service Components


Depends On 

Provides Support To 

Portal Server 

Application Server or Web Server 

Access Manager 

Directory Server 

If configured to use corresponding Channels: Calendar Server Messaging Server Instant Messaging 


Messaging Server 

Directory Server 

Access Manager (for single sign-on) 

Calendar Server (for email notifications) 

Portal Server (for messaging channel) 

Instant Messaging 

Directory Server 

Access Manager (for single sign-on) 

Portal Server (for instant messaging channel) 

Calendar Server 

Directory Server 

Messaging Server (for e-mail notification service) 

Access Manager (for single sign-on) 

Portal Server (for calendar channel) 

Access Manager 

Application Server or Web Server 

Directory Server 

Portal Server 

If configured for single sign-on: Calendar Server Messaging Server Instant Messaging 

Application Server 

Message Queue 

Directory Server (for administered objects) 

Portal Server 

Access Manager 

Message Queue 

Directory Server (for administered objects) 

Application Server 

Web Server 

Access Manager (for access control) 

Portal Server 

Access Manager 

Directory Server 


Portal Server 

Calendar Server 

Messaging Server 

Instant Messaging 

Access Manager 

Service Registry 


Applcation Server-based components 

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

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

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. However, logical tier concepts also apply to system service components that provide application-level services, such as Messaging Server and Calendar Server.

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 Java 2 Platform, Enterprise Edition (J2EETM platform) component model. However, other distributed component models, such as CORBA, also support this architecture.

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 the various computers in a networked environment:

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, however, include application-level services provided directly by 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.

Figure 2–5 Messaging Server: Example of Tiered Architecture

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

Note –

Figure 2–5 is not meant to be a complete logical architecture; a number of Java ES components are omitted to simplify the illustration. Lines connecting components represent interactions.

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.

Dimension 3: Quality of Service

The previous two architectural dimensions (infrastructure service dependencies and logical tiers) mostly concern 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.

The quality of service dimension of solution architecture highlights the roles played by Java ES service quality components.

Service Qualities

As Internet and e-commerce services have become more critical to business operations, the performance, availability, security, scalability, and serviceability of these services have become key quality-of-service requirements of large-scale, high-performance deployment architectures.

To design a successful software solution, you have to establish relevant quality-of-service requirements and design an architecture that meets those requirements. A number of important service qualities are used to specify quality-of-service requirements. These service qualities are summarized in the following table.

Table 2–2 Service Qualities Impacting Solution Architecture

System Service 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 (the uptime of a system).


A complex combination of factors that describe the integrity of a system and its users. Security includes physical security of systems, network security, application and data security (authentication and authorization of users), as well as the secure transport of information. 


The ability to add capacity 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 monitoring the system, repairing problems that arise, and upgrading hardware and software components. 

The quality-of-service dimension strongly impacts a solution’s deployment architecture: how application components and infrastructure components are deployed in a physical environment.

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

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

Java Enterprise System Service Quality Components

Several Java ES components are used principally to enhance the quality of services provided by system service components or distributed application components. These software components are often used in conjunction with hardware components, such as load balancers and firewalls.

The Java ES service quality components, introduced in Service Quality Components, are summarized as follows:

The following table shows the most important Java ES service quality components from an architectural perspective with the system qualities they impact most.

Table 2–3 Service Quality Components and the System Qualities Impacted


System Qualities Impacted 

Communications Express



Directory Proxy Server



High Availability Session Store 


Portal Server Secure Remote Access



Sun Cluster 



Web Proxy Server 

Security Performance Serviceability

Sun Cluster Software

Sun Cluster software provides high availability and scalability services for Java ES components and for applications supported by Java ES infrastructure.

A cluster is a set of loosely coupled computers that collectively provides a single client view of services, system resources, and data. Internally, the cluster uses redundant computers, interconnects, data storage, and network interfaces to provide high availability to cluster-based services and data.

Sun Cluster software continuously monitors the health of member nodes and other cluster resources. In case of failure, Sun Cluster software intervenes to initiate failover of the resources it monitors, thereby using the internal redundancy to provide near-continuous access to these resources.

A two-node cluster to support data store services for Messaging Server and Calendar Server is shown in the following figure.

Figure 2–6 Availability Design Using Sun Cluster Nodes

Diagram showing redundant computers, data stores, and interconnects
in Sun Cluster availability design.

Sun Cluster data service packages (sometimes referred to as Sun Cluster agents) are available for all Java ES system service components. You can also write agents for custom-developed application components.

Because of the control afforded by Sun Cluster software, it 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, Sun Cluster software can therefore provide for both high availability and scalability in a distributed enterprise application.

Because of the redundancy necessary to support Sun Cluster environments, inclusion of Sun Cluster in a solution substantially increases the number of computers and network links required in your physical environment.

Unlike the services provided by other Java ES components, Sun Cluster availability services are distributed peer-to-peer services. Sun Cluster software therefore needs to be installed on every computer in a cluster.

Synthesis of the Three Architectural Dimensions

When viewed together, the three architectural dimensions shown in Figure 2–1 and discussed in the previous sections provide a framework for designing distributed software solutions. The three dimensions (infrastructure service dependencies, logical tiers, and quality of service) highlight the role played by Java ES components in solution architectures.

Each dimension represents a distinct architectural perspective. Any solution architecture needs to take them all into account. For example, distributed components in each logical tier of a solution architecture (dimension 2) need to be supported by appropriate infrastructure components (dimension 1) and appropriate service quality components (dimension 3).

Similarly, any component within a solution architecture plays different roles with respect to the different architectural dimensions. For example, Directory Server can be seen both as a back-end component in the data tier (dimension 2) and as a provider of persistence services (dimension 1).

Because the centrality of Directory Server with respect to these two dimensions, quality of service issues (dimension 3) are paramount for this Java ES component. A Directory Server failure would have a tremendous impact on a business system, so high availability design for this component is very important; and because Directory Server is used to store sensitive user or configuration information, security design for this component is also very important.

The interplay of the three dimensions with respect to Java ES components impacts the design of solution logical architectures and solution deployment architectures.

It is beyond the scope of this book to outline detailed design methodologies based on the architectural framework represented by Java Enterprise System Architectural Framework. However, the three-dimensional architecture framework highlights aspects of design that are important to understand in deploying software solutions based on Java Enterprise System.

Example Java Enterprise System Solution Architecture

Java Enterprise System supports a broad range of software solutions.

Many solutions can be designed and deployed out-of-the-box, with no development effort, by using components included in Java Enterprise System. Other solutions, might require extensive development efforts, requiring you to develop custom J2EE components that provide new business or presentation services. You might encapsulate these custom components as web services that conform to Simple Object Access Protocol (SOAP) interface standards. Many solutions involve a combination of these two approaches.

This section provides an example that demonstrate how Java Enterprise System supports an out-of-the-box solution, drawing from the architectural concepts of the previous section.

Enterprise Communications Scenario

Businesses commonly need to support communication among their employees, specifically email and calendar services. Such businesses find it advantageous for their employees to have personalized access to internal web sites and other resources based on enterprise-wide authentication and authorization services. In addition, these businesses want employee identity to be tracked across all enterprise services, so that a single web sign-on provides access to all such services.

These specific business requirements, which represent only an example set of business requirements, are summarized in the following table.

Table 2–4 Business Requirements Summary: Communications Scenario

Business Requirement 


Java ES Services Needed 

Single sign-on 

Access to secure enterprise resources and services based on a single identity with single sign-on for web access. 

Identity services 



Email messaging between employees and with outside world. 

Electronic employee calendaring and meeting arrangements. 

Communication and Collaboration services 

Portal access 

Single, web-based, personalized access point to communication services such as email and calendar as well as internal web pages. 

Portal services 

In addition, an enterprise has requirements concerning the performance, availability, network security, and scalability of the software system that provides these services.

Logical Architecture for Example Scenario

A logical architecture for delivering the portal, communication, and identity services identified in Table 2–4 using Java ES components is shown in the following figure. The architecture treats logically distinct configurations of Messaging Server as separate components because of the distinct services they each provide.

Figure 2–7 Logical Architecture for Enterprise Communications Scenario

Diagram showing logical architecture for the example enterprise
communications scenario.

The components are placed within a horizontal dimension that represents standard logical tiers and within a vertical dimension that represents infrastructure service levels. The interactions between the components depend on their functions as distributed infrastructure services (interactions between infrastructure service levels) or their roles within a tiered application architecture (interactions within and between logical tiers).

In this architecture, Access Manager, accessing user information stored in Directory Server, is the arbiter of single sign-on authentication and authorization for Portal Server and other web-based components in the presentation tier. Messaging Server components include a message store (Messaging Server-STR) in the data tier, sending and retrieving components in the business services tier, and an HTTP access component and Communications Express in the presentation tier.

The logical architecture also shows the infrastructure service dependencies between the various Java ES components. Portal Server, for example, depends on Communications Express for its messaging and calendar channels and on Access Manager for authentication and authorization services. These components, in turn, depend upon Directory Server for user information and configuration data. A number of components require web container services provided by Web Server.

For more information about Java ES solution logical design, see the Sun Java Enterprise System 2005Q4 Deployment Planning Guide.

Deployment Architecture for Example Scenario

In moving from the logical architecture to a deployment architecture, quality-of-service requirements become paramount. For example, protected subnets and firewalls might be used to create a security barrier to back-end data. Availability and scalability requirements might be met for many components by deploying them on multiple computers and using load balancers to distribute requests among the replicated components.

However, where more demanding availability requirements apply and where large amounts of disk storage is involved, other availability solutions are more appropriate. For example, Sun Cluster can be used for the Messaging Server store and multimaster replication can be used for Directory Server.

For more information about Java ES solution deployment design, see the Sun Java Enterprise System 2005Q4 Deployment Planning Guide.

Key Terms in This Chapter

This section explains key technical terms used in this chapter, with an emphasis on clarifying the relationships between these terms how they are used in the Java Enterprise System context.

application component

A custom-developed software component that performs some specific computing function, providing business services to end users or to other application components. An application component usually conforms to a distributed component model (such as CORBA and the J2EETM platform). These components, singly or combined, can be encapsulated as web services.


A design that shows the logical and physical building blocks of a distributed application (or some other software system) and their relationships to one another. In the case of a distributed enterprise application, the architectural design generally includes both the application’s logical architecture and deployment architecture

business service

An application component or component assembly that performs business logic on behalf of multiple clients (and is therefore a multi-threaded process). A business service can also be an assembly of distributed components encapsulated as a web service, or it can be a standalone server.


Software that requests software services. (Note: this is not a person—see end user.) A client can be a service that requests another service, or a GUI component accessed by an end user.

deployment architecture

A high-level design that depicts the mapping of a logical architecture to a physical computing environment. The physical environment includes the computers in an intranet or Internet environment, the network links between them, and any other physical devices needed to support the software.

logical architecture

A design that depicts the logical building blocks of a distributed application and the relationships (or interfaces) between these building blocks. The logical architecture includes both the distributed application components and the infrastructure services components needed to support them.


A multi-threaded software process (as distinguished from a hardware server) that provides a distributed service or cohesive set of services for clients that access the service by way of an external interface.

web service

A service that conforms to standardized Internet protocols for accessibility, service encapsulation, and discovery. The standards include the SOAP (Simple Object Access Protocol) messaging protocol, the WSDL (Web Service definition Language) interface definition, and the UDDI (Universal Discovery, Description, and Integration) registry standard.