Having established an understanding of our unit of exchange - the message - we are now ready to delve into the mechanics of messaging using the JMS API. In this chapter we begin with a discussion on implementation choices, examining our options regarding the software components with which we might implement a JMS client. We then undertake a detailed review of the JMS API, using code snippets to illustrate usage and implementation approaches. We do this by examining in turn each set of interfaces: point-to-point, publish-subscribe, and the unified or common interface. This will round out our knowledge of JMS and prepare us to consider a number of real-world scenarios based on a specific product family: IBM WebSphere.
The JMS client is the entity that utilizes the JMS API to interact with the JMS provider. It can be any Java artifact, and depending on the application environment, a number of choices exist as to how the JMS client is implemented. The JMS client could be a standalone Java application, serving as part of a desktop client, or acting as the connectivity module (adapter) for a business application. The JMS client could also be encapsulated in a J2EE component such as an applet, servlet or portlet, or Enterprise JavaBean (EJB). That the JMS client can be any Java artifact offers a great deal of flexibility in implementation. However, this comes at a price, as the deci-sion-making process regarding your implementation choice becomes more involved.
The choice between a standalone Java application or J2EE component is one we need not address, as that decision is driven more by the nature of the application and its target runtime environment than by the JMS connectivity requirement. However, if the application is J2EE-based, then we still have the basic choices of applet, servlet, or EJB.
Servlets and EJBs are server-side components that run in containers in the J2EE server. They consequently have access to a host of services, such as security and transaction support (see Chapter 2, "Java Message Service"). Applets, on the other hand, are client-side (presentation layer) components that run in a browser and are most often used as user interface constructs. Current best practice recommends that J2EE applications adopt a lightweight presentation layer with business logic and connectivity to enterprise resources (such as messaging providers) residing in server-side components. This enables transaction and security services to be readily invoked if required and offers an important advantage in that it is much easier to scale and modify serverside components. Furthermore, it greatly simplifies the implementation of the presentation layer.
With this in mind, it is fair to say that applets are probably least suited to the role of JMS client. Besides the design considerations, there are practical implications to be considered as well. The applet needs access to the JMS libraries (standard and provider implementation), increasing its size and potentially impacting the time it takes it to download to the browser. In addition, the still existing inconsistencies in browser Java Virtual Machines (JVMs) and their support for running JMS must be addressed. Such inconsistencies can complicate the deploy-ment of the solution and force you to have to specify browser versions or runtime plug-ins that will support your application. In solutions where applets are used (their current popularity is questionable), a better pattern is for the applet to call a servlet. The servlet then either calls an EJB, which implements the JMS client, or it implements the JMS client itself.
