 
Use of JCP site is subject to the
JCP Terms of Use and the
Oracle Privacy Policy
 |
|
 JSRs: Java Specification Requests
JSR 261: JavaTM API for XML Web Services Addressing (JAX-WSA)
This JSR has been Withdrawn The following has been updated from the original request.
2005.09.15: The JSR Title was changed from
Original Java Specification Request (JSR)
Identification |
Request |
Contributions
Section 1. Identification Submitting Member: Sun Microsystems, Inc. Name of Contact Person: Arun Gupta E-Mail Address: arun.gupta@sun.com Telephone Number: +1 408 276 7098 Fax Number: +1 408 276 7503 Specification Lead: Arun Gupta & Mike Grogan E-Mail Address: arun.gupta@sun.com & mike.grogan@sun.com Telephone Number: +1 408 276 7098 & +1 425 818 1166 Fax Number: +1 408 276 7503 & +1 425 818 1166 Initial Expert Group Membership: Apache Software Foundation Supporting this JSR: Apache Software Foundation Section 2: Request
2.1 Please describe the proposed Specification:W3C WS-Addressing provides transport neutral mechanisms to address Web services and messages and will become a key specification in the Web services world. WS-Addressing defines endpoint reference as a construct for conveying the information needed to access a Web service endpoint and also defines message information headers to enable uniform addressing of messages. This includes addressing for source and destination endpoints as well as message identity independent of underlying transport. Both of these constructs are designed to be extensible and re-usable so that other specifications can build on them. Thus it is beneficial to have a single JSR that cover all the addressing aspects of Web services in order to provide a coordinated effort among all other Web services-related JSRs. The Java APIs for XML-based Web Services Addressing (JAX-WSA) 1.0 specification will define APIs and a framework for supporting transport-neutral addressing of Web services. JAX-WSA will align with JSR 224 (Java API for XML-based RPC 2.0) to define this API and the framework. It's scope includes, but is not limited to, the following set of features:
* JSR 224 defines the javax.xml.rpc.JAXRPCContext interface that provides an extensible property mechanism that may be used to configure javax.xml.rpc.BindingProvider instances. We will define standard JAXRPCContext properties that can be used to access the addressing information. * W3C WS-Addressing defines the action property on message information headers to identify the semantics implied by a message. This attribute derives it's value from the Action attribute on input, output and fault messages in a WSDL port type (known as explicit mapping) or using the default rules as defined in W3C WS-Addressing and is used for internal dispatching of an incoming message. We will extend the WSDL-to-Java mapping defined in JSR 224 to support both explicit and default mapping. * We expect that a JAX-WSA compatible application will be deployable in a J2EE 5.0 compatible application server. This JSR will define a standard deployment descriptor for J2EE application to provide addressing configuration to the container. We will also define standard SPIs, to be honored by an underlying JAX-RPC implementation, that a J2EE container can use to access addressing information. * W3C WS-Addressing defines faults with code, subcode, reason, and detail that are generated if a particular condition is met. It also defines the binding of faults to SOAP 1.1 and SOAP 1.2. We will define a mapping of W3C WS-Addressing faults to Java exceptions. * JSR 224 and JSR 183 (Web Services Message Security APIs) define APIs and annotations for Web services message security. This JSR will define how these APIs and annotations interact with addressing. * Policy information can be specified as part of an endpoint reference. Policy describes the behavior, requirements, and capabilities of the endpoint and an endpoint may have multiple policies associated with it. JAX-WSA will define a standard way to attach and consume standards-based policy information associated with each endpoint reference. JAX-WSA will align with standard Java technologies to specify policy information. * Endpoints represented by endpoint references with different reference properties may have different associated metadata. We will define reference properties on endpoint references to enable conversational interactions associated with generic session capabilities between sender and receiver. * Message Information Headers consists of abstract properties that define interaction patterns such as "Request Reply". This JSR will define "synthetic interactions" defined using message information headers and how they map to the JAX-RPC programming model. For instance a request-response interaction can be created out of two separate one-way interaction. * Define interoperability requirements on a JAX-WSA compatible application based upon the W3C WS-Addressing specification. 2.2 What is the target Java platform? (i.e., desktop, server, personal, embedded, card, etc.)Like JAX-RPC, JAX-WSA is intended to be used in both J2SE and J2EE contexts. 2.3 The Executive Committees would like to ensure JSR submitters think about how their proposed technology relates to all of the Java platform editions. Please provide details here for which platform editions are being targeted by this JSR, and how this JSR has considered the relationship with the other platform editions.Like JAX-RPC, JAX-WSA is intended to be used in both J2SE and J2EE contexts. 2.4 Should this JSR be voted on by both Executive Committees?No 2.5 What need of the Java community will be addressed by the proposed specification?This specification will provide Java APIs and framework for supporting transport-neutral addressing of Web services. 2.6 Why isn't this need met by existing specifications?Please see 2.1 above. 2.7 Please give a short description of the underlying technology or technologies:Please see 2.1 above. 2.8 Is there a proposed package name for the API Specification? (i.e., javapi.something, org.something, etc.)javax.ws.addressing 2.9 Does the proposed specification have any dependencies on specific operating systems, CPUs, or I/O devices that you know of?No 2.10 Are there any security issues that cannot be addressed by the current security model?No 2.11 Are there any internationalization or localization issues?No 2.12 Are there any existing specifications that might be rendered obsolete, deprecated, or in need of revision as a result of this work?No 2.13 Please describe the anticipated schedule for the development of this specification.The final schedule will need to be determined by the expert group, and will also be dependent on the progress of WS-Addressing Working Group at W3C. However, we expect to have a final draft by December 2005. 2.14 Please describe the anticipated working model for the Expert Group working on developing this specification.The Expert Group will interact using the 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.15 It is important to the success of the community and each JSR that the work of the Expert Group be handled in a manner which provides the community and the public with insight into the work the Expert Group is doing, and the decisions that the Expert Group has made. The Executive Committees would like to ensure Spec Leads understand the value of this transparency and ask that each JSR have an operating plan in place for how their JSR will address the involvement of the community and the public. Please provide your plan here, and refer to the Spec Lead Guide for a more detailed description and a set of example questions you may wish to answer in your plan.We will leverage the Early Draft feature of JCP 2.6 to allow the public to see the specification in progress. The reference implementation will be developed entirely in a public project on java.net. The TCK will be developed privately by Sun. 2.16 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 as separate downloads. 2.17 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.18 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.6, the following is a summary of Sun's anticipated principal license terms and conditions for the JSR-tbd, JAX-WSA, version 1.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 Java Research License (JRL) and Java Distribution License (JDL). Licensing of the RI is not required for the licensing of the TCK. The JAX-WSA TCK and RI source will be made available at no extra charge to J2EE licensees. The JAX-WSA 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.
3.2 Explanation of how these items might be used as a starting point for the work.The Java APIs for Web services Addressing 1.0 specification will aim to support the work done under WS-Addressing Working Group at W3C. Other documents and specifications listed above will be used in the specification of functionality outlined in Section 2.1 of this JSR |
