On 2012-08-24 10:55, stephen.burke@stfc.ac.uk wrote:
glue-wg-bounces@ogf.org [mailto:glue-wg-bounces@ogf.org] On
Behalf Of Florido Paganelli said: I favour the 1) as it makes possible to have Endpoints inside a ComputingService, that would give better readability and clarity to Endpoints which are NOT ComputingEndpoints.
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.
Also, would you allow a ComputingEndpoint to be part of a non-Computing Service?
Well this is impossible also by looking at the model, because: 1) Service is the only entity that has an association with Endpoint; 2) Service is the most generic object in the hierarchy 3) ComputingService is the only entity that has an association with ComputingEndpoint; So any non-computing service, whether it is Service or some other non-ComputingService, does NOT have any relationship whatsoever with ComputingEndpoint, but only with Endpoint at most. a non-ComputingService _different_ from Service can inherit this an association with ComputingEndpoint in only one way: by extending ComputingService, that is, ComputingService must be the parent or super object Class of the non-ComputingService. so, I don't, as inheritance does not allow that.
What do you think? Which one should we favour?
In LDAP I don't think it makes very much difference. With the current way of doing it you can find all Endpoints which belong to computing services with (objectclass=GLUE2ComputingEndpoint). If you remove the objectclass from a few of them you lose that ability, and I think there is no gain other than a very small reduction in data volume.
In LDAP, I would scope the search for endpoints starting from the ComputingService, but we will have a debate if we go into this, I told you I like the LDAP tree structure for such reasons. But if implementations are keen adding associations, I can even scope the search by filtering on associations, which is unfortunately less performing.
(If you want to find only the Endpoints which allow job submission you can select on the Capability.)
yes I completely agree on the above
I am really annoyed of calling ComputingEndpoint an Endpoint that has nothing to do with computing!
As I said before, if it has nothing to do with computing maybe it shouldn't be part of a ComputingService at all.
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 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. I tried to express this in previous emails but I clearly didn't succeed. There is, however, a third approach in this service-to-service thing: 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 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. What do you think about this one above? Cheers, -- Florido Paganelli Lund University - Particle Physics ARC Middleware EMI Project