The Java Community Process(SM) Program - JSRs: Java Specification Requests (original) (raw)
JSRs: Java Specification Requests
JSR 109: Implementing Enterprise Web Services
| Stage Access Start Finish Maintenance Release 3 Download page 07 Jun, 2013 Maintenance Draft Review 5 Download page 21 Feb, 2013 25 Mar, 2013 Maintenance Release 2 Download page 10 Dec, 2009 Maintenance Draft Review 4 Download page 30 Sep, 2009 30 Oct, 2009 Maintenance Draft Review 3 Download page 01 Apr, 2009 04 May, 2009 Maintenance Release Download page 11 May, 2006 Maintenance Draft Review 2 Download page 09 Feb, 2006 13 Mar, 2006 Maintenance Draft Review Download page 24 Oct, 2005 28 Nov, 2005 Final Release Download page 15 Nov, 2002 Final Approval Ballot View results 01 Oct, 2002 14 Oct, 2002 Proposed Final Draft Download page 31 Aug, 2002 Public Review Download page 25 Apr, 2002 23 Jun, 2002 Community Draft Ballot View results 15 Jan, 2002 22 Jan, 2002 Community Review Login page 03 Dec, 2001 22 Jan, 2002 Expert Group Formation 20 Mar, 2001 01 May, 2001 JSR Review Ballot View results 06 Mar, 2001 19 Mar, 2001 |
Status: Maintenance
JCP version in use: 2.7
Java Specification Participation Agreement version in use: 2.0
Description:
This specification defines the programming model and runtime architecture for implementing web services in Java.
Please direct comments on this JSR to the Spec Lead(s)
| Specification Leads | ||
|---|---|---|
| Jitendra Kotamraju | Oracle | |
 |
||
| Expert Group | ||
| Art Technology Group Inc.(ATG) | BEA Systems | |
| Cisco Systems | Developmentor | |
| Hewlett-Packard | IBM | |
| Interwoven | Macromedia, Inc. | |
| Novell, Inc. | Oracle | |
| SAP SE | Software AG | |
| Sun Microsystems, Inc. | Sybase |
Updates to the Original JSR
The following has been updated from the original JSR:
2013.02.19:
Martin Grebac is the Maintenance Lead for JSR 109.
Maintenance Lead: Martin Grebac
E-Mail Address: martin.grebac@oracle.com
Telephone Number: +420 221 438 700
2007.11.02:
Jitendra Kotamraju is the Maintenance Lead for JSR 109.
Maintenance Lead: Jitandra Kotamraju
E-Mail Address: jitendra.kotamraju@sun.com
Telephone Number: +1 408 276 7298
Fax Number: +1 408 276 7191
2005.06.08:
The Maintenance Lead changed from IBM to Sun Microsystems on 2005.06.08. The JCP version changed from 2.1 to 2.6 on that same date.
Maintenance Lead: Dhiru Pandey
E-Mail Address: dhiru.pandey@sun.com
Telephone Number: +1 408 276 4405
Fax Number: +1 408 276 7191
Original Java Specification Request (JSR)
Identification | Request | Contributions
Section 1. Identification
Submitting Member: IBM Corporation
Name of Contact Person: Donald Ferguson
E-Mail Address: dff@us.ibm.com
Telephone Number: 914-766-1154
Fax Number: 914-766-8124
Specification Lead: Jim Knutson
E-Mail Address: knutson@us.ibm.com
Telephone Number: +1 1 512 838 1655
Fax Number: +1 512 838 1032
This information has been updated from the original JSR.
Initial Expert Group Membership:
(Please provide company or organization names. Note that expert group members must have signed the JSPA.)
Section 2: Request
2.1 Please describe the proposed Specification:
This specification defines the programming model and architecture for implementing web services in Java. The specification will build on the work of JSRs 67, 93 and 101. The specification will also build on the JSRs for J2EE technologies, including J2EE itself, Servlets and JSPs. The intent of this JSR is not to subsume J2EE JSR's role nor to define a platform. We also do not pre-suppose that this JSR's output will become part of J2EE. Selecting this JSR's output, in whole or in part, for inclusion in J2EE will be decided within the J2EE JSR process.
JSR 101 focuses on XML RPC and the Java language, including representing XML based interface definitions in Java, Java definitions in XML based interface definition languages (e.g. SOAP) and marshalling. JSR 67 provides similar functions for XML messaging.
JSR 93 defines the Java interfaces to XML registries, like JNDI, ebXML and UDDI. These interfaces provide the mechanism through which client applications find web services and web services (and servers) publish their interfaces.
This JSR's objective is provide a programming model and runtime model for web services based on JSRs 67, 93 and 101 and future JSRs oriented toward individual web services standards, similar to what the EJB specification did for RMI (RMI-IIOP) and JNDI. This is an analogy only, and this JSR will build on but not extend the EJB specification.
Specifically, we will focus this JSR on:
- The programming model for implementing a web service. This may include defining a new server side base classes and frameworks, specifying new APIs, defining new concrete subclasses of JSP, Servlet or an existing EJB type like MessageBean. Any extensions would be analogous to HttpServlet extending generic Servlet or the approach the Enterprise MediaBeans takes in defining subtypes of EntityBeans.
- The client side programming model for using web services from Java. This would be analogous to the client programming model that EJB defines. This would explain how to use the APIs defined in JSRs 67, 93 and 101 in tandem. Again, the intent is to minimize new concepts introduced.
- The specification would state how existing concepts, like the EJB transaction model, security for Servlets, EJBs, or HttpSession State materialize in web services usage and implementation.
- Defining how to extend the basic Servlet/HTTP model to include dispatching web services over FTP, e-mail, etc. Again, this ideally references the existing JSRs/Java standards and focuses on the programming model and parts needed to support web services.
- Define the concrete model for developing and deploying a web service on top of J2EE.
This JSR would provide documentation on the programming model, APIs and runtime service model. It would provide a reference implementation for any J2EE compliant application server and would have open source test cases for interoperability and compliance. The specification would rely on the existing J2EE application packaging.
Some sample questions that this JSR might answer are:
- What is the lifecycle model for a web service?
- Are there stateless and stateful web services? How do you implement a stateful EJBs?
- Do web services have Homes?
- Is there an EntityBean model for web services?
- What are the mapping service contexts that flow over ebXML or SOAP to EJB services?
- Are new server-side classes for web services needed? To what extent can existing J2EE server-side APIs such as EJB and JMS be used for dispatching web service calls? Is subclassing appropriate for web-service specific EJBs, or should web services information go into the EJB deployment descriptor, or are both techniques needed?
- Are new client-side classes for web services needed? To what extent can web services be invoked using existing J2EE client programming models such as EJB and JMS?
2.2 What is the target Java platform? (i.e., desktop, server, personal, embedded, card, etc.)
This specification targets the J2EE platform.
2.3 What need of the Java community will be addressed by the proposed specification?
Over the past several years and with the aid of many vendors, J2EE has become the platform of choice for developing web-based business applications. With the assistance of major standards bodies such as the WorldWide Web Consortium(W3C), the ebXML group, and the UDDI organization, standards are being developed for dynamically publishing, finding and binding to business applications over the web. These business applications may be written in Java or in any other programming language, but as long as they follow the appropriate standards they can participate as web services. It is very important to the Java community that Java application programmers have a common model for writing and running web services under J2EE. It is important that there is a consistent Java model for accessing and using interfaces and services that public web services protocols define. This includes those that exist today (for example SOAP RPC, SOAP messaging, and WSDL) and those that are currently under development in such areas as security, trust and systems management.
This specification does not encroach on the overall coordination mission of J2EE JSRs. This specification seeks to define APIs that programmers use, base types programmers extend and a common runtime mapping of web services interface definition languages and services (e.g. Security, SOAP Attachments).
2.4 Why isn't this need met by existing specifications?
Specifications have been opened for defining APIs to parts web services, such as JSR 67 (Java APIs for XML Messaging), JSR 93 (Java APIs for XML Registry) and JSR 101 (Java APIs for XML-Based RPC). Much in the same way that Servlets tied together a set of concepts like cookies and HttpSession, and EJB tied together RMI, JTA/JTS, JDBC, etc. with a programming model and runtime model, we view this JSR doing the same for implementing and using web services.
2.5 Please give a short description of the underlying technology or technologies:
This is covered in section 2.1.
2.6 Is there a proposed package name for the API Specification? (i.e., javapi.something, org.something, etc.)
To be determined
2.7 Does the proposed specification have any dependencies on specific operating systems, CPUs, or I/O devices that you know of?
No.
2.8 Are there any security issues that cannot be addressed by the current security model?
No. We believe that this JSR will define how to integrate the existing J2EE/Java security model with the Internet security models, like Digital Signatures.
2.9 Are there any internationalization or localization issues?
No.
2.10 Are there any existing specifications that might be rendered obsolete, deprecated, or in need of revision as a result of this work?
No.
2.11 Please describe the anticipated schedule for the development of this specification.
- Community Draft submitted to PMO: August, 2001
- Public Draft submitted to PMO: November, 2001
- Proposed Final Draft submitted to PMO: February, 2002
2.12 Working style for the expert group.
We anticipate using a collaborative style for the expert group, with regularly-scheduled meetings and a teamroom to facilitate intragroup communication.
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.
- Existing J2EE specifications
- Universal Description, Discovery, and Integration (UDDI) Programmer's Specification
- W3 XMP Protocol group
- Web Services Definition Language (WSDL) 1.0
- Simple Object Access Protocol (SOAP) 1.1
- ebXML Technical Specifications
- Java( TM) APIs for XML Messaging 1.0
- Java( TM) APIs for XML Registries 1.0
- Java (TM) APIs for XML RPC
3.2 Explanation of how these items might be used as a starting point for the work.
These are some of the specifications that the expert group will need to consider when it is defining Java APIs to web services, since the web services specifications themselves are being defined by standards bodies other than the JCP.
The purpose of the expert group is to take advantage of the excellent work that is going on in the standards bodies listed above by defining APIs and thin bindings that make these standards easily accessable to and exploitable by the Java programmer. The intent is not to duplicate work going on in these standards bodies but to make such work available in an orderly and expeditious fashion to the Java programming community.