Editor's Note: The Domino and WebSphere Strategies tip will cover issues that Domino developers and administrators face when integrating Domino and WebSphere. This first tip covers the basics of WebSphere v5 architecture. Other topics will include specifics on portals, understanding single sign-on, WebSphere Portal v5 and more.
WebSphere architectures contain one or more computer systems, which are referred to in WebSphere terminology as nodes. Nodes exist within a WebSphere cell. A WebSphere cell can contain one node on which all software components are installed or multiple nodes on which the software components are distributed.
A typical WebSphere cell contains software components that may be installed on one node or distributed over multiple nodes for scalability and reliability purposes. These include the following:
- A Web server that provides HTTP services
- A database server for storing application data
- WebSphere Application Server (WAS) V5
The following diagram shows a one-node architecture.
A single node WebSphere architecture
A description of the software components is given below.
HTTP server
The HTTP server, more typically known as the Web server, accepts page requests from Web browsers and returns Web page content to Web browsers using the HTTP protocol. Requests for Java servlets and JavaServer Pages (JSPs) are passed by the Web server to WebSphere for execution. WebSphere executes the servlet or JSP and returns the response to the Web server, which in turn forwards the response to the Web browser for display.
WebSphere V5 supports numerous Web servers such as Apache, Microsoft IIS, Netscape and Domino. However, WebSphere has the tightest integration with Domino because IBM provides single sign-on capabilities between WebSphere and Domino.
WebSphere plug-in
The WebSphere plug-in integrates with the HTTP Server and directs requests for WebSphere resources (servlets, JSPs, etc.) to the embedded HTTP server (see below). The WebSphere plug-in uses a configuration file called plugin-cfg.xml file to determine which requests are to be handled by WebSphere. As applications are deployed to the WebSphere configuration, this file must be regenerated (typically using the Administration Console) and distributed to all Web servers, so that they know which URL requests to direct to WebSphere. This is one of the few manual processes that a WebSphere administrator must do to maintain the WebSphere environment.
Embedded HTTP server
The embedded HTTP server receives requests for WebSphere assets from the WebSphere plug-in and passes them to an application server for processing. Any response from the application server is passed back to the WebSphere plug-in for display. The embedded HTTP server supports both HTTP and secure HTTP (HTTPS) protocols for connecting Web servers to application servers. By default, the embedded HTTP server listens for requests on TCP/IP port 9080 but this is configurable. For example:
http://server-name:9080/servlet/snoop
You can also use the embedded HTTP server to test your WebSphere applications, but it should never be used as a production Web server.
Application server
The application server provides a run-time environment for J2EE applications (supporting servlets, JSPs, Enterprise JavaBeans, etc.). A node can have one or more application server processes. Each application server runs in its own runtime environment called a Java Virtual Machine (JVM). The JVM provides complete isolation (crash protection) for individual applications servers.
Application database
WebSphere applications such as IBM's commerce and portal products, as well as applications you create yourself, use a relational database for storing configuration information and data. WebSphere V5 ships with the Cloudscape database and supports a wide range of database product, including the following:
- IBM DB2
- Informix
- Oracle
- SQL Server
- Sybase
Administration service
Each application server contains an administration service that is responsible for reading and maintaining the configuration information and run-time status of the application server. The administration service runs in the same JVM as the application server.
Configuration repository
The configuration repository is a collection of XML files that contains the configuration information for all application servers on a given node. The administration service reads the configuration information for its application server from the configuration repository. Nodes that are part of a cell contain a subset of a centralized configuration repository. The centralized configuration repository contains configuration information for all nodes in the cell. This enables the administrator to centrally manage the configuration of all of these nodes. Configuration changes are automatically distributed to the specific node to which the changes pertain.
Multiple configuration repositories can be created to support environments that require multiple WebSphere cells. This is particularly useful when separate domains are required for development, testing and production purposes. Each node is configured to use a separate configuration repository.
Administration console
The administration console provides a Web-based interface for managing a WebSphere cell from a central location. The administration console can be used to change the configuration of any node within the cell at run-time. Configuration changes are automatically distributed to other nodes in the cell.
Tony Higham is chief solution officer at FatWire Software and former Lotus developer. He is a strong advocate of the business and technology value of Sun's Java technology and the IBM WebSphere platform.
Do you have comments on this tip? Let us know.
