Java Message Service, 2nd Edition

Chapter 11. Messaging Design Considerations

Until now we have been focusing on the concepts and semantics of JMS messaging. This chapter expands on those concepts and introduces some of the design considerations that need to be addressed when building messaging systems.

Internal Versus External Destination

The Java Message Service API consists of a set of standard interfaces that must be implemented by open source or commercial vendor products called JMS providers. There are many different types of open source and commercial JMS providers ranging from J2EE application servers (e.g., JBoss, WebLogic, IBM WebSphere, Oracle AS) to standalone solutions (e.g., ActiveMQ, SonicMQ, IBM WebSphere MQ).

Because most Java EE application servers can also serve as JMS providers, a common design choice is deciding whether to leverage your current application server environment or use an external JMS provider. After all, why complicate your architecture and incur additional middleware licensing fees if you can simply utilize your existing application server? While this seems like a straightforward question, there are several implications and limitations to using an application server as a JMS provider. As you will see in this section, using an existing Java EE application server environment versus an external standalone JMS provider is an important design decision that carries with it many implications with respect to an overall messaging solution.

There are two primary deployment topologies with respect ...