Find JSRs
Submit this Search


Ad Banner
 
 
 
 

Summary  |  Proposal  |  Detail (Summary & Proposal)
JSRs: Java Specification Requests
JSR 181: Web Services Metadata for the JavaTM Platform

Stage Access Start Finish
Maintenance Release 2 Download page 18 Jun, 2013  
Maintenance Draft Review 3 Download page 12 May, 2009 15 Jun, 2009
Maintenance Release Download page 27 Jun, 2006  
Maintenance Draft Review 2 Download page 30 Mar, 2006 01 May, 2006
Maintenance Draft Review Download page 23 Dec, 2005 23 Jan, 2006
Final Release Download page 27 Jun, 2005  
Final Approval Ballot View results 29 Mar, 2005 11 Apr, 2005
Proposed Final Draft Download page 18 Feb, 2005  
Public Review Ballot View results 19 Oct, 2004 25 Oct, 2004
Public Review Download page 20 Sep, 2004 25 Oct, 2004
Early Draft Review Download page 11 May, 2004 10 Jun, 2004
Expert Group Formation   16 Apr, 2002 26 Dec, 2003
JSR Review Ballot View results 02 Apr, 2002 15 Apr, 2002
Status: Active
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

Specification Leads
  Alan Mullendore Oracle
Expert Group
  BEA Systems Bossons, John Harby, John
  IBM Motorola Nokia Corporation
  Oracle PalmSource, Inc. Pollack, Mark
  Pramati Technologies Research In Motion, LTD (RIM) SAP AG
  Sun Microsystems, Inc.

Updates to the Original JSR

The following updates were made to the original proposal.

2009.05.01:
The Maintenance Lead changed to Oracle:

Specification Lead: Alan Mullendore

E-Mail Address: alan.mullendore@oracle.com

Telephone Number: -

Fax Number: -

2005.09.15:
The Maintenance Lead changed:

Specification Lead: Stuart Edmondston

E-Mail Address: stuart.edmondston@bea.com

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
Borland
IONA Technology
Sun Microsystems

Supporting this JSR:

BEA Systems
Borland
IONA Technology
Sun Microsystems>



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.
JSR-101, which focuses on web services APIs.
The above specifications describe fully generalized APIs that can be used for development of a very wide range of types of web services. In contrast, the primary purpose of the the current JSR is to provide a simplified development model for quick and simple development of the commonly needed forms of 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.
Monthly conference calls.
Face-to-face meetings each quarter.





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
2. WSDL 1.1
3. SOAP 1.1
4. Schema 1.0
5. JSR-109
6. JSR-101
7. Existing J2EE specifications.
8. JSR-088
9. Apache AXIS "JWS" drop-in deployment of web services
10. BEA WebLogic Workshop "JWS" annotated java web services

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