Featured White Papers

• Measuring Risk to Improve Java Software Quality
• Do You Really Get Classloaders?
• Pragmatic Continuous Delivery with Jenkins, Nexus, and LiveRebel
• Your Next Java Web App: Less XML, No Long Restarts, Fewer Hassles
• Coding with JRebel, Java Forever Changed
• 2012 Developer Productivity Report: Java Tools, Tech, Devs, and Data

Sponsored Links

• Graph databases are 1000x faster than relational.

  Learn More!

• Career opportunities at Harman- Careers That'll Rock Your Socks Off.

  Learn More!

• Developer-friendly Java PDF libraries by Qoppa Software

  Live Demos

• Stop blaming your app! Diagnose Java performance issues.

  Free tool >

• UrbanCode: Go From Continuous Integration to
  Continuous Delivery

  Learn More!

Sponsored Links

Optimize with a SATA RAID Storage Solution
Range of capacities as low as $1250 per TB. Ideal if you currently rely on servers/disks/JBODs

Messaging helps move Java into the enterprise

Find out how the Java Message Service API helps developers create more robust enterprise applications

By Todd Sundsted, JavaWorld.com, 01/01/99

In its effort to stay on top of important industry trends, Sun announced last April (at the 1998 JavaOne Developer Conference) its plans to publish the Java Message Service (JMS) API, an interface for using existing enterprise messaging systems in a uniform manner. The version 1.0 specification, which was released in July, provides a set of interfaces and associated semantics that define how a JMS client accesses the facilities of an enterprise messaging product.

Since its release, almost twenty vendors have stepped up to endorse the specification (including companies like IBM, Oracle, and BEA) and four companies have produced implementations: Etsee Soft, Fiorano Software, Modulus Technologies, and Push Technologies.

Messaging services

Rather than communicate directly with each other, the components in an application based around a message service send messages to a message server. The message server, in turn, delivers the messages to the specified recipients. This might seem like an extra, unnecessary layer of software, but the advantages a message service provide often outweigh this single disadvantage. The message service model is much like the model behind the postal service. We could directly deliver our own mail, but letting someone else do it greatly simplifies our life.

The common building block of a messaging service is the message. Messages are events, requests, and replies that are created by and delivered to enterprise applications. Messages contain formatted data with specific business meanings.

Beyond the message, however, messaging services display a surprising degree of diversity. For example, a messaging service may:

• Allow messages to be prioritized
  
  
• Deliver messages either synchronously or asynchronously
  
  
• Guarantee messages are delivered once and only once
  
  
• Support message delivery notification
  
  
• Support message time-to-live
  
  
• Support transactions

In addition, every messaging service packages these capabilities slightly differently.

How does the JMS API fit in?

A key goal of the JMS API is to unify the packaging of these capabilities and to minimize the set of concepts a Java programmer must learn in order to use messaging products. As its secondary goal, it strives to maximize the portability of messaging applications.

Specific goals of the JMS API specification are to:

• Provide a single, unified message API
  
  
• Provide an API suitable for the creation of messages that match the format used by existing, non-JMS applications
  
  
• Support the development of heterogeneous applications that span operating systems, platforms, architectures, and computer languages
  
  
• Support messages that contain serialized Java objects
  
  
• Support messages that contain XML pages

The JMS API is divided into two nearly identical pieces. One implements the point-to-point model of messaging, and the other implements the publish/subscribe model of messaging. Each of these models is called a domain. The APIs are almost identical between domains. This greatly improves the feeling of cohesiveness throughout the API.