Далеко не первый год известны решения для описания и графического моделирования бизнес-процессов, которые стали ответом на растущий интерес к управлению предприятием на базе процессного, а не функционального подхода. Мы же обратимся к относительно новому сегменту программных систем, чьи производители используют аббревиатуру 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 допускает применение выражений, а также для манипуляций с данными пользовательских задач в рамках процесса.
Литература
- Putting the control of business processes into the business user?s hands. ZapThink White Paper, October 2004.
- А. Николаев. Автоматизация процессов, ориентированных на контент. «Открытые системы», 2004, № 11.