All the JSRs I know of have started with the previous version of the spec and made changes.
Nigel
On 25/02/2013 18:19, John D. Ament wrote:
> 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 <mailto: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
> "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
>
>