1. Overview
2. Requirements
1. R1 - Find webservices
2. R2 - Provide basic characteristics of webservices found
3. R3 - Allow the ability to easily add new WSDLFinder implementations
3. Conceptual Design
4. Detailed Design

This document describes the WSDLFinder technology including its proposed public interface and API.

The WSDLFinder must provide the ability to find Webservices both locally and remotely.

These include:

• Webservice status - Holds information on whether the webservice is currently running
• Webservice Location - Holds information on whether the service is remote or local
• J2ee Specification Levels
• Servlet Specification Levels
• Server Factory ID
• Server Instance ID
• Runtime Type
• WSDL URL
• Endpoint URL
• Implementation Resource URL

The ability to implement the WSDLFinder public interface will be a key part of this framework. As you can imagine it is likely that a vendor might have specific ways in which their Webservices can be found. They should be able to quickly incorporate their special requirements through some extensibility mechanism.

The WebServiceFinder method getWebservices() returns an array of WebServiceInfo objects. The WebServiceLocator Interface is implemented by AbstractWebServiceLocator which should be extended by those implementing locators. An example of a locator implementation is the WorkspaceWSDLLocator.

A locator registry will provide a mechanism for the WebServiceFinder to retrieve all locators. To be found by the WebServiceFinder, all locators must register by creating an extension in their plugin to the org.eclipse.wst.ws.locator extension point. The WebServiceLocatorRegistry is a singleton which returns an array of IConfigurationElements when called by the WebServiceFinder.

This section contains thoughts that will be worked into the design at some point.

• Locator implementations - starting with WorkspaceWSDLLocator then moving on to AxisLocator.
• Finding local and remote web services will be determined by looking at service endpoint. If it is not deployed on localhost then it is assumed remote.
• Will not be locating remote web services in the 1.0 timeframe. Goal for 1.0 is to add local indicators plus running/stopped or unknown status. Unknown status will be assumed where it cannot be determined if a web service is running or stopped.
• Access to locators should be through the WebServiceFinder only. Locators must not be used directly.
• Filtering will be added for the WebServiceFinder to allow selection of the type of services returned.
• A categorization mechanism will be created for the WebServiceFinder so that locators can register in a category or define their own category. The category will be used by the finder filter to return a subset of web services from available locators.
• The categorization mechanism will have to be loose enough that additional categories can be defined but strict enough that it is easy to determine what categories exist. Categories should be surfaced to the UI in some way so the user can specify what categories to include in a query.
• Avoid repetitive searching of the workspace for efficiency purposes. Add caching of web services found in the workspace by adding a listener on resource tree for .wsdl files.
• Eliminate duplicate .wsdl files (i.e. .wsdl files that may be found in more than one place in the workspace). Check to see if the .wsdl filename and the service endpoints match. TODO: confirm this is the correct approach.