Lifetime Management with BPEL (Part III)

В июне 2006-го я начал этот блог чтобы делиться результатами своей деятельности в keyintegrity.

В то время я ходил в американский дом и мой английский был "в апогее" и, может быть поэтому, я начал блог на этом языке. Почти сразу же я понял, что задумка оказалась неудачной - это можно заметить по количеству английских постов - их 3 :)

Хотелось делиться этой информацией и обсуждать ее, причем делать это с русскими. Чтобы мои сокурсники или хотя бы какие-то студенты из моего университета услышали про такие технологии, как BPEL. Было очень обидно когда никто, включая самых молодых преподавателей, не понимал, что ты делаешь и чем занимаешься, хотя бизнес-процессы, их описание и управление - были одним из главных направлений моей кафедры. Но дальше SADT-анализа и UML никто не видел/не хотел видеть/не хватало времени заниматься... Не с кем было поговорить и обсудить эти темы не только на английском (где они и где мы), но и на русском... Может быть это и стало одной из основных причин, почему я длительное время вообще ничего сюда не писал.

Чтобы хоть как-то исправить ситуацию я написал курсовую работу Webseller и даже "выбил" академическую лицензию дизайнера ActiveBPEL для кафедры (тогда он еще был платным). На следующий год, кстати, по ActiveBPEL были поставлены лабораторные работы... Было приятно :)

Кстати, сейчас похоже их линейка называется ActiveVOS...

Но это все лирика, начатое всеравно нужно завершать, поэтому я назвал этот пост - Lifetime Management with BPEL (Part III), чтобы наконец-то закончить эту серию. Я не буду писать на английском и не буду здесь представлять законченного примера использования этого паттерна. Я даже не буду писать на BPEL, просто опишу словами то, что хотел.

Чтобы реализовать то, о чем я писал в предыдущей части нужно процесс (или его часть/scope, в которой определено состояние, например, содержимое корзины) заключить в контейнер Pick с несколькими обработчиками сообщений, среди которых должны быть:

1. обработчики onMessage, которые меняют состояние процесса (например, изменяют наполнение корзины);
2. обработчики onMessage, после которых процесс выйдет из scope'а (например, товары из корзины пойдут на оформление заказа);
3. обработчик onAlarm, который определяет время жизни состояния, после которого состояние должно сброситься.

Действие обработчиков 1 и 2 должны заканчиваться асинхронным вызовом этого же процесса. Изюминка заключается в том, что эти вызовы нужно выравнять при помощи correlationSet с контейнером Pick, чтобы последующие вызовы обработчиков этого процесса работали с той же корзиной. Это позволяет после каждого изменения состояния корзины продлевать время ее жизни на интервал, указанный в onAlarm.

В correlationSet в данном случае можно передавать, например, идентификатор корзины, по которому можно найти ее в БД.

Вот собственно и все. Лучше поздно, чем никогда :)

P.S.
Второй причиной, почему английский язык плох для ведения блога - потому что он не родной для меня и сковывает меня в красноречии :)

Кстати, этот же вывод я сделал по опыту разработок в нашей компании. Программисты не пишут комментарии... Это относится и к коду, и к документации (я имею в виду javadoc) и к комментариям к комитам...

Правилом хорошего тона является английский язык в комментариях - ведь код будут читать другие, особенно если это open source проект... Но всеже лучше что-то, чем совсем ничего... После того, как мы стали использовать русский язык в наших проектах, производительность заметно повысилась (как минимум один живой пример этому есть - это я :). И уже не лень и не напрягает написать пару лишних строк в описании метода, которые иллюстрируют примеры его использования и т.д. и т.п.

Практика сложилась так, что наши (русские) программисты умеют лучше читать и понимать английский, чем писать на нем и им разговаривать.

Ну, а если возникнет необходимость описать API, то его можно продублировать на английском языке - перевести самому или будет дешевле передать эту задачу переводчикам.

С одной стороны меня греет то, что русский open source от этого только выиграет, по крайней мере я так думаю :)

А с другой стороны есть правило - комментарии писать на языке заказчика. Так что делайте выводы сами.

Семинар Keyintegrity "Сближая бизнес и IT: методология и инструментарий BPM для эффективного управления бизнес-процессами предприятия"

Второго октября 2007 компания Keyintegrity провела бесплатный семинар в г. Набережные челны по теме "Сближая бизнес и IT: методология и инструментарий BPM для эффективного управления бизнес-процессами предприятия".

Я читал доклад о взаимосвязи SOA, BPMN и BPEL (презентация прилагается, 173 КБ).

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

На демонстрации разбирался пример, опубликованный в одном из предыдущих постов, реализованный на Intalio|BPMS.

Особенно хочется отметить роль Open Source'овых продуктов. Известно, что внедрение SOA рекомендуется начинать постепенно, с "маленьких" бизнес-процессов, потихоньку на практике знакомясь с особенностями применения данной методологии. Закупать для этих целей полнофункциональные продукты уровня Enterprise, такие как, например, семейство продуктов WebSphere (ESB, Process Server, и т.д.) - слишком дорогое удовольствие, а применение бесплатных Open Source аналогов может быть вполне оправданным.

Функциональных возможностей Open Source аналогов может быть вполне достаточно и для их дальнейшего использования в production, а если возникнет необходимость в переносе уже реализованного функционала на коммерческие продукты, то этот процесс не займет больших усилий:

1. С одной стороны благодаря поддержке открытых стандартов - для переноса возможно нужно будет поменять только схемы деплоймента (BPEL, WS, Java EE и т.д.);
   
2. С другой стороны это связано с одной из моделей коммерческого Open Source. Производители коммерческого ПО выносят базовую функциональность своих продуктов в Open Source, оставляя в коммерческой версии функции, необходимые для применения в production. В этом случае все проекты смогут работать в коммерческой версии "как есть".
   

Java-, WS- и XML-технологии в проекте WebSeller

Проект WebSeller, который я делал в магистратуре в рамках курсовой работы/проекта в 2005 году.

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

Аннотация

Цель данного учебного проекта – получить навыки разработки распределенных программных систем на платформе J2EE. В качестве основной архитектуры рассматривается сервис-ориентированная архитектура (Service-Oriented Archi-tecture, SOA) на основе web-служб. Рассмотрены основные технологии разра-ботки web-служб, в частности – JAX-RPC и язык описания бизнес процессов на основе web-служб – BPEL, а также разработаны две web-службы с использова-нием рассмотренных технологий.
В проекте используются, в основном, продукты Apache Software Foundation и другие open source проекты. Дается краткое описание использованных техноло-гий и приемы работы с ними.
Так же уделяется внимание унифицированному процессу RUP, как подходу к проектированию подобных учебных проектов.
В приложениях на компакт диске представлены исходные коды в виде проекта для IDE Eclipse 3.1; набор разработанных артефактов RUP для проекта, а также дистрибутивы использованных программных технологий.

Табл.: 2; Ил.: 15.

Скачать проект (2 МБ):

• Пояснительная записка
• Плакаты
• Артефакты RUP
• Проект WebSeller для Eclipse 3.1.1

Lifetime Management with BPEL (Part II)

It's time now to explain to the reader what I mean using the term "Lifetime Management".

The basic idea is handling the timeouts as they were previously defined before (see Lifetime Management with BPEL (Part I) with BPEL Peek example).

Standard BPEL allows us to handle duration or deadline timeouts by defining how much time should elapse before the timeout event will occur or by specifying the deadline date and time for the deadline (onAlarm's for and until attributes accordingly).

The new way I'd like to declare the process timeout expression is so that onAlarm can handle an automatic duration prolongation in the case when some of the duration expression conditions were changed. It's important to notice that you can not just change onAlarm's expression via, say, Assign activity (at least I couldn't found the way how to do that, so please inform me if you know the way).

Lets take an example of how to use this functionality.

Imagine a web shop that keeps a personal shopping cart for each of its customers.

A user may surf through the web shop, put some products in the cart and make an order.

One of usecases for this web shop may be the following:

• Customer wants to buy everything he placed in the cart (the good one :). In this case the system calculates an order and starts the process of billing and delivery of the products to the user;

Another possible usecase is:

• Customer leaves the webshop page (doesn't matter how - by navigating to another URL or just closes the browser window).

What should become with a customer's shopping cart and all the goods that he placed into it in the last scenario? Should we release all the items from the cart immediately? But what if the user will return to the page and act as in the first use case? Then he would have to navigate the site once again and take all the stuff he already did few time ago - bad usability.

On the other hand if we left the items in the cart forever then no one other would be able to buy the stuff that is in the other user's cart since it's already reserved.

So we need to specify the cart lifetime somehow so that all the items were released and the cart were cleared after the specified time.

The typical solution for a web shop here nowadays is using HTTP session but as we are talking about Web Services the HTTP session is not suitable for that. So we may use BPEL that can give us the functionality we need at the higher level of abstraction.

Why not just use BPEL onAlarm duration (the for attribute)? Since, as I already said above, it is not possible to change the duration expression at runtime while this is required to set the new cart lifetime after each cart update (say after adding new item to cart).

In the next part we'll see how to implement this example using BPEL and discuss some key aspects that you should pay attention for while using BPEL here...

Lifetime Management with BPEL (Part I)

Here we go...

I'd like to show you an example of BPEL (read BEEPLE :) that allows to implement some kind of a lifetime management using web-services.

This implementation is based on BPEL's Pick activity, and right before we start I'd like to introduce readers in what this activity is need for. Those who familiar with that may freely skip this part.

So, as I already said, BPEL have the Pick activity that is like widely known Switch/Case language construction in programming languages (Java, C++ or Pascal Case/Of). Those constructions have a possibility of redirecting control flow based on some expression, for instance (Java):

switch (directionExpression) {
case LEFT:
    moveLeft();
    break;
case RIGHT:
    moveRight();
    break;
case UP:
    moveUp();
    break;
case DOWN:
    moveDown();
    break;
default: // Hold
}

In BPEL the Pick activity is the analog of the Switch statement. Pick's OnMessage statements are like Switch's case statements.

To be true to the reader I'd like to say that BPEL have the Switch activity too. The main thing that distinguish Pick from Switch constructions is that Pick is a blocking activity, that means that the expression that manages the process control flow is a message that BPEL process instance is waiting for to receive, and the flow would be frozen until this message arrives, while in Switch we already have this expression defined as a process variable and the alternative flow may be picked up without any delay.

Now I'd like you to mention the default statement. Pick has the analog of this statement that corresponds the situation when no message were arrived to the Pick activity during some time period (or by deadline) - the timeout; and the activity that is responsible to handle such timeouts is Pick's OnAlarm.


So the BPEL code using Pick may looks like:

<pick>
<onMessage operation="approve">
<!-- TODO Implement OnApprove -->
</onMessage>
<onMessage operation="reject">
<!-- TODO Implement OnReject -->
</onMessage>
<!-- Timeout will occur in one minute  -->
<onAlarm for="&quot;PT1M&quot;">
<!-- TODO Implement OnTimeout -->
</onAlarm>
</pick>

to be continued...

References

• The BPEL specification - Business Process Execution Language for Web Services Version 1.1 (PDF, 507K)