[glue-wg] ComputingService and Endpoints, a point of view

[stephen.burke at stfc.ac.uk]

Florido Paganelli [mailto:florido.paganelli at hep.lu.se] said:
> > What would you propose to do with Share, Resource and Manager?
> 
> Same approach. As I said, this depends if we want to override the
> associations or not. This cannot be represented in UML, but makes sense
> in realizations.

And what about the relations between them? And the same for the storage classes? I think this would be quite a big change which would need a significant advantage to be worthwhile, and so far I don't think you've given one.

> In LDAP, I would scope the search for endpoints starting from the
> ComputingService,

You can do that if you have chosen one specific ComputingService, but in your own example of a delegation endpoint which could serve computing or others kind of service, the current definition lets you search for all the endpoints which serve computing services but not the others. 
 
> but then give me something to relate a local information service and
> its endpoints (some OpenLDAP service), or an independent delegation
> Service to the box where the ComputingService is, otherwise I run the

As I already said, I think an information endpoint should be a separate Service. For a delegation service I can't say, it would depend on how closely it's bound to the computing service and what the use cases are.

> risk of quering twice the information system(s) for no reason, and
> submit jobs twice to the same endpoint because I cannot distinguish
> between them.

Queries are normally very lightweight compared with real service interactions like job submission, unless you're doing a very large number of them - querying twice is not a problem. Being able to recognise that you have the same Endpoint multiple times obviously is important, but I don't see why it would be difficult to recognise duplicates.

> In my initial implementation I wanted to use the service-to-service
> association described in GFD1.47 (page 7, page 13); however I was told
> that this was not the purpose for it to be there, but it was more to
> reflect some hierarchy between Services.

I don't see how it could represent a hierarchy unless you had some other way to express it - Service-Service is a peer relation, there is no directionality (unlike e.g. Domain-Domain). In any case, as I've said repeatedly, the question is not what the purpose was when the schema was defined (none in particular as far as a I remember) but whether it can be used to satisfy whatever requirements you have now in a specific case. For the things you're describing this may well be sufficient.

> I think the flaw in such an association based approach would be that
> the unique ID might be wrong at a certain point in time (for example
> because of ID renewal) and not refer anymore to the record it points
> to.

Persistency of IDs is a separate question, and a general one - IDs must be persistent for as long as necessary for all the possible uses. ServiceIDs in particular should probably change only when services are reconfigured in a major way. If references to IDs can't be followed the whole schema will be unusable!

Stephen