BEA WebLogic Server 8 For Dummies Cheat Sheet - dummies
Cheat Sheet

BEA WebLogic Server 8 For Dummies Cheat Sheet

From BEA WebLogic Server 8 For Dummies

By Jeff Heaton

BEA WebLogic Server, now called Oracle WebLogic Server (Oracle acquired BEA in 2008), is one of the most widely used Java application servers on the market today. By knowing some administrator tips, monitoring your WebLogic servers, and keeping WebLogic Server up-to-date, you’ll soon be on your way to building and deploying web services for large and small projects in no time.

5 Tips for WebLogic Server Administrators

A WebLogic Server administrator’s job has many facets. And as you administer systems, you gain experience of what works and what doesn’t work. Here are five useful tips for WebLogic Server administration.

Document procedures

As a WebLogic Server administrator, you’ll follow many procedures, including tasks such as these:

  • Restarting the server

  • Shutting down the server for routine maintenance

  • Deploying new versions of WebLogic Server

  • Backing up the server

  • Installing the latest patches

  • Creating WebLogic Server resources such as data sources

You should have written instructions for each of these procedures, which will enable you to follow the same procedure each time, ensuring consistency.

Written procedures also enable your company to perform these operations when you’re away. In addition, if you take a new position in the company or with a new firm, having written procedures enables you to fulfill your responsibility to transfer knowledge to the new administrator.

Define a service level agreement

A service level agreement (SLA) helps to define what end users expect from your server in terms of reliability. Most users expect that a system will be up and running 24 hours a day, 7 days a week. Such a schedule is simply not possible. Many events will cause your system to be down for a period of time. For example, dealing with hardware failures, routine updates, or rebooting your server to name a few.

The SLA is the contract between you and the users that your system supports. This contract should specify the amount of time that your system will be allowed to be down through the year.

In addition to defining maintenance periods, a properly written service level agreement should also specify the following:

  • When maintenance will be performed

  • How many minutes of unexpected outage are allowed per year

  • How soon the system must return after an unexpected outage

  • How often backups will be performed

  • The overall percent of time that the server should be up

Set up on-call procedures

At some point, the system will go down unexpectedly. When an unexpected outage occurs, you and your staff must be ready to deal with it. The outage may be something that the administrator can handle or something related to the software. If the outage is caused by a software error, a developer will need to get involved in the solution. Additionally, these outages may occur outside regular business hours. This is especially true if you work for a multinational corporation.

Plan for growth

When your system is first deployed, you may not be thinking about growth. But you should have a plan when your current system is outgrown. In general, you have two choices when your system can no longer handle the amount of processing required:

  • Upgrade your server to a faster machine. Perhaps one of the simplest ways to handle more requests is to upgrade to a faster machine. This may mean the purchase of a new server or simply adding another processor to your current server. When you upgrade to a faster machine, you must make sure that your server is properly copied across the network to the new machine. All configuration settings and installed packages should be copied to the new machine.

  • Add additional servers to your cluster. If you’re running a cluster of servers, you can simply add another server. If you’re not running a cluster of servers and your request volume is becoming too high, you should consider using a cluster of servers. Adding another server to the cluster causes WebLogic Server to have another server that can share some of the workload. This allows the application as a whole to be able to accept more connections.

Back up your servers

Backing up data is an important part of any administrator’s job. For backing up WebLogic, you’ll need to back up the part of your web application that changes — the SQL database. If this data is already being backed up by a database administrator, you don’t need to worry about backing up application data.

If you lose the hard drive on your WebLogic server, you’ll be expected to reinstall everything and get the server running again. If your application was packaged as a web application archive (WAR) file, you can quickly get your application back up by redeploying the WAR file.

Monitoring WebLogic Servers

Monitoring your sever is an important task that every WebLogic Server administrator must deal with. You’ll monitor whether your server is up as well as the server load. Monitoring allows you to quickly see an overview of how different parts of WebLogic Server are performing. WebLogic Server allows you to monitor the following areas:

  • CORBA connection pools

  • EJB

  • HTTP

  • JDBC

  • JMS

  • JNDI

  • JTA subsystem

  • Security

  • Servers

All monitoring activity takes place through Administration Console. The monitoring functions of Administration Console are not isolated to one specific area. Rather, these functions are placed in the same area as the system that they’re monitoring.

In general, to find the monitoring page for a specific service in WebLogic Server, follow these steps:

  1. Log on to Administration Console.

  2. In the Services folder (on the left side of the screen), click the folder representing the service you want to monitor.

    The information at the right side of the console changes to reflect the service you selected.

  3. On the right side of the screen, click the Monitoring tab.

The monitoring page shows you how many connections are active, how many threads are waiting on a connection, and how many connections are unavailable. From here, you can monitor your connection.

Keeping WebLogic Server Up-to-Date

You should be aware of any patches as well as the current version of WebLogic Server. Patches correct errors and security issues that occur between major releases of WebLogic Server. You should download and install patches for WebLogic Server as well as other system components. This is particularly true of the Windows operating system, which has many security patches available.

When the security of a system is compromised, it’s often because the administrator didn’t have the most up-to-date patch installed.

Upgrading to the current version of WebLogic Server is much less critical than applying operating system and WebLogic Server patches. Sometimes it takes a redesign of the source code to get the current version to work properly. After the initial release of a new version, many companies prefer to wait until the release has been proven. When you decide to upgrade to the latest version of WebLogic Server, you should do so on a test server. Then, after you verify that the test server is performing well, you can put the new version onto your production system.

You can find the most up-to-date information on the Oracle WebLogic Server web page.