Nigel,
Comparing our spec to other specs, do the other specs typically use the
prior version and modify it or are they writing documents from scratch on
every release?
John
On Mon, Feb 25, 2013 at 1:17 PM, Nigel Deakin <nigel.deakin_at_oracle.com>wrote:
> 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<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<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
>
>