JSR 224: JavaTM API for XML-Based Web Services (JAX-WS) 2.0

Stage Access Start Finish
Maintenance Release 5 Download page 21 Sep, 2017
Maintenance Review Ballot View results 11 Apr, 2017 24 Apr, 2017
Maintenance Draft Review 6 Download page 27 Mar, 2017 10 Apr, 2017
Maintenance Release 4 Download page 19 Dec, 2011
Maintenance Draft Review 5 Download page 12 Apr, 2011 12 May, 2011
Maintenance Release 3 Download page 10 Dec, 2009
Maintenance Draft Review 4 Download page 25 Sep, 2009 25 Oct, 2009
Maintenance Draft Review 3 Download page 30 Mar, 2009 04 May, 2009
Maintenance Release 2 Download page 08 May, 2007
Maintenance Draft Review 2 Download page 05 Apr, 2007 07 May, 2007
Maintenance Release Download page 05 Feb, 2007
Maintenance Draft Review Download page 25 Oct, 2006 27 Nov, 2006
Final Release Download page 11 May, 2006
Final Approval Ballot View results 04 Apr, 2006 17 Apr, 2006
Proposed Final Draft Download page 11 Oct, 2005
Public Review Ballot View results 12 Jul, 2005 18 Jul, 2005
Public Review Download page 17 Jun, 2005 18 Jul, 2005
Early Draft Review 3 Download page 05 Apr, 2005 05 May, 2005
Early Draft Review 2 Download page 04 Feb, 2005 06 Mar, 2005
Early Draft Review Download page 23 Jun, 2004 23 Jul, 2004
Expert Group Formation 10 Jun, 2003 23 Apr, 2004
JSR Review Ballot View results 27 May, 2003 09 Jun, 2003
Status: Maintenance
JCP version in use: 2.10
Java Specification Participation Agreement version in use: 2.0

Description:
The JAX-WS 2.0 specification is the next generation web services API replacing JAX-RPC 1.0.

Expert Group Transparency:
Public Project Page
Public Communications
Issue Tracking

Team

Specification Leads
Lukas Jungmann Oracle
Expert Group
Art Technology Group Inc.(ATG)
: Mark Stewart BEA Systems
: Neal Yin Capgemini
: Carlo Marcoli
Developmentor
: Kevin R. Jones IBM
: Russell Butek IBM
: Jian Wu Dai
Intalio, Inc.
: Sebastien Sahuc Motorola
: Rahul Sharma Nokia Corporation
: Srividya Natarajan
Novell, Inc.
: Bjarne Rasmussen NTT Data Corporation
: Toshiyuki Kimura Oracle
: Shih-Chang Chen
Oracle
: Roberto Chinnici Oracle
: Martin Grebac Oracle
: Lukas Jungmann
Oracle
: Anish Karmarkar Oracle
: Greg Pavlik Pramati Technologies
: Rajiv Shivane
Progress Software
: Daniel Kulp Red Hat
: Alessio Soldano SAP SE
: Chavdar Baikov
SAP SE
: Sanjay Patil SeeBeyond Technology Corp.
: Ugo Corda SeeBeyond Technology Corp.
: Alan Davies
Sonic Software
: Glen Daniels Sosnoski, Dennis M.
: Dennis M. Sosnoski Sun Microsystems, Inc.
: Marc Hadley
Sun Microsystems, Inc.
: Jitendra Kotamraju Sun Microsystems, Inc.
: Rajiv Mordani Sun Microsystems, Inc.
: Vivek Pandey
TmaxSoft, Inc.
: Changshin Lee Trifork
: Claus Nyhus Christensen WebMethods Corporation
: Christopher St. John
Contributors

Updates to the Original JSR

The following information has been updated from the original request:

2017.03.17:
The JSR has moved to JCP 2.10 as part of the maintenance process.

Q: Is the schedule for the JSR publicly available, current, and updated regularly?
A: It’s aligned with JDK 9 schedule

Q: Can the public read and/or write to a wiki for the JSR?
A: no, there is no wiki set up

Q: Is there a publicly accessible discussion board for the JSR that you read and respond to regularly?
A: there are mailing lists: http://java.net/projects/jax-ws/lists as well as “private project” for EG: https://java.net/projects/jsr224/lists

Q: Have you spoken at conferences and events about the JSR recently?
A: No

Q: Are you using open-source processes for the development of the RI and/or the TCK?
A: for RI - yes, for TCK - no, I don’t think so.

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?
A: API and RI are both hosted at java.net, so its terms of use should apply

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.
A: https://java.net/jira/browse/JAX_WS and private for EG: http://java.net/jira/browse/JSR224

Q: What is the mechanism for the public to provide feedback on your JSR?
A: Mailing lists: https://java.net/projects/jax-ws/lists and private for EG: https://java.net/projects/jsr224/lists

Q: Where is the publicly-accessible document archive for your Expert Group?
A: for the spec itself internal-only, I think; for discussions mailing list archives provided by java.net infrastructure. The JSR went final under JCP 2.6.

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?
A: yes, twitter: https://twitter.com/jlukas

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)?
A: Don’t know at this point since I’m new in this role within this JSR.

2017.02.01:
The Maintenance Lead was changed from co-leads Shih-Chang Chen, Martin Grebac to Lukas Jungmann.

Maintenance Lead: Lukas Jungmann, Oracle

E-Mail Address: lukas.jungmann@oracle.com

Telephone Number: +420 221 43 8543

Fax Number: -

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@oracle.com, martin.grebac@oracle.com

Telephone Number: +1 856 359 2915, +420 22 143 8700

Fax Number: -
NOTE: this information has been updated from this original request.

2007.11.02:
The Maintenance Lead was changed to Jitendra Kotamraju.

Maintenance Lead: Jitendra Kotamraju

E-Mail Address: jitendra.kotamraju@sun.com

Telephone Number: +1 408 276 7298

Fax Number: +1 408 276 7191
NOTE: this information has been updated from this original request.

2007.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@sun.com

Telephone Number: +1 503 345 9806

Fax Number: +1 503 345 9806
NOTE: this information has been updated from this original request.

2005.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.

2005.06.23:

Specification Lead: Roberto Chinnici & Rajiv Mordani

E-Mail Address: roberto.chinnici@sun.com & rajiv.mordani@sun.com

Telephone Number: +1 408 276 7043 & +1 408 276 7204

Fax Number: +1 408 276 7191
NOTE: this information has been updated from this original request.

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: Roberto Chinnici & Marc Hadley

E-Mail Address: roberto.chinnici@sun.com & marc.hadley@sun.com

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
• IONA Technology
• Macromedia
• Oracle
• SAP AG
• Sun Microsystems, Inc.

Supporting this JSR:

• BEA Systems
• Borland Software Corporation
• Fujitsu
• IONA Technology
• Macromedia
• Oracle
• SAP AG
• Sun Microsystems, Inc.

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™ 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 101 # Java APIs for XML based RPC (JAX-RPC) 1.0
* 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.