Related link: http://jcp.org/jsr/detail/109.jsp

The following JSR is pending final approval, as excerpted from jcp.org.

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.