|
|
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
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.
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:
In addition, every messaging service packages these capabilities slightly differently.
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:
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.