|
|
(3 intermediate revisions by 2 users not shown) |
Line 1: |
Line 1: |
| [[Category:GOCDB]] | | [[Category:GOCDB]] |
| << Back to [[GOCDB/Documentation_Index]] <br/>
| | Moved to [[GOCDB/Release4/Development/MultipleEndpointsPerService]] |
| << Back to [[GOCDB/Release4/Development]] <br/>
| |
| | |
| <!--
| |
| [10:36:31] Marian Babik @David: can you confirm that this applies in general for any services ? Since https://rt.egi.eu/rt/Ticket/Display.html?id=3347 suggests this is only for information system endpoints.
| |
| [10:41:56] david meredith hi Marian, yes, multiple endpoints per service would apply to all service types – of course we need to have a new list of InterfaceName values used to distinguish between those endpoint URLs
| |
| [10:47:18] Marian Babik So while discussing this with Pedro, we assumed this is only for IS. Let me re-discuss, but I'm affraid this won't be easy for SAM since we use (service_type, service_endpoint) to match (service_type, test) throughout the system. We assume tests are written for particular service_type (not endpoint type/interface_type).
| |
| [10:50:00] david meredith I see, so you would need to determine your test based on service_type & intefaceName = test
| |
| [10:51:04] Marian Babik yes, exactly
| |
| -->
| |
| =Multiple Endpoints=
| |
| ==Introduction==
| |
| 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.
| |
| <!--# 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). -->
| |
| | |
| 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 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 [[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).
| |
| | |
| ==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>).
| |
| | |
| <source lang="XML">
| |
| <?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>
| |
| </source>
| |
| | |
| <!--
| |
| <ENDPOINT InterfaceName="RIS">
| |
| <URL>ldap://ce-cms.vinca.rs:2170/mds-vo-name=AEGIS10-VINCA-CMS,o=grid</URL>
| |
| <ENDPOINT>
| |
| <GRIS_ENDPOINT>
| |
| <URL>ldap://ce-cms.vinca.rs:2170/mds-vo-name=AEGIS10-VINCA-CMS,o=grid</URL>
| |
| <GRIS_ENDPOINT> -->
| |
| | |
| == Status 10.05.12 ==
| |
| 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.
| |