Alan Mullendore

BEA Systems

 

BEA Systems		Bossons, John		Harby, John
IBM		Motorola		Nokia Corporation
Oracle		PalmSource, Inc.		Pollack, Mark
Pramati Technologies		Research In Motion, LTD (RIM)		SAP AG
SeeBeyond Technology Corp.		Sun Microsystems, Inc.

Expert Group Private Page

JSR Community Update Page

 

Updates to the Original JSR

The following updates were made to the original proposal.

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 Java^TM Platform will build on the Java^TM 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 Java^TM 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 Java^TM 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:

Java^TM Language Metadata is a recently submitted JSR that provides a standard model for annotating Java code, of which Web Services Metadata for the Java^TM Platform will be one application.

Javadoc is a standard syntax for structured comments that was introduced in the first version of the Java^TM Language Specification, and may be related to Java^TM 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 Java^TM 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, Java^TM 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