In our previous blog on OSLC, we introduced the OSLC specifications and how they improve integrations and traceability across ALM tools. In this blog, we will dive a bit deeper into how these applications find each other through OSLC Discovery.

OSLC Discovery defines a sequence of endpoints that lets a consumer tool dynamically explore what a provider offers:
• RootServices
• ServiceProviderCatalog
• ServiceProvider Service

In this post, we’ll break down how Discovery works, draw a real-world analogy using streaming platforms, and end with a practical example connecting IBM DOORS Next and ETM. 

Imagine trying to find your favorite movie. You check Netflix and no luck. You jump to Prime Video, then Disney+, only to discover that the movie you want is on a different platform. Each platform has its own catalog, its own interface, and no common way to search them all at once. Frustrating, right? 

Engineering teams face the same challenge. Each ALM tool (requirements, change management, test management) is a silo with its own API.

Without OSLC Discovery, your applications don’t even know what each other can do.

OSLC Discovery solves this problem by creating a standardized way for tools to:
• Expose what they provide (services, domains, resources, capabilities).
• Let others discover them dynamically, no hardcoding of URLs.
• Build trust, link data, and collaborate seamlessly.

To solve this “streaming problem,” some third-party applications, let’s call them Streaming Hubs, collect the catalogs of popular streaming platforms, listing them as separate catalogs per platform, but also enabling global search and pointing the user to where to find the movies and TV shows they want.

In the OSLC world, IBM ELM uses RootServices as an entry point for each application, and then the serviceProviderCatalog acts as a “Streaming Hub”, listing all the providers (Project Areas) your application has.

What it is:
A top-level document (typically /rootservices) that lists the URLs of main catalogs and OAuth endpoints.

Although not part of the OSLC Core 3.0 specification, it’s widely used, especially in IBM ELM, which defined the RootServices specification, and is recommended as a discovery starting point.

Why it matters:
It gives consumers a single URL to start discovery without needing to know specific catalogs.

Example: GET https://elm.example.com/rm/rootservices
Returns RDF data listing serviceProviderCatalogs, OAuth request/access URLs, and version info. 

Purpose:
The entry point defined by OSLC Core 3.0. It contains one or more oslc:ServiceProvider entries.

Analogy:
Think of it as a Streaming Hub like JustWatch.

Example: GET https://elm.example.com/rm/oslc_rm/catalog Lists available service providers (projects, components, etc.) 

Purpose:
Each ServiceProvider describes the services available for a specific project, component, or domain, as defined by the application’s catalog structure.

Contains:
• oslc:Service elements (each representing a domain, e.g., Requirements or Change Management).
• oslc:details and metadata (title, description).

Analogy:
Think of it as streaming platforms like Netflix and Prime Video. 

Purpose:
Defines what you can do and where:
• QueryCapability → search and retrieve resources.
• CreationFactory → create new resources.
• Delegated UIs → embedded dialogs to select or create resources interactively.

Analogy:
Think of it as the genres inside a Netflix catalog (e.g., Comedy, Drama, Adventure), each exposing resources of interest: movies and TV shows. In OSLC terms, it exposes API endpoints for querying and creating OSLC resources. 

Before any discovery works across secure environments, a consumer must establish trust with the provider:

• Discovery (rootservices) often lists OAuth endpoints (request token, access token, authorization).
• The friendship step lets the consumer register and gain authorized access.
• Once trust is set, discovery and subsequent resource access follow the OSLC standard securely. 

Let’s see discovery in action in a real integration scenario:

RootServices
• DOORS Next (provider) exposes /rm/rootservices.
• ETM (consumer) fetches it to find the ServiceProviderCatalog URI and OAuth endpoints.
• We can see it in action when we are friending an application in IBM ETM. We provide the DNG rootservices URL, and then ETM will automatically discover the OAuth endpoint and establish trust: 

ServiceProviderCatalog 
• ETM requests the catalog → gets a list of ServiceProviders (e.g., each DNG project).
• IBM DNG catalog contains a service provider for each Project Area. We can check the catalog being consumed when we try to create an association with DNG from an ETM Project Area:

ServiceProvider
• ETM requests the serviceProvider → gets a list of Services (e.g., creation and query capabilities, dialogs).
• We can check the serviceProvider in action when we try to create a link from an ETM test case to a DGN requirement, as an example. The link dialog lets you choose the DNG Project Area (ServiceProvider). With the service provider selected, it fetches the OSLC Delegated Dialog URL and displays it in an iframe to list the DNG requirements:

Without Discovery, your applications are like streaming platforms with isolated catalogs, and users never know where to find what they need. With Discovery, there’s a central hub that lets every app know what exists, where it lives, and how to reach it.

Discovery is the first handshake in the OSLC world; it’s how tools recognize, trust, and explore each other’s capabilities. Once you can discover services, linking and querying become the natural next steps.

Want your applications to speak the same language and find each other automatically? Reach out to us.

We can help you design OSLC discovery and linking workflows that make your ecosystem audit-ready and future-proof.