Alert.png The wiki is deprecated and due to be decommissioned by the end of September 2022.
The content is being migrated to other supports, new updates will be ignored and lost.
If needed you can get in touch with EGI SDIS team using operations @ egi.eu.

Difference between revisions of "GOCDB/Release4/Development/MultipleGRIS"

From EGIWiki
Jump to navigation Jump to search
Line 10: Line 10:
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:  
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 ldap URL with a <InterfaceName> value of "ldap.RIS" representing an ldap endpoint to a Resource Information Service.  
* 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.  
<!--# Define a new Endpoint 'InterfaceName' attribute, e.g. <Endpoint IntefaceName="ldap.RIS">
<!--# Define a new Endpoint 'InterfaceName' attribute, e.g. <Endpoint IntefaceName="ldap.RIS">
# Define an Endpoint sub-type specialisation such as <GRIS_Endpoint> (the GLUE2 extensibility mechanism. Currently not preferred due to increased complexity - requires XSD abstract elements and XSD substitution groups). -->
# Define an Endpoint sub-type specialisation such as <GRIS_Endpoint> (the GLUE2 extensibility mechanism. Currently not preferred due to increased complexity - requires XSD abstract elements and XSD substitution groups). -->
Line 19: Line 19:
When adding or editing a service we propose that a user can add multiple child Endpoint objects.   
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 have a URL with the requied interface (e.g. "ldap.RIS").
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 have 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 [[GOCDB/Input_System_User_Documentation#Service_types|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).
GOCDB would centrally manage an enumeration of <InterfaceName>s. Each type of InterfaceName would be documented similar to [[GOCDB/Input_System_User_Documentation#Service_types|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).
Line 25: Line 25:
==PI Examples==
==PI Examples==
Query String:
Query String:
https://goc.egi.eu/gocdbpi/private/?method=get_service_endpoint&InterfaceName=ldap.RIS
https://goc.egi.eu/gocdbpi/private/?method=get_service_endpoint&InterfaceName=RIS


<source lang="XML">
<source lang="XML">
Line 46: Line 46:
       <ENDPOINT>
       <ENDPOINT>
         <URL>ldap://ce-cms.vinca.rs:2170/mds-vo-name=AEGIS10-VINCA-CMS,o=grid</URL>
         <URL>ldap://ce-cms.vinca.rs:2170/mds-vo-name=AEGIS10-VINCA-CMS,o=grid</URL>
         <InterfaceName>ldap.RIS</InterfaceName>
         <InterfaceName>RIS</InterfaceName>
       </ENDPOINT>   
       </ENDPOINT>   
   
   

Revision as of 14:12, 2 February 2012

<< 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 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. 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 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.

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 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 have 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

 <?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>