Колеги, всім доброго дня. На 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), налагодили інтеграцію з бек-офісом, пора і про бізнес-аналітику подумати, але це вже окрема пісня.
Отже, колеги, хто що думає про типову архітектуру? Який сервер додатків використовувати, на чому писати бізнес-логіку?
Хто що думає?
З повагою,
Георгій