 
Use of JCP site is subject to the
JCP Terms of Use and the
Oracle Privacy Policy
 |
|
 JSRs: Java Specification Requests
JSR 109: Implementing Enterprise Web Services
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 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 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 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:
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:
Some sample questions that this JSR might answer are: 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.
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.
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. |
