GOCDB/Release4/Development/MultipleGRIS

From EGIWiki
< GOCDB‎ | Release4‎ | Development
Revision as of 19:32, 1 February 2012 by Jcasson (talk | contribs) (Implementation)
Jump to: navigation, search

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

Multiple Endpoints

Introduction

As requested in ticket https://rt.egi.eu/rt/Ticket/Display.html?id=3347. Make GOCDB capable of storing 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 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. We propose using using a known interface name:

  • As per GLUE2, Define a new <InterfaceName> tag as a child of <Endpoint>. For example, the Endpoint could define the service's GRIS URL with a <InterfaceName> value of "RIS" for 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. We may change the 'InterfaceName' element with a more suitable alternative or use a sub-type or attribute (still to decide). For more GOCDB/GLUE2 comparisons see GOCDB/Release4/Development/GLUE2Compatibility.

Implementation

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

The GOCDB-PI output will be extended to show multiple <Enpoint> elements (each nesting the child <URL> and an <InterfaceName>). Using this mechanism the Top-BDII can retrieve a filtered list of endpoints that have a URL with the requied classification (e.g. "RIS").

GOCDB would centrally manage an enumeration of <InterfaceName>s. Each InterfaceName type would be documented similar to service types. Each type would be specifically defined such that URLs of a particular type guarantee to implement the interface documented.

PI Examples

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

 <?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&amp;object_id=77182&amp;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>