|
|
In the current project state, all components used and implemented are from the "Eclipse BaSyx" SDKs.
|
|
|
They share the same API definitions and work seamlessly with each other.
|
|
|
|
|
|
But other implementations of AAS registries exist.
|
|
|
Here I want to document my experiments with them.
|
|
|
|
|
|
## [admin-shell-io/python-aas-registry](https://github.com/admin-shell-io/python-aas-registry)
|
|
|
This registry is developed by the University of Magdeburg and is a Python implementation of an AAS registry.
|
|
|
|
|
|
I had a hard time even starting the container like it is described in the documentation.
|
|
|
The registry uses an MQTT server which I ran on the same machine.
|
|
|
But the client the registry set up was not able to connect to it unless I set the container to use the host machine network stack.
|
|
|
To do that, just replace both `-p port:port` arguments in the `docker run` command with one `--network host`.
|
|
|
|
|
|
But even after finally getting it running there was no way to make it work with the existing setup.
|
|
|
To be honest I expected that because of the [routes described in the documentation](https://github.com/admin-shell-io/python-aas-registry#aas-registry-rest-api-services) do not match the routes used in BaSyx.
|
|
|
The biggest difference is probably that BaSyx [prefixes all registry routes](https://github.com/eclipse-basyx/basyx-java-sdk/blob/main/src/main/java/org/eclipse/basyx/aas/registration/restapi/AASRegistryModelProvider.java#L55).
|
|
|
|
|
|
But everything else doesn't match too.
|
|
|
When starting a [Light host component](/implementation/Light-host-walkthrough) it tries to call `PUT /api/v1/registry/urn:de.olipar.basyx:%hostname%:redLight_0` but the registry only takes `PUT` for AAS on `/registry/shellDescriptors/{aas-identifier}`.
|
|
|
Even without the prefix, the path is different.
|
|
|
|
|
|
In conclusion, this registry probably could work as a substitute for the BaSyx registry but not without changing basically every route in the REST API. |