| Oracle GlassFish Server Deployment Planning Guide Release 3.1.2 Part Number E24931-01 |
|
|
View PDF |
| Oracle GlassFish Server Deployment Planning Guide Release 3.1.2 Part Number E24931-01 |
|
|
View PDF |
Oracle GlassFish Server provides a robust platform for the development, deployment, and management of Java EE applications. Key features include scalable transaction management, web services performance, clustering, security, and integration capabilities.
The following topics are addressed here:
GlassFish Server implements Java platform, Enterprise Edition (Java EE) 6 technology. The Java EE platform is a set of standard specifications that describe application components, APIs, and the runtime containers and services of an application server.
Java EE applications are made up of components such as JavaServer Pages (JSP), Java servlets, and Enterprise JavaBeans (EJB) modules. These components enable software developers to build large-scale, distributed applications. Developers package Java EE applications in Java Archive (JAR) files (similar to zip files), which can be distributed to production sites. Administrators install Java EE applications onto GlassFish Server by deploying Java EE JAR files onto one or more server instances (or clusters of instances).
Each server instance includes two containers: web and EJB. A container is a runtime environment that provides services such as security and transaction management to Java EE components. Web components, such as Java Server Pages and servlets, run within the web container. Enterprise JavaBeans run within the EJB container.
The Java EE platform provides services for applications, including:
Naming - A naming and directory service binds objects to names. A Java EE application can locate an object by looking up its Java Naming and Directory Interface (JNDI) name.
Security - The Java Authorization Contract for Containers (JACC) is a set of security contracts defined for the Java EE containers. Based on the client's identity, containers can restrict access to the container's resources and services.
Transaction management - A transaction is an indivisible unit of work. For example, transferring funds between bank accounts is a transaction. A transaction management service ensures that a transaction is either completed, or is rolled back.
Message Service - Applications hosted on separate systems can communicate with each other by exchanging messages using the Java Message Service (JMS). JMS is an integral part of the Java EE platform and simplifies the task of integrating heterogeneous enterprise applications.
Clients can access a Java EE application as a remote web service in addition to accessing it through HTTP, RMI/IIOP, and JMS. Web services are implemented using the Java API for XML-based web services (JAX-WS). A Java EE application can also act as a client to web services, which would be typical in network applications.
Web Services Description Language (WSDL) is an XML format that describes web service interfaces. Web service consumers can dynamically parse a WSDL document to determine the operations a web service provides and how to execute them. GlassFish Server distributes web services interface descriptions using a registry that other applications can access through the Java API for XML Registries (JAXR).
Clients can access Java EE applications in several ways. Browser clients access web applications using hypertext transfer protocol (HTTP). For secure communication, browsers use the HTTP secure (HTTPS) protocol that uses secure sockets layer (SSL).
Rich client applications running in the Application Client Container can directly lookup and access Enterprise JavaBeans using an Object Request Broker (ORB), Remote Method Invocation (RMI) and the internet inter-ORB protocol (IIOP), or IIOP/SSL (secure IIOP). They can access applications and web services using HTTP/HTTPS, JMS, and JAX-WS. They can use JMS to send messages to and receive messages from applications and message-driven beans.
Clients that conform to the Web Services-Interoperability (WS-I) Basic Profile can access Java EE web services. WS-I is an integral part of the Java EE standard and defines interoperable web services. It enables clients written in any supporting language to access web services deployed to GlassFish Server.
The best access mechanism depends on the specific application and the anticipated volume of traffic. GlassFish Server supports separately configurable listeners for HTTP, HTTPS, JMS, IIOP, and IIOP/SSL. You can set up multiple listeners for each protocol for increased scalability and reliability.
Java EE applications can also act as clients of Java EE components such as Enterprise JavaBeans modules deployed on other servers, and can use any of these access mechanisms.
On the Java EE platform, an external system is called a resource. For example, a database management system is a JDBC resource. Each resource is uniquely identified and by its Java Naming and Directory Interface (JNDI) name. Applications access external systems through the following APIs and components:
Java Database Connectivity (JDBC) - A database management system (DBMS) provides facilities for storing, organizing, and retrieving data. Most business applications store data in relational databases, which applications access via JDBC. GlassFish Server includes the Java DB database for use sample applications and application development and prototyping, though it is not suitable for deployment. GlassFish Server provides certified JDBC drivers for connecting to major relational databases. These drivers are suitable for deployment.
Java Message Service - Messaging is a method of communication between software components or applications. A messaging client sends messages to, and receives messages from, any other client via a messaging provider that implements the Java Messaging Service (JMS) API. GlassFish Server includes a high-performance JMS broker, GlassFish Server Message Queue.
Java EE Connectors - The Java EE Connector architecture enables integrating Java EE applications and existing Enterprise Information Systems (EIS). An application accesses an EIS through a portable Java EE component called a connector or resource adapter, analogous to using JDBC driver to access an RDBMS. Resource adapters are distributed as standalone Resource Adapter Archive (RAR) modules or included in Java EE application archives. As RARs, they are deployed like other Java EE components. GlassFish Server includes evaluation resource adapters that integrate with popular EIS.
JavaMail - Through the JavaMail API, applications can connect to a Simple Mail Transport Protocol (SMTP) server to send email and to an IMAP or POP3 server to receive email.
This section describes the components in GlassFish Server.
The following topics are addressed here:
The administration tools, such as the browser-based Administration Console, communicate with the domain administration server (DAS), which in turn communicates with the server instances.
A server instance is a GlassFish Server running in a single Java Virtual Machine (JVM) process. GlassFish Server is certified with Java platform, Standard Edition (Java SE) 6.
It is usually sufficient to create a single server instance on a machine, since GlassFish Server and accompanying JVM are both designed to scale to multiple processors. However, it can be beneficial to create multiple instances on one machine for application isolation and rolling upgrades. In some cases, a large server with multiple instances can be used in more than one administrative domain. The administration tools makes it easy to create, delete, and manage server instances across multiple machines.
An administrative domain (or simply domain) is a group of server instances that are administered together. A server instance belongs to a single administrative domain. The instances in a domain can run on different physical hosts.
You can create multiple domains from one installation of GlassFish Server. By grouping server instances into domains, different organizations and administrators can share a single GlassFish Server installation. Each domain has its own configuration, log files, and application deployment areas that are independent of other domains. Changing the configuration of one domain does not affect the configurations of other domains. Likewise, deploying an application on one domain does not deploy it or make it visible to any other domain.
Note:
All hosts in a domain on which the DAS and GlassFish Server instances are running must have the same operating system.
A domain has one Domain Administration Server (DAS), a specially designated GlassFish Server instance that hosts the administrative applications. The DAS authenticates the administrator, accepts requests from administration tools, and communicates with server instances in the domain to carry out the requests.
The administration tools are the asadmin command-line tool and the browser-based Administration Console. GlassFish Server also provides a RESTful API for server administration. The administrator can view and manage a single domain at a time, thus enforcing secure separation.
The DAS is also sometimes referred to as the admin server or default server. It is referred to as the default server because it is the default target for some administrative operations.
Since the DAS is a GlassFish Server instance, it can also host Java EE applications for testing purposes. However, do not use it to host production applications. You might want to deploy applications to the DAS, for example, if the clusters and instances that will host the production application have not yet been created.
The DAS keeps a repository containing the configuration of its domain and all the deployed applications. If the DAS is inactive or down, there is no impact on the performance or availability of active server instances, however administrative changes cannot be made. In certain cases, for security purposes, it may be useful to intentionally stop the DAS process, for example to reboot the host operating system to install a kernel patch or a hardware upgrade.
Administrative commands are provided to backup and restore the domain configuration and applications. With the standard backup and restore procedures, you can quickly restore working configurations. If the DAS host fails, you must create a new DAS installation to restore the previous domain configuration. For instructions, see "Administering Domains" in Oracle GlassFish Server Administration Guide.
A cluster is a named collection of server instances that share the same applications, resources, and configuration information. You can group server instances on different machines into one logical cluster and administer them as one unit. You can easily control the lifecycle of a multi-machine cluster with the DAS.
Clusters enable horizontal scalability, load balancing, and failover protection. By definition, all the instances in a cluster have the same resource and application configuration. When a server instance or a machine in a cluster fails, the load balancer detects the failure, redirects traffic from the failed instance to other instances in the cluster, and recovers the user session state. Since the same applications and resources are on all instances in the cluster, an instance can failover to any other instance in the cluster.
Note:
All hosts in a cluster on which the DAS and GlassFish Server instances are running must have the same operating system.
Clusters, domains, and instances are related as follows:
An administrative domain can have zero or more clusters.
A cluster has one or more server instances.
A cluster belongs to a single domain.
A named configuration is an abstraction that encapsulates GlassFish Server property settings. Clusters and stand-alone server instances reference a named configuration to get their property settings. With named configurations, Java EE containers' configurations are independent of the physical machine on which they reside, except for particulars such as IP address, port number, and amount of heap memory. Using named configurations provides power and flexibility to GlassFish Server administration.
To apply configuration changes, you simply change the property settings of the named configuration, and all the clusters and stand-alone instances that reference it pick up the changes. You can only delete a named configuration when all references to it have been removed. A domain can contain multiple named configurations.
GlassFish Server comes with a default configuration, called default-config. The default configuration is optimized for developer productivity.
You can create your own named configuration based on the default configuration that you can customize for your own purposes. Use the Administration Console and asadmin command line utility to create and manage named configurations.
The load balancer distributes the workload among multiple physical machines, thereby increasing the overall throughput of the system. The GlassFish Server includes the load balancer plug-ins for Oracle iPlanet Web Server, Oracle HTTP Server, Apache Web Server, and Microsoft Internet Information Server.
The load balancer plug-in accepts HTTP and HTTPS requests and forwards them to one of the GlassFish Server instances in the cluster. Should an instance fail, become unavailable (due to network faults), or become unresponsive, requests are redirected to existing, available machines. The load balancer can also recognize when a failed instance has recovered and redistribute the load accordingly.
For simple stateless applications, a load-balanced cluster may be sufficient. However, for mission-critical applications with session state, use load balanced clusters with replicated session persistence.
To setup a system with load balancing, in addition to GlassFish Server, you must install a web server and the load-balancer plug-in. Then you must:
Create GlassFish Server clusters that you want to participate in load balancing.
Deploy applications to these load-balanced clusters.
Server instances and clusters participating in load balancing have a homogenous environment. Usually that means that the server instances reference the same server configuration, can access the same physical resources, and have the same applications deployed to them. Homogeneity enables configuration consistency, and improves the ability to support a production deployment.
Use the asadmin command-line tool to create a load balancer configuration, add references to clusters and server instances to it, enable the clusters for reference by the load balancer, enable applications for load balancing, optionally create a health checker, generate the load balancer configuration file, and finally copy the load balancer configuration file to your web server config directory. An administrator can create a script to automate this entire process.
For more details and complete configuration instructions, see "Configuring HTTP Load Balancing" in Oracle GlassFish Server High Availability Administration Guide.
Java EE applications typically have significant amounts of session state data. A web shopping cart is the classic example of a 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 a session state. Both HTTP sessions and stateful session beans (SFSBs) have session state data.
While the session state is not as important as the transactional state stored in a database, preserving the session state across server failures can be important to end users. GlassFish Server provides the capability to save, or persist, this session state in a repository. If the GlassFish 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.
GlassFish Server supports the following session persistence types:
Memory
Replicated
File
Coherence*Web
With memory persistence, the state is always kept in memory and does not survive failure. With replicated persistence, GlassFish Server uses other server instances in the cluster as the persistence store for both HTTP and SFSB sessions. With file persistence, GlassFish Server serializes session objects and stores them to the file system location specified by session manager properties. For SFSBs, if replicated persistence is not specified, GlassFish Server stores state information in the session-store subdirectory of this location. For more information about Coherence*Web, see Using Coherence*Web with GlassFish Server.
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 developing stateful session beans, see "Using Session Beans" in Oracle GlassFish Server Application Development Guide. For more information on enabling SFSB failover, see "Stateful Session Bean Failover" in Oracle GlassFish Server High Availability Administration Guide.
Apart from the number of requests being served by GlassFish Server, the session persistence configuration settings also affect the session information in each request.
For more information on configuring session persistence, see "Configuring High Availability Session Persistence and Failover" in Oracle GlassFish Server High Availability Administration Guide.
With IIOP load balancing, IIOP client requests are distributed to different server instances or name servers. The goal is to spread the load evenly across the cluster, thus providing scalability. IIOP load balancing combined with EJB clustering and availability features in GlassFish Server provides not only load balancing but also EJB failover.
There are two steps to IIOP failover and load balancing. The first step, bootstrapping, is the process by which the client sets up the initial naming context with one ORB in the cluster. The client attempts to connect to one of the IIOP endpoints. When launching an application client using the appclient script, you specify these endpoints using the -targetserver option on the command line or target-server elements in the sun-acc.xml configuration file. The client randomly chooses one of these endpoints and tries to connect to it, trying other endpoints if needed until one works.
The second step concerns sending messages to a specific EJB. By default, all naming look-ups, and therefore all EJB accesses, use the cluster instance chosen during bootstrapping. The client exchanges messages with an EJB through the client ORB and server ORB. As this happens, the server ORB updates the client ORB as servers enter and leave the cluster. Later, if the client loses its connection to the server from the previous step, the client fails over to some other server using its list of currently active members. In particular, this cluster member might have joined the cluster after the client made the initial connection.
When a client performs a JNDI lookup for an object, the Naming Service creates an InitialContext (IC) object associated with a particular server instance. From then on, all lookup requests made using that IC object are sent to the same server instance. All EJBHome objects looked up with that InitialContext are hosted on the same target server. Any bean references obtained henceforth are also created on the same target host. This effectively provides load balancing, since all clients randomize the list of live target servers when creating InitialContext objects. If the target server instance goes down, the lookup or EJB method invocation will failover to another server instance.
Adding or deleting new instances to the cluster does not update the existing client's view of the cluster. You must manually update the endpoints list on the client side.
The GlassFish Server Message Queue (Message Queue) provides reliable, asynchronous messaging for distributed applications. Message Queue is an enterprise messaging system that implements the Java Message Service (JMS) standard. Message Queue provides messaging for Java EE application components such as message-driven beans (MDBs).
GlassFish Server implements the Java Message Service (JMS) API by integrating Message Queue into GlassFish Server. GlassFish Server includes the Enterprise version of Message Queue which has failover, clustering and load balancing features.
For basic JMS administration tasks, use the GlassFish Server Administration Console and asadmin command-line utility.
For advanced tasks, including administering a Message Queue cluster, use the tools provided in the as-install/mq/bin directory. For details about administering Message Queue, see the Oracle GlassFish Server Message Queue Administration Guide.
For information on deploying JMS applications and Message Queue clustering for message failover, see Planning Message Queue Broker Deployment.
The following procedure lists the major tasks for configuring GlassFish Server for high availability. The procedure also provides cross-references to detailed instructions for performing each task.
Determine your requirements and goals for performance and QoS.
For more information, see the following documentation:
Size your system.
For more information, see Design Decisions.
Install GlassFish Server and related subcomponents such as a web server.
For more information, see the following documentation:
Installation guides for related subcomponents, for example, Oracle iPlanet Web Server 7.0.9 Installation and Migration Guide
If you plan to administer your clusters centrally, set up secure shell (SSH) for centralized administration.
For more information, see "Setting Up SSH for Centralized Administration" in Oracle GlassFish Server High Availability Administration Guide.
Configure domains, nodes, clusters, GlassFish Server instances, and virtual servers as required.
For more information, see the following documentation:
"Administering Domains" in Oracle GlassFish Server Administration Guide
"Administering GlassFish Server Nodes" in Oracle GlassFish Server High Availability Administration Guide
"Administering GlassFish Server Clusters" in Oracle GlassFish Server High Availability Administration Guide
"Administering GlassFish Server Instances" in Oracle GlassFish Server High Availability Administration Guide
"Administering Virtual Servers" in Oracle GlassFish Server Administration Guide
Configure your load balancer.
If you are using a web server for load balancing, configure the web server and Load Balancer Plugin as follows:
Configure the web server software for load balancing.
Install the Load Balancer Plugin.
For more information, see "Installing the Loadbalancer Plug-In" in Oracle GlassFish Server High Availability Administration Guide.
Configure the Load Balancer Plugin.
For more information, see "Configuring HTTP Load Balancing" in Oracle GlassFish Server High Availability Administration Guide.
For more information, see the following documentation:
"Configuring Oracle iPlanet Web Server" in Oracle GlassFish Server High Availability Administration Guide
"Configuring Apache HTTP Server" in Oracle GlassFish Server High Availability Administration Guide
"Configuring Microsoft IIS" in Oracle GlassFish Server High Availability Administration Guide
"Configuring Oracle HTTP Server" in Oracle GlassFish Server High Availability Administration Guide
If you are using the Apache Tomcat Connector mod_jk for load balancing, configure mod_jk.
For more information, see "Administering mod_jk" in Oracle GlassFish Server Administration Guide.
Configure the web container and EJB container for replicated session persistence.
For more information, see "Configuring High Availability Session Persistence and Failover" in Oracle GlassFish Server High Availability Administration Guide.
If you are using messaging extensively, configure Java Message Service (JMS) clusters for failover .
For more information, see the following documentation:
"Configuring Java Message Service High Availability" in Oracle GlassFish Server High Availability Administration Guide
Deploy applications and configure them for high availability and session failover.
For more information, see the Oracle GlassFish Server Application Deployment Guide.
|
 Copyright © 2012, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|
