[SAGA-RG] Service Discovery revisions

[Andre Merzky]

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 at rl.ac.uk>
> To: "SAGA RG" <saga-rg at 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.