 
Use of JCP site is subject to the
JCP Terms of Use and the
Oracle Privacy Policy
 |
|
 JSRs: Java Specification Requests
JSR 267: JSP Tag Library for Web Services
This JSR has been Withdrawn
Identification |
Request |
Contributions
Section 1. Identification Submitting Member: Sun Microsystems, Inc Name of Contact Person: Dhiru Pandey E-Mail Address: dhiru.pandey@sun.com Telephone Number: +1 408 276 4405 Fax Number: +1 408 276 7191 Specification Lead: Dhiru Pandey & Pierre Delisle E-Mail Address: dhiru.pandey@sun.com & pierre.delisle@sun.com Telephone Number: +1 408 276 4405 & +1 408 276 7056 Fax Number: +1 408 276 7191 Initial Expert Group Membership: * TBD Supporting this JSR: * JBoss Section 2: Request
2.1 Please describe the proposed Specification:This JSR requests the creation of a standard JSP tag library for accessing Web Services. Web Services have enabled a distributed computing environment in which any application or application component can interoperate seamlessly in a platform and language neutral fashion as long as they are network accessible. Most of this is possible because the Web Services stack uses standard web protocols and technologies: SOAP, WSDL, XML, and HTTP. JavaServer Pages (JSP) is an extremely popular server side web development technology. JavaServer Pages (JSP) technology lets you rapidly develop and easily maintain, information-rich, dynamic Web pages. JSP pages contain display markup and tags that encapsulate the logic for generating dynamic content. JSP technology includes some standard tags and support for creating custom tags. A JSP tag library for Web Services is a happy union of the two technologies that will help JSP page authors integrate Web Services into their web applications with minimal effort and quick turnaround times. In addition to existing standards for both Web Services and JSP technologies, there is industry wide acceptance and widespread usage of both the technologies. All of these facts make a compelling case for creating a standard for this tag library. Currently, there are two main approaches used in JSP tag libraries for accessing Web Services: * Generic Tag Library: A generic tag library that can access any Web Service. The web service to be accessed is first declared (through its own tag or configuration in the deployment descriptor) with information such as the WSDL, service name, and port name. Then this web service can be accessed through an invoke action, specifying the web service (previously declared), operation name, and input parameters. For example:
.....
<ws:invoke var="temperature" ws="cityweather" operationName="getTemp">
<h2> Current temperature is : ${temperature}° F</h2> We will consider supporting the client programming model of JSR-109 for referencing a web service in a JSP. This mode of operation can be used for deployment on J2EE compliant containers. JSR-109 specification requires that a client uses JNDI lookup to access a Service object that implements the Service Interface as defined by the JAX-RPC specification. The Service object is a factory used by the client to get a stub or proxy that implements the Service Endpoint Interface. The stub is the client representation of an instance of the Web service. The deployment descriptors would contain the mapping between the JNDI name of the Web Service and the actual location of the WSDL and other Web Service details. * Custom JSP tag library for a specific Web Service: In this approach, a custom JSP tag library is created for a specific Web Service. Typically, a tool is used to create this tag library and the tool uses the WSDL for the Web Service as an argument to create the tag library. An example of this is shown below (using custom tags for Amazon's search web service):
<html> ...... This JSR will standardize a tag library for the usage model outlined in the first approach. For the second approach, we will evaluate if it is appropriate to create a standard that specifies the rules for mapping a WSDL for a Web Service into a JSP tag library. If it is deemed appropriate, then a future version of this JSR will address the creation of a standard for this. It is understood that the implementation work behind the tag handlers offered in this tag library may potentially be reused by other environments like JSF and tools. In that spirit, the JSR will explore the specification of a middle tier API that could be leveraged by this tag library and environments like JSF and tools. We will also ensure that this standardized tag library works well with JavaServer Faces (JSF) technology. Creation of tag library validators will also be investigated to enforce correctness and constraints on the usage of these tag libraries. A future version of this JSR will investigate the use of JSP as a mechanism to define simple Web Services (that may be an aggregation of other Web Services). While this JSR deals with creation of a JSP tag library for Web Services, it is not part of the JSTL specification. If this JSR were a part of JSTL then it will have to follow the release schedules for J2EE platform, which may limit options for early release of this specification. Having a separate JSR for this will allow us the flexibility and expediency with the timelines and future revisions of this JSR. Once this tag library is mature, the intent is to fold it into JSTL. 2.2 What is the target Java platform? (i.e., desktop, server, personal, embedded, card, etc.)JavaTM 2 Platform, Enterprise Edition (J2EE) 1.4. 2.3 The Executive Committees would like to ensure JSR submitters think about how their proposed technology relates to all of the Java platform editions. Please provide details here for which platform editions are being targeted by this JSR, and how this JSR has considered the relationship with the other platform editions.This specification targets the J2EE 1.4 Platform. It will be based on the corresponding release of the J2SE platform. 2.4 Should this JSR be voted on by both Executive Committees?No 2.5 What need of the Java community will be addressed by the proposed specification?This JSR will address the need of the Java community for a standardized Web Services tag library. 2.6 Why isn't this need met by existing specifications?There is no existing standard for accessing Web Services through JSP pages. There are different and diverse methodologies used by tools and server side technology vendors (Application Server/Web Server) to achieve this. A standard in this area is needed and would be useful to JSP page authors. 2.7 Please give a short description of the underlying technology or technologies:See 2.1 above. 2.8 Is there a proposed package name for the API Specification? (i.e., javapi.something, org.something, etc.)We propose using the URI http://java.sun.com/jsp/jstl/ws for this tag library. The use of jstl in the URI may appear confusing at first as this tag library is not part of the JSTL specification. However, once this tag library is mature, the intent is to fold it into JSTL. Using this URI ensures a smooth transition to JSTL in the future. It is not clear if any APIs will need to be exposed by this JSR. If some APIs do need to be exposed, we propose using javax.servlet.jsp.jstl.ws.*. Same comment as above regarding the use of jstl in the package name. 2.9 Does the proposed specification have any dependencies on specific operating systems, CPUs, or I/O devices that you know of?No 2.10 Are there any security issues that cannot be addressed by the current security model?No 2.11 Are there any internationalization or localization issues?Maybe. JSTL already provides a comprehensive set of actions to support internationalization of web applications. However, in light of the facts presented in the paper on Web Services Internationalization Usage Scenarios referenced in section 3.1, we will need to investigate and revisit this area to ensure that adequate support for i18n is provided. 2.12 Are there any existing specifications that might be rendered obsolete, deprecated, or in need of revision as a result of this work?No 2.13 Please describe the anticipated schedule for the development of this specification.The following dates are preliminary:
* Expert Group Formation: January 2005 2.14 Please describe the anticipated working model for the Expert Group working on developing this specification.It is our goal to make the work of the expert group as transparent as possible to the community. We will use the same communication model used by the JSP and JSTL expert groups. A public project within the JSR community at http://java.net will allow us to keep the community informed of our progress in this JSR. The work with the expert group will be driven mostly through e-mail communications and the use of an EG private project at http://java.net. 2.15 It is important to the success of the community and each JSR that the work of the Expert Group be handled in a manner which provides the community and the public with insight into the work the Expert Group is doing, and the decisions that the Expert Group has made. The Executive Committees would like to ensure Spec Leads understand the value of this transparency and ask that each JSR have an operating plan in place for how their JSR will address the involvement of the community and the public. Please provide your plan here, and refer to the Spec Lead Guide for a more detailed description and a set of example questions you may wish to answer in your plan.In order to achieve transparency in the development of this specification, we plan to create a public project at http://java.net to keep members of the community informed about the work performed in this JSR. The plan is to host the following tools in this public project to make this process transparent and involve the community:
* Community pages will be maintained within the project to provide general information on the JSR and its current status 2.16 Please describe how the RI and TCK will de delivered, i.e. as part of a profile or platform edition, or stand-alone, or both. Include version information for the profile or platform in your answer.Sun will deliver a Reference Implementation (RI) and Technology Compatibility Kit (TCK) in a stand-alone form. 2.17 Please state the rationale if previous versions are available stand-alone and you are now proposing in 2.13 to only deliver RI and TCK as part of a profile or platform edition (See sections 1.1.5 and 1.1.6 of the JCP 2 document).N/A 2.18 Please provide a description of the business terms for the Specification, RI and TCK that will apply when this JSR is final.The JSP Tag Library for Web Services Reference Implementation is free to use and redistribute commercially in non modifiable binary form. The Reference Implementation source code will made available under the terms of Java Distribution License (JDL). The TCK for JSP Tag Library for Web Services is available at no extra charge to J2EE Licensees with an amendment to their existing agreements or separately for Sun's standard fee for individual technologies. Qualified individuals and not for profit organizations will receive access to the TCK at no charge. 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.* JSTL 1.1 - JSP Standard Tag Library. http://java.sun.com/products/jsp/jstl/ 3.2 Explanation of how these items might be used as a starting point for the work.The JSTL 1.1 specification will be used as a model for the design of this tag library. |
