ImplementationCase: Asynchronous activity on web service

Motivation

To execute an operation on the service that lasts longer than the attention span of the client.

Story 1

A Client requires an activity on a Service that is expected to run for a while. The activity produces output as files in MySpace , and the files are produced at intervals during the activity. Service provides the activity in an asynchronous form with a specific web-service operation to start it.

Client invokes the web-service operation. Service checks the request; if it's not good, then Service returns a fault and the activity ends immediately. Assuming that the request is valid, Service completes the web-service operation immediately and starts the activity. In the completion message of the web-service operation, Service includes an identifier for the activity. Client is expected to include this identifier in all subsequent operations to do with the activity.

Service maintains metadata to do with the activity: 'running/finished/failed'; names of files of output completed; possibly others. Client polls these metadata using an enquiry operation provided by Service. Client uses the files of output as they are announced, instead of waiting to the end of the activity to start processing them. When client sees from the metadata that the activity is complete, or has failed, then client stops polling.

Story 2

As story 1, but Service also provides a notification service for the activity metadata. Client subscribes to this and is sent the status updates as they arise instead of having to poll.

Story 3

As Story 1, but client is not interested in intermediate results and just wants to wait for the end of the activity. After the operation that starts the activity, Client calls a 'wait' web-service operation on Service. The latter operation blocks until the activity is complete, then returns the final metadata of the operation.

Story 4

As above, but Client goes off-line during the activity and does not come back until the work of the activity is over. Client then needs to know what happened. Service therefore considers the activity to be on-going and allows client to poll the metadata after the work of the activity is finished. If Client resubscribes to notification of the metadata, then Client gets immediately the completion status. if Client calls the 'wait' operation, then that operation returns immediately.

Ultimately, client is finished with the activity and tells Service to forget the metadata. If client ommits to do this, then Service forgets the metadata anyway after some timeout period that is part of Service's design.

Story 4

As above, but Service does not write the results to files in MySpace . Instead, it keeps them in a temporary DB-table. The name of the table is one of the activity's metadata. When Service forgets the activity, either on command from Client or due to a timing out, then the temporary table is dropped and its storage reclaimed.

Discussion

We need asynchronous activities

• to get at intermediate results during an activity;
• to mitigate the coupling of Client and Service during a synchronous web-service call (we don't want the work to be wasted if Client looses contact with Service);
• to help manage results cached by Service.

These functions could be implemented using WS-ResourceFramework (WS-RF). In fact, many of the details were suggested by what WS-RF provides. AG-2 would need to add to a WS-RF implementation the 'wait' activity and some conventions on the structure of the metadata.

-- GuyRixon - 26 Apr 2004