Introduction

How are actual (e.g. Web or Grid Service or workflow) invocations constructed by general-purpose clients (e.g. the Gateway)? How are the operations related to services? How are the parameters described? What about optional or default parameters? etc.

Review

Current stuff:

• WSIF (WebServicesInvocationFramework^?), originally IBM, now Apache "is a simple Java API for invoking Web services, no matter how or where the services are provided" ( http://ws.apache.org/wsif/ ).

• The workflow enactor has its own dynamic invocation library, written to address shortcomings (e.g. support for complex types) in WSIF version 1. This is used by the enactor to call web services, based on WSDL definitions of those services and the operation and message part names defined there.

• The WP2 service architecture/framework includes a notion of "startpoints", and a supporting common client API for invoking operations on services in a technology-indepentent way.

• The current Gateway provides its clients with a common abstract view of operation invocation, that is supported by a per-operation XML configuration file held by the Gateway, and a simple Java client class loading extension point (see GatewayJobDefinition). It currently supports (i) direct invocation of individual web service operations (ii) invocation of Soaplab service operations (iii) execution of workflows on the enactment engine. At the moment (Feb 2003) this file also supports Gateway-specific semantic service descriptions, i.e. includes operation and parameter concept annotations. As well as associating concepts (and types) with parameters, it also supports the specification of default values for parameters.

• Applab ( http://industry.ebi.ac.uk/applab/ ) supports an (extended) version of the OMG BSA standard for service metadata, which can provide names, (human consumption) descriptions of the operations and parameters, some simple classification and other metadata for services (e.g. provider, version), (simple - command-line oriented) types of the intput and output parameters, default values, valid values, and can express some dependencies between parameters (such as some alteratives).

Requirements

For Discovery:

Locate a service or workflow according to the work that is does, as expressed by an associated operation concept.

• Each service may be annotated with zero of more operation concepts supported by (methods of) that service.

Locate a service or workflow according to the input or output (concept and/or concrete type and/or format.

• The input and output parameters of each (logical) operation should be annotated with the associated concept type(s) and (where appropriate) format(s) and/or more specific concrete types (compare 'operation taking a string and returning a string').

Locate a service by name or description.

• Services (and service (logical) operations) may be described and/or named in various ways, e.g. UDDI business, tModel, etc.

Locate a service by use or association.

• Services may be located by searching historical usage information which is held in the system in any case for provenance purposes.

Refine a search according to other associated information, e.g. QOS.

• Services may be annotated with various additional metadata, and this may be provided by various parties.

For invocation:

Invoke an operation.

• The individual operation(s) (rather than the service as a whole) must be annotated with the concept operation. But note that this breaks down with complex operation interfaces, such as the enactment engine or Soaplab, where a single interface operation in isolation does not 'do' the logical/conceptual operation (see below).

• (as with discovery) The input parameters of each (logical) operation should be annotated with the associated concept type(s) and (where appropriate) format(s) and/or more specific concrete types (compare 'operation taking a string and returning a string').

Allow the user to ignore - or not - a subset of parameters, e.g. through default or pre-configured parameters.

• Default values may be associated with a subset of input parameters. This is logically (a) part of a workflow's definition that needs to be shared (b) subject to customisation and personalisation.

Allow (something equivalent to) partial evaluation, service customisation and republishing or continuation passing.

• For example the same mechanisms as above (for default parameters) but restricted modification.

Deal appropriately with output values.

• (as with discovery) The output parameters of each (logical) operation should be annotated with the associated concept type(s) and (where appropriate) format(s) and/or more specific concrete types.

Support correct use of polymorphic operations, and operations with type dependencies between parameters (e.g. value of an input affects the type of an output, or which other inputs are valid).

• Ouch!

• Consider simplified and restricted (but useful) forms?

• Describe each pattern of dependency as a separate logical operation.

Invoke operations on (a) a bespoke Web Service operation (b) a workflow-defined operation (c) a complex/composite Web Service invocation interface such as Soaplab or (d) a Factory-based GridService^? in the same way.

• Annotate services (and/or endpoints) with invocation 'idiom' information, e.g. from ontology, or implicitly by proposing a particular client-side implementation class which encapsulates the corresponding protocol.

Monitor and manage the progress of the long-running operation.

• Standardise and support an extended model of operation invocation, see for example the enactment engine API and the Soaplab API, each of which supports invocation of a single logical operation, using a number of actual WebService^? invocations, with additional management-specific operations allowing polling of status, generation of progress events or notifications, aborting of the operation.

Next Steps

1. Clarify exactly what information is needed.
2. Clarify who/what needs that information, and when.
3. Clarify who/what can generate that information and when.
4. Clarify how that information can get from where it is generated to where it is needed.
5. Clarify how this is divided up between the various parts of myGrid, noting that multiple strategies may be provided in parallel.

-- ChrisGreenhalgh - 14 Feb 2003