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 от этого только выиграет, по крайней мере я так думаю :)

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