GlassFish is an open source application server for developing and deploying Java EE applications and web services. This server is compliant with Java Enterprise Edition 5 (Java EE 5), and is in fact the reference implementation of Java EE 5.

The GlassFish server offers tremendous support for JMS messaging, by offering a fully integrated JMS provider. The Java Message Service API is implemented by integrating Sun Java System Message Queue software into GlassFish, providing transparent JMS messaging support.

Few Terms to clear out :

what is domain in glassfish : A domain (statically) is an administrative name space. It’s a boundary, all GlassFish entities within which are controlled by an administrator.

Refer image : http://blogs.sun.com/bloggerkedar/resource/as-domains.jpg

what are node-agents : Node agents are responsible for communication between you domain admin server and server instances or clusters. You create a node agent be executing asadmin create-node-agent <nodeagentname>. If you don’t specify a node agent name the hostname if your system will be used. If you create your node agent on a different server you also have to specify host/port information for your domain admin server by giving –host <hostname> –port <portnumber> to asadmin

JMS Support in GlassFish

GlassFish supports two JMS resources: the connection factory and destination resources.

A connection factory is an object used by JMS clients to create a connection to a JMS provider. Connection factories can be of three types:

  • Connection factory: Used by point-to-point as well as publish-subscribe messaging models.
  • Queue connection factory: Used by the point-to-point messaging model.
  • Topic connection factory: Used by the publish-subscribe messaging model.

A destination is the object used by JMS message producers to post the message to and the source from which JMS message consumers consume the message. Supported destination types are:

  • Queue: The queue is the destination for point-to-point communication.
  • Topic: The topic is the destination for publish-subscribe communication.

Following are some of the JMS connection features supported by GlassFish.

Connection Pool

A GlassFish server automatically pools JMS connections. The user can set connection pool properties using the GlassFish admin console or asadmin commands. Connection pool details are configured while creating connection factories. Some of the connection pool parameters supported by GlassFish are:

  1. Initial and minimum pool size: Indicates the number of initial connections in the pool. This is also the minimum number of connections set for the pool.
  2. Maximum Pool Size: The maximum number of connections available in the pool.
  3. Pool resize quantity: The number of connections to be removed when the pool reaches idle timeout.
  4. Idle timeout: The maximum time that a connection may remain idle in the pool.
  5. Max wait time: The maximum wait time before a connection timeout is sent.
  6. Failure action: In case of a failure, the connection can be closed and reconnected.
  7. Transaction support: The level of transaction support. Supported transaction types are “local transaction,” “XA transaction,” and “no transaction.”
  8. Connection validation: If this property is selected, connections will be validated before passing them on to the application.
Connection Failover

This feature enables the application server to reconnect to the message broker if the connection is lost. If reconnection is enabled and if the primary message broker goes down, then the application server will try to reconnect to another available broker. The user can configure the number of retries and the time interval between retries.

Accessing JMS Resources from Application

In GlassFish, the connection factory and destination can be accessed in two ways: by using Java Naming and Directory Interface (JNDI) lookup or using annotations.

JNDI Lookup

JMS clients can use the JNDI API to look up connection factories and message destinations.

 InitialContext jndi = new InitialContext(); // Lookup queue connection factory QueueConnectionFactory qFactory = (QueueConnectionFactory)jndi. lookup("webTrackerConnFactory"); // Lookup queue Queue queue = (Queue)jndi.lookup("webTrackerQueue"); 

Annotations are a declarative style of programming introduced in Java SE 5.0. Annotations are like metatags that can be applied to classes, constructors, methods, variables, etc.

The annotation @Resource is used for looking up connection factories and destinations. In a web application, if this annotation is placed on a variable, then the servlet container will inject the requested resource; i.e., the annotated variable will be pre-populated with an appropriate value before serving the request.

 @Resource(name="connFactory", mappedName="webTrackerConnFactory") private QueueConnectionFactory qFactory; @Resource(name="jmsQueue", mappedName="webTrackerQueue") private Queue queue; 
Put Messaging to Work

So far we have discussed how JMS and MDB work together to facilitate asynchronous messaging. We have also seen GlassFish’s capabilities and the JMS support it provides. Now we will see how we can make these technologies work with the help of a realtime use case called “Web Access Tracker.”

Web Access Tracker helps site administrators or business users to monitor user request statistics like the number of visitors on a day, frequently accessed pages, page/service requested time, request serving time, etc. In the following section, I will explain a solution to collect the web access information for each page accessed by the user, without compromising on the performance of the actual application. You can download the full source code of this example, as well as its deployable binary file, from the link in the Resources section.


A JMS-based messaging solution has been selected to capture and process web access data with the help of other technologies like Java Architecture for XML Binding (JAXB), Java Server Faces (JSF), servlet filters, etc. GlassFish provides support for JMS messaging and also for deploying the application.

The demo application uses a servlet filter to intercept user requests and to extract required information from the request header. This information will be then posted to a message queue as a JMS message. Messaging is done asynchronously through a message-driven bean, which is the consumer for JMS messages. The data collected from the message will be persisted to an XML data store. JAXB is the technology of choice for accessing and storing data into XML files. User interfaces are developed using JSF.

Refer : http://today.java.net/pub/a/today/2008/01/22/jms-messaging-using-glassfish.html