[glue-wg] New Endpoint and Service types

[stephen.burke at stfc.ac.uk]

Paul Millar [mailto:paul.millar at desy.de] said:
> Stephen, to you DPM, dCache and Castor provide the same 
> functionality, 
> so you would be happy with instances of all three published as 
> Service.Type of 'storage' (or similar).

Not entirely - the object names are prefixed with "Storage" anyway, so simply publishing a Type of "storage" would be redundant. Also it seems to me that something like a standalone xrootd server or a "classic SE" as we used to have would reasonably be different types of storage service, even aside from the details of which protocols they support. However, we do have a family of SRM-based SEs which seem to me to represent a commmon type - indeed I thought that one of the goals of EMI for dcache, DPM and StoRM was precisely to make them interoperable! In the past I would have suggested "SRM" as a Type, but since we now seem to be making moves away from the use of SRM that may not be ideal as a name. From a dcache POV, what do you see as providing commonality with DPM and StoRM? (Beyond all being storage systems.)

> Somebody who needs some unique characteristic provided by dCache (or 
> DPM, or ...) might want more detailed Type, specifically that the 
> service provides the dCache-like facilities (or DPM-like or ...).

If someone really wants to know the implementation they can look at the EndpointImplementationName or ManagerProductName - although of course it's undesirable to have anything which is implementation-specific. For me, to be a valid type it would have to be the case that a completely different vendor could potentially produce an independent product which could reasonably be described as "a DPM" or "a dcache" - even conceptually, can you see such a thing as being meaningful? If so, how would you define it? You use "dcache-like" above, but what does that mean (in terms of external interfaces)?

> For the xrootd protocol, dCache currently publishes
> 
>      Endpoint.URL: xroot://xrootd-door.example.org/
>      EndpointInterface.Name: xroot
> and StorageAccessProtocol.Type: xrootd

What protocol name do you recognise in e.g. a getTURL operation to return an xroot TURL? Does it match what DPM and StoRM use? What about webdav?

> For WebDAV, dCache is currently publishing as either 'http' 
> or 'https', 
> depending on whether SSL/TLS tunnelling is enabled or not.  

Bear in mind that the scheme name in the URL is not the same as the InterfaceName. I don't know a lot about webdav but my impression is that it's far from being identical with http as far as file access goes, so I would expect a different InterfaceName even if the URL is https:// (c.f. SRM vs. httpg://).

> When publishing an Endpoint object the describes an HTTP or a WebDAV 
> endpoint with unencrypted access then the URL SHOULD start 
> 'http://' and 
> the InterfaceName SHOULD be 'http'.  If the endpoint is 
> encrypted then 
> the URL SHOULD start 'https://' and the InterfaceName SHOULD 
> be 'https'. 
>   If the endpoint supports WebDAV then a SupportedProfile of 
> 'http://webdav.org/' SHOULD be published.

If it's necessary to make that distinction think I would prefer to publish both http and webdav endpoints, doing it your way would seem likely to be error-prone.

Stephen-- 
Scanned by iCritical.