Is DNG regulating OSLC provider links?
I'm getting the impression that DNG is regulating OSLC provider link resource types.
One reason is the OSLC provider doesn't always show up as an option in the "Create Link" pop up window. For example, if the link type is "Satisfies" the OSLC-CM provider is not an option. But it is an option if the link type is "Affected By". This doesn't make sense because I can select the option to create a "Web" link in the UI for almost every link type.
Another issue is I have a OSLC client that creates links in DNG and it works fine every time regardless of the link type. The HTTP status is always 200 after I update the resource. The problem is when you go to the DNG UI and look for the link and it's not there but for some link types like "Elaborated By" the link is there. Why would DNG send back a 200 if the link isn't actually created? Or maybe it does get created in the DNG DB but the UI filters it out. Who knows?
Finally, while trouble shooting another issue I came across the JS code below where it appears DNG can only handle or expects certain OSLC spec types...
_getResourceElement:function(_52,_53,_54,_55){So what do you do as an OSLC provider that wants to create links via a Delegated UI to resources other than what's in the OSLC-RM/AM/CM/QM spec's? What if I wanted to produce a OSLC-CM config provider and allow the DNG user to select a OSLC VersionReference as a "Satisfies" link? It appears the client side JS just won't allow it.
var _56=null;
if(_52!=null){
var _57=null;
switch(_54){
case _3.SYSTEM_LINK_TYPE_IMPLEMENTED_BY:
case _3.SYSTEM_LINK_TYPE_TRACKED_BY:
case _3.SYSTEM_LINK_TYPE_AFFECTED_BY:
if(_55){
_57="http://open-services.net/ns/cm-x#Plan";
}else{
_57="http://open-services.net/ns/cm#ChangeRequest";
}
break;
case _3.SYSTEM_LINK_TYPE_VALIDATED_BY:
_57="http://open-services.net/ns/qm#";
_57+=_55?"TestPlan":"TestCase";
break;
case _3.SYSTEM_LINK_TYPE_DERIVES:
case _3.SYSTEM_LINK_TYPE_SATISFY:
case _3.SYSTEM_LINK_TYPE_TRACE:
case _3.SYSTEM_LINK_TYPE_REFINE:
_57="http://open-services.net/ns/am#Resource";
break;
case _3.SYSTEM_LINK_TYPE_REFERENCES:
_57="http://open-services.net/ns/rm#Requirement";
break;
}
Is there a list anywhere that reflects what OSLC provider specs DNG can consume? Is there a list of what OSLC resource types can leverage what DNG link type? Can DNG even support linking to the OSLC-CM config spec resources?
It's a lot to ask but I hope someone will enlighten me.
Accepted answer
Yes, DNG does control its OSLC link types (as do the other Jazz applications as RTC and RQM). If you look at the link types tab for DNG project/component properties, you can see that the OSLC links are system defined, and have a RDF URI that has a namespace of http://open-services.net/ns/rm. Likewise with the RM internal links types.
This enables DNG to ensure what kind of objects will be at the other end, which can be interrogated as Linked Data and adheres to OSLC REST operations (GET/POST/PUT/DELETE) etc. And with that you can do proper querying and reporting, viewing artifacts with trace-ability and link validity, etc. With a web link, you have no guarantee what's at the other end of the link.
Probably someone can give a more formal answer, but this should give you a good idea.
Comments
Bas, thank you. That is very helpful.
Are there any limitations on which OSLC domains DNG is capable of consuming?
Actually Jim Amsden answer was good here, maybe somewhat heavy on details, but the crux is when you add an association between DNG and other application project areas (including other DNG instances), you can select an application on a friended server, select the project area artifact container to associate with, and by DNG will check which association types are available through the service provider and matching system defined OSLC links. I think the matching takes place on the RDF URI defined on the link types.
So far as I know, DNG can do OSLC linking with DNG itself, RTC, RQM, RDM, DOORS (Classic) and other applications while the implement their OSLC services properly, ie comply with the OSLC spec for the domain they cover. On this page you can see the OSLC domains currently available.
Matthew, also see this Knowledge Center entry on links: DNG link types
2 other answers
RDNG (and all the jazz CLM apps) use Friend relationships to connect to other OSLC servers using OAuth authentication. When a friend is established, the rootservices URL to the server is provided, and the OAuth provisional consumer key is created, and accepted. The rootservices document, which is not part of the OSLC standard, specifies a number of links to OSLC Service Provider Catalogs that are provided by the Friend server. This is how the Jazz apps initiate OSLC discovery.
I defer to Jim here.
So what do you do as an OSLC provider that wants to create links via a Delegated UI to resources other than what's in the OSLC-RM/AM/CM/QM spec's? What if I wanted to produce a OSLC-CM config provider and allow the DNG user to select a OSLC VersionReference as a "Satisfies" link? It appears the client side JS just won't allow it.
(If you code this up and it works, share here your implementation. Like you, I'm in the midst of trying to implement an OSLC AM Provider that is OSLC Config savvy which DNG happily couples with.)
Comments
By the way, slightly related curiousity here. I'm implementing the OSLC CM ServiceProvider and its OSLC CM Services. As a provider, I must expose a Creation Factory link to an LDP Container service (where the Components and the Baselines and Streams Configurations are to published).
- Turn off GC and run away
- Roll your own LDP Server capabilities
- Stand up Apache Marmotta and delegate to it
- Stand up Eclipse Lyo LDP Server and delegate to it
-
Use some other third-party LDP Server (which, may I ask?)