[glue-wg] New Endpoint and Service types
Paul Millar
paul.millar at desy.de
Wed Mar 5 12:30:06 EST 2014
Hi Stephen, Maria, everyone else,
On 05/03/14 13:22, stephen.burke at stfc.ac.uk wrote:
> Maria Alandes Pradillo [mailto:Maria.Alandes.Pradillo at cern.ch] said:
>> On behalf of the DPM team, could you please also consider adding:
>
> I think these do need some more discussion ...
>
>> - "DPM" to ServiceType
>
> It isn't clear to me that DPM is a distinctive type - as far as I
> know it only implements standard interfaces like SRM and xroot, so
> why is it a different type of service to, say, dcache? What would you
> propose as a definition? DPM as a product name is published
> elsewhere. I think we probably need a type name that would be common
> between, say, DPM, dcache and Castor since they provide basically the
> same functionality.
For comparison, dCache currently publishes a Service.Type of
'org.dcache.storage'
I think we've already had a discussion on this point, without coming to
a conclusion, as I recall.
The problem (IMHO) is the level of detail depends on who's asking the
question.
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).
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 all someone wants is to store some data using, say, WebDAV, then they
can look for a WebDAV endpoint that they're authorised to use. They
wouldn't even look at the StorageService Type.
That isn't to say publishing DPM (or 'org.dcache.storage') is the
correct approach, but that saying "they're all storage" also isn't
necessarily correct.
So, in the absence of other compelling reasons, I would suggest going
for a *more* specific Type: the generic features may be published
elsewhere (e.g., as endpoints) and searched for as such.
The only thing I would suggest is that instead of publishing DPM, you
publish a reasonable DNS name. A three-letter acronym is perhaps
generic enough that it might result in confusion.
>> - "org.webdav" and "org.xrootd" to InterfaceName
>
> xroot has already been discussed extensively and we made a decision -
> I think the decision was to use "xroot" for the protocol name but we
> should check.
For the xrootd protocol, dCache currently publishes
Endpoint.URL: xroot://xrootd-door.example.org/
EndpointInterface.Name: xroot
and StorageAccessProtocol.Type: xrootd
> For webdav I think the "org." prefix isn't adding much here -
> probably we should just use "webdav" as it's a well-known protocol
> defined in an RFC so there's no issue of a name clash, but there may
> be other views. Anyway there are likely to be other interested
> parties - dcache at least - who should express a view.
For WebDAV, dCache is currently publishing as either 'http' or 'https',
depending on whether SSL/TLS tunnelling is enabled or not. This is for
Endpoint.URL ('http://' or 'https://'), Endpoint.InterfaceName and
StorageAccessPoint.Type. This is largely for historical reasons (dCache
supported HTTP before WebDAV) -- not to say this is correct.
Since HTTP is a subset of WebDAV, it would be useful if someone
searching for HTTP endpoints could also find any WebDAV endpoint.
Therefore, here's a concrete proposal:
---
A service that supports HTTP or WebDAV protocols MAY publish
StorageAccessProtocol objects to represent this. If a
StorageAccessProtocol object is published to represent HTTP access then
the Type SHOULD be 'http'. If a StorageAccessProtocol object is
published to represent WebDAV access then the Type SHOULD be 'webdav'.
Since HTTP is a subset of WebDAV, a service that publishes a WebDAV
StorageAccessProtocol SHOULD publish a StorageAccessProtocol for HTTP.
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.
---
Cheers,
Paul.
More information about the glue-wg
mailing list