From EGIWiki
< GOCDB‎ | Release4‎ | Development
Revision as of 11:42, 27 April 2012 by Davidm (talk | contribs) (Introduction)
Jump to: navigation, search

<< Back to GOCDB/Documentation_Index
<< Back to GOCDB/Release4/Development

Multiple Endpoints


Define multiple Endpoints per Service. As requested in ticket https://rt.egi.eu/rt/Ticket/Display.html?id=3347. GOCDB needs to be extended so that it can store a GRIS URL field for each service endpoint. This will allow the Top-BDII to directly retrieve information about the endpoint.

To achieve this we propose adding support for multiple <Endpoint> elements per service (the Endpoint element in turn wraps a <URL>). For example, one Endpoint could define the actual service URL, a second could define the GRIS ldap URL, whilst a third could define an admin portal URL and so on.

Given that a Service would be able to define multiple endpoints, a mechanism is required to distinguish different endpoint types and their intended purpose. To do this, we propose adopting the GLUE2 InterfaceName value:

  • As per GLUE2, Define a new <InterfaceName> tag as a child of <Endpoint>. For example, the Endpoint could define the service's GRIS ldap URL with a <InterfaceName> value of "RIS" (or maybe "ldap.RIS") representing an ldap endpoint to a Resource Information Service.

Adding multiple Endpoints per service is a more GLUE2 centric approach. Additional elements/attributes can be added to the GOCDB Endpoint if required. For more GOCDB/GLUE2 comparisons see GOCDB/Release4/Development/GLUE2Compatibility.


When adding or editing a service we propose that a user can add multiple child Endpoint objects.

The GOCDB-PI output will be extended for nesting multiple child <Enpoint> elements within a parent <SERVICE_ENDPOINT>. Each <Endpoint> nests the child <URL> and an <InterfaceName>. Using this mechanism the Top-BDII can retrieve a filtered list of endpoints that support a URL with the requied interface (e.g. "RIS" or maybe even "ldap.RIS" to indicate the URL protocol scheme).

GOCDB would centrally manage an enumeration of <InterfaceName>s. Each type of InterfaceName would be documented similar to service types. Endpoint URLs that nest a particular InterfaceName MUST fully support that particular interface type (which is the intended purpose of a standard interface).

PI Examples

Query String: https://goc.egi.eu/gocdbpi/private/?method=get_service_endpoint&InterfaceName=RIS

This query would return all <SERVICE_ENDPOINT> elements that support a RIS <ENDPOINT> (note, muliple <ENDPOINT> elements can still be nested in each <SERVICE_ENDPOINT>).

 <?xml version="1.0" encoding="UTF-8"?>
      <!-- More Endpoints not shown -->