Read an Excerpt

WebSphere Application Server: Step by Step

MC Press

WebSphere Application Server V6: Packaging and Architecture

With complete J2EE compatibility and integrated Web services support, Version 6.0 of WebSphere Application Server delivers high performance and a highly scalable transaction engine for dynamic and mission-critical e-business applications. The product, the cornerstone of the IBM WebSphere product family, forms the foundation for IBM's other middleware offerings. Leading-edge products such as WebSphere Commerce Server, WebSphere Process Server (formerly WebSphere Business Integration Server Foundation), WebSphere Enterprise Service Bus, and WebSphere Portal Server (to name just a few) are built on top of this powerful application server.

In Version 6, WebSphere Application Server supports the full Java 2 Platform, Enterprise Edition (J2EE) 1.4 programming model, including servlets, Java Server Pages (JSPs), Enterprise JavaBeans (EJB), and Web services. WebSphere V6 also continues to support applications developed using the J2EE 1.2 and 1.3 specifications, making it easier to migrate applications deployed on WebSphere Application Server 4.x and 5.x. Figure 1-1 summarizes the standards support in WebSphere Application Server V6. (For complete documentation of the J2EE 1.4 specification, see the list of Web references in the Appendix.)

WebSphere V6 is supported on many platforms, including Windows (Windows 2000, 2003, and XP), Unix (AIX, HP-UX, Linux, and Solaris), and IBM's i5/OS (OS/400) operating system. For a complete list of supported platforms, see the Web references list in the Appendix. In this chapter, we look at how IBM packages the product in Version 6 and examine the architectures associated with each variation. Before concluding the chapter, we'll review some of the significant new features in V6, including administrative console improvements, high-availability features, and deployment and management enhancements. Chapter 2 gives you an overview of the installation and configuration process and provides an introduction to the rest of the book.

Packaging

IBM offers WebSphere Application Server V6 in the following packages:

* WebSphere Application Server V6 — Express — The Express package provides a fully functional, affordable, and easy-to-use Java application server and development environment. Unlike Version 5, the V6 Express package provides full J2EE support, including an Enterprise JavaBeans container.

* WebSphere Application Server V6 — In addition to the functionality supported by the Express runtime, the base application server product — what we call "the Base package" in this book — delivers high performance and a highly scalable transaction engine for dynamic e-business applications. The Base package provides the same functionality as the Express package, but an expanded license agreement supports the ability to federate (i.e., add) an application server node to a WebSphere Deployment Manager cell. (You'll learn more about WebSphere nodes and cells later in this chapter.)

* WebSphere Application Server V6 — Network Deployment — In addition to the functionality provided in the Base/Express package, the Network Deployment (ND) package delivers advanced deployment services, including clustering, edge-of-network services, Web services enhancements, and high availability for distributed configurations. Figure 1-2 illustrates the relationship among the Base, Express, and Network Deployment packages.

* WebSphere Application Server V6 — Extended Deployment — Installed on top of the Network Deployment package, the Extended Deployment (XD) package the Network Deployment package, the Extended Deployment (XD) package helps customers with multiple mission-critical and complex applications improve availability and performance by balancing and sharing the workload of multiple application server nodes and clusters to provide on- demand computing.

Base/Express Package Software

Figure 1-3 depicts the software products that come with the Express and Base versions of WebSphere Application Server. These two packages include essentially the same set of software (the development tool provided is the only difference). The Base/Express package includes the following software:

* Standalone application server node with support for multiple instances

* Application client

* IBM HTTP Server V6

* Web server plug-ins

* IBM Rational Web Developer (iRWD) V6 (with the Express package) or a trial version of IBM Rational Application Developer (iRAD) V6 (with the Base package)

* Application Server Toolkit (AST)

* DB2 Universal Database (DB2 UDB) Express Edition 8.2

It's important to understand that no functionality or feature differences exist between the Express and Base versions of WebSphere Application Server in the WebSphere V6 runtime. These packages are built of the same code base and therefore are identical in terms of features and functions. The difference between the two packages is simply a licensing issue. To be able to federate an application server node to a WebSphere cell, you must have a paper agreement; only the Base package permits use of this feature.

A license agreement also grants Base installations unlimited CPU use, while Express package users are limited to two CPUs.

Network Deployment Package Software

To the Base/Express package's support for a standalone application server environment, the WebSphere Application Server V6 – Network Deployment package adds the ability to create and manage a distributed server configuration. This product includes the following software in addition to the software provided in the Base/Express package:

* Deployment Manager

* Edge Components (Load Balancer, Caching Proxy)

* IBM Tivoli Directory Server (a Lightweight Directory Access Protocol, or LDAP, server)

* Tivoli Access Manager (TAM) server

* DB2 UDB Server Edition 8.2

* IBM Cloudscape database

Figure 1-4 depicts the software products that come with the Network Deployment package.

The key additional features provided in the Network Deployment package are support for workload management, high availability, and clustering and the ability to run the Web server as a managed node. (If you use IBM HTTP Server V6 as your Web server, you can manage it through IBM HTTP Admin Server V6 instead of using a node agent process from the WebSphere administrative console. This feature is not available with other supported Web servers.)

Standalone Application Server

The heart of a WebSphere Application Server installation is the application server itself. The application server provides a runtime environment in which to deploy, manage, and run J2EE applications. Both the Base and Express packages support a standalone application server structure. Figure 1-5 illustrates the components of this basic architecture, which forms the foundation of every WebSphere Application Server installation.

Each application server runs in its own Java Virtual Machine (JVM). As you can see in the diagram, the application server process contains the following services and containers:

* Admin server — The administrative server maintains and manages the administration configuration repository (which consists of Extensible Markup Language, or XML, flat files in the file system). The admin server accepts requests from the WebSphere administrative console (a browser-based graphical interface for configuring and managing WebSphere resources) and wsadmin commands and changes the configuration information accordingly. If you've enabled global security, the admin server also secures the administrative repository by authenticating and authorizing the user role.

* Web container — The Web container provides a runtime environment for servlets, JSPs, JavaBeans, and static content (if you've enabled the file-serving servlet). These artifacts are typically packaged as a Web module and run inside the Web container. A Web module is packaged as a file with a .war (Web archive) extension. If necessary, the Web container works with the application server's EJB container or the Web services engine to process requests. Files with .war and .jar (Java archive) extensions run inside the Web container.

* Embedded HTTP Server (EHS) — The application server's EHS component receives requests from an external HTTP server (e.g., IBM HTTP Server) using Hypertext Transfer Protocol (default TCP/IP port 9080) and passes the requests to the Web container for processing. The embedded server can serve all static content, just like an external HTTP server. EHS isn't meant to replace an external HTTP server in a production environment, but you can use it to test your WebSphere applications. By using EHS as an HTTP server to serve static content without an external HTTP server, you can save system resources in development and functional testing environments.

* Web services engine — The Web services engine is the part of the application server runtime that supports Web services. Web services are self-contained, modular applications that you can describe, publish, locate, and invoke over a network.

* EJB container — The application server's EJB container provides a runtime environment for deploying, managing, and running Enterprise JavaBeans. These artifacts are typically packaged as an EJB module and run inside the EJB container. An EJB module is packaged as a file with a .jar extension. Files with a .jar extension and an EJB deployment descriptor run inside this container. Java clients communicate with Enterprise JavaBeans in the EJB container. The client container depicted in the figure provides services for running standalone Java clients that use the application server. You invoke the client application container by executing the launchClient command.

* J2C service — The Java 2 Connector (J2C) service provides connections between J2EE applications running inside the application server and applications running in legacy enterprise information systems. Connections and their runtime environment are pooled and managed as defined in the J2EE 1.4 specification's J2C architecture.

* JNDI naming server — You can register resources in the application server's Java Naming and Directory Interface (JNDI) namespace. Client applications can then obtain the references to these resource objects in their programs.

* Messaging engine — The messaging engine provides the core messaging functionality of a Service Integration Bus (SIBus). To enable the messaging engine in the application server process (default messaging provider with WebSphere V6), you create an SIBus and attach the application server to it as a member. This messaging engine is all-Java based and runs in-process with the application server. Applications can use an external JMS provider such as WebSphere MQ, a third-party JMS provider such as TIBCO, or the WebSphere V5 embedded messaging provider instead of the default messaging engine. In this book, we cover use of the default messaging engine only.

* Security server — The security server provides authentication and authorization services.

Application Server Profile

Notice that Figure 1-5 depicts the application server as enclosed within a profile. The concept of profiles is new in WebSphere Application Server V6. A profile contains a set of files that enable the runtime environment for a WebSphere server process. You create a profile for the application server during the installation process.

Using the Base/Express package, you can create only one type of profile: an application server profile. The Network Deployment package supports two additional profile types, deployment manager and custom, both of which we describe later.

As the diagram in Figure 1-6 illustrates, when you install the WebSphere V6 package, the installation program copies to a directory on the server machine the product binaries, which include a default application server template and other files required to create a profile. During the installation process, you use the profile template to define the configuration settings of the new server you're going to create.

When you create an application server profile, an application server (named server1) is created by default, and necessary applications are deployed on it to help manage the configuration (adminconsole, filetransfer) and verify the installation (default application, installation verification test). You can use the same set of product binaries (and template) to create multiple profiles.

If you desire, you can create multiple application servers (e.g., server2, server3) within the same profile. But for easy maintenance, you may want to create a new profile (an application server process gets created with a profile) if you ever expect to have multiple application servers.

IBM HTTP Server

You can use WebSphere Application Server's Embedded HTTP Server (available inside the Web container) to serve static content, but EHS isn't meant to be used this way in a production environment, due to scalability and availability limitations. For this reason, IBM includes the "full-strength" IBM HTTP Server Web server as part of the WebSphere V6 product.

IBM HTTP Server V6, which comes with both the Base/Express and the Network Deployment packages, is based on the Apache Web Server 2.0.47. As a Web server, HTTP Server's purpose is to process and serve static content, such as Hypertext Markup Language (HTML), images, Cascading Style Sheets (CSS), and JavaScript.

Figure 1-7 shows the basic architecture of HTTP Server in V6. The server contains the following services:

* Apache service — This is the core Apache service that processes HTTP requests.

* Admin service — If you configured the Web server node as an unmanaged node, the WebSphere admin service can use the HTTP admin service to manage HTTP Server, change the configuration of the HTTP plug-in and HTTP Server, and propagate the plug-in configuration file remotely from the WebSphere administrative console.

WebSphere V6 Plug-in for HTTP Server

When a Web application user sends a request, the external HTTP server processes the request first (here we are assuming that the plug-in module is not installed and configured to run with the HTTP server). If the request is for static content only, the HTTP server can serve it. (Requests for static content can be served using the file-serving enabler servlet from the application's Web module running in the application server's Web container or, if configured appropriately, from the document root of IBM HTTP Server.) However, if the request is to display dynamic content (served through a servlet and/or a JSP), an application server must fulfill it. In this case, the HTTP server needs to know where and how to divert the request. For this reason, WebSphere provides a plug-in module that runs with HTTP Server. The plug-in module uses an XML-based file containing a request-routing table to divert requests to the appropriate application server. Figure 1-8 illustrates the plug-in's relationship with WebSphere V6 and HTTP Server V6. Once you've installed and configured the WebSphere plug-in module on the HTTP server, the plug-in process receives the request from the client first. If the request is for dynamic content, the plug-in diverts the request to the WebSphere application server. If the request is for static content, the plug-in forwards it to the HTTP server.

Architectures Possible with the Base/Express Package

When it comes to architecting a WebSphere V6 Base/Express application server, you have various options with respect to IBM HTTP Server and the plug-in module. In this section, we review a few possibilities to give you a general idea of how you might build a WebSphere V6 system. You can create any of the architectural variations described here (and others) by following the steps given in Chapters 3 through 6.

---

Excerpted from WebSphere Application Server: Step by Step by Rama Turaga, Owen Cline, Peter Van Sickel. Copyright © 2009 MC Press Online, L.P.. Excerpted by permission of MC Press.
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.

---