 
Use of JCP site is subject to the
JCP Terms of Use and the
Oracle Privacy Policy
 |
|
 JSRs: Java Specification Requests
JSR 368: JavaTM Message Service 2.1
Reason: Withdrawn at the request of the Spec Lead. JCP version in use: 2.10 Java Specification Participation Agreement version in use: 2.0 Description: The JMS API is an API for accessing enterprise messaging systems from Java programs. This JSR is to develop JMS 2.1, the next version of the API. Expert Group Transparency: Public Project Page Public Communications Issue Tracking Team
This JSR has been Withdrawn
2015.07.14:
Original Java Specification Request (JSR)
Identification |
Request |
Contributions
Section 1. Identification Submitting Member: Oracle Name of Contact Person: Nigel Deakin E-Mail Address: nigel.deakin Telephone Number: +44 20 7562 6736 Fax Number: - Specification Lead: Nigel Deakin, Oracle E-Mail Address: nigel.deakin Telephone Number: +44 20 7562 6736 Fax Number: - Initial Expert Group Membership: Oracle Supporting this JSR: Red Hat Section 2: Request
2.1 Please describe the proposed Specification:The Java Message Service (JMS) API is a 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 2.0, which was developed as JSR 343 and which achieved final release in 2013. The JMS 2.0 API may be implemented standalone for use in a Java SE environment. It is also a required service that must be available in a full Java EE 7 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, JMS 2.1. The proposed content of JMS 2.1 is as follows:
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 intended that JMS 2.1 will be included as a required part of the Java Platform, Enterprise Edition version 8. Aligning the timeline of this JSR with that of Java EE 8 may therefore impact the scope of the JMS 2.1 release. 2.4 What need of the Java community will be addressed by the proposed specification?See 2.1 above. 2.5 Why isn't this need met by existing specifications?See 2.1 above. 2.6 Please give a short description of the underlying technology or technologies:See 2.1 above. 2.7 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.8 Does the proposed specification have any dependencies on specific operating systems, CPUs, or I/O devices that you know of?No. 2.9 Are there any security issues that cannot be addressed by the current security model?No. 2.10 Are there any internationalization or localization issues?No. 2.11 Are there any existing specifications that might be rendered obsolete, deprecated, or in need of revision as a result of this work?This JSR is proposing to define new API for receiving messages asynchronously. The EJB specification currently defines a way to do this using message-driven beans (MDBs). The use of MDBs to receive JMS messages may become partially or wholly obsolete as a result of this work. The use of MDBs to receive non-JMS messages is outside the scope of the JMS specification and will neither change nor become obsolete. It is not expected that major changes will be needed to the EJB specification, but small changes are likely since the two specifications are so closely-related. It is intended that it will be possible for application servers to implement the proposed new API for receiving messages asynchronously by using a JCA resource adapter. However it is possible that changes may be required to the Java Connector Architecture (JCA) specification to support this. 2.12 Please describe the anticipated schedule for the development of this specification.Q3 2014 Expert Group formed 2.13 Please describe the anticipated working model for the Expert Group working on developing this specification.The primary means of communication will be email, with conference calls and face-to-face meetings scheduled as needed. 2.14 Provide detailed answers to the transparency checklist, making sure to include URLs as appropriate:The jms-spec.java.net project site will be used to track all issues and disseminate information on the progress of the JSR. Q. Is the schedule for the JSR publicly available, current, and updated regularly? A. The schedule will be available on the project site jms-spec.java.net. Q. Can the public read and/or write to a wiki for the JSR? A. The project site jms-spec.java.net includes a wiki which may be read by anyone. Only expert group members will be able to update the wiki. Q. Is there a publicly accessible discussion board for the JSR that you read and respond to regularly? A. The existing email alias users@jms-spec.java.net will be used for this purpose. Anyone may subscribe to and post to this alias, and an online archive of past messages will be available on the project website. Q. Have you spoken at conferences and events about the JSR recently? In the past year I gave two presentations at JavaOne 2013 in San Francisco. One was a summary of the new features of JMS 2.0, and the other was a consultation session to discuss what might be in JMS 2.1. I have submitted proposals for two similar talks at JavaOne 2014. Q. Are you using open-source processes for the development of the RI and/or the TCK? A. The RI for JMS 2.0 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.1 will continue in the same vein. The TCK for JMS is not open source. Q. What are the Terms of Use required to use the collaboration tools you have prepared to use with the Expert Group, so that prospective EG members can judge whether they are compatible with the JSPA? A. The collaboration tools use java.net terms of service. These are available at https://home.java.net/javanet-web-site-terms-use Q. What is the location of your publicly-accessible Issue list? In order to enable EC members to judge whether Issues have been adequately addressed, the list must make a clear distinction between Issues that are still open, Issues that have been deferred, and those that are closed, and must indicate the reason for any change of state. A. The issue list is available to anyone at https://java.net/jira/browse/JMS_SPEC. This uses JIRA. Each issue has a status field which reflects its status. Issues that have been incorporated into a release of the specification are closed, and the "fix version" shows which release of the spec incorporates the change. Issues which are rejected as invalid, incomplete or inappropriate and which will not be reconsidered are marked as closed, with an appropriate comment to explain why the issue was closed. All new issues, and any older issues which have been deferred for future consideration, are left open and are listed on the JMS 2.1 planning page https://java.net/projects/jms-spec/pages/JMS21Planning. Each issue on that page is given a JIRA tag to classify whether the issue is major or minor, whether it was deferred, and so on. That page lists the possible tags that are used. Q. What is the mechanism for the public to provide feedback on your JSR? A. The jms-spec project front page jms-spec.java.net explains the various ways in which feedback may be provided. This invites members of the community to log an issue in the issue tracker or send an email to the community email alias. Once work on the JSR begins this will be updated and given greater prominence on the site. Q. Where is the publicly-accessible document archive for your Expert Group? A. The document archive is at https://java.net/projects/jms-spec/downloads The API interfaces and specification itself (including work-in-progress drafts) are stored in a publicly-available svn repository. Access details are at https://java.net/projects/jms-spec/sources and the contents of the repository may be browsed at https://java.net/projects/jms-spec/sources/repository/show Q. Does the Community tab for my JSR have links to and information about all public communication mechanisms and sites for the development of my JSR? A. The community tab for JSR 343 (https://jcp.org/en/egc/view?id=343) directs readers to the project website jms-spec.java.net. When this new JSR is approved, its community tab will be similarly updated. Q. Do you have a Twitter account or other social networking feed which people can follow for updates on your JSR? A. No, though I will consider creating a Twitter account specifically for this JSR for JMS 2.1. Q. Which specific areas of feedback should interested community members (such as the Adopt-a-JSR program) provide to improve the JSR A. The formation of Adopt-a-JSR groups for JMS 2.1 will be encouraged and supported. The London Java Community expressed interest in participating in the Adopt-a-JSR programme for JSR 343 though little support was provided by the expert group. It is intended that the formation of this and other Adopt-a-JSR programmes for the new JSR will be encouraged and supported rather more. 2.15 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 8. 2.16 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).No change is proposed from what was delivered for previous versions of JMS. 2.17 Please provide a description of the business terms for the Specification, RI and TCK that will apply when this JSR is final.
RI license
TCK license
2.18 Please describe the communications channel you have established for the public to observe Expert Group deliberations, provide feedback, and view archives of all Expert Group communications.The Expert Group will conduct business using a publicly readable email alias for the JSR, similar to the email alias which was used for JSR 343. All messages sent to this alias by expert group members will be forwarded to the JMS specification community email alias. An online archive of messages will be available. The existing JMS specification community alias users@jms-spec.java.net, will continue to be used to allow members of the community to receive copies of all emails sent to the expert group alias, as well as to provide feedback and allow discussion on any issue related to the JMS specification. An online archive of messages will be available. There will also be a publicly accessible issue tracker, source repository (used for draft API classes and the draft specification itself) and a document archive (used for discussion documents). See also 2.19 and 2.20 below. 2.19 What is the URL of the Issue Tracker that the public can read, and how does the public log issues in the Issue Tracker?https://java.net/jira/browse/JMS_SPEC Instructions on how members of the community may log issues are given at https://java.net/projects/jms-spec/pages/Home#How_to_create_an_issue 2.20 Please provide the location of the publicly accessible document archive you have created for the Expert Group.The document archive is at https://java.net/projects/jms-spec/downloads In addition, draft API classes and the draft specification itself will be available in a svn repository. Access details at https://java.net/projects/jms-spec/sources 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.The JSR that developed JMS 2.0 was JSR 343. The formal JSR page is http://jcp.org/en/jsr/detail?id=343 The final specification for JMS 2.0 is available at https://jcp.org/aboutJava/communityprocess/final/jsr343/index.html The API docs for JMS 2.0 is available at https://jms-spec.java.net/2.0/apidocs/index.html The standalone JMS RI is Open Message Queue: http://mq.java.net/ The Java EE 7 RI, which include Open Message Queue and some additional JMS components to provide support for JMS 2.0 in a Java EE environment, is GlassFish Server Open Source Edition. This is available at https://glassfish.dev.java.net/ 3.2 Explanation of how these items might be used as a starting point for the work.This new JSR will develop the specification for JMS 2.1 as as a revision of the existing JMS 2.0 specification and API. The standalone RI for JMS 2.1 will be developed as a revision of the existing RI for JMS 2.0, Open Message Queue. The Java EE 8 RI will similarly be developed as a revision of the existing Java EE 7 RI, GlassFish Server, Open Source Edition. This will include Open Message Queue as well as some updated components to provide support for JMS 2.1 in a Java EE environment. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
