The GlassFish Server support for JMS messaging, in general, and for message-driven beans, in particular, requires messaging middleware that implements the JMS specification: a JMS provider. The GlassFish Server uses the GlassFish Message Queue software as its native JMS provider. The Message Queue software is tightly integrated into theGlassFish Server, providing transparent JMS messaging support. This support is known within GlassFish Server as the JMS Service. The JMS Service requires only minimal administration.
The relationship of the Message Queue software to the GlassFish Server can be one of these types: EMBEDDED, LOCAL, or REMOTE. The effects of these choices on the Message Queue broker life cycle are as follows:
If the type is EMBEDDED, the GlassFish Server and Message Queue software run in the same JVM, and the networking stack is bypassed. The Message Queue broker is started and stopped automatically by the GlassFish Server. This is the default for the Domain Administration Server (DAS).
Lazy initialization starts the default embedded broker on the first access of JMS services rather than at GlassFish Server startup.
If the type is LOCAL, the Message Queue broker starts when the GlassFish Server starts. This is the default for all GlassFish Server instances except the DAS.
The LOCAL setting implicitly sets up a 1:1 relationship between a GlassFish Server instance and a Message Queue broker.
If the type is REMOTE, the Message Queue broker must be started separately. For information about starting the broker, see the Oracle GlassFish Message Queue 4.4.2 Administration Guide.
For more information about setting the type and the default JMS host, see Configuring the JMS Service.
For more information about the Message Queue software, refer to the documentation at http://docs.sun.com/coll/1343.13.
For general information about the JMS API, see the JMS web page at http://java.sun.com/products/jms/index.jsp.