Comments 6
А какое принципиальное отличие от того, чтобы написать это же самое на обычном языке программирования? Т.е. кроме того что вместо текста там квадратики и стрелочки — есть какие-либо плюсы?
Основная задача — окучить клиента. Если тупо показать ему код, то он почувствует себя дураком и покупать ваше изделие не станет. А схемки нехило поднимут его самооценку.
BPEL вообще мертворожденный язык. Изначально планировался для оркестрации вебсервисов и выполнения примитивной логики. Но внезапно оказалось, что людям требуется делать нечто бОльшее, чем тупые меппинги полей 1-1 при помощи XPath, а стандарт на этот счет молчал. Поэтому каждый кулибин внедряет в свой BPEL специальные нестандартные ноды типа «Compute», которые позволяют выполнять хоть что-то полезное в какой-нибудь среде: sql, java, etc. Сейчас BPEL повсемесно вытесняется BPMN-ом.
Основное отличие от кода на языке — возможность асинхронного выполнения процесса и «засыпания» с сохранением состояния в базе до прихода события извне, ответа вебсервиса, etc… Но это только для «хороших» BPMS.
О косяках концепта BPM как такового я писал здесь.
BPEL вообще мертворожденный язык. Изначально планировался для оркестрации вебсервисов и выполнения примитивной логики. Но внезапно оказалось, что людям требуется делать нечто бОльшее, чем тупые меппинги полей 1-1 при помощи XPath, а стандарт на этот счет молчал. Поэтому каждый кулибин внедряет в свой BPEL специальные нестандартные ноды типа «Compute», которые позволяют выполнять хоть что-то полезное в какой-нибудь среде: sql, java, etc. Сейчас BPEL повсемесно вытесняется BPMN-ом.
Основное отличие от кода на языке — возможность асинхронного выполнения процесса и «засыпания» с сохранением состояния в базе до прихода события извне, ответа вебсервиса, etc… Но это только для «хороших» BPMS.
О косяках концепта BPM как такового я писал здесь.
Изначально планировался для оркестрации вебсервисов и выполнения примитивной логики.
Вот интересно, почему тогда первые две буквы BP, это как бы намекает. Однако, в реальных бизнес-процессах помимо веб-сервисов есть ещё и люди. Помню, когда в своё время смотрел в сторону BPEL, возмутился этим фактом и стал рыть. Оказалось, что есть на эту тему какие-то extension's, но на то время ещё в статусе черновика и нигде так не реализованные (с тех пор я больше не интересовался судьбой этого стандарта).
Основное отличие от кода на языке — возможность асинхронного выполнения процесса и «засыпания» с сохранением состояния в базе до прихода события извне, ответа вебсервиса, etc…
Для этой цели я немного «докрутил» Java, чтобы она могла «засыпать». А именно: взял javaflow из апачевского инкубатора (это такой проект, который может обычный код в Java преобразовывать в корутины) и немного допилил напильником. В частности, оказалось, что ни стандартной сериализации, ни какого-нибудь kryo не хватает для того, чтобы нормально сохранить состояние выполнения. Пришлось писать свой простенький сериализатор с нужными мне фичами. Всё работает нормально, но проблема в том, что даже при малейшем изменении кода бизнес-процесса десериализация старых образов ломается, причём весьма неочевидным образом. Проблему удалось частично решить заменой бинарной сериализации на сериализацию в JSON и написанием дешифратора стека, который порождается javaflow. Короче, идея красивая, но вот эта проблема, в которую я упёрся, кажется, не имеет удовлетворительного решения.
С BPMN в своё время я намучился. Непонятно, для кого это. С одной стороны, аналитик их понимает и умеет редактировать. С другой, он без помощи разработчиков не может понять, почему этот вот "${foo.bar()}" работает, а "$foo.bar". Причём чаще всего бизнес-процессы у разных клиентов похожи до безобразия, и нужно обычно «чуть-чуть поменять вот эту штуку», ради чего приходится плодить кучу похожих диаграмм. По мне, так уж пусть лучше разработчики реализуют бизнес-процессы так, как им угодно, закладывая в них разумную вариативность, и предоставляя возможность тому же внедренцу/аналитику их настроить с помощью параметров. По крайней мере, на моём текущем месте работы этот подход себя вполне зарекомендовал, особенно по сравнению с предыдущей коробочной BPMS.
Про все эти BPM я уже ответил здесь: http://habrahabr.ru/post/273025/#comment_8690463 (Хабр мне не дает вставлять нормально ссылку).
С BPEL работал и работаю до сих пор. В самой его наихудшей реализации: IBM Websphere Process Server. Oracle SOA выглядит и работает значительно лучше. Самый лучший и во многом продуманный продукт — это JBoss BPM Suite.
Про асинхронное выполнение. Можно взять уже готовый движок jBPM или Activiti. Они в минимальном окружении весят 50кб и ничего дополнительного не требуют. Для Java есть фреймворк Quasar, который прозрачно для кода заменяет треды файберами, которые в свою очередь suspendable и serializable.
С BPEL работал и работаю до сих пор. В самой его наихудшей реализации: IBM Websphere Process Server. Oracle SOA выглядит и работает значительно лучше. Самый лучший и во многом продуманный продукт — это JBoss BPM Suite.
Про асинхронное выполнение. Можно взять уже готовый движок jBPM или Activiti. Они в минимальном окружении весят 50кб и ничего дополнительного не требуют. Для Java есть фреймворк Quasar, который прозрачно для кода заменяет треды файберами, которые в свою очередь suspendable и serializable.
Поправьте меня, если я ошибаюсь, но экзотический язык для бизнес-критичного приложения (мне нравится именно этот термин) — это залог монополии для производителя системы. Он будет её устанавливать, он будет её обслуживать, он будет диктовать условия. И кого-то другого я ему на замену не найду. Таким образом, я впадаю в ненужную мне зависимость. Так ли это?
С этой точки зрения, любые платформы-конструкторы бизнес-приложений, игр, web-сайтов и платные, и бесплатные «привязывают» к себе пользователя. Совершенно невозможно себе представить мягкий быстрый переход, например, с WordPress на Goomla или с Jira на SBM. Но так ли это плохо?! Платформы-конструкторы действительно сильно упрощают многие задачи и операции разработки новых приложений, резко повышают эффективность разработки. Если смотреть на этот вопрос еще шире, то даже чистое программирование на C# на самом деле резко сужает для вас список сред разработки, не так ли?
Ближе к теме статьи, как уже было замечено Throwable, на BPEL никто не автоматизирует процессы. Даже у нас на платформе SBM для этого используется своя простая нотация workflow (не BPMN, к сожалению), а модули, написанные на BPEL, только дополняют основной процесс необходимой функциональностью. Например, до или после действий пользователя на форме приложения, обратиться к внешней системе за информацией в синхронном режиме или записать во внешнюю систему информацию в асинхронном.
Еще один плюс — модуль на BPEL запросто можно переносить из среды разработки в промышленную среду вместе с кодом самого приложения без необходимости менять вручную массу параметров соеднения в коде.
Ближе к теме статьи, как уже было замечено Throwable, на BPEL никто не автоматизирует процессы. Даже у нас на платформе SBM для этого используется своя простая нотация workflow (не BPMN, к сожалению), а модули, написанные на BPEL, только дополняют основной процесс необходимой функциональностью. Например, до или после действий пользователя на форме приложения, обратиться к внешней системе за информацией в синхронном режиме или записать во внешнюю систему информацию в асинхронном.
Еще один плюс — модуль на BPEL запросто можно переносить из среды разработки в промышленную среду вместе с кодом самого приложения без необходимости менять вручную массу параметров соеднения в коде.
Sign up to leave a comment.
Создание бизнес-процесса на языке BPEL с использованием платформы Serena Business Manager