Chapter 1 Introduction to Sun Java System Application Server 7, Enterprise Edition

The Sun Java™ System Application Server 7, Enterprise Edition provides a high-performance Java™ 2 Platform, Enterprise Edition (J2EE™) platform suitable for broad deployment of application services and web services. It offers a new modular architecture based on industry standard components, including proven implementations of the HTTP server infrastructure, Java Message Service (JMS), and rigorous support of the latest J2EE and web services specifications with J2EE version 1.3, Java 2 Platform, Standard Edition version 1.4, and the Java APIs for XML (JAX) from the Java Web Services Developer Pack software.

In addition, Sun Java System Application Server offers load balancing of HTTP/S and RMI/IIOP requests, and high availability of remote EJB references and HTTP sessions. For a com0plete list of features, see the Sun Java System Application Server Product Introduction.

About Application Server Instances

Application server instances form the basis of an application server deployment. Each instance has its own directory structure, configuration, and deployed applications. Each server instance also includes the J2EE platform web and EJB containers. The Sun Java System Application Server also includes a proven, high-performance HTTP server. An Object Request Broker (ORB) module enables EJB invocation using RMI-IIOP.

To access backend systems, applications can leverage J2EE connector architecture support and third-party resource adapters, either the built-in JMS provider or third-party providers, and any combination of popular third-party JDBC drivers. Access to backend systems can be managed within the scope of distributed transactions using the built-in, all-Java Transaction Manager.

The Admin Server (also called the Administration Server) is a special server instance that runs the core administration application and an SNMP agent. All remote management activity flows through the Admin Server. Both command-line and web-browser -based administrative clients access the Admin Server directly either through HTTP, or securely through HTTPS.

Web server plug-ins (such as the load balancer plug-in) enable you to deploy the Application Server behind one or more web servers housed in a demilitarized zone (DMZ) that is bracketed by one or more layers of firewalls. The plug-ins provide a means for the front-end web server tier to direct incoming HTTP and HTTPS traffic received from the Internet to one or more Application Servers housed in a back-end application server tier.

A variety of client applications can access business services deployed to the Application Server. Web service clients and browser-based clients can use either HTTP or HTTPS to access the web services, server-side end points, and J2EE web applications.

Figure 1-1 shows an application server instance in detail. The application server instance is a building block in the clustering, load balancing, and session persistence features described in About Enterprise Edition Features.

About Administrative Domains

Administrative domains enable you to define multiple, completely separate application server runtime configurations that reuse the same installation image. Each administrative domain has an Admin Server which in turn controls one or more application server instances. Figure 1-1 shows a single administrative domain.

In the tutorials, you will be working with a single administrative domain configured during installation of the product, as well as multiple server instances in a cluster.

About Enterprise Edition Features

Sun Java System Application Server Enterprise Edition 7 2004Q2 provides advanced clustering and failover technologies. These features enable you to run scalable and highly available J2EE applications.

This guide shows you how to use the Enterprise Edition features described in the following sections:

Clustering

A cluster is a group of application server instances that work together as one logical entity. Each Application Server instance in the cluster has the same configuration and the same applications deployed to it. For a detailed description of an Application Server cluster, see Chapter 2, "Clustering Scenarios".

The Application Server instances within a cluster can be hosted on different machines or on the same machine. That is, you can group application server instances across different machines into one logical cluster. For this guide, the default configuration is for two instances on the same machine.

For more information about clustering, see the Sun Java System Application Server Administration Guide.

Using clusters in Sun Java System Application Server helps you to achieve the following:

High Availability

Sun Java System Application Server provides high availability by allowing for failover protection of Application Server instances in a cluster. If one application server instance goes down, another Application Server instance will take over the sessions that were assigned to the unavailable server.

Session information is stored in the high-availability database (HADB) that is bundled with Sun Java System Application Server Enterprise Edition. For more information on the HADB, see High-Availability Database.

HTTP/S Sessions

The load balancer plug-in fails over HTTP/S connections and the associated session information to another Application Server instance if the original Application Server instance serving the session becomes unavailable. Session information is stored in the HADB, when high availability is enabled.

The load balancing plug-in keeps track of HTTP/S sessions through the following two methods:

Cluster configuration should be created in the loadbalancer.xml file. This file has to be created manually, based on the loadbalancer.xml.example file that is installed along with the load balancer plug-in. By default, the example configuration file is located in your web server’s config directory.

EJB References Within HTTP Sessions

Failover of EJB references and J2EE objects that implement the java.io.Serializable interface that are stored in HTTP Sessions is supported. For more information, see “Configuring Session Persistence” in Sun Java System Application Server Administration Guide.

Remote References of EJB and JNDI InitialContext over RMI/IIOP

To enable high availability for RMI/IIOP applications, you need to configure an IIOP cluster with designated IIOP endpoints. The ORB listeners that will be part of the IIOP cluster, are called as IIOP endpoints. IIOP endpoints are configured using the Admin Console or CLI.

When a request is received along the RMI/IIOP path, one of the available IIOP endpoints in the cluster is selected randomly by the Application Server as the primary endpoint. The other IIOP endpoints in the cluster are then designated as alternate endpoints.

If the primary endpoint becomes unavailable, the remote reference associated with the connection is failed over to one of the alternate endpoints.

An IIOP cluster can be configured using either the Admin Console or CLI. The changes are registered in the Application Server configuration file, server.xml. For a detailed description, see RMI/IIOP Clustering Scenario.

JMS connections

JMS connection failover is provided by Sun Java System Message Queue Enterprise Edition 3.5 SP1.

Scalability

Sun Java System Application Server provides high scalability for your J2EE applications by allowing for the addition of Application Server instances to a cluster, thus increasing the capacity of the system. You can add Application Server instances to a cluster without disrupting service.

The HTTP and RMI/IIOP load balancing system distributes requests to healthy Application Server instances in the cluster.

Load Balancing

The goal of load balancing is to evenly distribute the workload among multiple Sun Java System Application Server instances. Load balancing can be configured for application requests along HTTP/S and RMI/IIOP path.

HTTP Load Balancing

Sun Java System Application Server distributes incoming HTTP and HTTPS requests to Application Server instances that are configured in a cluster. Load balancing is accomplished by the bundled load balancer plug-in that is installed on a supported web server.

When a new HTTP request is sent to the load balancer plug-in, the request is forwarded to an Application Server instance based on a simple round robin scheme. Subsequent requests, with the same context-root, is assigned to the Application Server instance that initially serviced the request, based on cookies or explicit URL rewriting.


Note	The IIOP and HTTP clusters must be made up of the same Application Server instances.

To configure HTTP load balancing and failover, you need to specify the Application Server cluster to the load balancing plug-in. The configuration changes must be made in the loadbalancer.xml file. For more information on the load balancer configuration file, see Creating the loadbalancer.xml File.

You can either use the load balancer plug-in supplied with the Sun Java System Application Server, or you can use various third party hardware and software load balancers. This guide describes the bundled HTTP load balancer plug-in. For more information about load balancing, see the Sun Java System Application Server Administration Guide.

RMI/IIOP Load Balancing

Sun Java System Application Server, Enterprise Edition 7 provides load balancing of remote EJB references on the RMI/IIOP path, based on the JNDI InitialContext. A new target Application Server instance is selected, from among the configured IIOP cluster, for every new JNDI InitialContext initiated.

To enable load balancing for RMI/IIOP based requests, a few, minor code changes are required in the RMI/IIOP client application to enable load balancing. The bundled ORB provides the necessary infrastructure for load balancing.

The settings for enabling load balancing in RMI/IIOP clients varies depending on the type of client. For an example configuration, see RMI/IIOP Clustering Scenario. For detailed information on setting up various RMI/IIOP clients, see Sun Java System Application Server Developer’s Guide to Clients.

Session Persistence

Session persistence ensures that if a Sun Java System Application Server instance or machine fails, the HTTP/S or EJB session will be picked up by another server instance. Sun Java System Application Sever supports persistence of the following:

The high-availability database (HADB), bundled with the Sun Java System Application Server, functions as the persistence store. For more information on the high-availability database, see High-Availability Database.

About Session Persistence Types

Sun Java System Application Server supports three types of persistence: ha, file, and memory.

Use the Administration interface to choose the HADB persistence store. Follow these steps to set the HADB as your persistence store:

Open the Availability Service component under your server instance.

Go to the Availability Service page.

Check the Instance Level Availability box.

Click on the Save button.

Click Properties under Persistence Store Properties.

In the Name field, type store-pool-jndi-name.

In the Value field, type the JNDI name of the HADB JDBC Resource. The assumed default is jdbc/hastore.

Click on the Save button.

Go to the server instance page.

Apply Changes and restart the server.

The element hierarchy in the server.xml file looks like the following when the HADB is configured:

...

<availability-service availability-enabled="true">

<persistence-store>

</persistence-store>

</availability-service>

...

</server>

For information about how to configure the HADB persistence store, see the Administration Guide.

The file persistence type stores session information periodically to files, but you may experience loss of data when an instance becomes unavailable. The file persistence type is not supported for production environments that require failover capabilities; however it is sometimes used in development environments for testing applications.

The session-store attribute in the server.xml file determines where the SFSB state is stored if the local file system is used for SFSB state persistence. For example:

The ha session persistence is the only type covered in the exercises in this guide. For more information on configuring and using the other types of session persistence, see the Sun Java System Application Server Administration Guide.

About Session Persistence Configuration

When you install the Sun Java System Application Server and run the clsetup command, your session persistence information is configured to default values. However, you can change the default values to balance your particular needs for performance, reliability, and high availability. These options are described in the following two topics:

Setting the Persistence Scope

If you are using HADB as the persistence store, you must set the persistence scope to configure the amount of session state that should be stored. For example, every time your data is saved, or store the entire session, or store the session only if the session has been modified. You can also configure the persistence setting so that only the modified attributes of the session are stored.

session The entire session is saved every time session state is saved to the HADB.

Setting the Persistence Frequency

If you are using HADB to store session state, you can configure the frequency at which the session state is stored in the HADB database. For example, you can choose to store the session after every web request, thus providing high availability and reliability of updated session states, or you can choose to store the session after a time interval you specify, thus providing better performance.

web-method In the web-method persistence frequency, the session is stored at the end of every web request.

time-based In the time-based persistence frequency, the session state is stored at time intervals defined in the reapIntervalSeconds property of the manager-properties element in the server.xml file (for instance-level configuration) or in the sun-web.xml file (for application-level configuration).


Note	You can choose the persistence frequency for only the ha persistence type.

For more information about the various configuration options for session persistence, see “Configuring Session Persistence,” in Sun Java System Application Server Administration Guide.

About Single Sign-on Session Information

In a single application server instance, once you are authenticated by a web application, you are not required to reauthenticate individually to other web applications running on the same instance. This is called single sign-on.

In order for this feature to continue to work even when a session fails over to another instance in a cluster, single sign-on information must be persisted to the HADB. This persistence is enabled when you enable high availability for the Application Server instance and the following property is added to the virtual-server element in server.xml:

About SFSB Checkpointing

The state of an SFSB is saved to the persistent store at predefined points in its life cycle.

For SFSB checkpointing to be enabled at a given level, it must be enabled at all higher levels as well. For example, to enable SFSB checkpointing at the application level, you must also enable it at the server instance and EJB container levels.

For more information on how to configure SFSB checkpointing, see Sun Java System Application Server 7 Developer’s Guide to Enterprise JavaBeans Technology.

High-Availability Database

The high-availability database (HADB) is used to store HTTP and SFSB session information. High availability means that the system remains available despite unplanned outages caused by hardware or software failures. The HADB, a JDBC-compliant database, is based on the Always-On technology and is capable of exceeding 99.999% data availability, offering an ideal platform for delivering all types of session state persistence within a highly-loaded enterprise application server environment.

The HADB achieves this data availability through fragmentation and replication of data. All tables in the database are partitioned to create subsets of approximately the same size called fragments. This process of fragmentation is based on a hash function that fragments and evenly distributes the data among the database’s nodes. Each fragment is stored twice in the database, in mirror nodes. This ensures fault tolerance and fast recovery of data. In addition, if a node fails or is shut down, a spare node can take over until the node is active again.

The HADB stores and retrieves all state information in a separate but tightly-integrated persistent storage tier. For more information on setting up and configuring the HADB, see “Preparing for HADB Setup” in Sun Java System Application Server Installation Guide.

Tools for Configuring and Administering the Application Server

Sun Java System Application Server provides the following tools for configuring and administering the Sun Java System Application Server. You can use these tools to start and stop the server, as well as perform various other functions. Detailed steps for using some of these tools to perform specific configuration tasks are included in the tutorials.

For more information on asadmin, see “Appendix A, Using the Command Line Interface” in Sun Java System Application Server Administration Guide.

The cladmin command. The cladmin command runs certain asadmin commands simultaneously on all application server instances in a cluster. Using the cladmin command assures you that all instances in the cluster are being configured identically, so you should use cladmin, rather than asadmin, whenever possible. Not all asadmin commands are supported by cladmin.

For more information on cladmin, see “Appendix F, Using the cladmin Script for Administration” in Sun Java System Application Server Administration Guide.

For more information on Admin Console, see “Part 1, Server Basics and Administering Global Settings” in Sun Java System Application Server Administration Guide.

The clsetup command. The clsetup command allows you to easily set up a cluster, including initial configuration of the HADB database. For full instructions on the clsetup command, see the Sun Java System Application Server Installation Guide. Additionally, you should consult the manpages provided with clsetup.



Note	Some aspects of server configuration and corresponding interfaces are still undergoing change. An unstable interface may be removed and replaced with a cleaner and more stable version in a subsequent product release. Most server configuration and administrative interfaces will remain the same or change in a compatible manner; however some aspects may change incompatibly. Product documentation for future releases will clearly describe incompatible changes when they do occur.

Previous Contents Index Next
Sun Java System Application Server Enterprise Edition 7 2004Q2 Getting Started Guide