CompanyMedia Next: открытость, производительность, масштабируемость

1. Архитектура CompanyMedia Next:
открытость, производительность,
масштабируемость
Владимир Александрович Панов,
главный архитектор,
Компания «ИнтерТраст»
(495) 956-7928

2. Стратегия развития архитектуры
CompanyMedia
 За счет глубокой и последовательной
трансформации архитектуры CompanyMedia,
применения самых современных программных
платформ и мировых открытых стандартов
обеспечить решение критических проблем в области
электронного документооборота и управления
контентом
 Обеспечить поддержку современных тенденций в
области управления контентом и коллективной
работы

3. Ключевые требования к
архитектуре CompanyMedia
 Юзабилити
(относится к клиентам, но влияет на всю архитектуру)
 Производительность и масштабируемость
 Открытость:
расширяемость, переносимость,
интероперабельность, адаптивность
 Технологичность (на всех этапах ЖЦ)
 Экономичность

4. Открытость
 Открытость:
 соответствие популярным стандартам, спецификациям
 расширяемость
 переносимость,
 интероперабельность,
 адаптивность
 Стандарты, спецификации, …
 BPMN 2.0
 ACM (Adaptive Case Management)
(пока стандарта нет, но его подготовка постепенно идет)
 CMIS
 HTML5
 XMPP (Jabber)
 REST (архитектурный стиль)
 JPA (Java Persistence API)

5. Расширяемость и адаптивность
 Высокая степень адаптивности системы, технологичность доработок и
расширяемость без перепрограммирования - за счет использования
«конструктора бизнес-решений» (КоБРа), в котором под каждое «БР»
создаются несколько взаимоувязанных моделей, определяющих самые
изменчивые аспекты БР:
 бизнес-объекты и их агрегаты/композиты;
 жизненные циклы бизнес-объектов;
 процессы (BPMN 2);
 роли и орг.стрктура;
 пользовательские интерфейсы (формы, представления, …)
 Отчеты
 Новое перспективное направление – кейс-менеджмент (об этом отдельно)
 Два уровня расширяемости:
 Системный / Полнофункциональный - КоБРа - для разработчиков, архитекторов,
системных аналитиков (в нашей компании, у партнеров, у заказчиков)
 Пользовательский – обычно это средства создания разных шаблонов – для бизнес-
аналитиков, предметных специалистов, продвинутых пользователей. Например,
шаблоны процессов согласования и совм.подготовки, шаблоны кейсов, …

6. Переносимость
 Поддержка разных конфигураций базового ПО от разных
поставщиков:
 Web-клиент: все современные ОС и браузеры
 Сервер: разные ОС и серверы Java-приложений
 РСУБД: DB2, Oracle, MS SQL, PostgreSQL, MySQL,…
 СУБД класса NoSQL
 ECM - (FileNet, OpenText, …)
 Конфигурации, полностью построенные на СПО, например:
 Tomcat+Spring+Hibernate+PostgreSQL+CouchDB+Lucene+OpenOffice+…
 Демо-конфигурация «всё в одном флаконе» (в 1 war-файле)
 Поддержка "нативных" клиентов (например, iPhone/iPad) без
изменений на стороне сервера

7. Интероперабельность
 SOA + REST = WOA
= Web-Oriented Architecture

8. Representational State Transfer
(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

9. Принципы REST
 Принципы REST
 Идентификация ресурсов
Индивидуальные ресурсы идентифицируются в запросах, например, с помощью URI в
Веб. Сами ресурсы концептуально отделены от представлений, возвращаемых
клиенту. Например, сервер отправляет не свою БД, а, возможно, некоторый файл
HTML, XML или JSON, представляющий некоторые записи своей из базы.
 Манипуляция ресурсами через их представления
Получив представление ресурса, включая метаданные, клиент имеет достаточно
информации, чтобы изменить или удалить ресурс на сервере, если он имеет на это
разрешение.
 Самоописывающие сообщения
Каждое сообщение содержит достаточно информации, чтобы описать способ
обработки сообщения, например, MIME-тип. Ответы также явно указывают
возможность кэширования.
 Гипермедиа как машина состояний приложения
Клиенты выполняют переходы в другие состояния только с помощью действий,
которые динамически определены ссылками в гипертекстовом представлении ресурса.
 Клиенту достаточно знать фиксированную точку входа в приложение и
MIME-типы ресурсов, для работы с которыми он предназначен

10. Производительность и
масштабируемость
 Система строится на базе самых современных Java-
технологий;
 Многоуровневая архитектура – возможность независимого
масштабирования слоев;
 Кэширование на всех уровнях обработки данных – от HTTP
(браузер – прокси - web-сервер) до СУБД;
 Уникальная документоориентированная модель хранения
данных, позволяющая использовать не только любую РСУБД,
но и NoSQL СУБД, что открывает перспективу неограниченной
масштабируемости

11. Многоуровневая архитектура
сервера
 User Interface (Presentation) Layer
 Операционный уровень
(координация прикладных
операций)
 Domain Layer (Model Layer)
Уровень предметной области

Из книги «Предметно-ориентированное проектирование (DDD):
Infrastructure Layer
структуризация сложных программных систем» (Эрик Эванс)

12. Многоуровневая архитектура CM
Клиенты
Мобильные Web-клиенты:
Конструктор
клиенты: 1. АРМ пользователя
бизнес-решений
iPad, Blackberry 2. АРМ руководителя
Сеть (HTTP)
Представление
REST-интерфейс
Предметная
область
Бизнес-объекты и логика ЭДО
Инфраструктура
Бизнес-объекты и
ECM
другие данные CM
WF/BPM:
SharePoint
BPMN 2.0;
OpenText
Alfresco
Domino
РСУБД
NoSQL
FileNet
СУБД
Lotus
ACM

13. Многоуровневая архитектура CM
Клиенты
Клиенты др.систем Другие системы (интеграция) Клиенты CM (разные)
Сеть (HTTP)
REST API (Web-сервисы в стиле REST) Представление
Другие системы (СЭД, ECM, почта, МЭДО, СМЭВ,…)
Предметная
Асинхронные Бизнес-объекты: документы, задачи, кейсы, контакты,… область
взаимодействия ЖЦ объектов, роли участников, события, операции (ЭДО)
с другими системами; Коллекции (общие, ролевые, персональные):
Внешний ЭДО: МЭДО, журналы, папки, представления, рез-ты поиска, задачи,…
корпоративный, … Службы: регистрация, контроль, планирование, поиск,
Репликация отчеты, ChLog, управление доступом, Locker, …
бизнес-объектов Процессы: согласование, ознак-е,… Кейс-менеджмент
Шлюзы в Инфраструктура
др. системы:
СЭД, Почта, Основной Вторичные
Календари, WF Engine:
репозиторий (производные) Сервер
Jabber/XMPP, BPMN 2.0; ACM; Кэш
бизнес- данные отчетов
WS SOAP, … WorkList Handler
объектов (индексы)
Шлюзы в ECM
Базовое ПО
OpenOffice Коллекции
Поиск Очереди Поиск:
БД: NoSQL, (РСУБД) Аналит. БД
в ECM сообщений Lucene;
Jabber (XMPP) РСУБД, …
(JMS) Solr (РСУБД, DWH)

14. Зачем несколько отдельных БД?
 Чтобы обеспечить одновременное выполнение
ключевых требований к системе:
 Переносимость
 Масштабируемость
 Подсистема хранения/обработки данных играет
ключевую роль в этих вопросах
 Проблемы:
 РСУБД масштабируются плохо/дорого
 NoSQL-БД масштабируются прекрасно, но есть «нюансы»
 Решение:
 Применять к каждому классу задач технологию, лучшую в
этом классе, интегрируя их в одной системе
 Предусловие:
 Задачи подсистем делятся на такие классы

15. Инфраструктура хранения
и обработки данных
 Первичные (оригинальные) данные
 Репозиторий всех объектов системы
• Документоориентированная модель данных
 Репозиторий контента. Варианты:
• в БД основного репозитория;
• в ECM-системе;
• в файловой системе
(только в конфигурации сервера «всё в одном»)
 Вторичные (производные) ресурсы
 Коллекции (разнообразные выборки по той части объектов, которая
находится в работе)
 Поисковый индекс
 Аналитическая БД
 Кэш (часто используемые объекты)
 Требования к РСУБД коллекций
весьма демократичны, т.к.
 Обрабатывается малый % всех данных
 Это не «первичные» данные

16. Репозиторий объектов CM
 Задача: эффективное хранение и предоставление всех
объектов:
 Бизнес-объекты и справочники, их атрибуты, версии и взаимосвязи
 Ролевые, групповые и/или персональные настройки
 Модели, шаблоны, создаваемые в «конструкторах»
 Экземпляры процессов
 Контент (опционально, если нет ECM - вообще или в конкретной СМ-сети)
 Всё остальное делается «этажом выше» - в слое предметной
области: репликация в «федеративном режиме», управление
доступом к объектам, разбор конфликтов,…
 Документоориентированная модель данных - хранение данных
как «документов» в смысле целостных объектов-агрегатов,
включающих всю информацию, фиксирующую каждое
принятое решение.

17. Репозиторий объектов CM
Нефункциональные требования
1. Высокая производительность, адекватная конфигурации системы,
начиная с минимальной;
2. Неограниченная масштабируемость;
3. Возможность развертывания в "облаках";
4. Высокая доступность (непрерывность функционирования) и
надежность;
5. Кроссплатформность (как минимум, Windows + Linux);
6. API для разработки на java и/или REST-API (по HTTP);
7. Глобальная целостность «в итоге» («eventual consistency»);
8. Транзакционная целостность (атомарность) операций с отдельными
документами

18. Репозиторий объектов CM
СУБД: SQL или NoSQL?
Перечисленным выше требованиям в настоящее время лучше всего
удовлетворяют базы/системы, построенные в соответствии с концепцией
"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

19. Конфигурация
«федеративной» системы

20. Внешние (подключаемые) системы
 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, ...)

21. CompanyMedia:
дополнительная информация
 Компания «ИнтерТраст»
http://www.intertrust.ru/
 CompanyMedia
http://www.companymedia.ru
 Инициатива «Новая СЭД – строим открыто»
 Специализированный подраздел на сайте CNews
http://opendev.cnews.ru/
 Блог ИнтерТраст на CNews
http://club.cnews.ru/ИнтерТраст
 CompanyMedia на Facebook
http://www.facebook.com/pages/CompanyMedia/200431593375537
 Очные мероприятия
 Более подробная презентация:
http://www.slideshare.net/vpanov/companymedia-next-architecture-vladimir-panov-26122011