search

admin-shell-io / aas-specs-api

Repository of the Asset Administration Shell Specification DTA-01002 API
https://admin-shell-io.github.io/aas-specs-antora/index/home/index.html
Creative Commons Attribution 4.0 International
12 stars 6 forks source link

[GetAllAssetAdministrationShellsByAssetId] Intended Use Case? #287

Open FrankSchnicke opened 5 months ago

FrankSchnicke commented 5 months ago

What?

GetAllAssetAdministrationShellsByAssetId (i.e., /shells?assetIds=XYZ) is providing functionality similar to the AAS Discovery (GetAllAssetAdministrationShellIdsByAssetLink), however, limited to a single AAS Repository.

In a fully distributed deployment it may not behave as expected because the AAS it is looking for may be in a different repository. As a result, using this endpoint in an application may become an obstacle to later changes in the architecture when an AAS is redeployed (similar to the superpaths discussed in other tickets). As a result, from my understanding, this endpoint ties the application using it to the architectural decision to use a centralised approach, and I would not use it to avoid changes in applications due to possible future redeployments.

Is there another intended use for this endpoint that I'm not aware of were it would provide value?

sebbader-sap commented 5 months ago

Hello Frank,

this endpoint ties the application using it to the architectural decision to use a centralised approach

Why would that be the case? Given that the result of this call would be an empty array, the only conclusion the client can make is that "This repository does not contain the AAS for my Asset" but not "No AAS exists for my Asset".

It's the general topic of open world vs. closed world views, isn't it?

sebbader-sap commented 5 months ago

We discussed this topic in the meeting today. While we all share the general view that an empty response from any AAS service must not be interpreted in a way that a respective AAS, Submodel, Asset etc. does not exist, we agree that this has not yet been clearly communicated.

Therefore, the proposal is to add a statement explaining the topic into the AAS API (Part 2) document.

sebbader commented 5 months ago

The AAS Specification Workstream supports the proposal, therefore, an explaining statement will be added in the next publication.

FrankSchnicke commented 2 days ago

The underlying point of my question was about the centralized vs. a decentralized way to build the AAS infrastructure. The components are described as highly distributed and scalable infrastructure consisting of various microservices (e.g., separate Discovery, Registries, Repositories). This infrastructure has a clear interaction pattern for finding AAS belonging to an asset, i.e., query the AAS Discovery, then query the AAS Registry, and finally query the AAS Repository. Some endpoints, such as the GetAllAssetAdministrationShellsByAssetId endpoint break this decentralized view by introducing endpoints that covers some of the responsibilities of other components (here: the AAS Discovery), resulting in a monolithic component that covers multiple responsibilities – but with limited scope. Thus, any application using this endpoint assumes a centralized system where the referenced AAS Repository contains the AAS being searched for. However, this locks the application to the centralized approach where there are no truely distributed (and independent) microservices, and consequently makes it difficult to change the architecture later when scalability issues may arise.

In my opinion, the reason or use case for using this endpoint instead of the AAS Discovery is not clear. Is it just convenience? If so, it should be labelled to indicate that this is a “shortcut” for demonstration purposes and should not be used for real-world deployments where scalability might become relevant.