Find JSRs
Submit this Search


Ad Banner
 
 
 
 

JSRs: Java Specification Requests
JSR 109: Implementing Enterprise Web Services

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


Original Java Specification Request (JSR)

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:

  • The programming model for implementing a web service. This may include defining a new server side base classes and frameworks, specifying new APIs, defining new concrete subclasses of JSP, Servlet or an existing EJB type like MessageBean. Any extensions would be analogous to HttpServlet extending generic Servlet or the approach the Enterprise MediaBeans takes in defining subtypes of EntityBeans.
  • The client side programming model for using web services from Java. This would be analogous to the client programming model that EJB defines. This would explain how to use the APIs defined in JSRs 67, 93 and 101 in tandem. Again, the intent is to minimize new concepts introduced.
  • The specification would state how existing concepts, like the EJB transaction model, security for Servlets, EJBs, or HttpSession State materialize in web services usage and implementation.
  • Defining how to extend the basic Servlet/HTTP model to include dispatching web services over FTP, e-mail, etc. Again, this ideally references the existing JSRs/Java standards and focuses on the programming model and parts needed to support web services.
  • Define the concrete model for developing and deploying a web service on top of J2EE.

  • 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:

  • What is the lifecycle model for a web service?
  • Are there stateless and stateful web services? How do you implement a stateful EJBs?
  • Do web services have Homes?
  • Is there an EntityBean model for web services?
  • What are the mapping service contexts that flow over ebXML or SOAP to EJB services?
  • Are new server-side classes for web services needed? To what extent can existing J2EE server-side APIs such as EJB and JMS be used for dispatching web service calls? Is subclassing appropriate for web-service specific EJBs, or should web services information go into the EJB deployment descriptor, or are both techniques needed?
  • Are new client-side classes for web services needed? To what extent can web services be invoked using existing J2EE client programming models such as EJB and JMS?
  • 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.

    We anticipate using a collaborative style for the expert group, with regularly-scheduled meetings and a teamroom to facilitate intragroup communication.



    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.