Skip to main content

[jsr343-experts] (JMS_SPEC-86) Chapter 1 "Introduction" is a little dated and requires rewriting

  • From: Nigel Deakin <nigel.deakin@...>
  • To: jsr343-experts@...
  • Subject: [jsr343-experts] (JMS_SPEC-86) Chapter 1 "Introduction" is a little dated and requires rewriting
  • Date: Mon, 25 Feb 2013 18:17:22 +0000
  • Organization: Oracle Corporation

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
"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:

* 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)


Attachment: JMS20-Chapter1-changes.pdf
Description: Adobe PDF document

[jsr343-experts] (JMS_SPEC-86) Chapter 1 "Introduction" is a little dated and requires rewriting

Nigel Deakin 02/25/2013

[jsr343-experts] Re: (JMS_SPEC-86) Chapter 1 "Introduction" is a little dated and requires rewriting

John D. Ament 02/25/2013

[jsr343-experts] Re: (JMS_SPEC-86) Chapter 1 "Introduction" is a little dated and requires rewriting

Nigel Deakin 02/25/2013
Please Confirm