Mastering BEA Weblogic Server: Best Practices for Building and Deploying J2ee Applications

Overview

  • Designed to show experienced developers how to become power developers with BEA WebLogic
  • Covers BEA WebLogic Server version 8.1 and earlier versions
  • A perfect companion to the bestselling book, Mastering Enterprise JavaBeans, Second Edition (0471-41711-4)
  • Companion Web site includes technology updates and links to related sites
Read More ...
See more details below
Other sellers (Paperback)
  • All (29) from $1.99   
  • New (6) from $26.41   
  • Used (23) from $1.99   
Sending request ...

Overview

  • Designed to show experienced developers how to become power developers with BEA WebLogic
  • Covers BEA WebLogic Server version 8.1 and earlier versions
  • A perfect companion to the bestselling book, Mastering Enterprise JavaBeans, Second Edition (0471-41711-4)
  • Companion Web site includes technology updates and links to related sites
Read More Show Less

Product Details

  • ISBN-13: 9780471281283
  • Publisher: Wiley, John & Sons, Incorporated
  • Publication date: 8/25/2003
  • Edition number: 1
  • Pages: 768
  • Product dimensions: 7.38 (w) x 9.24 (h) x 1.92 (d)

Meet the Author

GREGORY NYBERG is a technical architect, focusing on the development of enterprise J2EE applications using BEA WebLogic Server.

ROBERT PATRICK is Senior Director of Technology at BEA Systems, specializing in designing and troubleshooting large-scale systems built with BEA WebLogic Server.

PAUL BAUERSCHMIDT is a former software engineer in the WebLogic Server Security Team at BEA Systems.

JEFF McDANIEL is Senior Director of the Technical Solutions Group at BEA Systems.

RAJA MUKHERJEE is Director of Systems Engineering at BEA Systems.

Read More Show Less

Read an Excerpt


Mastering BEA WebLogic Server



Best Practices for Building and Deploying J2EE Applications


By Gregory Nyberg Robert Patrick Paul Bauerschmidt Jeff McDaniel Raja Mukherjee


John Wiley & Sons



Copyright © 2003

Gregory Nyberg, Robert Patrick, Paul Bauerschmidt, Jeff McDaniel, Raja Mukherjee
All right reserved.



ISBN: 0-471-28128-X



Chapter One


Building Web Applications
in WebLogic

Web applications are an important part of the Java 2 Enterprise Edition (J2EE) platform
because the Web components are responsible for key client-facing presentation and
business logic. Apoorly designed Web application will ruin the best business-tier components
and services. In this chapter, we will review key Web application concepts and
technologies and their use in WebLogic Server, and we will provide a number of recommendations
and best practices related to Web application design and construction
in WebLogic Server.

This chapter also provides the foundation for the discussion of recommended Web
application architectures in Chapter 2 and the construction and deployment of a complex,
realistic Web application in Chapters 3, 4, and 5.


Java Servlets and JSP Key Concepts

In this section we willreview some key concepts related to Java Servlets and
JavaServer Pages. If you are unfamiliar with these technologies, or if you need additional
background material, you should read one of the many fine books available on
the subject. Suggestions include Java Servlet Programming Bible by Suresh Rajagopalan
et. al. (John Wiley & Sons, 2002), Java Servlet Programming by Jason Hunter (O'Reilly &
Associates, 2001), and Core Servlets and JavaServer Pages by Marty Hall (Prentice Hall
PTR, 2000).


Characteristics of Servlets

Java servlets are fundamental J2EE platform components that provide a
request/response interface for both Web requests and other requests such as XML
messages or file transfer functions. In this section, we will review the characteristics of
Java servlets as background for a comparison of servlets with JavaServer Pages (JSP)
technology and the presentation of best practices later in the chapter.


Servlets Use the Request/Response Model

Java servlets are a request/response mechanism: a programming construct designed to
respond to a particular request with a dynamic response generated by the servlet's specific
Java implementation. Servlets may be used for many types of request/response
scenarios, but they are most often employed in the creation of HyperText Transfer Protocol
(HTTP) responses in a Web application. In this role, servlets replace other HTTP
request/response mechanisms such as Common Gateway Interface (CGI) scripts.

The simple request/response model becomes a little more complex once you add
chaining and filtering capabilities to the servlet specification. Servlets may now participate
in the overall request/response scenario in additional ways, either by preprocessing
the request and passing it on to another servlet to create the response or by
postprocessing the response before returning it to the client. Later in this chapter, we'll
discuss servlet filtering as a mechanism for adding auditing, logging, and debugging
logic to your Web application.


Servlets Are Pure Java Classes

Simply stated, a Java servlet is a pure Java class that implements the javax.servlet
.Servlet interface. The application server creates an instance of the servlet class and
uses it to handle incoming requests. The Servlet interface defines the set of methods
that should be implemented to allow the application server to manage the servlet life
cycle (discussed later in this chapter) and pass requests to the servlet instance for pro-cessing.
Servlets intended for use as HTTP request/response mechanisms normally
extend the javax.servlet.http.HttpServlet class, although they may imple-ment
and use the Servlet interface methods if desired. The HttpServlet class
implements the Servlet interface and implements the init(), destroy(), and
service()methods in a default manner. For example, the service()method in
HttpServlet interrogates the incoming HttpServletRequest object and forwards
the request to a series of individual methods defined in the HttpServlet class
based on the type of request. These methods include the following:

_ doGet()for handling GET , conditional GET , and HEAD requests

_ doPost()for POST requests

_ doPut()for PUT requests

_ doDelete()for DELETE requests

_ doOptions()for OPTIONS requests

_ doTrace()for TRACE requests

The doGet(), doPost(), doPut(), and doDelete()methods in HttpServlet
return a BAD_REQUEST (400) error as their default response. Servlets that extend
HttpServlet typically override and implement one or more of these methods to generate
the desired response. The doOptions()and doTrace()methods are typically
not overridden in the servlet. Their implementations in the HttpServlet class are
designed to generate the proper response, and they are usually sufficient.

A minimal HTTP servlet capable of responding to a GET request requires nothing
more than extending the HttpServlet class and implementing the doGet()
method.

WebLogic Server provides a number of useful sample servlets showing the basic
approach for creating HTTP servlets. These sample servlets are located in the
samples/server/examples/src/examples/servlets subdirectory beneath
the Web-Logic Server home directory, a directory we refer to as $WL_HOME throughout
the rest of the book. We will examine some additional example servlets in detail
during the course of this chapter. These example servlets are available on the companion
Web site for this book at wiley.com/compbooks/masteringweblogic.

Creating the HTML output within the servlet's service()or do XXX )method is
very tedious. This deficiency was addressed in the J2EE specification by introducing a
scripting technology, JavaServer Pages (JSP), discussed later in this chapter.


Servlets Have a Life Cycle

A servlet is an instance of the servlet class and has a life cycle similar to that of any
other Java object. When the servlet is first required to process a request, the application
server loads the servlet class, creates an instance of the class, initializes the instance,
calls the servlet's init()method, and calls the service()method to process the
request. In normal servlet operation, this same instance of the servlet class will be used
for all subsequent requests.

Servlets may be preloaded during WebLogic Server startup by including the
element in the web.xml file for the Web application. You can also provide
initialization parameters in this file using elements. WebLogic
Server will preload and call init()on the servlet during startup, passing the specified
initialization parameters to the init()method in the ServletConfig object.

An existing servlet instance is destroyed when the application server shuts down or
intends to reload the servlet class and create a new instance. The server calls the
destroy()method on the servlet prior to removing the servlet instance and unloading
the class. This allows the servlet to clean up any resources it may have opened during
initialization or operation.


Servlets Allow Multiple Parallel Requests

Servlets are normally configured to allow multiple requests to be processed simultaneously
by a single servlet instance. In other words, the servlet's methods must be
thread-safe. You must take care to avoid using class- or instance-level variables unless
access is made thread-safe through synchronization logic. Typically, all variables and
objects required to process the request are created within the service()or do XXX )
method itself, making them local to the specific thread and request being processed.

BEST PRACTICE Servlets that allow multiple parallel requests must be
thread-safe. Do not share class- or instance-level variables unless
synchronization logic provides thread safety.


Servlets may be configured to disallow multiple parallel requests by defining the
servlet class as implementing the SingleThreadModel interface:

...
public class TrivialSingleThreadServlet
extends HttpServlet implements SingleThreadModel
{
public void init(ServletConfig config)throws ServletException
{
super.init(config);
System.out.println("Here!");
}
...

This simple change informs the application server that it may not process multiple
requests through the same servlet instance simultaneously. The application server can
honor this restriction in multiple ways: It may block and queue up requests for processing
through a single instance, or it may create multiple servlet instances as needed
to fulfill parallel requests. The servlet specification does not dictate how application
servers should avoid parallel processing in the same instance.

WebLogic Server satisfies the single-threaded requirement by creating a small pool
of servlet instances (the default pool size is five) that are used to process multiple
requests. In older versions of WebLogic Server, multiple parallel requests in excess of
the pool size would block waiting for the first available servlet instance. This behavior
changed in WebLogic Server 7.0. The server now creates, initializes, and discards a new
instance of the servlet for each request rather than blocking an execute thread under
these conditions. Set the pool size properly to avoid this extra servlet creation and initialization
overhead.

You can configure the size of the pool at the Web application level using the
single-threaded-servlet-pool-size element in the weblogic.xml deployment
descriptor. If you choose to employ single-threaded servlets in high-volume
applications, consider increasing the pool size to a level comparable to the number of
execute threads in the server to eliminate the potential overhead required to create
extra servlet instances on the fly to process requests.

Although instance variables are safe to use in single-threaded servlets, class-level
static variables are shared between these instances, so access to this type of static data
must be thread-safe even when using the SingleThreadModel technique. Deploying
and executing this TrivialSingleThreadServlet example verifies this pooling
behavior in WebLogic Server. The first servlet request causes WebLogic Server to
create five instances of the servlet, as evidenced by five separate invocations of the
init()method and the subsequent writing of five "Here!" messages in the log.

BEST PRACTICE In general, you should avoid using single-threaded
servlets. If you find that you need to use servlets that implement the
SingleThreadModel, use the
single-threaded-servlet-pool-size element
to set the pool size properly to avoid the overhead of creating and initializing
extra servlet instances to handle peaks in the number of concurrent requests to
the servlet.


Servlets May Access Request Data

The HttpServletRequest parameter passed in to the service()or do XXX )
method contains a wealth of information available to the servlet during the processing
of the request. Useful data in the HttpServletRequest is summarized in Table 1.1.

This is not an exhaustive list of the methods available on the HttpServletRequest
class or its superclass, ServletRequest . Refer to the servlet javadocs at
java.sun.com/products/servlet/2.3/javadoc/index.html or a good reference
book on servlets for a complete list including parameter types, return types, and other
details.

A useful servlet packaged with the WebLogic Server examples, SnoopServlet ,
illustrates the use of many of the methods available on the HttpServletRequest
object. For example, this section of SnoopServlet illustrates how to retrieve and display
the names and values of all parameters passed to the servlet:

...

Enumeration e = req.getParameterNames();
if (e.hasMoreElements()){
out.println("

Servlet parameters (Single Value style):

");
out.println("");
while (e.hasMoreElements()){
String name =(String)e.nextElement();
out.println(" " ++name +" ==" ++req.getParameter(name));
}
out.println("");
}
...

This servlet can be very useful for debugging HTML forms during development.
Specify SnoopServlet as the action for an HTML form to view all of the parameters,
cookies, and headers sent by the browser during submission of the form. Nothing is
more frustrating than spending time debugging a servlet only to find that the HTML
form had an improperly named input item.

BEST PRACTICE Use the SnoopServlet as an action target during
development and debugging to inspect request information and verify HTML
forms.


Note that SnoopFilter, a servlet filter discussed later in this chapter, provides a
superior mechanism for viewing request information for some or all pages in the Web
application.


Servlets Use Session Tracking

A servlet is a request/response mechanism that treats each incoming request as an
independent processing event with no relationship to past or future requests. In other
words, the processing is stateless. The HTTP protocol is also a stateless protocol: Each
request from the Web browser is independent of previous or subsequent requests.
Linking current requests to previous requests from the same client requires a mechanism
for preserving context or state information from request to request. There are a
number of HTML-based techniques for preserving context or state information:

_ Cookies may be set in previous requests and passed back to the server on subsequent
requests.

_ URL-rewriting may be used to encode small amounts of context information on
every hyperlink on the generated page.

_ Hidden form fields containing context information may be included in forms.

These techniques all have limitations, and none provides the robust data types and
flexibility needed to implement true state management. Fortunately, the session tracking
capability defined in the J2EE servlet model provides an excellent solution.

Session tracking provides a flexible hash-table-like structure called an HttpSession
that can be used to store any serializable Java object and make it available in subsequent
requests. To identify the specific client making the request and look up its
session information, session tracking uses a cookie or URL-encoded session ID passed
to the server on subsequent requests. In WebLogic Server, this session ID has the name
JSESSIONID by default and consists of a long hash identifying the client plus
creation-time and cluster information. The format of the session ID is

JSESSIONID=SESSION_ID!PRIMARY_JVMID_HASH!SECONDARY_JVM_HASH!CREATION_TIME

WebLogic Server uses exclamation marks to separate portions of the session ID. The
first portion is used by the session tracking implementation in WebLogic Server to look
up the client's HttpSession object in the Web application context.

Continues...




Excerpted from Mastering BEA WebLogic Server
by Gregory Nyberg Robert Patrick Paul Bauerschmidt Jeff McDaniel Raja Mukherjee
Copyright © 2003 by Gregory Nyberg, Robert Patrick, Paul Bauerschmidt, Jeff McDaniel, Raja Mukherjee.
Excerpted by permission.
All rights reserved. No part of this excerpt may be reproduced or reprinted without permission in writing from the publisher.
Excerpts are provided by Dial-A-Book Inc. solely for the personal use of visitors to this web site.

Read More Show Less

Table of Contents

Acknowledgments.

About the Authors.

Introduction.

Chapter 1. Building Web Applications in WebLogic.

Chapter 2. Choosing a Web Application Architecture.

Chapter 3. Designing an Example J2EE Application.

Chapter 4. Building an Example Web Application.

Chapter 5. Packaging and Deploying WebLogic Web Applications.

Chapter 6. Building Enterprise JavaBeans in WebLogic Server.

Chapter 7. Building an Example EJB Application.

Chapter 8. Packaging and Deploying WebLogic EJB Applications.

Chapter 9. Using WebLogic JMS.

Chapter 10. Using WebLogic Security.

Chapter 11. Administering and Deploying Applications In WebLogic Server.

Chapter 12. Optimizing WebLogic Server Performance.

Chapter 13. Development Environment Best Practices.

Chapter 14. Production Environment Best Practices.

Chapter 15. Developing and Deploying Web Services.

Index.

Read More Show Less

Customer Reviews

Be the first to write a review
( 0 )
Rating Distribution

5 Star

(0)

4 Star

(0)

3 Star

(0)

2 Star

(0)

1 Star

(0)

Your Rating:

Your Name: Create a Pen Name or

Barnes & Noble.com Review Rules

Our reader reviews allow you to share your comments on titles you liked, or didn't, with others. By submitting an online review, you are representing to Barnes & Noble.com that all information contained in your review is original and accurate in all respects, and that the submission of such content by you and the posting of such content by Barnes & Noble.com does not and will not violate the rights of any third party. Please follow the rules below to help ensure that your review can be posted.

Reviews by Our Customers Under the Age of 13

We highly value and respect everyone's opinion concerning the titles we offer. However, we cannot allow persons under the age of 13 to have accounts at BN.com or to post customer reviews. Please see our Terms of Use for more details.

What to exclude from your review:

Please do not write about reviews, commentary, or information posted on the product page. If you see any errors in the information on the product page, please send us an email.

Reviews should not contain any of the following:

  • - HTML tags, profanity, obscenities, vulgarities, or comments that defame anyone
  • - Time-sensitive information such as tour dates, signings, lectures, etc.
  • - Single-word reviews. Other people will read your review to discover why you liked or didn't like the title. Be descriptive.
  • - Comments focusing on the author or that may ruin the ending for others
  • - Phone numbers, addresses, URLs
  • - Pricing and availability information or alternative ordering information
  • - Advertisements or commercial solicitation

Reminder:

  • - By submitting a review, you grant to Barnes & Noble.com and its sublicensees the royalty-free, perpetual, irrevocable right and license to use the review in accordance with the Barnes & Noble.com Terms of Use.
  • - Barnes & Noble.com reserves the right not to post any review -- particularly those that do not follow the terms and conditions of these Rules. Barnes & Noble.com also reserves the right to remove any review at any time without notice.
  • - See Terms of Use for other conditions and disclaimers.
Search for Products You'd Like to Recommend

Recommend other products that relate to your review. Just search for them below and share!

Create a Pen Name

Your Pen Name is your unique identity on BN.com. It will appear on the reviews you write and other website activities. Your Pen Name cannot be edited, changed or deleted once submitted.

 
Your Pen Name can be any combination of alphanumeric characters (plus - and _), and must be at least two characters long.

Continue Anonymously

    If you find inappropriate content, please report it to Barnes & Noble
    Why is this product inappropriate?
    Comments (optional)