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"
| Line 6: | Line 6: | ||
As requested in ticket https://rt.egi.eu/rt/Ticket/Display.html?id=3347. The Top-BDII needs the URL of each service endpoint's GRIS in order to retrieve information about the endpoint. The GRIS URL for each endpoint is to be stored in GOCDB. | As requested in ticket https://rt.egi.eu/rt/Ticket/Display.html?id=3347. The Top-BDII needs the URL of each service endpoint's GRIS in order to retrieve information about the endpoint. The GRIS URL for each endpoint is to be stored in GOCDB. | ||
To achieve this we propose adding support for multiple <Endpoint> elements per service (the Endpoint element in turn wraps a <URL> | To achieve this we propose adding support for multiple <Endpoint> elements per service akin to GLUE2 (the Endpoint element in turn wraps a <URL> and a <Classification> - or a suitable GLUE2 equivalent - todo look this up). | ||
The classification flag serves to distinguish between a service’s different endpoint types and their intended purpose. For example, one Endpoint could define the service's GRIS URL with a classification value of "Resource Information Service", another Endpoint could define the actual service URL, whilst another could define an Endpoint URL for the admin portal of that service and so on..). | |||
==Implementation== | ==Implementation== | ||
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 to show multiple <Enpoint> elements (each nesting child <URL> and < | The GOCDB-PI output will be extended to show multiple <Enpoint> elements (each nesting child <URL> and <Classification> elements). Using this mechanism the Top-BDII can retrieve a filtered list of endpoints that have a URL with the requied classification (e.g. "Resource Information Service"). | ||
This is a more GLUE2 centric approach. Additional elements/attributes can be defined on each Endpoint if required. We may change the 'classification' element with a more suitable/alternative glue2 field (todo, check). | This is a more GLUE2 centric approach. Additional elements/attributes can be defined on each Endpoint if required. We may change the 'classification' element with a more suitable/alternative glue2 field (todo, check). | ||
Revision as of 12:49, 28 January 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. The Top-BDII needs the URL of each service endpoint's GRIS in order to retrieve information about the endpoint. The GRIS URL for each endpoint is to be stored in GOCDB.
To achieve this we propose adding support for multiple <Endpoint> elements per service akin to GLUE2 (the Endpoint element in turn wraps a <URL> and a <Classification> - or a suitable GLUE2 equivalent - todo look this up).
The classification flag serves to distinguish between a service’s different endpoint types and their intended purpose. For example, one Endpoint could define the service's GRIS URL with a classification value of "Resource Information Service", another Endpoint could define the actual service URL, whilst another could define an Endpoint URL for the admin portal of that service and so on..).
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 child <URL> and <Classification> elements). Using this mechanism the Top-BDII can retrieve a filtered list of endpoints that have a URL with the requied classification (e.g. "Resource Information Service").
This is a more GLUE2 centric approach. Additional elements/attributes can be defined on each Endpoint if required. We may change the 'classification' element with a more suitable/alternative glue2 field (todo, check).
PI Examples
Query String: https://goc.egi.eu/gocdbpi/private/?method=get_service_endpoint&Classification=Resource%20Information%20Service
<?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>
<CLASSIFICATION>Resource Information Service</CLASSIFICATION>
</ENDPOINT>
</SERVICE_ENDPOINT>