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