Реализация бизнес-процессов в SOA

Повышение эффективности процессов в организациях основано на преодолении в них организационной и технологической разрозненности. В сочетании с постоянным мониторингом и реинжинирингом эти меры образуют основу методологии BPM.

Даниил Фейгин

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

Организационная разрозненность естественным образом сопутствует любой сервис-ориентированной архитектуре (service-oriented architecture): четкое разделение границ, в том числе административных, является базовым и определяющим постулатом SOA. Любое множество систем, «обитающих» в сервис-ориентированной среде, каждая из которых при этом находится в разном подчинении, может быть объединено в рамках того или иного бизнес-процесса без предварительного выполнения очередного интеграционного проекта. Для этого достаточно соблюдать некоторые правила, среди которых: декомпозиция систем до уровня контекстно-независимых сервисов, стандартизация контрактов таких сервисов и доступность информации об экземплярах сервисов для их потенциальных потребителей. Практическая реализация этих правил в каждой организации, конечно, выражается по-разному.

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

Модульность, издавна считавшаяся ключом к гибкости и многократности использования программных активов, благодаря SOA получила новую форму и новые качества, многократно увеличивающие ее эффективность, вследствие расширения сферы применения за рамки отдельных информационных систем. В результате интеграция приложений все чаще основывается на подходах SOA и технологиях Web-сервисов, что и не удивительно, учитывая преимущества предоставления бизнес-функциональности через слабосвязанные, общедоступные по сети сервисы. По этой причине SOA может стать мощным катализатором развития BPM: непрерывное совершенствование процессов, независимо от систем, поддерживающих их исполнение, подразумевает наличие гибкой инфраструктуры, способной обеспечить как интеграцию приложений, так и широкие возможности адаптации. Архитектурный стиль SOA основан на модульности и композиции, ввиду чего его, безусловно, можно считать подходящей основой для такой инфраструктуры. Если BPM преследует целью обеспечение эффективности процессов, то SOA — их адаптивности.

SOA и BPM не только методологически дополняют друг друга, а соприкасаются и напрямую. Чтобы убедиться в этом, достаточно рассмотреть структуру сервиса. Сервисы учетных систем предоставляют функции сохранения-выборки информации. Такие сервисы называют «мелкозернистыми» (fine-grained) из-за их низкого уровня абстракции и высокой детальности. Из них можно формировать «крупнозернистые» (coarse-grained) сервисы, которые, в свою очередь, могут компоноваться в бизнес-сервисы более высокого уровня. Конечно, вовсе не обязательно, чтобы сервисы были организованы в строго разграниченные слои — на практике это нередко не только не возможно (системы от различных разработчиков могут быть построены с разным уровнем гранулярности сервисов), но и не оптимально. Важен сам принцип обобщения — от специфических функций определенных систем к композитным сервисам уровня бизнес-архитектуры. Именно наличие слабосвязанных сервисов на разных уровнях позволяет гарантировать гибкость — за счет реорганизации связей. Композитные сервисы с практической точки зрения неотличимы от бизнес-процессов, за исключением наличия у них собственных интерфейсов, обеспечивающих поддержку интеграции процессов и очередного уровня композиции.

Рекурсивная композиционность сервисов позволяет также решить и непростую организационную проблему, из-за которой внедрение BPM часто не достигает желаемого результата. Инструменты BPM представляют бизнес-процессы в виде диаграмм, состоящих из последовательностей действий, к каждому из которых бизнес-аналитики привязывают те или иные операционные эквиваленты из ИТ-окружения. Такими операционными эквивалентами, конечно, могут быть и сервисы. Некоторые из этих сервисов могут быть самостоятельными бизнес-процессами, вследствие чего бизнес-аналитики могут специализироваться на отдельных предметных областях компании. Это позволяет экспертам накапливать знания, а не поверхностно заниматься «функцией BPM» во всех областях. Отсутствие специализации такого рода нередко приводит к некачественному описанию бизнес-процесса — например, такому, каким он некогда был или каким бы он мог быть, но так и не стал, а не к искомому описанию бизнес-процесса в том виде, в котором он фактически является или будет являться на самом деле.

Помимо собственно описания бизнес-процессов, для реализации BPM необходимо также иметь возможность точно представлять эти описания в виде ИТ-активов, а также развивать их по мере изменения бизнес-процесса. При этом путь от изменения процесса к изменению кода должен быть минимальным и прослеживаемым. Поэтому оркестрация является одним из наиболее многообещающих подходов, который заключается в исполнении специальным контейнером логики связывания сервисов, содержащейся непосредственно в описании бизнес-процесса. Для этого контейнер должен отвечать требованиям, характерным для интеграционных брокеров и мониторов транзакций, а интерпретируемые им процессы должны состоять из предварительно определенных алгоритмических и коммуникационных примитивов. С учетом этих соображений был создан язык BPEL (Business Process Execution Language), нацеленный на формирование сервисов путем рекурсивной композиции и совмещения модели процесса времени проектирования с моделью времени исполнения в едином описании.

Сегодня наиболее широко применяется спецификация BPEL4WS 1.1, опубликованная в марте 2003 года консорциумом компаний в составе BEA Systemms, IBM, Microsoft, SAP и Siebel. В ближайшие месяцы ожидается выпуск версии BPEL 2.0, имеющей статус стандарта OASIS.

Модель BPEL

Модель процесса в BPEL является прямым расширением сервисной модели WSDL (Web Services Description Language). У процесса, как и у любого сервиса, с которым он контактирует, должен быть описанный на языке WSDL интерфейс. BPEL следует принципу разделения описания сервисов на абстрактную часть и зависимую от внедрения. Так, модель процесса оперирует конструкциями типа: и , но не и , которые относятся к фактическим экземплярам сервисов, используемым процессом во время исполнения.

Зависимость BPEL от WSDL, вопреки расхожему мнению, отнюдь не ограничивает выбор протоколов, по которым можно контактировать с процессом и с используемыми им сервисами. Как язык описания интерфейсов сервисов WSDL не привязан к какому-либо протоколу, хотя зачастую протоколом доступа к сервису становится SOAP. Различие более очевидно, если учесть, что SOAP, в свою очередь, вовсе не подразумевает наличия WSDL. Более того, WSDL и не позволяет полностью описать модель передачи сообщений SOAP (SOAP Messaging Framework). BPEL компенсирует это в части своего расширения WSDL, путем предоставления модели специфицирования высокоуровневого протокола обмена сообщениями между сервисами.

Элементы и в WSDL не несут функциональной нагрузки с точки зрения типизации интерфейса процесса, хотя информация о фактических используемых протоколах и адресах, безусловно, необходима во время исполнения. Эти элементы, как правило, добавляются в генерируемый WSDL контейнером, в который загружена реализация сервиса на основании специфицированной пользователем конфигурации (в том числе протоколов и адресов). Управление передачей сообщений в ряде реализаций вынесено в отдельные [I]сверхконтейнеры[$], на которые ложатся функции адресации и маршрутизации, переключения протоколов, преобразования сообщений, применения бизнес-правил и управления соединениями. Сверхконтейнеры могут принимать различные формы, в том числе интегрированной ESB (например, реализация разработчика Cape Clear) или расширяемой компонентной архитектуры на базе JBI (Java Business Integration; например, проекты с открытым кодом servicemix и Mule).

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

Партнеры предоставляют сервисы с интерфейсами BuyerPT и SellerPT. Для крупнозернистых сервисов, таких как обработка заказов, типична ориентация на передачу целых документов, а не RPC-подобных вызовов с множеством именованных параметров. Новый элемент специфицирует связь, имеющую место между партнерами в рамках взаимодействия. Таким образом, BPEL расширяет понятие контракта, ограниченное в WSDL стороной провайдера. Это объясняет, почему этот элемент присутствует именно в элементе исходного WSDL. Партнерская связь Ordering специфицирует две роли, которые в данном случае являются как провайдером, так и потребителем друг для друга. Если бы ролей было больше, то элемент помог бы нам не запутаться, какие роли непосредственно контактируют друг с другом.

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

Пока мы не специфицировали в этой связке роль нашего сервиса (Buyer или Seller), а просто сообщили о ее наличии, аналогично тому, как не специфицирует экземпляров сервисов — продавец и покупатель с точки зрения этого WSDL равнозначны. Оба могут создавать на основе этого описания процессы, реагирующие на получение соответствующих сигналов сообразно их внутренней логике обработки и ИТ-архитектуре. Например, получив заказ, продавец, обращаясь к доступным приложениям и базам данных, может проверить наличие товара, соответствие указанных цен фактическим и т.д. Эта часть процесса, как и следует ожидать, не подлежит разглашению партнеру, а потому не содержится в публичных описаниях.

20.10.2005г