About extensibility in GlassFish v3 prelude

GlassFish v3 is both less and more than a Java EE 5 application server. 


OK, to be precise, one way v3 prelude - today's release - is less is that the only Java EE app type it supports is web apps.  The others will come with the final release.


A much more interesting way in which GlassFish v3 is less than an app server is that GlassFish v3's highly modular architecture loads only those parts you want or need.  In fact, v3 will figure out what modules it needs and load them when it needs them.  This helps a lot with fast start-up.


GlassFish v3 is more than an application server because the v3 architecture makes it very easy to add brand new types of containers that handle application types that are not even in Java EE.  GlassFish v3 defines a service provider interface (SPI) which each container developer needs to implement.  Then the GlassFish v3 framework invokes the container's implementation of the SPI to detect, deploy, and manage applications of the new type. 


There are other aspects of extending GlassFish v3 as well.  For example, Jason Lee has written about how you can extend the admin console.  Here I'll focus on how new types of containers can be added to GlassFish v3.


Although what follows is a bit of a simplification, it gives an overview of how all this works.  The container developer builds two or more OSGi modules which contain an implementation of the SPI, makes those modules available to GlassFish v3, and right away GlassFish v3 knows how to handle the new application type.  Specifically, the OSGi modules for the new container type provides implementations of three key interfaces defined by GlassFish v3: (scroll down to see the table - there's extra space, I guess due to the formatting...)





















Interface  Purpose
 Sniffer  Reports whether this container type recognizes a given application (used during deployment)
 Deployer  Takes an application's bits and makes them ready for execution
 Container  Loads and runs the application


The diagrams below illustrate how the GlassFish v3 backbone interacts with the implementations of these interfaces as an application is presented to GlassFish v3 for deployment.


First, an admin request arrives from a client program, such as the admin console or the asadmin command-line tool.  GlassFish examines the request and figures out that it is asking for deployment of an app. 


Resolving admin command as deployment request


Once GlassFish identifies this as a deployment request, the DeployCommand logic asks each Sniffer present in this GlassFish v3 environment if it can handle the application being deployed.  For each one that can, GlassFish v3 invokes the corresponding Deployer implementation and, if the app is enabled (the default during deployment), has the Container start the application.


Preparing, loading, and starting a new application


The amount of work involved in writing the implementations of these three interfaces depends, naturally, on how complicated the application type is.  But once written, those implementations can be made available to GlassFish v3 very simply and GlassFish immediately knows how to deal with applications of that type.


This is exactly how support for web apps is provided in GlassFish v3 prelude. 


Look in the Add-on Component Development Guide of the GlassFish v3 documentation set for more details.

Comments:

Nice Blog. I really like the UML sequence diagram. It also illustrates the modularity of CLI commands.

Posted by Jane Young on November 06, 2008 at 05:58 AM CST #

Post a Comment:
  • HTML Syntax: NOT allowed
About

News and musings on the technology I work on at Oracle.

The views expressed on this blog are my own and do not necessarily reflect the views of Oracle.

Search

Categories
Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today