Both JMS Queues and Topicss are referred to generally as destinations. From a J2EE perspective, they also fall under a group (along with connection factories) known as administered objects. This means that they must be created and maintained by an administrator, external to a bean or application. It also means using a vendor-proprietary method to perform these tasks. The J2EE RI administration tool, j2eeadmin, includes the capability to create queues and topics. We've seen j2eeadmin before, when adding a DataSource entry (see The Rock Survey Database). For destinations, the
-addJmsDestination
input argument is sent to
j2eeadmin. The deployment panel for the message-driven bean example program,
Deploying the Rock Survey, Take 3, shows how to use
j2eeadmin to create a
Queue.
Ultimately, messages are the reason for using JMS. The API defines a Message interface, along with subinterfaces for specific message types. A Message is composed of three parts:
-
Header — Header values contain information useful for identifying and routing messages.
-
Properties — Properties are a built-in mechanism for adding application specific header information. Programs can use this information for message selection and filtering.
-
Body — JMS defines five body types (and corresponding subinterfaces) for a
Message:
-
Bytes
-
Map
-
Object
-
Stream
-
Text
You can read about the details of the types and subinterfaces in the J2EE API documentation. The important thing to consider here is message data portability; clearly, a Message containing a Java Object will not be understood by a C language, COBOL, RPG, or other language program. While being portable often means doing more work, Java developers, more than any others, should value portability in data as well as code, right? Therefore, careful consideration should be given to message types and their implications during your application design.
