 
Use of JCP site is subject to the
JCP Terms of Use and the
Oracle Privacy Policy
 |
|
 JSRs: Java Specification Requests
JSR 181: Web Services Metadata for the JavaTM Platform
JCP version in use: 2.7 Java Specification Participation Agreement version in use: 2.0 Description: This JSR defines an annotated JavaTM format that that uses JavaTM Language Metadata (JSR 175) to enable easy definition of Java Web Services in a J2EE container. Please direct comments on this JSR to the Spec Lead(s) Team
The following updates were made to the original proposal.
2009.05.01: Specification Lead: Alan Mullendore E-Mail Address: alan.mullendore Telephone Number: - Fax Number: - 2005.09.15:The Maintenance Lead changed: Specification Lead: Stuart Edmondston E-Mail Address: stuart.edmondston Telephone Number: +1 415 402 7672 Fax Number: +1 415 402 7243 Original Java Specification Request (JSR)
Identification |
Request |
Contributions |
Additional Information
Section 1. Identification Submitting Member: BEA Systems Name of Contact Person: David Bau E-Mail Address: david.bau@bea.com Telephone Number: +1 610 745 5581 Fax Number: +1 425 641 7315 Specification Lead: David Bau E-Mail Address: david.bau@bea.com Telephone Number: +1 610 745 5581 Fax Number: +1 425 641 7315 NOTE that the Spec Lead has been changed to Jim Trezzo. Initial Expert Group Membership: BEA Systems Supporting this JSR: BEA Systems Section 2: Request
2.1 Please describe the proposed Specification:This specification will define an annotated Java syntax for programming Web Services. The principal goal of the specification is to provide a simplified model for web services development that is easy to learn and quick to develop with. The specification will focus on enabling the commonly needed forms of web services required for achieving robust, maintainable, and highly interoperable integration. The Web Services Metadata for the JavaTM Platform will build on the JavaTM Language Metadata technology (JSR 175) to provide an easy to use syntax for describing web services at the source-code level for the J2EE platform. The specification is intended to provide a syntax that is amenable to manipulation by tools. The specification is intended to define a format that is easy to deploy. One attractive model is a submerged compilation model similar to JSP. The specification will build on the work of JSR-101 and JSR-109, and it will be designed to deploy on existing J2EE components. Metadata in the format should determine how J2EE features are deployed and provide access to the commonly needed web services technology standardized in the above JSRs while reducing the need to for application developers to learn and implement routine APIs. 2.2 What is the target Java platform? (i.e., desktop, server, personal, embedded, card, etc.)J2EE 2.3 What need of the Java community will be addressed by the proposed specification?Developers need a standard way to more quickly build and deploy web services without learning and implementing generalized APIs and deployment descriptors. The goals are to provide a mechanism related to core J2EE web services APIs that plays the role, by analogy, that JSP plays in relationship to Servlets. While the core J2EE web services APIs must provide broad generality and power, the Web Services Metadata for the JavaTM Platform specification must provide ease of development, including a simple syntax that can be managed by tools, and it must permit an easy model for deployment. It is not a goal of the current JSR to make it possible to use every feature or build every possible web service that is enabled by the existing specifications. However, it is a goal to make it easy to build the commonly needed types of web services. This JSR aims to address the following specific common needs: * It should make it easy for a Java developer to develop server applications that conform both to basic SOAP and WSDL standards. * It should be easy to build web services that can be deployed on the core Web Services APIs and existing J2EE standards. * It should be easy for a developer to separately control public web service message contracts and private implementation signatures, since in practice public and private formats evolve on different schedules. * It should be easy to use asynchronous modes of communication. Since diverse servers that communicate with each other must be expected to operate on different time scales, it is often critical that they do not block each other. While it is a goal to define an idiom for easily building asynchronous web services, standardization of asynchronous web services protocols is outside the scope of this JSR. Asynchronous support in Web Services Metadata for the JavaTM Platform shall be independent of any particular web service standard for expressing asynchronous messaging. 2.4 Why isn't this need met by existing specifications?Prior JSRs that are related include:
JSR-109, which is elaborating a fully generalized runtime model for building and using web services. This model shall be designed to be layered on top of the APIs defined in the other specifications. However, it is not an explicit goal to achieve complete generality. Instead, the primary purpose of this JSR is to provide a highly simplified idiom for web services development and deployment. No other specification or group of specifications meets this goal. 2.5 Please give a short description of the underlying technology or technologies:JavaTM Language Metadata is a recently submitted JSR that provides a standard model for annotating Java code, of which Web Services Metadata for the JavaTM Platform will be one application. Javadoc is a standard syntax for structured comments that was introduced in the first version of the JavaTM Language Specification, and may be related to JavaTM Language Metadata. JSR-109 is elaborating a runtime model for building web services; it is a goal of the Web Services Metadata specification to be able to be implemented on this model. JSR-101 is elaborating an model for web services in Java. J2EE provides existing technologies for messaging, state management and communication; the Web Services Metadata specification will rely on these technologies. 2.6 Is there a proposed package name for the API Specification? (i.e., javapi.something, org.something, etc.)TBD 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?The expert group developing this specification will research the security requirements. 2.9 Are there any internationalization or localization issues?The expert group developing this specification will research the internationalization and localization requirements. 2.10 Are there any existing specifications that might be rendered obsolete, deprecated, or in need of revision as a result of this work?No 2.11 Please describe the anticipated schedule for the development of this specification.TBD (based on schedule for the JSR for JavaTM Language Metadata). 2.12 Please describe the anticipated working model for the Expert Group working on developing this specification.A dedicated mailing list. 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.1. JSR 175 for Java Language Metadata 3.2 Explanation of how these items might be used as a starting point for the work.The existing standards 2-6 above provide the necessary technologies to build interoperable web services. The goal of this JSR is to leverage the first standard, JavaTM Language Metadata, to provide a standard that simplifies development of the commonly required web services idioms made possible by the other standards. This specification will not define any innovations at lower levels of the web services stack: the primary goal is simplify development of robust, maintainable, and interoperable web services using existing standards. In investigating deployment models for JWS, the expert group will determine the extent to which this specification should refer and relate to JSR-088. Existing implementations such as 9 and 10 achieve several of the goals of this JSR and will provide a starting point for the specification. Section 4: Additional Information (Optional)
4.1 This section contains any additional information that the submitting Member wishes to include in the JSR.None |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
