Unclear expected resolution behavior of superpaths for AAS Interface

[FrankSchnicke]

What?

DotAAS Part 2 V3 specifies multiple super paths for the Asset Administration Shell Interface:
aas/submodels/{submodel-identifier}/*

If the requested submodel is available to the component providing the AAS, it can easily return the requested submodel. However, it is unclear what the expected behavior is of this superpath is in the context of distributed deployments. For example, if the submodel is provided by another network node, the assumption that the AAS-providing component can successfully resolve the request may not hold due to the following concerns:

• It may not even know the submodel endpoint (Should it resolve it via a Submodel Registry? How do we guarantee that it knows the correct submodel registry if there are several?)
• It may not be able to access the requested submodel due to security constraints (Forwarding the security token provided by the requester may work from a technical point of view but raises other security concerns)

We discussed in BaSys4Transfer how to handle this endpoint and came to the conclusion that the only sensible interpretation is a best effort resolution, i.e. if the submodel can be resolved return it, otherwise return 404.
However, this leads to the point that when implementing any logic using the AAS superpaths, there needs to be a fallback logic in case the component providing the AAS superpath can't resolve the request. This fallback logic would then use a configured submodel registry.

However, if we have to implement this fallback logic anyway, there's no benefit to superpaths. Even worse, if a submodel is moved from one component to another, superpath utilization can cause the application to break because the application can't retrieve the submodel anymore since the component providing the superpath can't do so anymore.

As a consequence, BaSyx probably won't implement superpaths because of these concerns.

How?

A simple solution would be to describe the expected behavior of AAS superpaths in distributed deployments as best effort. However, due to the concerns outlined above, we believe the best approach would be to mark the endpoints as deprecated and recommend the use of registry-driven retrieval instead.

[BirgitBoss]

I think the answer is to follow the recommended way of interaction as described in Part 2 of the AAS specification:

In case an AAS API with Submodel superpathes is implemented your questions are valid. In this case you probably would need a submodel registry for the AAS, that is accessed by the AAS server (hidden for the data consumer).

Are you missing error codes in the Part 2 specification?

[FrankSchnicke]

I think the answer is to follow the recommended way of interaction as described in Part 2 of the AAS specification

Thanks for pointing out this image - yes, this makes a lot of sense.

Are you missing error codes in the Part 2 specification?

Related to this specific question or more in a general sense?

[aorzelskiGH]

My impression is, that we need to have a possibilty, that superpaths are optional.
As Frank explains, superpaths are helpful for a big respository, but may be less helpful for a fully distributed system.

Related profiles without superpaths might be a possibility.

[sebbader-sap]

related to #147