[Interest] Software architecture style options

[Roland Hughes]

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/interest/attachments/20210331/9cb492e6/attachment.html>