You're a developer, not an administrator. You think you don't care about system and application administration. Well, you should... and this series of articles on WebLogic Server administration and management for developers will explain why, and how.

Before you can get too far developing a J2EE application with BEA WebLogic Server 8.1, you have to do some administration work to configure a server and deploy the application. Once you're ready to promote the application from your local development environment to another test or production environment, you need to understand what administrative tasks are necessary to prepare the other environment for your application. At some point during the application's life, you'll probably be asked to help troubleshoot some sort of problem with the application. This might require you to monitor the server's and/or application's behavior. You might even be asked to write some custom scripts or programs to automate some of these administrative or monitoring tasks. All of these tasks require some knowledge of system and application administration.

The BEA WebLogic Server administration and management subsystem is based on Java Management Extensions (JMX) version 1.0. So, what is JMX? JMX is the Sun Microsystems, Inc. specification that provides open and extensible Java management services. Even though JMX does not become an official part of J2EE until the release of the J2EE 1.4 specification, it has proven its value to enterprise application infrastructure, and most Java application server vendors today support JMX to some extent. BEA has supported JMX since the WebLogic Server 6.0 release.

WebLogic Server also supports the industry-standard Simple Network Management Protocol (SNMP) version 1 and version 2. SNMP support provides the ability to use the most popular enterprise system and application monitoring products, like HP OpenView, BMC Patrol, or CA Unicenter, to monitor WebLogic Server-based applications. WebLogic Server's SNMP interface is read-only and will not be covered here.

On top of the JMX infrastructure, WebLogic Server provides three major types of interfaces that you can use to achieve your management goals:

In this article, we'll talk about ways of managing BEA WebLogic Server that do not require an understanding of the JMX infrastructure, which will be covered in subsequent articles. We start with an overview of the graphical administration tools and then move on to discuss uses of the command-line tools that do not require an understanding of JMX. Before we dive into WebLogic Server administration, let's define some of the major concepts upon which WebLogic Server administration is based.

Administration Concepts and Terminology
BEA WebLogic Server uses the term domain to describe a logically related group of WebLogic Server resources that you manage as a unit. It's important to understand that a domain is a purely administrative entity, and logically can cover more then a single application, or even a portion of an application. A domain always includes at least one WebLogic Server instance called an Administration (or Admin) Server. The Admin Server serves as the central configuration repository and central point of contact for administration. A domain may also include additional WebLogic Server instances, called managed servers; and clusters, each of which includes one or more managed servers. A cluster can span one or more physical machines.

WebLogic Server also supports the use of a node manager. The node manager is a cross-domain entity that provides support for remotely starting servers, restarting failed servers, and monitoring server health. As such, you need only one node manager instance per physical machine. We'll take a closer look at the node manager later. Figure 1 shows one example of a WebLogic Server domain topology.

In addition to facilitating the domain's administration and management, the Admin Server also has at least one application deployed on it: a J2EE application that delivers the WebLogic Server Administration Console to your browser.

Graphical Tools: Configuration Wizard, Admin Console, and Builder
In this section, we'll take you on a tour of the WebLogic Server GUI tools from the perspective of getting your application packaged, and your BEA WebLogic Server 8.1 system and application environments configured and ready for application deployment.

Application Environment Configuration
The first thing you need to do after installing the BEA WebLogic Server 8.1 software is to set up a domain and start your Admin Server. As we mentioned earlier, one of the responsibilities of the Admin Server is to act as the configuration repository for the domain. This configuration information primarily resides within an XML file called config.xml. In order to start the Admin Server and access the Admin Console to configure the rest of your domain, you need a base config.xml file (and some other files) that reflects your environment and has enough information to start the Admin Server. WebLogic Server provides the Configuration (Config, for short) Wizard that walks you through this process.

The Config Wizard is a stand-alone Java Swing application that comes with WebLogic Server. Since it is primarily a bootstrapping tool, it does not require the Admin Server to be running in order for you to use it to create the base configuration that your domain requires. You can choose to configure additional information about your domain such as topology information (e.g., clusters, managed servers, and machines), JDBC and JMS resources, and security (e.g., users, groups, and roles).

As in any other wizard-based tool, the Config Wizard walks you through a sequence of data entry screens that not only take your input but also verify accuracy throughout the configuration process. You can go forward and backward, change your decisions, and fix any errors encountered during the process. Figure 2 shows one of the Config Wizard screens.

Once you've completed the configuration process, the Config Wizard creates all the necessary directories and files needed to start your Admin Server. At this point, you may need to do additional configuration through the Admin Console or, depending on your application requirements, you may be ready to deploy your J2EE application.

Once you've completed your domain's entire configuration, the WebLogic Server Configuration Template Builder allows you to turn an existing domain into a template that can be distributed and replayed to create equivalent configurations in other environments. This can be a big help when trying to promote applications from development to QA, user acceptance testing, and production.

System Configuration with the Administration Console
Once you start the Admin Server, you can access the Admin Console as you would any other Web application running on the server at the configured port. By default, the server uses port 7001, so the URL to access the console from the machine where the Admin Server is running is http://localhost:7001/console. Figure 3 shows the initial view of the Admin Console after logging in, with the Medical Records sample application that comes with BEA WebLogic Server 8.1 deployed. For example, some of the nodes in the object tree on the left have been expanded.

The Admin Console provides a graphical, intuitive, and comprehensive interface to WebLogic Server administration. As a developer, you may be more or less concerned about some of these capabilities; however, it is important that you are at least aware of what the Admin Console has to offer.

One of the functional areas that the Admin Console provides is general server configuration. There are parameters for things like server restart attributes, memory and thread settings, listen addresses and ports, settings for the different protocols that WebLogic Server supports (e.g., IIOP, HTTP, COM), logging, and many others. As a developer, you may not need to change many of these settings. However, they may become important as your application moves from development into QA, performance and load testing, and production. Figure 4 shows the server configuration screen for HTTP protocol configuration.

BEA WebLogic Server provides a set of services for your application, many of which probably contributed to the decision to use an application server in the first place. These services include J2EE and non-J2EE resources. Typically, you can't deploy your application unless you have all the J2EE resources it requires already configured and available in the server. These resources include database connectivity (JDBC connection pools and data sources), asynchronous messaging support (JMS), e-mail connectivity (JavaMail), integration resource adaptors (JCA), and others. Other services need to be configured properly in order for your application to function correctly. These include things like transaction support (JTA), security, XML, and others. The Admin Console provides a convenient and intuitive view of all these services as a tree of objects that you can configure, manage, and monitor.

In addition to these application services, WebLogic Server provides a set of services targeted at providing high performance, scalability, fault tolerance, and reliability to your application. These services consist of things like replication groups for controlling the in-memory replication failover, different kinds of caching for performance and resource efficiency, object pools, thread pools, and so on. Through the Admin Console and the J2EE deployment descriptors, WebLogic Server gives you the ability to configure and fine-tune many of these services to optimize your applications' performance, availability, and reliability. For example, one of the most important configuration parameters for improving performance is the execute queue thread count. When a request is received by a server, the server places it in an execute queue. This request is then assigned to an execute thread that processes the request and returns the response to the requestor. In addition to the default queues for processing requests, WebLogic Server provides you with the ability to configure new execute queues, each with their own set of execute threads, and assign them to either entire applications or pieces of an application. As we will see later, the Admin Console provides powerful monitoring features that can help you understand and optimize your application's performance.

J2EE Application Configuration with WebLogic Builder
In addition to configuring different server-provided services, you need to configure and package your application before deployment so it can use all the server-provided services correctly. According to the J2EE specification, your application-specific configuration is stored in XML configuration files called deployment descriptors (DD). While you can create and edit DD by hand using any text editor, you will find this to be a very tedious and error-prone process. WebLogic Builder - a graphical J2EE application packaging and deployment tool - is a great help in this process.

WebLogic Builder (see Figure 5) is a stand-alone Java Swing-based tool that comes with BEA WebLogic Server. It allows you to create and/or modify the application's configuration stored in both the J2EE-standard and WebLogic Server-specific deployment descriptors. While this tool does not require WebLogic Server to be running, it can validate many of the application configuration settings against a running instance of WebLogic Server if one is available. After completing your configuration, WebLogic Builder will package your J2EE application into the appropriate JAR, WAR, and/or EAR files; and even deploy it directly to the WebLogic Server instance of your choice.

You might notice that there is some overlap in configuration features between the Config Wizard, the Admin Console, and WebLogic Builder. Each of these tools focuses on a specific audience and task. WebLogic Builder is primarily intended to allow application developers or deployers to create and modify application deployment descriptors and package your J2EE applications for deployment to BEA WebLogic Server. The WebLogic Server Config Wizard is primarily intended to provide a domain configuration bootstrapping mechanism to create the files necessary to start your Admin Server. WebLogic Server's Admin Console is the primary configuration, deployment, and monitoring tool used for all other tasks. As a developer, it's beneficial to have at least some understanding of each of these tools.

Summary
This article introduced you to the major concepts and terminology for a BEA WebLogic Server domain. Then we showed you the most commonly used graphical tools for setting up WebLogic Server, and packaging and configuring applications to be deployed on it: the Administration Console, the Configuration Wizard, and WebLogic Builder.

In our next article, we'll look at application deployment, run-time management, and monitoring facilities available with WebLogic Server - both graphical and command line-based.