JSRs: Java Specification Requests
JSR 224: JavaTM API for XML-Based Web Services (JAX-WS) 2.0
The following information has been updated from the original request:
2013.07.15: The Maintenance Lead was changed to co-leads Shih-Chang Chen, Martin Grebac, Oracle.
Maintenance Lead: Shih-Chang Chen, Martin Grebac
E-Mail Address: shih-chang.chen
Telephone Number: +1 856 359 2915, +420 22 143 8700
Fax Number: -2007.11.02: The Maintenance Lead was changed to Jitendra Kotamraju.
Maintenance Lead: Jitendra Kotamraju
E-Mail Address: jitendra.kotamraju
Telephone Number: +1 408 276 7298
Fax Number: +1 408 276 71912007.05.16: The JSR summary was updated from "The JAX-WS 2.0 specification extends the existing JAX-RPC 1.0 specification with new features."
2006.07.20: The Maintenance Lead was changed to Doug Kohlert.
Maintenance Lead: Doug Kohlert
E-Mail Address: doug.kohlert
Telephone Number: +1 503 345 9806
Fax Number: +1 503 345 98062005.07.15: The title was changed from "Java API for XML-Based RPC 2.0" to "Java API for XML-Based Web Services 2.0". The summary was also updated to reflect this change.
Specification Lead: Roberto Chinnici & Rajiv Mordani
E-Mail Address: roberto.chinnici
Telephone Number: +1 408 276 7043 & +1 408 276 7204
Fax Number: +1 408 276 7191
Original Java Specification Request (JSR)
Original Summary: The JAX-RPC 2.0 specification extends the existing JAX-RPC 1.0 specification with new features, including some or all of the following: direct support for JAXB 2.0-based data binding, support for the latest W3C and WS-I standards (e.g. SOAP 1.2, WSDL 1.2), standardized metadata for Java<->WSDL mapping, ease-of-development features, support for easier evolution of Web services, an improved handler framework, support for asynchronous RPC and non-HTTP transports.
Section 1. Identification
Submitting Member: Sun Microsystems, Inc
Name of Contact Person: Roberto Chinnici
E-Mail Address: firstname.lastname@example.org
Telephone Number: +1 408 276 7043
Fax Number: +1 408 276 7191
Specification Lead: Roberto Chinnici & Marc Hadley
E-Mail Address: email@example.com & firstname.lastname@example.org
Telephone Number: +1 408 276 7043 & +1 781 442 3740
Fax Number: +1 408 276 7191 & +1 781 442 1437
NOTE: this information has been updated from this original request.
Initial Expert Group Membership:
* BEA Systems
Supporting this JSR:
* BEA Systems
Section 2: Request
2.1 Please describe the proposed Specification:
The JAX-RPC 1.0 specification ( JSR-101) defines APIs and conventions for supporting XML-based RPC protocols in the JavaTM platform. The specification is neutral with respect to network protocols , but the design center is SOAP-based Web services. In order to provide interoperability between JAX-RPC implementations and with Web services implemented using other technologies, JAX-RPC 1.1 added support for the WS-I Basic Profile 1.0 specification.
The JAX-RPC 2.0 specification will extend JAX-RPC in a number of different areas.
Due primarily to scheduling concerns, JAX-RPC 1.0 had to define its own data binding facilities. Now that the JAXB 1.0 technology ( JSR-31) has gone final, there is no reason to maintain two separate sets of XML mapping rules in the Java(TM) platform. Hence we anticipate that JAX-RPC 2.0 will strongly align with JAXB, effectively delegating to the JAXB 2.0 specification (developed in parallel with the present one) all data binding-related tasks.We expect the expert groups for JAX-RPC 2.0 and JAXB 2.0 to work closely together to ensure that all requirements are taken into account. Of course, great care will be exercised in order to maintain backward compatibility with the JAX-RPC 1.1 specification in the area of data binding, as well as in others.
We also expect JAX-RPC 2.0 to support new versions of external standards from organization such as W3C and WS-I. For instance, it is expected that the SOAP 1.2 and WSDL 1.2 specifications being developed at W3C will be finalized in the timeframe of this JSR, so it would make sense for JAX-RPC 2.0 to provide full support for them.
JAX-RPC 1.1 defines standard mappings between Java and WSDL. Additionally, there are a number of JSRs, namely JSR-109 (Implementing Enteprise Web Services) and JSR-181 (Web Services Metadata for the JavaTM Platform), that have defined or are in the process of defining a representation for the Java<->WSDL mapping information described in JAX-RPC. Clearly, this dependency forces those specifications to be updated whenever JAX-RPC changes. For JAX-RPC 2.0, we'd like to make it possible to use annotations (i.e. the metadata facility defined by JSR-175) to incorporate Java<->WSDL mapping information directly inside Java classes. We also expect JAXB 2.0 to do the same for data binding. The explicit goal here is to capture all the information in JSR-109's jaxrpc-mapping-info descriptor and to align with JSR-181 to avoid duplication of effort.
JAX-RPC 2.0 will have a major focus on Ease-of-Development in order to allow this technology to be used by an even wider circle of developers. JAX-RPC could benefit from using annotations (JSR-175) to simplify the most common development scenarios for both clients and servers. For instance, the java.rmi.Remote and java.rmi.RemoteException types are used essentially as markers in JAX-RPC 1.0. Once again JAX-RPC 2.0 will align with and complement JSR-181 (Web Services Metadata for the JavaTM Platform). In particular, we'd like the Web service-related annotations defined by these JSRs to work together smoothly so as to simplify the developer's task.
Feedback from JAX-RPC 1.0 implementors and users alike has pointed out a number of shortcomings in the handler processing framework. JAX-RPC 2.0 will address them, including: choice of a single bidirectional handler chain model vs. separate one-directional chains for request/response; unifying the handleResponse/handlerFault methods; improving the declarative model for handlers; decoupling the handler model from SOAP; clarifying the relationship of the handler framework to the SAAJ API.
Other areas of JAX-RPC 1.0 may be the target of improvements in 2.0, including the mapping of Java exceptions to SOAP/WSDL faults as well as the partial dependency on SOAP bindings for the WSDL->Java mapping, which clashes with the protocol-agnostic nature of JAX-RPC.
Another area where we see the potential for improvements to JAX-RPC is that of versioning and evolution of Web services. Currently, users that want to evolve an existing JAX-RPC-based Web service must take into account the WSDL document for it and either carefully go about modifying/augmenting the existing interface or create a completely different one.
JAX-RPC 1.0 essentially ignored non-HTTP transports, especially messaging-based ones and asynchronous invocations. In the RPC world, the paradigm of asynchronous remote procedure calls is well understood and we'd like to investigate adding support for it to JAX-RPC 2.0.
JAX-RPC being an extremely valuable technology for developers of client applications, we would like to be able to include it in J2SE. JAX-RPC 1.0 didn't define portable stubs or serializers, mostly because there wasn't a single, standard XML processing mechanism that fulfilled all requirements. In JAX-RPC 2.0, we'd like to investigate using StAX (JSR 173, Streaming API for XML) as a foundation for portable generated Java artifacts.
Given that the list of potential new features in JAX-RPC 2.0 is extensive, we expect the expert group to prioritize it and only address the most important ones in the timeframe of this JSR.
2.2 What is the target Java platform? (i.e., desktop, server, personal, embedded, card, etc.)
It will run on JavaTM 2 Platform, Standard Edition (J2SE) 1.5.
2.3 What need of the Java community will be addressed by the proposed specification?
Please see 2.1 above.
2.4 Why isn't this need met by existing specifications?
Please see 2.1 above.
2.5 Please give a short description of the underlying technology or technologies:
Please see 2.1 above.
2.6 Is there a proposed package name for the API Specification? (i.e., javapi.something, org.something, etc.)
2.7 Does the proposed specification have any dependencies on specific operating systems, CPUs, or I/O devices that you know of?
2.8 Are there any security issues that cannot be addressed by the current security model?
2.9 Are there any internationalization or localization issues?
2.10 Are there any existing specifications that might be rendered obsolete, deprecated, or in need of revision as a result of this work?
The proposed specification will supersede JSR 101 ("JavaTM API for XML based RPC").
2.11 Please describe the anticipated schedule for the development of this specification.
The final schedule will need to be determined by the expert group as it depends on the features that will be incorporated into the specification, but we expect to have a final draft by the end of 2004.
2.12 Please describe the anticipated working model for the Expert Group working on developing this specification.
The Expert Group will interact using the private e-mail alias and web site provided by the JCP's PMO in addition to conference calls and face-to-face meetings as appropriate. Expert Group members have strong ties into the Java and Web Services communities and will call on domain experts as needed.
2.13 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.
They will be available both separate and as part of J2EE 1.5.
2.14 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).
2.15 Please provide a description of the business terms for the Specification, RI and TCK that will apply when this JSR is final.
In line with the Java Community Process version 2.5, the following is a summary of Sun's anticipated principal license terms and conditions for the JSR-tbd, JAX-RPC, version 2.0.
The Reference Implementation (RI) will be delivered in binary form free of charge. Licensing for the RI will be under the Sun Microsystems, Inc. Binary Code License Agreement.
The RI source will be available under Sun Community Source License (SCSL). Licensing of the RI is not required for the licensing of the TCK.
The JAX-RPC TCK and RI source will be made available at no extra charge to J2EE licensees.
The JAX-RPC TCK will be licensed at no charge, without support or any trademark license rights under Sun's Compatibility Testing Scholarship Program, described at http://java.sun.com/scholarship/.
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 014 Add Generic Types to the JavaTM Programming Language
* JSR 173 Streaming API for XML
* JSR 175 A Metadata Facility for the JavaTM Programming Language
* JSR 181 Web Services Metadata for the JavaTM Platform
* JSR 183 Web Services Message Security APIs
* JSR 201 Extending the JavaTM Programming Language with Enumerations, Autoboxing, Enhanced for loops and Static Import
* JSR 921 Implementing Enterprise Web Services 1.1
* JSR-tbd JAXB 2.0 (submitted in parallel with the present one)
* SOAP 1.2 Part 1: Messaging Framework and SOAP 1.2 Part 2: Adjuncts (candidate recommendation)
* WSDL 1.2,/a> and WSDL 1.2: Bindings (public draft).
3.2 Explanation of how these items might be used as a starting point for the work.
The Java APIs for XML based RPC 1.1 specification will be used as the basis for this work.