Hi Steve, some comments to your comments :-) 1 (UC in intro) Yes, may make sense to remove the long use case quotes, and to replace with summaries. Not neccessarily to save space, but to have the language and terminology uniform. 3 (data filter) Your proposal to simply suggest to use glue based data filter attributes sounds great to me: no need to reinvent anything here. And no need to come up with any 'complete' list of attributes either, which would probably impossible anyway... 11 (SQL portability) proposed solution, to limit camparing of strings, sounds good to me. not being very SQL literate: are we loosing much here? Quoting [Fisher, SM (Steve)] (Aug 06 2008):
Date: Wed, 6 Aug 2008 13:35:35 +0100 From: "Fisher, SM (Steve)" <S.M.Fisher@rl.ac.uk> To: "SAGA RG" <saga-rg@ogf.org> Subject: [SAGA-RG] Service Discovery revisions
Hi,
I have gone through the comments made in the public comment period and arranged them and subsequent discussions between Andre and myself into a page of HTML which is attached.
For some issues - e.g. typos - the solution is obvious so I marked these as green. Other issues with a suggested resolution are marked yellow - and I would like feedback on these - i.e. do you agree or not. Others have no suggested resolution - typically where Andre and I disagree - we need input on those.
I will send round the web page periodically as it is revised until it is all a delightful shade of green. I will then consult those who made the comments to make sure they are happy.
Please send your comments to the list in plain text - I don't want to merge HTML files.
Steve
Content-Description: SD.html
# Issue Author Text Discussion Resolution 1 Use Cases in the Introduction lfield I would suggest removing the use cases in the introduction as they do not really add to the document and make it more confusing. I think use cases in the intro are good, as to motivate the package, and give some context for its usage. - Andre 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. - UWE Laurence discussed this with me before making the original comment. He had read it quickly and had seen the quotes as part of the text. The difficulty is that the wording of the use cases is confusing (for example it talks about components rather than services). I would like to remove the quoted text but to summarise the use case in a few words of my own. The reference to the use case document will of course be retained. - Steve I don't think we need a picture - but I can add a few more words with the examples at the end of the document. - Steve Replace the quoted text with a summary Add a few more words with the examples at the end of the document. 2 vo_filter sreynaud 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. Yes - Andre No - I think the abstract concept of a VO is bigger than VOMS. For a non-grid deployment the "service provider" can publish the name of a group of people that might use the service. I could change the attribute name from VO to UserVO - except that this might imply that it is the VO of the user makign the query which is not the case - Steve 3 data_filter sreynaud 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'). Yes - Andre I quite like the idea - perhaps it could go in an appendix as suggested attribute names. However I am not competent to choose this set of names and I fear it could cause long delays, so i would prefer not to do it. - Steve 4 service_filter sreynaud 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'. Yes - Andre We could say that the File service is implemented by the file and directory classes and similarly for 'logical-file' and 'logical-directory'. - Steve On page 10 say that the File service is implemented by the file and directory classes and similarly for 'logical-file' and 'logical-directory' 5 discoverer sreynaud 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. Yes - Andre Add an optional argument when creating a discoverer to guide the implementation in locating the underyling information system. 6 discoverer not available UWE 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 system? That is up to the SAGA implementation. One implementation may just fail, another may fall back to another service, a third one may to collect information from a set of available services (probably preferred). - Andre I think this is also addressed by the issue above from "sreynaud" Add an explanation to the document 7 Access Control UWE 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. The discover is created in a saga::session, thus has a set of saga::context's available. Only with these credentials it can perform queries. Also, these credentials identify the user to the backend, thus potentially allowing to perform server side authorization on that ID. - Andre Add an explanation to the document 8 Stale services UWE 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. You can't avoid stale services: even if the API confirms a service is not stale, it might be on the next call, and vice versa. The SD API can only provide endpoints, but notguarantee availability, nor completeness. - Andre Add an explanation to the document 9 Time stamping UWE 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? Hmm, I wonder if there is a use case for that... Otherwise, this can very well be part of the free form service_data. - Andre If the underlying info system is using GLUE II then everything has a creation time and a lifetime. The implementation may choose not to return "expired" services. I would like to note that it is the responsibility of the implemenation to apply any algorithm it chooses to return valid services - this might include ignoring services that have not refreshed their registration recently. 10 Legacy services UWE 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. The data model is not tied to web services, nor is the API. I don't see any reason why that should not work for not-web services. - Andre I propose to say nothing 11 SQL variations UWE 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? The document refers to SQL92 syntax, which is a standard. Any deviation from this standard, e.g. due to vendor specific backend SQL, need either to be treanslated by the SAGA implementation (preferred), or to be well motivated and documented. Indeed, different SQL versions would break portability, and IMHO compliance with the document. - Andre Data are all strings except that page 11 says: If values are specified as numeric values and not in single quotes the service data will be converted from string to numeric for comparison. So there is no problem with dates and times. Case sensitivity is normally in the hands of the user (or in this case the service discovery implementor) - at least it is for MySQL and HSQLDB. However there is a problem with comparison of strings. I suggest that we say that you cannot use > and < on strings. - Steve Forbid comparison of Strings other than equality, ineqaulity and LIKE. 12 UWE Not clear whether the attributes of the discovered service bring the middleware information too. Don't understand the point - I will go back and ask them - Steve 13 Adaptor loading UWE Can we automatically load the adaptor, once the discovered service is selected? That is up to the implementation. Not all implementations may be adaptor based. - Andre I propose to say nothing 14 Punctuation UWE Punctuation is poor. Authors should address the comma and the semi-colon. They aid readability. I will get someone who is "good at punctuation" to give it a read through at the end. 15 Typos UWE 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 These will be corrected -- Nothing is ever easy.