Хмарний комерційний об'єктно-орієнтований бізнес-додаток для платного туалету або думки про архітектуру

Колеги, всім доброго дня. На sql'e хтось створив жартівливу тему, але модератори вирізали її під корінь. Однак, ця тема запустила якийсь уявний процес, результатами якого хотів би з Вами поділитися. Однак, на жаль, питань вона народила ще більше.


Отже, віддалений пост:

pisun

Хмарний комерційний об'єктно-орієнтований бізнес-додаток для платного туалету

У мене є середній бізнес - три платних туалети. Вважаю, що настав час автоматизувати бізнес-процеси мого бізнесу за допомогою комерційних об'єктно-орієнтованих хмарних бізнес-додатків.

Які підходи, методології, фреймворки необхідно використовувати для розробки хмарних комерційних об'єктно-орієнтованих бізнес-додатків для платних туалетів?

Скільки рядків комерційного коду має містити хмарний комерційний об'єктно-орієнтований бізнес-додаток для платного туалету?

Які є готові коробкові хмарні комерційні об'єктно-орієнтовані бізнес-додатки для платного туалету?

І деякі мої думки, які, можливо, будуть комусь цікаві.

Давайте розкладемо архітектуру на 3 основних складових:

* це фронт (те, що бачить клієнт, з чим він працює)

* сервер додатків (відповідає за обробку бізнес-логіки)

* база даних (де зберігаються дані)

так само треба врахувати два важливих моменти: облікова система - це не самоціль. Не можна просто так зберігати всі дані - вони чомусь потрібні. Питання, які дані ми будемо зберігати, для чого вони потрібні:

* для ведення фінансової діяльності підприємства

* для надання регламентованої звітності контролюючим органам

* для вивчення потреб клієнта та можливостей їх максимально задовольнити (аналіз продуктів і послуг, що постачаються, вивчення поведінкових моделей, прогнозування попиту на основі історичних даних)

Отже, ми зберігаємо ті дані, які нам будуть необхідні надалі - для ведення управлінського та бухгалтерського обліку та бізнес-аналітики. Так само, для ведення бухгалтерського та кадрового обліку необхідно вести облік ряду документів суворої звітності - чеки/акти/рахунки/накази тощо, але ряд цих функцій відносяться до бек-офісу і можуть вестися в окремій системі.

Однак, іноді необхідно передбачити і фіксування операцій з фронт-системи (чеки, авторизація на виконання операцій з банківської картки тощо). А це іноді вимагає окремого ряду рішень щодо інтеграції з платіжними системами та/або POS-системами, а так само забезпечення безпеки подібних операцій і відновлення історії операцій при збої.

Таким чином, ми підходимо до важливих речей - це backup, який, в принципі, можливий стандартними засобами СУБД, і безпеки.

Повернемося до архітектури:

* сервер додатків (відповідає за обробку бізнес-логіки)

* база даних (де зберігаються дані)

Питання, на якому з цих шарів необхідно забезпечити безпеку і поділ доступу?

Є 3 підходи:

1. На рівні сервера програм

Ми даємо всього кілька ролей, і Сервер додатків (AOS) під ними вже звертається до БД, розмежування ролей до БД - зашито в СП, розмежування за даними/на рівні записів ведеться засобами AOS.

Плюси: Легкість адміністрування. Немає сильної залежності від СУБД.

Мінуси: Бізнес-аналітика зазвичай чіпляється безпосередньо в БД, і бачить все, без урахування обмежень на рівні СП. Реалізація доступу бізнес-аналітики через СП - дуже нетривіальна і може сильно навантажити СП.

2. На рівні СУБД

Всі ролі користувачів, рівень доступу, розмежування за даними/на рівні записів задаються на рівні СУБД. Таким чином, треба сильно допилювати сервер додатків, щоб не ускладнювати адміністрування системи: налаштували в робочому місці адміністратора, і автоматом ролі застосувалися на рівні БД.

Плюси: BI/звітна система може чіплятися безпосередньо до БД під тим чи іншим користувачем, немає необхідності в додатковому контролі прав доступу

Мінуси: Складність реалізації, оскільки імплементація цього механізму сильно залежить від використання тієї чи іншої СУБД.

Складність тестування - випадають нулі, і треба зрозуміти, чому так: це помилка в логіці програми або в налаштуванні прав доступу. Можливо, дублювання адміністрування - завели користувача, причепили до нього бізнес-логіку, а потім доналаштували права в БД.

3. Змішаний

Ми даємо всього кілька основних ролей, і ряд «типових», відмінність у доступі яких відрізняється на рівні фільтрів.

Сервер додатків (AOS) для низки основних ролей - звертається до БД, розмежування ролей до БД - зашито в СП

Для «типових» - АОС заходить з обмеженням на кожну роль, додаткові обмеження за даними/на рівні записів ведеться засобами СУБД за допомогою фільтрів.

При всіх плюсах - легкості адміністрування, нескладному налаштуванні BI-систем (фактично, доведеться дублювати фільтри для користувача в СУБД і BI системі) це найбільш трудовитратний спосіб реалізації.

Отже, якщо з фронтом визначитися нескладно - ми живемо в століття мобільності, отже, треба передбачити що наш додаток будуть відкривати з будь-якого виду пристроїв. Значить, треба буде писати «тонкі клієнти» під iOS/Android/Win/Linux або просто написати фронт, який буде відкриватися в будь-якому середовищі - наприклад, з будь-якого браузера. Так як з Java зараз невизначена ситуація, хтось відмовляється від JVM, комусь заборонено політиками безпеки, то я б дивився в бік HTML 5 (6...). Хоча, знову ж таки, питання, буде виглядати Ваш додаток на моніторі 24 «» і на телефоні 4 «» - тут або автомасштабування, або підміна клієнта (виводимо тільки основне, або б'ємо по екранах/елементах) або знову - писати тонкі клієнти...

Гаразд, давайте уявимо, що ми вибрали HTML5. Гаразд, навіть Grid можна реалізувати.

Тепер до СУБД. Основні - це MS Sql і Oracle, ну і ще тенденція з Open Source, значить і PostgreSQL треба не забути. Якщо передбачається велике кол-во розподілених інсталяцій, то треба придивитися до Hadoop/Mongo і т. п., але це не реляційні СУБД, що вирішують певні завдання, ви не пошуковик або соцмережа збираєтеся робити? Давайте поки на перших 3 зупинимося, а краще - хоча б з одного почнемо. Або передбачимо якусь незалежність від СУБД, залишивши тільки властиві всім СУБД функції.

На чому ж реалізовувати бізнес-логіку? Що стане сполучним елементом між браузером і СУБД?

А ось відкрите питання. Я б і сам послухав колег

Якщо ми віддаємо перевагу технологіям Oracle - тоді oracle apex. Якщо переростемо - то Fusion Middleware на повний зріст + WebLogic

Якщо ми схиляємося з Open Source - тоді Apache Tomcat. Так, якщо інсталяція велика, тоді б ще й балансувальник навантаження, типу PgBouncer і Nginx. Якщо розподілена - то ще й менеджер ресурсів кластера Pacemaker, обмін повідомленнями між вузлами кластера Corosync тощо.

Якщо прихильник технологій MS - то Студію і вперед. На жаль, не підкажу готових AOS в їх стеці. Тільки сторонні фреймворки типу К2.

Зібрали сервер додатків, інтегрувалися з банк-клієнтом (можливо, задіявши брокер гарантованої доставки повідомлень Apache ActceMQ), налагодили інтеграцію з бек-офісом, пора і про бізнес-аналітику подумати, але це вже окрема пісня.

Отже, колеги, хто що думає про типову архітектуру? Який сервер додатків використовувати, на чому писати бізнес-логіку?

Хто що думає?

З повагою,

Георгій