[OASIS Issue Tracker] (OSLCCORE-46) Discovery of services through query rather than LDPC traversal

[OASIS Issues Tracker <workgroup_mailer@lists.oasis-open.org>]

    [ https://issues.oasis-open.org/browse/OSLCCORE-46?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=61181#comment-61181 ] 

James Amsden commented on OSLCCORE-46:
--------------------------------------

Since ServiceProviderCatalog, ServiceProvider and Service are LDPC, the OSLC2 resource-based and the OSLC3 link-based discovery mechanisms are now unified. An OSLC3 client can iterate over OPTIONS requests on LDPCs, or do a GET on some LDPC that is also a ServiceProvider (assuming the server chooses to support that). In this case the Services are all provided inline in the entity response body, so the client gets all the information about that LDPC in a single request. 

It is up to the server to determine how its discoverable resources are organized. It should do so based on typical usage scenarios and take into consideration network latency and other QOS concerns.

> Discovery of services through query rather than LDPC traversal
> --------------------------------------------------------------
>
>                 Key: OSLCCORE-46
>                 URL: https://issues.oasis-open.org/browse/OSLCCORE-46
>             Project: OASIS OSLC Lifecycle Integration Core (OSLC Core) TC
>          Issue Type: New Feature
>            Reporter: David Honey
>            Assignee: James Amsden
>
> The proposed 3.0 discovery requires that clients traverse a hierarchy of LPDCs to find service(s) of interest. Some OSLC 2.0 clients may [erroneously] assume they can discover such services through a single GET of the service provider catalog. When the OSLC client has significant network latency with the OSLC provider, having to iteratively GET LDPCs might lead to slow discovery performance. 



--
This message was sent by Atlassian JIRA
(v6.2.2#6258)