Florido Paganelli [mailto:florido.paganelli@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