Архитектура интегрированной ИС ТГУ. Возможный подход

Архитектура интегрированной ИС ТГУ. Возможный подход
Ситуация автоматизации
В процессе автоматизации деятельности ТГУ и разработки образовательного портала в ЦНИТ
было разработано и внедрено множество различных систем – Приемная комиссия, ОК
сотрудников и студентов, Кафедры, Деканаты, Документооборот, около двух десятков
различных модулей и заглушек портала. Учитывая существование в вузе также таких
программных продуктов как 1C (при чем как 7.7, так и 8.1), MarcSQL, шахтинские «Планы» и
«Нагрузки», АВТОРасписание, картина получается достаточно пестрая.
По мере того, как функциональность систем нарастает, мы все глубже и глубже начинаем
увязать в проблеме интеграции различных системы – в первую очередь, по ключевым данным
и сквозным бизнес-процессам. Остро встал вопрос о единых для всех систем данных по
подразделениям, должностям сотрудникам и необходимых для них классификаторах – типов
подразделений и должностей, ученых степеней и званий, статусов и т.д. Реализация любого
бизнес-процесса, затрагивающего несколько АИСУ, приводит к необходимости разрабатывать
шлюзы, причем логика бизнес-процесса оказывается зашитой в интерфейсах и коде шлюза, и
малейшие изменения процесса приводят к необходимости повторной разработки.
Причина проблем вовсе не в ошибочной архитектуре разрабатываемых систем. «Лоскутная
автоматизация» не лучше и не хуже, чем тотальная автоматизация единой информационной
системой. Второй подход (как, например, в системах SAP/R3 или Илада) хорош целостной
структурой данных и бизнес-процессов, но при большом разнообразии автоматизируемых
процессов становится тяжелым и малоэффективным. Очевидно, что бухгалтерия единой
системы лучше интегрирована, но уступает по возможностям 1C, то же самое касается
библиотечного учета, корпоративных сайтов, автоматического составления расписания и любой
другой специфической функциональности.
Речь идет о том, что кроме архитектур отдельных систем должна быть спроектирована и
реализована принципиальная архитектура всей интегрированной информационной системы
ТГУ. Возможные подходы и технологии интеграции гетерогенных систем и сервисов – одна из
наиболее обсуждаемых тем в сфере автоматизации деятельности в последние 5 лет.
Современные подходы
Еще лет десять назад информационные системы рассматривались только как средство
управления, позволяющее ускорить рутинные операции, повысить уровень учета, и при этом
обеспечить точное соблюдение заложенных в описание бизнес-процессов норм и правил
деятельности. Изменение бизнес-правил требовало особого рода процесса, называемого
«business-process reengineering», предполагающего работу команды профессионалов очень
высокой квалификации, в которую входили специалисты в области процессного подхода,
архитекторы информационных систем и разработчики структур данных и программного
обеспечения.
Но уровень как сложности, так и изменчивости современных бизнес-процессов постоянно
возрастает. Для таких процессов, как, например, учебный процесс, задачи полной
автоматизации становится практически нереальной – правила изменяются быстрее, чем
разработчики успевают описать и автоматизировать старые.
Сервисно-ориентированная архитектура
Ответом на этот вызов стала принципиально новая архитектура информационных систем под
условным обозначением SOA – Service-Oriented Architecture. Эта архитектура имеет ряд
ключевых характеристик:
- функциональность отдельных рабочих мест и операций в рамках процессов может
разрабатываться независимо – это и есть «сервисы», строительные кирпичики целостной
системы. По типу эти кирпичики напоминают элементы конструктора Лего – стандартный блок
можно использовать где угодно, колесо крутится, стекло прозрачно, но все они могут
соединяться между собой. Так, например, может быть реализован сервис «подготовить версию
документа для печати», или «рассчитать книгообеспеченность», или «отрисовать
технологическую карту учебного курса»;
- отдельные сервисы могут разрабатываться на различных языках и системах и существовать на
различных серверах, а взаимодействие между ними осуществляется через стандартные
протоколы Всемирной сети (отсюда и название – web-сервисы). В результате компоненты
системы могут быть даже раскиданы по различным континентам – так, сервис «Погода на
дорогах» сайта Gismeteo.ru использует в качестве фона карты дорог американский сервис
«Google Maps» со снимками со спутников НАСА (а кроме него «Google Maps» использует ещё
более 600 сервисов в мире);
Одним из существенных преимуществ архитектуры SOA является независимая
масштабируемость отдельных сервисов. В монолитной системе резкий рост нагрузки на любой
её модуль «тормозит» всю систему. В SOA-системе перегружается лишь отдельный сервис, и
проблема решается увеличением лишь его мощности.
Подробнее про SOA можно прочитать в Википедии (http://en.wikipedia.org/wiki/Serviceoriented_architecture).
В основе современной сервисно-ориентированной архитектуры лежит ряд ключевых
механизмов:
- ESB, Enterprise Service Bus;
- Service Orchestration and Choreography, оркестровка и хореография сервисов;
- Business Processes, формализованное описание бизнес-процессов;
- Business Rules, формализованное описание бизнес-правил;
- MDM, Master Data Management.
Рассмотрим эти механизмы подробнее.
Enterprise Service Bus
Идея ESB заключается в том, чтобы различные приложения взаимодействовали между собой
не через индивидуально разработанные шлюзы, а через единую шину, по аналогии с тем, как
взаимодействуют между собой аппаратные компоненты компьютера. Важной частью ESB
является единая для всей информационной системы модель сообщений. Если ранние версии
ESB (реализованные, например, на технологии CORBA, EJB или .Net) предполагали
единственный стандартный протокол обмена, то современные среды включают адаптеры,
поддерживающие интеграцию компонентов через множество различных протоколов, включая
SOAP, SMTP и POP3, JMS, JCA, HTTP GET/POST и многие другие, включая частные стандарты SAP,
Lotus и т.д. Стандартом формата сообщений является XML с описание метаданных при помощи
XML Schema, сервисы регистрируются на шине как веб-сервисы через WSDL-описание, шина
обеспечивает при необходимости трансляцию данных при помощи XSLT и XQuery. Среди других
функций ESB – маршрутизация, система управления событиями, обеспечение безопасности
соединения, управление транзакциями, мониторинг, аудит и администрирование. Иногда к
функциям ESB относят оркестровку и хореграфию сервисов, но обычно их рассматривают как
отдельный компонент сервисно-ориентированной архитектуры.
Существуют как дорогостоящие коммерческие продукты от Oracle, IBM, Sonic, так и недорогие и
бесплатные реализации ESB – Mule, Apache ServiceMix. Более подробно про ESB можно
почитать в Приложениях 14, 20 и в Википедии
(http://en.wikipedia.org/wiki/Enterprise_service_bus).
Service Orchestration and Choreography
Просто создать корпоративную шину недостаточно – это не решит основных проблем
интеграции. Необходимо обеспечить взаимодействие сервисов между собой, причем так,
чтобы логика этого взаимодействия не была зашита в код каждого из сервисов.
Оркестровка и хореография – это два подхода, решающие различные задачи интеграции.
Оркестровка предполагает, что один выделенный сервис «дирижирует» остальными, и вся
логика бизнес-процесса сконцентрирована в нем. Хореография обеспечивает свободный обмен
сообщениями (collaboration) и лучше подходит для процессов, ориентированных на
уведомления, события и массовые рассылки.
После того, как был утвержден стандарт языка описания процессов BPEL, обсуждение различий
между оркестровкой и хореографией постепенно стихает, поскольку BPEL с его расширениями
поддерживает оба подхода. Поскольку чаще всего решается задача интеграции сервисов в
сквозных бизнес-процессах, обычно просто упоминают о необходимости оркестровки. Пример
можно посмотреть в Приложении 11.
Business Processes
Попытки вынести логику бизнес-процессов из приложений предпринимались достаточно
давно. После пикового всплеска разработок различных языков описания бизнес-процессов в
течение последних пяти лет ситуация наконец стабилизировалась после того, как основные
игроки рынка (IBM, Oracle, Microsoft, SAP, BEA) разработали совместный стандарт BPEL. Про
историю развития языков описания бизнес-процессов можно прочитать в Приложениях 17, 18,
19.
Язык BPEL является ядром современной SOA-архитектуры. На нем описывается бизнес-логика
(как правило, в визуальном BPEL-редакторе), и особого рода веб-сервис (BPEL engine) работает
на шине ESB, выполняя загруженные в него описания процессов и «дирижируя» при этом
другими сервисами согласно бизнес-логике. Огромное преимущество такого подхода
заключается в том, что изменения в бизнес-логику могут вносить не программисты, а
менеджеры.
Коммерческие реализации управления процессами на основе языка BPEL, с дополнительными
расширениями и мощными возможностями масштабирования и интеграции – довольно
дорогостоящие продукты, так, Oracle BPEL Process Manager стоит $50000 на один процессор.
Однако на рынке есть и менее дорогие и даже бесплатные разработки – например, ActiveBPEL.
Прочитать про возможности, синтаксис BPEL, посмотреть на примеры решаемых с его помощью
задач можно в Приложениях 4, 10, 13, 14. Короткий и красивый пример того, как при помощи
BPEL можно организовать простой бизнес-процесс, включающий в себя электронный
документооборот, приведен в Приложении 3.
Business Rules
Формализация описания бизнес-процессов пошла еще дальше. Кроме того, что из кода
выделено устройство бизнес-процессов, из тела бизнес-процессов можно выделить так
называемые бизнес-правила. Бизнес- правила описывают те условия, при которых
выполняются те или иные действия в рамках бизнес-процессов, например «стипендия
назначается в том случае, если количество долгов за все предыдущие сессии 2 или меньше».
Выделение бизнес-правил имеет весомый смысл – они меняются гораздо чаще, чем бизнеспроцессы, кроме того, внесение изменений в бизнес-процессы требует довольно высокой
конструкторской квалификации, правила же формулируются на понятном логическом языке и
могут напрямую управляться менеджером.
Язык описания бизнес правил в большинстве предлагаемых коммерческих систем основан на
промышленном стандарте описания систем искусственного интеллекта Rete. Описание того,
как реализован механизм поддержки бизнес-правил корпорацией Oracle и как разделяются и
затем интегрируются между собой бизнес-процессs и бизнес-правила, можно прочитать в
Приложениях 1, 2, 6, 12.
Master Data Management
Интеграция сервисов в сквозные бизнес-процессы не решает проблему целостности
корпоративных данных. Проблема разных оргструктур ТГУ, с которой мы столкнулись – это
общая проблема всех крупных организаций, и для её решения разрабатываются специальные
системы под названием MDM – Master Data Management.
По сути, MDM – это очередная ступень развития систем Data Warehouse. Их основное отличие
от простого «склада» актуальных данных – это то, что они предлагают мощный пакет сервисов
по аналитике и отчетности на основе этих данных, что позволяет вынести в одно место всю
логику бизнес-анализа, оторвав её от конкретных приложений. Другими словами, функция
«распечатать оргструктуру ТГУ» или «вывести отчет такого-то типа» должны работать не с
данными ОК сотрудников или портала, а только с данными MDM.
Опять же, коммерческие реализации MDM очень дорогостоящие. Как правило, они включают в
себя поддержку конкретных типов данных (например, о продуктах, о клиентах и т.д.), и стоят в
зависимости от количества хранящихся в них записей. Например, лицензия Oracle Customer Hub
для систем B2B стоит $8 за запись, для систем B2C – $0,4 за запись, но минимальное количество
записей при приобретении лицензии определяется в 20000.
Представление о том, что сейчас происходит в мире MDM-систем, можно получить, прочитав
блог публикаций с сайте Forrester Research (Приложение 7). Фукнкциональность MDM-систем и
подходы к их построению подробно описаны в статьях (Приложения 15 и 16).
Что делать дальше
По мере нарастания степени автоматизации различных процессов, тем более в преддверии их
серьезных изменений (связанных в первую очередь с введением двухуровневой системы
обучения и кредитно-модульной системы) необходимо срочно совместно разработать
архитектуру единой интегрированной ИТ ТГУ.
Мы неоднократно обсуждали внутри ЦНИТ возможность формализованного описания бизнеспроцессов и вынесения их логики из кода. Теперь надо просто сделать это культурно, с
применением тех наработок и стандартов, которыми успешно пользуются системные
интеграторы в мире.
Предлагаю следующую последовательность шагов:
1. Начинаем эксперименты – закачиваем коммерческие демо и открытые реализации ESB,
MDM, BPEL, бизнес-правил, ставим, пробуем интегрировать с их помощью какой-нибудь
простой вымышленный процесс. Вполне возможно, здесь могут помочь практиканты.
2. Параллельно обсуждаем наши работы Программы развития-2008 и выделяем те,
которые будем пробовать делать в новой архитектуре. Очевидный кандидат на MDM –
данные об оргструктуре, должностях и сотрудниках. Что касается сквозного бизнеспроцесса – можно взять Науку с её публикацией в библиотеку. В любом случае брать
надо ещё не написанную систему, иначе вынесение бизнес-логики из уже написанного
кода станет дорогим удовольствием.
3. Обучаемся тому минимальному набору новых технологий, которые предстоит
использовать (очевидно, как минимум BPEL, WSDL, JMS, XSLT/XQuery).
4. Выбираем реализацию ядра SOA-системы и технологию MDM, организуем рабочий
сервер и поднимаем ESB и BPEL Engine. Если удастся найти недорогое решение MDM –
пробуем использовать его, иначе пишем свой простой сервис синхронизации,
интегрированный с ESB.
5. Реализуем первый в нашей жизни бизнес-процесс по-новому :)
6. Обсуждаем итоги, докладываем начальству, принимаем решение по дальнейшим
шагам.
Очень хочется не тянуть, а сделать шаги 1-6 в течение примерно двух месяцев.
Приложения
Приложение 1. b28965.pdf (англ.) – руководство пользователя Oracle Business Rules
Приложение 2. BPEL and Rules.doc (англ.) – статья про то, как выделять бизнес-правила из
бизнес-процессов и реализовывать всё это при помощи технологий Oracle
Приложение 3. BPEL в действии.doc – описание того, как организована интеграция NaumenDoc с
другими системами с упоминанием SOA, WSDL, BPEL и различных сервисов
Приложение 4. BPEL_Process_manager.pdf – презентация SOA-подхода и Oracle BPEL Process
Manager как одного из инструментов её реализации
Приложение 5. bpelAndRules.pdf (англ.) – «white paper» Oracle про то, как устроена архитектура
Oracle Business Rules и Oracle BPEL Process manager
Приложение 6. businessWhitepaper.pdf (англ.) – «white paper» Oracle про выделение Business
Rules, включая ссылки на сайты и другие продукты
Приложение 7. Data management.doc (англ.) – серия публикация в стиле блога с сайта Forrester
Research по теме MDM
Приложение 8. droz_pcweek.pdf – о платформах интеграции ИС бизнеса и государства с
анализом разных SOA-платформ
Приложение 9. forrester-aps-wave-overall-0707.pdf (англ.) – обзор Forrester Research платформ
серверов приложений для различных сценариев, анализ результатов
Приложение 10. orabpel-BPEL101.pdf (англ.) – краткий учебник по BPEL (Oracle)
Приложение 11. oracle soa suite - process orchestration.pdf – «white paper» Oracle про то, что
такое «оркестровка» сервисов при помощи Oracle BPEL Process manager
Приложение 12. oraclebusinessrulestechnicalwhitepaper.pdf (англ.) – «white paper» Oracle про
архитектуру Oracle Business Rules
Приложение 13. quickstart.pdf – руководство по Oracle BPEL Process manager
Приложение 14. SonicBPEL.pdf – краткое описание возможностей Sonic BPEL и Sonic ESB
Приложение 15. Бизнес по нормам и правилам.doc – подходы к управлению НСИ (MDM)
Приложение 16. Задачи управления мастер-данными.doc – подходы к построению MDMсистем
Приложение 17. Перспективы BPEL.doc – краткая история спецификаций BPEL, возможности и
ограничения
Приложение 18. Перспективы WorkFlow-систем.doc – несколько устаревшая, но хорошая
история автоматизации на основе процессного подхода, включая историю языков описания
бизнес-процессов и их математические основания
Приложение 10. Сравнение WorkFlow-языков.doc – сравнительное описание семантики
основных языков описания бизнес-процессов
Приложение 20. Тестирование ESB-пакетов.doc – на самом деле, сравнительный анализ SOAпакетов, довольно подробный, хотя и слегка устаревший