Коллеги, всем доброго дня. На sql'e кто-то создал шутливую тему, но модераторы вырезали ее под корень. Однако, эта тема запустила некий мыслительный процесс, результатами которого хотел бы с Вами поделиться. Однако, к сожалению, вопросов она родила еще больше.
Итак, удаленный пост:
И некоторые мои мысли, которые, возможно, будут кому-то интересны.
Давайте разложим архитектуру на 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), наладили интеграцию с бэк-офисом, пора и про бизнес-аналитику подумать, но это уже отдельная песня.
Итак, коллеги, кто что думает про типовую архитектуру? Какой сервер приложений использовать, на чем писать бизнес-логику?
Кто что думает?
С Уважением,
Георгий
Итак, удаленный пост:
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), наладили интеграцию с бэк-офисом, пора и про бизнес-аналитику подумать, но это уже отдельная песня.
Итак, коллеги, кто что думает про типовую архитектуру? Какой сервер приложений использовать, на чем писать бизнес-логику?
Кто что думает?
С Уважением,
Георгий
Комментарии (2)
GeorgeNordic
08.04.2016 09:31Да сколько там тех туалетов? Вполне хватит 1C: Общественный туалет. Вот, кстати, еще одна платформа, про которую я не упомянул, увлекшись масштабом. А, судя по последним версиям, там все есть — бери да делай. Кстати, и политика очень здравая: ну кто еще позволит взять типовую конфигурацию, тот же ТиС, сделать на ее базе свою, какую-нить Торговля и Склад Г*8н@, и продавать? Хотя допилить придется, ту же логистику и ТОиРО. Надо планировать ассенизацию, пополнение мыла и бумаги, смены персонала, ремонт и обслуживание… Следить за частотой использования, планировать развитие и расстановку новых точек, геоаналитику надо прикрутить… В общем, если кто-то возьмется, поднимет хороший бизнес. Деньги не пахнут :)
С Уважением,
Георгий
gena_glot
Я хотел бы подчеркнуть что тема не очень шутливая скажем сеть платных туалетов города Питирбурга вполне подходит на средний бизнес который может захотеть автоматизироваться.