On 07/05/2012 12:06 PM, stephen.burke@stfc.ac.uk wrote:
glue-wg-bounces@ogf.org
[mailto:glue-wg-bounces@ogf.org] On Behalf Of Florido Paganelli said: I think is a GLUE2 WG task to understand, if not describe and propose, how these values can be used in a nice way.
What's your opinion on that?
So far I don't think we have a good idea of what use cases the ServiceType should support, i.e. under what circumstances would you query for a specific Type? For a computing service you can get every instance with objectclass=GLUE2ComputingService (or equivalent in xml), and if you want to use a specific protocol you can query by the EndpointInterfaceName, so I'm not sure when you would want something intermediate. If the GOC DB does have a practical use case it may be that that should drive what we publish - I agree that it would seem strange if the GOC DB uses different Types.
I think it will be interesting for you EGI profiling, how to cope with such situations. In the ARC example I gave, there is _no hint_ in the information system about the fact that the service is running as a DG gateway. Getting GLUE2 serviceType and Endpoints as you explained above is irrelevant for Desktop Grid clients at the moment. The operating behavior is exactly the same as any client submitting to a predefined ARC CE -- just submit to a URL. Currenlty the problem arises when the Operational/Monitoring view comes into play: GOCDB knows, and wants to keep track, that such a CE is operating as special purpose gateway, and that's why they come up with different names. Ideally also clients should care about it, if we enforce a sane infosys-based approach. Easy path is to force services to publish specific ServiceTypes, but my fear is, is that the correct way of using these GLUE2 concepts? -- Florido Paganelli Lund University - Particle Physics ARC Middleware EMI Project