Assume a device using Raspberry Pi to control some hardware. This diagram tries to clarify the components:
SOA concept feasibility is being explored right now. The motivations are:
Would the SOA concept be a proper option?
I'm just curious does anyone has any other architecture style in mind which might be suitable but I'm missing? Thanks.
I received a nice answer:
It mostly depends on what your mobile/Desktop application capacity. If they are indeed doing business logic and can have some kind of offline business logic, I would go Qt / Qml ( you could also distribute the application on the mobile easily with Qt/Qml). That way you can recycle the C++ code from the raspberryPi into common lib with std C++.
The WebGL doesn’t allow multiple users as far as I known to render the GUI into WebGL (correct me if I’m wrong here I haven’t used it yet, so take this with a grain of salt), but I don’t see that as a solution for multiple simultaneous user into different usage context. I always saw this option as a good configuration view for a device, a config page for a router for example. I’m speculating on this, I haven’t play with it, but my understanding so far: If you would need multiple user you would need to spawn a webgl process per user connected (CGI script or something?!?). And having the business logic into a single process that the webgl GUI process access.
But if your GUI are only action controller that are process into the centralized business logic, that must always be connected to the device, I would go full web browser and can simply wrap you web site into an Electron app, saving you a lot of work and have a similar experience across the line and reduce the development time considerably.
Another nice reply received:
I have a few comments.
...
You don't need pointers. You're asking a system architect to work for free.
The first thing you need to do is get a copy of this book
https://www.theminimumyouneedtoknow.com/soa_book.html
Actually read it Don't try to wing it by skimming a few lines of source code. ... You need to understand the concepts in that book. One of the huge concepts you need to understand is throttling or more correctly, throttle control. Your drawing has given zero consideration to that and it is the first thing your design needs to have. You generally can't bolt it on at the end. Just because you don't think anyone will hit it with 10,000 requests per second doesn't mean that won't happen.
The book I pointed you to ... covers creating services on a host (OpenVMS) using ACMS (Application Control Management System). There are Linux type things like Tuxedo (not quite as good) and probably some free stuff by now. What you need to learn from the book is how to design and create restartable units of work. That's a completely foreign concept for people who only develop on x86 and less architectures. It's most of your week every week when you work on big systems.
The PC mentality is:
Open connection - keep connection open while device is operating for minutes/hours/days - report back on same connection status - report back final completion - close connection.
When connection is lost mid-operation the device is left in a FUBAR state. The PC mentality doesn't have any clean-up/reset capability. Only the "happy path" is ever designed for.
The big system mentality is:
Assume failure and design around it from the start
Open connection - submit request for device to do something - receive unique id/method to monitor from - disconnect
At this point it depends on how far your design needs to go. If it needs to be expandable to possibly work on the Web, your front end needs to establish itself with some kind of publish-subscribe service and wait for a push.
Local network only type solutions are easier and more forgiving. Some will use a mailbox type service (don't think email there, because it is not). Some will launch their own local service sitting on a specific IP port that will accept one or a very limited number of messages OF FIXED LENGTH AND SPECIFIC FORMAT. Whatever connects will be required to use the previous unique ID that was received. Service dies off after some period of time without receiving answer.
The road to Hell is paved with JSON and XML.
Never assume a connection can be maintained or that you can transfer as much data as you want during that connection.
Never tie-up a resource you don't need to tie-up.
Throwing hardware at it isn't solving an algorithm problem.
Other comments received:
...
But Qt can help with the QML local UI and remote browser WebGL plugin, the experimental Qt HTTP server (though I prefer web sockets these days)
...
Last time I tried, it worked, or could work, however concurrency management is left as an excercise to the coder. https://bugreports.qt.io/browse/QTBUG-65241
