Design document for the Web Services Wizard Framework
JST Web Services Design Documents
Credits
 
Enhancement 89082
89083
Version 1.0 Draft
Last Updated 2005.03.21
Target Release WTP 1.0
Target Milestone M4
Contributors Gilbert Andrews
Chris Brealey
Kathy Chan
Rupam Kuehner
Peter Moogk
Seng Phung-Lu
Index
 
  1. Overview
  2. Requirements
    1. R1 - End to end Web service (client) wizards
    2. R2 - Web service runtime extensibility
    3. R3 - Web service implementation extensibility
    4. R4 - Web service test extensibility
    5. R5 - Web service publish extensibility
  3. Conceptual Design
  4. Detailed Design
1.0 - Overview
 

The Web service tools in the WTP provide extensible Web service (and client) wizards that allow end users to create/publish and discover/consume Web services. Much of what the user sees in the wizards including such things as the supported Web service runtimes, servers, J2EE levels, module types, and wizard pages is contributed through extension points. The goal of this document is to present a high-level design of this extensible Web service (client) wizard framework.

2.0 - Requirements
R1 - End to end Web service (client) wizards
 

End users of WTP can use the Web service (client) wizards to discover, develop, assemble, deploy, install, run, and test Web services (clients).

R2 - Web service runtime extensibility
 

Extenders of WTP can contribute Web service runtimes to the Web service (client) wizard along with all the tasks and wizard pages needed to develop, assemble, deploy, install, run, and announce Web services (clients) for a contributed runtime.

R3 - Web service implementation extensibility
 

Extenders of WTP can contribute Web service (client) implementation types to the Web service (client) wizard along with a UI browser to aid the user in locating artifacts of that type.

R4 - Web service test extensibility
 

Extenders of WTP can contribute Web service (client) test facilities to the Web service (client) wizard along with associated wizard pages.

R5 - Web service publish extensibility
 

Extenders of WTP can contribute Web service publish facilities to the Web service wizard along with associated wizard pages.

3.0 - Conceptual Design
 

The Web service (client) wizard framework (called framework from here on) guides users through end-to-end discovery, creation, test, and publish of Web services and Web service clients. The framework divides the process of creating Web services (clients) into nine phases: discover, develop, assemble, deploy, install, run, test, publish, and announce. The activities performed in each of these phases can be further divided into those that are common to all Web service runtimes (generic activities) and those that are specific to each Web service runtime (specific activities). The framework performs the generic activities and delegates to the Web service runtime extension to perform the specific activities. Outlined below is a brief description of each of the nine phases and examples of generic and specific activities.

  • Discover:
    Select the implementation artifact, such as a Java bean or stateless session EJB. The kinds of artifacts available to the user can be extended using the Web services (client) implementation extensibility point. The framework comes with Java Bean and EJB extensions.


  • Develop:
    Develop the WSDL definition and implementation of the Web service. Provide deployment specific information needed by the Deploy phase. Generic activities include the creation of modules which will contain the generated code. Web service runtime extensions should provide the develop tasks specific to the extension.


  • Assemble:
    Assemble and configure modules into a module, such as an EAR, that can be installed on the target server. Generic activities include the association of modules to EARs. Extenders should perform tasks specific to the Web service runtime, such as any additional modules that need to the created and configured and any module dependencies that need to be established.


  • Deploy:
    Generate the deploy artifacts. Framework delegates entirely to the Web service runtime extension.


  • Install:
    Install and configure the module on the target server. Installing the module on the server is a generic activity. Web service runtime specific install tasks might include modifying the server configuration.


  • Run:
    Start the Web service (client) by starting the server. Specific tasks? Not sure.


  • Test:
    Test the Web service (client). Framework allows the user to choose from an extensible list of test facilities. Examples are the Web services explorer and the Generated JSPs.


  • Publish:
    Publish the Web service. Framework allows the user to choose from an extensible list of publish facilities (e.g. Web services explorer).


  • Announce:
    Announce the Web service to the user. Framework has a boiler-plate Announce page that which announces things such as the WSDL URL and endpoint URL. Web service runtime extensions can optionally override this boiler-plate announce page to provide their own.


3.1 WebServiceRuntime Extension Point

A Web service runtime can be loosely defined as a SOAP engine which manages Web services (clients) and also prescribes the manner in which they are to be created (from the develop phase to the run phase). Web service runtime characteristics can vary widely in terms of their supported specification levels (e.g. Servlet, J2EE), Web servers (e.g. Tomcat, JBoss), implementations (e.g. Java bean, EJB) and scenarios (e.g. bottom-up, top-down, client). An extender of WTP can contribute a new Web service runtime to the framework with the following XML (Please note: Element and attribute names are not final. They are for descriptive purposes only.)

  • org.eclipse.jst.ws.wsImpl - extend to contribute implementation types of Web services WTP comes with Java bean and EJB implementation extensions defined.
  • org.eclipse.jst.ws.wsClientImpl - extend to contribute implementation types of Web service clients. WTP comes with the Java proxy extension defined.
  • org.eclipse.jst.ws.serviceType - extend to contribute a unique combination of a Web service implementation type and Web service creation scenarios: bottom-up and top-down.
    • implId: is the id of the org.eclipse.jst.ws.wsImpl extension this serviceType supports
    • buModuleTypes: a list of ids representing the module types this serviceType supports for bottom-up Web service creation.
    • tdModuleTypes: a list of ids representing the module types this serviceType supports for top-down Web service creation.
  • org.eclipse.jst.ws.clientType - extend to identify module types that support a Web service client implementation type
    • implId: is the id of the org.eclipse.jst.ws.wsClientImpl extension this clientType supports
    • moduleTypes: a list of ids representing the module types this clientType supports
  • org.eclipse.jst.ws.webServiceRuntime - extend to contribute a Web service runtime(WSRT)
    • label - the translatable label for this WSRT.
    • serviceTypes - a space separated list of id's of serviceTypes supported by this WSRT. This WSRT will only be shown to the user if it supports the selected Web service implementation type and scenario.
    • clientTypes - a space separated list of id's of clientTypes supported by this WSRT. This WSRT will only be shown to the user if it supports the selected Web service client implementation type.
    • servletLevels - a space separated list of servlet levels supported by this WSRT (e.g. 23 24). Used to determine supported servers if runtimes and servers attributes are missing. The attribute need not be present for WSRT's that support all servlet levels or to which servlet levels do not apply.
    • j2eeLevels - a space separated list of J2EE levels supported by this WSRT (e.g. 13 14). These are exposed as choices to the user and used to determine supported servers if runtimes and servers attributes are missing. The attribute need not be present for WSRT's that support all J2EE levels or to which J2EE levels do not apply.
    • runtimes - a space separated list of id's of runtimes (defined in server APIs) supported by this WSRT. These are used to determine supported servers if the servers attribute is missing.
    • servers - a space separated list of server factory id's (defined in server APIs) supported by this WSRT. These are exposed as choices to the user. Extenders can be as generic or as specific in their specification of servers as they desire. If the WSRT will function on any server that satisfies the servlet and/or J2EE specification levels specified, the best approach may be to omit the runtimes and servers attributes. This causes the framework to expose support for all servers which support the specification levels. If the WSRT specifies specific server factory ids in the servers attribute, the framework will only expose support for those servers.
    • class - the fully qualified name of class which implements IWebServiceRuntime (illustrated below) and has a zero argument constructor. Extenders must implement IWebServiceRuntime by extending AbstractWebServiceRuntime and providing implementations for getWebService(), getWebServiceClient(). They can also override the implementation of the announce(..) method if they wish to override the boiler-plate announce capabilities of the framework.

      Based on the Web service runtime selected by the user, the framework will activate the corresponding extension by constructing the provided class (e.g. FooWebServiceRuntime). It will then obtain an IWebService or IWebServiceClient from this class, to which it will delegate all Web service runtime specific activities in the develop, deploy, assemble, install, and run phases of Web service (client) creation. IWebService is illustrated below. IWebServiceClient is very similar to IWebService, the main difference being that IWebServiceClientInfo does not have an endPointURL field.



3.2 Discovery Extension point

Once the user has chosen the implementation type, the framework requires them to discover and select a suitable artifact to begin creation of the Web service (client). The nature of the artifact being discovered depends on the selected scenario: bottom-up or top-down Web service creation, or client creation. Web service client creation must begin with the discovery of Web services (covered in the Web Service Finder framework). Top down Web service development, by definition, involves starting with WSDL. This is hard-wired into the framework and not something extenders can change. Bottom-up Web service development involves starting with the artifact that implements the Web service. Extenders can contribute new Web service implementation types through the org.eclipse.jst.ws.wsImpl extension point. The org.eclipse.jst.ws.discovery extension point allows the contribution of UI browse mechanisms for Web service implementation types. The platform comes with discovery extensions for Java beans and stateless session EJBs. If the selected implementation type does not have a corresponding discovery extension, the framework will allow the user to select resources in the workspace. The discovery extension point is illustrated below.



3.3 Test Extension point

Once the Web service (client) has been created, the framework gives the user the option of testing it using a test facility of their choice. The test extension point enables the contribution of test facilities to the framework. These are exposed to the user in the wizards and pop-up actions. The platform comes with two test facilities, namely the Web Services Explorer and the Generated Sample JSPs. An extender must provide the following information in the extension XML (also illustrated below).
  • id - a unique id
  • label - a translatable label
  • testWSDL - "yes" if this test facility can test a Web service with only the WSDL as input. "no" otherwise.
  • wsClientImplIds - a space separated list of ids of Web service client implementation types that this test facility can test. The framework will only expose this test facility if the implementation type of the client being tested is in this list.
  • moduleTypes - a space separated list of module type ids. Extensions use this attribute to tell the framework which type(s) of modules its generated artifacts can be put in. For example, JSPs must be put in a Web module.
  • methodsNeeded - "yes" if this test facility needs as input the list of operations/methods to be tested.
  • class - the fully qualified name of a class which implements IWebServiceTester and has a zero argument constructor. If this test facility is selected, the framework will construct this class and call the generate(..) and launch(..) methods to obtain the Commands needed to generate and launch the test facility.



3.4 Publish Extension point

Once the Web service has been created and (optionally) tested, the framework gives the user the option of publishing the Web service using a facility of their choice. Publication refers to the act of making the Web service visible and accessible to a broader internet or intranet audience. The publish extension point enables the contribution of publish facilities to the framework. These are exposed to the user in the wizard. The platform comes with one publication facility, the Web services Explorer, which enables the user to publish to UDDI registries. An extender must provide the following information in the extension XML (also illustrated below)
  • id - a unique id
  • label - a translatable label
  • class - the fully qualified name of a class which implements the IWebServicePublisher interface. If this publication facility is selected, the framework will construct this class and call the publish(..) method to obtain the command needed to publish the Web service.


>>Coming soon....
  • How the framework allows Web service runtimes to provide wizard pages

4.0 - Detailed Design
 

Write any detailed, internal design material here.