|Main||EGI.eu operations services||Support||Documentation||Tools||Activities||Performance||Technology||Catch-all Services||Resource Allocation||Security|
|GOC DB menu:||Home •||Documentation Index •|
<< Back to GOCDB/Release4/Development
GOCDB needs to be extended so that it can store multiple service endpoint/URLs, e.g. multiple GRIS endpoints. 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).
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"?> <results> <SERVICE_ENDPOINT PRIMARY_KEY="50257G0"> <PRIMARY_KEY>50257G0</PRIMARY_KEY> <HOSTNAME>dgiref-globus.fzk.de</HOSTNAME> <GOCDB_PORTAL_URL>https://goc.egi.eu/portal/index.php?Page_Type=View_Object&object_id=77182&grid_id=0</GOCDB_PORTAL_URL> <HOST_OS>SL5</HOST_OS> <BETA>N</BETA> <SERVICE_TYPE>GRAM5</SERVICE_TYPE> <CORE></CORE> <IN_PRODUCTION>Y</IN_PRODUCTION> <NODE_MONITORED>Y</NODE_MONITORED> <SITENAME>DGIREF</SITENAME> <COUNTRY_NAME>Germany</COUNTRY_NAME> <COUNTRY_CODE>DE</COUNTRY_CODE> <ROC_NAME>NGI_DE</ROC_NAME> <ENDPOINT> <URL>ldap://ce-cms.vinca.rs:2170/mds-vo-name=AEGIS10-VINCA-CMS,o=grid</URL> <InterfaceName>RIS</InterfaceName> </ENDPOINT> <!-- More Endpoints not shown --> ... </SERVICE_ENDPOINT> </results>
We have received a mail from Marian Babik (Wed 09/05/2012 17:09) explaining that SAM needs time to develop Glue2.0 support before multiple endpoints can be introduced in GOCDB.
SAM have asked us to hold off on implementing multiple endpoints until they have a development plan and proposal for how to resolve their issues.