View
535
Download
2
Category
Preview:
DESCRIPTION
CompanyMedia Next: открытость, производительность, масштабируемость
Citation preview
Архитектура CompanyMedia Next: Архитектура CompanyMedia Next: открытость, производительность,открытость, производительность,
масштабируемостьмасштабируемость
Владимир Александрович Панов,главный архитектор,
Компания «ИнтерТраст»(495) 956-7928
Стратегия развития архитектуры CompanyMedia
За счет глубокой и последовательной трансформации архитектуры CompanyMedia, применения самых современных программных платформ и мировых открытых стандартов обеспечить решение критических проблем в области электронного документооборота и управления контентом
Обеспечить поддержку современных тенденций в области управления контентом и коллективной работы
Ключевые требования к архитектуре CompanyMedia
Юзабилити(относится к клиентам, но влияет на всю архитектуру)
Производительность и масштабируемость Открытость:
расширяемость, переносимость, интероперабельность, адаптивность
Технологичность (на всех этапах ЖЦ) Экономичность
Открытость
Открытость: соответствие популярным стандартам, спецификациям расширяемость переносимость, интероперабельность, адаптивность
Стандарты, спецификации, … BPMN 2.0 ACM (Adaptive Case Management)
(пока стандарта нет, но его подготовка постепенно идет) CMIS HTML5 XMPP (Jabber) REST (архитектурный стиль) JPA (Java Persistence API)
Расширяемость и адаптивность
Высокая степень адаптивности системы, технологичность доработок и расширяемость без перепрограммирования - за счет использования «конструктора бизнес-решений» (КоБРа), в котором под каждое «БР» создаются несколько взаимоувязанных моделей, определяющих самые изменчивые аспекты БР:
бизнес-объекты и их агрегаты/композиты; жизненные циклы бизнес-объектов; процессы (BPMN 2); роли и орг.стрктура; пользовательские интерфейсы (формы, представления, …) Отчеты
Новое перспективное направление – кейс-менеджмент (об этом отдельно)
Два уровня расширяемости: Системный / Полнофункциональный - КоБРа - для разработчиков, архитекторов,
системных аналитиков (в нашей компании, у партнеров, у заказчиков) Пользовательский – обычно это средства создания разных шаблонов – для бизнес-
аналитиков, предметных специалистов, продвинутых пользователей. Например, шаблоны процессов согласования и совм.подготовки, шаблоны кейсов, …
Переносимость
Поддержка разных конфигураций базового ПО от разных поставщиков:
Web-клиент: все современные ОС и браузеры
Сервер: разные ОС и серверы Java-приложений
РСУБД: DB2, Oracle, MS SQL, PostgreSQL, MySQL,…
СУБД класса NoSQL
ECM - (FileNet, OpenText, …)
Конфигурации, полностью построенные на СПО, например: Tomcat+Spring+Hibernate+PostgreSQL+CouchDB+Lucene+OpenOffice+…
Демо-конфигурация «всё в одном флаконе» (в 1 war-файле)
Поддержка "нативных" клиентов (например, iPhone/iPad) без изменений на стороне сервера
Representational State Transfer Representational State Transfer (REST)(REST)
REST – это архитектурный стиль Крупнейшей реализацией системы, соответствующей архитектурному
стилю REST, является Всемирная паутина (World Wide Web).
В основе REST лежит ресурсно-ориентированный подход, в котором центральное место отводится объектам (ресурсам).
Клиенту достаточно знать простую фиксированную точку входа в приложение и MIME-типы ресурсов, для работы с которыми он предназначен.
CompanyMedia: Взаимодействие с системой при помощи API,
построенного на принципах REST.
Спецификация REST API для CM4/5 будет опубликована (пока-что ДСП):https://sup.inttrust.ru:8446/prjdocs/cmj/specs/internal/rest.html
Производительность и Производительность и масштабируемостьмасштабируемость
Система строится на базе самых современных Java-технологий;
Многоуровневая архитектура – возможность независимого масштабирования слоев;
Кэширование на всех уровнях обработки данных – от HTTP (браузер – прокси - web-сервер) до СУБД;
Уникальная документоориентированная модель хранения данных, позволяющая использовать не только любую РСУБД, но и NoSQL СУБД, что открывает перспективу неограниченной масштабируемости
Многоуровневая архитектура сервера
User Interface (Presentation) Layer
Операционный уровень (координация прикладных операций)
Domain Layer (Model Layer)Уровень предметной области
Infrastructure LayerИз книги «Предметно-ориентированное проектирование (DDD): структуризация сложных программных систем» (Эрик Эванс)
Многоуровневая архитектура CM
Клиенты
Сеть (HTTP)
Представление
Предметная область
Инфраструктура
REST-интерфейс
Бизнес-объекты и логика ЭДО
Бизнес-объекты и другие данные CM
Web-клиенты:1. АРМ пользователя2. АРМ руководителя
WF/BPM: BPMN 2.0;
ACM
ECM
File
Ne
t
Ope
nTex
t
Sha
reP
oint
Alfr
esco
Lotu
s D
omin
o
NoS
QL
СУ
БД
РС
УБ
Д
Конструкторбизнес-решений
Мобильные клиенты:
iPad, Blackberry
Многоуровневая архитектура CM
Клиенты
Сеть (HTTP)
Представление
Предметная область
(ЭДО)
Инфраструктура
Базовое ПО
Вторичные (производные)
данные (индексы)
REST API (Web-сервисы в стиле REST)
Бизнес-объекты: документы, задачи, кейсы, контакты,… ЖЦ объектов, роли участников, события, операцииКоллекции (общие, ролевые, персональные): журналы, папки, представления, рез-ты поиска, задачи,…Службы: регистрация, контроль, планирование, поиск, отчеты, ChLog, управление доступом, Locker, …Процессы: согласование, ознак-е,… Кейс-менеджмент
Основной репозиторий
бизнес-объектов
Другие системы (интеграция) Клиенты CM (разные)
Асинхронные взаимодействия
с другими системами;Внешний ЭДО: МЭДО,
корпоративный, …Репликация
бизнес-объектов
Шлюзы в др. системы:СЭД, Почта,Календари,
Jabber/XMPP, WS SOAP, …
WF Engine: BPMN 2.0; ACM;WorkList Handler
Очереди сообщений
(JMS)
Сервер отчетов
Др
уги
е си
стем
ы (
СЭ
Д,
EC
M,
почт
а, М
ЭД
О,
СМ
ЭВ
,…)
Клиенты др.систем
БД: NoSQL, РСУБД, …
Аналит. БД(РСУБД, DWH)
Коллекции(РСУБД)
Поиск: Lucene;
Solr
OpenOffice
Jabber (XMPP)
Шлюзы в ECM
Поиск в ECM
Кэш
Зачем несколько отдельных БД?
Чтобы обеспечить одновременное выполнение ключевых требований к системе: Переносимость Масштабируемость
Подсистема хранения/обработки данных играет ключевую роль в этих вопросах
Проблемы: РСУБД масштабируются плохо/дорого NoSQL-БД масштабируются прекрасно, но есть «нюансы»
Решение: Применять к каждому классу задач технологию, лучшую в
этом классе, интегрируя их в одной системе Предусловие:
Задачи подсистем делятся на такие классы
Инфраструктура хранения и обработки данных
Первичные (оригинальные) данные Репозиторий всех объектов системы
• Документоориентированная модель данных Репозиторий контента. Варианты:
• в БД основного репозитория;• в ECM-системе;• в файловой системе
(только в конфигурации сервера «всё в одном»)
Вторичные (производные) ресурсы Коллекции (разнообразные выборки по той части объектов, которая
находится в работе) Поисковый индекс Аналитическая БД Кэш (часто используемые объекты)
Требования к РСУБД коллекцийвесьма демократичны, т.к.
Обрабатывается малый % всех данных Это не «первичные» данные
Репозиторий объектов Репозиторий объектов CMCM
Задача: эффективное хранение и предоставление всех объектов:
Бизнес-объекты и справочники, их атрибуты, версии и взаимосвязи Ролевые, групповые и/или персональные настройки Модели, шаблоны, создаваемые в «конструкторах» Экземпляры процессов Контент (опционально, если нет ECM - вообще или в конкретной СМ-сети)
Всё остальное делается «этажом выше» - в слое предметной области: репликация в «федеративном режиме», управление доступом к объектам, разбор конфликтов,…
Документоориентированная модель данных - хранение данных как «документов» в смысле целостных объектов-агрегатов, включающих всю информацию, фиксирующую каждое принятое решение.
Репозиторий объектов Репозиторий объектов CMCMНефункциональные требованияНефункциональные требования
1. Высокая производительность, адекватная конфигурации системы, начиная с минимальной;
2. Неограниченная масштабируемость;
3. Возможность развертывания в "облаках";
4. Высокая доступность (непрерывность функционирования) и надежность;
5. Кроссплатформность (как минимум, Windows + Linux);
6. API для разработки на java и/или REST-API (по HTTP);
7. Глобальная целостность «в итоге» («eventual consistency»);
8. Транзакционная целостность (атомарность) операций с отдельными документами
Репозиторий объектов Репозиторий объектов CMCMСУБД: СУБД: SQLSQL или или NoSQLNoSQL??
Перечисленным выше требованиям в настоящее время лучше всего удовлетворяют базы/системы, построенные в соответствии с концепцией
"NoSQL" (Not Only SQL) http://ru.wikipedia.org/wiki/NoSQL
Ассортимент современных NoSQL СУБД ( NoSQL = Not Only SQL ):Системы из категории СПО:
CouchDB, MongoDB, Accumulo, Hadoop Hbase, Cassandra, OrientDB, Redis, …
NoSQL СУБД известных вендоров: IBM Lotus Domino IBM DB2 NoSQL Oracle NoSQL Database
Системы «облачного» развертывания: Microsoft Windows Azure Storage Amazon Dynamo, Amazone SimpleDB Google Megastore
Внешние (подключаемые) системы
ECM : IBM FileNet или другая ECM-платформа: хранение основных бизнес-
объектов СМ в любых объемах, доступ к ним в том числе средствами ECM или из других приложений (с ограниченной функциональностью).
Поиск CM-клиентом документов в ECM-репозитории (собственных или порожденных другими системами и приложениями).
IM Server XMPP/Jabber: мгновенная передача сообщений в обсуждениях, отслеживание статусов присутствия пользователей, доставка срочных сообщений прямо в IM-клиент (краткое содержание + ссылка на контекстный объект, открываемая в основном клиенте пользователя).
OpenOffice: используется как сервис преобразования форматов файлов, в частности для их предпросмотра в Web-клиенте.
Почтовый сервер SMTP (Lotus Domino, MS Exchange, ...) Календарный сервер (Lotus Domino, MS Exchange, ...) LDAP Сервер (MS AD, Lotus Domino, ...)
CompanyMedia: дополнительная информация
Компания «ИнтерТраст» http://www.intertrust.ru/
CompanyMediahttp://www.companymedia.ru
Инициатива «Новая СЭД – строим открыто» Специализированный подраздел на сайте CNews
http://opendev.cnews.ru/
Блог ИнтерТраст на CNews http://club.cnews.ru/ИнтерТраст
CompanyMedia на Facebookhttp://www.facebook.com/pages/CompanyMedia/200431593375537
Очные мероприятия
Более подробная презентация: http://www.slideshare.net/vpanov/companymedia-next-architecture-vladimir-panov-26122011
Recommended