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
Distributed Enterprise Application Architecture
Distributed Service Infrastructure
The Java Enterprise System
Application Life-Cycle Concepts

---

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:

Supports high transaction throughput
Serves large populations of end users
Provides high availability
Performs complex functions
Supports secure access and communications
Supports dynamic upgrades of features or functionality

Architectural Model

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

Client tier – the front-end user interface
Presentation tier – the formatting and presentation of data
Business logic tier – the logic that manipulates data
Data tier – the back-end data storage

The architectural model is illustrated in the following figure.

Figure 1-1  Architectural Model for Distributed Enterprise Applications

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:

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 logic 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 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 idea is to run distributed application components on the computing nodes best suited to their individual computing requirements and best suited to maximizing network bandwidth.

The mapping of application components to a hardware environment depends on many factors: the speed and power of the different computers, the speed and bandwidth of network links, security and firewall considerations, and the need to replicate components for failover (high availability) and load balancing (scalability). The mapping you choose also depends upon the sizing, performance, and overall cost requirements of a particular solution.

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

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

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

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:

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 the basic networking support for communication between distributed application components running on different computing nodes. this layer includes 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 access to and storage of both static data (such as user, directory, or configuration information) and dynamic application data (information that is frequently being updated).
Messaging.    Provides the 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 the support required by any distributed component model, such as the CORBA or J2EE 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 MDB containers in an application server or web server.
Security and policy.    Provides the support for secure transmission of data and secure access to application resources. These services include support for policies that govern group access to distributed resources, as well as single sign-on capabilities. Single sign-on allows a user’s identity to be known by all application components (J2EE components, business services, and web services) in a distributed 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 email 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.

---

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

The Java Enterprise System includes two main component types:

Discrete software servers (system servers) that provide services at various levels within the distributed service infrastructure. These service providers are based on the client-server model (a multi-threaded server process that supports a large number of clients). Some of the system components in this category include their own clients.
Sun Cluster, which provides high availability and scalability for the system as a whole. Cluster software is based on a peer-to-peer service model (the software is both server and client to other peers). As shown in Figure 1-5, Cluster services span all the infrastructure services provided by the Java Enterprise System.

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:

System services subcomponents
Support services subcomponents
Shared components

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

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:

Connection services depend upon network transport services and might also require middleware messaging services.
Security services typically depend upon identity and policy services, as well as persistence services.
Resource manager services depend upon platform services.

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:

A messaging protocol (normally conforming to an industry standard) by which clients access the server (normally conforms to an industry standard)
An application programming interface (API) by which you can customize the server). Customization can be an important aspect of deploying a business solution.

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	Protocols	Customization API
Application Server	RMI (J2EE), HTTP/HTTPS	No
Calendar Server	HTTP/HTTPS, Web Calendar Access Protocol (WCAP)	Yes
Directory Proxy Server	LDAP, Directory Service Markup Language (DSML), version 2	Yes
Directory Server	LDAP	No
Identity Server	HTTP/HTTPS	Yes
Instant Messaging	HTTP/HTTPS, TCP	Yes
Message Queue	JMS, HTTP/HTTPS, TCP	No
Messaging Server	SMTP, IMAP, POP3, HTTP, LMTP	Yes
Portal Server	HTTP/HTTPS	Yes
Portal Server, Secure Remote Access	HTTP/HTTPS	Yes
Web Server	HTTP/HTTPS	Yes

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.

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

Requirements Analysis
Deployment
Production Execution

Figure 1-7  Application Life-Cycle Stages

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

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 operating system platforms that must be supported
Load condition requirements (the number of concurrent end users that the application must support, and the level of performance required)
Security requirements
Application availability requirements
Seviceability requirements (system upgrade requirements)
Latent capacity requirements

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.

Deployment

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
Deployment architectures
Reference deployment architectures

Overview of the Deployment Process

The deployment process consists of the following general phases:

Deployment design
Development
Prototype testing
Production rollout

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".

Development

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.

Prototyping

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

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.