|
5.4.1 Overview of WebSphere Application Server architectureThe WebSphere Application Server software architecture can be viewed in several ways: as bundles of Java libraries; as a group of cooperating services implemented by different components; or as a layered software architecture. To understand the WebSphere Application Server environment and how it exploits the platform on which it runs, all three perspectives must be examined and understood. However, in this document we focus on layering and how WebSphere Application Server can be split into independently viewable parts. Each part has its own behavior and its own opportunities for tuning. WebSphere Application Server is shipped in a number of different types of packages that are aimed at different uses, yet each has a common core and common code across platforms.
These editions have the same base functionality and code at their core, with the additional features added as separate deployable components or as features that are deployed onto the core product via the WebSphere Application Server Profile Manager. In enterprise class POWER/AIX environments, the core WebSphere Application Server ND or WebSphere Application Server XD products are likely to be used. Because the WebSphere Application Server- XD product adds to the WebSphere Application Server ND product externally, we need to understand the WebSphere Application Server and WebSphere Application Server ND picture. When WebSphere Application Server is installed, most of the code is deployed as a set of Java jar libraries that are written as Eclipse/OSGI plug-ins that extend a core runtime. The core runtime is shipped in a file called com.ibm.ws.runtime_6.1.0.jar that is started by scripts and an Eclipse/OSGI runtime itself. Eclipse/OSGI is comprised of extensible components called plug-ins or bundles, so the runtime provides a base on which other plug-ins or bundles build by extending "extension points" in the base. In the runtime, for example, there is code for generic support for containers, threading, and communications, and other code is shipped to extend this either in other parts of the WebSphere Application Server runtime, or in separate plug-ins or bundles. Thus, WebSphere Application Server consists of a set of JAR files that are Eclipse/OSGI plug-ins or bundles. Much of this description can be seen with an understanding of Eclipse and OSGI plug-ins and bundles. Extensions, services, and extension points are described in a plugin.xml file or MANIFEST.MF file that is included inside the JAR file or directory holding the code. A JAR file is essentially the same as a zipped tar file, and you can find the plugin.xml or MANIFEST.MF file within it. If you open the plugin.xml file for com.ibm.ws.runtime_6.1.0.jar, you can see the base description for the startup of WebSphere Application Server and the extension points that it offers for other code to extend, such as the Web container implementation code in the com.ibm.ws.webcontainer_2.0.0.jar file. For the Web container, the base WebSphere runtime in com.ibm.ws.runtime_6.1.0.jar offers the thread pool management, transport channel management, service registry, and base functional utility code that underlies the Web container, and the com.ibm.ws.webcontainer_2.0.0.jar file contains the Web container implementation code that sets the policy for behavior of the Web container functionality, and adds functions like the Apache Jasper JSP compiler functions and JSF code. This type of implementation makes sense given that Web services make use of the same core functionality, so reusability is obtained without mixing the different concerns of usage. Note that the com.ibm.ws.webcontainer_2.0.0.jar file contains its own plugin.xml file that lists the extensions and extension points it uses and makes available, and the MANIFEST.MF file lists the OSGI Bundle Activator that it contains that allows the Eclipse/OSGI runtime to initialize it. It is important to note that the XML shows that different code is run for the iSeries® (AS/400®) and zSeries® (S/390®) within the WebSphere Application Server startup to accommodate differences in these platforms. But, for all other platforms, the core Java code is the same after the startup has completed and set up the appropriate environment. The AS/400 and S/390 tags in some of the sections of the plugin.xml file highlight these differences. Figure 5-11 illustrates how WebSphere Application Server is extended to add new features.
Figure 5-11 WebSphere Application Server deployment architecture in the JVM Although this description gives you an understanding of deployment, it does not explain the base functionality that can be found in the core WebSphere Application Server runtime services and how to best tune the environment. When the core Eclipse/OSGI runtime starts up, it examines the plugin.xml file to see what components to start as part of the base, and what to offer for extension. In this file is the startup order of the application environment that the containers and the rest of the environment build upon. This core appserver base contains code that knows what platform it is running on and sets up thread pools, communications channels, and other I/O and memory management that is appropriate for the platform it is running on, as well as generic services such as Java Management Extensions (JMX) management, Java Transaction Service (JTS) transaction management, and logging. The information in the plugin.xml file and the configuration in the server.xml file control the setup and usage of the environment and how this server instance behaves. On AIX, the WebSphere Application Server runtime knows to make use of asynchronous I/O, so appropriate flags are set in the Java code. Java Native Interface (JNI) shared objects (libibmaio.so or libibmaiodbg.so) are loaded into the WebSphere Application Server address space to best use asynchronous I/O on the AIX platform. So, by tuning asynchronous I/O for the AIX platform, you effectively tune WebSphere Application Server. The WebSphere Application Server runtime requires communications with the outside world over TCP/IP sockets, so it sets up a pool of sockets and code to manage listeners and socket clients called channels. These channels can be built into a chain, so an HTTP channel builds on a TCP channel, and so on. Some channels have very specific coding that distinguishes them from other channels, such as the HTTP channels that support the Web container and Web services over TCP and SSL, the CORBA IIOP channel that forms the core of the EJB container communications via its central CORBA ORB, the Service Integration Bus (SIB) MQ messaging channel, and the internal Data Replication Service (DRS) channel used for fast communications between cluster members. These channels are managed by the appserver runtime itself and essentially sit outside of the containers. However, they pass requests, responses, packets, and messages into and out of the containers. The IIOP communications are particularly interesting because a specialized JNI shared object (libSelector.so) is used for a reader thread for this task. Note the references in many parts of the WebSphere Application Server configuration to JFAP, either with reference to the Service Integration Bus or channels, which refers to the format and protocols used for messaging (that is, WebSphere MQ-type communications with embedded messaging). There are both inbound and outbound chains of channels, which are managed independently to improve throughput and resilience. A request comes into the channel and passes through the chain before being handled by the container in a manner similar to a queue, with the container then routing the message as appropriate to the application module responsible for it for handling. Then, any response is put into the appropriate queue for the given outbound channel. The management of these mappings uses the server.xml file for the WebSphere Application Server instance in tandem with the generic configuration in the com.ibm.ws.runtime_6.1.0.jar file plugin.xml file. Figure 5-12 illustrates WebSphere Application Server channels and thread pools. Figure 5-12 WebSphere Application Server channels and thread pools Similarly, the appserver sets up thread pools that are appropriate for the platform. In past WebSphere Application Server releases, this could be problematic given the 8:1 ratio between user mode application threads and kernel threads and synchronization difficulties this could cause with external processes such as those for WebSphere MQ Server. However, the use of the AIX System thread mode and 1:1 thread ratio has removed these difficulties. The WebSphere Application Server process has Java code to manage the thread pools for the containers at one level, on which the containers and services build. But the core thread code is handled within the JVM itself and its AIX pthreads-based thread and monitor code, as discussed when examining the JVM. Configuration of these thread pools is again held in the server.xml file for the WebSphere Application Server instance. Other core services are implemented in the WebSphere Application Server runtime as Java code. However, the transaction management, logging, and RAS features of WebSphere Application Server exploit the platform, as described in the discussion of asynchronous I/O. This is unlike iSeries and zSeries platforms, which have specific code in the runtime. The security mechanism for WebSphere Application Server is essentially built on industry standards for J2EE. For the Web container, the IETF RFC 2617 standard is used for authentication. The X509 standard is used for certificates. The SSL/TLS standards in RFC 2246 are used for transport security. The EJB container standard part of J2EE is built around CORBA. For this reason the CORBA CSIv2 security standard, which includes certificate and SSL standards and patterns for their specific usage, is used. These have specific implementations within the Java Virtual Machine and its libraries, but these are supplemented with additional support in WebSphere Application Server for functions specific to an appserver environment, and which are all controlled using configuration in the security.xml file. User information is usually mapped down to an Lightweight Directory Access Protocol LDAP) directory. Java also includes the Java Authentication and Authorization Service (JAAS) for a custom implementation, and IBM ship code for the Java Cryptography Extensions (JCE) and the GSSAPI. Keep in mind, though, that while WebSphere Application Server 6.1 runs on a virtual machine that has its own security mechanisms, it also sits on top of the platform security that also includes SSL, Kerberos, and LDAP, so the two layers of security can be used in combination. It is common in an enterprise to use Kerberos and LDAP to secure AIX for the WebSphere Application Server, platform administrators, and WebSphere Application Server account, and then to have the WebSphere Application Server users who are accessing the applications running inside WebSphere Application Server also using Kerberos and LDAP, with both AIX and WebSphere Application Server sharing a common Kerberos keytab file. As with all security-related matters, WebSphere Application Server should not run under the root account, and should not have its binaries writable. But in general, the combined security is very flexible and configurable for many different purposes. Configuration for security is in the security.xml file for the WebSphere Application Server instance, and this file needs careful control and configuration. Underpinning WebSphere Application Server 6.1 architecture is something new for Version 6.1 and something that is important for a large number of IBM server-side infrastructure packages for the future. This is the Eclipse 3.1.2/OSGI (formerly the Open Standard Gateway Initiative, but now an obsolete name) runtime. This is exactly the same runtime that underpins the well-known Eclipse 3.1.2 IDE, and it is known to Rational Application Developer users everywhere. So why is it used? Because the Eclipse runtime is a framework for bundling lightweight components that can provide extensions and dynamically extend other components (known as plug-ins) at runtime, all with minimum overhead. The similar OSGI model provides bundles (similar to plug-ins) that provide services. The extensions, extension points, and services can all be enumerated via registries that use configuration files to get their metadata. Thus, a plug-in or bundle is copied into a particular directory, provides a small set of boilerplate code (although this is not a hard requirement), and either a plugin.xml file or a MANIFEST.MF file that contains details of what extensions and services it provides and which ones it uses. The Java code itself is not loaded until it is required; only the plug-in configuration files are accessed and loaded by the registry to minimize memory usage. An important consideration is that extensions and extension points carry version information with them to allow multiple versions of a component to co-reside without breaking any version dependencies for extensions. |
