RE: [ogsa-wg] OGSA-BES-07Mar2005
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@ggf.org [mailto:owner-ogsa-wg@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
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?
Certainly. The whole point of the interface description is for it to be concise psuedo code so that we can agree initially on what we want to represent. In this case we want to return an 'array of arrays'. Once we have agreed on what we want to do specifying the XML structure to deliver it to the client will (I hope, nay dream) be simple.
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 seems an interesting idea. It would mean exposing more of the internal state of the service and focussing on a batch-ish environment. Something for discussion at the BoF or during the WG.
3. We need to clarify when operations use abstract names and when they use addresses.
This where some progress is needed from the naming folks within OGSA-WG or elsewhere. A simple URN can always be mapped through a registry/resolver to an EPR or something service specific.
Also, what happens when a job is migrated from one service to another?
If you have a resolvebale URN, job migration is handled by resolving the URN to the new job location. 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
participants (2)
-
Dave Berry -
Steven Newhouse