 
Use of JCP site is subject to the
JCP Terms of Use and the
Oracle Privacy Policy
 |
|
 JSRs: Java Specification Requests
JSR 343: JavaTM Message Service 2.0
The following updates have been made to the original proposal:
2013.03.05: 2.18 Please provide a description of the business terms for the Specification, RI and TCK that will apply when this JSR is final.
JSR 343 moved to JCP 2.9.
2012.03.09:
2012.02.28: Original Java Specification Request (JSR)
Identification |
Request |
Contributions
Section 1. Identification Submitting Member: Oracle Corporation Name of Contact Person: Nigel Deakin E-Mail Address: nigel.deakin Telephone Number: +44 20 7562 6736 Fax Number: - Specification Lead: Nigel Deakin E-Mail Address: nigel.deakin Telephone Number: +44 20 7562 6736 Fax Number: - Initial Expert Group Membership: Oracle Corporation Supporting this JSR: Adam Bien Section 2: Request
2.1 Please describe the proposed Specification:The Java Message Service (JMS) API is the Java API for accessing enterprise messaging systems from Java programs in both Java EE and Java SE environments. It provides a common way for Java programs to create, send, receive and read an enterprise messaging system's messages. The current version of this API is 1.1, which was developed as JSR 914. The last maintenance release was in April 2002. The JMS 1.1 API may be implemented standalone for use in a Java SE environment. It is also a required service which must be available in a full Java EE 6 environment, in the EJB, web and application client containers. When used in a Java EE environment, certain parts of the JMS specification are overridden by parts of the Java EE, EJB and Servlet specifications which define further how the JMS API should behave. This JSR proposes that a new revision of the JMS specification be developed. Although JMS continues to be a successful standard with many active implementations, there have been many developments in Java SE, in Java EE and in the field of messaging since the previous revision. Because of this, suggestions to revise the specification vary greatly in their complexity and ambition. The lists below give an indication of the range of suggestions that have been received so far. However, because there has been so little activity on the JMS specification in recent years there is no existing Expert Group and there has been limited community discussion as to how the standard should be extended. In consequence, the proposers of this JSR consider that the goals for this new revision should be modest in scope and that any major extensions should be deferred to a subsequent revision. It is expected that the formation of an EG for this revision will facilitate discussions on what should be in the next one. Changes that will be considered by the Expert Group for inclusion in this new revision include, but are not limited to, the following:
2.2 What is the target Java platform? (i.e., desktop, server, personal, embedded, card, etc.)The target platforms are Java EE and Java SE. 2.3 The Executive Committees would like to ensure JSR submitters think about how their proposed technology relates to all of the Java platform editions. Please provide details here for which platform editions are being targeted by this JSR, and how this JSR has considered the relationship with the other platform editions.The Java Message Service (JMS) API is designed for both Java EE and Java SE platform environments. It is expected that JMS 2.0 will be included as a required part of the Java Platform, Enterprise Edition version 7. Aligning the timeline of this JSR with that of Java EE 7 may therefore impact the scope of the JMS 2.0 release. 2.4 Should this JSR be voted on by both Executive Committees?No. It should be voted on by the Java SE / EE Executive Committee only. 2.5 What need of the Java community will be addressed by the proposed specification?Changes to improve ease of development During the eight years since the specification was last updated the way in which Java EE applications are created has changed significantly. For example, the way in which EJBs are defined has been simplified considerably by a change in the programming model used and in the use of annotations to define behaviour and to refer to JNDI resources. In addition, Java EE 6 supports JSR 299 (Contexts and dependency injection) which has further simplified the way in which applications are written and reduced the amount of Java code (especially boilerplate code) that needs to be provided. It is now time to extend similar benefits to the developers of JMS applications. In addition, a number of ambiguities have been discovered where it is unclear how a JMS provider should behave in various cases. As a result, each JMS provider has taken their own view as to what behaviour is appropriate. In addition there are many places in the existing JMS specification which deliberately leave the detailed behaviour up to the vendor to define. This means that user applications written to work with one JMS provider may not work in the same way with another provider. This reduces the portability of applications between JMS providers, which was a key goal of JMS . By clarifying these ambiguities, and "hardening" the specification where appropriate, the proposed specification will make it easier to convert applications from using one JMS provider to another. Clarification of the relationship between the JMS and other Java EE specifications The existing JMS 1.1 specification does not contain any information on how the JMS API should be used by applications running in a Java EE container. For historical reasons it has been left to other specifications, notably the Java EE, EJB and servlet specifications, to do this by implicitly overriding some parts of the JMS specification. For example, the JMS 1.1 specification states that a JMS connection can be used to create multiple sessions. However the EJB 3.1 specification states that a JMS connection can be used to create only one session. Experience has shown that this is confusing for some users, who read the JMS API or specification only to find that some of it does not apply. There are also some aspects (such as the correct behaviour when there is no transactional context) which are not fully specified in the EJB or other specifications. It is therefore proposed to extend the JMS specification to reflect the fact that some of it is overridden by other specifications. The Expert Group will assess the best way to do this. One possibility is simply to cross-reference the other specifications where needed. Another possibility is to aim to make the JMS specification complete in itself by copying JMS-related content from other specifications. The goal should be to make it easier for both the user and JMS vendors to understand how the JMS API should be used in an application server. Definition of a new mandatory API to allow any JMS provider to be integrated with any Java EE application server There is a requirement in the user community for an application running in a Java EE application server to be able to use a JMS provider other than the one provided by the application server itself. There are two main reasons for this.
The existing JMS 1.1 specification includes a section (chapter 8) on "application server facilities" which are intended to provide a standard way for the JMS provider to integrate with an application server. However this chapter is optional, so some JMS providers do not implement it. In addition, application servers are not required to provide direct support for this API. Furthermore, this chapter leaves a few issues unresolved (such as exactly how JMS messages received by a MessageListener are integrated with a distributed transaction). Subsequent to the release of JMS 1.1, the Java EE Connector Architecture has been developed and is now part of Java EE. One of the goals of the connector architecture was to provide a pluggability layer for JMS providers. It did this by defining how a resource adapter could be created which could be plugged into any application server. However, although this allows a JMS implementor to implement a resource adapter which could be used with any JMS provider, they are not required to do so, and so it is still not possible to plug any JMS provider into any application server. The pluggability of JMS providers between application servers could be achieved either by mandating the provision of a resource adapter which supports the Java EE Connector Architecture API, or by the definition of mandatory API to allow the creation of general-purpose JMS resource adapters by other parties. The EG will decide which approach is more appropriate and define any new API required. Additional features requested by the community At least twelve implementations of the current JMS 1.1 specification are in existence and in active use. Some of these are provided as part of a complete Java EE environment and some are standalone. Some are closed-source, some are open-source. Over the years since the JMS specification was last updated, vendors have found the need to add additional features which go beyond the scope of the JMS specification. Although many such features will probably always be beyond the scope of standardising in an updated JMS specification, there are some which are not. In some cases, different vendors have implemented similar features which despite being non-standard are in fact quite similar (typically because they were added to satisfy the same business need) and so would benefit from being standardised. 2.6 Why isn't this need met by existing specifications?See 2.5 above. 2.7 Please give a short description of the underlying technology or technologies:See above. 2.8 Is there a proposed package name for the API Specification? (i.e., javapi.something, org.something, etc.)The API Specification will continue to use the javax.jms package. 2.9 Does the proposed specification have any dependencies on specific operating systems, CPUs, or I/O devices that you know of?No 2.10 Are there any security issues that cannot be addressed by the current security model?No 2.11 Are there any internationalization or localization issues?No 2.12 Are there any existing specifications that might be rendered obsolete, deprecated, or in need of revision as a result of this work?Section 2.5 above explained how this revision of the JMS specification would address the problem whereby some sections of the JMS specification were overridden by other specifications. The Expert Group may decide that some of the rules of other specifications which define the behaviour of JMS API should be moved into the JMS specification, which would necessitate changes to the other specification. 2.13 Please describe the anticipated schedule for the development of this specification.Expert Group Formation: March 2011
Note that this schedule has been updated on 2012.03.09: We intend to include Java Message Service 2.0 as part of Java EE 7. The above dates may need to be adjusted as the schedule for Java EE 7 is more fully defined. 2.14 Please describe the anticipated working model for the Expert Group working on developing this specification.The primary means of communication will be email and conference calls. Face-to-face meetings will be scheduled if needed. 2.15 Provide detailed answers to the transparency checklist, making sure to include URLs as appropriate:The public can read the names of the people on the Expert Group. Yes. This information will be available in all spec drafts and on the Update page of the JSR. The Expert Group business is regularly reported on a publicly readable alias. We intend this to be the case. In addition, blogs will be used to keep the community updated on the progress of the JSR. The schedule for the JSR is publicly available, it's current, and I update it regularly. This will be available on the JSR Update page. The public can read/write to a wiki for my JSR. See the answers to other questions. It is likely that other means will be used to achieve similar functionality. I read and respond to posts on the discussion board for my JSR on jcp.org. There will be a public discussion board and/or mailing list where members of the community can ask questions and send information to the Expert Group, and which I and the Expert Group will read and respond to. There is an issue-tracker for my JSR that the public can read. There will be. I have spoken at conferences and events about my JSR recently. Colleagues from Oracle proposed a revision of the JMS API at the JavaOne conference in Septemner 2010 in a BOF session "JMS - Time for version 2.0?" I am using open-source processes for the development of the RI and/or TCK. The RI for JMS 1.1 is Open Message Queue. It is part of GlassFish Server, Open Source Edition. Both are open source. It is expected that the RI for JMS 2.0 will continue in the same vein. The TCK for JMS is not open source. The Update tab for my JSR has links to and information about all public communication mechanisms and sites for the development of my JSR. This will be the case. 2.16 Please describe how the RI and TCK will de delivered, i.e. as part of a profile or platform edition, or stand-alone, or both. Include version information for the profile or platform in your answer.Oracle Corporation will deliver a Reference Implementation (RI) and Technology Compatibility Kit (TCK) available both stand-alone and as part of Java EE 7. 2.17 Please state the rationale if previous versions are available stand-alone and you are now proposing in 2.13 to only deliver RI and TCK as part of a profile or platform edition (See sections 1.1.5 and 1.1.6 of the JCP 2 document).N/A 2.18 Please provide a description of the business terms for the Specification, RI and TCK that will apply when this JSR is final.Note that this information has been updated since this original proposal. Specification license Section 3: Contributions
3.1 Please list any existing documents, specifications, or implementations that describe the technology. Please include links to the documents if they are publicly available.JSR 914: Java Message Service (JMS) API http://jcp.org/en/jsr/detail?id=914 Java Message Service 1.1 specification: http://java.sun.com/products/jms/docs.html Open Message Queue: http://mq.java.net/ GlasssFish Server, Open Source Edition: https://glassfish.dev.java.net/ JSR 322: Java EE Connector Architecture 1.6: http://jcp.org/en/jsr/summary?id=322 3.2 Explanation of how these items might be used as a starting point for the work.The Java Message Service1.1 API, and its Reference Implementation, Open Message Queue, will be the starting point for this work. |
