GlassFish - World's first Java EE 7 Application Server


[

Unknown macro: {TableOfContents title=' '}

|(TableOfContentstitle='')]

1. Introduction

1.1. Project/Component Working Name:

GlassFish V3 Overview Functional Spec

1.2. Name(s) and e-mail address of Document Author(s)/Supplier:

Jerome Dochez
jerome.dochez@sun.com
x17062

1.3. Date of This Document:

06/19/08

2. Project Summary

2.1. Project Description:

GlassFish V3 is the next version of Sun's Java EE application server. The new features of this release are modularity, extensibility and embeddability.

2.2. Risks and Assumptions:

The biggest risk associated with this release is modularity. Previous versions of the application server were a monolithic implementation of all the features making upgradability of one particular feature almost impossible to achieve. In GlassFish V3, we switched to a modular environment where each module represent a small set of functionally close features. Transforming our monolithic implementation into a set of modules and delivering the entire GlassFish features list as a consistent set of modules interacting with each other is non trivial and will require extensive rework or rewrite of our implementation.

3. Problem Summary

3.1. Problem Area:

The new landscape of server side Java is forcing us in being more open to external technologies than traditional Java EE stack. We have repeatedly heard calls that we needed to offer more choice of technologies as well as provide a slim infrastructure to build a dedicated stack that corresponds to a particular problem area.

We have started seeing a proliferation of scripting solutions coupled with web centric frameworks available on the Java Virtual Machine. However most of these solutions are very developer centric and very little effort has been spent on deployment features. This is a market opportunity for GlassFish to offer these deployment features while respecting the container's original development environment.

3.2. Justification:

Traditional Java EE application servers can provide a wealth of experience to deployment scenario with clustering and replication, there is a real growth opportunity to untraditional users by providing features to community outside of our traditional Java EE followers.

4. Technical Description:

4.1. Details:

In order to facilitate and mitigate the risks associated with modularization, the project will use industry standard components to build or run GlassFish V3 :

Maven 2

Previous versions of GlassFish were built using a combination of ant, maven 1 and shell scripts. Technically difficult to understand and maintain, we will use maven 2 to facilitate the development of modules. Maven pom.xml naturally match modular development where each project describes the dependencies it uses and such metadata can be used at build time to generate the rather obscure OSGi metadata.

more details at http://maven.apache.org

APT and Maven plugins

A number of APT and maven plugins have been use to facilitate the service based architecture description.

OSGi

When the industry think about modularity, one of the obvious solution that we heard over the last few years has been OSGi. GlassFish V3 will use OSGi module management subsystem as a proven solution to our modularization effort.

more details at http://osgi.org/

4.2. Bug/RFE Number(s):

List any Bug(s)/RFE(s) which will be addressed by this proposed change.
Provide links to the Issue tracker Bug(s)/RFE(s)where possible

4.3. In Scope:

Aspects that are in scope of this proposal if not obvious from above.

OSGi

OSGi integration will require the following features implementation

  • ability to import OSGi bundle through an administrative command
  • ability to import OSGi programmatically
  • ability to import library jar files through and administrative command

Scripting

The following scripting environment need to be supported :

  • JRuby packaged in a WAR file as well as natively deployed
  • Grails
  • Optional : phobos

WebTier

The full Java EE 5 Web stack need to be implemented and successfully pass the CTS Tests associate with each technologies.

Grizzly Configuration

In previous versions of GlassFish, the HTML request dispatching was handled within the web container, however in V3 this has been externalized since we needed a mechanism that would be container agnostic. With this externalization of the functionality, the grizzly configuration which was contained within the web container configuration need to be pushed out and be stored somewhere else in our configuration.

The grizzly configuration should leverage or at least plug-in in the new configuration infrastructure to allow grizzly configuration to be available in situations where GlassFish is not present.

Admin GUI

Just like GlassFish, the administrative console need to be modularized to offer configuration screens based on a the current GlassFish configuration rather than a predefined set of features.

  • Ability to define Plug-in to offer particular configuration element like a container configuration. These Plug-ins should have access to facilities used by the console like JSF Templating, jMaki to provide a nice integrated user experience.
  • The core administrative console should become agnostic of which containers can be configured as the set can evolve dynamically with the adding of new plugins.
  • Branding support should be offered where external developer should be capable of altering the console look and feel as well as the product information (name, version ,etc.)

Deployment

Deployment need to offer the following pluggablity area :

  • Ability to define a new archive type. Each archive type need to be treated equally by deployment backend and each existing container should be able to leverage the new Archive type if the container's components are packaged in the archive type. New archive type should also come with an associated ClassLoader (potentially augmented to support class file transformation).
  • Ability to define new archive medium. By default GlassFish supports jar based archive as well as exploded directory archives, users should be able to define new medium for archives like a memory based one, a network one or a scattered archive when elements are disparately stored on the file system.
  • Ability to plug new Engines. Engines are container for specific components. An application can potentially contain components belonging to several unrelated engines. When such applications are deployed, each engine currently installed in GlassFish should have the ability to inspect the application to discover if components targeted to itself are present. Each engine should use the same class loader so that each components have complete freedom to directly reference classes that are ultimately running in a different engines, such class loader should be obtained from the archive type handler.

Monitoring

Monitoring should be available though industry standard interfaces like JMX but we should offer a flexible architecture where users should be able to add or activate probes through administrative actions. These probes existence should not impact negatively the application server performance when not used. A telemetry subsystem should be available to record minimum set of monitoring data when monitoring is selectively turned on. Such data should be available through the Habitat as well as JMX, depending on customer demand, we might consider adding CLI and JAX-RS endpoints to retrieve the monitoring data.

Pluggability / Extensibility

The following features of GlassFish are extensible :

  • Administration console through JSF plugins
  • Administration Command Line interface commands
  • Configuration
  • Containers (ability to run new types of applications)
  • Deployment (new archive types, new class loader implementations, new annotation processors)

REST Interface for Administration

In the previous releases, the only programatic interface to GlassFish administration and configuration was the AMX interfaces. In V3, we would like to add the following supported interfaces to our programatic capabilities :

  • Simple REST style like HTTP Forms invocation style
  • REST interfaces based on JAX-RS will be considered if there is customer demand.

Admin Infrastructure

Since we are transforming GlassFish into an extensible server side environment, we need to following features to be available :

  • Command Line Interface

The CLI infrastructure should allow for several types of clients (HTTP, JMX...) with a simple REST Style interface to lower the bar of entry for external tools to interact with administrative commands. Administrative commands should be fully extensible where external users should be able to add new commands very easily. GlassFish should stop relying on a predefined (or preconfigured) list of available commands but should use a lookup approach to discover available commands).

  • Configuration

It is important for the user to see a well integrated location where GlassFish configuration is stored (ie the domain.xml), however, with the addition of containers that are maintained externally, we must offer an extensible mechanism where each container has the ability to define its configuration data and the core admin backend takes care of storing/retrieving such configuration from our centralized location.

Embeddable GlassFish

GlassFish V3 must be embeddable in the following scenario :

  • non modular environment : Although V3 is built to be modular and dynamic, it should be possible to run it in a single class loader environment loosing its dynamic nature yet retaining all the features available preconfigured. For maximum flexibility, a single jar should be able to be created from our build environment.
  • API driven configuration : users should be able to exclusively use APIs to configure the application server rather than relying on an existing well defined domain.xml
  • layout : users should be able to drive the embedded glassfish file layout to their specific needs, GlassFish must stop relying on predefined file locations or directory availabilities. Configuration (domain.xml) should also support URL locations on top of the usual file location.
  • application file layout : users should have the ability to configure where containers will find the deployment artifacts (xml files, classes, etc...).

Installer & Desktop Integration

Packaging and File Layout Snjezana Sevo-Zenzerovic, Ken Cavanaugh

4.4. Out of Scope:

We will test V3 under a security manager, however we will not consider supporting running in a secure mode (with a security manager) a release driver.
We will not support an official upgrade scenario from a V1 or V2 installation into GlassFish V3 prelude. We are making all efforts that CLI and configuration remain compatible.

4.5. Interfaces:

Interfaces of GlassFish V3 are contained in the org.glassfih.common:glassfish-api module.

4.6. Doc Impact:

List any Documentation (man pages, manuals, service guides...) that will be impacted by this proposal.

4.7. Admin/Config Impact:

Although the GUI layout might be changed to improve usability, the overall experience should be mostly unchanged. The CLI commands should also be mostly (if not all) compatible with the previous releases. One limitation due to the dynamic nature of GlassFish V3 is that all commands may not be available in certain distributions, however, if present, commands should be backward compatible.

The domain.xml will also be backward compatible. However, because there will not be a DTD since it is now fully open and extensible, we will not apply any type of XML validation when loading.

4.8. HA Impact:

What new requirements does this proposal place on the High Availability or Clustering aspects of the component?

4.9. I18N/L10N Impact:

Does this proposal impact internationalization or localization?

4.10. Packaging & Delivery:

What packages, clusters or metaclusters does this proposal impact? What is its impact on install/upgrade?

4.11. Security Impact:

How does this proposal interact with security-related APIs or interfaces? Does it rely on any Java policy or platform user/permissions implication? If the feature exposes any new ports, Or any similar communication points which may have security implications, note these here.

4.12. Compatibility Impact

A lot of new features as well as a complete re-architecture of the product is a challenge to compatibility. However, all efforts must be spent to support backward compatibility. If a mechanism must be redesign in a incompatible manner, the new mechanism should be the default mode of operation but the old mechanism should be available at least optionally.

In particular, APIs, or anything that can be used with scripts (CLI) must be supported unless specifically approved by CCC.

There is no migration/upgrade tool for GlassFish V3 prelude.

4.13. Dependencies:

List all dependencies that this proposal has on other proposals, components or products. Include interface
specifics above in the interfaces section; LIST dependency component version requirements here.

5. Reference Documents:

List of related documents, if any (BugID's, RFP's, papers).

Explain how/where to obtain the documents, and what each contains, not just their titles.

6. Schedule:

6.1. Projected Availability:

Dates in appropriate precision (quarters, years)