It's all about the answers!

Ask a question

Can you provide documents on OSLC friend and consumer relationships?

Philipp Wohlgemuth (264) | asked Dec 01 '21, 10:14 a.m.
edited Jan 13, 7:11 a.m. by Ralph Schoon (59.6k23643)

We would be interested on how the friend and consumer relationships work in detail in OSLC. I.e. we would like to know more about the architecture to be able to answer questions such as “can we establish a mesh of friend relationships rather than having one central hub where every friend relationship has to point to (e.g. a JTS)?

One answer

permanent link
Ralph Schoon (59.6k23643) | answered Dec 02 '21, 4:50 a.m.
edited Dec 02 '21, 4:53 a.m.

 Hi Philipp,

I am not sure how much this is OSLC related. I also do not think it is such a mystery. 

The core of the whole Friends/Consumers/Whitelist setup is to define which server you trust and allow to access your resources in the context of a user request. 

Lets take an ELM system instance, JTS and the apps first. If you want to be able to allow JTS dashboards to show widgets with content of a CCM server, the JTS must be able to delegate requests to that CCM. This requires a mechanism that allows to trust a server and to be able to delegate a users request. This is implemented using OAuth. 

For each server that should be able to send you inbound delegate requests, it is necessary to set up a consumer key. In a typical ELM context, an application like CCM would want to have such a relationship set up for at least all the servers of this ELM system, including JTS. 

This is a lot of work and this is why the Friends relationship mechanism/registration mechanism is provided. It allows you to set up an outgoing relationship to a Friend e.g. to the JTS. By default, during setup, all the OAuth consumer keys are automatically created for all the applications that are consumers of (registered to) the central JTS. This allows each application to consume each other applications data (providing a user context).

It looks like this is all JTS related, but it is not. It is each application to each application registered to the same JTS and JTS to each application.

If you have multiple ELM system instances (E1 and E2), and you want to be able to communicate between these systems, you would have to setup the consumer relationships. If you want to be able to have E2 CCM widgets in E1 JTS, you would have to have to set up E1 JTS as Consumer in E2 CCM. 

From the description in the UI

Use this page to manage friends of this Jazz Team Server. A friend is an application (such as the ones listed on the "Registered Applications" page) or another Jazz Team Server to which this Jazz Team Server and its registered applications are allowed to make outbound requests, in order to consume the services provided by the friend. A consumer key and secret are used for secure communications between the friends. Applications registered with this Jazz Team Server do not need to be configured as friends.
The registration process in the setup makes the JTS a friend to each application. That way they automatically get the friend relationship to the other registered apps. 

You could make E1 JTS friend with E2 JTS and vice versa and, as far as I understand, all apps could communicate to all other apps across E1 and E2.

You can however also use friends and the OAuth Consumers to set up direct connections e.g. between E1 CCM and E2 RM. 

Once this is done, it is then possible to set up the OSLC consumer nd Provider relationships between the E1 CCM project areas and E2 RM project areas that allow to link items.

I have not thought about this for a long time, so a bit rusty. If you want to discuss this further, send me an invite.

Philipp Wohlgemuth commented Jan 12, 10:43 a.m.
Thanks Ralph, for this detailed answer!
We would have one follow-up question though. As the friend/consumer relationship is a peer to peer relationship i.e. a one to one relationship either between two single applications or between an application and a JTS server, we would like to know if you ever thought about a kind of middle-ware based solution where the relationships are handled centrally? In that way the relationships could be managed more efficiently when you think about a more  complex scenario with 1-to-n or even n-to-m relationships.

Ralph Schoon commented Jan 13, 2:55 a.m.

for security reasons, it is absolutely necessary that each pair of applications are linked peer to peer. There is no way around it. It is a direct trust relationship.

Whatever I might have thought about is irrelevant. Relevant is what is available - and used - today. The existing mechanism is in usage in our Jazz servers in production. 

Better automation, similar to the registration scenario when setting up an ELM server, is just another possible enhancement. It might be possible to write something or request an enhancement. 

Your answer

Register or to post your answer.