Configmodel - Broker/AppStore/Clearing House/App Resource

[HeinrichPet]

Hi there,

we currently working on an enhanced version of the Configuration Manager (hopefully open source soon). Therefore we identified some points which we need in the configuration model.

First of all we need lists in InformationModel/model/infrastructure/ConfigurationModel.ttl for:

• Broker (in the next section someone can choose brokers to send resources information to)
• Clearing House (which can be used for different IDS resources)
• App Store (which can be used to get apps from)
• (Installed) App Resources in the IDS Connector

Furthermore we need to add information about what to do with a connector endpoint in a route:

• Store a list of Broker where the endpoint should be registered
• Store a Clearing House which should be informed during data exchange

Additionally we need to add a AppResource to an AppEndpoint, so that the Configuration Manager knows that a specific route is connected to a specific AppResource which should be installed/instantiated in the Connector.

Best regards, Heinrich

[HaydarAk]

Hi @HeinrichPet ! It should be possible to implement the first two change requests without problems.

---

Regarding the third request:

Additionally we need to add a AppResource to an AppEndpoint, so that the Configuration Manager knows that a specific route is connected to a specific AppResource which should be installed/instantiated in the Connector.

Until now, the relation between all app-related classes is as follows:

• ids:AppResource -> ids:representation -> AppRepresentation App Resources may be represented by one or more concrete Represenations. For Data Resources, two represenations may be e.g. CSV and XML- for apps, two represenations may be e.g. Docker images and Java application.

• ids:AppRepresentation -> ids:dataAppInformation -> ids:DataApp For a given ids:AppRepresenation, there is a corresponding ids:DataApp class, which contains implementation specific information (e.g. the apps endpoints and runtime related stuff).

• ids:DataApp -> ids:appEndpoint -> ids:AppEndpoint The endpoints of a specific implementation of a ids:DataApp.

My thoughts about your suggestion:

1. This is a big chunk of information (the whole ids:AppResource), which each ids:AppEndpoint of ids:DataApp has to hold (redundancy).

2. As far as I understood, you do not need the ids:AppResource, but the ids:AppRepresenation. As described above, the Represenation describes a concrete serialisation of an AppResource, e.g. a docker image. Adding the AppResource leads to vagueness / information loss, because you would not know which concrete serialisation of an app should be instantiated (if there are 2 or more Representations of an AppResource.

3. This information is specific for a routing and the ids:ConfigurationModel.

My proposal

There are two variants, how to model this. It is up to you to decide, which is more appropiate. Maybe both=?

Variant 1:

Add the information to ids:AppRoute, the class. The ids:AppRoute class holds the information about all "atomic" routes (ids:EndToEndRoute). E.g.: ids:AppRoute -> (some property name) -> ids:AppRepresenation.

Variant 2:

Add the information to the atomic route classesids:EndToEndRoute in form of: ids:EndToEndRoute -> (some property name) -> ids:AppRepresenation.

Using the first variant allows you to get the list of App(Represenations) without reading all single routes. If you only need to know which apps to instantiate / deploy, this should be sufficient. Like "For this whole routing configuration, I need following AppRepresenations: [List of AppRepresenations]"

Variant 2 binds an AppRepresenation to the single Route. It is more precise since you know for every single route, which app it is used with.

It could also be more convenient to have both information available. The first variant for the whole deployment process. And the second to build the routes between apps. You would have to ensure on application level, that all AppRepresenations of the single routes (ids:EndToEndRoute) are part of the AppRepresenation list in the ids:AppRoute class.

[HeinrichPet]

Hi @HaydarAk,

thanks for the quick response and for the very detailed answer! Let us go with Variant 2, because we also need to know at what Route Position the app needs to be included.

Best regards, Heinrich