[OASIS Issue Tracker] (OSLCCORE-53) Does a ServiceProvider have one Service per oslc:domain value, or does it reflect the server's desired container structure.

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

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

James Amsden commented on OSLCCORE-53:
--------------------------------------

Agree with Nick, there's no reason a domain can't be supported with multiple Service resources, possibly each having a different oslc:usage. But a Service resource must have exactly one domain. 

Martin points out that Link headers can be used for discovery on ServiceProviderCatalog LDPCs (whose members are ServiceProviders) and Service LDPCs (whose members are Services). 

However, even though Service is an LDPC, we don't specify what its members are, so clients can't rely on consistent discovery through Link headers, they must instead use the Service creationFactory properties.

Let's consider two cases: one where the Service members are the domain resources, and another where they are not.

1. Service members are domain resources - in this case, the members of the service are either other LDPCs supporting discovery and/or LDPRs defined by the domain. So OSLC 2.0 SPC discovery and OSLC 3.0 Link discovery are both supported and would provide the same discovery information.

2. Service members are not domain resources - that is, the members of the Service are not defined by OSLC and could be anything. Link discovery could be used to see what the membrers are and what OSLC services the support, and this might not have anything to do with the Service domain. A server could for example keep caches, admin information or anything else as members of the Service.

In this case, v2 SPC and v3 Link discovery are possibly still supported, but perhaps not from the same server path structure.

2.a. A v2 client would use SPC discovery and expect the creationFactory to be a property of the Service.

2.b. A v3 client could still use the Link headers for discovery, but would start from the containment hierarchy for the LDPC specified in the Service creationFactory creation URI, not  the ServiceProviderCatalog URI. 

That is, the containment hierarchy for v2 SPC/SP/Service discovery may be completely disjoint from the actual containment hierarchy for the resources themselves.

I don't see any real value in requiring these two hierarchies to coincide. I agree if they did, v2 and v3 discovery would be unified. But I'm not sure we care. It only makes a difference for v3 clients that want to do part of the discovery with ServiceProviderCatalog and ServiceProvider resources and do other discovery with Link headers. I would think most v3 clients would do one or the other and not mix them.

So I don't see any problem with not specifying what the members of a Service are, and allowing servers to put LDPCs and domain resources as members if they wish to. 

> Does a ServiceProvider have one Service per oslc:domain value, or does it reflect the server's desired container structure.
> ---------------------------------------------------------------------------------------------------------------------------
>
>                 Key: OSLCCORE-53
>                 URL: https://issues.oasis-open.org/browse/OSLCCORE-53
>             Project: OASIS OSLC Lifecycle Integration Core (OSLC Core) TC
>          Issue Type: Bug
>            Reporter: Martin Pain
>            Assignee: James Amsden
>
> In OSLCCORE-23 we agreed that a Service resource should be an LDPC, but didn't state what its members were. My reading of that ticket's proposal is that the members are defined by the domain.
> In recent emails, there has been a discussion about what the members of a Service should be. My latest comments that triggered me to raise this ticket:
> According to OSLCCORE-23, we agreed that "Service is the point at which Domain specifications specify their specific service capabilities." - which suggests the tie between domains and Service resources. Of course, it doesn't have to be an OSLC-defined domain, but in my opinion it must be a value of the oslc:domain property on the Service. And that it is unreasonable to expect clients to be able to work with two Service resources with the same oslc:domain value, unless explicitly permitted by that domain.
> So I think we have a question to answer, which probably requires its own ticket: Do we keep the one-to-one relationship between Service resources and oslc:domain values from v2 (within the context of a single SP, and if that understanding of v2 is correct), or do we redefine it and suggest/require that a Service is one-to-one with an LDPC (if not exactly the same resource) in the server's desired organisation of containers?
> The benefit of the former is that clients have fewer options to present to users, and that v3 servers are more likely to work with v2 clients (although that could do with verification). The benefit of the latter is that the server's organisation of containers is exposed in the OSLC data, but this comes at the cost of complexity for the clients.



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