• 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
	Jitendra Kotamraju	Oracle
Expert Group
	Art Technology Group Inc.(ATG)	BEA Systems	Borland Software Corporation
	Cisco Systems	Developmentor	EDS
	Hewlett-Packard	IBM	Informix Software
	Interwoven	Macromedia, Inc.	Motorola
	Novell, Inc.	Oracle	Progress Software
	SAP SE	Software AG	Sonic Software
	Sun Microsystems, Inc.	Sybase	WebGain

Updates to the Original JSR

The following has been updated from the original JSR:

2013.02.19:

Martin Grebac is the Maintenance Lead for JSR 109.

Maintenance Lead: Martin Grebac

E-Mail Address: martin.grebac@oracle.com

Telephone Number: +420 221 438 700

2007.11.02:

Jitendra Kotamraju is the Maintenance Lead for JSR 109.

Maintenance Lead: Jitandra Kotamraju

E-Mail Address: jitendra.kotamraju@sun.com

Telephone Number: +1 408 276 7298

Fax Number: +1 408 276 7191

2005.06.08:

The Maintenance Lead changed from IBM to Sun Microsystems on 2005.06.08. The JCP version changed from 2.1 to 2.6 on that same date.

Maintenance Lead: Dhiru Pandey

E-Mail Address: dhiru.pandey@sun.com

Telephone Number: +1 408 276 4405

Fax Number: +1 408 276 7191

Identification | Request | Contributions

Section 1. Identification

Submitting Member: IBM Corporation

Name of Contact Person: Donald Ferguson

E-Mail Address: dff@us.ibm.com

Telephone Number: 914-766-1154

Fax Number: 914-766-8124

Specification Lead: Jim Knutson

E-Mail Address: knutson@us.ibm.com

Telephone Number: +1 1 512 838 1655

Fax Number: +1 512 838 1032

This information has been updated from the original JSR.

Initial Expert Group Membership:
(Please provide company or organization names. Note that expert group members must have signed the JSPA.)

IBM Corporation

Section 2: Request

2.1 Please describe the proposed Specification:

This specification defines the programming model and architecture for implementing web services in Java. The specification will build on the work of JSRs 67, 93 and 101. The specification will also build on the JSRs for J2EE technologies, including J2EE itself, Servlets and JSPs. The intent of this JSR is not to subsume J2EE JSR's role nor to define a platform. We also do not pre-suppose that this JSR's output will become part of J2EE. Selecting this JSR's output, in whole or in part, for inclusion in J2EE will be decided within the J2EE JSR process.

JSR 101 focuses on XML RPC and the Java language, including representing XML based interface definitions in Java, Java definitions in XML based interface definition languages (e.g. SOAP) and marshalling. JSR 67 provides similar functions for XML messaging.

JSR 93 defines the Java interfaces to XML registries, like JNDI, ebXML and UDDI. These interfaces provide the mechanism through which client applications find web services and web services (and servers) publish their interfaces.

This JSR's objective is provide a programming model and runtime model for web services based on JSRs 67, 93 and 101 and future JSRs oriented toward individual web services standards, similar to what the EJB specification did for RMI (RMI-IIOP) and JNDI. This is an analogy only, and this JSR will build on but not extend the EJB specification.

Specifically, we will focus this JSR on:

This JSR would provide documentation on the programming model, APIs and runtime service model. It would provide a reference implementation for any J2EE compliant application server and would have open source test cases for interoperability and compliance. The specification would rely on the existing J2EE application packaging.

Some sample questions that this JSR might answer are:

2.2 What is the target Java platform? (i.e., desktop, server, personal, embedded, card, etc.)

This specification targets the J2EE platform.

2.3 What need of the Java community will be addressed by the proposed specification?

Over the past several years and with the aid of many vendors, J2EE has become the platform of choice for developing web-based business applications. With the assistance of major standards bodies such as the WorldWide Web Consortium(W3C), the ebXML group, and the UDDI organization, standards are being developed for dynamically publishing, finding and binding to business applications over the web. These business applications may be written in Java or in any other programming language, but as long as they follow the appropriate standards they can participate as web services. It is very important to the Java community that Java application programmers have a common model for writing and running web services under J2EE. It is important that there is a consistent Java model for accessing and using interfaces and services that public web services protocols define. This includes those that exist today (for example SOAP RPC, SOAP messaging, and WSDL) and those that are currently under development in such areas as security, trust and systems management.

This specification does not encroach on the overall coordination mission of J2EE JSRs. This specification seeks to define APIs that programmers use, base types programmers extend and a common runtime mapping of web services interface definition languages and services (e.g. Security, SOAP Attachments).

2.4 Why isn't this need met by existing specifications?

Specifications have been opened for defining APIs to parts web services, such as JSR 67 (Java APIs for XML Messaging), JSR 93 (Java APIs for XML Registry) and JSR 101 (Java APIs for XML-Based RPC). Much in the same way that Servlets tied together a set of concepts like cookies and HttpSession, and EJB tied together RMI, JTA/JTS, JDBC, etc. with a programming model and runtime model, we view this JSR doing the same for implementing and using web services.

2.5 Please give a short description of the underlying technology or technologies:

This is covered in section 2.1.

2.6 Is there a proposed package name for the API Specification? (i.e., javapi.something, org.something, etc.)

To be determined

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. We believe that this JSR will define how to integrate the existing J2EE/Java security model with the Internet security models, like Digital Signatures.

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?

No.

2.11 Please describe the anticipated schedule for the development of this specification.

• Community Draft submitted to PMO: August, 2001
• Public Draft submitted to PMO: November, 2001
• Proposed Final Draft submitted to PMO: February, 2002

2.12 Working style for the expert group.

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. Existing J2EE specifications
2. Universal Description, Discovery, and Integration (UDDI) Programmer's Specification
3. W3 XMP Protocol group
4. Web Services Definition Language (WSDL) 1.0
5. Simple Object Access Protocol (SOAP) 1.1
6. ebXML Technical Specifications
7. Java( TM) APIs for XML Messaging 1.0
8. Java( TM) APIs for XML Registries 1.0
9. Java (TM) APIs for XML RPC

3.2 Explanation of how these items might be used as a starting point for the work.

These are some of the specifications that the expert group will need to consider when it is defining Java APIs to web services, since the web services specifications themselves are being defined by standards bodies other than the JCP.

The purpose of the expert group is to take advantage of the excellent work that is going on in the standards bodies listed above by defining APIs and thin bindings that make these standards easily accessable to and exploitable by the Java programmer. The intent is not to duplicate work going on in these standards bodies but to make such work available in an orderly and expeditious fashion to the Java programming community.