Introduction to Messaging
| Messaging applications, or as they are sometimes called, Message Oriented Middleware (MOM) products, have been used for quite some time. These messaging products help applications that normally are not connected to one another structurally communicate with each other. In applications that aren't using a messaging product, this communication might be performed using sockets, RMI, or in various other ways. A few problems are associated with communicating between applications using one of these approaches. One of the problems is that each side involved in the communication might have direct knowledge about one another. Each side is aware of the other with respect to the transport protocol and other low-level details. This knowledge is known as a tight coupling . It would be more flexible if the two sides weren't so tightly coupled . This way, if something changed on either side, the other side might not be affected. Another problem is that it's hard to perform asynchronous messaging with sockets or RMI. Asynchronous communication is where a response is not immediately expected or returned. The alternative approaches just mentioned, such as sockets or RMI, are types of synchronous communication. Message-oriented middleware can help reduce the coupling and complexity of allowing applications or components to communicate with one another asynchronously. It's also designed to help interoperability between applications, which is very important when building enterprise applications. What Is Message-Oriented Middleware?Message-oriented middleware was designed to decouple the applications or components and allow them to communicate with one another by exchanging messages asynchronously. These messages can be things such as event notifications, application data, request for services, or even objects. Any type of information that needs to be communicated from one application to another is done by passing a message to the receiving system. As you'll see later in this chapter, various types of messages can be passed from one application to another. Although messages generally can be sent in either direction, certain names are given to the application or component that is sending or receiving a message. The component that creates or produces a message is referred to as a producer . The application or component that receives a message is called a consumer . It's possible for an application to be both a producer and a consumer of messages, but for a given transfer of information, one side must produce the message and another side must consume it. A benefit of separating the producing and the consuming of messages is that the producer and consumer only really need to agree on the format of the message. Each side doesn't need to worry about how the message is transported. To make this possible, a message is not sent directly from a producer to the consumer. As we'll see later in this chapter, how it makes its way to the consumer depends on which type of messaging model you choose for your application. Figure 10.1 illustrates a generic messaging scenario. Figure 10.1. An application communicating through messaging contains a producer and a consumer. Java Message Service as a Message-Oriented MiddlewareAlthough the EJB 2.0 Specification does not cover messaging, it is part of the Java Message Service (JMS) specification and is so fundamental to the Enterprise JavaBeans API that it would be deficient not to cover it in any serious discussion on the subject. Because many enterprise applications will use some level of messaging, it's a good idea to understand the concepts. You also will need to be familiar with the Java Message Service (JMS) APIs before understanding the new message-driven bean that has been added to the EJB 2.0 Specification. Differences Among JMS ImplementationsAnother important fact should be pointed out. JMS is not an implementation of a message-oriented middleware. In fact, it's really nothing more than a specification for describing how messages should be produced and consumed in a Java enterprise application. By itself, it provides no functionality. As with other APIs that we have already discussed, the API or interfaces are separate from the implementation. This gives the benefit of describing in detail what the user view should be, while at the same time allowing vendors to implement the details however they want. As long as the vendor adheres to the JMS specification, a user shouldn't have to worry too much about how the implementation is constructed . The point of hiding the implementation from the client and exposing only the JMS APIs is to hide the details from the users that want a higher-level API and also to ensure portability among implementations. If a vendor implements the JMS specification and adheres to it completely, there is typically no problem developing portable JMS applications and switching between vendors. As with the rest of the specifications in the Java 2 Enterprise Edition (J2EE), JMS has a version number that identifies that current release of the specification. The current JMS specification is 1.0.2. If you write an application based on this or any newer specification, you must ensure that the vendor whose JMS implementation you are using adheres to this level of the specification. You can download the latest JMS specification at the following URL: http://java.sun.com/products/jms Many vendors provide an implementation for the JMS specification. Some are included along with a complete or partial implementation of the entire J2EE suite of technologies. Table 10.1 is a list of vendors who provide a commercial implementation of the JMS specification. Table 10.1. Vendors Who Provide a Commercial JMS Implementation
There are also several open -source JMS projects. Table 10.2 lists a few of them. Table 10.2. Partial List of Open-Source JMS Projects
Many other vendors endorse the JMS API. The following URL provides a more exhaustive listing: http://java.sun.com/products/jms/vendors.html |
EAN: 2147483647
Pages: 223