Previous Contents Index Next |
Sun Java System Application Server Standard and Enterprise Edition 7 2004Q2 Update 2 System Deployment Guide

> ## Chapter 1
> Overview of Deployment

> This chapter describes what you need to know to set up your Sun Java™ System Application Server, Standard and Enterprise Edition the way that best meets your requirements.

> This chapter contains the following sections:

> - About Deployment
> - Phases of the Deployment Process
> - Understanding Session Persistence

> ##

> About Deployment

> Successful deployment of complex applications on the Application Server requires that you consider practical aspects of the environment. In general, you should begin by assessing your goals for performance and availability. You should then plan the hardware, network, and resource configuration accordingly.

> Here are the important goals that you should consider while planning the deployment:

> - Throughput
> - Response time
> - Availability

> You gather information related to these goals and then analyze it to establish a processing threshold for your site.

> In considering performance, consider both—application server instances and the High Availability Database (HADB).

> The HADB uses the patented Always-On technology and works as the persistence store to provide high availability for web applications. It offers an ideal platform for delivering all types of session state persistence within an enterprise application server environment. For more information on configuring HADB, see Sun Java™ System Application Server Administration Guide.

> ### Throughput

> Throughput is the number of requests that Sun Java System Application Server can service in a given time period. For example requests per minute. You should estimate the maximum number of operations and transactions that the system needs to perform under peak load conditions. It is also useful to determine the operations and transactions per minute under steady state (typical) load conditions. This will help you to determine the network bandwidth needed, the number of application server instances required, and the number of HADB nodes required.

> You should also consider plans to increase capacity in the future.

> ### Response Time

> You should determine the acceptable response time from the system under heavy load. This has a direct bearing on hardware capacity planning.

> ### Availability

> Will your system be running 24 x 7? If there is a failure in the system, will your users notice it? Do you have a subset of applications that need to be available all the time whereas other applications will run only periodically? The answers to these questions determine your availability needs. You will have to build redundancy into the system to meet availability needs and avoid single points of failure.

> ##

> Phases of the Deployment Process

> The deployment process primarily comprises the following three phases, each one building on the previous one.

> - Planning Your Environment
> - Selecting a Topology
> - Running Tests

> ### Planning Your Environment

> In the first phase of planning your deployment, determine how the Application Server fits into your overall enterprise. Central to planning your environment is the assessment of the goals discussed in About Deployment. You should establish performance goals related to throughput and response time. You also determine your availability goals.

> Based on the performance and availability goals, you consider the network requirements and the infrastructure requirements including hardware, storage, and network requirements.

> You may realize during this process that you should change the structure and components of your network to accommodate the needs of your Application Server. If your network structure cannot be changed at this time, use the environment planning process to determine how you can best deploy Application Server to fit in with your existing network.

> For more details on this phase of the planning process, see Chapter 2, "Planning your Environment."

> ### Selecting a Topology

> Once you have determined the performance, availability, network, and infrastructure requirements, you then select a topology that best meets your performance needs. A topology is the schematic arrangement of Application Server components and the communication flow between these components. The two recommended topologies (and their variations) are:

> - Co-located: The application server instance and the HADB node are on the same machine.
> - Separate Tier: The application server instance and the HADB node are on different machines.

> For more details on these topologies, see Chapter 3, "Selecting a Topology."

> ### Running Tests

> Once you configure the Application Server, you should deploy a representative sampling of applications and run tests to check whether your performance goals are met. If you are not able to reach your stated performance goals, use this phase to identify bottlenecks, fine-tune the system, and improve performance.

> As implementation of this phase is completely dependent on your particular environment, it is not covered in this guide.

> ##

> Understanding Session Persistence

> J2EE applications typically have significant amounts of session state data. A web shopping cart is the classic example of session state. Also, an application can cache frequently-needed data in the session object. In fact, almost all applications with significant user interactions need to maintain session state. Both HTTP sessions and stateful session beans (SFSBs) have session state data.

> While session state is not as important as transactional state stored in a database, preserving session state across server failures can be important to end users.The Application Server provides the capability to save, or persist, this session state in a repository. If the application server instance that is hosting the user session experiences a failure, the session state can be recovered. The session can continue without loss of information.

> Sun Java System Application Server supports the following types of session persistence stores:

> - High Availability (HA)
> - Memory
> - File

> When you set the persistence type to HA, Application Server uses HADB as the persistence store for both HTTP and SFSB sessions. With Memory persistence, the state is always kept in memory and does not survive failure. With File persistence, the Application Server serializes session objects and stores them to the file system location specified by session manager properties. For SFSBs, if HA is not specified, the Application Server stores state information in the session-store sub-directory of this location.

> Checking an SFSB’s state for changes that need to be saved is called checkpointing. When enabled, checkpointing generally occurs after any transaction involving the SFSB is completed, even if the transaction rolls back. For more information on enabling SFSB checkpointing, see the Sun Java System Application Server Developer’s Guide to Enterprise JavaBeans Technology.

> Apart from the number of requests being served by the Application Server, the session persistence configuration settings affect the number of requests received per minute by HADB, as well as the session information in each request.

> The persistence settings can be defined for each application server instance. However, all application server instances in a single cluster must have the same persistence configuration. If you have deployed more than one Application Server cluster, it is not necessary for all clusters to have the same persistence configuration settings.

> For more information on configuring session persistence and its effect on performance, see HTTP Session Persistence Frequency.

> Note | Use the command cladmin to ensure that the session persistence settings are homogeneous for all instances in a cluster. For more information on using the cladmin command, see Sun Java System Application Server Administration Guide.

> Previous Contents Index Next

> Copyright 2005 Sun Microsystems, Inc. All rights reserved.