AIX > Tips & Techniques > Application Development

A New Take on WAS Internals

A complete Java program, even a heavyweight application such as the WebSphere Application Server, is just a process. This means that the outside systems’ management tools can’t see what the Java code itself is doing, as it’s just an impenetrable process.

 

In the last installments of this series we looked at the IBM implementation of the Java Virtual Machine (JVM) and how IBM optimized it for the AIX platform. We also considered how this benefits the WebSphere Application Server (WAS) platform.

This next batch of articles will explore the Eclipse runtime that underpins the application server, or more precisely the OSGI runtime at the core of Eclipse. Finally, we’ll explain how this affects the internals of WAS and its behavior on the AIX OS. Before we do that, we must first recap on the basics of Java and the Java 2 Extended Edition, the focus of this article.

Java Basics

Java was originally designed as a simplified portable, object-oriented, multi-threaded language derived from C++, using the tied-in virtual machine to offer greater security and safety over existing environments. Safety essentially refers to the language being strongly typed and having no pointers to avoid common bugs. Contrary to popular belief the JVM can run other languages—with the only real requirement that classes consisting of byte code with the appropriate package structure are executed.

Initially, Java was aimed at the embedded device market where processors and systems facilities vary greatly, but now the language has become ubiquitous. To allow programs to operate consistently where underlying system consistency is lacking, whilst avoiding a lowest common denominator approach, a number of rules must be adopted. Programs can’t rely on how garbage collection is implemented and when it’s performed, the priority of threads outside of program specified synchronization, and how the underlying APIs themselves are implemented. Java also provides extensive built-in security to isolate the platform from errant Java programs:

• Garbage collection can often be controlled to suit particular application roles and systems implementation, as we looked at previously, and the way memory is managed by the underlying OS affects this behavior. Thus, on the AIX OS the functionality of the MALLOCOPTIONS and MALLOCTYPE, and the LDR_CNTRL environment variable settings can influence the memory allocation behavior of some JVM versions or the same functionality is implemented in the JVM itself and enabled by JVM command line options.
• Threading inside the JVM used to be implemented on the AIX platform with user mode threads, i.e. the equivalent of the threading environment variables AIXTHREAD_SCOPE=P and AIXTHREAD_MNRATION=8:1. However, like with many programs, this led to synchronization issues with external programs (such as WebSphere MQ 5.3), so the latest JVMs use a 1:1 mapping with AIX kernel threads or AIXTHREAD_SCOPE=S and AIXTHREAD_MNRATIO=1:1. In reality, these latter values should be used as the default for all environments with later AIX releases.
• When implementing an API a choice is made between having the API as a thin wrapper for a native method implemented in some other language (usually C or C++) or whether to use more elemental Java APIs to build the required functionality. Take the HTTP functionality implemented by the java.net.URLConnection class, which can be implemented entirely in Java using the java.net.Socket class or can be implemented directly using the underlying host system functionality exposed via a Java Native Interface (JNI) library call. To produce a JNI-based API, a class must be implemented in Java, an underlying shared object must be implemented using an external language, and this external code calls the OS APIs. Ultimately, the core functionality of the Java socket interface is implemented in the JVM via calls to the host OS, but there is a variance in where the line is drawn. See Figure 1.

Remember that a complete Java program, even a heavyweight application such as the WebSphere Application Server, is just a process. This means that the outside systems’ management tools can’t see what the Java code itself is doing, as it’s just an impenetrable process. However, newer tools can make use of the JVMTI and JVMPI performance monitoring interfaces—with the lightweight JVMTI interface offered by the Java 5 virtual machines being preferred.

Java 2 Extended Edition

The Java 2 Extended Edition (J2EE) is a specification for a set of enterprise server-level services and APIs that every compliant server must support. The implementer is free to implement those APIs and services however they wish, as long as the specification is adhered to. In many ways the J2EE can be described as “paperware,” as it consists of a set of paper descriptions and a simple reference environment to give examples. The services consist of a number of interfaces for scalable persistence and database access (JDBC and EJB Entity Beans), user interface and Web (and other protocol) handles (JSP and servlets), message queuing interfaces and behavior, etc. One important part of specification is the requirement for two distinct containers within the Java process—the Web container for handling JSPs and servlets, and the EJB container for handling session, message-driven and entity bean business component code in a scalable manner—each of which offers further layers of isolation within the Java process. The implementer has to decide how much of this environment is to be implemented as elemental Java code and how much is to be implemented separately in external JNI component libraries. In early WAS releases, most of the core function was implemented using the external JNI method with code from the earlier IBM Component Broker tool, but most of the core code in later versions has been Java-based. See Figure 2.

The next articles in this series will cover Eclipse and OSGI runtime, AIX storage structure and more. Previous articles on WAS internals begin here.

 

Tweet