[glue-wg] Enumerations for DPM and related InterfaceNames was: Re: New Endpoint and Service types

[Florido Paganelli]

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/5dKm/content/dpm-2
> 
> 

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 at REMOVE_THIShep.lu.se
 Homepage: http://www.hep.lu.se/staff/paganelli
==================================================