Understanding Operational Requirements

Before you begin to deploy and tune your application on the Application Server, it is important to clearly define the operational environment. The operational environment is determined by high-level constraints and requirements such as:

• Application Architecture

• Security Requirements

• Hardware Resources

Application Architecture

The J2EE Application model, as shown in the following figure, is very flexible; allowing the application architect to split application logic functionally into many tiers. The presentation layer is typically implemented using servlets and JSP technology and executes in the web container.

Figure 1–1 J2EE Application Model

Moderately complex enterprise applications can be developed entirely using servlets and JSP technology. More complex business applications often use Enterprise JavaBeans (EJB) components. The Application Server integrates the web and EJB containers in a single process. Local access to EJB components from servlets is very efficient. However, some application deployments may require EJB components to execute in a separate process; and be accessible from standalone client applications as well as servlets. Based on the application architecture, the server administrator can employ the Application Server in multiple tiers, or simply host both the presentation and business logic on a single tier.

It is important to understand the application architecture before designing a new Application Server deployment, and when deploying a new business application to an existing application server deployment.

Security Requirements

Most business applications require security. This section discusses security considerations and decisions.

User Authentication and Authorization

Application users must be authenticated. The Application Server provides three different choices for user authentication: file-based, LDAP, and Solaris.

The default file based security realm is suitable for developer environments, where new applications are developed and tested. At deployment time, the server administrator can choose between the Lightweight Directory Access Protocol (LDAP) or Solaris security realms. Many large enterprises use LDAP-based directory servers to maintain employee and customer profiles. Small to medium enterprises that do not already use a directory server may find it advantageous to leverage investment in Solaris security infrastructure.

For more information on security realms, see Chapter 9, Configuring Security, in Sun Java System Application Server Enterprise Edition 8.2 Administration Guide.

The type of authentication mechanism chosen may require additional hardware for the deployment. Typically a directory server executes on a separate server, and may also require a backup for replication and high availability. Refer to Sun Java System Directory Server documentation for more information on deployment, sizing, and availability guidelines.

An authenticated user’s access to application functions may also need authorization checks. If the application uses the role-based J2EE authorization checks, the application server performs some additional checking, which incurs additional overheads. When you perform capacity planning, you must take this additional overhead into account.

Encryption

For security reasons, sensitive user inputs and application output must be encrypted. Most business-oriented web applications encrypt all or some of the communication flow between the browser and Application Server. Online shopping applications encrypt traffic when the user is completing a purchase or supplying private data. Portal applications such as news and media typically do not employ encryption. Secure Sockets Layer (SSL) is the most common security framework, and is supported by many browsers and application servers.

The Application Server supports SSL 2.0 and 3.0 and contains software support for various cipher suites. It also supports integration of hardware encryption cards for even higher performance. Security considerations, particularly when using the integrated software encryption, will impact hardware sizing and capacity planning.

Consider the following when assessing the encryption needs for a deployment:

• What is the nature of the applications with respect to security? Do they encrypt all or only a part of the application inputs and output? What percentage of the information needs to be securely transmitted?

• Are the applications going to be deployed on an application server that is directly connected to the Internet? Will a web server exist in a demilitarized zone (DMZ) separate from the application server tier and backend enterprise systems?

  A DMZ-style deployment is recommended for high security. It is also useful when the application has a significant amount of static text and image content and some business logic that executes on the Application Server, behind the most secure firewall. Application Server provides secure reverse proxy plugins to enable integration with popular web servers. The Application Server can also be deployed and used as a web server in DMZ.

• Is encryption required between the web servers in the DMZ and application servers in the next tier? The reverse proxy plugins supplied with Application Server support SSL encryption between the web server and application server tier. If SSL is enabled, hardware capacity planning must be take into account the encryption policy and mechanisms.

• If software encryption is to be employed:

  • What is the expected performance overhead for every tier in the system, given the security requirements?

  • What are the performance and throughput characteristics of various choices?

For information on how to encrypt the communication between web servers and Application Server, please refer to Chapter 9, Configuring Security, in Sun Java System Application Server Enterprise Edition 8.2 Administration Guide.

Hardware Resources

The type and quantity of hardware resources available greatly influence performance tuning and site planning.

The Application Server provides excellent vertical scalability. It can scale to efficiently utilize multiple high-performance CPUs, using just one application server process. A smaller number of application server instances makes maintenance easier and administration less expensive. Also, deploying several related applications on fewer application servers can improve performance, due to better data locality, and reuse of cached data between co-located applications. Such servers must also contain large amounts of memory, disk space, and network capacity to cope with increased load.

The Application Server can also be deployed on large “farms” of relatively modest hardware units. Business applications can be partitioned across various server instances. Using one or more external load balancers can efficiently spread user access across all the application server instances. A horizontal scaling approach may improve availability, lower hardware costs and is suitable for some types of applications. However, this approach requires administration of more application server instances and hardware nodes.

Administration

A single Application Server installation on a server can encompass multiple instances. A group of one or more instances that are administered by a single Administration Server is called a domain. Grouping server instances into domains permits different people to independently administer the groups.

You can use a single-instance domain to create a “sandbox” for a particular developer and environment. In this scenario, each developer administers his or her own application server, without interfering with other application server domains. A small development group may choose to create multiple instances in a shared administrative domain for collaborative development.

In a deployment environment, an administrator can create domains based on application and business function. For example, internal Human Resources applications may be hosted on one or more servers in one Administrative domain, while external customer applications are hosted on several administrative domains in a server farm.

The Application Server supports virtual server capability for web applications. For example, a web application hosting service provider can host different URL domains on a single Application Server process for efficient administration.

For detailed information on administration, see Sun Java System Application Server Enterprise Edition 8.2 Administration Guide.