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 themat 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 purposeproviding 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:

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 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:

Figure I-1. JNDI in a WebLogic Environment

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. 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.

Figure I-2. Stubs and Skeletons

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.