Minutes of Access Grid meeting, 14 Feb 2003

Attendees

Manchester: Carole Goble, Mark Greenwood, Phil Lord, Nick Sharman

Newcastle: Peter Li, Savas Parastatidis

Nottingham: Chris Greenhalgh

Southampton: Simon Miles, Juri Papay, Victor Tan

Agenda (not that we kept to it, but...)

1. Identify some 'generic' scenarios (example below) that will support the particular activities/workflows of the Graves' disease programme.
2. Review Savas' version of the service interaction matrix: do the identified interactions support the scenarios from (1)?
3. Review Chris's proposed MIR schema: does it capture enough to support the scenarios from (1)?
4. Order the scenarios from (1) to plan development activities

Discussion

These notes are only loosely chronological. As the author of these minutes, I've taken the liberty of adding comment not expressed in the meeting: I've enclosed them in square brackets [thus].

We started with the simple scenario given in the calling note:

1. Scientist logs on to a 'lab book' client (or portal)
2. Scientist discovers an interesting workflow
3. Scientist invokes workflow
4. Scientist examines output(s) and provenance of workflow invocation
5. Scientist logs off

and noted that the second step (workflow discovery) could be unpacked to several use cases, depending on the type of discovery. Later, we suggested a number of possibilities for this.

Carole proposed the following use cases:

• Register a service
• Find a service
• Search MIR for workflow by name
• Search MIR for workflow by concept
• Connect semantic descriptions to service instances
• Propagate a notification (of service addition, change or deletion) from the directory to some subscriber (e.g. the user agent)

The semantic find service would also be a subscriber in the last of these, but can poll the service directory in the short term.

Mark proposed:

• On logging on to the client, the Scientist receives notifications of service changes, workflow completions, database updates, ...
• Scientist A annotates some entity (Thing) in the MIR; Scientist B receives a notification of the action

Carole noted that it should be possible to annotate a Thing:

• with a concept
• with arbitrary text
• with a simple association to some other Thing

Simon proposed:

• Scientist receives job status notifications from the workflow enactor
• Scientist A completes a task; a notification is sent to Scientist B and/or the enactor to allow a workflow to progress
• Automated support for reliable, repeatable, service registrations (e.g. of the current family of SOAPLAB services -- in progress with Martin)
• Notifications from the service directory to the semantic find service (as above)

Carole noted that, to support the Graves' disease demonstration, we need to identify ASAP the extra services we need, and to extend our service ontology to cover them and any relevant new biology.

We will also need to define (and populate) service properties for service quality, locaton, cost, ... in the directory.

We discussed the issue of associating semantic types with either service instances or WSDL abstract service descriptions. The suggested alternatives were

• By querying the service instance directly. This could be an operation defined in the myGridService port type (say) or, when we adopt OGSA, a use of GridService::FindServiceData. The downside is that it needs to be implemented in each supported service (via a container?).

• By using UDDI's TModel capabilities directly. This would be an extension of UDDI's support for taxonomies and requires no implementation in the services themselves or tinkering with the WSDL, so could be added to registrations that weren't ontology-aware. The downside is that the TModel support may not be smart enough anyway, and we do not want to be tied just to UDDI.

• By extending the associated WSDL. This is simple and can be made to work, so we decided to go with this approach. To support appropriate notifications to the semantic find service, we would support a simple property (HasSemanticConcept=true, say) in the service directory. [Question: would the directory set this automagically as new registrations arrive?]

Carole listed use cases involving workflows:

• Construct a workflow. Currently, this is supported by hand-crafting WSFL documents, and we have a very basic graphical editor; IT Innovation may be able to produce a better one for us.

• Discover a workflow. Possible alternatives include:
  • find an object; look for workflows to which it could be input
  • search by associated semantic concepts
  • search by name, ownership, provenance, last-modified date, ...
  • by registering as a 'canned service' and searching (a view on) the service directory

• View a workflow. Possible alternatives include:
  • Use the graphical editor
  • Use an XSL transform
  • Use a non-specific text or XML editor (e.g. XMLSpy)

In fact, since in the information model, workflow definitions (ActionDefinitions) are Things, we need a general mechanism for associating viewers with Things. Suggestions included utilising the host operating system's support for MIME types and/or some explicit assocation in a client, the gateway (as at present) or the MIR. Chris's present view was that it was not appropriate to store client-side dynamic code loading issues (of which this is a case) in the MIR.

• Invoke a workflow.

We discussed how to supply stuff to the workflow. Currently, the service ontology separate inputs that are semantically significant, and parameters that are typically auxiliary to the main purpose of the service (e.g. configuration parameters). At the WSDL/SOAP levels, these two are indistinguishable, but the present binding mechanism only really support the first kind,which have to be the contents of domain entities (AKA DataThings?). Parameters are fixed in job definition files held in the gateway.

We discussed whether the service ontology needs changing to cater for this, but in fact we do need to unify at the user level different classes of service with different invocation models:

• straightforward call-and-return
• workflow enactment
• SOAPLAB-style job submission
• (eventually) OGSI-style factory-and-instance

The gateway's job definition files already address this issue, so perhaps we just need to refine it to handle parameters more cleanly? Simon suggested that the concept of "service start point" is also relevant, along with upcoming work on WS-Security[?] and WS-Policy.

[Do the job definition files really belong in the gateway? I don't think they are client-side specific in the way that plug-in viewers are; they are there mainly because the gateway's authors found they were necessary. I suspect they belong further down the myGrid stack -- in the MIR?]

Actions

At that point, the meeting timed out, and Carole proposed we continue it next Friday, if possible.

1. Newcastle team: to publish their list of use cases ASAP

1. Nick: to produce these minutes (done!)

1. Carole: negotiate to take over Geodise's AG session next Friday (20 Feb 2003)

-- NickSharman - 14 Feb 2003