The JMS API describes the ConnectionFactory and TopicConnectionFactory.

Jerry Smith

In addition to TopicConnectionFactory, the JMS API also includes QueueConnectionFactory, which provides connections for queued, or point-to-point (P2P), communications. Although support is growing, not all JMS providers implement P2P messaging at this time.

An application receives certain JMS-related objects from a JMS factory that are administered in the sense that these resources are controlled by the JMS server's security subsystem. The security subsystem varies from vendor to vendor and is not part of the JMS specification from Sun Microsystems. Most JMS middleware vendors provide a graphical console for administering these resources.

Applications (distributed application components) typically communicate via one or more destinations (topics and/or queues); these destinations are placed under the control of the security subsystem. Thus, for application components to produce or consume messages via these destinations, they (1) must be on the access list for the named destinations, (2) hold the appropriate user ID and password at the connection (or some other) level, or (3) satisfy other vendor-specific access criteria.

For intranet- or extranet-distributed applications, these security steps are often necessary; for experimenting with JMS, these steps are a minor inconvenience. Some JMS servers, however, automatically create destinations with guest access privileges, so that the security subsystem is virtually seamless. Applications can "turn on" a higher level of security at a later stage in the development cycle. Even for JMS servers that require direct participation with respect to the security subsystem, the process is often as simple as providing user ID and password arguments when invoking a factory method. For example, with the JMS middleware from Progress Software, the following steps (1) obtain a connection factory, and (2) create a connection, and (3) start a session:

  try {
    qcf = new progress.message.jclient.QueueConnectionFactory(url, "");
    con = qcf.createQueueConnection(userId, password);
    session = con.createQueueSession(false, Session.AUTO_ACKNOWLEDGE);
  catch (Exception e) { /* handle exception */ }

In order to set up a JMS-capable application, that is, in order to access JMS services within a distributed application, you must:

  • Obtain the appropriate connection factory
  • Obtain the appropriate connection from the factory
  • Obtain a session object from the connection
  • Obtain a queue/topic from the session
  • Obtain a consumer or producer object
  • In the case of a consumer connection, register a message listener (if the client wants to receive messages asynchronously)
  • Activate the connection
  • When the application is finished, close the connection

This process involves several steps, but the resulting messaging capabilities are extensive. Also, this process is "routine" and amazing similar for each application, so it's pretty easy to write a convenience class that performs these step, and that is configurable for different topics and/or queues.

Of the steps listed previously for enabling JMS services in an application, the first step varies somewhat across vendors. Some vendors provide connection factories via object instantiation, as in the previous example. In this case, you must know the class name for the connection factory. Other vendors deliver the connection factory via a JNDI look-up operation, in which case you must know the appropriate look-up symbol, for example, "topicConnectionFactory". These minor details are explained in the vendor's documentation.

The JMS FAQ includes several complete example programs that demonstrate how to set up JMS services in an application, as well as how to employ those services. In addition, most vendors provide demonstration programs as part of their software distribution.