GlassFish Application Server: Present and Future

Much has happened in the GlassFish community since the introduction of the GlassFish Java Platform, Enterprise Edition (Java EE) application server at last year's JavaOne conference.

The main goal of Project GlassFish has been to produce an application server that implements the Java EE standard. The server is licensed under the Common Development and Distribution License (CDDL), which allows developers to view, use, edit, and alter the code, as well as to distribute or use the code in production.

Session TS-4436, "Technical Overview of GlassFish v2," presented by Dhiru Pandey and Larry White, brought the audience up-to-date on recent developments. Later in the day, Jerome Dochez presented TS-6503, "GlassFish v3 Architecture Review," and provided a preview of version 3 (v3).

Version 2 of the GlassFish server, due to be released at the beta 2 level this week, contains many new features. Here are the most prominent:

• Improved clustering and session failover capabilities
• Web Services Interoperability Technology (WSIT)
• Support for Java Business Interface (JBI) technology

Instances of the GlassFish application server can be grouped into clusters, which can be administered jointly. For example, an administrator can distribute an application to all instances in the cluster with a single deployment.

The clusters are dynamic, so when an instance is added or removed, the changes in cluster topology are handled automatically. The automation is made possible by Group Membership Service (GMS), which provides up-to-date membership information for the cluster, and the replication framework, which reshapes cluster topology when necessary.

At the heart of the GlassFish dynamic clustering capability lies GMS, an outgrowth of Project Shoal. Project Shoal is a Java technology-based clustering framework that provides infrastructure to build fault tolerance, reliability, and availability. GlassFish clustering capability also makes use of Project JXTA peer-to-peer communication technologies.

In a GlassFish cluster, GMS runs as a process on each instance. GMS keeps track of group membership by registering a callback function that is invoked whenever group membership changes. Instance members can be added and removed from the cluster, and members might fail and recover. As these events occur, GMS adjusts the cluster membership automatically.

Moreover, GMS can differentiate between a member that leaves the group deliberately due to administrative action and a member that leaves the group due to failure. GMS itself requires very little administrative overhead.

The combined abilities of GMS to monitor cluster membership and of the replication framework to change cluster topology forms the basis of the new GlassFish v2 high-availability solution.

Sun Microsystems has historically offered a robust high-availability solution for application servers based on High-Availability Database (HADB) technology. HADB offers 99.999 percent ("five nines") availablity for maintaining session-state information. However, it has a higher cost to implement and maintain and, although freely available, has not been available in an open-source version.

Requests for a lighter weight, open-source alternative have resulted in an in-memory replication feature for GlassFish version 2. In-memory replication relies on instances within the cluster storing state information for one another in memory, not in a database. The HADB solution remains available, however, and may be preferred for many installations.

In the GlassFish application server, cluster instances are organized in a ring topology. Each member in the ring sends in-memory state data to the next member in the ring, its replica partner, and receives state data from the previous member. As state data is updated in any member, it is replicated around the ring.

When a member fails in the ring topology, the ring is broken. As noted earlier, GMS can recognize the failure of a member. In that event, the replication framework reshapes the topology of the cluster and notifies members of the changes. When a member learns that its replica partner has disappeared, it selects a new partner from in-service members.

Note that reshaping a cluster does not rely on each instance communicating directly with all of the others. Solutions based on that scheme do not scale well to large clusters.

In the GlassFish clustering scheme, the load balancer tier is not expected to provide any special or proprietary features in order to maintain high availability. The load balancer tier simply sends requests for service to members in the cluster until an in-service member acknowledges its request. Within the cluster, the replication framework makes sure that the responding member is provided the state information that it needs to provide service.

To enable interoperability between the Java platform and Microsoft .NET 3.0, GlassFish version 2 implements Web Services Interoperability Technologies (WSIT). WSIT is an outgrowth of Project Tango, a part of the GlassFish community development effort.

In the GlassFish server, WSIT is used to provide advanced web services features such as bootstrapping, optimizing communication, reliable messaging, atomic transactions, security, and trust. For more on WSIT, check out session TS-4865, "Takes Two to Tango: Java Web Services and .NET Interoperability."

Developers of service-oriented architecture (SOA) composite applications will appreciate another new feature in version 2: the inclusion of runtime components for Java Business Integration (JBI).

A SOA composite application is made up of components that provide and consume one another's services, communicating through messages. With JBI, the components need not interact with each other directly. Instead, JBI acts as an intermediary to route messages between components. A standard message format ensures that all components understand one another. An abstract service description is the only coupling between a service consumer and a service provider. The service description is expressed in Web Services Description Language (WSDL).

GlassFish Application Server, version 2 arrives with many more enhancements. Among them are the following:

• Usage profiles. Usage profiles configure the server for different user roles. Three profiles are provided by default: developer, cluster, and enterprise. For example, most developers work within a single domain and machine, and they would choose the developer profile to improve performance and expend the least administrative effort.

• Security. Version 2 supports JSR 196, which provides a standard service provider interface for authentication. It also supports encryption with Elliptic Curve Cryptography (ECC) and Java Key Store (JKS) format. To provide the ability to grant permissions based on authentication, but independent of identity, the server supports assign-groups in the security realm. Finally, the server supports JDBCRealm to authenticate users and define their security roles based on information from a relational database accessed through JDBC APIs.

• Web container. Web container enhancements include multiple docroot support and compliance with the Apache JServ Protocol. Dynamic attributes and property changes are allowed without requiring a server restart. In addition, a nonblocking implementation of SSL has been implemented using Grizzly for improved performance.

• New admin console. The admin console graphical user interface (GUI) has been reimplemented. It now provides Project jMaki charting for monitoring charts. The console uses Ajax techniques to refresh the navigation tree, providing faster perceived user response.

• Update Center. The Update Center provides a GUI for users who want to find the latest software and information available from the Download Center web site.

• Specification updates. The following specifications were updated for GlassFish application server, version 2:

  • JSR 196: Java Authentication Service Provider Interface for Containers
  • JSR 208: JBI
  • JavaServer Faces 1.2 technology: maintenance release
  • JavaServer Pages (JSP) technology: maintenance release
  • JavaServer Pages Standard Tag Library (JSTL): maintenance release
  • Servlet: maintenance release
  • Java API for XML Web Services (JAX-WS): maintenance release
  • Java Architecture for XML Binding (JAXB): maintenance release

The success of the GlassFish version 2 application server in beta release has stimulated interest in version 3.

"The two biggest architectural improvements for version 3 are modularity and open extensibility," said Jerome Dochez in TS-6503, "GlassFish v3 Architecture Review."

The organization of GlassFish version 3 subsystems into modules is loosely based on the work of JSR 277, which defines a distribution format and a repository for collections of Java technology code and related resources. The specification promises to overcome the shortcomings of distribution by means of Java Archive (JAR) files, which have no versioning mechanism, no ability to enforce interdependency, and no automatic way to track classpaths that change during deployment.

During development, each module in GlassFish version 3 is identified by a name and version number. Each module requires one class loader, which can deploy as many JAR files as necessary.

At runtime, modules are identified by module instances. Each module instance has two class loaders: a public one that users can access and a private one that loads all of the module's classes. Each module has a list of other modules' class loaders to handle loading of imported classes. Garbage collection occurs after all references to the public class loader have been released.

Modularity provides advantages both at runtime and during development. First, it means that startup can be much faster because only the application container that will be used for a deployment needs to be loaded, not the entire infrastructure.

The modular architecture also means that GlassFish version 3 will be easier to maintain. Modules can be updated independently instead of replacing the entire server with a new patch.

Modular updates give developers and administrators more independence in updating their installations. Different versions of the same module can live happily within a single GlassFish application server. So when a new module is installed, an older version of the same module can still be used until the applications that require it can be tested and qualified with the new module.

In the past, application servers were typically restricted to Java EE applications -- web applications, EJB beans, web services, and the like.

GlassFish version 3 breaks that restriction. In the new architecture, the application server is a metacontainer for application containers. As a result, you can install application containers that can run applications other than those based on Java EE technology: Ruby on Rails applications or PHP scripts, for example. These applications can be developed more quickly due to improved support for interactive development cycles. And these applications can be deployed directly without the need for complicated repackaging.

GlassFish version 3 will provide a number of containers by default and will also publish APIs that developers can use to add additional container types. According to Dochez, the GlassFish community has already received requests from developers who want to add their own containers to the GlassFish framework.