Difference between revisions of "Swordfish Documentation: Architecture: Dynamic Endpoint Resolution"

Revision as of 09:29, 28 October 2009

Description

In Swordfish the relationship between components using a service (consumers) and components providing a service (providers) need not be static. In fact, a consumer refers to a provider by means of a logical identifier that clearly signifies the service’s interface together with a statement of the consumer’s non-functional capabilities and requirements which is called a policy. Given these two pieces of information and its own database of existing service providers along with their respective policies, the Service Registry selects a matching provider and calculates an effective policy that governs all future communication between consumer and provider.

Design

Swordfish supports the connection to different service registries in order to allow dynamic endpoint resolution. This flexibility is realized through the service registry plugin. The Service Registry Plugin consists of the following components:

• ServiceResolver - resolves information about the service endpoints for specified service using endpoint document providers and endpoint extractors
• EndpointDocumentProvider - is responsible for retrieval of service description from different kinds of location. Different implementations of the EndpointDocumentProvider can be used to get the service descriptions from local filesystem or from a remote registry.
• EndpointExtractor - extracts endpoint parts (e.g. endpoint address, transport protocol) from the service description representation. At the same time multiple endpoint extractors can be registered in the system, each suitable for processing one type of service description document (e.g. extractor for WSDL 1.1 based service descriptions, extractor for WSDL 2.0 and so on).

API

(To do: interfaces are part of org.eclipse.swordfish.core.resolver, package api does not exist)

Main component classes

(To do: interfaces are part of org.eclipse.swordfish.core.resolver, package api does not exist)

Processing sequence

The endpoint resolution process is described by the following scenario:

1. ServiceResolver gets all EndpointDocumentProviders registered at runtime and chooses one with the highest priority. The chosen provider is then queried for service description documents corresponding to the specified service interface. All found documents are returned from provider as collection of the ServiceDescription objects where each ServiceDescription represents one raw description document.
2. ServiceResolver gets all registered EndpointExtractors and uses them to extract endpoint description information from received ServiceDescriptions. At this step it also performs policy trading which allows to exclude non-matching service descriptions from the extraction process. Extracted endpoint descriptions are grouped as collection of EndpointDescription objects and returned to caller.

Implementation

Involved bundles

• org.eclipse.swordfish.core.api (core interfaces)
• org.eclipse.swordfish.core.resolver (core interfaces and (Spring) configuration)
• org.eclipse.swordfish.plugins.resolver.backend.base (basic implementations for endpoint descriptions and WSDL extraction)
• org.eclipse.swordfish.plugins.resolver.backend.local (resolve endpoints using the local file system)
• org.eclipse.swordfish.plugins.resolver.backend.remote (resolve endpoints using a Swordfish Service Registry)