Sun logo      Previous      Contents      Index      Next     

Sun Java Enterprise System 2003Q4 Technical Overview

Chapter 1
Conceptual Foundations

This description of the Sun Java Enterprise System is an effort to clarify technical concepts and terminology used in the Java Enterprise System documentation set. Italicized terms are found in "Java Enterprise System Key Terms", which defines the terms and clarifies how they are used in the Java Enterprise System context.

The Java Enterprise System is a software infrastructure that provides the service needed to support enterprise-strength applications distributed across a network or Internet environment. These applications are referred to as distributed enterprise application. The structure of these distributed enterprise applications and the infrastructure services needed to support them are described in subsequent sections of this chapter.

The Java Enterprise System is also a Sun software release and delivery methodology and a new business and pricing strategy. The focus of this document, however, is on the Java Enterprise System as a software system.

This document explores the conceptual foundations of the Java Enterprise System, including the following topics:

Java Enterprise System Component Products

The Java Enterprise System is an integration of previously independent Sun software products into a single software system.

The components of this system (the component products) have been tested together to ensure interoperability: they are compatible with one another and are synchronized on a common set of shared libraries. The components also share a common installation and upgrade technology.

The components of Java Enterprise System and the infrastructure services they provide are described in the following table.

Table 1-1  Java Enterprise System Components 

System Component

Services Provided

Sun Cluster

Provides high availability and scalability services for the Java Enterprise System, the applications that run on top of the Java Enterprise System infrastructure, and the hardware environment in which both are deployed.

Sun ONE Application Server

Provides J2EE container services for Enterprise JavaBeans™ (EJB) components, such as session beans, entity beans, and message-driven beans. The container provides the infrastructure services needed for tightly-coupled distributed components to interact, making it a platform for the development and execution of e-commerce applications and web services. The Application Server also provides web container services.

Sun ONE Calendar Server

Provides calendar and scheduling services to end users and groups of end users. Calendar Server includes a browser-based client that interacts with the server.

Sun ONE Directory Proxy Server

Provides security services for Directory Server from outside a corporate firewall. Directory Proxy Server provides enhanced directory access control, schema compatibility, routing, and load balancing for multiple Directory Server instances.

Sun ONE Directory Server

Provides a central repository for storing and managing intranet and Internet information such as identity profiles (employees, customers, suppliers, and so forth), user credentials (public key certificates, passwords, and pin numbers), access privileges, application resource information, and network resource information.

Sun ONE Identity Server

Provides access management and digital identity administration services. Access management services include authentication (including single sign-on) and role-based authorization for access to applications and/or services. Administration services include centralized administration of individual user profiles, roles, groups, and policies.

Sun ONE Instant Messaging

Provides secure, real-time communication between end users, such as instant messaging (chat), conferencing, alerts, news, polls, and file transfer. The service includes a presence manager that tells users who is currently on line and includes a browser-based client that interacts with the server.

Sun ONE Message Queue

Provides reliable, asynchronous messaging between loosely-coupled distributed components and applications. Message Queue implements the Java Message Service (JMS) API specification and adds enterprise features such as security, scalability, and remote administration.

Sun ONE Messaging Server

Provides secure, reliable, high-capacity store-and-forward messaging that supports email, fax, pager, voice, and video. It can concurrently access multiple message stores and provides content filtering to help reject unsolicited email and prevent virus attacks.

Sun ONE Portal Server

Provides key portal services, such as content aggregation and personalization, to browser-based clients accessing business applications or services. Portal Server also provides a configurable search engine.

Sun ONE Portal Server, Secure Remote Access

Provides secure, Internet access from outside a corporate firewall to Portal Server content and services, including internal portals and Internet applications.

Sun ONE Web Server

Provides Java 2 Platform, Enterprise Edition (J2EE™ platform) web container services for Java web components, such as Java Servlet and JavaServer Pages™ (JSP™) components. The Web Server also supports other web application technologies for delivering static and dynamic web content, such as CGI scripts and Active Server Pages.

Distributed Enterprise Application Architecture

The Java Enterprise System provides infrastructure services to support applications that have both distributed and enterprise application aspects:

Distributed     The application consists of interacting software components deployed across an intranet or Internet environment that might include geographically remote sites. These distributed components, running on the various computing nodes in the environment, work together to deliver specific business functions to end users.

Enterprise     The application’s scope and scale meet the needs of a production environment or Internet service provider. The application typically spans an entire enterprise, integrating many departments, operations, and processes into a single software system.

In short, a distributed enterprise application has one or more of the following functional characteristics:

Architectural Model

The standard architecture for distributed enterprise applications separates application logic into a number of tiers:

The architectural model is illustrated in the following figure.

Figure 1-1  Architectural Model for Distributed Enterprise Applications

Diagram showing four logical tiers, left to right, client tier, presentation tier, buisiness logic tier, and data tier.

The services shown in the presentation and business logic tiers of Figure 1-1 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 model illustrated in Figure 1-1, 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:

Java Implementation of the Architectural Model

The architectural model of Figure 1-1 can be implemented using the various J2EE platform distributed component types and service implementations shown in the following figure. (The links shown between components are suggestive, and are not meant to reflect all possibilities.)

Figure 1-2  Java Implementation of Distributed Enterprise Applications

Diagram showing four logical tiers, populated with the J2EE distributed component types in each tier.

This section provides a brief description of the four tiers of the architectural model as implemented in the Java programming language.

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 logic tier.

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

Business Logic Tier

The business logic 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 higher-level business services, such as an inventory service or tax calculation service. Individual components and higher-level 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 load balancing and failover, 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 Data Access Protocol (LDAP) data store. The data can also include real-time data feeds from external sources or data accessible from legacy computing systems.

Distributed Service Infrastructure

Applications based on the architectural model described in "Distributed Enterprise Application Architecture" depend upon many software services at many levels. The distributed components of such an application require an underlying distributed service infrastructure to communicate with each other, to coordinate their work, to implement secure access, and so forth. This service infrastructure, in turn, is supported by a hardware environment of computing nodes and network links. The general scheme is illustrated in the following figure.

Figure 1-3  Support Infrastructure for Distributed Enterprise Applications

Diagram showing how a distributed enterprise application sits on top of a distributed service infrastructure, which in turn sits on a networked hardware environment.

The distributed service infrastructure shown in Figure 1-3 provides the software platform upon which a distributed enterprise application runs. This platform consists of a set of distributed services as shown in the following conceptual illustration.

Figure 1-4  Distributed Service Infrastructure

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

The levels in Figure 1-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 interacting with intermediate services. 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 1-4 are not strictly prescribed. Other service levels, such as a monitoring or management service, might also be included.

In general, the services shown within the distributed service infrastructure fall into three broad groupings: low-level platform services, high-level application services, and a group of middleware services, so named for their location in the infrastructure.

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 1-4:

The Java Enterprise System

The Java Enterprise System is an implementation of the distributed service infrastructure (Figure 1-4). The positioning of the different Java Enterprise System components within the distributed service infrastructure is shown in the following illustration:

Figure 1-5  The Java Enterprise System

Diagram showing positioning of Java Enterprise System components against the various levels in the distsributed services infrastructure, previously described. Higher-level components generally depend on lower-level components.

The Java Enterprise System includes two main component types:

The following sections describe Java Enterprise System servers and Sun Cluster in greater detail.

System Servers

Java Enterprise System servers implement most of the layers within the distributed service infrastructure, as shown in Figure 1-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 system servers below it in the infrastructure and supports system servers above it. Some servers, however, implement lower-level services internally and are therefore not dependent on other lower-level system servers.

Table 1-2 shows the specific dependencies between the different Java Enterprise System servers, listed from top to bottom, as shown in Figure 1-5.

Table 1-2  System Server Dependencies 

System Server

Depends On

Portal Server

Web Server or Application Server
Directory Server
Identity Server
Messaging Server (optional: channel)
Calendar Server (optional: channel)
Instant Messaging (optional: channel)

Portal Server, Secure Remote Access

Portal Server
Identity Server (optional: SDK)

Messaging Server

Directory Server
Web Server (optional)
Identity Server (optional: single sign-on)

Instant Messaging

Directory Server
Identity Server (optional: SDK)
Messaging Server (optional)

Calendar Server

Directory Server
Identity Server (optional: single sign-on)
Messaging Server (optional: email notices)

Identity Server

Web Server or Application Server
Directory Server

Web Server

Directory Server (optional: access control)

Application Server

Message Queue
Directory Server (optional: access control)

Message Queue

Directory Server (optional: directory services)

Directory Server


Directory Proxy Server

Directory Server

Anatomy of a System Server

Despite the different system 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 Figure 1-6 and 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 system server implements the services it provides differently. 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.

Figure 1-6  Java Enterprise System Server Anatomy

Diagram showing the kinds of components and subcomponents that make up a Java Enterprise System server: system services subcomponents, support services subcomponents, and shared components.

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 1-6 typically correspond to various services in the distributed software service infrastructure. 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 minimize the use of internal support services in favor of external system services, extracting common internal services and implementing them as new system services, such as a new logger service or new 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.

External Interfaces

Each Java Enterprise System server interacts with clients through an interface. The clients might be other servers, business service implementations, simple distributed components, or they might be end-user clients such as the client programs delivered with Calendar Server and with Instant Messaging.

A system server’s external interfaces include two kinds:

The following table summarizes the protocols by which clients interact with each system server and indicates which system servers provide a customization API. The servers are listed in alphabetical order.

Table 1-3  System Server Interface Protocols and API Support 

System Server


Customization API

Application Server



Calendar Server

Web Calendar Access Protocol (WCAP)


Directory Proxy Server

Directory Service Markup Language (DSML), version 2


Directory Server



Identity Server



Instant Messaging



Message Queue



Messaging Server



Portal Server



Portal Server, Secure Remote Access



Web Server



Each Java Enterprise System server also has an administration interface for configuring and managing server functions. This administration interface provides access to the server for server-specific administration clients. These administration clients might be GUI based, command line, or both.

System Server Configuration

For each Java Enterprise System server, the internal components can be tuned to maximize server performance. In fact, each instance (server instance) of a system server is specified by properties that affect the behavior of its various system service and support service subcomponents.

In general, there can be several instances of a system server on a single computing node, single instances of a server on one or more nodes, or a combination of the two, depending on the needs of a deployed application. You can configure each of these instances separately, though multiple instances on a single node might share a common set of configuration properties.

Most system servers have an administration console (a graphical administration interface) that you can use to start, stop and configure each instance of a server. Often this is a browser-based interface that allows you to administer remote servers.


The Java Enterprise System includes, as a separately installable component, the Sun ONE Administration Server (and Server Console) used to configure and manage server instances, as well as perform user and group administration, for Directory Server, Directory Proxy Server, and Messaging Server.

Sun Cluster

Sun Cluster software provides high availability and scalability services for the Java Enterprise System as well as for applications that run on top of the 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.

Application Life-Cycle Concepts

The following figure shows the three main life-cycle stages of a distributed enterprise application:

Figure 1-7  Application Life-Cycle Stages

Diagram showing three main stages in application life cycle: requirements analysis, deployment, and  production execution. Each stage shows tasks involved in that stage.

The following sections describe the concepts and terminology relevant to each of these life-cycle stages.

Requirements Analysis

In the requirements analysis stage of the life cycle, you translate information about business needs into use cases and other technical requirements, which you use to evaluate possible solutions. You then specify a best-fit solution and the system requirements it must meet in a deployment scenario, as shown in the following figure.

Figure 1-8  Requirements Analysis Specifies a Deployment Scenario

Diagram showing how business needs translate through use cases into a solution (a logical architecture) and also how these needs translate into system requirements the solution must meet.

Use Cases and Best-Fit Solution

Use cases are the specific end-user tasks or set of tasks that a distributed enterprise application must perform to meet business needs. Use cases are therefore the basis for arriving at a software solution. The solution is a high-level logical architecture that specifies the application logic required to implement the use cases as well as the infrastructure services needed to support that logic.

Use cases are not only instrumental in choosing a solution, but also, in the deployment stage, in testing that solution to verify that it meets the system requirements identified by your requirements analysis.

System Requirements

A requirements analysis, in addition to specifying a set of use cases that reflect business functional needs, also specifies other technical and performance requirements that a solution must meet. Hence, a deployment scenario must not only specify a software solution, but also a set of system requirements that the solution must meet. These system requirements include the following:

The system requirements you specify in the deployment scenario reflect the usage patterns and growth you expect for a deployed application. A clearly specified deployment scenario allows you to create a deployment design (in the deployment stage) that meets your business needs.


In general, the deployment stage of the life style is a complex process that involves a number of iterative phases and depends not only on an solution’s logical architecture, but also on designing a deployment architecture that meets the application’s performance, availability, security, serviceability, and other requirements.

The deployment process generally involves software components in all the tiers (shown in Figure 1-1) and in all the service layers (shown in Figure 1-4) required to support an application. Thus, in addition to any specific distributed application components (J2EE components, web services, or other servers) you might deploy, you must also deploy any Java Enterprise System components (system components) needed to support the application.

This section covers a number of topics related to the deployment stage of the life-cycle process:

Overview of the Deployment Process

The deployment process consists of the following general phases:

The deployment phases are not rigid: the deployment process is iterative in nature. Nevertheless, the following subsections discuss each of the deployment phases independently.

Deployment Design

In the deployment design phase, you construct a deployment architecture based on the deployment scenario specified in the requirements analysis phase. The objective is to map the logical building blocks of an application (the logical architecture) to a physical environment (a physical topology) in a way that meets the system requirements specified in the deployment scenario.

One aspect of this design is sizing the physical environment to meet load, availability, and performance requirements. The deployment architecture takes into account details of the physical topology, such as the capabilities of different computing nodes and network bandwidth, in assigning system servers and application components to the computing nodes in the environment. For more information, see "Deployment Architectures".


The logical architecture specified in the requirements analysis stage of the life cycle determines the scope of the development work needed to implement a solution.

For some solutions, development might be quite extensive, requiring you to develop new business and presentation services from scratch using J2EE components that run in an Application Server environment or Web Server environment. In other cases, it might be sufficient to customize existing system servers, such as the Portal Server, to achieve the functionality required.

In the case of solutions requiring extensive development, Java Enterprise System 2003Q4 does not provide the tools you need to program distributed components or business services. These tools are provided in Sun Java Studio, which simplifies the programming and testing of applications supported by the Java Enterprise System infrastructure.


In the prototyping phase, you prototype your deployment design by implementing the deployment architecture in a test environment. You use new application logic and server customizations from the development effort, as described above (see "Development"), to perform proof-of-concept deployment testing. This phase involves installing, configuring, and starting up distributed applications and any required infrastructure services in your test environment.

If prototype testing reveals shortcomings in your deployment architecture, you modify the architecture, prototype again, and test again. This iterative process should eventually result in a deployment architecture that is ready for deployment in a production environment.

Production Rollout

In the production rollout phase, you implement your deployment architecture in a production environment. This phase involves installing, configuring, and starting up distributed applications and any required infrastructure services in a production environment. You normally start with a limited deployment and move to organization-wide implementation. In this process, you perform trial runs, in which you apply increasing loads and stress test the system.

As part of the rollout phase you might need to perform administrative tasks such as provisioning users, implementing single sign-on, and tuning the system to meet performance objectives.

Deployment Architectures

A deployment architecture maps a logical architecture to a computing environment. The system requirements specified in the deployment scenario (as well as restrictions on the total cost of ownership or total cost of availability) affect the design of a deployment architecture, as illustrated in the following figure.

Figure 1-9  Deployment Architecture Maps Logical Architecture to Physical Topology

Diagram showing how a deployment scenario translates to a deployment architecture; the logical architecture is mapped to a physical topology taking system requirements into account.

The larger the number of system servers in the deployment scenario, and the more demanding your system requirements (the higher the end-user load, the more stringent the security and firewall requirements, the higher the required availability, and so forth), the more demanding your design is on high-power computing nodes and high network bandwidth. Where hardware is limited, or prohibitively expensive, you will have to make trade-offs between different system requirements or increase the sophistication of your design.

Because designing a deployment architecture is an inexact science, most architectures evolve in an iterative fashion. You incrementally expand an existing system, noting bottlenecks, and adjusting the hardware or modifying the architecture to remove the bottlenecks.

Production Execution

In the production execution stage of the life cycle, you run a deployed application, monitoring and optimizing its performance and upgrading the application to include new functionality.

Java Enterprise System 2003Q4 does not provide a common monitoring and management infrastructure or administration tools for managing the system as a whole. Each system component has its own administration tools for configuring, tuning, or managing its operations. The goal is to provide system-wide administration for the Java Enterprise System in the future.

Previous      Contents      Index      Next     

Copyright 2003 Sun Microsystems, Inc. All rights reserved.