[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [OASIS Issue Tracker] (OSLCCORE-9) Bootstrapping discovery
[ https://issues.oasis-open.org/browse/OSLCCORE-9?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Martin Pain updated OSLCCORE-9:
--------------------------------
Proposal:
Here's a draft of the proposal (in specification-like) form for review and possibly a vote by the TC at the Aug 6 meeting.
------------------------------------ The Proposal ----------------------
In order for end users or tool integrators to leverage OSLC Discovery capabilities, they must have a URI that establishes a starting point. A starting point could be a URI to a Service Provider Catalog, or a URI to a particular LDPC. Either of these URIs would allow a client to discover other URIs and capabilities that may be exploited to meet their needs.
OSLC Core Discovery specifies how to discover capabilities. But there also needs to be a standard way of determining the URIs a client would need to know in order discover the supported capabilities. By convention, some OSLC servers utilize a rootservices document at the root of the server URI that contains properties whose value is the URI for a service provider catalog. LDP specifically states that it does not define how clients discover LDPCs (see LDP 1.0, section 5.2.1). Tool integration is simplified by providing a standard way of discovering URIs that are intended to support discovery of capabilities provided by an OSLC compliant server.
A user or client application of course has to know some URI in order to access a server at all. This URI would include the supported protocol, host name, port, path and any other URI components the server requires. Often servers will have some well-known home page, often ‘/‘, that provides and entry point into hyper-linked content provided by that server. This URI may not be the root discovery URI itself, but can provide a means of discovering root discovery URIs.
1. Servers SHOULD include one or more Link: <discovery-URI>; rel=“http://open-services.net/nx/core#resourceDiscoveryRoot”; headers on an HTTP GET, HEAD, or OPTIONS request on the server’s advertised or default home page. The discovery-URI is the URI of a ServiceProviderCatalog resources, ServiceProvider resources or LDPC that can be used for subsequent discovery of OSLC capabilities.
2. The Link: <discovery-URI>; rel=“http://open-services.net/nx/core#resourceDiscoveryRoot”; headers SHOULD allow discovery of all OSLC resources and capabilities on that server either directly, or indirectly through referenced ServiceProviderCatalogs and/or contained LDPCs.
3. Servers MAY provide Link: <discovery-URI>; rel=“http://open-services.net/nx/core#resourceDiscoveryRoot”; headers on an HTTP GET, HEAD, or OPTIONS request on other URIs that are likely to be seen to represent the OSLC server's root or the OSLC server as a whole. These different URIs could represent a partitioning of the OSLC resources and capabilities provided by the server.
was:
Here's a draft of the proposal (in specification-like) form for review and possibly a vote by the TC at the Aug 6 meeting.
------------------------------------ The Proposal ----------------------
In order for end users or tool integrators to leverage OSLC Discovery capabilities, they must have a URI that establishes a starting point. A starting point could be a URI to a Service Provider Catalog, or a URI to a particular LDPC. Either of these URIs would allow a client to discover other URIs and capabilities that may be exploited to meet their needs.
OSLC Core Discovery specifies how to discover capabilities. But there also needs to be a standard way of determining the URIs a client would need to know in order discover the supported capabilities. By convention, some OSLC servers utilize a rootservices document at the root of the server URI that contains properties whose value is the URI for a service provider catalog. LDP specifically states that it does not define how clients discover LDPCs (see LDP 1.0, section 5.2.1). Tool integration is simplified by providing a standard way of discovering URIs that are intended to support discovery of capabilities provided by an OSLC compliant server.
A user or client application of course has to know some URI in order to access a server at all. This URI would include the supported protocol, host name, port, path and any other URI components the server requires. Often servers will have some well-known home page, often ‘/‘, that provides and entry point into hyper-linked content provided by that server. This URI may not be the root discovery URI itself, but can provide a means of discovering root discovery URIs.
1. Servers SHOULD include one or more Link: <discovery-URI>; rel=“http://open-services.net/nx/core#resourceDiscoveryRoot”; headers on an HTTP GET, HEAD, or OPTIONS request on the server’s advertised or default home page. The discovery-URI is the URI of a ServiceProviderCatalog resources, ServiceProvider resources or LDPC that can be used for subsequent discovery of OSLC capabilities.
2. The Link: <discovery-URI>; rel=“http://open-services.net/nx/core#resourceDiscoveryRoot”; headers SHOULD allow discovery of all OSLC resources and capabilities on that server either directly, or indirectly through referenced ServiceProviderCatalogs and/or contained LDPCs.
3. Servers MAY provide Link: <discovery-URI>; rel=“http://open-services.net/nx/core#resourceDiscoveryRoot”; headers on an HTTP GET, HEAD, or OPTIONS request on other URIs that are likely to be seen to represent the OSLC server's root or the OSLC server as a whole. These different URIs could represent a partitioning of the OSLC resources and capabilities provided by the server.
---------------------------- Additional Background -------------------------
My proposal is:
- We define a URI "http://open-services.net/ns/core#resourceDiscoveryRoot"; (note that this is a change in name from the email) to be used as a Link header "rel" URI, where the value of that Link header is the URI pointing to a ServiceProviderCatalog.
- We add to the discovery spec that servers MUST (maybe SHOULD) include that Link header on responses to OPTIONS requests to their web UI home page. The Link header MUST point to a ServiceProviderCatalog. That ServiceProviderCatalog SHOULD allow discovery of all OSLC resources on that server through any of: links to other ServiceProviderCatalogs, links to ServiceProviders, links to LDPCs and/or links to QueryCapabilities.
- We also add to the spec that servers MUST (maybe SHOULD) include that Link header on responses to OPTIONS requests for "any URI that is likely to be seen to represent the OSLC server's root or the OSLC server as a whole". (As this is rather subjective we could make it a non-normative suggestion instead).
Secondary proposal:
- We define a URI "http://open-services.net/ns/core#scopedResourceDiscovery"; (note that this is a change in name from the email) to be used as a Link header "rel" URI, where the value of that Link header is the URI pointing to a ServiceProviderCatalog for the same "scope" as the page it was linking from.
- We add to the discovery spec that when servers split their resources up into different scopes (e.g. teams, projects, tenants) within one server, then the home page for each of those projects MAY use this URI to point to a ServiceProviderCatalog which has the same scope as that page. For example, a project's home page can use it to link to the ServiceProviderCatalog for that project.
- This means that when giving the home page for a project to a client, the client can then say something like "You gave me the link for the 'Project X' scope. By default I'll look in there for resources, but if you want to look in a different project or across the whole server then <click here> (or <change this setting>)."
> Bootstrapping discovery
> -----------------------
>
> Key: OSLCCORE-9
> URL: https://issues.oasis-open.org/browse/OSLCCORE-9
> Project: OASIS OSLC Lifecycle Integration Core (OSLC Core) TC
> Issue Type: Task
> Reporter: Martin Pain
> Assignee: James Amsden
>
> See https://lists.oasis-open.org/archives/oslc-core/201503/msg00016.html
> The problem is about the user experience's when configuring OSLC clients to connect to OSLC servers. I think having to search a server's documentation and UI to find a discovery URI that is used only once is not a good user experience, and this will come very early in new users' experimentation with OSLC (both developers and administrators).
> The resource the client wants is the "root" ServiceProviderCatalog. The user will be aware of the idea of URIs representing resources, but the resource in their mind is the server, and the URI they associate with the server is most likely the home page of its web UI. So I suggest we define a Link header rel that is used to link that web UI URI to the ServerProviderCatalog URI.
> So then the user's experience will be:
> - They are reading the client's instructions for integrating with OSLC servers.
> - It says to enter the URI to the server's home page.
> - The user copies that from their browser and enters it into the client.
> - The client finds what it needs on the server. (Under the covers: they do a OPTIONS request on the URI that was provided, follow the Link header that has the rel that we define, and request that URI with an Accept header for the content types that they support, and receive the root ServiceProviderCatalog).
> So my proposal is:
> - We define a URI "http://open-services.net/ns/core#resourceDiscoveryRoot"; (note that this is a change in name from the email) to be used as a Link header "rel" URI, where the value of that Link header is the URI pointing to a ServiceProviderCatalog.
> - We add to the discovery spec that servers MUST (maybe SHOULD) include that Link header on responses to OPTIONS requests to their web UI home page. The Link header MUST point to a ServiceProviderCatalog. That ServiceProviderCatalog SHOULD allow discovery of all OSLC resources on that server through any of: links to other ServiceProviderCatalogs, links to ServiceProviders, links to LDPCs and/or links to QueryCapabilities.
> - We also add to the spec that servers MUST (maybe SHOULD) include that Link header on responses to OPTIONS requests for "any URI that is likely to be seen to represent the OSLC server's root or the OSLC server as a whole". (As this is rather subjective we could make it a non-normative suggestion instead).
> Secondary proposal:
> - We define a URI "http://open-services.net/ns/core#scopedResourceDiscovery"; (note that this is a change in name from the email) to be used as a Link header "rel" URI, where the value of that Link header is the URI pointing to a ServiceProviderCatalog for the same "scope" as the page it was linking from.
> - We add to the discovery spec that when servers split their resources up into different scopes (e.g. teams, projects, tenants) within one server, then the home page for each of those projects MAY use this URI to point to a ServiceProviderCatalog which has the same scope as that page. For example, a project's home page can use it to link to the ServiceProviderCatalog for that project.
> - This means that when giving the home page for a project to a client, the client can then say something like "You gave me the link for the 'Project X' scope. By default I'll look in there for resources, but if you want to look in a different project or across the whole server then <click here> (or <change this setting>)."
--
This message was sent by Atlassian JIRA
(v6.2.2#6258)
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]