Hi Marteen, Thanks for bringing this up again. On 2014-04-04 13:24, Maarten Litmaath wrote:
Hi Florido, all,
If we look at the list of ServiceType_t in GFD.147, chapter B.31, you'll se that the third-level names there area all product names.
True. It appears we have a precedent...
So, if Stephen thinks that we should see dCache and DPM as a single Storage ServiceType_t, I can now say that I don't think we should.
If the capabilities are the same, then discovery should be done on capabilities and NOT ServiceType_t IMHO. But this I said in many other various emails.
I suspect using capabilities would be better indeed,
During the EMI project we suggested an alternative solution for discovering using capabilities which is now implemented in the EMI-ES interface. If you look at the Capability_t-draft.csv file I uploaded long time ago, not yet approved by the group, you'll se examples of how we implemented it: https://github.com/OGF-GLUE/Enumerations/blob/master/Capability_t-draft.csv It is very job-interface centric, but can be applied to anything, and I found it way better than filling tag names and using the Profile attribute to read a RFC as Paul proposed. Example: data.access.stageindir.gridftp Capacity of offering clients a place from where to upload data by means of the gridftp protocol information.query.xpath1 Capacity of answering information system queries specified in the XPath v 1.0 query language. Maybe verbose, but difficulty to interpret in a wrong way. And more than this, intuitive both for man and machine.
but there exists plenty of legacy usage that selects on ServiceType. For example, an SE supporting the SRM protocol should publish a record with GlueServiceType=SRM, while _GlueSEImplementationName_ may be "DPM".
I think the above is part of the GLUE2 EGI profile. I found it perfectly sound, as so far there was no solution to discover such information. We actually agreed on using it, but I don't think this is a nice way of performing discovery. I think you're right, this is legacy stuff. This happened because Glue1 was NOT service-oriented, but endpoint oriented, and the service inherited the endpoint name SRM, or whatever it was in Glue1. Same as GOCDB, it's Service-Endpoint oriented, that means there is no difference between the service and the endpoints/interfaces/webservices it serves. I would suggest SRM to be Deprecated as a ServiceType_t in favour of correct product names with proper reverse DNS. Implementation name is fine. The string SRM is very misleading. It's a protocol, not a service. It's written everywhere here: https://www.gridpp.ac.uk/wiki/SRM There's even a section with implementations. I think this should NOT be a ServiceType_t all. As a matter of fact, it does never appear in GFD.147 as such. Instead there is a clumsy ogf.srm InterfaceName_t there.
I think the real problem here is that I didn't figure out what this DPM thing is. Nobody sent a description. Nobody sent a link to relevant documentation. If you know about this, please help me understanding this better.
http://www.eu-emi.eu/releases/emi-3-montebianco/products/-/asset_publisher/5...
thanks for the link! I still think the ServiceType should be different. That would make perfect sense to me. It does not really describe the product itself, but the collection of endpoints that the product MAY offer. Maybe ch.cern.dpm ? Cheers, Florido -- ================================================== Florido Paganelli ARC Middleware Developer - NorduGrid Collaboration System Administrator Lund University Department of Physics Division of Particle Physics BOX118 221 00 Lund Office Location: Fysikum, Hus B, Rum B313 Office Tel: 046-2220272 Email: florido.paganelli@REMOVE_THIShep.lu.se Homepage: http://www.hep.lu.se/staff/paganelli ==================================================