What are your thoughts about client libraries and clients? Of course I can implement or simply generate stubs from the OpenAPI documentation of Vorto, but with an official or at least reference client the community would benefit.
My incentive to bring this up is the following problem I'd like to discuss with you.
When building micro-services in a ditto-vorto environment I need the model-information at many different services. Each service requires other meta data but they all share the need for some kind of caching in order to minimize the executed queries against vorto. Actually I'd like to program against 'handles' like it's done in the ditto client with potentially a configurable cache of entries in the back so I can save the network usage.
I've a service which is basically invoked for every message to a thing. If this service now calls out to vorto for each and every message this creates a huge amount of requests which then becomes an important scaling factor.
@JulianFeinauer I am also using vorto (or start using it) to model big industrial machine with many subsystems. I am currently looking for examples of a more complex device then a Bosch XDK. At first I though it should be possible to create some relations between infomodels... for example
Machine 1 '--> Pump 1 '--> Pump 2 '--> Vessel 1
But I could not find any hint on this.
I could model it as InfoModel
Machine 1 with different function blocks
Vessel or with a more atomic approach like this:
machine1.infomodel, pump1.infomodel, pump2.infomodel, vessel1.infomodel.
Do you have any further experiences how well these approaches would scale?
Hi @shantanoo-desai , sure you can host your own Vorto Repository on your local machine or a server that's not in a cloud. You can either run the SpringBoot application directly, or use our Docker image to spin up your own instance. You can find a quickstart guide for using the Docker image here: https://github.com/eclipse/vorto/blob/master/docker/Readme.md
If you have further questions feel free to reach out again.
MQTT pythonto send information to custom brokers.
@shantanoo-desai Vorto is not restricted to any specific platform. I think for understanding how it works, it is important to distinguish the different components.
The Vorto repository is a standalone application with a REST API that you can call from any application. There is a Java client that simplifies the integration for Java application.
The Payload Mapping Engine (aka. Vorto Middleware) is a separate component that retrieves the mapping specifications from the repository and uses it to map telemetry data. To receive data the Middleware supports the AMQP protocol. The middleware can be easily extended to support multiple output types. AWS Kinesis is already implemented for time series data. (see here: https://github.com/eclipse/vorto-examples/tree/master/vorto-middleware/middleware-ext-kinesis)
We currently are not planning to add InfluxDB or other similar DBs. If you would like to do the implementation, we are glad to accept your contribution.