Next Generation Application Integration: From Simple Information to Web Services

Although some traditional message-oriented middleware products like IBM's MQSeries support Java, the real story is a new standard from JavaSoft called Java Message Service. JMS is attracting a critical mass of messaging vendors that seek to bind their products tightly with Java.

JMS adds a common API and provider framework to Java, which enables the Java developer to dispatch and receive messages with other Java-enabled applications or applets that exist anywhere on the network (see Figure 8.1). JMS defines a common set of messaging concepts and programming strategies. It provides a good mix of the messaging features common to most messaging products important, yes, but hardly revolutionary. The difficulty is to support these concepts and strategies from JMS-compliant vendor to JMS-compliant vendor. If this obstacle is successfully overcome, the resulting products not only will share common characteristics, but will have the ability to share messages, as well something more traditional message-oriented middleware products have yet to perfect.

JMS consists of three major entities: the JMS provider, JMS messages, and JMS domains. The provider implements JMS for a particular product (for example, a Java applet, servlet, bean, or application that supports JMS). JMS messages are sets of messaging interfaces that define a common mechanism and format for moving information between providers.

JMS messages consist of several parts, including the header, properties, and body (see Figure 8.2). The header supports the same set of header fields as traditional messaging products. Both the JMS client and provider use the header to identify and route messages. JMS message properties allow developers to add information to the standard header, such as application-specific properties, standard properties, and provider-specific properties. The body contains the data that is being transported.