Best Practices for Enterprise Messaging

Enterprise messaging is often a core part of an enterprise's infrastructure for connecting disparate systems together via a common messaging medium. Enterprise messaging can also involve overhead not only in terms of performance but also in establishing the infrastructure to support messaging. As such, it is thus important that enterprise messaging be done not only when appropriate but also implemented appropriately.

In terms of when it is appropriate to employ enterprise messaging, the asynchronous nature of messaging means that the applications sitting on each end of the producer-consumer spectrum need to be able to wait for messages to be delivered. Hence, applications connected via a messaging service often perform coarser-grained operations embodied by coarse-grained messages. You wouldn't want to be sending a user's last name in one message, and then a first name in another message, and then a username message, a password message, and so forth. You'd want to create messages that hold enough data to warrant the overhead involved with sending and receiving the message as well as the waiting that can be involved with its asynchronous delivery.

While a case can be made for using messaging to encapsulate more than just a minimal amount of data, there also might be a limit on the upper bound of a message size that you want to employ in your designs. This is most appropriately accomplished by thinking about the logical cohesiveness of the data inside of a message. If certain chunks of data are not logically related and can be processed separately without affecting the correctness of an application, such data may be encapsulated inside of separate messages. For example, if there exists an application to process a large amount of credit-related data for customers and that data is reasonably minimal, you might consider batching up chunks of that data into one message as it becomes available. However, if each individual amount of credit information is fairly large per customer, you might consider encapsulating the credit data in one message per customer.

The asynchronous nature of messaging also behooves you to warrant its use when the applications at each end of the producer-consumer spectrum are fairly disparate and logically operate independently as systems unto themselves. This is why messaging is used most often to integrate legacy and auxiliary applications.

Even though it is possible to do messaging over a wider area network, such as the Internet, messaging is most often used inside of a local area network or Intranet. The primary reason for this fact is that messaging often involves loosely coupled applications for which the enterprise's staff has control over the message interface definition among the applications. Over wider area networks, service-oriented architectures and Web Services are becoming the norm as opposed to traditional enterprise messaging. Additionally, many organizations also shy away from enterprise messaging over the Internet due to the fact that it requires potentially less secure and difficult to manage firewall configuration settings.

In terms of how to most appropriately implement messaging, the very fact that you will be using JMS gives you one huge advantage. The standard interface embodied by JMS enables you to learn how to implement messaging paradigms by learning one interface as opposed to understanding the many interfaces offered by various proprietary messaging providers. Use of BEA WebLogic also provides you with a simplified means to configure and deploy messaging applications either using WebLogic's built-in messaging provider or by connecting to an external messaging service.

Keeping in mind the aforementioned information about when it is appropriate to use messaging, you can map that to how you will implement your messaging solution using JMS and WebLogic. That is, the size of your JMS messages, coarse-grained nature of your JMS design, and use of JMS on local networks are all key implementation considerations.

Finally, following the examples in this book, you've seen how many JMS operations can be applied throughout your JMS applications in a reusable fashion. Many common JMS operations, such as establishing connection factories, creating connections, and creating destinations, can all be performed inside of reusable and generic code components that read in configuration data to adapt their behavior as needed. The new JMS v1.1 APIs take generic code components one step further by enabling you to create code completely independent of whether a topic- or queue-based messaging paradigm is employed. In such a way, you can create very robust and generic messaging applications using standard JMS APIs and quickly roll out new messaging applications via minimal effort in modifying configuration parameters.