After the JMS 2.0 early draft was published last year one of the comments I received was that chapter 1 "Introduction"
was looking distinctly dated. I therefore logged this issue to cover updating this chapter and would now like to address
it before the final JMS 2.0 release.
This is
http://java.net/jira/browse/JMS_SPEC-86
"Chapter 1 "Introduction" is a little dated and requires rewriting"
This chapter was written a long time ago and hasn't changed much since the JMS 1.0.1 spec back in 1998. It reflects the
origins of JMS as a standard Java API on top of existing non-Java messaging systems. Although this remains an important
use of JMS it need rewording to reflect the existence of numerous pure-Java messaging systems written expressly to
implement JMS.
It states that enterprise messaging systems "are becoming an essential component for integrating intra-company
operations". I think that in 2013 we can confidently omit the word "becoming"!
It also uses some quaint terminology, such as the statement in section 1.2 that in addition to "the traditional MON
vendors", enterprise messaging products are provided by "a number of internet companies". I'm not sure what was meant
by "internet companies" but I'm sure it meant something quite different back in 1998 than it does in 2013.
As part of a final tidy-up before we submit the JMS 2.0 specification I have updated this chapter, mainly to delete
material which I think is no longer needed.
I have also clarified and given more prominence to a statement describing the relationship between JMS and Java EE, to
make it clear that JMS exists both as a specification in its own right independent of Java EE, whilst also providing a
major component of the Java EE specification.
You can see the new text in three ways:
* The updated text is given below
* You can read the text in the draft spec itself, which is properly formatted and also has change bars:
http://java.net/projects/jms-spec/sources/repository/content/jms2.0/specification/word/JMS20.pdf
* I attach a version with full Microsoft Word "show changes" switched on, so you can see exactly what I have added and
what I have deleted.
I see this as an editorial tidy-up which doesn't actually change anything other than to make the spec more readable.
However if you think this update raises any issues of concern then please say so. And comments on my wording and editing
would of course be welcome.
Chapter 1 Introduction
======================
This specification describes the objectives and functionality of the JavaTM Message Service (JMS).
JMS provides a common way for Java programs to create, send, receive and read an enterprise messaging system’s messages.
1.1 Overview of JMS
-------------------
Enterprise messaging products (or as they are sometimes called, message-oriented middleware products) are an essential
component for integrating intra-company operations. They allow separate business components to be combined into a
reliable, yet flexible, system.
JMS was initially developed to provide a standard Java API for the established messaging products that already existed.
Since then many more messaging products have been developed.
JMS provides a common way for both Java client applications and Java middle-tier services to use these messaging
products. It defines some messaging semantics and a corresponding set of Java interfaces.
Since messaging is a peer-to-peer technology, users of JMS are referred to generically as clients. A JMS application is
made up of a set of application defined messages and a set of clients that exchange them.
Messaging products that implement JMS do so by supplying a provider that implements the JMS interfaces. Messaging
products may support clients which use programming languages other than Java. Although such support is beyond the scope
of JMS, the design of JMS has always accommodated the need for messaging products to support languages other than Java
1.1.1 What is messaging?
------------------------
The term messaging is quite broadly defined in computing. It is used for describing various operating system concepts;
it is used to describe email and fax systems; and here, it is used to describe asynchronous communication between
enterprise applications.
Messages, as described here, are asynchronous requests, reports or events that are consumed by enterprise applications,
not humans. They contain vital information needed to coordinate these systems. They contain precisely formatted data
that describe specific business actions. Through the exchange of these messages each application tracks the progress of
the enterprise.
1.1.2. The objectives of JMS
----------------------------
The objectives of JMS are
* to provide Java applications with the messaging functionality needed to implement sophisticated enterprise applications
* to define a common set of messaging concepts and facilities
to minimize the concepts a Java language programmer must learn to use enterprise messaging products
* to maximize the portability of Java messaging applications between different messaging products
1.1.3 JMS domains
-----------------
JMS supports the two major styles of messaging provided by enterprise messaging products:
* Point-to-point (PTP) messaging allows a client to send a message to another client via an intermediate abstraction
called a queue. The client that sends the message sends it to a specific queue. The client that receives the message
extracts it from that queue.
* Publish and subscribe (Pub/Sub) messaging allows a client to send messages to multiple clients via an intermediate
abstraction called a topic. The client that sends the message publishes it to a specific topic. The message will then be
delivered to all the clients that are subscribed to that topic.
1.1.4. What JMS does not include
--------------------------------
(I have not changed this section)
1.1.5. Java SE and Java EE support
----------------------------------
The JMS API is designed to be suitable for use by both Java client applications using the Java™ Platform, Standard
Edition (Java SE), and Java middle-tier services using the Java™ Platform, Enterprise Edition (Java EE).
All JMS providers must support its use by Java client applications using Java SE. It is optional whether a given JMS
provider supports its use by middle-tier applications using Java EE.
The Java EE Specification requires a full Java EE platform implementation to include a messaging provider which supports
the JMS API in both Java SE and Java EE applications.
Java EE makes a number of additional features available to messaging applications in addition to those defined in the
JMS specification itself, most notably message-driven beans (MDBs) and JTA transactions. Java EE also imposes a number
of restrictions on the use of the JMS API.
For more information on the use of JMS by Java EE applications, see chapter 12 "Use of JMS API in Java EE applications".
1.2. What is new in JMS 2.0?
----------------------------
(This section has not been changed)
Nigel