In the first post of this series, we introduced OSLC as the open standard that turns siloed ALM tools into one integrated system. In the second post, we explored how applications actually find each other through OSLC Discovery. Once two tools have found each other, someone has to speak, and someone has to listen. Someone has to ask, and someone has to answer. 

That's what this post is about. We'll define the two fundamental roles in every OSLC integration, the Provider and the Consumer. 

In a real engineering lifecycle, no tool is self-sufficient. A requirements management tool needs to know which test cases validate its requirements. A test management tool needs to know which requirements it's supposed to cover. A change management tool needs to know which requirements and tests a defect impacts. 

When these exchanges are scattered across different tools, every integration becomes a fragile, vendor-specific project. Upgrade one tool, and three integrations break. Swap a vendor, and you start from scratch. 

OSLC solves this by formalizing who exposes data and who requests it. Instead of building integrations, teams implement roles. A tool that plays the Provider role the OSLC way can be consumed by any OSLC Consumer, even ones that didn't exist when the Provider was built. Integration stops being a custom connection and becomes a contract. 

And like any good contract, it has two parties. 

Imagine a restaurant.  The kitchen owns the food, the recipes, and the plating. It decides what's on the menu, what's in season, and how each dish is prepared - the kitchen is the Provider.
 
The diner arrives hungry, they have a need, they scan the menu, and they place an order. The diner is the Consumer. 

Between them stands the waiter, who doesn't cook and doesn't eat, they carry requests one way and responses the other, following a predictable protocol. In OSLC, that role is played by the HTTP protocol. 

The menu tells the diner what the kitchen offers and at what price. In OSLC, the menu is the Service Provider Catalog, Service Provider, and its Services. 

The reservation and ID check at the door? That's OAuth Authentication. And the special diet and allergy notes? Those are Resource Shapes, constraints telling the diner exactly what the kitchen can and cannot accept. 

The beauty of this system is that any diner can eat at any restaurant. OSLC is the rulebook that makes it possible. 

A Provider is any application that exposes lifecycle data in an OSLC-compliant way. It is the source of truth for a set of resources (requirements, test cases, defects, work items, architectural elements, etc…) and it makes those resources available to other applications through standard interfaces. 

A Provider must: 
- Publish a Root Services document and/or Service Provider Catalog so Consumers can find it (covered in the previous post on OSLC Discovery).
- Expose Services describing what it offers, typically QueryCapability, CreationFactory, Delegated UIs, and Selection Dialogs.
- Publish Resource Shapes so Consumers know which fields exist, which are required, and which are optional.
- Support authentication, most commonly OAuth 1.0a and OAuth 2.0.
- Serve resources in standard RDF serializations (RDF/XML, Turtle, or JSON-LD).

Resources: the actual lifecycle artifacts (a requirement, a test plan, a change request).
Metadata: Resource Shapes, query capabilities, creation factories, selection dialogs.
Delegated UIs: compact and standard renderings that the Consumer can embed when displaying dialogs from the Provider.

- IBM DOORS Next: Provider of Requirements Management resources.
- IBM Engineering Test Management (ETM): Provider of Quality Management resources.
- IBM Engineering Workflow Management (EWM): Provider of Change Management resources.
- Jama Connect, Polarion, Windchill, CodeBeamer: Providers across several OSLC domains.

For the complete set of domain specifications a Provider may implement, see the OASIS OSLC domain specifications. 

A Consumer is any application that requests or uses resources exposed by one or more Providers. Where the Provider owns the data, the Consumer owns the need. 

A well-behaved Consumer must: 

- Discover the Provider via its Root - Services document and/or Service Provider Catalog.
- Authenticate with the Provider.
- Send correctly formed HTTP requests to the endpoints the Provider exposes.
- Parse RDF responses in whichever serialization the Provider returns.
- Act on the result usually by storing and persisting links. 

- Queries a Provider for resources, for example, "give me all requirements in project X tagged 'safety-critical'".
- Opens a Delegated UI so a user can pick a resource to link to, without the Consumer having to reimplement the Provider's selection logic.
- Creates a new resource remotely through a Creation Factory.
- Embeds a Preview UI of a linked artifact inside its own interface, for example, hovering over a requirement link in a test case and seeing the requirement's details rendered by the Provider.  

- A test management tool consuming requirements from DOORS Next to build traceability from requirements to test cases.
- A change management tool consuming test results from ETM before deciding whether to close a defect.
- An analytics dashboard or AI assistant consuming lifecycle data across several tools to generate cross-tool reports or impact analysis. 

Roles only come alive in conversation. Here's the five-step exchange that happens at every OSLC integration. 

1. Discover: The Consumer reads the Provider's Root Services, then its Service Provider Catalog, then the specific Service Provider that matches its project.
2. Authenticate: An OAuth handshake establishes trust between the two systems.
3. Request: The Consumer calls one of the Services the Provider exposes; a QueryCapability to search, a CreationFactory to create, or a Delegated UI to pick.
4. Respond: The Provider returns an RDF document describing the resource or resources.
5. Link or act: The Consumer stores the returned URI as a persistent link, embeds a Preview UI, or uses the data to drive its own workflow.

HTTP verbs give every tool the same vocabulary for create, read, update, and delete. RDF lets each tool describe its data in its own terms without forcing a shared schema. And Linked Data means a URI is the integration; as long as the link resolves, the connection lives. There is no hidden copy of the data, no synchronized database, no middleware to keep aligned. 

This is the reason OSLC integrations outlive tool upgrades, version changes, and even vendor migrations. 

Most real lifecycle tools play both OSLC Provider and Consumer roles simultaneously. 

IBM EWM, for example, is a Provider of change requests; other tools can query, create, and link to its work items. But EWM is also a Consumer of requirements from DOORS Next and of test plans from ETM, because a change request meaningfully refers to both. 

Back to the restaurant: a fine-dining kitchen is also a Consumer of the farmer's market, the fish market, the wine distributor. It produces for its diners and consumes from its suppliers, all in the same day. 

For architects, this changes how you think about integration design. The useful question is not "which tool owns what?", it is "for each flow of information, which tool is playing the Provider role and which is playing the Consumer role?" Once you see every integration as a pair of roles rather than a pair of products, the architecture becomes much cleaner. 

Let's make this concrete with the most common OSLC integration in the IBM ELM world: linking a test case in ETM to a requirement in DOORS Next. 

Scenario: A QA engineer in ETM is authoring a new test case and wants to declare which requirement it validates. 

Roles: Consumer: IBM ETM has the need, it initiates the request. Provider: IBM DOORS Next owns the requirement data. 

Flow:
1. From within the ETM test case editor, the engineer clicks "Link to Requirement". ETM opens a Delegated UI dialog served by DOORS Next (ETM does not reimplement the DOORS Next picker; it just embeds it on an IFrame). 

2. The engineer searches and selects a requirement. DOORS Next returns the requirement's URI and a label. 

3. ETM stores the URI as a validatedBy / validates link on the test case. 
4. Later, when the engineer hovers over the link inside ETM, DOORS Next serves a Preview UI showing the requirement's details. 

Notice that the roles can flip. If a requirements engineer in DOORS Next wants to see which test cases validate a given requirement, DOORS Next becomes the Consumer and ETM the Provider. The same two tools, the same OSLC standard, a different direction. 

Provider and Consumer are the main roles played at every OSLC integration. Discovery tells tools how to find each other and the roles tell them what to do once they have. A Provider exposes while the Consumer requests and HTTP and RDF carry the conversation. Because most real tools play both roles, every integrated lifecycle is a web of provider-consumer pairs. 

If you're looking at your own toolset and wondering which tools should play which roles, or whether your current integrations would survive a vendor change, reach out. We'll help you map Providers, Consumers, and the links that bridge them.