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
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 do not match the routes used in BaSyx. The biggest difference is probably that BaSyx prefixes all registry routes.
But everything else doesn't match too.
When starting a Light host component 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.
Manual testing
Testing this was another challenge. That's because the documentation of this project's REST API honestly is a mess.
There are two different paths documented for the registry REST endpoint:
-
http://localhost:9021/registry/shellDescriptors/{aas-identifier}in the README on the project page -
http://localhost:9021/api/v1/registry/{aas-identifier}in the provided example
And the best part: None of those two work for the docker container that should be used according to the README.
Inspecting the docker container by attaching a command line to it and reading through the code was more successful:
All these lines here are different in the docker container and use "kebab-case" instead of "camelCase".
So the correct spelling for shellDescriptors in the path is shell-descriptors.
Before the test started I fetched a PUT request from our projects light component using a simple server script. I now just needed to pipe this data into the correct path to the python-aas-registry and voilà: "HTTP/1.1 500 INTERNAL SERVER ERROR" and "The syntax of the passed Asset Administration Shell descriptor is not valid or malformed request".
This concludes the testing for this registry. The documentation is really bad and it won't work with any BaSyx components.
SAP/i40-aas
SAP has a framework, too, which also is already talked about in the initial considerations. As one of the key points, SAP states the framework "Provide[s] registry and discovery services". The documentation is pretty good in technical terms but hard to navigate. It can be found here.
After "installing" it (which just runs a docker-compose stack) everything seems to be up and running.
There are logs in the console and running sudo lsof -i -P -n | grep LISTEN shows that docker is listening on all the ports that are configured in the .env file in the repository.
But for some reason, every connection to any service returned an empty response.
Turns out, the browsers' default is to not use HTTPS on local connection, which normally is fine, but the i40-aas service only serves on HTTPS using a self-signed certificate, you have to explicitly trust in the browser.
https://localhost:4401/index.html is the "endpoint-registry-ui" which is where you can see the registered endpoints - so it's a UI for the registry.
You can even add new descriptors by hand.
How we can use the registry endpoints programmatically is described in the endpoint-registry documentation. And here we see: The routes are very different again. They neither match the BaSyx registry nor the python-aas-registry.
Manual testing
This test took less time than the one above. In short: it fails too.
It took less time because the project provides a test collection for Postman. When trying to register our light asset, we just get another "HTTP/1.1 500 INTERNAL SERVER ERROR".
This registry won't work with BaSyx components either.