 
Use of JCP site is subject to the
JCP Terms of Use and the
Oracle Privacy Policy
 |
|
 JSRs: Java Specification Requests
JSR 356: JavaTM API for WebSocket
JCP version in use: 2.8 Java Specification Participation Agreement version in use: 2.0 Description: The Java API for WebSocket JSR will define a standard API for creating WebSocket applications. Expert Group Transparency: Public Communications Issue Tracking Team
The following information has been updated from the original proposal on the dates shown.
2014.06.23:
Pavel Bucek
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.
Identification |
Request |
Contributions
Section 1. Identification Submitting Member: Oracle Name of Contact Person: Danny Coward E-Mail Address: danny.coward Telephone Number: +1 415 350 1701 Fax Number: +1 408 276 4185 Specification Lead: Danny Coward E-Mail Address: danny.coward Telephone Number: +1 415 350 1701 Fax Number: +1 408 276 4185 Initial Expert Group Membership: - Supporting this JSR:
SAP Section 2: Request
2.1 Please describe the proposed Specification:This JSR will define a standard API for creating WebSocket
applications. There is a wide range of web applications that rely on timely
updates from a central server like stock tickers, live maps, chat
applications, collaborative online tools and multiplayer web-based
games. WebSocket offers solution to the problems of latency,
scalability and performance associated with HTTP based solutions
like polling, long-polling and HTTP-streaming. There is a lot of
interest in the Java developer community in creating web
applications for the Java platform that utilize WebSocket. Given
that the definition of WebSocket protocol is a proposed standard,
and that the major web browsers either support, or plan to support
it in their next major release, the time is right for a standard
Java API for WebSocket. This JSR will provide support in the Java EE platform for:-
The primary scenario is for that applications created using this technology be server based. That is to say, this technology will be for Java EE developers creating WebSocket applications in bi-directional commutation with browser clients. This is exemplified by a chat application, consisting of a web page, executing a client script that connects to a server application. The server application accepts new chat participants using the web sockets handshake, accepts incoming chat messages, broadcasts updates of the currently participating users to all clients in session, mediates client-to-client chat sessions. A secondary scenario, is that this API will aid Java-clients of WebSocket applications residing on a server. This scenario is illustrated by a Java-based chat client participating in the chat example above. This JSR will explore a separable client-API for WebSocket that will run standalone on Java SE (specifically including API support for initiating WebSocket communication) as part of its first release, or may defer this to a later release. 2.2 What is the target Java platform? (i.e., desktop, server, personal, embedded, card, etc.)This specification is targeted for Java EE. 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.This specification targets the Java EE 7 Platform. It will be based on the corresponding release of the Java SE platform. 2.4 Should this JSR be voted on by both Executive Committees?No. Just the SE/EE Executive Committee. 2.5 What need of the Java community will be addressed by the proposed specification?The Java community has already seen the need to use WebSocket from Java applications, as can be seen from the list of projects that already provide a way to do so. The Java community is best served by one standard API for using WebSocket in an application. 2.6 Why isn't this need met by existing specifications?Though WebSocket applications could be created by low level I/O APIs in Java SE, this approach is cumbersome and difficult. There is no standard Java API that is high enough level to make the creation of WebSocket applications simple. 2.7 Please give a short description of the underlying technology or technologies:Since WebSocket is TCP based, and uses an HTTP 'handshake' to initiate and terminate a WebSocket session, this project will likely build on existing networking and HTTP-based APIs where appropriate. This JSR will work closely with the Java Servlet 3.1 expert group who are exploring the integration of the intial handshake into the Java Servlet model. 2.8 Is there a proposed package name for the API Specification? (i.e., javapi.something, org.something, etc.)Possibly: javax.net.websocket.* or under java.net.websocket. 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?This JSR will use the I18N support in Java SE. 2.12 Are there any existing specifications that might be rendered obsolete, deprecated, or in need of revision as a result of this work?No. 2.13 Please describe the anticipated schedule for the development of this specification.We hope to deliver the final specification, reference implementation, and TCK in the Q1 of 2013. A rough schedule would be:
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, with conference calls and face-to-face meetings scheduled as needed. We will solicit feedback from the community and leverage the open source development model. 2.15 Provide detailed answers to the transparency checklist, making sure to include URLs as appropriate:websocket-spec java.net project site will be used to track all issues and disseminate information on the progress of the JSR. The Expert Group will conduct business on a publicly readable alias. A private alias will be used only for EG administrative matters, as needed. - Is the schedule for the JSR publicly available, current, and updated regularly? The schedule will be available on the project page for the JSR. - Can the public read and/or write to a wiki for the JSR? We'll use a public mailing list for comments. - Is there a publicly accessible discussion board for the JSR that you read and respond to regularly? We'll track such discussions and respond to them on the public comment mailing list. - Have you spoken at conferences and events about the JSR recently? No - Are you using open-source processes for the development of the RI and/or the TCK? Yes, the RI will be developed as a java.net project. - 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? The terms will be available on the project page for the JSR. - 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? Yes, it will point to the project page for the JSR. 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.The RI will be delivered standalone and possibly bundled with some future release of Glassfish. The TCK will be delivered both standalone and as part of a suitable future release of the Java EE TCK. See the business terms for details. 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 2.19 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 on jsr356-experts@websocket-spec.java.net mailing list which is publicly readable. 2.20 What is the URL of the Issue Tracker that the public can read, and how does the public log issues in the Issue Tracker?A JIRA issue tracker for websocket-spec java.net project will be used for this purpose. The issue tracker URL is http://java.net/jira/browse/WEBSOCKET_SPEC 2.21 Please provide the location of the publicly accessible document archive you have created for the Expert Group.Expert Group's publicly readable mailing list will be archived at http://java.net/projects/websocket-spec/lists/jsr356-experts/archive 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.
3.2 Explanation of how these items might be used as a starting point for the work.Will understand the current needs surrounding WebSocket usage and its implementations, and build an agreed API |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
