воскресенье, 21 июня 2009 г.

Введение в SOA и BPEL


Уже более полугода я занимаюсь разработкой описаний бизнес-процессов на языке BPEL. За это время удалось кое в чем разобраться, кое что структурировать и осознать. Результатом стала данная статья, впервые опубликованная на HabraHabr. Теперь же я решил привести текст статьи в своем блоге с необходимыми изменениями.

Давайте начнем с понятия "Корпоративная Информационная Система (КИС)." Такая система, как правило, представляет собой набор программного обеспечения разной степени однородности. Т.е. в лучшем случае все необходимое ПО (для организации бухгалтерского, оперативного и складского учетов, документооборота, сервисных служб, call-центра) закупается у одного вендора, в худшем же — полный бардак (что-то по-быстрому набросали сисадмины, что-то купили у Майкрософт, что-то у Naumen, а что-то вообще у 1С).

В то же время понятно, что пользователи (сотрудники предприятия) всегда должны иметь возможность получать любую необходимую им информацию, независимо от того, в какой системе она хранится и/или обрабатывается.

Для этого необходимо интегрировать все приложения, предоставляющие и обрабатывающие информацию в единую информационную систему. Одной из концептуальных возможностей решения такой задачи является использование SOA.


Сага о SOA


Сервисно-ориентированная архитектура (СОА, SOA) — понятие, которое в последнее время становится мэйнстримом в области разработки корпоративных систем. Не буду вдаваться в дебри теории, скажу лишь о сути. Суть SOA в том, что информационная система разбивается на несколько функционально законченных узлов — сервисов, которые взаимодействуют друг с другом. Собственно, это и есть концепция SOA, остальное (устройство сервисов, обеспечение связей между ними) — детали.

Сразу хочу предостеречь от путаницы. Сервис в терминах SOA и веб-сервис — разные вещи. Веб-сервисы — это один из наиболее распространенных способов реализации сервисов в рамках SOA. Но это ортогональные понятия: в рамках SOA сервисы можно заставить взаимодействовать через RMI, CORBA, OSGi, а самим сервисом может быть та же 1С Бухгалтерия. Точно также веб-сервисы могут взаимодействовать без всякой SOA. Кстати, про то, как создать веб-сервис с помощью xfire+spring+hibernate можно прочитать здесь.

Примерами сервисов могут являться такие узлы, как менеджер задач (всем сотрудникам в рамках КИС будут создаваться задачи и будет контролироваться их выполнение), сервис расчета зарплаты, сервис отображения начисленной зарплаты в интерфейсе КИС, сервис взаимодействия с пенсионным фондом, с налоговой инспекцией, сервис складского учета и т.д. Главное, что сервис — это некий черный ящик, который умеет получать, обрабатывать и выдавать информацию.

Раз сервисы обмениваются информацией, то возникает вопрос: «как организовать этот обмен». Дело в том, что сервисы потребляют, обрабатывают и выдают самую разную (как по семантике, так и по формату) информацию (грубо говоря бухгалтерской системе абсолютно параллельно распилены в цеху доски или нет, но не параллельно сколько часов их пилили и сколько рабочего времени потратили, его ведь надо оплатить). Более того, следует учитывать большое количество уже имеющихся legacy-систем, которые имеют свой формат представления информации.

Таким образом, первая проблема взаимодействие сервисов — согласование информации и форматов ее передачи.

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

Другим, более правильным, решением является использование сервисной шины (ESB — Enterprise Service Bus). Сервисная шина является посредником между сервисами. Соответственно, она обеспечивает унификацию формата обмена (теперь нужно всего лишь написать для каждого сервиса один конвертер — в формат шины), а также синхронизацию и управление обменом между сервисами.

В мире Java (а именно про этот мир я и буду писать) существуют такие реализации ESB, как:

— Sun Microsystems — OpenESB
— IBM — IBM WebSphere ESB
— BEA Systems (куплена Oracle) — ALSB (AquaLogic Service Bus)
— Oracle — Application Server 10g + WebService Manager
— JBoss — JBoss ESB + JBoss Web Services

Сага о BPM


Итак, первым вопросом было «как заставить сервисы взаимодействовать». Вторым вопросом является: «как управлять вызовом сервисов».

Давайте задумаемся над следующим: «Что такое вообще работа любого предприятия»? Т.е. что общего между работой больницы, школы, пилорамы, шинного завода и IBM? На мой взгляд общим является то, что деятельность любого из этих предприятий представляет собой множество параллельно выполняющихся последовательностей создания-выполнения-контроля-завершения задач, т.е. множество бизнес-процессов.

Примеры бизнес-процессов: обработка входящего письма, подготовка исходящего документа, составление инструкции, создание шестеренки, расчет заработной платы для сотрудника, оформление отпуска, оформление командировки и т.д.

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

Таким образом, мы вплотную подошли к рассмотрению класса систем, которые называются BPMS (Business Processes Management Systems — системы управления бизнес-процессами). В чем же особенности разработки таких систем и почему я до этого так много писал про какую-то SOA? А вся правда жизни в том, что BPMS очень удобно разрабатывать в рамках концепции SOA. Собственно, BPMS и SOA — это, как русский с китайцем — братья на век.

Фактически, реализация любого бизнес-процесса в рамках SOA является лишь последовательностью (зачастую очень хитрой и запутанной) вызовов тех или иных сервисов. Т.е. у нас есть набор строительных блоков — сервисов, мы задаем последовательность вызовов этих блоков — получаем автоматизацию бизнес-процесса. Меняем последовательность вызовов — получаем автоматизацию другого бизнес-процесса.

Несомненым плюсом такого подхода является высочайшая масштабируемость, причем как техническая так и функциональная. Добавляем новые сервисы — реализуем новые бизнес-процессы. Разворачиваем каждый сервис на свей машине — решаем проблемы производительности.

Теперь посмотрим, что же предлагают нам вендоры для работы с BPM:

— Sun Microsystems — Application Server GlassFish + java.sun.com/javaee/community/
— IBM — IBM WebSphere Business Modeller, IBM WebSphere Integration Developer, IBM WebSphere Process Server
— BEA Systems — BPM (Business Process Management), DSP (Data Services Platform)
— Oracle — Application Server 10g + WebService Manager
— JBoss — JBoss Web Services + JBoss BPM
— Active Endpoints — ActiveBPEL Engine + ActiveBPEL Designer

Сага о BPEL





Итак, мы разобрались с тем, что такое SOA и как заставить это все работать для решения основной задачи автоматизации предприятия — автоматизации обработки бизнес-процессов. Осталось рассмотреть такой вопрос: как описывать бизнес-процессы в терминах BPMS?

Вообще, некоторые вендоры (например, JBoss) предлагают свой формат описания, однако существует стандарт и этим стандартом является язык Business Process Modeling and Execution (BPEL, читается «БИПЛЬ»). BPEL — XML-based язык, что позволяет довольно легко его парсить машиной и в то же время читать и даже слегка править человеком. Также сохраняются все преимущества текстовых форматов, такие как легкость в передаче по сети, читабельность, работа с системами контроля версий и т.д. Подробное описание формата BPEL выходит за рамки данной статьи, опишу лишь основные понятия.

Как и в любом языке программирования в BPEL есть набор конструкций (можно рассматривать его как набор операторов). Так вот, операторов, которыми задается непосредственно действие, всего два: присваивание и вызов веб-сервиса (есть реализации, позволяющие вызывать EJB). Остальные конструкции являются управляющими — их задача обеспечить правильную последовательность присваиваний и вызовов внешних сервисов. В теории предполагается, что бизнес-аналитик будет рисовать бизнес-процесс, задавая порядок вызова сервисов, а программисты - разрабатывать эти сервисы.

Также любой BPEL-процесс имеет точку входа и точку выхода. Правда, это не совсем соответствует понятию «начало» и «конец» на схеме алгоритма. Точка входа представляет собой уведомление BPEL-машине о том, что надо создать и запустить экземпляр бизнес-процесса. Точка выхода — уведомление вызвавшей процесс системе о том, что процесс запущен. Также можно передать некоторые данные в вызвавшую систему, например pid процесса. После того, как мы уведомили вызвавшую нас систему о том, что процесс запущен, можем продолжать его исполнение.

Обычно работа с BPEL-описаниями процессов состоит из двух этапов: создание и выполнение. Создается процесс с помощью специализированных графических редакторов, которые позволяет этот процесс нарисовать. Примерами таких редакторов являются:

— Eclipse BPEL
— ActiveBPEL Designer (плагин для Eclipse)
— IBM Integration Developer
— NetBeans SOA-плагины
— Oracle JDeveloper

После того как процесс сохранен как .bpel-файл, его необходимо развернуть на сервере выполнения бизнес-процессов. Например, в ActiveBPEL Engine такой процедурой является создание bpr-архива: архива, включающего в себя bpel-описание процесса, метаинформацию, набор WSDL-файлов, описывающих вызываемые веб-сервисы и сам бизнес-процесс, как веб-сервис.

В этом, кстати, одно из преимуществ технологии BPEL — извне каждый бизнес-процесс представляет собой веб-сервис, имеющий собственное описание. В частности, запуск процесса представляет собой вызов веб-сервиса. Это позволяет рассматривать BPEL-Engine как один из элементов SOA и менять Engine не меняя описания процессов и не перестраивая всю архитектуру.

На этом введение можно считать законченным. Не думал, что статья получится такой длинной. Впрочем, в ней удалось описать суть основных технологий и понятий, которые постепенно становятся мэйнстримом при разработке КИС. Буду рад вашим комментариям.

Понравилось сообщение - подпишитесь на блог или читайте меня в twitter

14 комментариев:

Дмитрий комментирует...

Интересная тема. Надеюсь последует продолжение :)

Samolisov Pavel комментирует...

По возможности - да ))

Dawn Architect комментирует...

Хорошая статья, Павел. Хороший стиль и доступное изложение. Растёте в IT-публициста.

Samolisov Pavel комментирует...

Спасибо на добром слове. Я стараюсь.

Анонимный комментирует...

Спасибо за статью. Интересное и доступное изложение. Для начинающих тема очень насущная, помогает освоить логику SOA и BPEL. Ждемс продолжения))

Анонимный комментирует...

Павел, опиши, пожалуйста, как запускать процесс на сервере процессов. Еще интересно было бы узнать про Intalio. Отдельно можно упомянуть, что существуют интеграционные решения от Oracle, SAP, Microsoft

Samolisov Pavel комментирует...

Привет. С Intalio я не работал, но спасибо за наводку - посмотрю.

По поводу деплоя процессов - он зависит от используемой BPEL-машины. Мы используем ActiveBPEL, там деплой выглядит так: создается процесс (.bpel-файл), создается его дескриптор развертывания (руками или через визарды ActiveBPEL Designer). В дескрипторе описываем все PartnerLink-и. Затем импортируем процесс в архив - .bpr файл. Импортировать можно так же с помощью дизайнера (он, кстати, может сгенерировать для этого ant-овский скрипт). Полученные .bpr-ки кладутся в каталог /bpr томката, откуда их подхватит ActiveBPEL. Профит!

Samolisov Pavel комментирует...

Сорри, не импортируем, а экспортируем. Дальше - по тексту )

Konstantin Pavlov комментирует...

Хочется заметить, что использрование SOA в реальном проекте может быть оправдано только если компоненты между, которыми организуется взаимодействие,
представляют собой для разработчика "черные ящики", но имеют четко специфицированное поведение и API, если разработчики не могуть изменять эти компонетны.

Со временем, количество BPEL процессов в системе растет и расплачиваться приходится сложностью в поддержке такой системы: отладка, поиск ошибок, неоходимость изменять бизнес-процессы при изменении интерфейсов или логики работы компонентов.
Зачастую, единственным способом отловить ошибку в такой системе остается анализ запросов на транспортном уровне, используя для этого инструментов типа Http Analyzer, анализ логов и т.п.

В-общем, если можно не распределять объекты (компоненты системы), то их лучше не распределять.
А интегрировать бывает удобно через базу данных, хотя тут тоже есть много минусов...

Samolisov Pavel комментирует...

Во многом согласен - сейчас сам поддерживаю разросшуюся систему с немалым количеством процессов и подпроцессов.

Но. Если мы говорим об унаследованных системах от разных производителей, то структуры их баз данных могут сильно отличаться, поэтому большой вопрос какое решение будет проще.

Если же мы сами строим SOA-архитектуру (и сами ее документируем), то лазить с аналайзером придется только в случае затянувшихся дебагов, что бывает не так часто (сам не помню когда уже лазил по своей системе с аналайзером).

Распределять так же бывает нужно с целью повышения производительности, особенно, если сервисы очень загружены.

Александр Храмцов комментирует...

Устроился работать в Naumen в департамент DMS.
Опыта работы с BPM и OSGi до этого не имел, так что без Ваших статей как без воздуха =)

Pavel Samolisov комментирует...

Когда я там работал не все программисты знали что такое OSGi (т.е. не все создавали новые бандлы) и что такое BPEL (этим занимались выделенные люди). Интересно, это изменилось?

Igor Petruk комментирует...

Добрый день, Павел.

Думаю, что для блога не помешал бы критерий выбора графического редактора процессов, о котором Вы упоминали выше.

Мы с Вашей помощью делали проект в Украине "Ого!Диск".
Oracle JDeveloper использовался для этой задачи по умолчанию. Есть ли прелести в других редакторах и в чем они заключаются?

Уверен, что эта тема заинтересует соответствующее круги как разрабочиков, так и администраторов компаний Энтерпрайз-рынка, который и потребляет решения такого уровня.

Pavel Samolisov комментирует...

Здравствуйте, Игорь.

На мой взгляд выбор редактора не отделим от выбора платформы. Т.к. несмотря на то, что есть определенные стандарты (BPEL или BPMN) разрабатывать под каждую платформу удобнее всего в том редакторе, который вместе с ней поставляется. Просто потому что помимо собственно редактирования процессов, такие системы предлагают средства для их развертывания, отладки, модульного тестирования и т.д.

К тому же не стоит забывать, что производители включают в свои платформы нестандартизированные части, такие как движки бизнес-правил или ESB, которые требуют конкретного редактора.

Сам я работал в основном с двумя редакторами: Eclipse (для Oracle Service Bus и Active BPEL), а так же JDeveloper (для Oracle SOA Suite). На мой взгляд наиболее удобный редактор это - JDeveloper. Очень нравится работа с XML, мощный редактор процессов, мастера для настройки адаптеров, а так же редактор бизнес-правил и генерация пользовательских форм для Human WorkFlow. Для сравнения, редактирование XML в Eclipse сделано гораздо хуже. Редактор процессов в Active BPEL не умеет их форматировать, в итоге процесс представляется как набор "кубиков", соединенных ломаными линиями, читать такой процесс очень неудобно. BPEL-процессы в JDeveloper'е выглядят гораздо красивее, хотя справедливости ради иконки в Active BPEL мне нравятся больше.

Так же нельзя не упомянуть, что в JDeveloper'е из коробки реализована работа с базами данных. В последнее время для работы с базами данных я использую именно JDeveloper, соответствующие плагины в Eclipse мне просто не нравятся, да их еще и дополнительно ставить нужно.

Из недостатков JDeveloper'а я бы отметил две вещи: ресурсоемкость, но это исправлено в версии 11.2.1.0 переходом на OSGi и загрузкой плагинов по требованию. Второй недостаток - то, что в нем не реализована работа с Oracle Service Bus, поэтому разработка под данную ESB требует двух открытых редакторов - в JDeveloper'е создаются и настраиваются адаптеры, а в Eclipsе уже реализуются сервисы. Впрочем, Oracle обещает, что с версии 12с основной IDE все же станет JDeveloper, поэтому я очень жду Fusion Middleware 12.1.2.

Отправить комментарий

Любой Ваш комментарий важен для меня, однако, помните, что действует предмодерация. Давайте уважать друг друга!