Introduction

IN THIS CHAPTER

Introduction

The Underlying Technologies

Java

J2EE

JDBC

Context

Implemention

JNDI

Java Servlets

EJBs

XML

JNDI and Clustering

RMI

Intoduction to BEA Concepts

Domain

Administration Console

Accessing Online Help

Conventions of This Book

Recap

Introduction

This book is an introduction to the process of administering the BEA WebLogic server. It is intended as a supplement to the online documentation included with the server distribution and on the BEA Web site. While that documentation is frequently useful and sometimes complete, it can leave beginning administrators with the sense that they came in in the middle of the show. There are many unstated assumptions about the reader's knowledge, and to the reader who lacks that knowledge the documentation can be nearly impenetrable. The intent of this book is to fill those gaps.

This is not simply a bound collection of the how-to's that ship with the WebLogic server. Anyone who might conceivably have a need for them already has them—they're readily available online.

This book gives you the information you need to intelligently administer your WebLogic server.

Note that this book addresses only the tasks involved administering the WebLogic server. It does not touch on the process of developing the Java™ programming language (Java) applications that will be run on that server.

The Basics

WebLogic is an application server developed by BEA systems. If you're in the IT industry, you've probably heard the term “application server”; it's one of the buzzwords du jour. But what does it mean, exactly?

An application server is a relatively new class of program that integrates the functionality of several historically distinct classes of programs such as HTTP/HTTPS servers, EJB servers, and CGI. The emerging popularity of application servers is due, perhaps, to their being the product of a single more or less coherent design. This makes them easier to learn, easier to work with, and more efficient in their use of system resources.

Application servers are optimized to run multitiered applications, which separate the functionality of an application (typically, but not always, a Web-based application) into distinct conceptual layers. A multitiered application typically consists of three rigidly defined layers, or tiers:

Application servers include such products as CORBA, Microsoft's .NET, and of course WebLogic. WebLogic is of particular interest in that it has passed the 6000+ tests necessary for Sun to certify it as J2EE compatible.

This book is a discussion of the techniques and concepts involved in administering BEA WebLogic server. It is perhaps worth emphasizing that it is not a discussion of the design or development of those applications that will be run on the server. Those topics are covered only as they relate to the administration of the server.

The Underlying Technologies

Just as it is possible for people with few programming skills to administer Apache or IIS, it is possible to competently administer WebLogic without being an expert Java developer. However, in order to make informed administrative decisions, it is a good idea to have a basic understanding of the technologies that the server is intended to support. This section introduces these technologies.

Java

The cornerstone of all WebLogic applications is the Java™ programming language. Java is an object-oriented programming language developed by Sun Microsystems. Java has become the de facto standard for modern software development for a number of very sound reasons.

• Implementations of Java are freely available for virtually all available computing platforms.

• These implementations support well thought-out extensions to the language such as AWT and Swing that define GUI and multimedia components to do just about anything. In fact, Java programming is not so much a matter of “developing objects” as it is of knowing where to locate existing objects that already do what you want.

• Finally, and perhaps most important: Java is the most portable programming language ever implemented. Traditional computer languages are translated from the source code written by the programmer into a binary language of operation codes and their operands that can be run directly by a machine, a process known as compilation. While it is possible to write source code that can be run on most machines, the binary version that is ultimately executed by the CPU is very platform specific.

Until Java came along, portability was a heavy limitation on the kinds of content that could be deployed over the Internet. Because there is no way for a Web server to know what sort of operating system its' client processes are running on, the Web server was unable to pass executable code to them—at least, not with any expectation that they might be able to run it.

Java code, by contrast, is not compiled into platform-specific binary executables. When you compile a Java application, the source code is translated into an intermediate form known as byte code. The byte code is in turn translated into machine-specific executable instructions by a second program, the Java Virtual Machine. Because all Java Virtual Machines read the same set of byte code, a server can deploy programs (known as “applets”) with a much broader range of functionality than was previously possible.

All modern Web browsers are capable of executing Java byte code.

J2EE

The Java 2 Enterprise Edition is an extension of the Java 2 development platform intended to facilitate and standardize the development of distributed enterprise applications. The J2EE specification includes definitions of the following APIs that are of particular interest to us:

RMI/IIOP

JNDI

JDBC

JMS

JDBC

JDBC stands for Java DataBase Connect. It is an extension of the Java language designed to serve as a translator between a Java application and a database. JDBC extensions are available for every database implementaion of any significance, whether commercial (Oracle, Informix) or open-source (MySQL, Postgres). Frequently, the only interaction between the Application and third- or data tiers of your application will be via JDBC.

Java Servlets

Java Servlets, or JSPs, are analogous to the CGI programs of the early Web era. They are executable applications written in Java. They reside on the server side of a Web application and dynamically generate content (frequently HTML code) that can be interpreted and displayed by a client Web browser.

EJB

Enterprise JavaBeans, or EJBs, are a collection of Java classes that conform to Sun's published design specifications.

Entity Beans

Entity beans are maps to a database table that implement an object view of that table. Because they are an interface between the client and the underlying data store, they must always be stateful. The instantiated values of the bean must be synchronized with the underlying data store. Depending on whether this synchronization is handled by the container or the bean, entity beans are characterized as either container-managed persistence (CMPs) or bean-managed persistence (BMPs).

Session Beans

Session beans are an EJB associated with a particular client session. They are created with the client session and destroyed with it as well. Session beans are classified as stateful or stateless depending on whether or not they retain information about the state of the client process across invocations.

XML

The eXtensible Markup Language (XML) can be thought of as the next step in the evolution of HTML. Both HTML and XML are tools for defining information about information. If you are familiar with HTML, the open and close tags of an XML file will look familiar to you:

<OUTER>
<INNER>
Content.
</INNER>
</OUTER>

The difference is in the types of information that the tags define. The design of HTML addresses a single purpose—providing a shorthand for describing the content of Web pages. The possible tags under HTML are rigidly defined by a standards board.

As the name implies, XML is designed to be extended. The tags of an XML document may describe any kind of information. They are defined on an as-needed basis and thus in effect are infinite.

You may be saying to yourself, “That's all well and good, but having an infinite language is effectively the same as having no language at all.” How does the machine know what to do with an XML document? Good question. The look, feel, and to a certain extent the use of an XML document are defined by a companion document called a stylesheet.

XML is of particular interest to WebLogic administrators in that the configuration of the WebLogic server is defined in an XML document. The administration console that you use for most of your WebLogic configuration is, in essence, a program for manipulating the XML configuration files.^[1]

^[1] Hand editing of XML configuration files is conceivable but strongly discouraged.

JNDI

The Java Naming and Directory Interface is a naming service. Its purpose is to associate human-readable text labels with computational resources found in the Java environment. As the name implies, JNDI is divided into two primary areas of functionality:

JNDI is used as a front end to one or more service providers. (See Figure I-1). A service provider can be any program for which a JNDI-compliant interface exists. In practice, it's usually one or more of the following:

WebLogic serves as the naming and directory manager. The naming and directory manager is responsible for requests for resources to the appropriate location in the tree and returning the results.

Context

Another term that you'll see cropping up frequently when JNDI is under discussion is context. A context is the actual run-time connection through which your application sends and receives JNDI data. Contexts are obtained by the application from a context factory. A context factory is a specialized element of JNDI that is responsible for creating client-server connections.

Implementation

You as the administrator don't have to worry much about how JNDI is implemented. However, just for illustration, I'll provide a brief description of the process here.

WebLogic has its own JNDI tree. Before any resource can be used, the developer must first obtain access to that tree and associate the object that will be used with it. This process is known as binding.

At run time, the application will be passing to the context factory information like the URL of the bound object it is attempting to access, perhaps a user name and password, and the protocols that the two programs will be using to communicate.

JNDI and Clustering

In order for a WebLogic cluster to function, each server in the cluster must be aware what resources exist on the other servers in the cluster. Each time a server joins a cluster, the cluster's JNDI tree is updated to include copies of the resources of the new server. The updated tree is then pushed out to each server in the cluster.

Obviously, a ubiquitous naming scheme will be of little value in situations where the object to which the name refers is no longer available. For this reason, it is recommended that mission-critical objects be deployed on multiple servers.

RMI

Remote Method Invocation is the Java mechanism for enabling processes running on one Java Virtual Machine to access objects from another JVM. Usually this access occurs across a network, though not necessarily. You can envision circumstances where JVM-1 accesses something from JVM-2 running on the same physical computer but in a different CPU. Actually, you can even have a JVM access its own methods via RMI. Not that you'd want to, mind, but it can be done.

RMI comes with Java, but WebLogic ships with an inhouse version that has been optimized for the WebLogic operating environment. In particular, weblogic.rmi has more efficient network calls to prevent performance drag during clustered object replication.

A feature of RMI is that at the implementation level, all procedure calls appear to be local. The client machine houses enough code for each method that the procedure appears to reside on the local machine. These code snippets, called stubs, are actually just a front end for RMI. (See Figure I-2.) They accept the parameters passed in my method calls and pass them across the RMI interface to the remote server. On the server side, the back ends of the stubs (called skeletons) analyze the parameters that were passed in and return any results across the network to the client.

In most cases you will be happier running the WebLogic RMI than the Java RMI. The WebLogic RMI has the following advantages:

• The WebLogic RMI is started automatically by the server.

• The Java RMI must be compiled by hand, but the WebLogic RMI automatically compiles at run time.

• The WebLogic RMI is optimized for network communications. All the RMI traffic is passed through a single socket connection, which eliminates a significant amount of network overhead.

• If, for whatever reason, a method that resides on the local server is called via RMI, the WebLogic RMI is bright enough to circumvent the stubs and skeletons and just call it as a local method. The Java RMI is not.

Introduction to BEA Concepts

This section is intended as a gentle introduction to the terms and concepts you will encounter when administering WebLogic.

Domain

In the language of WebLogic, a domain refers to a collection of one or more WebLogic servers managed as a unit. Regardless of the number of servers in a domain, exactly one of them must be acting as the Administration Server. All other servers in the domain are referred to as managed servers.

Multiple domains may exist on the same machine. Each domain is defined in a directory under the config directory in your WebLogic server installation. The name of the directory is the name of the domain. (See Figure I-3.)

The BEA home directory is the home directory for all BEA software installed on your machine.

The install directory is the directory under which the WebLogic server has been installed. Typically, the install directory is a subdirectory of the BEA home directory. However, it is possible to put the install directory somewhere else. For instance WebLogic server version 6.1 SRH has an install directory of wlserver6.1. The general term install directory will be used interchangeably with the directory wlserver6.1 in the discussions.

config.xml

The domain's configuration is maintained in a configuration file config.xml located in the home directory of that domain.

A domain is described as active if an Administration server that controls its configuration file used that configuration file when it was started.

Administration Console

As I mentioned earlier, the Administration console is the resource you will utilize most often when administering WebLogic server. It is a Web-based application, accessible on both versions 6.x and 7.x by entering a URL like:

http://servermachine:7001/console

Of course, the word servermachine will need to be replaced by an actual server name or IP address. That will bring up either a screen like Figure I-3 for WebLogic Server versions 7.x.

Or, for versions 6.x, a screen with a different color scheme but largely similar functionality. (See Figure I-4.)

Obviously, you can't get to the server console until your WebLogic server instance is installed. The installation process is discussed in detail in Chapter 2.

We note here several important things about the Administration console. First, it is broken up into left and right panes, separated by a horizontal divider positioned about one-third of the way across the screen. The content of the left pane will always be more or less the same, though the individual elements in the tree can be expanded and contracted. The content in the right pane is dependent on what was most recently clicked in the left pane.

The left pane consists largely of labeled icons that look like little file folders. In this book, when I use the term folder, I'm referring to the folder icons in the left pane of the administration console. Note also that the contents of the left pane are sometimes referred to as the tree, for the hierarchical nature of the organization.

Accessing Online Help

BEA provides pretty good how-to documentation that ships with WebLogic server. In particular, there are step-by-step instructions for most of the administrative tasks, and explanations of some of the data entry fields on the administration console. This help information can always be accessed by clicking on the question-mark icon to the left of a field in the right pane of the administration server console.

In WebLogic Server versions 6.x, the help screens were mostly just plain text. In WebLogic version 7 and above, the screens had more hypertext and, as an added bonus, frequently better quality documentation.

Conventions of This Book

This book is broken into chapters according to the administration technique or concept that is under discussion. For example, there is a chapter on installation, another on starting and stopping, another on clustering.

The success or failure of any given WebLogic configuration depends on the internal server configuration, the application code, the configuration of the underlying operating system, and the vagaries of the network support services. Given that, it is, in fact, impossible to say with absolute certainty that the examples presented herein will run on your particular machine. However, you have my solemn vow that I typed each and every one of them in and they worked for me.

Typographical Conventions

Example commands and directives are printed in bold type and centered:

						Example Text
					

Important terms and concepts which occur in the flow of the text are set off by boldface type. Directory paths and file names which occur in the flow of the text are in Courier New typeface with bold type: /sample/directory or filename.

Because we will spend much of the book talking about networking concepts, it's probably worth explicitly defining my notation here.

Recap

This book's purpose is to give you the information necessary to intelligently administer WebLogic server. It's purpose is not to duplicate the online documentation provided with the WebLogic server distribution. WebLogic server is a J2EE-compliant server that makes use of the following APIs and technologies: JDBC, JNDI, RMI/IIOP, EJBs, and XML.