Почему BPEL так важен?
Несмотря на то, что многие эксперты в области BPM и независимые аналитики восторженно приняли новый продукт компании Intalio – систему BPM 2.0 – вопрос о необходимости использования BPEL для многих из них остается открытым. Проблема выбора между языком BPEL и XPDL, (или BPEL и ничего) является одной из самых обсуждаемых за последние 10 лет истории BPM. В этой статье предпринята попытка объяснить, почему выбор был сделан именно в пользу языка BPEL.
Во-первых, необходимо прояснить один аспект: никто и никогда не должен пытаться написать BPEL код вручную. BPEL – очень сложный язык, имеющий с широкие возможности, поэтому крайне сложно отыскать человека, способного написать подходящий BPEL код вручную. BPEL – очень точный язык. Изначально он задумывался как язык, который автоматически создавается генераторами кода. Другими словами, язык BPEL предназначен для компьютеров, а не людей.
Во-вторых, если все-таки возникла необходимость написать код вручную, важно использовать упрощенную версию BPEL, основанную на менее подборном синтаксисе. Компания Intalio как раз работает над созданием такого языка в рамках проекта Apache ODE. Он называется SimPEL.
В-третьих, если требуется написать любой код, необходимо поднапрячься и создать свой BPEL код с помощью BPMN дизайнера, а не визуального BPEL редактора. BPEL – многосложный язык благодаря своей семантике и запутанному синтаксису, поэтому визуальный BPEL редактор мало чем может в этом помочь.
Теперь время обратиться непосредственно к преимуществам языка BPEL.
BPEL выиграл войну стандартов
Несмотря на то, что сначала компания Intalio проиграла одну битву, когда язык BPEL вытеснил BPML, с выходом BPEL 2.0 (осуществленном при поддержке компании Intalio) война, в конце концов, была выиграна. Все основные вендоры, включая компании Microsoft, Oracle и SAP приняли BPEL 2.0, отказавшись от XPDL.
Нотации BPMN не достаточно
Многие из тех, кто пять лет назад боролся за XPDL, теперь настойчиво утверждают, что ни BPEL, ни XPDL на самом деле не играют важной роли, так как все определяет нотация BPMN. Более того, многие ошибочно полагают, что система BPM предназначена для бизнес-аналитиков, которым важно только, как выглядит процесс. Исполняемые процессы не могут быть созданы только с помощью нотации BPMN. BPMN диаграмма – это всего лишь фундамент. Чтобы процесс заработал, необходима надстройка. BPEL – это строительный материал для ее создания. Стоит выбрать неправильный компонент и получится неправильный строительный материал. Чего же не хватает нотации BPMN, чтобы описывать исполняемые процессы? Данных. Если BPM вендоры утверждают, что только нотация BPMN определяет ход всего процесса, то они попросту пытаются навязать ненужные и затратные мероприятия, утверждая, что создание полностью исполняемых процессов невозможно без разработки индивидуального пользовательского кода.
Язык BPEL построен по правильной математической модели
У любого BPM вендора есть три способа сделать процессы исполняемыми: использовать BPEL, XPDL, или свой собственный язык. При использовании BPEL применяется математическая модель Pi-Calculus, поддерживающая исполнение распределенных и совместных процессов. Модель Petrinet model, которая поддерживает исполнение отдельных процессов, предоставляет ряд преимуществ при использовании XPDL. При использовании собственного языка или модели исполнения, процесс полностью лишен любых существенных математических обоснований, и долго не просуществует. Модели Petrinet подходят для исполнения отдельных процессов, но не могут быть использованы для моделирования исполнения независимых процессов, которые должны исполняться параллельно и синхронизироваться друг с другом. Другими словами, такие модели могут быть использованы для создания отдельных workflow-систем, которые не будут объединяться с другими приложениями или взаимодействовать со многими другими workflow-системами. Все эти интеграции и взаимодействия можно закодировать вручную, но это уже не BPM (по крайней мере, не система BPM 2.0), а традиционная интеграция корпоративных приложений (EAI).
BPEL поддерживает распредёленные транзакции
Благодаря такому явлению как Scope, язык BPEL 2.0 поддерживает распредёленные транзакции, которые исполняются с помощью испытанных двухфазных протоколов фиксации. Ни XPDL, ни любая другая традиционная модель исполнения процесса не поддерживает распредёленные транзакции, что не позволяет использовать их для широкого спектра корпоративных приложений. Распредёленные транзакции также можно закодировать внутри таких программных компонентов как Enterprise Java Beans, но это не BPM (по крайней мере, не система BPM 2.0), а традиционная онлайновая обработка транзакций (OLTP).
BPEL – это стандарт
Выиграв войну стандартов, BPEL стал отраслевым стандартом. А стандарты играют важную роль в построении любых систем. То же самое верно и для системы BPMS. Только если система BPMS построена на основе языка BPEL, процесс, созданный с помощью ее инструментария, может работать на движках других вендоров.
Исполняемых нотаций BPMN не существует
Многие противники BPEL утверждают, что нотация BPMN – это все, что нужно для работы системы, а в скором времени появятся и исполняемые нотации BPMN. На самом деле исполняемых нотаций BPMN не существует. И даже если кто-то и разработает что-нибудь подобное, то он попросту заново изобретет BPEL 2.0, или что-то очень похожее. Другими словами, сочетание BPMN и BPEL – это все, что необходимо для того, чтобы сделать процесс исполняемым, но стоит их разъединить и вся система рухнет.
Исмаэль Халими (Ismael Ghalimi)
Комментарии