[ogsa-wg] OGSA-BES-07Mar2005

[Dave Berry]

I have a couple of thoughts about the proposed interface (quite apart
from the "WSRF?" Discussion).  I post them here because they might be
relevant to the general question of the "multiple arguments" pattern.

1.  The getActivityStatus operation takes an array argument and returns
an array of array of strings.  This looks like a design written by a C
programmer(*).  In the context of a Web Service interface, wouldn't it
be more appropriate to return an XML document?  It should be possible to
define a simple XML schema that nests activity statuses under activity
IDs, posibly restricting the range of permitted activity statuses
(rather than using arbitrary strings).  This would be more robust and
self-documenting than relying on positional arguments in arrays.

(*) I'm not implying that programming in C is bad per se, just that it's
inappropriate for this level of interface.

2.  The getActivityStatus and terminateActivity operations take an array
of activity IDs.  This means that the client has to include logic for
deciding which IDs to pass in.  An alternative might be to use a query
language, so that the client could specify sets of activities that meet
certain criteria.  E.g. a simple query might specify "all activities
owned by this client" (assuming a definition of ownership...).  More
complex queries might specify:
	- "all activities that have been running for more than x
minutes" 
	- "all activities that have failed to start"
	- "all activities taking more than X megabytes"
	- "the activities with IDs in this list" (i.e. providing the
same behaviour as an array parameter).

This may at first seem an ambitious suggestion, but of course we can use
an existing query language rather than develop a new one.  If the
activities can be represented as a virtual XML document, then the query
language can be XPath or XQuery.

3.  We need to clarify when operations use abstract names and when they
use addresses.  This is a general question across the architecture, but
it is particularly apparent here because we see clear differences
between the proposals.  Also, what happens when a job is migrated from
one service to another?  I realise that this is outside the scope of
OGSA-BES, but the answer to that question may constrain the design here
(or vice versa).

Dave.



> -----Original Message-----
> From: owner-ogsa-wg at ggf.org [mailto:owner-ogsa-wg at ggf.org] On 
> Behalf Of Steven Newhouse
> Sent: 07 March 2005 21:45
> To: ogsa-wg
> Subject: [ogsa-wg] OGSA-BES-07Mar2005
> 
> Document for tonight's discussion.
> 
> Steven
> -- 
> ----------------------------------------------------------------
> Dr Steven Newhouse                        Tel:+44 (0)2380 598789
> Deputy Director, Open Middleware Infrastructure Institute (OMII)
> Suite 6005, Faraday Building (B21), Highfield Campus,
> Southampton University, Highfield, Southampton, SO17 1BJ,  UK
>