2.3 WebSphere Application Server runtime architecture

---

2.3 WebSphere Application Server runtime architecture

Access to enterprise business logic and data from heterogeneous devices and technologies poses a significant technical challenge: The implementation of logic and data needs to be client neutral. Using a multi-tier architectural approach is a natural way to deal with this issue.

WebSphere Application Server provides the application logic layer in a multi-tier architecture, enabling client components to interact with data resources and legacy applications. Collectively, the multi-tier architectures are programming models that enable the distribution of application functionality across multiple independent systems, typically:

• Client components running on local workstations

• Processes running on remote servers

• A discrete collection of databases, resource managers, and mainframe applications

Be aware that these tiers are just logical tiers. Enterprise applications can be partitioned in a number of tiers that are logically independent—although they may physically reside on the same machine or run in the same process.

The very back end tier (Tier-3) of an enterprise application is the Data Server, as illustrated on the right side of the Figure 2-3. The data server may need to handle a combination of legacy databases and newly created information repositories. The services provided by this tier are protected from direct access by the client components residing within a secure network. Interaction must occur through the Tier-2 processes, as shown in Figure 2-3.

Figure 2-3: WebSphere Application Server V5 multi-tier application environment

The second-tier processes are commonly referred to as the application logic layer. These processes manage the business logic of the application, and are permitted to access the third-tier services. The business logic tier can be implemented by using Enterprise Java Beans. EJBs naturally map to business entities and business processes and, from a data persistence standpoint, they can be mapped to existing databases or to new tables. The EJB tier incorporates all aspects of the business logic, including the process flow.

The core of application functions and data represented by Tier-2 and Tier-3 in the figure can then be accessed in a variety of ways. They can be accessed by traditional "thick" clients, which are represented by the Tier-1 clients in the figure. Typically, these clients require highly functional and rich GUIs, and access the enterprise applications within the company's firewalls, that is, within the Intranet. Applications can be accessed from the outside world, through the Internet, either via a browser-based interface (represented by the Tier-0 Web browsers) via hand-held devices, or via business-to-business interfaces.

Servlets and JSPs, encapsulated in Tier 1, will be responsible for offering a suitable rendition of the business data and methods to Tier-0 customers. This is what we call presentation logic. It enables the user to interact with the Tier-2 processes in a secure and intuitive manner. Tier 1 is in essence the only segment of the whole architecture that needs to be adapted to fit different access methods.

All these tiers must communicate with each other. Open standard protocols and exposed APIs simplify this communication. You can write client components in any programming language, such as Java or C++. These clients run on any operating system, by speaking with the application logic layer. Databases in the very back end tier can be of any design, if the application layer can query and manipulate them.

2.3.1 WAS Version 5 base runtime architecture

The WebSphere Application Server V5 base configuration includes only a single stand-alone application server process. Its configuration files are in XML and could be administered by the Administrative client programs such as Administrative Console or the wsadmin scripting tool. There is no node agent or Deployment Manager involved in this configuration. No coordination between application server processes is supported in the base configuration. Each application server instance has to be separately administered.

Figure 2-4 on page 30 illustrates the main components running in the node for a standalone WebSphere Application Server base configuration.

Figure 2-4: Runtime architecture for WAS base configuration

For architecture features introduction, please refer to "Architectural features" on page 33.

2.3.2 WAS Version 5 Network Deployment runtime architecture

IBM WebSphere Application Server Network Deployment configuration includes support for multiple nodes, each with a node agent process and several application servers, all coordinated within an administrative cell by the Deployment Manager process. Clusters of load-balanced application servers can be configured within a Network Deployment cell. The configuration and application binaries of all components in the cell are managed by the Deployment Manager and synchronized out to local copies on each of the nodes.

Figure 2-5 on page 31 shows the main components running in the node and Deployment Manager for a Network Deployment environment.

Figure 2-5: Runtime architecture for WAS Network Deployment configuration

For your better understanding of the architecture for base configuration and Network Deployment configuration, here we briefly explain some terminologies that are commonly used in a WebSphere Application Server runtime environment.

Node

A node is a logical grouping of managed servers. A node usually corresponds to a physical computer system with a distinct IP host address. Node names usually are identical to the host name for the computer.

A node agent manages all WebSphere Application Server servers on a node. The node agent represents the node in the management cell.

Cell

Cells are arbitrary, logical groupings of one or more nodes in a WebSphere Application Server distributed network. A cell is a configuration concept, a way for administrators to logically associate nodes with one another. Administrators define the nodes that make up a cell according to whatever criteria make sense in their organizational environments.

Administrative configuration data is stored in XML files. A cell retains master configuration files for each server in each node in the cell. Each node and server also have their own local configuration files. Changes to a local node or server configuration file are temporary, if the server belongs to the cell. While in effect, local changes override cell configurations. Changes at the cell level to server and node configuration files are permanent. Synchronization occurs at designated events, such as when a server starts.

The following components belong to IBM WebSphere Application Server Network Deployment only.

Deployment managers

Deployment managers are administrative agents that provide a centralized management view for all nodes in a cell, as well as management of clusters and workload balancing of application servers across one or several nodes in some editions. WebSphere Application Server for z/OS uses WLM as the primary vehicle for workload balancing.

A deployment manager hosts the administrative console. A deployment manager provides a single, central point of administrative control for all elements of the entire WebSphere Application Server distributed cell.

Node agents

Node agents are administrative agents that route administrative requests to servers.

A node agent is a server that runs on every host computer system that participates in the WebSphere Application Server Network Deployment product. It is purely an administrative agent and is not involved in application-serving functions. A node agent also hosts other important administrative functions such as file transfer services, configuration synchronization, and performance monitoring.

Dispatcher

The Dispatcher component is part of the Load Balancer component set of the IBM WebSphere Application Server Edge Components product. The Edge components are included in WebSphere Application Server Network Deployment. The Dispatcher performs intelligent load balancing by using server availability, capability, workload, and other criteria you can define, to determine where to send a TCP/IP request. You can use the Dispatcher to distribute HTTP requests among Application Server instances that are running on multiple physical machines.

Clusters

Clusters are sets of servers that are managed together and participate in workload management. The servers that are members of a cluster can be on different host machines, as opposed to the servers that are part of the same node and must be located on the same host machine.

A cell can have no clusters, one cluster, or multiple clusters. Servers that belong to a cluster are members of that cluster set and must all have identical application components deployed on them. Other than the applications configured to run on them, cluster members do not have to share any other configuration data. One cluster member might be running on a huge multi-processor enterprise server system while another member of that same cluster might be running on a small laptop. The server configuration settings for each of these two cluster members are very different, except in the area of application components assigned to them. In that area of configuration, they are identical.

A vertical cluster has cluster members on the same node. A horizontal cluster has cluster members on multiple nodes.

A network dispatcher routes application access among cluster members by server-weighting, to provide better distribution control.

WebSphere Application Server can respond to increased use of an enterprise application by automatically replicating the application to additional cluster members as needed. This lets you deploy an application on a cluster instead of on a single node, without considering workload.

2.3.3 Architectural features

This section describes the major components within IBM WebSphere Application Server.

HTTP server

IBM WebSphere Application Server works with an HTTP server to handle requests for servlets and other dynamic content from Web applications.

The HTTP server and Application Server communicate using the WebSphere HTTP plug-in for the HTTP server. The HTTP plug-in uses an easy-to-read XML configuration file to determine whether a request is handled by the Web server or the Application Server. The HTTP plug-in uses the standard HTTP protocol to communicate with the Application Server though you can configure it to use secure HTTPS, if required. The HTTP plug-in is available for popular Web servers.

Application Server

The WebSphere Application Server collaborates with the Web server by exchanging client requests and application responses. You can define multiple Application Servers, each running in its own Java virtual machine (JVM).

EJB container

The EJB container provides the run-time services needed to deploy and manage EJB components, known as enterprise beans. It is a server process that handles requests for both session and entity beans.

The enterprise beans (inside EJB modules) installed in an Application Server do not communicate directly with the server; instead, an EJB container provides an interface between the enterprise beans and the server. Together, the container and the server provide the bean run-time environment.

The container provides many low-level services, including threading and transaction support. From an administrative viewpoint, the container manages data storage and retrieval for the contained beans. A single container can manage more than one EJB JAR file.

Web container

Servlets and JavaServer Pages (JSP) files are server-side components used to process requests from HTTP clients, such as Web browsers. They handle presentation and control of the user interaction with the underlying application data and business logic. They can also generate formatted data, such as XML, for use by other application components.

The Web container processes servlets, JSP files, and other types of server-side includes Pre-J2EE servlets run in a servlet engine. Each Web container automatically contains a single session manager.

When handling servlets, the Web container creates a request object and a response object, and then invokes the servlet service method. The Web container invokes the servlet destroy() method when appropriate and unloads the servlet, after which the JVM performs garbage collection.

Application client container

Application clients are Java programs that typically run on a desktop computer with a graphical user interface (GUI). They have access to the full range of J2EE server-side components and services.

The application client container handles Java application programs that access enterprise beans, Java Database Connectivity (JDBC), and message queues that belong to the Java Message Service (JMS). The J2EE application client program runs on client machines. This program follows the same Java programming model as other Java programs; however, the J2EE application client depends on the application client run time to configure its execution environment, and uses the Java Naming and Directory Interface (JNDI) name space to access resources.

Applet container

An applet is a client Java class that typically executes in a Web browser, but can also run in a variety of other client applications or devices.

Applets are often used in combination with HTML pages to enhance the user experience provided by a Web browser. They can also shift some of the processing workload from the server to the client.

The applet container handles Java applets embedded in HyperText Markup Language (HTML) documents that reside on a client machine that is remote from the application server. With this type of client, the user accesses an enterprise bean in the Application Server through the Java applet in the HTML document.

Embedded HTTP server

The HTTP handling capability embedded within the application server supports a connection from an HTTP client to the Application Server. An HTTP client can connect to a Web server and the HTTP plug-in can forward the request to the Application Server.

Virtual host

A virtual host is a configuration enabling a single host machine to resemble multiple host machines. Resources associated with one virtual host cannot share data with resources associated with another virtual host, even if the virtual hosts share the same physical machine.

Administrators can use virtual hosts to associate Web applications with a particular host configured to run the application.

Session Management

WebSphere Application Server provides facilities, grouped under the heading Session Management, that support the javax.servlet.http.HttpSession interface described in the Servlet API specification.

When an HTTP client interacts with a servlet, the state information associated with a series of client requests is represented as an HTTP session and identified by a session ID. Session Management is responsible for managing HTTP sessions, providing storage for session data, allocating session IDs, and tracking the session ID associated with each client request through the use of cookies or URL rewriting techniques. Session Management can store session-related information in several ways:

• In application server memory (the default). This information cannot be shared with other application servers.

• In a database. This storage option is known as database-persistent sessions.

• In another WebSphere Application Server instance. This storage option is known as memory-to-memory sessions.

The last two options are referred to as distributed sessions. Distributed sessions are essential for using HTTP sessions for failover facility. When an application server receives a request associated with a session ID that it currently does not have in memory, it can obtain the required session state by accessing the external store (database or memory-to-memory). If distributed session support is not enabled, an application server cannot access session information for HTTP requests that are sent to servers other than the one where the session was originally created. Session Management implements caching optimizations to minimize the overhead of accessing the external store, especially when consecutive requests are routed to the same application server.

JNDI support

Naming is used by clients of WebSphere Application Server applications to obtain references to objects related to those applications, such as Enterprise JavaBeans (EJBs) homes.

IBM WebSphere Application Server includes a name server to provide shared access to Java components, and an implementation of the javax.naming JNDI package, which supports user access to the WebSphere Application Server name server through the JNDI naming interface.

WebSphere Application Server's JNDI implementation is based on version 1.2 of the JNDI interface, and was tested with version 1.2.1 of Sun's JNDI Service Provider Interface (SPI).

Messaging support using JMS

WebSphere Application Server supports asynchronous messaging as a method of communication based on the Java Message Service (JMS) programming interface. JMS provides a common way for Java programs (clients and J2EE applications) to create, send, receive, and read asynchronous requests as JMS messages.

WebSphere Application Server also supports automatic asynchronous messaging using message-driven beans (a type of enterprise bean defined in the EJB 2.0 specification) and JMS listeners (part of the JMS application server facilities). Messages are automatically retrieved from JMS destinations, optionally within a transaction, then sent to the message-driven bean in an J2EE application, without the application having to explicitly poll JMS destinations.

Security Service

IBM WebSphere Application Server Version 5 provides security infrastructure and mechanisms to protect sensitive J2EE resources and administrative resources and to address enterprise end-to-end security requirements on authentication, resource access control, data integrity, confidentiality, privacy, and secure inter-operability. IBM WebSphere Application Server security is based on industry standards such as SSL Security 2.0. Version 5 has an open architecture that processes secure connectivity and inter-operability with Enterprise Information Systems including DB2, CICS®, MQ Series, Domino®, IBM Directory and others with security providers including Tivoli® Access Manager (Policy Director) and WebSEAL secure proxy server.

---