[glue-wg] Endpoints and ComputingService, relationships between services. Some thoughs

[Florido Paganelli]

Hi Stephen,

thanks again for your comments. Just a note on your last question:

On 2012-08-20 14:06, stephen.burke at stfc.ac.uk wrote:
> Florido Paganelli [mailto:florido.paganelli at hep.lu.se] said:
>> Your observations are right, however the model of service you have
>> in mind is monolithic and not distributed; I am in fact speaking
>> about something that was not considered during the GLUE2 "making
>> of".
>
> As a general question Service-Service relations weren't considered
> much because in practice we had no relevant use cases, and as far as
> I know we still haven't. The schema is not supposed to be able to
> represent any conceivable situation, just to satisfy the things we
> know about. The schema does have a Service-Service relation, but as
> far as I know we have no uses of it at the moment and the semantics
> would need to be defined for a specific service if we did have a
> need. It may also be the case that you can infer the relationships
> from other information - for example if multiple VOMS servers are
> related to the same VO.
>
>> 1) the service, by design, *has* distributed endpoints, that might
>> run on different hosts.
>
> As far as the schema is concerned it doesn't matter what hosts the
> endpoints are on - it will often be the case that a Service with many
> Endpoints will involve many hosts. It may of course be a question of
> the information system technology as to whether such a configuration
> can easily be published in practice. In particular if you have
> endpoints on different sites it may be difficult to co-ordinate the
> publishing. However within a site it should be fairly easy - for
> example CREAM is done like that (in the CLUSTER mode). Each head node
> publishes its own Endpoint(s) and they get merged in the site BDII.
>

Yes that's also the approach ARC will follow now, but I am not that 
happy with it.

>> How to relate these records and infer, for example, that they're on
>> the same machine and/or serve the same resource?
>
> Why would you care if they run on the same machine? In general you
> can't get that even from the URL, because it may refer to a DNS alias
> and not the real host. If they serve the same Resource in the schema
> sense you can known because they will all have relations to the same
> Resource object, i.e. ExecutionEnvironment for computing services.
>
> Stephen
>

Well at the beginning I was publishing the Execution Service as a 
ComputingService separated from the Information Service as a plain Service.

In the same box I had
- ComputingService
- Service (ldap information endpoints)

But then if one pushes these records in an endpoint index such as EMIR, 
that contains the full GLUE2 Service/ComputingServce and 
Endpoint/ComputingEndpoint records, a client gathering these records 
needs to understand that these services are running on the same machine, 
or at least that one information service will ONLY serve information 
about a single execution service.

If not, the client runs the risk of querying twice an information 
service for which you already have data.

An example is the following:

*) in the index I have
   (a) a ComputingEndpoint of a ComputingService on machine X, with 
Capability executionmanagement.jobexecution ,
   (b) a Endpoint of a Service on machine X with Capability 
information.discovery.resource, that also allows me to discover 1) on a 
local information system

*) a client wants to submit a job to machine X. It needs a Computing 
Endpoint with executionmanagement.jobexecution and wants to decide where 
to submit.

How do the client know that (a) is already on machine X, and it does not 
need to query (b), machine X local information service?

there's nothing in GLUE2 that tells me how (b) on machine X is related 
to (a) on machine X.

Then the best is to merge those under the same Service as you suggested. 
At least I will have EndpointServiceForeignKey relation with the same ID 
and I can check against that.

Cheers,
-- 
Florido Paganelli
Lund University - Particle Physics
ARC Middleware
EMI Project