|
5.2.1 WebSphere Application Server and the JMS Messaging EngineIn WebSphere Application Server 5.1 and earlier, JMS was supported through an external implementation of WebSphere MQ Server using either WebSphere Embedded Messaging Publish and Subscribe (WEMPS) or the full WebSphere MQ Server implementation. Almost the same binaries were used for either setup, but only the full implementation could interact with external remote WebSphere MQ environments. This setup led to a standard WebSphere Application Server implementation that required JMS to have a minimum of 10 processes running (9 minimum for WEMPS or WebSphere MQ), and environment variable setup requirements (that is, AIXTHREAD_SCOPE=S and AIXTHREAD_MNRATIO=1:1) to allow thread synchronization to function properly between these processes on AIX. This difference is illustrated in Figure 5-1.
Figure 5-1 WebSphere Application Server and the JMS Messaging Engine: from Version 5.1 to Version 6.x With the release of WebSphere Application Server 6, the Service Integration Bus and its embedded messaging implementation runs entirely inside the Java process. This change eliminates any external synchronization issues. This WebSphere MQ implementation in the Java space satisfies the requirements of the JMS specification, and can interoperate with remote WebSphere MQ environments. In addition to the messaging implementation changes and numerous other tuning and structural improvements, WebSphere Application Server 6 introduced an internal high availability manager called HAManager to manage high availability for a cluster and the failover of Java singleton components from one cluster member to another. This is similar in concept to High Availability Cluster Multi Processing (HACMP), but sits inside the Java process and works with Java artifacts, such as the Service Integration Bus components. Message queuing components are a good example of a singleton because there should be only one message queuing server actively receiving messages onto a queue at one time if message ordering is to be preserved. On WebSphere Application Server 6, the earlier Java 1.4 family of Java Virtual Machines was used to support the J2EE 1.4 standard. With WebSphere Application Server 6.1, the Java5 (1.5 JVM) "Tiger" Java Virtual Machine was introduced, but still supporting a J2EE 1.4 standard environment. This improves monitoring of performance inside the JVM through the introduction of the JVMTI standard, greatly improves memory management, makes coding easier and safer with new language features such as "generics". With each new release of the IBM Java Virtual Machine and WebSphere Application Server, other IBM-specific new features are added. With the Java5 release of the IBM J9 JVM, additional memory management features for improved garbage collection were added, as well as class sharing to minimize memory heads for multiple WebSphere Application Server processes running inside a single operating system image. For WebSphere Application Server, the runtime environment was changed so that it is based on an Eclipse implementation of the OSGI framework. This allows a component extension approach to hosting J2EE services and components. A SIP container (for VoIP and multimedia support) and Portlet container were also added to the Web container. Figure 5-2 displays the new features added to WebSphere Application Server 6.1.
Figure 5-2 New features introduced in WebSphere Application Server 6.1 |
