Working in a heterogeneous software environment sometimes feels frustrating. Users need ways to relate the information inside every tool of their toolchain, without caring much for the how. OSLC, standing for Open Services for Lifecycle Collaboration, is a set of specifications that offer an answer to this very business need, which leverages Linked Data. Its intent is to provide seamless integration between tools through specified services and interfaces.
This article serves both as education on this solution, as well as a clarification of the vocabulary that you will come across in SodiusWillert’s documentation and Journeys.
Note that by server OSLC application, we mean an application which is exposing its artifacts through an OSLC API. And by client OSLC application, we mean an application which is consuming the artifacts exposed by a server OSLC application. We will use artifact or resource to represent the application’s data exposed through the OSLC API.
Benefits of Collaboration Using OSLC
Seamless integration offered by OSLC can provide you with the ability to:
create links to existing resources in the server OSLC application,
create resources in the server OSLC application and automatically link them to your local resource,
navigate to the linked resources,
visualize a live preview of the linked resource,
visualize certain properties of your linked resources in line with their title,
enable cross-tool reporting of lifecycle artefacts.
Business Concepts and defintions
OSLC covers the whole scope of lifecycle domains for Application Lifecycle Management (ALM). Some of these domains can also be used to represent the artifacts of the Products Lifecycle Management (PLM).
Also known as RM, Requirement Management defines artifacts related to the specification phases of projects. Requirements Management resources include Requirements, Requirements Collections, and supporting resources.
Also known as AM, Architecture Management defines artifacts related to the modeling phases of projects. This domain addresses the management of product design artifacts including models, and relationships with other resources such as requirements, testing resources, and change requests
Also known as QM, Quality Management addresses the testing phases of projects. This domain defines the test plans, test cases, and test results resources of the software delivery lifecycle.
Also known as CM, Change Management addresses the planning and evolution of projects. It goes for the management of product change requests, activities, tasks, and relationships between those and related resources such as project, category, release, and plan.
All these domains are associated through a set of link types describing the OSLC traceability model, simplified below:
This particular domain defines how to represent versions of domain resources, and how to aggregate them in cohesive sets (configurations), either mutable (streams) or immutable (baseline).
Different solutions exist to this use case. One specification called TrackedResourceSet, short TRS, exists to enable such a feature of cross-tool reporting over the whole lifecycle.
Technical Concepts and definitions
To enable collaboration with OSLC, you will:
firstly, connect 2 applications in your toolchain, which is called friending. One OSLC application, which acts as a client, needs to be authorized, and if needed be authenticated, to another OSLC application, which acts as a server. The RootServices document contains useful information to enable this.
secondly, connect projects of each application together through creating a project association. That project association enables either a few or any link types. A link type represents a relationship, either inside a domain or between 2 domains.
finally, when navigating a resource of such domains, you will now be offered to create collaboration links to a remote artifact
Discovery through the RootServices document
The rootservices document is a publicly accessible document that enables the discovery of available authorization schemes, as well as domain catalogs of data. This document is leveraged to simplify creating the below configurations. You can find more details on the IBM specification for the rootservices document on Jazz.net.
You’ll see that when a client OSLC application creates a friend to a server OSLC application, this usually generates consumer (pending approval) in the server OSLC application. When properly configured, this allows for all the Linked Data interactions provided by OSLC.
A friend represents a server OSLC application that makes its information available to this client OSLC application using an authorized friend application user.
In other words, a friend in the client OSLC application is the declaration of intent to leverage the server OSLC application’s data for collaboration.
A consumer represents the authorization for a client application to consume the information of this OSLC application using an authorized Jira user.
In other words, a consumer is the authorization given to a client OSLC application to use the application’s data for collaboration.
Associations, or Project Associations, is how a project is allowed to leverage artifacts of another project. Associations can be bound to underlying business domains, or enable collaboration throughout all the domains supported by the OSLC application. The OSLC Traceability Model is part of the specifications.
A collaboration link represents a semantic relation between two artifacts, usually hosted in different repositories (or projects).
When selecting an artifact in the remote project for creating a link, we are leveraging what is called a Selection Dialog. The Selection Dialog is provided by the server OSLC application.
When creating an artifact in the remote project, we are leveraging what is called a Creation Dialog. The Creation Dialog is provided by the server OSLC application.
When previewing an artifact from a remote project, we are leveraging what is called a Preview. The Preview is provided by the server OSLC application, so that client applications don’t have to care how to present every particular artifact from every other tool. Some tools provide us with two previews of different sizes: the small preview, and the large preview.