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

[Florido Paganelli]

On 2012-08-24 10:55, stephen.burke at stfc.ac.uk wrote:
> glue-wg-bounces at ogf.org [mailto:glue-wg-bounces at 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