Облачное коммерческое объектно-ориентированное бизнес-приложение

Народ, ну кто тему ценную удалил? Тут у pisun'a душа болит, совета просит. Хорошо, что я сохранить успел.

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 ActiveMQ), наладили интеграцию с бэк-офисом, пора и про бизнес-аналитику подумать, но это уже отдельная песня.

Итак, коллеги, кто что думает про типовую архитектуру? Какой сервер приложений использовать, на чем писать бизнес-логику?

Кто что думает?

С Уважением,
Георгий

Модератор: Тему удалил я, решив, что автор решил постебаться. Если это не стеб, обсуждайте, не возражаю.

Garya

Pisun до этого постинга в форуме Работа, если не ошибаюсь, рассуждал по поводу потери времени коммерческими программистоми из-за того, что в мужском туалете отсутствуют писсуары, а только кабинки. Рассчитывал потери от данного факта в количестве ненаписанных сотен строк коммерческого кода из-за каждого такого похода в туалет. Так что стеб это. В том форуме его тему быстро удалили модераторы.

Garya, конечно, это стеб был чистой воды. Однако, эта тема запустила некий мыслительный процесс, результатами которого хотел бы с Вами поделиться. Однако, к сожалению, вопросов она родила еще больше... К самой моей больной теме - на чем писать Сервер Приложений, или что использовать в качестве СП и на чем писать бизнес-логику.

С Уважением,
Георгий

George Nordic
Итак, коллеги, кто что думает про типовую архитектуру? Какой сервер приложений использовать, на чем писать бизнес-логику?

1. Нужно определиться с термином бизнес-логика. Под ним тоже, много чего понимают. Например валидация входных данных, это бизнес логика или UI ?

2. Тут тоже возможен смешанный подход. AFAIK например в OeBS часть бизнес логики на стороне апп-сервера (Forms, OAF), часть критической бизнес логики (расчеты, проведение транзакций) в БД.

В принципе, можно посмотреть достоинства и недостатки всех подходов, для современных a la WEB приложений:

2.1. Все на сервере приложений. Как крайний случай, Java, бизнес объекты в классах, Hibernate в полный рост.
Недостатки:
2.1.1. Данные в БД, а ВСЯ обработка на сервере приложений.

Недостатки:
Значительная потеря производительности на передаче данных и конвертации (ORM) данных.
Увеличение трудозатрат при разработке/сопровождении т.к. конвертацию данных и лишний слой (ORM) в той или иной форме все равно нужно поддерживать.

Достоинства:
Еще один уровень абстракции при грамотной архитектуре, добавляет возможность масштабировать систему методом добавления блейдов с апп-серверами.
Это так же может повысить отказоустойчивость к аппаратным сбоям (упал один апп-сервер)
Насколько это компенсируется недостатки - не понятно.

Спорное:
Приложение может не зависить от вендора СУБД. Можно расматривать как достоинство, можно как недостаток.

2.1.2. Все в БД или максимально близко к БД. Например PL/SQL HTTP картридж, Oracle APEX.
Достоинства:
Можно обеспечить максимально высокую производительность.

Недостатки:
Меньшее кол-во развитых фреймворков, фраймворки сильно привязаны к вендору и зависят от его капризов и не всегда логичных решений (вендора).

2.1.3. Промежуточный подход

Какая-то бизнес-логика (валидация и прочее) на апп-сервере, сложные бизнес процессы (вычисления,проводка транзакций и пр) в слое БД.

Достоинства: компромиссный подход, теоретически можно взять самое лучшее от разных систем

Недостатки:
В штате сотрудников нужно держать специалистов по двум разным веткам продуктов
Сложная архитектура, можно легко попасть в какую нибудь крайность или нагородить велосипедостроение

Масштабирование СУБД обычно более дорогое, чем масштабирование апп-сервера. Поэтому AFAIK, например в OeBS, можно выделить даже 3-и слоя абстракции:

UI-бизнес логика: Forms или OAF
Основная бизнес логика в БД
"Тяжелая" бизнес логика в виде concurent процессов

AFAIK Другие системы также часто содержат что-то подобное concurrent manager'у из OeBS с целью вывести "тяжелые процессы" из СУБД или, как минимум, изолировать их работу от остальной работы СУБД (фоновое выполнение).

IMHO & AFAIK

George Nordic
...Теперь к СУБД. Основные - это MS Sql и Oracle, ну и еще тенденция с Open Source, значит и PostgreSQL надо не забыть....

"при всем богатстве выбора, другой алтернативы нет" ( C ) реклама 90-х

1) MS SQL и Oracle это IMHO достаточно "сильные" БД, под которые можно найти специалистов.

При этом, если брать учетные системы, то MS предлагает Axapta / Navision, а Oracle OeBS. Не знаю как сейчас, но вроде раньше на основе Акспате, Нависион полно было "самописок". И некоторые, вполне даже "тиражируемые".

2) Если PostgreSQL, то ничего не хочу сказать плохого, но боюсь, найти специалистов готовых на Pg-языке писать сотни тысяч строк кода для бизнес-логики, будет достаточно сложно.

Т.ч. остается только вариант: ВСЕ на сервер приложений и там for'ами, for'ами... Java и Hibernate в полный рост )))

3) Ну и не забывает "наше все", т.е. 1C /сам с ним не знаком/

Leonid Kudryavtsev, спасибо!
1. Нужно определиться с термином бизнес-логика. Под ним тоже, много чего понимают. Например валидация входных данных, это бизнес логика или UI ?

Тут тонкий момент. Например, если мы ограничимся маской ввода - это чистый UI. А вот lookup и валидация (например, поиск существующего контрагента) - это чистая бизнес-логика.

Еще. А от чего зависит маска ввода? Кол-символов, там? Это же все может меняться, так что если мы завяжемся на UI, то надо будет отслеживать и БЛ, и изменение UI! Это сделает сопровождение системы весьма трудоемким.

Поэтому на уровне БЛ необходимо предусмотреть настройку и элементов UI.
Типа таблицы:
Обязательное поле или нет
Выводимое имя полное
краткое
Подсказка (все это - в разрезе языков)
Тип данных: int, str...

Str - максимальная длинна
пароль / нет
по какому полю lookup (и что из lookup доступно в разрезе безопасности)

int
Минимальне заначение
Максимальное значение
допустим ли ввод 0
допустим ли ввод отрицательных значений
real
тоже + сколько знаков после запятой выводить и учитывать.

Т.е. формировать словарь данных, и элементов данных, которые используются в системе и в UI.
Еще и отображение бы - сколько может занимать на странице - это необходимо если мы будем авторазмещать элементы.

В Microsoft Dynamics AX это называется АОТ. Хотелось бы узнать, есть ли фреймворки / сервера приложений, где это все уже реализовано.

С Уважением,
Георгий

George Nordic,

George Nordic
Тут тонкий момент. Например, если мы ограничимся маской ввода - это чистый UI. А вот lookup и валидация (например, поиск существующего контрагента) - это чистая бизнес-логика.

Если валидация ввода имеет значение с точки зрения бизнес логики (то есть какой бы UI не был данные считаются корретными только если они подпадают под условие) - это бизнес логика.

Leonid Kudryavtsev, вот по второму полностью согласен - лучше все делать на AOS, оставляя в БД как можно меньше. Или то, что требует моментальной реакции (lookup?) или тяжелые расчеты, которые требуют ресурсов и могут быть запущены на периодической основе, когда нагрузка на систему низкая (но что нельзя вынести в аналитическую БД) - расчет себестоимости, например.

Разноску заказов бы еще туда... но тут много бизнес-логики может быть задействовано, так что надо или на уровне БЛ, или гибрид.

В общем, чем меньше пишем на уровне БД, тем проще сопровождать / портировать систему.

С Уважением,
Георгий

George Nordic,