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

Некоммерческая организация Business Process Management Group, образованная в 1992 году и называющая себя глобальным «бизнес-клубом» обмена идеями и практическим опытом в сфере управления бизнес-процессами, упоминает не одну сотню компаний и организаций, которые занимаются вопросами BPM. Как и в сфере средств моделирования, где представлены хорошо известные, но, по сути, нишевые предприятия, на рынке программных платформ BPM успешно действуют небольшие фирмы, среди которых известны своими комплексными решениями Axway, Fuego, Vitria и W4. Однако в последнее время это направление всерьез заинтересовало крупных ИТ-игроков. В результате приобретений или собственных разработок здесь сегодня конкурируют IBM, Oracle, BEA Systems, EMC, Fujitsu и др.

Понятия

Бизнес-процесс — это логически упорядоченная последовательность операций, выполнение которой направлено на достижение определенной цели бизнеса. Простота этого определения не должна скрывать сложности и многогранности бизнес-процесса. Например, рассуждая о сложности реальных процессов, аналитики компании ZapThink выделяют несколько их ключевых характеристик [1].

  • Процесс — это совокупность операций (в английской терминологии — activity). Операция, самый низкий уровень декомпозиции бизнес-процесса, представляет собой элемент работы, выполняемой сотрудником, автоматизированной системой или партнером организации. Операция может иметь определенные входные и выходные параметры, а также некоторые связанные с ней действия (action). Для того чтобы совокупность операций реализовала определенный бизнес-процесс, она должна выполняться в заданной и контролируемой последовательности.
  • Выполнение бизнес-операций может быть возложено на разные категории участников процесса (на отдельных лиц, информационные системы поддержки основного бизнеса и т.д.).
  • Процессы могут включать в себя другие процессы. Поскольку процесс определяется как совокупность операций, он сам может быть представлен как операция, результаты которой используются другими процессами. Такой процесс называется подпроцессом.
  • Процессы охватывают операции как в рамках одного предприятия, так и в сотрудничестве с другими организациями. Процесс пересекает границы не только функциональных подразделений, но и предприятия, включая в себя операции его партнеров.
  • Процесс имеет результат. По своей сути, он должен влиять на решение тех или иных бизнес-задач организации. Бизнес-процесс инициируется при определенных условиях и должен давать вполне определенные или ожидаемые результаты.
  • Процесс — неотъемлемая часть работы организации. Независимо от того, существуют ли в организации строгие методы и инструменты определения бизнес-процессов и контроля над ними или это происходит на интуитивном уровне, компания не может обойтись без бизнес-процессов.
  • Процессы могут включать в себя как автоматизированные операции, так и выполняемые человеком вручную.

Простой пример бизнес-процесса — обработка клиентского заказа. В такой процесс могут войти операции проверки кредитного статуса клиента, оформления заказа (включая операции инвентаризации, создания продукта или приобретения его у внешнего поставщика), назначения даты поставки и подтверждения доставки клиенту.

Если само понятие бизнес-процесса, несмотря на свою «объемность», не предполагает многозначных толкований, то управление бизнес-процессами (business process management, BPM) имеет далеко не одно пространное определение. Аналитики Aberdeen считают BPM новым подходом и новым инструментальным средством автоматизации бизнес-процессов и управления ими, учитывающим их сложную структуру и кроссфункциональность. BPM позволяет моделировать бизнес-процессы и поддерживать их в динамике, учитывая возможные уточнения и изменения в бизнес-требованиях. Аналитики Gartner определяют BPM как управление процессами, которое поддерживает транзакции (события бизнеса) от начала до конца с применением заданных в организации политик, или правил, определения моделей бизнеса.

Если мы имеем в виду комплексные решения, предназначенные для автоматизации описания и выполнения бизнес-процессов и в последние годы активно продвигаемые, то их основным отличием от прежних подходов к поддержке бизнес-процессов в ИТ является возможность отделить логику процесса от логики приложений, которые используются в ходе его выполнения. «Зашитая» в код приложений класса ERP реализация элементов бизнес-процесса не позволяет вносить оперативные изменения при изменениях условий выполнения процесса или общих требований бизнеса. Кроме того, даже простая бизнес-транзакция, например оформление клиентского заказа, охватывает различные функциональные подразделения и, возможно, вовлекает операции партнеров, а потому, как правило, задействует разные приложения. Это означает, что поддержка бизнес-процесса требует сложной интеграции прикладных систем, еще более усиливающей привязку логики бизнеса к конфигурации ИТ-инфраструктуры. Кроме того, не надо забывать, что бизнес-процесс включает в себя не только автоматизированные операции, но и человеческий труд. А его трудно учесть, рассматривая при управлении бизнес-процессом только те элементы, которые встроены в прикладные системы.

Выделение бизнес-логики в отдельный «уровень» ИТ-поддержки бизнес-процесса открывает путь к достижению динамичных адаптивных взаимосвязей между функционированием бизнеса и ИТ-инфраструктурой. Аналитики ZapThink характеризуют такие взаимосвязи как «нулевое сопротивление» между ИТ и бизнесом. Инструменты уровня управления бизнес-процессом должны поддерживать абстрактное описание логики выполнения операций бизнес-процесса, средства представления этих операций в информационных системах, интеграцию отдельных операций в единый процесс и мониторинг его выполнения. Если все эти требования выполнены, появляется возможность вносить изменения в бизнес-логику, меняя определение процесса. Другими словами, можно менять компоновку операций, не внося изменений в программный код соответствующих приложений. Таким образом, становится реальностью быстрая трансляция динамики бизнеса в поддерживающую его прикладную инфраструктуру.

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

Рис. 1. Концептуальная модель управления бизнес-процессами

Платформа BPM должна включать в себя следующие основные компоненты (рис. 1).

  • Дизайнер процессов (process designer). Служит для создания модели процесса, в которой определяются последовательность выполнения операций и потоки данных, присваиваются роли участникам процесса, вводятся правила маршрутизации и обработки исключений, задаются электронные формы, используемые участниками процесса для выполнения задач вручную, а также действия по интеграции автоматизированных бизнес-систем. Дизайнер позволяет сконструировать модель в виде графической диаграммы, задающей поток операций, с описанием деталей этой модели в виде свойств отдельных шагов, подпроцессов или процесса в целом. Дизайнер процессов — средство разработчиков процессов, бизнес-аналитиков, а не программистов, поэтому оно должно обеспечивать внесение изменений в бизнес-процесс путем простой модификации графической диаграммы и заданных свойств.
  • Механизм выполнения процессов (process engine). Среда исполнения экземпляра процесса в соответствии с его определением, созданным и утвержденным дизайнером процесса. Механизм выполнения отслеживает состояние процесса в каждый момент и гарантирует последовательность операций процесса, заданную в его графической модели. Для выполнения операций вручную участникам процесса посылаются нотификации о присвоенных им задачах, доступ к которым осуществляется с помощью списков задач (work list). Для шагов процесса, которые предусматривают автоматизацию операций с помощью бизнес-приложений (ERP, CRM, унаследованные системы и др.), механизм выполнения поддерживает единую среду интеграции. Она преобразует частные API и модели данных в стандартный интерфейс доступа к разнородным системам (например, на базе Web-сервисов), позволяя превращать их в многократно используемые компоненты бизнес-процессов.
  • Монитор операций (activity monitor). Отслеживает статус выполнения каждой операции процесса, анализирует производительность и проводит аудит истории процесса. Эта информация позволяет исследовать возможности совершенствования отдельных операций и повышения производительности процесса в целом. Источником данных для монитора операций является хранилище, которое пополняется сведениями о состоянии и истории каждого экземпляра процесса на стадии его выполнения.
  • Пользовательский интерфейс. Среда доступа к средствам BPM в ходе выполнения операций процесса.

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

Инструментарий BPM ориентирован преимущественно на бизнес-пользователей. Люди, хорошо понимающие логику бизнеса, получают возможность определять ее в стройных моделях, следить за ее реализацией и при необходимости менять. Еще одно ключевое преимущество данного подхода к BPM состоит в том, что не требуется выстраивать процессы «как есть» или «как должно быть» и внедрять новые решения для их поддержки. Можно комбинировать существующие и, не исключено, новые компоненты, в ходе выполнения «собирать» процесс из прикладных модулей и операций, выполняемых сотрудниками, и менять его, если того требуют новые условия ведения бизнеса.

Хотя платформы BPM возникли на стыке многих технологических направлений, основные корни этих решений относятся к двум областям ИТ — системам управления потоками работ и средствам интеграции приложений. Соответственно, можно выделить и две основные группы производителей, продвигающих комплексные системы управления бизнес-процессами. Первые имеют солидный опыт разработки решений класса workflow и строят свои BPM-продукты на этой базе, дополняя их унифицированными возможностями интеграции прикладных систем. Вторые специализируются на инфраструктурах интеграции и преобразуют их в платформы BPM, объединяя новейшие интеграционные стандарты с управлением потоками пользовательских задач.

От управления задачами к управлению процессами

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

Примером платформы BPM, эволюционировавшей из системы класса workflow, может служить разработка Fujitsu Software — дочерней компании концерна Fujitsu, которая специализируется на аппаратном обеспечении, ИТ-сервисе и программном обеспечении. Ее решение Interstage BPM дополняет возможности автоматизации потоков работ системы Fujitsu i-Flow средствами интеграции приложений в смоделированный процесс. Управление потоками заданий между бизнес-пользователями остается центром решения BPM от Fujitsu. Модуль Workflow Engine позволяет запускать процесс и выполнять отдельные операции с помощью интерфейса Task Master, выводящего на экран настольных систем список необходимых задач.

Операции процесса могут выполняться в соответствии со значениями таймера, ассоциированными с операциями на этапе моделирования процесса. Для моделирования Interstage BPM включает в себя графический модуль Development Manager с интерфейсом на базе браузера, который предоставляет как простые средства комбинирования элементов процесса по принципу буксировки, так и более сложные, ориентированные на ИТ-специалистов инструменты описания элементов. Система моделирования поддерживает понятия подпроцесса и связанных процессов, привязку процесса и отдельных его операций к определенной роли или конкретному сотруднику организации, который будет отвечать за выполнение процесса в целом или его этапов.

Чтобы взаимодействия в рамках процесса не ограничивались связями между людьми в ходе выполнения работ, в состав Interstage BPM входят механизмы интеграции системного программного обеспечения и внешних приложений. Архитектура адаптеров (встроенных в платформу BPM или специально разработанных модулей) поддерживает использование разных СУБД, систем документооборота и служб каталогов. В партнерстве с компаниями-разработчиками Taviz и iWay предоставляются адаптеры для включения в бизнес-процесс наиболее популярных ERP-систем. Корпоративная редакция системы Interstage BPM базируется на J2EE-серверах приложений и использует их возможности включения в бизнес-процесс (в качестве операций) разных прикладных компонентов. Это осуществляется в том числе с помощью поддержки в операциях средств Javascript, а также обращения к внешним функциям как к Web-сервисам и представления в качестве такого сервиса бизнес-процесса в самой Interstage BPM. Платформой сервера приложений может быть сервер Fujitsu Interstage, внешнее решение IBM WebSphere или BEA Weblogic.

Согласно заключенному весной соглашению между Fujitsu и Software AG, система Interstage BPM станет частью семейства Software AG по реализации сервис-ориентированной архитектуры, поддержке композитных приложений и управлению бизнес-процессами. Это совсем новое направление в стратегии фирмы Software AG. Она традиционно специализировалась на решениях для мэйнфреймов и средствах интеграции унаследованных приложений, но с будущего года намерена активно включиться в конкурентную борьбу за долю рынка решений SOA и BPM.

Появившиеся в 80-е годы программные средства управления потоками работ во многих случаях фигурировали как встроенные функции систем документооборота. Сегодня ведущие производители решений по автоматизации корпоративного документооборота и управления контентом EMC Documentum и FileNet предлагают свои реализации управления бизнес-процессами. Отличительной чертой Documentum BPM является то, что эта система предназначена для управления бизнес-процессами, ориентированными на контент [2], т.е. процессами, в которых документы или другая неструктурированная информация определяют ход процесса или являются его результатом. Такие процессы присутствуют во многих областях человеческой деятельности: в производстве, страховом бизнесе, финансовых институтах, правительственных организациях, издательском деле, здравоохранении. Ориентация на контент достигается путем интеграции функций BPM и возможностей систем управления корпоративным контентом (enterprise content management, ECM), доминирующей сегодня в решениях Documentum.

Процессы, ориентированные на контент, делятся на две основные группы: процессы жизненного цикла контента и процессы с фиксированным контентом. Процессы первой группы отвечают за продвижение документов по всем этапам их жизненного цикла, включая создание, пересмотр, утверждение, публикацию, распределение и помещение в архив. К ним можно отнести поддержку Web-сайтов, утверждение технической документации, процедуру оформления новых лекарств, управление маркетинговой информацией. В этих процессах основные операции выполняются сотрудниками и традиционно поддерживаются системами workflow, но Documentum BPM добавляет основанные на единых принципах средства интеграции внешних бизнес-систем и других корпоративных бизнес-процессов. Общие интеграционные возможности, необходимые для системы BPM, в Documentum реализуются с помощью J2EE-архитектуры Business Process Services. В ней используются стандартные механизмы серверов приложений, в том числе Java Messaging Service и Web-сервисы.

В процессах с фиксированным контентом не подлежащие ревизии документы (заявления, заказы, счета) инициируют бизнес-процесс, определяющий логику выполнения операций процесса, например порядок обработки заказа. Documentum BPM объединяет автоматизированные возможности работы с объектами репозитария контента ECM-системы Documentum и операции с внешними бизнес-системами. Кроме того, поддерживаются специальные механизмы event listener, позволяющие системе управления бизнес-процессом моментально реагировать на появление новых или модификацию существующих объектов в системе управления контентом, а также на сообщения от внешних систем.

Важно и то, что Documentum BPM позволяет объединить две информационные инфраструктуры. Одну из них, предназначенную для управления строго структурированными бизнес-процессами, создает система BPM. А вторая, среда поддержки совместной работы, помогает в более или менее неформальном общении сотрудников при работе над документами. Системы Documentum eRoom и Collaboration Services создают интерактивное рабочее пространство, которое может стать операцией или подпроцессом бизнес-процесса, определенного в Documentum BPM. С другой стороны, из этой коллаборативной среды может быть запущен бизнес-процесс типа workflow — поток рабочих заданий сотрудников.

Cистема FileNet Business Process Manager (BPM), реализованная на платформе управления корпоративным контентом и бизнес-процессами FileNet P8, отличается от других поддержкой средств, которые расширяют традиционные возможности BPM. Это имитационное моделирование в модуле описания бизнес-процессов и встроенные средства интеграции с внешними системами управления бизнес-правилами. Имитационное моделирование (simulation) позволяет моделировать выполнение процесса без фактического развертывания экземпляра такого процесса. Это дает возможность исследовать выделение ресурсов под разные этапы процесса, тестировать альтернативные конфигурации и оптимизировать модель, добиваясь сокращения времени выполнения и улучшения других характеристик производительности.

Технология управления бизнес-правилами позволяет выделить элементы бизнес-логики, которые подвержены наиболее частым изменениям (из-за влияния корпоративных политик, внешних нормативных актов, контрактных условий и т.д.), и управлять выполнением этих элементов независимо от их реализации в приложениях. Интеграция управления бизнес-правилами с управлением бизнес-процессами обеспечивает автоматическую адаптацию бизнес-процесса к возможным изменениям бизнес-среды. Существует целый ряд нишевых компаний, специализирующихся на системах управления бизнес-правилами, в том числе Fair Isaac, Versata, ILOG и др. FileNet BPM поддерживает интеграцию с такими системами, предоставляя специальный инструментарий FileNet Rules Connectivity Framework. Для каждого нового процесса механизм выполнения FileNet BPM автоматически передает определение процесса в систему управления правилами, которая анализирует применимость тех или иных бизнес-правил к данному процессу.

Язык управления

Особый импульс развитию технологий BPM дал рост популярности нового подхода к разработке и развертыванию корпоративных приложений — сервис-ориентированных архитектур (service oriented architecture, SOA). Основная идея SOA состоит в том, что приложения, их компоненты и целые процессы могут быть представлены в виде сервисных единиц, выполняющих определенные функции, предоставляющих результат и взаимодействующих между собой. SOA полностью скрывает особенности реализации сервисов, поддерживая единые стандарты их описания и взаимодействия. В этой идеологии для реализации бизнес-процесса на базе SOA остается фактически, один шаг — задать логику его выполнения путем описания последовательности и условий взаимодействия сервисов, реализующих отдельные операции процесса. Процесс сборки и координации выполнения сервисов для реализации бизнес-процесса называется оркестровкой (orchestration).

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

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

На роль такого стандарта претендует язык BPEL4WS, или просто BPEL, у истоков создания которого стояли компании IBM и Microsoft, объединившие свои разработки в области описания бизнес-процессов с помощью Web-сервисов. Сегодня спецификация BPEL развивает организация OASIS.

BPEL — язык описания потока операций в бизнес-процессе и всего процесса в целом как взаимодействия Web-сервисов. Описание процесса («сценарий» на языке BPEL) интерпретируется и осуществляется механизмом выполнения процесса в системе BPM, который в данном случае лучше назвать механизмом оркестровки бизнес-процесса. Язык BPEL опирается на основные стандарты Web-cервисов: он строится на базе грамматики XML, реализует обращения к Web-сервисам через интерфейсы на языке WSDL и асинхронный обмен XML-сообщениями, использует WSDL и XML Schema для создания моделей данных.

Для описания логики выполнения процесса в BPEL предусмотрены нотации ожидания события, передачи сообщения, точки принятия решения, в которой выбирается дальнейший «маршрут» выполнения процесса в зависимости от данных в сообщении, параллельного выполнения операций, вызова внешнего сервиса, ожидания ответа, обозначения ошибочной ситуации и определения компенсационной обработки. Полученный бизнес-процесс представляется как один или несколько Web-сервисов с интерфейсом на языке WSDL. Платформы BPM с поддержкой BPEL для создания процесса обеспечат графические редакторы, которые позволят строить диаграмму процесса, трансформируемую в BPEL-сценарий (рис. 2).

Рис. 2. Диаграмма бизнес-процесса. Простой процесс резервирования билетов включает в себя операции проверки запроса, подтверждения менеджером возможности выполнения запроса и обращения к партнеру для резервирования

Не вызывает удивления тот факт, что пионерами реализации BPEL становятся производители инфраструктур интеграции приложений. Сегодня они являются основными проводниками в жизнь теории SOA и расширяют возможности своих серверов приложений за счет средств взаимодействия Web-сервисов. Компаниям BEA, IBM и Oracle вполне логично сделать следующий шаг от создания инфраструктуры передачи XML-сообщений между Web-сервисами к предоставлению инструмента оркестровки бизнес-процессов.

Модуль Oracle BPEL Process Manager вошел в пакет программных продуктов сервера приложений Oracle в результате приобретения компании Collaxa. Он включает в себя «джентльменский набор» компонентов платформы BPM: графический интерфейс моделирования, сервер выполнения процесса, консоль на базе Web-браузера для мониторинга процесса и репозитарий для сохранения данных о процессе во время выполнения. Система может быть развернута не только на базе Oracle Applications Server, но и на J2EE-платформах от IBM и BEA, а также на основе сервера приложений с открытым кодом Jboss.

Если для Oracle выпуск продукта с реализацией BPEL был первым шагом к поддержке BPM, то для IBM и BEA Systems переход к BPEL является развитием их платформ управления бизнес-процессами. У IBM такой платформой является WebSphere Business Integration Server Foundation, которая, судя по последним анонсам, получает теперь название WebSphere Process Server и становится полноценным BPEL-сервером на базе сервера приложений WebSphere. Эта система включает в себя компонент Process Choreografer для выполнения бизнес-процессов, смоделированных с помощью инструментария WebSphere Business Integration Modeler.

Использование термина хореография (сhoreografy) в названии этого решения отражает тот факт, что поддерживается включение в бизнес-процесс не только прикладных компонентов, оформленных как Web-сервисы, но и заданий, выполняемых специалистами (т.е. решается задача более сложная, чем оркестровка Web-сервисов). BPEL Flow Manager в составе модуля Process Choreografer отвечает за выполнение бизнес-процессов, объединяющих прикладные компоненты и пользовательские задачи, которые назначаются определенным потребителям или ролям в соответствии с BPEL-описанием процесса. Включение пользователей в бизнес-процесс достигается благодаря интеграции BPEL-сервера с порталом WebSphere Portal. Мониторинг производительности Web-служб в ходе выполнения процесса осуществляет система WebSphere Business Monitor.

Поддержку спецификации BPEL в последней версии своей BPM-системы WebLogic Integration 8.5 недавно анонсировала компания BEA. WebLogic Integration включает в себя модуль Studio, предоставляющий графическую нотацию для моделирования бизнес-процесса, Java-сервер для выполнения процесса, до перехода на BPEL обеспечивавший интеграцию с помощью механизмов JMS и вызова EJB-компонентов, а также средства встраивания в бизнес-процесс подключаемых модулей (Java-классов) для расширения функциональности системы BPM. Кроме того, в него входят шаблоны, помогающие строить модели бизнес-процессов и разрабатывать подключаемые модули, наконец, специальное клиентское приложение для предоставления пользователю возможности инициировать/останавливать бизнес-процесс или участвовать в его выполнении.

Однако, похоже, пока производители систем BPM на базе J2EE-инфраструктур не видят возможности отказаться от прямого обращения к компонентам, написанным на Java, и полностью перейти в определении бизнес-процесса на интерфейсы Web-сервисов. Как можно предположить, это связано с тем, что далеко не все корпоративные функции уже преобразованы в форму Web-сервисов, в то время как использование Java-компонентов позволяет запрограммировать логику сколь угодно сложных бизнес-процессов и увеличить производительность их выполнения. Во всяком случае, в Oracle именно последним соображением объясняют применение в BPEL Process Manager дополнительных средств реализации прямых вызовов Java API, которые обеспечивают встраивание кода Java в сценарий BPEL.

Компании IBM и BEA совместно работают над расширением языка BPEL под названием BPELJ. Оно даст разработчикам возможность реализовывать операции бизнес-процесса как программы на Java (так называемые Java snippets) и использовать Java как язык выражений там, где BPEL допускает применение выражений, а также для манипуляций с данными пользовательских задач в рамках процесса.

Литература

  1. Putting the control of business processes into the business user?s hands. ZapThink White Paper, October 2004.
  2. А. Николаев. Автоматизация процессов, ориентированных на контент. «Открытые системы», 2004, № 11.