 
Use of JCP site is subject to the
JCP Terms of Use and the
Oracle Privacy Policy
 |
|
 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:
2017.03.17:
Q: Is the schedule for the JSR publicly available, current, and updated regularly?
Q: Can the public read and/or write to a wiki for the JSR?
Q: Is there a publicly accessible discussion board for the JSR that you read and respond to regularly?
Q: Have you spoken at conferences and events about the JSR recently?
Q: Are you using open-source processes for the development of the RI and/or the TCK?
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?
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.
Q: What is the mechanism for the public to provide feedback on your JSR?
Q: Where is the publicly-accessible document archive for your Expert Group?
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: Only pointers to EG are available
Q: Do you have a Twitter account or other social networking feed which people can follow for updates on your JSR?
Q: Which specific areas of feedback should interested community members (such as the Adopt-a-JSR program) provide to improve the JSR (please also post this to your Community tab)?
2017.02.01: Maintenance Lead: Lukas Jungmann, Oracle E-Mail Address: lukas.jungmann Telephone Number: +420 221 43 8543 Fax Number: -
2013.07.15: Maintenance Lead: E-Mail Address: Telephone Number: Fax Number: - NOTE: this information has been updated from this original request.
2007.11.02: Maintenance Lead: E-Mail Address: Telephone Number: Fax Number:
2007.05.16:
2006.07.20: Maintenance Lead: E-Mail Address: Telephone Number: Fax Number:
2005.07.15:
2005.06.23: Specification Lead: E-Mail Address: Telephone Number: Fax Number:
Original Java Specification Request (JSR)
Identification |
Request |
Contributions
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: roberto.chinnici@sun.com Telephone Number: +1 408 276 7043 Fax Number: +1 408 276 7191 Specification Lead: E-Mail Address: Telephone Number: Fax Number: 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.)javax.xml.rpc 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 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?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).N/A 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.JSRs:
* 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. |
