This is a Java-based implementation of the Submodel Registry server and client based on the corresponding Open-API specification of the German Plattform Industrie 4.0.
basyx.submodelregistry-client-native can be used to interact with the backend to register or unregister descriptors and submodels or perform search operations.
basyx.submodelregistry-service provides the application server to access the submodel descriptor storage and offers an API for REST-based communication.
basyx.submodelregistry-service-basemodel provides a base model implementation that should be used if you do not need specific model annotations for your storage. It is used for the in-memory storage implementation and you need to add it explicitly as dependency for your server deployment as it is defined as 'provided' dependency in the basyx.submodelregistry-service POM.
basyx.submodelregistry-service-basetests provides helper classes and abstract test classes that can be extended in storage tests or integration tests. The abstract test classes already define test methods so that you will get a good test coverage without writing any additional test cases.
basyx.submodelregistry-service-mongodb-storage provides a registry-storage implementation based on mongoDB that could be used as storage for submodelregistry-service. It comes with java-based model classes, annotated with mongoDB annotations.
basyx.submodelregistry-service-inmemory-storage provides a non-persistent registry-storage implementation where instances are stored in hash maps. It can be used as storage for submodelregistry-service.
basyx.submodelregistry-service-kafka-events extends basyx.submodelregistry-service with a registry-event-sink implementation that delivers shell descriptor and submodel registration events using Apache Kafka. The default provided by submodelregistry-service just logs the events.
basyx.submodelregistry-service-release-kafka-mongodb is used to combine the server artifacts to a release image that uses Apache Kafka as event sink and MongoDB as storage.
basyx.submodelregistry-service-release-kafka-mem is used to combine the server artifacts to a release image that uses Apache Kafka as event sink and an in-memory storage.
basyx.submodelregistry-service-release-log-mongodb is used to combine the server artifacts to a release image that logs registry events and uses MongoDB as data storage.
basyx.submodelregistry-service-release-log-mem is used to combine the server artifacts to a release image that logs registry events and an in-memory storage.
A docker-compose file that illustrates the setup can be found in the docker-compose folder.
The REST API and the client implementation will not be modified - if not a SNAPSHOT version - until a new major version is released or an update of the openAPI definition. All server-side classes and the plugins are not intended to be used as programming library. They could be updated or removed then a new minor version is released.
To build the images run these commands from this folder or for the parent project pom:
Install maven generate jars:
mvn clean installIn order to build the docker images, you need to specify docker.namespace and docker.password properties (here without running tests):
MAVEN_OPS='-Xmx2048 -Xms1024' mvn clean install -DskipTests -Ddocker.namespace=eclipsebasyx -Ddocker.password=""You can now check your images from command-line and push the images:
docker images ...Or you can directly push them from maven.
MAVEN_OPS='-Xmx2048 -Xms1024' mvn deploy -Ddocker.registry=docker.io -Ddocker.namespace=eclipsebasyx -Ddocker.password=pwdIn addition, maven deploy will also deploy your maven artifacts, so you can do everything in one step.
Have a look at the docker-compose sub-folder to see how the created images could be referenced in docker-compose files.
Consider updating the image name pattern if you want a different image name.