Technical Session: Java Platform, Enterprise Edition 6 with Extensible GlassFish Application Server v3

In the session, Java Platform, Enterprise Edition 6 with Extensible GlassFish Application Server v3, architect Jerome Dochez and engineer Mahesh Kannan gave details of the upcoming GlassFish v3 release, now available as a preview download.

For those who have been napping for the past four years, GlassFish is the Java EE open-source application server sponsored by Sun Microsystems. GlassFish v3 is a major rewrite of the v2 release. It features a lightweight and extensible core based on OSGi, a web and scripting container, and an easy-to-use Admin Console for configuration and management. You can develop and deploy on GlassFish v3 from NetBeans 6.7, currently in beta test). The GlassFish v3 application server, together with the release of Java EE 6, forms the cornerstone of the Java platform on the server side.

GlassFish is the reference implementation of Java EE, and Douchez began by explaining how features of Java EE 6 made their way into GlassFish.

Profiles are subsets or supersets of Java EE technology that provide only the important capabilities needed by a development role. The first such profile, described in the Java EE 6 specification, is the Web Profile. Future profiles will be defined in the Java Community Process. The intent was to drive the same sort of developer productivity that was granted by Java EE 5 for Enterprise JavaBeans (EJB) containers -- that is, the ability to use annotations inside servelets rather than having to write complicated XML files.

Because GlassFish is a reference implementation, it must deliver a different version of GlassFish for each profile in Java EE 6. This constraint added to the inclination towards a modular architecture for GlassFish v3.

Making development easier with Java EE has been an ongoing concern. Java EE 6 addresses this concern for web development by using annotations across all web APIs, reducing or eliminating the need for deployment descriptors (no editing of web.xml required), allowing third-party libraries to self-register, simplifying packaging, providing JAX-RS for RESTful web services, and in general getting technologies to work well together.

You can use a light EJB container as an embedded container inside your Java EE 6 application. Moreover, the entire GlassFish v3 application is embeddable, making it possible to start and stop GlassFish through its API.

With version 3, GlassFish opens up to all Java Virtual Machine (JVM) technologies, notably JRuby/Rails. One advantage for Ruby developers is that you do not need to deploy a Ruby application as a war file. Instead, GlassFish v3 can directly invoke the JRuby interpreter and deploy a Rails application natively without modification. In addition to multiple runtime deployment options, GlassFish v3 offers dynamic resizing of the JRuby runtime pool. As a result, GlassFish performs well under high load while consuming minimal resources under low load.

With this release, you can extend the functionality of GlassFish through its API, and expose that functionality through the Admin Console. Moreover, you can add features to the platform dynamically without having to restart. Extensibility is made possible by APIs that can replace or extend features. OSGi also provides extension capabilities that you can leverage to extend the OSGi runtime.

One aspect of the modular design of GlassFish v3 is a service-based architecture. Services are defined by contracts whose implementation can be changed with relative ease. Service-based architecture also permits lazy loading based on usage patterns.

Expanding GlassFish capabilites for version 3 required a new, modular architecture. The modularity features of GlassFish v3 are based on OSGi. OSGi's service-based architecture enables these components to dynamically discover one another and collaborate.

The microkernel of the new architecture is small. It makes GlassFish v3 a lightweight deployment platform that starts quickly and uses resources sparingly because it uses lazy loading to start only those services required to support deployed applications. For example, if your application does not use the EJB container, it is never loaded.

Many small modules can mean a lot of moving parts, and GlassFish v3 is delivered as 170 bundles. Even with this number of modules, GlassFish startup is fast. The hope is to reduce the number of bundles to around 100.

A strong build tool was necessary when developing the project, chiefly because of the complexity of bundle dependencies. The GlassFish team used Maven, the Apache build manager for Java projects, to simplify the build process.

GlassFish v3 features embedded APIs that can be used to start and configure the application server. This means that you can, for example, start and stop GlassFish containers from within a Java Platform, Standard Edition (Java SE) application. When the development team tested the GlassFish application, they used this technique from inside Maven, which is itself a Java SE application. A GlassFish v3 plug-in will be made available for testing with Maven.

The 170 GlassFish v3 bundles are divided into three types: kernel, services, and containers. The kernel provides startup/shutdown sequences, basic services such as deployment, and configuration reading. The kernel bundles compose a nuclear distribution: the smallest possible GlassFish distribution. It has no container, nor any ability to run an application. It is a building block about 3 MB in size.

Riding atop the kernel bundles are the services bundles, which provide cross-container functionality such as security, a naming manager, and the Admin Console.

Container bundles ride atop the kernel and services bundles. Container bundles provide independent, isolated containers that handle user applications. For example, web containers run web applications, and EJB containers run EBJ applications. Independent containers are essential to implementing profiles, which can each specify a number of different containers. Glue code is used for communication between containers and the kernel, OSGi, and basic services.

Depending on the requirements of a deployed application, GlassFish v3 can determine which containers are required, and can start them automatically. Each container has its own configuration, which is stored in one central configuration file. Organizing configuration data in a cental file makes it much easier to implement clustering in GlassFish v3. Application containers can accept commands from the command line or from REST invocations.

The modules used to distribute GlassFish are packaging artifacts. They are just jar files that specify what to import and export so that all dependencies are resolved. As a developer, your primary coding responsibilites are to program services, which are of two primary types: OSGi and HK2. HK2 abstracts the OSGi API, and provides services not available in OSGi.

To build an HK2 service, you declare interfaces with @Contract annotations, and you declare implementations with @Service annotations. The build system will then generate metadata automatically. No complex XML files are required.

Service lookup is dependency driven and produces automatic cascading. Asking for one service may cause that service to ask for contributing services, which may ask for other services in turn. If you have objects that cannot be managed, you can use APIs to look up a service by name, using a hash table approach.

Kernel components are furnished with glue code that accepts Deployment, Configuration, Grizzly, Monitoring, and Admin GUI connections. A container must provide mating glue code (for a Deployment connection as a minimum). Neither the kernel nor the container need any knowledge of one another's internals. They interact through service contracts.

Figure 1: Application Container and Kernel at Runtime

You write the glue code using four interfaces: a Sniffer, to recognize applications; a Container, one per container; a Deployer, one per container; and an Application Container, one per application.

All configuration interfaces are implemented by a single class. The class uses annotations to create a centralized XML configuration file. The configuration automates clustering support, MBeans generation for configuration data, REST interface for configuration data, and transaction access to mutating data. Although GlassFish v3 appears to be composed of disparate bits and pieces, it is experienced as a well-integrated product.

You can use JAX-RS to provide REST interfaces to configuration data, commands invocation (deploy, undeploy, and so on), and monitoring. You can even use REST clients as a substitute for the provided administrative console.

If you like, you can add administrative commands specific to each container. For example, the following code defines a new command called change-random-ctr that could be used to mutate a container's configuration.

@Service(name="change-random-ctr")
public class ChangeRandomCtr implements
AdminCommand {
  @Param
  String s1;
  @ParamString s2;
... } 

This class makes the following command available on the CLI:

asadmin change-random-ctr -s1 foo -s2 bar 

Monitoring in GlassFish v3 is probe based. Probes are defined by each module, and are turned off by default to eliminate overhead. Probes are enabled dynamically. When listeners register, probe implementations are dynamically rewritten to start firing events.

The strategy yields a lightweight implementation because only what is needed is enabled. The probe strategy uses BTrace under the covers, so monitoring is possible on all platforms. However, GlassFish v3 is DTrace enabled for use on the Solaris OS. Modules define probe points and, with open APIs, any module can define probe points.

» GlassFish Community
» GlassFish Downloads
» GlassFish v3 Preview with Java EE 6 SDK Preview Downloads
» GlassFish v3 Preview and Java EE 6 SDK Preview Documentation and Resources
» Java EE 6 Technologies

Do you have comments about this article? We welcome your participation in our community. Please keep your comments civil and on point. You may optionally provide your email address to be notified of replies - your information is not used for any other purpose. By submitting a comment, you agree to these Terms of Use.