Public comments are a very important part of the OGF document approval process. Through public comments, documents are given scrutiny by people with a wide range of expertise and interests. Ideally, a OGF document will be self-contained, relying only on the other documents and standards it cites to be clear and useful. Public comments of any type are welcomed, from small editorial comments to broader comments about the scope or merit of the proposed document. The simple act of reading a document and providing a public comment that you read it and found it suitable for publication is very useful, and provides valuable feedback to the document authors.
Thank you for making public comments on this document!
Comments for Document: SAGA API Extension: Service Discovery API
|Author(s):||S. Fisher, A. Paventhan|
|Public Comment End:||23 Jul, 2008|
Filtering by VO only is too restrictive compared to the security mechanisms supported by SAGA implementations. It can not be used with non-grid security contexts and it can not be used with non-VO attributes of grid security contexts (e.g. DN of proxy, VOMS role or group). I would suggest replacing 'VOFilter' with something like 'AuthzFilter'.
I would also suggest using the same attribute names as for context attributes (e.g. 'UserVO', 'UserID') for consistency with the SAGA Core specification.
The job management interfaces of SAGA Core specification can be used for uniform access to grid infrastructures because if defines both common methods and common attributes names for job description.
We need something equivalent for service discovery; it would help a lot if the specification could define a set of common service data attribute names (e.g. a subset of GLUE property names) per service type (e.g. 'job_service.RunningJobs').
A paragraph explaining why different service type names are defined for 'file' and for 'directory' is needed. Same comment for 'logical-file' and 'logical-directory'.
A SAGA implementation may support several discovery service end-points (with potentially different implementations) to enable simultaneous access to several grid infrastructures that do not interoperate. Hence I would suggest to add an argument of type URL to the constructor of class 'discoverer'. This argument could be optional.
I think use cases in the intro are good, as to motivate the package, and give some context for its usage.
great and sensible comments, IMHO!
Please find below the comments from the UWE team. Sorry for the late
contribution. We only came to know on July 22nd that comments have been solicited on the specification. I hope you can still accommodate these comments/suggestions.
1. Access control mechanism is not discussed. How can user set access privileges on the discovery service contents? Different users have different privileges and there should be a mechanism where users can get the information based on their access right.
2. Stale services can appear in user requests and are not discussed in the spec. Grid and distributed systems are dynamic. Services may come and go at any time. There should be a mechanism to identify stale services, or the services which are down due to any reason.
3. Time stamping of services is not mentioned. How a user may know when a particular service was registered or can query certain values for a particular time instance/interval?
4. What happens if a discovery service instance being queried is not available? Can a user contact another instance?
Or which fault tolerant mechanism should be considered to access services which are not listed on a particular information
5. What to do if the published services are not standard webservices as is the case with most Grid Services? I do not think this API will be able to access legacy Grid applications or can identify non standard services.
6. SQL Implementations are inconsistent and, usually, incompatible between vendors.
In particular date and time syntax, string concatenation, nulls, and comparison
case sensitivity often vary from vendor to vendor. How can applications users may be forced to use a single SQL syntax for all the implementations of discovery service?
7. Not clear whether the attributes of the discovered service bring the middleware information too.
8. Can we automatically load the adaptor, once the discovered service is selected?
9. We'd like a diagram showing how the API is invoked/used, ideally
with a clear worked example, for the novices amongst us. Consequently
We would support the use of actual use-cases in this specification and would
resist any movement to get rid of them from the introduction, as suggested
in another comment.
10. Punctuation is poor. Authors should address the comma and the
semi-colon. They aid readability.
11. Typos :
'Intendeded' on page 1
'or a broker' should be 'or by using a broker' on page 4
'as they as' should be 'as they are' on page 6
'perfomed' should be 'performed' on page 11
12. Clear, well written, mature and well researched specification
of value to the SAGA (and wider) community.