Cover | Table of Contents | Colophon

Table of Contents

Chapter 1: Introduction

Content preview·Buy reprint rights for this chapter

WebLogic Server is one of the leading J2EE application servers on the market today. It is a robust, mature, scalable implementation of the J2EE specification. It also lies at the heart of the WebLogic Platform, a unified, extensible platform for developing and deploying enterprise solutions such as enterprise information portals and systems integration solutions. This chapter provides an overview of WebLogic Server, and offers a perspective of its place within the WebLogic Platform. You'll also get a flavor of the various J2EE and enterprise features of WebLogic that you'll encounter in this book.

As you shall see, WebLogic offers much more than a full-fledged implementation of the J2EE standards. This chapter introduces some of the extensions to the J2EE technology stack, such as WebLogic's management framework and its robust support for web services. In addition, this chapter prepares the groundwork for the rest of the book, and helps you get started with using WebLogic Server.

WebLogic is a Java Application Server, a server-side Java program that provides a number of enterprise services for the benefit of the various applications and components running on the server. These services include the HTTP service, session handling, distributed naming and lookup, database access, persistence, transaction management, caching, concurrency, messaging, security, and much more. Server-side applications can use these services to implement their application logic, while external clients can either use the published services or directly interact with the applications. Once installed, WebLogic provides various command-line scripts for starting up the server. In fact, many of the WebLogic tools are Java programs that run within a console or as a GUI-based Java application. For this reason, stable releases of WebLogic Server are available on a wide range of platforms, including Windows 2000 Server/Professional, Windows XP, Solaris OS, Red Hat Linux, Tru64, HP-UX, IBM AIX, and other Unix variants.

WebLogic is designed to operate in a distributed environment. This means that you can easily set up an environment where multiple WebLogic instances are running on separate machines within the network, each configured with its own set of applications and services. Alternatively, you may need to design a "cluster" of WebLogic instances distributed across multiple machines over the network, each configured with the same set of applications and services. If you're blessed with powerful, multi-CPU machines, you even may opt to host multiple servers on a single machine. Moreover, WebLogic provides tools that enable you to set up these different scenarios and effectively manage the applications and other resources spread across all the servers. The ease and flexibility with which you can adapt your WebLogic configuration to suit your performance and scalability needs make WebLogic Server a very attractive platform for building real-world enterprise applications.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Overview of WebLogic Server

Content preview·Buy reprint rights for this chapter

WebLogic is a Java Application Server, a server-side Java program that provides a number of enterprise services for the benefit of the various applications and components running on the server. These services include the HTTP service, session handling, distributed naming and lookup, database access, persistence, transaction management, caching, concurrency, messaging, security, and much more. Server-side applications can use these services to implement their application logic, while external clients can either use the published services or directly interact with the applications. Once installed, WebLogic provides various command-line scripts for starting up the server. In fact, many of the WebLogic tools are Java programs that run within a console or as a GUI-based Java application. For this reason, stable releases of WebLogic Server are available on a wide range of platforms, including Windows 2000 Server/Professional, Windows XP, Solaris OS, Red Hat Linux, Tru64, HP-UX, IBM AIX, and other Unix variants.

WebLogic is designed to operate in a distributed environment. This means that you can easily set up an environment where multiple WebLogic instances are running on separate machines within the network, each configured with its own set of applications and services. Alternatively, you may need to design a "cluster" of WebLogic instances distributed across multiple machines over the network, each configured with the same set of applications and services. If you're blessed with powerful, multi-CPU machines, you even may opt to host multiple servers on a single machine. Moreover, WebLogic provides tools that enable you to set up these different scenarios and effectively manage the applications and other resources spread across all the servers. The ease and flexibility with which you can adapt your WebLogic configuration to suit your performance and scalability needs make WebLogic Server a very attractive platform for building real-world enterprise applications.

WebLogic provides a rich set of client options — it can interact with web clients that use HTTP, Java clients that use RMI-IIOP, JAX-RPC clients for web services over SOAP, and mobile devices that use WAP. It also provides comprehensive support for enterprise Java technologies. In fact, WebLogic is a fully certified J2EE application server. It means that you don't need to live under any illusions about the capabilities of WebLogic Server. At the very least, WebLogic will continue to support the full J2EE technology stack and adhere to all of the constraints that it imposes on interoperability. But WebLogic offers more and implements enterprise services that go beyond the J2EE standard, anticipating future trends in the enterprise Java application server market.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Software and Versions

Content preview·Buy reprint rights for this chapter

This book examines features and services of WebLogic Server. We've used WebLogic Server 8.1 SP 1, and WebLogic 7.0 SP 2. We recommend that you apply the latest service packs after installing WebLogic Server to ensure all known issues have been resolved. Most of the changes between WebLogic 7.0 and WebLogic 8.1 occur in the form of new features or in slight changes to the Administration Console. We have tried hard not to litter the book with sections relevant to only one particular version, or with distracting warnings about which features are in which version. Rather, we have tried to be discrete. So, for example, when we say at the beginning of a section that "WebLogic 8.1 introduces a new feature that ...," you can be sure that the feature is in WebLogic 8.1 only, and not in 7.0.

Customers can choose the particular edition of WebLogic Server that best suits their needs. If you intend to develop pure web applications that consist of static web resources and incorporate dynamic content through servlets and JSPs, you can perhaps opt for the WebLogic Express edition. If you need to build full enterprise systems using EJBs, JMS, and distributed transactions, you will need WebLogic Server instead. Each comes in two different flavors: versions that support clustering and versions that don't.

Your WebLogic distribution is shipped with a stable release of the J2SE SDK. WebLogic 8.1 ships with a 1.4 JDK, and WebLogic 7.0 with a 1.3 JDK. All shell scripts and batch command files within WebLogic reference the JRE contained within this JDK.

WebLogic Server is fully compliant with the J2EE 1.3 standard. This means that you can incorporate any other third-party custom components, such as JSP tags that conform to the JSP 1.2 specification or entity beans that conform to the EJB 2.0 standard. Moreover, WebLogic applications can interact with any LDAP server for which the vendor supplies a JNDI 1.1-compliant service provider. In addition, you can deploy any third-party resource adapter that conforms to the JCA 1.1 standard.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Getting Started with WebLogic Server

Content preview·Buy reprint rights for this chapter

As we've already seen, all WebLogic instances and their resources exist within the context of an organizational unit called a WebLogic domain. Within the domain, you can set up multiple servers, customize their network configurations, and deploy multiple J2EE applications and any required resources. You may even set up WebLogic clusters using a subset of the servers in the domain. All servers in the cluster can then work together to provide support for failover and load balancing.

One server in the domain is vital to its existence: the Administration Server that manages the configuration for the entire domain. This includes the configuration of all servers within the domain, and all applications and services deployed to these servers. Other servers in the domain, called Managed Servers, host the actual J2EE applications and resources such as JDBC connection pools, data sources, JMS connection factories, topics and queues, RMI objects, and so on. The Administration Server merely manages the entire configuration of these servers. In a single-server domain, you have little choice but to deploy your applications to the Administration Server itself. However, in a production environment, we recommend you deploy your applications to a separate server.

WebLogic is fairly flexible about how you configure the servers in the domain. So long as all Managed Servers in the domain can reach the Administration Server over the same network, WebLogic doesn't care whether the servers in the domain run on the same machine or on their own hardware.

Let's now quickly look at how to create a single-server WebLogic domain so that you can start the Administration Server. Once you're able to access the domain's configuration using the Administration Console, you know that you have a working WebLogic domain. This should be a good starting point for you to start building J2EE applications for WebLogic, and trying out any examples that you encounter as you read this book. Chapter 13 shows you how to expand on this configuration to build more complex domains.

In order to set up a running WebLogic instance that you can work with, you need to first create a WebLogic domain. When you've successfully done so, you can deploy your J2EE applications to the Administration Server itself. Later on, as you become more comfortable with WebLogic Server, you can add more servers to the domain and move your applications to the Managed Servers.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Chapter 2: Web Applications

Content preview·Buy reprint rights for this chapter

Many of today's enterprise applications implement a web frontend. They choose to expose their business functions via a web user interface, most often accessed from the client's browser. These applications may access other enterprise services such as XML transformers, JNDI, database resources, and connection factories to fulfill their service contracts. WebLogic Server provides the ideal environment for creating rich web applications — it offers an extensive range of tools for assembling and configuring web components. Like any servlet engine, WebLogic supports all the functionality needed to host multiple web applications, which we shall cover in detail in later chapters.

In this chapter, we look at the internal structure of web applications and their associated XML deployment descriptors. We shall see how WebLogic eases the task of building and assembling web applications, and examine some of the deployment issues of WebLogic Server. We also look at how you can configure the various web components.

We take a peek at WebLogic's JSP compiler, and then examine JSP configuration issues when deploying a web application. Custom JSP tags are a useful mechanism for adding dynamic content to a JSP page. WebLogic provides a number of tag libraries. One such tag library offers useful caching functionality. Similar caching functionality is made available in the form of a servlet filter. WebLogic also provides a tool that can automatically create a JSP tag library from EJB components.

You also will learn about WebLogic's servlet support, such as session tracking and session persistence. WebLogic provides a number of ways to persist session state. File-, memory-, and cookie-based persistence mechanisms are supported. When using servlets in a cluster, in-memory session replication also can be used. This chapter examines these mechanisms, and looks at how to set up a simple web cluster with session replication.

Finally, we look at various ways in which you can secure a web application using declarative and programmatic techniques. Setting up the HTTP over SSL (HTTPS) listen port and the associated SSL configuration is covered in Chapter 16. Chapter 3 concludes the discussion of the web environment — it describes how you can use and configure WebLogic's HTTP server and proxy plug-ins.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Packaging and Deployment

Content preview·Buy reprint rights for this chapter

As a J2EE-compliant web container, WebLogic Server can host a number of web applications. Each web application is a logical collection of servlets, JSPs, client-side applets, and static web resources such as HTML pages, images, multimedia documents, etc. In addition, a web application may use filters, JSP tag libraries, utility Java classes, and JavaBean components. Each web application is executed in its own runtime environment provided by the web container—a handle to this environment is provided by ServletContext. We refer to JSPs and servlets as web components. These web components also have access to external resources and WebLogic enterprise services such as deployed EJB components, JDBC data sources, JMS destinations, XML parser factories, and much more through access to ServletContext.

A web application is structured as a hierarchy of directories — the root directory serves as the document root for all resources in the web application. These directories contain all the JSPs, servlets, and other, static resources such as images that are referenced by the application. A special directory named WEB-INF holds all resources that aren't part of the public document tree of the application. So, a web client will not have direct access to any file stored under the WEB-INF directory, which is quite useful for protecting from clients specific resources in the web application. However, the contents of the WEB-INF directory are exposed to the server side. Both the methods getResource() and getResourceAsStream( ) of the ServletContext object and the forward( ) and include( ) methods of the RequestDispatcher object can access the contents of the WEB-INF folder.

The WEB-INF folder also includes the following files:

• A web.xml deployment descriptor, which is the standard J2EE XML document that describes the contents of the web application
• A weblogic.xml deployment descriptor, which contains the WebLogic-specific deployment information about the web application

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Configuring Web Applications

Content preview·Buy reprint rights for this chapter

The configuration for a web application deployed on WebLogic is spread across the application's deployment descriptors and the server configuration file. For instance:

• The session timeout for the web application can be configured using the session-timeout element within the standard web.xml deployment descriptor.
• The JSP compilation parameters for a web application are defined in the WebLogic-specific weblogic.xml deployment descriptor.
• The staging mode setting, which determines how a web application is deployed, can be found in the server's config.xml file.

The easiest approach to editing the deployment descriptors is to use either the Administration Console or WebLogic Builder. The following sections examine WebLogic-specific configuration settings related to web applications.

A web application is rooted at a specific path within the web server, called the context root. For example, if the context root for a web application is set to here, you could access it by using a URL of the form http://server:port/here/index.html. If you do not explicitly set a context root for the web application, its default value depends on how the web application has been packaged:

• If the web application is deployed in the exploded format, its default context root is the name of the folder that holds the contents of the web application.
• If the contents of the web application have been packaged as a web archive, its default context root is the name of the web archive itself. An example of this is if you deploy the web application myWar.war to WebLogic, you can invoke a resource — say, index.html — using the URL http://server:port/myWar/index.html.

There are two ways to configure the context root for a web application:

• If it is deployed as a standalone application, you can set the context-root element within the weblogic.xml descriptor for the web application:

  <weblogic-web-app>
    <context-root>

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Servlets and JSPs

Content preview·Buy reprint rights for this chapter

WebLogic supports HTTP servlets as defined in the Servlet 2.3 specification, as well as JSP pages and tag extensions as defined in the JSP 1.2 specification. Typically, you will use servlets alongside JSPs to build a web application. WebLogic provides a number of useful additions to standard servlet and JSP configuration. For example, you can assign custom execute queues to critical servlets, and install servlets to serve static files and act as a CGI gateway.

By default, all J2EE applications (except JMS resources) share the same pool of server threads for their operation. This includes the servlets and JSPs that rely on the default execute queue configured for a particular WebLogic instance. However, WebLogic also lets you assign a custom execute queue that is dedicated to an individual servlet (or JSP). In this way, you can ensure that a dedicated pool of threads is always available for a particular servlet and that it doesn't need to compete with other services for a free server thread. Execute queues are explained is more detail in Chapter 15.

To assign an execute queue to a servlet, you need to modify the weblogic.xml descriptor file to include a dispatch-policy element for the servlet. The value of this element should match the name of a preconfigured execute queue. Here is an example:

<servlet-descriptor>
  <servlet-name>FooServlet</servlet-name>
    <init-as-principal-name>system</init-as-principal-name>
    <destroy-as-principal-name>system</destroy-as-principal-name>
    <dispatch-policy>MyCustomExecuteQ</dispatch-policy>
</servlet-descriptor>

In this way, you can configure each servlet with its own execute queue, or perhaps even force multiple servlets to share the same execute queue.

When using multithreaded servlets, you must make adequate provisions for concurrent access within the service methods. Your servlet code needs to guard against sharing violations on access to shared resources and member variables. That said, wherever possible, avoid synchronization because it blocks other servlet threads until the current thread has completed. Limit sharing across threads by defining variables within the scope of the service methods. If you are accessing external resources such as databases, JMS destinations, etc., you need to synchronize on the class level, or whenever possible, encapsulate your work in a transaction.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

JSP Tag Libraries

Content preview·Buy reprint rights for this chapter

JSP tag libraries provide a simple, elegant way of embedding dynamic server-side request handling into a JSP page. WebLogic Server provides a tag library with custom tags that you may use in your JSP pages; this library defines the cache, repeat, and process tags. Other tags also are supplied, though these are not discussed, as much of their functionality can now be found in more standard tag library implementations, such as the Java Standard Template Library (JSTL). WebLogic also provides a tool to automatically generate a tag library for an EJB.

WebLogic's tag library JAR (weblogic-tags.jar) is located in WL_HOME/server/ext. It packages the tag library descriptor, the tag handler classes, and several other support classes. In order to use these tags in your JSP pages, you need to make the library available to your web application. Copy the JAR to the /WEB-INF/lib folder under the document root of the web application, and define a taglib element in the standard web.xml deployment descriptor:

<taglib>
  <taglib-uri>/weblogic-tags</taglib-uri>
  <taglib-location>/WEB-INF/lib/weblogic-tags.jar</taglib-location>
</taglib>

Now you can import the tag library into your JSP pages as follows:

 <%@ taglib uri="/weblogic-tags" prefix="wl" %>

Let's take a closer look at the features and capabilities of these three tags.

Section 2.4.1.1: The cache tag

The cache tag enables you to cache the output generated within the body of the tag. Because the output is usually some function of parameter or attribute values, the tag also allows you to cache the values of input parameters or attributes that uniquely generate a particular response. The caches are implemented using soft references to prevent the cache mechanism from hogging memory. Let's examine important attributes of the cache tag.

A cache tag may specify a unique name for the cache, if it is to be used across multiple JSP pages. A random name is generated if you do not specify one. By default, the

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Session Tracking

Content preview·Buy reprint rights for this chapter

HTTP is, by design, a stateless protocol. Many web applications require that a series of requests from a client be associated with one another. For example, an online store will need to maintain the state of a user's shopping cart across HTTP requests. The HttpSession object allows servlets and JSPs to manage client-specific state on the server. You can associate object-valued attributes to the HttpSession by name. Any object bound to the session is available to any other servlet within the same servlet context. You can even declare JavaBean components within JSPs that have session-wide scope.

In order to implement server-side HTTP sessions, WebLogic needs to associate session data across browser requests with the same client. This is done by associating a unique tag (called the session ID) with every client, and ensuring that this tag is transferred with every request. The mechanism by which WebLogic binds the client to its session data is called session tracking. WebLogic supports two mechanisms for tracking session-state information: cookies and URL rewriting.

Every J2EE-compliant servlet engine is required to support session tracking using cookies. When an HttpSession is created, a unique ID is associated with it. WebLogic then attempts to store the session ID by sending a cookie back to the client. Once a cookie is set, the browser will return the cookie on each subsequent request. The server then is able to parse the cookie and return the associated session object when you invoke the getSession( ) method on the servlet. The servlet specification demands that this session-tracking cookie be named JSESSIONID.

Section 2.5.1.1: Using cookies with SSL

Requests sent using HTTP and HTTPS use different ports, and some browsers treat the same address with different ports as two different locations. Hence a cookie created using one port may not be associated with the cookie using the other port. As a result, you may find new sessions being created when browser requests alternate between the HTTP and HTTPS protocols. To get around this problem, you need to configure the

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Session Persistence

Content preview·Buy reprint rights for this chapter

Session persistence involves persisting the data stored in the HTTP session object. This typically is done to support failover across a cluster of servers. For instance, if the session state is duplicated between two running servers, and if one goes down, the other server can take over and no data is lost. WebLogic supports five different mechanisms for persisting session state information:

Memory (single-server, nonreplicated)

The session data is stored on a single server in memory.

File

The session data is stored on a shared filesystem.

JDBC

The session data is stored in a database table.

Cookie-based

The session data is stored at the client end in a cookie.

In-memory replication

The session data is stored in memory on multiple servers.

By default, WebLogic stores session state information in memory in a nonreplicated manner. The other four persistence mechanisms are desirable when the web application is deployed in a WebLogic cluster. Session persistence allows WebLogic Server to support automatic session failover. Session failover ensures that a server failure remains transparent to the user — another server will seamlessly pick up the backup of the session data. Because the session data is now persistent and accessible to multiple server instances, session information isn't lost when the server goes down. Clearly, session persistence will be more expensive than just storing the session data in memory on a single server. The session caching mechanism can help alleviate this cost.

We will examine each persistence mechanism in detail later in this chapter, with a separate section dedicated to in-memory replication. Usually, any kind of Java object can be bound to the session. However, if you want to use session persistence, certain restrictions are imposed. If you have configured the session persistence to use either file, JDBC, or in-memory replication, an object must implement the java.io.Serializable interface before it can be bound in the session. If you have configured session persistence to use cookies instead, only strings may be bound in the HTTP session.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Clusters and Replicated Persistence

Content preview·Buy reprint rights for this chapter

Setting the persistence type to replicated enables WebLogic to replicate the session state in memory itself. Like the default memory persistence scheme, session data is stored in memory. Unlike the default memory persistence, this scheme works closely with the notion of primary and secondary servers in the cluster, as discussed later in Chapter 14. WebLogic creates the primary session state on the server that a client first connects to, and then transparently replicates the session-state information onto a secondary server instance. The process of copying session state from one server instance to another in the cluster is called in-memory replication. The replica is kept up-to-date so that the secondary server can take over when the original server instance that holds the session data fails.

In-memory session-state replication will work only for those object-valued attributes in the session that are Serializable objects. Changes to the session object will be replicated only if you use the setAttribute( ) and removeAttribute( ) methods on the HttpSession object. These methods ensure that any changes to the attributes of the session are mirrored onto the secondary server for the client. Remember that only nontransient attributes of an object in the session will be replicated to the secondary server. All transient attributes of the object will be ignored.

If you modify the state of an object stored in the session using another object reference, those changes will not be automatically replicated across. For instance, suppose you access a session attribute and modify its value as follows:

HttpSession session = request.getSession(false);
com.oreilly.user.AUser foo = (AUser) session.getAttribute("user");
foo.setName("Ali Cowan");

The changes to the AUser object will be replicated only if you subsequently invoke the setAttribute( ) method:

session.setAttribute("user", foo);

This means that changes to the session data are replicated only after explicit calls to either the setAttribute( )

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Configuring a Simple Web Cluster

Content preview·Buy reprint rights for this chapter

Whenever you deploy a web application to a WebLogic cluster, you need something sitting before the cluster (i.e., between the client and the cluster) that can direct incoming requests to the appropriate server that hosts the primary session state. There are many ways in which you can accomplish this:

Hardware load balancer

A hardware load balancer can be placed in front of the cluster. In this case, all client requests to the cluster must pass through the load balancer. The load balancer can distribute requests across the available members of the cluster, and direct requests involved in a session to the appropriate server holding the primary state.

Web server with proxy plug-in

A web server can be augmented with a proxy plug-in, a piece of software supplied with WebLogic that will redirect certain requests (for example, those to servlets and JSPs) through to the cluster. Clients accessing the web server then can be served up static content by the web server directly and transparently proxied through to the cluster behind the web server for the dynamic content.

WebLogic with the HttpClusterServlet

The HttpClusterServlet is an alternative to a proxy plug-in. A WebLogic instance can be configured to host the servlet, which can forward requests across to the cluster in the same way as the proxy plug-in.

The main ways in which you can architect your cluster and web tiers are discussed in much more detail in Chapter 14. Here we will give a brief introduction to setting up the HttpClusterServlet, leaving the configuration of the proxy plug-ins, an almost identical task, to Chapter 3.

As its name suggests, the HttpClusterServlet is a servlet. It is supplied with WebLogic. To put the servlet into action, create a simple web application with the servlet configured as part of the web application. You need to then deploy the web application to the machine that is going to serve as the main gateway to your cluster, as suggested by Figure 2-2.

Figure 2-2:

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Security Configuration

Content preview·Buy reprint rights for this chapter

WebLogic provides several ways to secure a web application:

• You can declaratively configure web authentication for clients that access your web application. You can restrict access to resources in a web application by applying security constraints to a collection of web resources.
• A servlet/JSP can programmatically check whether the client has sufficient privileges before executing a particular piece of code.
• You can programmatically log in a user, bypassing the standard J2EE mechanisms.

The login-config element in the standard web.xml deployment descriptor allows you to set up authentication for a web application. You can specify the authentication method using the auth-method element. WebLogic supports the following authentication methods:

HTTP basic authentication (BASIC)

Here the web server authenticates the client against the security realm using the supplied username and password combination.

Form-based authentication (FORM)

Here the client authenticates using a custom HTML form, which resembles:

<form method="post" action="j_security_check"> 
  <input type="text" name="j_username">
  <input type="password" name="j_password"> 
</form>

If you choose form-based authentication, you must specify the locations for the login page that initially will be displayed, and the error page that will be used when the user fails to authenticate himself. Use the form-login-page subelement to specify the login page, and the form-error-page subelement to specify the error page.

Here's a sample configuration for a web application that uses form-based authentication:

<!-- web.xml entry: -->
<login-config>
  <auth-method>FORM</auth-method>
  <realm-name>foo</realm-name>
  <form-login-config>
    <form-login-page>/login.html</form-login-page>
    <form-error-page>/error.html</form-error-page>
  </form-login-config>
</login-config>

Client certificates (CLIENT-CERT)

Here the web server authenticates the client using a client certificate or some form of perimeter authentication.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Monitoring Web Applications

Content preview·Buy reprint rights for this chapter

You can monitor web applications, and the servlets and JSPs contained in them, by using the Administration Console. Choose the Deployments/Web Application Modules to list each web application, together with its context root and deployment order. If you customize the view, you will be able to view further information, such as the security authentication realm associated with the web application and the servlet's reload period.

From the Servlets tab (the Monitoring tab in WebLogic 7.0), you can view statistics on each servlet, such as the number of times it has been invoked and its average execution time. You also can customize the view and obtain further information, such as the full classname of the servlet and the number of times the servlet was reloaded. By default, the servlet with the name /* is the FileServlet, which serves any request for static files. JSPs also are listed here because they, too, are servlets.

You can gather further statistics about sessions, but to do so you have to first enable session monitoring. You can do this by selecting the Sessions tab and enabling the option. You also can enable this option for a web application from its Configuration/Descriptor tab. Once you've enabled session monitoring, you can then view the list of active sessions from the Monitoring/Sessions tab. This includes data such as the session identifier, the server to which the session is bound, and at the time the session was last accessed.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Chapter 3: Managing the Web Server

Content preview·Buy reprint rights for this chapter

As a J2EE-compliant servlet engine, WebLogic Server is able to serve dynamic content through servlets, filters, JSPs, and custom tag libraries. It supports multiple web applications, each providing a distinct piece of functionality, and each having access to an array of configured enterprise services. It supports robust server-side session-state management, which is vital for constructing rich enterprise applications that use a client browser as their interface. It provides standard web authentication mechanisms to log in users and provides a secure operating environment. As a full-featured HTTP server, WebLogic also can be used as the primary web server for static content such as HTML pages, applets, images, multimedia files, etc.

WebLogic Server can do a lot more than just serve the static file contents of a web application. It supports many features found in other web servers, such as multiple virtual hosts, whereby a single WebLogic Server instance or cluster can host multiple web sites. Even though each logical web server has its own hostname, Domain Name Service (DNS) may map each of them to the same IP address (or cluster IP address). WebLogic extracts the hostname from the HTTP request headers, and redirects the request to the appropriate "web site." The same web application can then be targeted to multiple virtual hosts, as if it were deployed on separate web servers. In this chapter, we look at how to configure the web server and HTTP protocol, and how to create multiple virtual hosts. We also will look at how you can configure the logging of HTTP requests.

WebLogic Server also can integrate with other web servers, such as the Apache HTTP Server, Microsoft's IIS, and the NES. You can proxy HTTP requests for static content through WebLogic to another web server. Alternatively, you can install a native plug-in (provided by your WebLogic distribution) on the web server so that the web server forwards requests for servlets and JSPs to a WebLogic server or cluster. We examine both of these scenarios in this chapter.

We'll also see how a plug-in can function like the

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Configuring WebLogic's HTTP Server

Content preview·Buy reprint rights for this chapter

WebLogic's HTTP server forms an implicit part of its support for a number of different protocols. For example, it supports HTTP, HTTPS, T3, T3S, IIOP, and IIOPS. This chapter concentrates on its support for HTTP only, while Chapter 13 examines the other protocols. The HTTP protocol can be configured from the Administration Console by selecting the Server node from the navigation tree in the left frame, and then choosing the Protocols/HTTP tab from the right frame. As the next section will explain, identical HTTP settings can be configured for a number of virtual hosts as well. Table 3-1 lists the general settings for the HTTP server (or virtual host).

Table 3-1: Settings for configuring the HTTP server

Parameter	Description	Default
Default Server Name	Sets the hostname returned in the HTTP response header when the web server redirects a request.	none
Enable Keepalives	Use this to set HTTP keepalives. You generally want this set to true.	true
Duration	The number of seconds to wait before closing an inactive HTTP connection.	30
HTTPS Duration	The number of seconds to wait before closing an inactive HTTPS connection.	60

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Virtual Hosting

Content preview·Buy reprint rights for this chapter

Virtual hosting is the ability to run multiple web sites — say, www.domain1.com and www.domain2.com — on a single web server. Name-based virtual hosting implies that you map multiple domain names (or logical hosts) to the same IP address. The fact that both web sites run on the same server is not apparent to the clients. WebLogic Server allows you to create a virtual host for any number of different domain names. For instance, using DNS you could create two different domain names — v1.oreilly.com and v2.oreilly.com — pointing to the same physical WebLogic instance. On this single instance you can create two virtual hosts — say, v1 and v2.

If you have two virtual hosts, you can configure the web server to behave in the following ways:

• You can modify the HTTP behavior of each virtual host independently. For instance, each virtual host can have its own HTTP access logs.
• You can associate a different default web application with each virtual host in the same way that you associate a default web application with a WebLogic Server.
• You can target different WebLogic servers or clusters to different virtual hosts. For instance, if you have mapped different web applications to the virtual hosts, and targeted the web applications to different WebLogic servers, you can effectively target the virtual hosts to the appropriate servers.

Identical web applications are then isolated from each other when they are targeted to different virtual hosts.

The Servlet specification demands that each logical virtual host must have its own servlet context, and that servlet contexts cannot be shared across virtual hosts.

Before you set up virtual hosts on WebLogic Server, you need to ensure that you have mapped the desired domain names to the same IP address. In our earlier example, the DNS server would have mapped v1.oreilly.com and v2.oreilly.com to the machine's IP address. Now to create a virtual host, you need to perform the following steps from the Administration Console:

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

HTTP Access Logs

Content preview·Buy reprint rights for this chapter

HTTP access logs maintain a record of all HTTP requests received by WebLogic Server. You can separately configure HTTP logging for each web server or virtual host defined in your WebLogic domain. The information in the access logs may be written in one of two formats: either the Common Log Format or the Extended Log Format. The Common Log Format is the default format based on standard conventions. The Extended Log Format enables you to customize the information that is recorded in the access logs.

To configure the HTTP logging facilities for a web server, start the Administration Console, then go to the Servers node in the left frame and choose the Logging/HTTP tab. To configure logging for a virtual host, select the host from the Services/Virtual Hosts node and then choose the Configuration/Logging tab. Note that the logging facilities also include a "log rotation" mechanism, which means that WebLogic Server continues to use a log file until its size reaches a certain limit or for a certain time period. After that, WebLogic renames the log file and creates a new one in its place. Table 3-4 provides a description of the configuration settings for the HTTP logging facility.

Table 3-4: Configuration settings for HTTP logging

Parameter	Description	Default
Enabled HTTP Logging	This setting enables logging of HTTP requests for the particular server or virtual host.	true
Log File Name	This setting determines the filename to which the log messages are written. If you provide a relative filename, it is assumed to be relative to the root directory of the machine on which the server or virtual host is running.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Understanding Proxies

Content preview·Buy reprint rights for this chapter

Even though WebLogic Server can operate as a full-featured HTTP 1.1 server, its real power lies in its ability to serve dynamic content through servlets and JSPs. A number of companies have adopted commercial web servers to host their corporate web sites. WebLogic provides integration with these web servers in the form of a web server proxy plug-in. This plug-in allows the web server to communicate with the WebLogic Server (or cluster). You then can have the web server serving up the usual static content, while it passes requests for JSPs and servlets to WebLogic. A proxy plug-in offloads the task of serving static content to a commercial web server.

Here are the various architectural scenarios you should consider:

• You could use WebLogic's built-in web server as your primary HTTP server, eliminating the need for other web servers.
• You can have WebLogic Server act as the primary HTTP server and servlet engine; additionally it proxies through certain requests for static requests to a commercial web server.
• You can have a commercial web server acting as your primary HTTP server; additionally it transparently proxies requests for servlets and JSPs through to WebLogic.

The choice of which configuration you adopt is largely dependent on the type of content being served up, the performance of the various HTTP servers, and other deployment parameters. For instance, if you are serving up mostly dynamic content (using JSPs and servlets), a pure WebLogic solution should be sufficient. If you are integrating with an existing framework, proxying to WebLogic Server may work better.

We have already seen how to establish WebLogic as your primary web server, including the configuration of virtual hosts. The following section shows how you can extend this by configuring WebLogic to proxy to a secondary web server. For more information on how to set up a web tier, refer to Chapter 14.

WebLogic Server can be configured so that its built-in web server services requests for servlets and JSPs, while other requests for static web resources are redirected to a secondary server. This approach ensures WebLogic primarily handles all dynamic requests, while requests for static files are handled by some other web server. In order to implement this scenario, you need to configure an

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Web Server Plug-ins

Content preview·Buy reprint rights for this chapter

Let us now examine the scenario where an industry-strength web server is configured as the primary HTTP server, proxying certain client requests (usually requests for servlets and JSPs) through to WebLogic Server. WebLogic implements this configuration by providing web server plug-ins that augment the primary server with proxying logic. As mentioned in Chapter 2, a proxy plug-in enhances the web server by allowing it to delegate requests for dynamic content to WebLogic Server. Currently, WebLogic supports plug-ins for three web servers: the Apache HTTP Server, IIS, and NES.

The web server continues to serve static content, such as HTML pages, images, text files, and other web resources, and uses the plug-in to redirect requests for servlets and JSPs to WebLogic Server, which may be running on a different process, or may even be located on a different host. This internal delegation of requests for dynamic content to WebLogic Server occurs transparently. The client browser remains unaware of the existence of WebLogic Server. Configuring the proxy plug-in is a two-stage process:

1. First, the proxy plug-in has to be installed on the web server. Refer to the WebLogic documentation for more information on how to install the plug-in on your web server. After that, you need to specify the conditions under which the web server will delegate client requests to the plug-in.
2. Second, the proxy plug-in itself has to be configured. You must supply a list of name-value pairs that define the behavior of the web server plug-in.

Let us now look at some of the issues you need to consider when configuring proxy plug-ins on web servers.

The rest of this section looks at how to use a proxy plug-in in general. In particular, we discuss how to configure the plug-in for the popular Apache 2.0 HTTP Server. The same configuration issues apply to proxy plug-ins for other well-known web servers. The only major change lies in how you set up the plug-ins on these servers. For instance, Apache's web server requires you to simply edit its configuration file, while Microsoft's IIS provides a GUI Console to establish the plug-in configuration. Though the exact syntax and configuration mechanism may differ, the overall intent and functionality remain unaltered. Refer to WebLogic's documentation for more information on how to install and configure the proxy plug-in on other supported web servers.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Chapter 4: Using JNDI and RMI

Content preview·Buy reprint rights for this chapter

The Java Naming and Directory Interface (JNDI) provides a standard way of accessing naming and directory services. The API describes how objects can be bound in a distributed directory service, and how clients of the directory can locate and retrieve these objects. It plays a critical role in any J2EE environment, providing the central naming and directory service API used by containers, J2EE resources, deployed applications, and external clients.

JNDI has an open architecture that permits the integration of a number of different implementations of directory services. These service provider implementations map vendor-neutral JNDI calls to the operations supported by the underlying directory service. For instance, your Java SDK distribution comes equipped with service providers for LDAP, CORBA Naming Services, and Java's Remote Method Invocation (RMI) Registry. Other service providers are also available for Sun's Network Information Service (NIS), Novell's Network Directory Service (NDS), DNS, and Windows Registry. Everything from Java objects to email addresses can be stored in the various types of directories, making them useful for a variety of things. In fact, WebLogic uses an embedded LDAP repository to store security information about WebLogic users, groups, security policies, and much more. The JNDI provides a standard interface to all of these types of directory services, and in WebLogic you will find a robust, distributed JNDI implementation that provides the naming and directory support for all J2EE applications.

WebLogic's JNDI implementation is used primarily as the standard J2EE mechanism that allows clients to publish, locate, and retrieve objects in a distributed fashion. For instance, when a JDBC data source or EJB is deployed, it is made available in a global JNDI tree, bound to its configured JNDI name. A Java client then can use the JNDI name to look up and gain access to the resource. Other J2EE resources such as JMS connection factories, JTA transactions, and RMI objects also may be bound in the JNDI tree.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Using WebLogic's JNDI

Content preview·Buy reprint rights for this chapter

Each WebLogic server maintains a local JNDI tree. Typically, you will bind various J2EE resources to the JNDI tree, such as JDBC data sources, EJB home objects, JMS connection factories, and more. You can use the Administration Console to view the contents and structure of the JNDI tree on a server. Select a server from the left frame of the Administration Console, right-click the server node, and choose the "View JNDI tree" option from the pop-up menu. This launches a new window that displays the contents of the JNDI tree for the selected server. You can now navigate the JNDI tree and view the various objects bound to it.

In the following sections, you will learn how to programmatically establish a connection to WebLogic's JNDI server, from both an external client and an internal J2EE component, and how to use the connection to locate and bind objects. As the JNDI tree also permits authorization policies, we also will look at a few security issues surrounding the use of a JNDI tree.

In order to access WebLogic's JNDI tree, you need to establish a standard JNDI InitialContext representing the context root of the server's directory service. You can do this by passing a Hashtable of property/value pairs to the javax.naming.InitialContext( ) constructor. The Hashtable represents environment properties that are used to establish the context; in an external client, you typically will need to supply at least a URL property that points to a server you wish to access, and a context factory class that represents the service provider to use in the construction of the context.

Example 4-1 shows how a Java client can obtain an initial JNDI context to a WebLogic Server.

Example 4-1. Obtaining the initial JNDI context

import javax.naming.*;

private static InitialContext ctx = null;
...
public static InitialContext getInitialContext( ) throws NamingException {
  if (ctx == null) {
    Hashtable env = new Hashtable( );
    env.put(Context.INITIAL_CONTEXT_FACTORY, 
            "weblogic.jndi.WLInitialContextFactory");
    env.put(

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Using JNDI in a Clustered Environment

Content preview·Buy reprint rights for this chapter

WebLogic's JNDI implementation can be used in a clustered environment. Indeed, it is JNDI that provides the bedrock of many of WebLogic's clustered services. For instance, an EJB may be deployed to a number of servers in an object-tier cluster. Servlets in the web tier can look up the EJB in the object tier's JNDI and obtain access to one of the servers hosting the EJB; context objects even can use load-balancing logic to choose a server instance. When an EJB is deployed to several servers in the clustered object tier, the JNDI tree is updated with a cluster-aware EJB stub that records the location of each server instance hosting the EJB. Moreover, this knowledge is automatically distributed throughout the JNDI trees in the cluster. This magic is implemented partly by WebLogic's clustered JNDI implementation, which we will now look at.

In a clustered environment, an object may be bound to the JNDI tree of an individual server, or it may be replicated and bound to all servers in the cluster. If the JNDI binding manifests in one server only, a client must explicitly connect to that server when establishing the initial context, as discussed earlier. In most cases, the JNDI binding actually will be replicated to all servers in the JNDI tree, in which case you need only specify a name representing the WebLogic cluster, not an individual server member. When creating an initial context to a cluster, WebLogic automatically chooses between the members of the cluster and creates a single context to that one member.

The next example shows how a client can look up an object that is available to a cluster-wide JNDI tree:

Context ctx = null;
Hashtable env = new Hashtable( );
env.put(Context.INITIAL_CONTEXT_FACTORY, 
         weblogic.jndi.WLInitialContextFactory");
env.put(Context.PROVIDER_URL, "t3://mycluster:8001");

//connect to the cluster-wide JNDI tree 
ctx = new InitialContext(env);
//now use the JNDI Context to look up objects

In this case, the value for the PROVIDER_URL property uses the DNS name mycluster, which resolves to the addresses of each server in the cluster.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Using WebLogic's RMI

Content preview·Buy reprint rights for this chapter

RMI is the standard model for distributed object programming in Java. Using RMI, a Java client can access a remote object seamlessly on another JVM, and invoke methods on the object as if it were located within the client's JVM. In addition, RMI incorporates various reference semantics for remote objects, such as lazy activation, live (or nonpersistent) references, and persistent references.

WebLogic RMI is an integral part of the server framework. It enables a Java client to transparently access RMI objects that live on WebLogic Server. This includes access to any EJB components and other J2EE resources that have been deployed to WebLogic. It allows you to build fast, reliable, standards-compliant RMI applications. It also incorporates support for load balancing and failover when RMI objects are deployed to a WebLogic cluster. WebLogic RMI is fully compatible with the RMI specification, but provides extensions not available under the standard RMI implementation. Here's a brief overview of some of the extra benefits of using WebLogic's version of RMI.

Performance and scalability

WebLogic incorporates a highly optimized implementation of RMI. It handles all the implementation issues that relate to the support for RMI: managing threads and sockets, garbage collection, and serialization. Standard RMI relies on separate socket connections between the client and the server, and between the client and the RMI Registry. WebLogic RMI multiplexes all this network traffic onto a single socket connection between the client and the server. The same socket connection is reused for other kinds of J2EE interaction as well, such as JDBC requests and JMS connections. By minimizing the network connections between the client and WebLogic, the RMI implementation is able to scale well under load, and support a large number of RMI clients simultaneously. It also relies on high-performance serialization logic. All these features mean a significant performance gain in client-server communication.

In addition, WebLogic automatically optimizes client-server interactions when the client runs within the same VM as the RMI object. It ensures that you don't incur any performance penalty because of marshalling or unmarshalling of arguments during a call to a remote method. Instead, WebLogic uses Java's pass-by-reference semantics when the client and the server object are collocated, and when the class-loader hierarchy permits it.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Using WebLogic's RMI over IIOP

Content preview·Buy reprint rights for this chapter

RMI over IIOP (or RMI-IIOP) enables Java-based RMI objects to interoperate with CORBA-based application components. By using the OMG standard IIOP as the underlying transport protocol, Java clients can invoke CORBA objects, and likewise, CORBA clients can remotely invoke RMI objects. CORBA components may be written in a variety of languages, including C++, Smalltalk, Java, COBOL, and many more. RMI-IIOP combines the ease of use of RMI with cross-language interoperability provided by the CORBA/IIOP architecture.

WebLogic's RMI-IIOP implementation provides several options for implementing Java-based RMI and CORBA/IDL clients:

Standalone RMI clients

You can implement an RMI client that uses the JDK's IIOP imp