OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

oslc-core message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: [OASIS Issue Tracker] (OSLCCORE-20) Service provider should describe domain/scope

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

James Amsden commented on OSLCCORE-20:

There are three possible ways a client could get information about a project area:

1. Use a v2 Service Provider Catalog available at a known "rootservices" URI, and use that to get the Service Provider descriptions (the project areas), and for each of those, the Services description for what services are provided by that service provider. Everything is accessed from one rootservices URI, can be accessed at the beginning of the application, and refreshed periodically if the service providers or services change over the execution lifetime of the application. This is the typical v2 discovery scenario.

2. If the client knows the URI of the project area, then v3 discovery could be used to dynamically and incrementally discover the available services on the project area using LDP-C link headers. This is the typical v3 discovery scneario.

3. I think Martin is hinting at a third, perhaps hybrid solution. Given a URI of the project area, the client could do a GET with an Accept header that indicated the client wanted to get the service provider description for that project area. The project area and its service descriptor are at the same URI and content negotiation would be used to get the project are content (a list of Change Request for CM) or its service description. Martin, did I get that right? 

I'm not sure content negotiation is the right solution here. A container and a description of a container are quite different things. Maybe they should have related, but not the same URIs since they are different resources and have different resource representations. Content negotiation is for the client to request the form of the resource, not different resource. But I could be looking at it too restrictively.

> Service provider should describe domain/scope
> ---------------------------------------------
>                 Key: OSLCCORE-20
>                 URL: https://issues.oasis-open.org/browse/OSLCCORE-20
>             Project: OASIS OSLC Lifecycle Integration Core (OSLC Core) TC
>          Issue Type: Improvement
>            Reporter: David Honey
>            Assignee: James Amsden
> OSLC 2.0 supports a service declaring a domain or scope using oslc:domain and oslc:usage. Jazz applications frequently declare a service provider for each project area. However, there is no standard way for a client to determine which service provider to use for a known project area.

This message was sent by Atlassian JIRA

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]