On 3/31/21 5:00 AM, Megidd Git wrote:
Hi everyone,
Maybe someone can help:
https://softwareengineering.stackexchange.com/q/424966/176220
I just need some pointers to guide me in the right direction to explore
architecture style options.
I have a few comments.
1) I'm always amazed at the questions asked on this list that link back
to a "Stack" site question. After posting a question there and getting
down voted once one of the little boys that hang out there stops having
the deer-in-headlights look, they come here to get an actual answer.
2) 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. Don't be upset that part of it is on an OS you've never
heard of. 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 (yes, I wrote it) 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.
--
Roland Hughes, President
Logikal Solutions
(630)-205-1593
http://www.theminimumyouneedtoknow.com
http://www.infiniteexposure.net
http://www.johnsmith-book.com
http://www.logikalblog.com
http://www.interestingauthors.com/blog
_______________________________________________
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest
