• JSRs by Platform
• JSRs by Technology
• JSRs by Stage
• JSRs by Committee
• List of All JSRs



Register for Site

Use of JCP site is subject to the JCP Terms of Use and the Oracle Privacy Policy


• About JCP
  • Program Overview
  • JCP Process Document
  • Calendar
  • JCP Members
  • Executive Committee
  • Elections
• Get Involved
  • Overview
  • Becoming a JCP Member
  • Java in Education
• Community Resources
  • Overview
  • Tutorials
  • JCP Podcasts
  • Spec Lead Guide
  • TCK Tool & Info
  • License Reference
• Community News
  • News
  • Programs & Awards
  • Press Releases
  • Success Stories
• FAQ
• Contact Us

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: -

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

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

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

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

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 Java^TM 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 Java^TM 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 Java^TM 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 Java^TM 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 ("Java^TM 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 Java^TM Programming Language
* JSR 173 Streaming API for XML
* JSR 175 A Metadata Facility for the Java^TM Programming Language
* JSR 181 Web Services Metadata for the Java^TM Platform
* JSR 183 Web Services Message Security APIs
* JSR 201 Extending the Java^TM 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.