Description

• The definitive guide to administering WebLogic Server 7!
• Maximizing performance, reliability, and efficiency
• Covers architecture, domains, clustering, JDBC, JMS, monitoring, and much more
• Includes 90-day trial version of WebLogic Server 7

WebLogic Server 7 administration complete: Maximizing efficiency, reliability, and performance.

BEA WebLogic Server Administration Kit is the definitive guide to administering BEA WebLogic Server 7! Scott Hawkins starts where the documentation leaves off, illuminating crucial concepts and offering practical guidance for maximizing the performance, reliability, and efficiency of any WebLogic Server system. Unlike previous books on BEA WebLogic Server, this book is 100% focused on administration—and it presents essential techniques you simply won't find anywhere else. Coverage includes:

• Installing, starting, and stopping WebLogic Servers
• Defining effective Web Logic Server architectures
• Establishing and managing WebLogic Server domains
• Managing HTTP services
• Creating and working with WebLogic Server clusters
• Configuring and managing JDBC and JMS
• In-depth coverage of monitoring and performance tuning

The accompanying CD-ROM contains a 90-day trial version of BEA WebLogic Server 7.0, the latest version of BEA's award-winning Java application server for developing, deploying, and managing Web applications with maximum scalability, performance, and fault tolerance.

Sample Content

Downloadable Sample Chapter

Download the Sample Chapter related to this title.

Table of Contents

Introduction.


1. Installation.

Introduction. Platform Issues. Version 6.x GUI Installation. Command-Line Installation. Version 7.x GUI Installation. Recap.

Introduction. Windows Application Start. Windows Service Start. Scripted Start. Command-Line Start. Remote Start. Stopping the Server. Recap.

Introduction. Creating a New Domain. Adding a Managed Server. Adding a Managed Server. Part 2-On the Managed Server Side. Recap.

Introduction. Basic Architecture. Multiple-Tier Architecture. Proxies. Recap.

Introduction. HttpProxyServlet. Apache. Netscape. IIS. Parameters. Recap.

Introduction. Communication. HttpClusterServlet. HTTP Servers. Configuration. Cluster Operations. Configuration in WebLogic Server 7.x. Recap.

Introduction. Connection Pools. MultiPools. Data Sources.

Introduction. Administering JMS. Clustering JMS. Messaging Bridges. Recap.

Introduction. Performance Tab. SNMP. Configuring SNMP.

Introduction. Tuning the JVM. Tuning WebLogic Server. Execute Queues. Recap.

Introduction. SSL. 6.x Security. 7.x Security.

Preface

Introduction

This book is an introduction to the process of administeringthe BEA WebLogic server. It is intended as a supplement to the onlinedocumentation included with the server distribution and on the BEA Web site.While that documentation is frequently useful and sometimes complete, it canleave beginning administrators with the sense that they came in in the middleof the show. There are many unstated assumptions about the reader’sknowledge, and to the reader who lacks that knowledge the documentation can benearly impenetrable. The intent of this book is to fill those gaps.

This is not simply a bound collection of the how-to’sthat ship with the WebLogic server. Anyone who might conceivably have a needfor them already has them—they’re readily available online.

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

Note that this book addresses only the tasks involvedadministering the WebLogic server. It does not touch on the process ofdeveloping the Java™ programming language (Java) applications that willbe run on that server.

The Basics  WebLogicis an application server developed by BEA systems. If you’re in the ITindustry, you’ve probably heard the term “applicationserver;” it’s one of the buzzwords du jour. But what does it mean,exactly?

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

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

• Presentation tier This portion of the application accepts input from the user and formats data for display. Frequently this function is served by a Web-browser/Web-server collaboration. However, in the case of WebLogic you will see quite a few client applications written in Java or perhaps some other language.

• Application tier This is the domain of the WebLogic server. It is where the business logic of the application is implemented.

• Third tier The third tier contains the database and perhaps other legacy or third-party applications. Third-tier components should communicate with one another and the client only through the application tier.

Application servers include such products as CORBA,Microsoft’s .NET, and of course WebLogic. WebLogic is of particularinterest in that it has passed the 60001 tests necessary for Sun to certify itas J2EE compatible.

This book is a discussion of the techniques and conceptsinvolved in administering BEA WebLogic server. It is perhaps worth emphasizingthat it is not a discussion of the design or development of those applicationsthat will be run on the server. Those topics are covered only as they relate tothe administration of the server.

The Underlying Technologies

Just as it is possible for people with few programmingskills to administer Apache or IIS, it is possible to competently administerWebLogic without being an expert Java developer. However, in order to makeinformed administrative decisions, it is a good idea to have a basicunderstanding of the technologies that the server is intended to support. Thissection introduces these technologies.

Java  

The cornerstone of all WebLogic applications is theJava™ programming language. Java is an object-oriented programminglanguage developed by Sun Microsystems. Java has become the de facto standardfor 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 onthe kinds of content that could be deployed over the Internet. Because there isno way for a Web server to know what sort of operating system its’ clientprocesses are running on, the Web server was unable to pass executable code tothem—at least, not with any expectation that they might be able to runit.

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

All modern Web browsers are capable of executing Java bytecode.

J2EE  

The Java 2 Enterprise Edition is an extension of the Java 2development platform intended to facilitate and standardize the development ofdistributed enterprise applications. The J2EE specification includesdefinitions 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 ofthe Java language designed to serve as a translator between a Java applicationand a database. JDBC extensions are available for every database implementaionof any significance, whether commercial (Oracle, Informix) or open-source(MySQL, Postgres). Frequently, the only interaction between the Application andthird- or data tiers of your application will be via JDBC.

Java Servlets  

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

EJB  

Enterprise JavaBeans, or EJBs, are a collection of Javaclasses that conform to Sun’s published design specifications.

Entity Beans  Entitybeans 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 synchronizedwith the underlying data store. Depending on whether this synchronization ishandled by the container or the bean, entity beans are characterized as eithercontainer-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. Sessionbeans are classified as stateful or stateless depending on whether or not theyretain information about the state of the client process across invocations.

XML  

The eXtensible Markup Language (XML) can be thought of asthe next step in the evolution of HTML. Both HTML and XML are tools fordefining information about information. If you are familiar with HTML, the openand 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 tagsdefine. The design of HTML addresses a single purpose—providing ashorthand for describing the content of Web pages. The possible tags under HTMLare rigidly defined by a standards board.

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

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

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

JNDI  

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

• Naming services This portion of JNDI allows developers to make classes accessible to the network by name.

• Directory services Directory services are functionally very similar to name services in that you look up some property in a tree structure. The difference is that you can associate more than just the name property with an object.

JNDI is used as a front end to one or more serviceproviders. A service provider can be any program for which a JNDI-compliantinterface exists. In practice, it’s usually one or more of the following:

• LDAP The Lightweight Directory Access protocol.

• RMI Remote Method Invocation, a collection of Java packages that enable you to call classes housed on one Java Virtual Machine from another JVM located across the network.

• NIS Network Information Service, a Unix-centric mechanism for storing information about users, groups, and other OS elements in a central repository. In recent years the use of NIS has dropped off sharply due to security concerns.

• WebLogic WebLogic relies heavily on JNDI for its own operations. Recall that clustered resources are accessed via JNDI. In addition, the left pane of the console is effectively a visual representation of the JNDI hierarchy.

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

Context  

Another term that you’ll see cropping up frequentlywhen JNDI is under discussion is context. A context is the actual run-timeconnection through which your application sends and receives JNDI data.Contexts are obtained by the application from a context factory. A contextfactory is a specialized element of JNDI that is responsible for creatingclient-server connections.

Implementation  

You as the administrator don’t have to worry much abouthow JNDI is implemented. However, just for illustration, I’ll provide abrief description of the process here.

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

At run time, the application will be passing to the contextfactory information like the URL of the bound object it is attempting toaccess, perhaps a user name and password, and the protocols that the twoprograms will be using to communicate.

JNDI and Clustering  

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

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

RMI 

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

RMI comes with Java, but WebLogic ships with an inhouseversion that has been optimized for the WebLogic operating environment. Inparticular, weblogic.rmi has more efficient network calls to preventperformance drag during clustered object replication.

A feature of RMI is that at the implementation level, allprocedure calls appear to be local. The client machine houses enough code foreach method that the procedure appears to reside on the local machine. Thesecode snippets, called stubs, are actually just a front end for RMI. They acceptthe parameters passed in my method calls and pass them across the RMI interfaceto the remote server. On the server side, the back ends of the stubs (calledskeletons) analyze the parameters that were passed in and return any resultsacross the network to the client.

In most cases you will be happier running the WebLogic RMIthan 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 theterms and concepts you will encounter when administering WebLogic.

Domain  

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

Multiple domains may exist on the same machine. Each domainis defined in a directory under the config directory in your WebLogic serverinstallation. The name of the directory is the name of the domain.

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

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

config.xml  

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

A domain is described as active if an Administration serverthat controls its configuration file used that configuration file when it wasstarted.

Administration Console  

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

http://servermachine:7001/console

Of course, the word servermachine will need to be replacedby an actual server name or IP address.

Obviously, you can’t get to the server console untilyour WebLogic server instance is installed. The installation process isdiscussed in detail in Chapter 2.

We note here several important things about theAdministration console. First, it is broken up into left and right panes,separated by a horizontal divider positioned about one-third of the way acrossthe 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. Thecontent in the right pane is dependent on what was most recently clicked in theleft pane.

The left pane consists largely of labeled icons that looklike little file folders. In this book, when I use the term folder, I’mreferring 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 thetree, for the hierarchical nature of the organization.

Accessing Online Help  

BEA provides pretty good how-to documentation that shipswith WebLogic server. In particular, there are step-by-step instructions formost of the administrative tasks, and explanations of some of the data entryfields on the administration console. This help information can always beaccessed by clicking on the question-mark icon to the left of a field in theright pane of the administration server console.

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

Recap

This book’s purpose is to give you the informationnecessary to intelligently administer WebLogic server. It’s purpose isnot to duplicate the online documentation provided with the WebLogic serverdistribution. WebLogic server is a J2EE-compliant server that makes use of thefollowing APIs and technologies: JDBC, JNDI, RMI/IIOP, EJBs, and XML.

Index

Download the Index file related to this title.

Updates

Submit Errata