[oslc-core] v1 Service Descriptions vs v2 Services
Steve K Speicher
sspeiche at us.ibm.com
Thu Jun 17 08:58:08 EDT 2010
Thanks for the feedback Jim. Adding the oslc-cm to this thread as it is
both of CM and Core interest. Comments below...
Thanks,
Steve Speicher | IBM Rational Software | (919) 254-0645
Jim des Rivieres <Jim_des_Rivieres at ca.ibm.com> wrote on 06/15/2010
05:17:55 PM:
> From: Jim des Rivieres <Jim_des_Rivieres at ca.ibm.com>
> To: oslc-core at open-services.net
> Date: 06/15/2010 05:18 PM
> Subject: [oslc-core] v1 Service Descriptions vs v2 Services
> Sent by: oslc-core-bounces at open-services.net
>
> Doing a side-by-side comparison of the upper-level superstructure of the
> v1 and v2 OSLC CM specs, I noticed two things.
>
> (1) In v1 Service Provider Catalog representation, the
> oslc_disc:ServiceProvider element has an oslc_disc:details with a
> rdf:resource attribute giving "the URI of a browsable resource providing
> details of the service provider or catalog." For RTC, this was the URI
of
> a particular project area.
>
> I couldn't find any counterpart to this in the v2 CM or Core specs. Was
> this an intentional omission? I.e., do we believe that it's no longer
> needed?
>
I believe you are saying it is still needed. Perhaps in an attempt to
simplify, it got dropped.
I will take the action to add this back, barring any objections.
> (2) In a v1 Service Provider Catalog, the catalog entries reference v1
> Service Provider resources as local, inline resources; these v1 Service
> Provider resources reference v1 Service Description resources as regular
> resources. In v1, a particular Service Description resource is
associated
> with a particular domain. E.g., it will be a CM Service Description
> resource.
>
> In a v2 Service Provider Catalog, the catalog entries reference v2
Service
> Provider resources as regular resources; these v2 Service Provider
> resources reference v2 Service resources as local, inline resources. In
> v2, a particular Service resource is associated with a particular
domain.
> A v2 Service Provider resource is designed to reference multiple and
> heterogenous v2 Services.
>
> Selecting from a v1 Service Provider Catalog yields the URI of a v1
> Service Description resource. The analogous selection from a v2 Service
> Provider Catalog would yield the URI of a v2 Service resource. However,
> since v2 Service resources are inlined into the v2 Service Provider
> document, the only available URIs for these are ones with fragment '#'
> identifiers that select a node based on its rdf:nodeID.
>
In an attempt to simplify the model in v2, we pushed some of the
information that was in the v1 ServiceProvider inline local resource and
consolidated the SeviceDescriptor into the v2 resource definition of
ServiceProvider.
In v1, you'd have:
ServiceProviderCatalog (URI)
+- ServiceProvider
+- service (URI) -> ServiceDescriptor
+- changeRequests
In v2, you'd have:
ServiceProviderCatalog (URI)
+- serviceProvider (URI) -> ServiceProvider
+- Service
+- domain = "
http://open-services.net/xmlns/cm/2.0#"
> Two issues I can see with this:
>
> (a) It means that all clients that dereference v2 Service resources are
> responsible for interpreting the fragment identifier and using it to
> locate the element with that rdf:nodeID. This is clunky for clients of
the
> v2 protocol.
This is not intended way for it to work.
> (b) It's impossible to claim that the URI of a v1 Service Description
> resource is also the URI of a v2 Service resource - the latter has a
> fragment identifier; the former does not. A cross-application "project
> links" that starts off referencing a v1 CM Service Description resource
> would end up referencing a v2 Service Provider resource, rather than a
v2
> Service resource, once the target server is upgraded to add support for
CM
> v2 under the existing CM v1 URIs.
The URIs are intended to be stable. If you want additional information
from the v2 ServiceProviderCatalog about a ServiceProvider, a client can
request that information to be "inlined" using oslc.properties.
I'll take the action to define this clearly in the CM 2.0 spec section of
compatibility
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://open-services.net/pipermail/oslc-core_open-services.net/attachments/20100617/49d2ac81/attachment-0003.html>
More information about the Oslc-Core
mailing list