jst/components/ws/designs/89083.xml - www.eclipse.org/webtools - Git at Google

 <?xml version="1.0" encoding="utf-8"?>
 <?xml-stylesheet type="text/xsl" href="../../../../wtp.xsl"?>

 <html>
 <head>
 <meta name="root" content="../../../../../" />
 <title>JST Web Services Design Documents</title>
 </head>
 <body>

 <h1>Design document for the Web Services Wizard Framework</h1>

 <h2>Credits</h2>

 <table cellspacing="5" cellpadding="2" border="1">
 <tr valign="top">
 <td>Enhancement</td>
 <td>
 <a
 	href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=89082">
 	89082
 </a>
 <br/>
 <a
 	href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=89083">
 	89083
 </a>
 </td>
 </tr>
 <tr valign="top">
 <td>Version</td>
 <td>1.0 Draft</td>
 </tr>
 <tr valign="top">
 <td>Last Updated</td>
 <td>2005.03.21</td>
 </tr>
 <tr valign="top">
 <td>Target Release</td>
 <td>WTP 1.0</td>
 </tr>
 <tr valign="top">
 <td>Target Milestone</td>
 <td>M4</td>
 </tr>
 <tr valign="top">
 <td>Contributors</td>
 <td>
 Gilbert Andrews<br/>
 Chris Brealey<br/>
 Kathy Chan<br/>
 Rupam Kuehner<br/>
 Peter Moogk<br/>
 Seng Phung-Lu<br/>
 </td>
 </tr>
 </table>

 <h2>Index</h2>

 <ol>
 <li><a href="#overview">Overview</a></li>
 <li><a href="#requirements">Requirements</a></li>
 	<ol>
 	<li><a href="#r1">R1 - End to end Web service (client) wizards</a></li>
 	<li><a href="#r2">R2 - Web service runtime extensibility</a></li>
     <li><a href="#r3">R3 - Web service implementation extensibility</a></li>
 	<li><a href="#r4">R4 - Web service test extensibility</a></li>
 	<li><a href="#r5">R5 - Web service publish extensibility</a></li>
 	</ol>
 <li><a href="#concepts">Conceptual Design</a></li>
 <li><a href="#details">Detailed Design</a></li>
 </ol>

 <h2><a name="overview"/>1.0 - Overview</h2>

 <p>
 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.
 </p>

 <h2><a name="requirements"/>2.0 - Requirements</h2>


 <h3><a name="r1"/>R1 - End to end Web service (client) wizards</h3>
 <p>
 End users of WTP can use the Web service (client) wizards
 to discover, develop, assemble, deploy, install, run, and test
 Web services (clients).
 </p>

 <h3><a name="r2"/>R2 - Web service runtime extensibility</h3>
 <p>
 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.
 </p>

 <h3><a name="r3"/>R3 - Web service implementation extensibility</h3>
 <p>
 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.
 </p>

 <h3><a name="r4"/>R4 - Web service test extensibility</h3>
 <p>
 Extenders of WTP can contribute Web service (client) test
 facilities to the Web service (client) wizard along with
 associated wizard pages.
 </p>

 <h3><a name="r5"/>R5 - Web service publish extensibility</h3>
 <p>
 Extenders of WTP can contribute Web service publish facilities
 to the Web service wizard along with associated wizard pages.
 </p>

 <h2><a name="concepts"/>3.0 - Conceptual Design</h2>

 <p>
 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.
 <br/><br/>
 <ul>
 <li><b>Discover:</b><br/>
 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.
 </li>
 <br/>
 <br/>
 <li><b>Develop:</b><br/>
 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.
 </li>
 <br/>
 <br/>
 <li><b>Assemble:</b> <br/>
 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.
 </li>
 <br/>
 <br/>
 <li><b>Deploy:</b><br/>
 Generate the deploy artifacts. Framework delegates entirely to the
 Web service runtime extension.
 </li>
 <br/>
 <br/>
 <li><b>Install:</b><br/>
 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.
 </li>
 <br/>
 <br/>
 <li><b>Run:</b><br/>
 Start the Web service (client) by starting the server. Specific tasks? Not sure.
 </li>
 <br/>
 <br/>
 <li><b>Test:</b><br/>
 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.
 </li>
 <br/>
 <br/>
 <li><b>Publish:</b><br/>
 Publish the Web service. Framework allows the user to choose from an
 extensible list of publish facilities (e.g. Web services explorer).
 </li>
 <br/>
 <br/>
 <li><b>Announce:</b><br/>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.
 </li>
 </ul>

 <hr WIDTH="100%"/>
 <br/>
 <b>3.1 WebServiceRuntime Extension Point</b>
 <br/>
 <br/>
 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.)
 <p><img src="89083/WSRTExtensionXML.jpg" height="540" width="720"></img></p>
 <p>
 <ul>
 <li><b>org.eclipse.jst.ws.wsImpl</b> - extend to contribute implementation types of
 Web services WTP comes with Java bean and EJB implementation extensions defined. </li>
 <li><b>org.eclipse.jst.ws.wsClientImpl</b> - extend to contribute implementation types
 of Web service clients. WTP comes with the Java proxy extension defined.</li>
 <li><b>org.eclipse.jst.ws.serviceType</b> - extend to contribute a unique combination
 of a Web service implementation type and Web service creation scenarios: bottom-up
 and top-down.
 <ul>
 <li>implId: is the id of the org.eclipse.jst.ws.wsImpl extension this serviceType
 supports</li>
 <li>buModuleTypes: a list of ids representing the module types
 this serviceType supports for bottom-up Web service creation.</li>
 <li>tdModuleTypes: a list of ids representing the module types
 this serviceType supports for top-down Web service creation.</li>
 </ul>
 </li>
 <li><b>org.eclipse.jst.ws.clientType</b> - extend to identify module types that
 support a Web service client implementation type
 <ul>
 <li>implId: is the id of the org.eclipse.jst.ws.wsClientImpl extension this clientType
 supports</li>
 <li>moduleTypes: a list of ids representing the module types
 this clientType supports</li>
 </ul>
 </li>
 <li><b>org.eclipse.jst.ws.webServiceRuntime</b> - extend to contribute a Web service runtime(WSRT)
 <ul>
 <li><b>label</b> - the translatable label for this WSRT.</li>
 <li><b>serviceTypes</b> - 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. </li>
 <li><b>clientTypes</b> - 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.</li>
 <li><b>servletLevels</b> - 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.</li>
 <li><b>j2eeLevels</b> - 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. </li>
 <li><b>runtimes</b> - 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.</li>
 <li><b>servers</b> - 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.</li>
 <li><b>class</b> - 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.
 <p><img SRC="89083/diagramW-wsrt.jpeg" height="441" width="548"/></p>
 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.
 <p><img src="89083/diagramB-ws.jpeg" height="640" width="690"/></p>
 </li>
 </ul>
 </li>
 </ul>
 </p>

 <hr WIDTH="100%"/>
 <br/>
 <b>3.2 Discovery Extension point</b>
 <br/>
 <br/>
 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.
 <p><img SRC="89083/DiscoveyDiagram.jpg" height="540" width="720"/></p>

 <hr WIDTH="100%"/>
 <br/>
 <b>3.3 Test Extension point</b>
 <br/>
 <br/>
 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).
 <ul>
 <li><b>id</b> - a unique id</li>
 <li><b>label</b> - a translatable label</li>
 <li><b>testWSDL</b> - "yes" if this test facility can test a Web service with only the WSDL
 as input. "no" otherwise.</li>
 <li><b>wsClientImplIds</b> - 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.</li>
 <li><b>moduleTypes</b> - 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. </li>
 <li><b>methodsNeeded</b> - "yes" if this test facility needs as input
 the list of operations/methods to be tested.</li>
 <li><b>class</b> - 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.</li>
 </ul>
 <p><img SRC="89083/TesterDiagram.jpg" height="540" width="720"/></p>
 <hr WIDTH="100%"/>
 <br/>
 <b>3.4 Publish Extension point</b>
 <br/>
 <br/>
 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)
 <ul>
 <li><b>id</b> - a unique id </li>
 <li><b>label</b> - a translatable label </li>
 <li><b>class</b> - 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. </li>
 </ul>

 <p><img SRC="89083/PublisherDiagram.jpg" height="540" width="720"/></p>


 <hr WIDTH="100%"/>
 >>Coming soon....<br/>
 <ul>
 <li>How the framework allows Web service runtimes to provide wizard pages</li>
 </ul>
 </p>

 <h2><a name="details"/>4.0 - Detailed Design</h2>

 <p>
 Write any detailed, internal design material here.
 </p>

 </body>
 </html>
	<?xml version="1.0" encoding="utf-8"?>
	<?xml-stylesheet type="text/xsl" href="../../../../wtp.xsl"?>

	<html>
	<head>
	<meta name="root" content="../../../../../" />
	<title>JST Web Services Design Documents</title>
	</head>
	<body>

	<h1>Design document for the Web Services Wizard Framework</h1>

	<h2>Credits</h2>

	<table cellspacing="5" cellpadding="2" border="1">
	<tr valign="top">
	<td>Enhancement</td>
	<td>
	<a
	href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=89082">
	89082
	</a>
	<br/>
	<a
	href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=89083">
	89083
	</a>
	</td>
	</tr>
	<tr valign="top">
	<td>Version</td>
	<td>1.0 Draft</td>
	</tr>
	<tr valign="top">
	<td>Last Updated</td>
	<td>2005.03.21</td>
	</tr>
	<tr valign="top">
	<td>Target Release</td>
	<td>WTP 1.0</td>
	</tr>
	<tr valign="top">
	<td>Target Milestone</td>
	<td>M4</td>
	</tr>
	<tr valign="top">
	<td>Contributors</td>
	<td>
	Gilbert Andrews<br/>
	Chris Brealey<br/>
	Kathy Chan<br/>
	Rupam Kuehner<br/>
	Peter Moogk<br/>
	Seng Phung-Lu<br/>
	</td>
	</tr>
	</table>

	<h2>Index</h2>

	<ol>
	<li><a href="#overview">Overview</a></li>
	<li><a href="#requirements">Requirements</a></li>
	<ol>
	<li><a href="#r1">R1 - End to end Web service (client) wizards</a></li>
	<li><a href="#r2">R2 - Web service runtime extensibility</a></li>
	<li><a href="#r3">R3 - Web service implementation extensibility</a></li>
	<li><a href="#r4">R4 - Web service test extensibility</a></li>
	<li><a href="#r5">R5 - Web service publish extensibility</a></li>
	</ol>
	<li><a href="#concepts">Conceptual Design</a></li>
	<li><a href="#details">Detailed Design</a></li>
	</ol>

	<h2><a name="overview"/>1.0 - Overview</h2>

	<p>
	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.
	</p>

	<h2><a name="requirements"/>2.0 - Requirements</h2>



	<h3><a name="r1"/>R1 - End to end Web service (client) wizards</h3>
	<p>
	End users of WTP can use the Web service (client) wizards
	to discover, develop, assemble, deploy, install, run, and test
	Web services (clients).
	</p>

	<h3><a name="r2"/>R2 - Web service runtime extensibility</h3>
	<p>
	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.
	</p>

	<h3><a name="r3"/>R3 - Web service implementation extensibility</h3>
	<p>
	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.
	</p>

	<h3><a name="r4"/>R4 - Web service test extensibility</h3>
	<p>
	Extenders of WTP can contribute Web service (client) test
	facilities to the Web service (client) wizard along with
	associated wizard pages.
	</p>

	<h3><a name="r5"/>R5 - Web service publish extensibility</h3>
	<p>
	Extenders of WTP can contribute Web service publish facilities
	to the Web service wizard along with associated wizard pages.
	</p>

	<h2><a name="concepts"/>3.0 - Conceptual Design</h2>

	<p>
	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.
	<br/><br/>
	<ul>
	<li><b>Discover:</b><br/>
	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.
	</li>
	<br/>
	<br/>
	<li><b>Develop:</b><br/>
	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.
	</li>
	<br/>
	<br/>
	<li><b>Assemble:</b> <br/>
	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.
	</li>
	<br/>
	<br/>
	<li><b>Deploy:</b><br/>
	Generate the deploy artifacts. Framework delegates entirely to the
	Web service runtime extension.
	</li>
	<br/>
	<br/>
	<li><b>Install:</b><br/>
	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.
	</li>
	<br/>
	<br/>
	<li><b>Run:</b><br/>
	Start the Web service (client) by starting the server. Specific tasks? Not sure.
	</li>
	<br/>
	<br/>
	<li><b>Test:</b><br/>
	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.
	</li>
	<br/>
	<br/>
	<li><b>Publish:</b><br/>
	Publish the Web service. Framework allows the user to choose from an
	extensible list of publish facilities (e.g. Web services explorer).
	</li>
	<br/>
	<br/>
	<li><b>Announce:</b><br/>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.
	</li>
	</ul>

	<hr WIDTH="100%"/>
	<br/>
	<b>3.1 WebServiceRuntime Extension Point</b>
	<br/>
	<br/>
	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.)
	<p><img src="89083/WSRTExtensionXML.jpg" height="540" width="720"></img></p>
	<p>
	<ul>
	<li><b>org.eclipse.jst.ws.wsImpl</b> - extend to contribute implementation types of
	Web services WTP comes with Java bean and EJB implementation extensions defined. </li>
	<li><b>org.eclipse.jst.ws.wsClientImpl</b> - extend to contribute implementation types
	of Web service clients. WTP comes with the Java proxy extension defined.</li>
	<li><b>org.eclipse.jst.ws.serviceType</b> - extend to contribute a unique combination
	of a Web service implementation type and Web service creation scenarios: bottom-up
	and top-down.
	<ul>
	<li>implId: is the id of the org.eclipse.jst.ws.wsImpl extension this serviceType
	supports</li>
	<li>buModuleTypes: a list of ids representing the module types
	this serviceType supports for bottom-up Web service creation.</li>
	<li>tdModuleTypes: a list of ids representing the module types
	this serviceType supports for top-down Web service creation.</li>
	</ul>
	</li>
	<li><b>org.eclipse.jst.ws.clientType</b> - extend to identify module types that
	support a Web service client implementation type
	<ul>
	<li>implId: is the id of the org.eclipse.jst.ws.wsClientImpl extension this clientType
	supports</li>
	<li>moduleTypes: a list of ids representing the module types
	this clientType supports</li>
	</ul>
	</li>
	<li><b>org.eclipse.jst.ws.webServiceRuntime</b> - extend to contribute a Web service runtime(WSRT)
	<ul>
	<li><b>label</b> - the translatable label for this WSRT.</li>
	<li><b>serviceTypes</b> - 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. </li>
	<li><b>clientTypes</b> - 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.</li>
	<li><b>servletLevels</b> - 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.</li>
	<li><b>j2eeLevels</b> - 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. </li>
	<li><b>runtimes</b> - 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.</li>
	<li><b>servers</b> - 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.</li>
	<li><b>class</b> - 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.
	<p><img SRC="89083/diagramW-wsrt.jpeg" height="441" width="548"/></p>
	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.
	<p><img src="89083/diagramB-ws.jpeg" height="640" width="690"/></p>
	</li>
	</ul>
	</li>
	</ul>
	</p>

	<hr WIDTH="100%"/>
	<br/>
	<b>3.2 Discovery Extension point</b>
	<br/>
	<br/>
	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.
	<p><img SRC="89083/DiscoveyDiagram.jpg" height="540" width="720"/></p>

	<hr WIDTH="100%"/>
	<br/>
	<b>3.3 Test Extension point</b>
	<br/>
	<br/>
	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).
	<ul>
	<li><b>id</b> - a unique id</li>
	<li><b>label</b> - a translatable label</li>
	<li><b>testWSDL</b> - "yes" if this test facility can test a Web service with only the WSDL
	as input. "no" otherwise.</li>
	<li><b>wsClientImplIds</b> - 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.</li>
	<li><b>moduleTypes</b> - 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. </li>
	<li><b>methodsNeeded</b> - "yes" if this test facility needs as input
	the list of operations/methods to be tested.</li>
	<li><b>class</b> - 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.</li>
	</ul>
	<p><img SRC="89083/TesterDiagram.jpg" height="540" width="720"/></p>
	<hr WIDTH="100%"/>
	<br/>
	<b>3.4 Publish Extension point</b>
	<br/>
	<br/>
	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)
	<ul>
	<li><b>id</b> - a unique id </li>
	<li><b>label</b> - a translatable label </li>
	<li><b>class</b> - 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. </li>
	</ul>

	<p><img SRC="89083/PublisherDiagram.jpg" height="540" width="720"/></p>



	<hr WIDTH="100%"/>
	>>Coming soon....<br/>
	<ul>
	<li>How the framework allows Web service runtimes to provide wizard pages</li>
	</ul>
	</p>

	<h2><a name="details"/>4.0 - Detailed Design</h2>

	<p>
	Write any detailed, internal design material here.
	</p>

	</body>
	</html>