|
|
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.
|
|
|
End users of WTP can use the Web service (client) wizards
to discover, develop, assemble, deploy, install, run, and test
Web services (clients).
|
|
|
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.
|
|
|
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
|
