In This Chapter
WebLogic Server, which is the nucleus of the BEA WebLogic Platform, is a very scalable, performance-proven and battle-tested J2EE 1.3–compliant application server. To scale to your business needs and also address the features of the J2EE specification you need to leverage, BEA provides three editions of WebLogic Server—WebLogic Express, WebLogic Server Advantage, and the WebLogic Server Premium Edition.
Because each WebLogic Server edition is targeted at supporting different types of J2EE applications, selecting which WebLogic Server edition is best aligned with your needs should be a prerequisite to any WebLogic Server evaluation/test-drive or final purchase.
Deciding which WebLogic Server edition you need requires a due diligence exercise on your part, which should begin with and be driven by understanding your business solution requirements and then transforming them into technical/integration design and operational requirements. For example
Business solution requirements—. Does your solution purely involve serving dynamic content and data from a repository to Web and wireless applications?
Technical design—. Which J2EE components does your solution really need to leverage—Servlets, JavaServer Pages, or EJBs?
Integration requirements—. Does your solution require bi-directional interoperability with other information systems within your enterprise?
Operational requirements—. How reliable, highly available, or scalable does your solution need to be?
Because there is a high degree of probability for business requirements and technical design to evolve throughout a project lifecycle, you will have to ensure your deployment platform (WebLogic Server edition) can accommodate that change. This can be validated through reviewing the J2EE application support each WebLogic Server edition provides, which is discussed in the following sections.
BEA WebLogic Express is primarily a platform suited for supporting Web and wireless applications that only require dynamic content presentation with database access support.
The core features of the WebLogic Express include the following:
A built-in high performance Web server to manage HTTP(S) connections.
Third-party Web server interoperability, which is supported through WebLogic plug-ins (Apache, iPlanet, and Microsoft IIS).
Note
The WebLogic plug-ins provide a means to leverage existing investments in Web server technologies. For example, if you have an iPlanet Web server that you use to serve static content, the WebLogic plug-ins can be used to redirect or even load balance those incoming HTTP/HTTPS requests bound for the WebLogic Server, thus enabling you to preserve your existing Web infrastructure.
A fully certified J2EE 1.3 application runtime environment for JavaServer Pages and Servlets, also known as the Web Container.
Support for all leading operating systems and databases.
A Web-based extensible management console.
A new security model where you can easily plug in third-party security solutions.
To implement a scalable and load-balanced deployment architecture, WebLogic Express can alternatively be utilized to front-end the presentation logic for a WebLogic Platform deployment model.
The Advantage Edition is primarily positioned for business solutions that require a standalone, fully J2EE-compliant application server. In addition to the features present in the WebLogic Express edition of WebLogic Server, the Advantage Edition also includes support for EJBs, enterprise messaging via a unified Java Messaging Service (JMS) , distributed transaction management using the two-phase commit transaction protocol, multi-channel client support, and Web Services.
The flagship of the WebLogic editions is the WebLogic Server Premium Edition, which is the most powerful and functional J2EE application server on the market. This infrastructure platform is designed to service enterprise mission-critical, large scale, distributed applications that demand the highest levels of availability. The Premium Edition also provides sophisticated clustering, caching, enterprise messaging, and distributed transaction management, which can optimally scale to any high-volume real-time transaction processing and large-scale messaging demands.
The core features of the Premium Edition offer all the features found in the Advantage Edition, plus the following:
Clustering across multiple homogeneous or heterogeneous hardware servers or large multi-CPU servers
Full administration of a distributed WebLogic cluster
Load-balancing and failover capabilities on the Web tier
Component load-balancing and failover
Component, JavaServer Page results and page caching
High throughput and highly available messaging (JMS)
WebLogic Server is a very scalable application server that can be configured to meet the demands of any J2EE application scenario. However, before you can install and start using WebLogic Server, you should be aware of the hardware system requirements required to install WebLogic Server, as well as the new WebLogic Server licensing model that has been implemented.
BEA states a few minimum system and software requirements that need to be satisfied for the target hardware system, as described in Table 10.1. In practice some of these minimum requirements will cause you to experience poor performance, if taken verbatim. So wherever possible in Table 10.1, an experienced recommendation will be suggested with the BEA guidelines.
Table 10.1. The Recommended System and Software Requirements for WebLogic Server
System/Software Requirements | Minimum and Recommended Requirements |
|---|---|
WebLogic Server is certified for most platforms and operating systems, for example Sun Microsystems with Solaris 8 and Intel with Windows 2000 Professional, Server and Advanced Server. You can reference all the BEA certified. platforms at the following URL: http://e-docs.bea.com/wls/certifications/certifications/index.html. This page also includes the recommended Java runtime environment versions and other prerequisites or recommendations, such as operating system patches, kernel configuration values, and performance packs. | |
BEA recommends a minimum of 128 MB of RAM for Unix and Windows based system. In reality, you will be running other applications in conjunction with WebLogic Server, and hence will incur a great deal of memory paging and swapping if you do not have enough memory. Also, the more memory you have, the faster the JVM will operate as more java classes can be maintained in the JVM memory (heap). So from an experienced perspective, and in recognition that memory is currently very cheap, you should aim for a minimum of 256MB RAM and an optimal of 512MB RAM for a standalone development environment. | |
BEA recommends a single Pentium 200MHz or higher processor. From an experienced perspective, you should aim to run WebLogic Server with a system that has at a minimum a Pentium II 400MHz processor. It is unbelievable how much an extra 200Mhz makes a difference in terms of performance. In general, you should take the approach of running WebLogic Server on the fastest processor you can possibly get your hands on. | |
For Windows-based systems, BEA recommends approximately 215MB of free storage and about 140MB of temporary storage. For Unix-based systems, BEA recommends approximately 175MB of free storage and about 140MB of temporary storage. Temporary storage is required for the installer program to unpack the installation files. From an experienced perspective, the actual free storage you need is determined by the size of your application deployment files, potential service packs you may need to install, WebLogic Server files, and any additional disk space required by supporting applications or components. For this reason, always ensure you have the capability to add disk storage space to your system in a very scalable manner. | |
As stated in the previous section, the Sun JDK 1.3.1_02 is bundled with WebLogic Server and is installed by default on your system. From an experienced perspective, you should consider using the JRockit JVM if you intend to deploy real-time transaction processing and mission critical J2EE Applications on Microsoft Windows or Red Hat Linux operating systems. | |
You will need a Java-compliant Web browser to support the WebLogic Administration Console, such as Microsoft Internet Explorer 5.x or Netscape 4.7x. |
In previous versions of WebLogic Server, a 30-day evaluation license was provided by default. Any extensions to the 30-day license required the involvement of a local BEA sales account manager. This evaluation licensing model was not viable for most organizations that were assessing the viability of WebLogic Server as a platform for their J2EE applications. Because mastering J2EE application development, deployment, and administration of WebLogic Server is not an easy exercise to grasp within 30 days, the evaluation license was a very painful experience for developers, who would continuously have to turn back their system clocks or re-install WebLogic Server.
BEA has recognized that having the best application server on the market is sometimes not enough to increase market share in the infrastructure space. There are many factors that contribute to being a successful application infrastructure company including having an experienced skill base. To the delight of all the global WebLogic developers, BEA is extending its evaluation license to 90 days, with access for up to 20 client connections. All production WebLogic Platform implementations will, however, incur a licensing cost. Also, if you do have a WebLogic Server production license, you can request developer licenses for your developers, which they can use at no cost to prepare their J2EE applications for deployment to a production and licensed WebLogic Server environment.
Note
A production license allows unlimited connections and development for an unrestricted period of time, for a specific IP address.
The motivation behind this licensing model is to increase the WebLogic Server skill base through development exposure and hence increase adoption in the application infrastructure market space.
In previous versions of WebLogic Server, you were required to download a Package installer program from the BEA Web site, a standalone installation program that contained all of the WebLogic Server software components (server and server samples). This method of downloading and installing the WebLogic Server product still exists, now includes WebLogic Workshop, and is approximately 150MB in size.
To comply with a uniform and flexible installation procedure for the WebLogic Platform, BEA now also offers the Net Installer download and installation option. This option funnels the installation process for WebLogic Server (WLS), WebLogic Integration (WLI), WebLogic Portal (WLP), and WebLogic Workshop products through a single, lighter setup program, as opposed to disparate heavyweight installer programs for each of the WebLogic products.
The following sections provide a step-by-step guide to the installation and configuration of WebLogic Server on a Windows 2000 system using the new Net Installer option.
Because the Net Installer is an executable file (approximately 20MB), you need to download the executable to a selected installation area on your hard drive from the BEA Download Center at the following URL:
http://commerce.bea.com/downloads/weblogic_platform.jsp
Caution
You should ensure you have a high speed Internet connection for the entire installation process using the Net Installer option.
Before you can download any product from BEA Systems, you will first be asked to log in or register. The registration process requires you to complete a user profile about yourself. After the Net Installer has been downloaded, execute the program. In the displayed Welcome screen, click Next and then in the BEA License Agreement screen, accept the terms of the license, and click Next to start the installation process.
In the Choose BEA Home Directory screen shown in Figure 10.1, select an existing directory or create a new BEA Home directory, which will form the root or central support directory for common files that are used by the WebLogic Platform products installed on your system.
In most cases, the default name of “BEA” should suffice. However, you can enter any name for the BEA Home directory that is compliant with your internal naming standards for software directories. After you have entered your BEA Home directory, click Next to continue.
The BEA Home directory is discussed in detail later in this chapter.
You have the following two options for installing the WebLogic Platform:
Because this chapter addresses the installation of WebLogic Server only, select Custom Installation and click Next to continue.
The Choose Components screen, as shown in Figure 10.2, enables you to select the software components you need to install from the WebLogic Platform.
You can see a brief description of each WebLogic Platform product and its respective components by selecting it in the tree view. Because the objective is to install WebLogic Server, select the WebLogic Server Product from the tree view, which should also automatically select the Server, Workshop, and Server Examples components. If you are new to J2EE and WebLogic Server, it is a good idea to install the Server Examples as they provide working examples of J2EE components and services in the context of WebLogic Server. After you have selected the components to install, click Next to continue.
From the Specify Download Options dialog screen shown in Figure 10.3, you can specify your preferences for downloading the WebLogic Server software as follows:
A temporary storage area on your machine for the WebLogic Server installation files, which should at a minimum accommodate 150MB
An option to remove the temporary installation files after you successfully installed WebLogic Server
If you are behind a Firewall, the Host and Port information for the HTTP Proxy server
Enter the information that pertains to your environment and click Next to begin the download process of the WebLogic Server installation files to your temporary storage directory.
The Download Status screen shown in Figure 10.4 gives you the option to automatically start the installation and configuration of WebLogic Server after the download is complete. Select this option.
If you do not select this option, to follow the subsequent installation steps you will need to launch the installation of the WebLogic Server manually by executing the WebLogic Server setup executable file, which can be found in your respective download directory.
Enter the directory within which the WebLogic Server software will be installed as shown in Figure 10.5. By default, a product directory within your BEA Home will be suggested, which is the recommended BEA directory structure for the WebLogic Platform and WebLogic Server software respectively.
Keep the recommended directory for the installation of your WebLogic Server software and click Next. A screen displays the progress of the WebLogic Server installation process.
After the WebLogic Server software files have been installed on your machine, the new WebLogic Domain Configuration Wizard will automatically be launched to assist you in creating your WebLogic domain. Select Yes and click Next to continue.
Because all WebLogic Servers exist in the context of a domain, which is an interrelated set of managed WebLogic Server resources, your next step is to define the type of domain you want to create and name it appropriately. As shown in Figure 10.6, your WebLogic Server will run in a domain based on a template you select from the following list:
WLS Examples—. This template creates a new domain in which WebLogic Server is preconfigured to run the WebLogic Server example applications.
WLS Petstore—. This template creates a new domain in which WebLogic Server is preconfigured to run the Pet Store sample application.
WLS Domain—. This template creates a new domain with no associated application. This should be the default WebLogic Server template you use to develop your applications within.
WebLogic Workshop—. This template creates a new domain in which the WebLogic Server supports the development of WebLogic Workshop Web service solutions.
Templates provide you with an option to create a WebLogic Server with an existing application deployed to it or not. Because you have already selected the Server Examples component, as shown in Figure 10.6, the WebLogic Server examples and Pet Store applications are automatically installed with the WebLogic Server installation. For this reason, unless you want to test or tune your newly created WebLogic Server with a fully operational application, you should select the WLS Domain template, which gives you the opportunity to learn about the WebLogic Server environment from the ground up.
The domain name is how you will uniquely identify the WebLogic environment you are creating. You can assign any alphanumeric name to your WebLogic domain, but it should be meaningful. For example, the domain name could represent the business function or application WebLogic Server is supporting.
For the purposes of following this installation, select the WLS Domain as your template and keep the default domain name “myDomain”. Click Next to continue.
Your next task is to select the type of WebLogic Server you want to create in the domain you have selected. As shown in Figure 10.7, you have the following options:
Single Server (Standalone)—. Creates a single WebLogic Server that acts as the Administration Server and also hosts applications.
Admin Server with Managed Server(s)—. Creates an Administration Server with one or more Managed Servers.
Admin Server with Clustered Managed Server(s)—. Creates an Administration Server with two or more clustered Managed Servers.
Managed Servers (with an Owning Admin Server Configuration)—. Can be used to extend an existing WebLogic domain with one Managed Server.
Note
▸ To learn more about Administration and Managed Servers in the context of a WebLogic domain, see “The Relationship Between Administration and Managed Servers,” p. 780.
Because the Single Server option creates a standalone WebLogic Server, this configuration is mostly recommended for WebLogic development environments. For this reason, select the Single Server option and click Next to continue.
As shown in Figure 10.8, specify the top-level directory where your myDomain domain will be created. The default is the user_projects directory underneath the BEA HOME. The user_projects directory is also known as the Domain Container directory because it can be used to maintain a separate location for your WebLogic Server domains and hence avoids burying them within the WebLogic Server product folder directory.
Keep the suggested default directory and click Next to continue.
Because you have selected to create a standalone WebLogic Server (single server), the Configuration Wizard needs the following configuration information to set up the WebLogic Server accordingly (see Figure 10.9):
Server Name—. A unique name you want to assign to WebLogic Server to be created. Because WebLogic Server will exist in the context of a WebLogic domain, it cannot have the same name as its WebLogic domain; this will cause the startup process of WebLogic Server to throw an exception and fail. The default server name is “myserver”.
Server Listen Address—. The IP address or machine name at which WebLogic Server will be reachable, for example localhost. If you do not assign a Listen Address, WebLogic Server will accept any request that comes through the Listen port using the primary IP address. You should only set the Listen Address if you are installing WebLogic Server on a machine with multiple IP addresses, for example in a clustering scenario. For the purposes of following this installation, leave this setting blank, which will default to your localhost name and primary IP address.
Server Listen Port—. The machine port from which WebLogic Server will listen for incoming non-secure HTTP requests. The default is 7001.
Server SSL Listen Port—. The machine port from which WebLogic Server will listen for incoming secure HTTPS requests. The default is 7002.
Enter the information for these settings and click Next to continue.
To start WebLogic Server, you will need to be an admin-level user. In the Create System User Name and Password screen, shown in Figure 10.10, enter a suitable username and associated password for your WebLogic Server administrator. Click Next to continue.
When you create your WebLogic Server, you have the option to install it as a Window Service, as shown in Figure 10.11.
Selecting the Yes option enables your WebLogic Server to be automatically started with the Windows system. If you are using WebLogic Server as a learning experience, it is best not to install WebLogic Server as a Windows service because you will need to maintain administration credentials between WebLogic Server and service. After you have selected which option meets your needs, click Next to continue.
The Create Start Menu Entry for Server screen gives you the option to create a Windows start menu for starting your standalone WebLogic Server. Because most administrators prefer to control the startup of their WebLogic Servers, this installation will opt not to create one.
Now that you have specified your WebLogic Server configuration settings, you can review them, as shown in Figure 10.12.
If you are satisfied with these configuration settings, click Create, which will install the necessary files in your domain directory to setup and start WebLogic Server as specified by the WLS Domain template.
After WebLogic Server is installed, you will see the Configuration Wizard Complete screen, as shown in Figure 10.13.
If you want to install additional WebLogic Servers using the WLS Petstore and WLS Examples domain templates, select the Run Configuration Wizard Again option and follow steps 10–15 to create the additional WebLogic Server domains. Otherwise, click Next and complete the configuration of your domains.
Alternatively, you can create additional domains by launching the Configuration Wizard independently by choosing Start, Programs, BEA WebLogic Platform 7.0, Configuration Wizard.
After you have installed WebLogic Server it is important you check the values of your system PATH and CLASSPATH environmental variables. The PATH variable provides your system with a list of directories that will be searched to invoke executable programs. Because the JVM is an executable program, you should ensure the installed JDK directory is included in the PATH variable.
The CLASSPATH variable is a list of directories and explicit Java class locations used by the JVM to locate any dependent Java class files it needs to load into memory and execute. At a minimum, the CLASSPATH variable should include the WL_HOME/server/lib directory, which contains the weblogic.jar file, which is the primary distribution file for WebLogic Server, and any service packs (weblogic_sp#.jar).
Both the PATH and CLASSPATH variables can be set at the system level or through a script file, which will be described later in the section “The startWebLogic Script File.”
After WebLogic Server has been installed, the next task is to become familiar with the WebLogic Server directory structure that has been created on your machine. Understanding the directory structure enables you to become familiar with WebLogic Server environment and the location of key directories and files you will need for starting WebLogic Server as well as refining your domain environment setup information. The following sections provide a description of the key aspects of the WebLogic Server 7 directory structure.
During the installation of WebLogic Server, you specified a location for the BEA Home directory. The role of the BEA Home directory is to serve as a central root directory for all installed BEA products on your machine and also to provide a central directory area for commonly shared files such as the Java Development Kit (JDK) and license files.
Note
The BEA Home directory is referenced within command line scripts using the %BEA_HOME% environmental variable.
Table 10.2 provides a description of the files and directories that are installed by default within the BEA Home directory.
Table 10.2. The Files and Directories Underneath the BEA Home Directory
Directory or File | Description |
|---|---|
| A directory containing the Java Development Kit (JDK) version 1.3.1_02, which provides the JVM and tools for compiling and debugging Java applications. |
| A directory containing a history file of installation and de-installation of WebLogic Platform software components. |
A domain container directory which is used to store your application domain directories. A detailed description of this directory is described in “The Domain Container Directory” section of this chapter. | |
A directory containing utilities that are used to support the installation of all WebLogic Platform software components. For example, the | |
The WebLogic Platform directory contains files shared by the entire WebLogic Platform software stack, as well as product-specific folders for each WebLogic Platform software component. A detailed description of this directory is described in “The WebLogic Platform Directory” section of this chapter. | |
An XML-format license file that contains the license keys for all licensable WebLogic Platform software components. | |
An XML-format registry file that contains a persistent record (of all WebLogic Platform software components installed on your system). BEA recommends this file should not be manually edited as any improper information can adversely affect future installation, maintenance upgrade, and de-installation tasks. | |
A command file (Windows NT/2000) or a shell script (Unix) utility that updates the |
Even though there is no enforcement to have only one BEA Home directory on your machine or even install BEA products within the BEA Home, it is beneficial from a central software management and maintenance perspective. However, a scenario where more than one BEA Home is recommended is when you need multiple independently maintained WebLogic Platform environments to reside on the same machine, for example development, test, and production environments.
The domain container directory (user_projects by default) is a new directory structure that is provided as a location for storing the applications you build and deploy to WebLogic Server. The intent of this new directory structure is to separate your application code from the WebLogic Server software code. In previous releases of WebLogic Server, domains were created within the directory structure of the WebLogic Server installation, including application code for each domain. By default, the domain container directory is created underneath the BEA Home directory and should contain the application domains you created using the Configuration Wizard earlier in this chapter, for example the myDomain domain. The domain container directory can be created anywhere on your file system as long as the application files it contains have location access to the JDK and WebLogic Server software files.
If you decide to manually create your domain directories, as opposed to using the Configuration Wizard, you are recommended to use the myDomain directory as a starting point because it contains the generic domain template configuration files you will need to configure a default WebLogic Server environment. Any new domains you create should use the following directory structure:
BEA_HOMEuser_projectsyour_domain_name
where
As a best practice, you should not modify the contents of the myDomain directory.
The subdirectories of the mydomain directory are described in Table 10.3.
Table 10.3. The Files and Directories Underneath the BEA Home Directory
Also, within your root domain directory, you should have the following resident files:
The
SetEnvscript to set up your environment for development with WebLogic Server. This script simply calls thesetWLSEnv.cmdscript under yourBEA_HOMEWL_HOMEserverindirectory, which is configured to your environment during the WebLogic Server installation. You can execute this file to set your Java environment to include your domain if you are doing any development.Scripts to start the WebLogic Servers in your domain (
startXXX.cmd).The configuration file (
config.xml) for the domain, which contains the configuration information for your entire domain. This file should not be edited directly.The
fileRealm.propertiesfile, which is used to store username location information and access control lists for the domain.The
SerializedSystemIni.datfile, a salt (hash) file that is used to encrypt user passwords for your domain.
WebLogic Platform has its own directory area, which by default, is located within the BEA Home directory. This directory is referenced in scripts using the %WL_HOME% variable.
Table 10.4 contains a description of each of the directories in the WebLogic Home directory.
Table 10.4. A Description of the WebLogic Home Directory
If you opted to install the WebLogic Server examples (refer to Figure 10.2), the installer also creates the Petstore and Examples domains. These sample domains are located in the WL_HOMEsamplesserverconfig directory, where WL_HOME is the root directory of your WebLogic Platform installation files.
The Petstore domain provides the application and configuration files for running the Java Pet Store 1.3, a sample J2EE reference application that showcases the main features of the Java 2 platform. The Examples domain provides the application and configuration files to demonstrate a variety of features using WebLogic Server. Both these sample domains are configured as standalone servers.
There are three methods that you can use to start WebLogic Server in a Windows 2000 environment as follows:
Choose Start, Programs, BEA WebLogic Platform, WebLogic Server 7.0, User Projects, myDomain, Start myserver. (This option is only applicable if you chose to create a Windows Start Menu entry using the Configuration Wizard.)
This menu-driven method is a shortcut to executing a start script, which is located in the root of a domain directory.
Execute the
startWebLogic.cmdscript file located in the root of your domain directory.Execute the
weblogic.Serverclass directly using the java command. This is the method the other methods ultimately execute without having to type the entire syntax on the command line.
Each of these methods will start WebLogic Server. However, if there is one method you should become extremely familiar with, it should be the one that uses the startWebLogic script, for the following reasons:
You may be asked to install and start WebLogic Server in multiple environments, not only Windows 2000.
Understanding the startWebLogic script enables you to understand the start-up mechanism of WebLogic Server, which is very important from an administration standpoint.
The startWebLogic script is a start-up mechanism that you can easily modify and re-use for all your domains.
You can version control your start-up mechanism for each of your domains.
Typing the command-line syntax using the java command is a very cumbersome and time-consuming effort, especially if you have to remember the start up options for the JVM as well as your domains.
The startWebLogic file is a text-based script file that provides an easy mechanism for starting an instance of WebLogic Server. The contents of the startWebLogic script enable you to specify the environmental configurations you need to support the execution of your J2EE applications. By default the startWebLogic script is located in the root of your domain directories, for example in your myDomain directory:
BEA_HOMEWL_HOMEuser_projectsmyDomain
You should not modify this file because it serves as a template startup script for future WebLogic Servers you may want to create manually. This script by default starts WebLogic Server as an Administration Server. There is a separate script, the startManagedWebLogic file, for which you can use a template for starting Managed Servers. When you create your own WebLogic Servers, you may want to consider renaming the startWebLogic file using the following naming convention:
StartDomain[Managed].cmd
where:
Domain specifies the name of the WebLogic Server domain.
Managed specifies WebLogic Server will be a Managed Server (Optional).
If you have installed the Pet Store and Examples sample applications, their specific startup scripts are named startPetStore.cmd and startExamplesServer.cmd respectively and are located under their own domain directories in the following location:
BEA_HOMEWL_HOMEsamplesserverconfig
Because the startWebLogic script is a text file, you can review its content through any text editor, such as Notepad or Wordpad. The important configuration variables stored in the startWebLogic script file you should become familiar with are described in Table 10.5.
Table 10.5. The startWebLogic Variables
After the domain startWeblogic script file is executed, the configuration information contained within the file is passed to a master startWLS.cmd script, which is located within the BEA_HOMEweblogic70serverin directory. This master startWLS script sets the variables related to the location of the root directory of your WebLogic installation and the root directory of JDK installation, and then starts WebLogic Server using the following Java command syntax to execute the weblogic.server class:
java RequiredArguments [OptionalArguments] weblogic.Server
The RequiredArguments and OptionalArguments are configuration information supplied by your domain and master startWeblogic script files.
All WebLogic-specific information uses the following syntax:
WebLogic-specific:
-Dweblogic.attribute=value
Java-specific:
-Djava.attribute=value
These options are tagged to the end of the JAVA_VM and MEM_ARGS variables.
From a WebLogic Server practitioner’s perspective, all startWebLogic script options and their respective values are important to the optimal operation of WebLogic Server. However, if you are just in the learning phases, there are three options with which you should immediately become familiar. The following sections describe these options and their preferred initial values.
Because you will be initially running all your default and sample WebLogic Servers as Administration Servers, this option prevents an Administration Server from discovering Managed Servers on your network. Unless you have a Managed Server WebLogic Server environment, placing an Administration Server in Discovery mode will place an unnecessary overhead (detection and connection processes) on your system, hence slowing it down quite considerably. By default this option is set to true (Discovery Mode). You can switch the Discovery mode off by using the following statement in your startWebLogic script:
JAVA_OPTIONS=-Dweblogic.management.discover=false
It is assumed you will initially be using your WebLogic Server for development purposes. If this assumption is true, you will also want WebLogic Server to auto deploy your J2EE applications or any modifications to them. In order for WebLogic Administration Server to provide this capability, it must be placed into Development mode, which starts a poll process that will detect changes in your application’s directory in your active domain. By default, this option is set to true, implying the WebLogic Administration Server is in Production mode, which does not provide any auto-deploy capabilities for production control reasons. You can place your WebLogic Administration Server in Development mode by using the following statement in your startWebLogic script:
JAVA_OPTIONS=-Dweblogic.ProductionModeEnabled-false
By default the minimum (-Xms) and maximum (-Xmx) values for the heap memory of your JVM are set to 200MB. If you are using a system that is constrained for memory, you should consider reducing these settings to an acceptable value that does not cause your system as a whole to slow down. For example, you can set these options to 100MB by using the following statement in your startWebLogic script:
MEM_ARGS=-Xms100m -Xmx100m
The following steps describe how to start the default WebLogic Server that is defined in the “myDomain” directory using the startWebLogic script:
From the command line, change the directory to the root of your
mydomaindirectory.Run the
startWebLogicscript, as shown in Figure 10.14.When you are prompted for an admin-level username and password, enter the respective information you used to create that account during the myDomain configuration.
After WebLogic Server has started, you can start the Administration Console, a Web based resource management tool for WebLogic Server, using the following syntax:
http://hostname:port/console
For example,
http://localhost:7001/console
The Administration Console Login screen should appear. Enter the admin-level username and password, as shown in Figure 10.15.
Figure 10.15. Enter the admin-level username and password at the WebLogic Administration Console Login screen.
Figure 10.16 shows the Administration Console screen for the “myDomain” domain.
Caution
You will not be able to start the Default (myserver), Pet Store or Example WebLogic Servers concurrently because they all share the same non-secure (7001) and secure (7002) port information. You will need to configure their port information separately through the Administration Console, which is discussed later in this chapter.
Using a boot identity file is the most secure and convenient way to bypass the WebLogic username and password prompt. To create a boot identify file, follow these steps:
Create a text file and enter the following two lines:
username=username password=password
The username and password values must match an existing user account that has the capability to start WebLogic Server.
Save the file as
boot.propertiesand locate it in the root of yourmyDomaindirectory.
When you first start WebLogic Server, the server will read the file and overwrite it with encrypted versions of the username and password. From this point forward, WebLogic Server will use the boot.properties file to attain the credentials to start up.
If you installed the Server Examples components (refer to Figure 10.2 earlier in this chapter), starting and navigating through the Pet Store application is always a good validation of a successful WebLogic Server installation because it is the J2EE reference application provided by Sun. If you are learning WebLogic Server and J2EE development, understanding the composition of the Pet Store example and how it runs in WebLogic Server is a superb place to start.
The following steps describe how to start the WebLogic Server instance of the Pet Store application:
From the command line, change directory to the root of your Pet Store application domain, which should be located in the following location:
BEA_HOMEweblogic70samplesserverconfigpetstoreRun the
startPetStore.cmdscript.Upon successfully starting the Pet Store application, your browser will automatically start the Java Pet Store Demo page, as shown in Figure 10.17.
From this page you can gain an overview of the WebLogic Server implementation of the Pet Store reference J2EE application.
Click the
enter the storehyperlink to launch the Pet Store application storefront, as shown in Figure 10.18.
There are two methods you should use for shutting down your WebLogic Server gracefully:
The WebLogic Server Administration Console
The
weblogic.Admincommand-line utility
You should always try to use one of these methods because killing the WebLogic Server process will prevent any cleanup processes from occurring, which can lead to the loss or corruption of data used by WebLogic Server.
Follow these steps to shut down an instance of WebLogic Server using the Administration Console:
Start the Administration Console for the instance of WebLogic Server you want to shut down using the
http://hostname:port/console syntax.Log in to the Administration Console using an admin-level username and password.
In the Administration Console navigation tree (the left pane), click the + in front of Servers to display the list of servers.
Right-click the name of the server you want to stop and choose Start/Stop This Server, as illustrated in Figure 10.19.
Follow the Administration Console instructions to stop WebLogic Server.
The weblogic.Admin command-line utility provides a suite of useful functions that can be used for the administration of WebLogic Server. Even though it does not provide the rich administration capabilities of the Administration Console, it is an extremely useful alternative, especially if you do not have access to a Web browser.
The syntax and required arguments for using the weblogic.Admin command-line utility are as follows:
java weblogic.Admin [-url URL] [-username username] [-password password] COMMAND arguments
where:
URLspecifies the WebLogic Server host including the TCP port at which the WebLogic Server is listening for client requests. The format for the URL argument is hostname:port, for example the default is localhost:7001.usernamespecifies a username with access to WebLogic Server.passwordspecifies a password for the username.COMMAND argumentsspecifies command syntax and arguments for a WebLogic Server administration task.
For detailed information on the weblogic.Admin command syntax and arguments, please refer to the WebLogic Server Administration Command Reference section of your WebLogic Server documentation.
In reference to shutting down a WebLogic Server, the following weblogic.Admin syntax and arguments can be used:
java weblogic.Admin [-url URL] [-username username] [-password password] SHUTDOWN [seconds] ["lockMessage"]
where:
secondsspecifies the number of seconds WebLogic Server will remain locked and will wait to start the shutdown process after the command is run.lockmessagesends a message to any user requesting a connection to WebLogic Server while it is in the process of shutting down.
To run the weblogic.Admin utility, it is important to have the PATH and CLASSPATH environmental variables set correctly to reflect your Java and WebLogic Server installation directories and files. This effort can be alleviated by using the setEnv script, which is created by default in your domain directories. For example, the myDomain directory contains a setEnv script that can be used to set up the environment for running java commands explicitly against WebLogic Server supporting the “myDomain” domain.
The following steps describe how to shut down an instance of the mydomain WebLogic Server using the weblogic.Admin utility:
From the command prompt, change directories to your
mydomaindirectory.From your
mydomaindirectory, run the setEnv script (setEnv.cmd) to set up your Java environment with the appropriatePATHandCLASSPATHinformation.Execute the following
weblogic.Admincommand:java weblogic.Admin -url localhost:7001 -username username -password password SHUTDOWN 60 "The myDomain WebLogic Server is in the process of shutting down"
As you can see in Figure 10.20, the myDomain WebLogic Server is shut down gracefully.
It is a good practice to provide a shut down message, so any users trying to connect to WebLogic Server are aware of its status, and hence avoid any unnecessary debugging exercises on why their connection requests are failing.
With the release of the WebLogic Server 7, the server lifecycle has been greatly improved to allow WebLogic Server to exist and transition between one of several states, as illustrated in Figure 10.21.
The behavior of each state shown in Figure 10.22 is as follows:
STARTING—. This transition progresses through the following steps:
An Administration Server retrieves its configuration information (including security configuration data) from the domain’s configuration files. Alternatively, a Managed Server communicates with its associated Administration Server for its configuration and security data.
WebLogic Server starts its kernel-level services, which includes logging and timer services.
WebLogic Server, using the retrieved configuration information, then initializes its subsystem-level services, such as the Web and EJB containers, RMI, JNDI, JDBC, and security.
WebLogic Server deploys the application modules to their respective containers.
WebLogic Server executes any configured startup classes.
STANDBY—. In this state, WebLogic Server has initialized all of its services and applications and can accept administration commands and participate in cluster communication. However, it is not accessible for requests that come from external clients, except administration requests. From the STANDBY state, you can quickly resume WebLogic Server’s ability to process client requests.
Note
▸ This state is only applicable if you have configured the domain to use an administration port. For a discussion of this, see “Enabling the Administration Port,” p. 801.
RUNNING—. In this state, WebLogic Server is fully functional and fully manageable, offering its services to clients and operating as a full member of the cluster.
SHUTDOWN—. In this state, WebLogic Server is configured, but does not exist as a process. You can transition WebLogic Server into this state either from the RUNNING state or the STANDBY state. As it transitions to SHUTDOWN, a server goes through the SHUTTING DOWN state.
When you issue a graceful shutdown, WebLogic Server first transitions itself to a transient state, SUSPENDING and rejecting new work but enabling in-flight work to complete. WebLogic Server then provides time to each subsystem-level service to release its external resources before it is shut down.
When you issue a forceful shutdown, the server notifies all applications and subsystems to abort all relevant in-flight work immediately and release remaining resources where applicable—for example, closing files and network connections. This is the quickest way to shut down WebLogic Server, but could result in rolled back transactions and session loss for some clients.
FAILED—. WebLogic Server can transition to this state if one or more critical services become dysfunctional during the lifetime of server. Your only option to recover from the FAILED state is to shut down the server.
UNKNOWN—. WebLogic Server can transition to this state if it does not respond to requests (Administration or client). Further investigation is required to determine the reason for this UNKNOWN state before it is shut down as the reason could be because the server is very busy processing requests.
You can control WebLogic Server’s lifecycle by choosing Server, Control, Start/Stop in the Administration Console or via the weblogic.Admin utility in conjunction with the following commands:
Note
▸ To learn how to use these weblogic.Admin commands, see “The weblogic.Admin Utility Commands,” p. 368.
With these new server lifecycle states, WebLogic Server can be brought up quickly in a Hot Standby state and be primed for quick activation in the case of an outage. Also, WebLogic Server can be gracefully suspended, allowing new work requests to be rejected, while in-flight requests are allowed to complete.
By default, the installation process of WebLogic Server installs the Java 2 Platform Standard Edition (JDK1.3.1) with the Java HotSpot JVM which is licensed from Sun. All other J2EE APIs are included in the weblogic.jar file, which is located in WebLogic Server’s software library directory (WL_HOMEserverlib).
A high percentage of WebLogic installations prior to the release of WebLogic Server 7.0 used this default Java 2 Platform to execute their J2EE applications. However, on February 25, 2002, BEA Systems Inc. announced the acquisition of Appeal Virtual Machines AB, a leading Java Virtual Machine (JVM) software company. Appeal’s product, the JRockit JVM, is specifically designed for enterprise server-side execution of Java applications and includes pioneering technology around I/O, memory management, and multi-threading, which results in industry leading scalability, manageability, and performance. The JRockit JVM is currently engineered for Intel and Linux machines, and work is underway to support a more diverse hardware platform.
The acquisition of Appeal Virtual Machines and the JRockit JVM leads to a high probability for future versions of the WebLogic Platform, including WebLogic Server, to include the JRockit JVM as the JVM of choice for selected hardware architectures. For this reason, this chapter includes a discussion on the option to use the JRockit JVM with the WebLogic Server.
A JVM is critical to your implementation of WebLogic Server because WebLogic Server is an instance of the weblogic.server Java class, which contains the main() method, executing within the context of the JVM. There can be multiple JVMs installed on a machine; however, every instance of WebLogic Server will run in its own JVM.
In general, the specifications for the Java Virtual Machine are relatively open for implementation by software vendors. The specifications define core features every JVM must possess:
By design, how these features are implemented is left to the architects of the JVM. This well-thought out approach allows the JVM specification to be flexible enough to be implemented on a wide variety of computers and devices as well as in software, such as Java IDEs and applications servers.
Most JVMs have their foundations in client-side environments, and have slowly been modified to support the demands of the server. It is extremely important for you to understand that JVMs are optimized quite differently for client-side and server-side usage. BEA’s research has shown that each of these environments place different demands on the JVM as follows:
Client-side JVM demands
75% in translating and executing bytecode.
20% in garbage collection.
5% in threads and I/O-related activities such as socket communication, files, and databases.
Server-side JVM demands
JRockit is the first commercially available JVM that has been engineered from scratch to support server-side Java applications with the following design features:
Superior server-side performance compared to any other JVM.
Full Java compatibility with J2SE 1.3.1 and J2SE 1.4.
Support for 32-bit and 64-bit architectures.
Full support for dynamic class loading.
Support for the core design goals of the JVM, which enables optimizations, thread scheduling policies, and memory management policies to be written in Java and added to the JVM at runtime.
Full adaptive optimization of the execution engine, enabling JVM runtime statistics to improve code optimizations, garbage collection, and thread management.
A bottleneck detector that constantly collects runtime statistics. If a method is executed frequently and found to be a bottleneck, it is sent to the Optimization Manager subsystem for aggressive optimization. The optimized method then replaces the old method dynamically. Hence, the bottleneck detector can continuously improve the performance of a Java application.
Two different thread systems—High Performance and Native threads.
Four different garbage collection schemes.
A management console that enables administrators to monitor the real-time operating characteristics of the JVM and the executing Java applications, enabling CPU and memory utilization problems to be proactively identified and resolved, which can otherwise contribute towards application downtime.
JRockit is currently freely available for anyone to use without restriction, and therefore does not require a license key to activate it. You can download the JRockit installation program (20MB) certified for either J2SE 1.4 or 1.3.1 to a directory on your machine from the BEA Web site using the following URL:
http://commerce.bea.com/downloads/weblogic_jrockit.jsp
After you have downloaded the JRockit installation program, execute it and follow the directions presented to install JRockit to a directory on your machine. The JRockit software installation files are approximately 40MB in size.
After you have installed JRockit, you can make JRockit the default JVM for your machine by adding the full path of the JRockit bin directory to your system’s PATH variable, ensuring the JRockit path occurs before the path to any other JVM. Alternatively, you can use the full path to the JRockit Java executable when starting a Java program.
Caution
On Windows 2000, some programs set the system default JVM by copying a java.exe file to the C:WINNTsystem32 directory. If this happens and the C:WINNTsystem32 directory is listed before the path to JRockit in your system PATH variable, you will probably be running a different JVM than expected. You can test which version of JVM you are using by executing java -version from the command prompt.
To switch WebLogic Server to use the JRockit JVM instead of the default HotSpot JVM, follow these steps:
Open the
WL_HOMEserverinstartWLS.cmdfile with any text editor.Edit the line “set JAVA_HOME=” to point to the fully qualified path to your JRockit JDK installation directory, for example:
set JAVA_HOME=C:Program FilesJRockit7.01.3.1
Remove the text %JAVA_VM% in the line near the end of the file.
Save the file.
Before you start up your WebLogic Server with JRockit, it is extremely important that you verify if you were using any –X command-line options to start the HotSpot JVM. The -X command-line options are used to change the behavior of the HotSpot JVM and are typically stated as values for the MEM_ARGS variable in the startWebLogic.cmd script file. Even though standard command-line options available for JRockit are the same as HotSpot, such as -version and -help, the nonstandard options (-X options) for JRockit are in most cases not the same as the nonstandard options for the HotSpot JVM. If you were using any –X command-line options to start the HotSpot JVM, you will need to review the syntax for implementing the same or similar feature for JRockit from the JRockit User Guide.
The JRockit Management Console can be used to supervise and monitor running instances of the JRockit JVM, providing real-time information about the characteristics of Java applications. For example
During development, you can use the management console to locate where in an application’s lifecycle more memory is consumed.
In a production environment, the management console can be used to monitor the health and resource utilization of the WebLogic Server.
The extra resource cost of running the JRockit Management Console against a running JRockit JVM is very small and can almost be disregarded, which provides an excellent means for monitoring and profiling your J2EE applications in conjunction with the WebLogic Administration Console.
Before you can use the JRockit Management Console, the management server inside the JRockit JVM, which is disabled by default, needs to be started. The management server provides the means for the management console to connect to the JRockit JVM via a port, which by default is set to 7090.
To enable the management server, you will need to start JRockit with the managementserver property set to true. This can be achieved by editing your startWebLogic.cmd script file and including the -Djrockit.managementserver=true value for the JAVA_OPTIONS variable, as follows:
set JAVA_OPTIONS= -Djrockit.managementserver=true
You can optionally modify which port to use by setting the port in the port property, as follows:
-Djrockit.managementserver.port=<portnumber>
After you have modified the JAVA_OPTIONS variable accordingly, you can start your WebLogic Server using the startWebLogic.cmd script file. After the management server is successfully started, you will be notified with the following message in the command console:
[JRockit] Management Server started on port 7090
To start the JRockit Management Console, ensure your PATH is set correctly to point to the JRockit installation directory, and type the following from the command prompt:
java -jar ManagementConsole.jar
After the JRockit Management Console starts, you will need to connect it to the JRockit JVM associated with your running WebLogic Server using the following steps:
From the Connection menu, select the New Connection option.
In the displayed Add New Connection dialog screen, enter the following information, as illustrated in Figure 10.22:
The IP Address or DNS of the machine where the JRockit JVM is running.
The Port number on which the management server is running.
Select the Connect Now option and click Add Connection.
After you have connected the JRockit Management Console to the JRockit JVM, you will see a screen similar to Figure 10.23, from where you can use the Overview, Memory, Processor, System and Notification tabs to monitor in real-time the different aspects of the JRockit JVM.
This chapter has methodically walked you through the steps of deciding which WebLogic Server Edition meets your needs, as well as an in-depth illustrative WebLogic Server installation and configuration process. You have also learned how to start and stop WebLogic Server using different options. Finally, you have learned about the WebLogic JRockit JVM, the advantages it offers over the default HotSpot JVM, and how to install, configure, and manage the JRockit JVM in conjunction with WebLogic Server.