Closed rsoika closed 1 month ago
gmillinger
commented
2 months ago I am new to this type of thinking but the concepts are understandable to me. Up to this point I have been loading a bare bones Unbuntu 22.04 on the Raspberry Pi. It would be interesting to build a container for IMIXS-micro and deploy it with Quarkus on a Pi I have ready for testing.
rsoika
commented
2 months ago I have now refactored the existing code and split up the project into multi-module project
It is still a lot of draft code even if the junit tests are all fine for now and we can run the code in a Quarkus-Docker Image (a very fast container!)
The idea is as you mentioned: when you start the image, the engine starts a WebSocket server to accept commands. It also loads the Workflow Kernel with all locally provided BPMN Models. So the engine is ready to process workflow instances.
gmillinger
commented
2 months ago Fantastic! I will dig in over the weekend. Thank you for doing this.
I am still thinking about the runtime environment for the Imixs-Micro project My initial approach was to build the engine as a Pojo (Plain old java object) . This is super simple and runs in-memory. And this is the current implementation status of the imixs-micro project.
But I think this is too simplistic and ignores the complexity of modern software environments. As I explained at the beginning, the full featured Jakarta EE approach is too heavyweight to run on a Micro controller like the Raspberry Pi. But the Pojo approach is to childish. There is no transaction-api, no metric-api not health-api. We would need to implement all these things manually.
A perfect fit seems to be the Quarkus Project. On this platform we can make use of a lot of the Jakarta EE APIs and still run in a very fast lightweight environment. Projects seems to be often build on top of Quarkus to be run on a Raspberry Pi environment. I will take a deeper look into this....