Бизнес-процессы в стиле RESTful

Чрезвычайно насыщенная неделя не оставила времени для написания сообщений. Неделя еще продолжается, свободного времени не предвидится, потому сообщение в телеграфном стиле.

На НЕконференции BPMS.ru практически не удалось затронуть тему адаптивного кейс-менеджмента. Времени было мало и потому в ACM решили не погружаться. Я не думаю, что ACM что-то слишком сложное. Сложно понять ACM, находясь на позиции традиционного BPM. Разницу взглядов этих парадигм на процесс Jim Sinur сформулировал больше года назад своим противопоставлением Design by Doing – Doing by Design Перефразирую известного консультанта: в ACM процесс управляется людьми, а в BPM процесс людьми управляет. Что может предложить процесс, описанный в нотации BPMN людям в качестве рычагов управления? Практически ничего. Максимум, что может сделать сотрудник, это протолкнуть процесс дальше или же сгенерировать из назначенной на него задачи некоторое событие (безусловно, разработчик процесса должен при проектировании предусмотреть для сотрудника такую возможность).

А чего хочет сотрудник от BPMS? Возьму на себя смелость предположить, что как минимум определить следующую активность для данного экземпляра процесса. По сути, работа knowledge worker заключается в том, чтоб «гонять» процесс по определенному набору состояний (Ну, иногда еще порождать экземпляры вспомогательных бизнес-процессов). Таким образом, если вы хотите реализовать минимальный ACM, вам необходим движок, в котором реализован набор состояний и разрешенных переходов. Вопрос – где его взять? Не спешите с ответом. Я хочу предложить более «вкусный» вариант. Однажды Рой Филдинг придумал идею Hypermedia as the Engine of Application State Вообще-то, он придумал архитектурный стиль REST, а HATEOAS это скорее некоторый критерий соответствия программного интерфейса стилю RESTful, не суть. Существенно, что состояния – это разбросанные по интернет страницы(ресурсы), а допустимые переходы – гиперссылки между ними.

Обобщаем на бизнес-процессы: участник процесс получает страничку и набор гиперссылок в ней, определяющих переходы, допустимые из этого состояния в другие; думает головой, выбирает необходимую гиперссылку и тем самым «передвигает» бизнес-процесс в следующее состояние. Реализация довольно проста. Назначение задачи на сотрудника можно сделать сообщением электронной почты с набором гиперссылок. Нужно получить визу начальника – отправляем ему e-mail c гиперссылками: «утвердить», «отклонить», «отправить в спам» (Очень удобно в связи с поголовной «мобилизацией» руководителей. Компьютера может рядом и не оказаться, а мобильник с почтовым клиентом – всегда под рукой).

Ни тебе BPMN-ов, ни тебе BPMS-ов, поменять процесс «на лету» – вообще не проблема. Хотите Social BPM – перешлите письмо подчиненному с соответствующей резолюцией или же эксперту с традиционным вопросом: «Мне следует это подписывать?». Немного ловкости в проектировании формата гиперссылок на соответствующие активности, немного интеграции с почтовым сервером, причем как на рассылку, так и на получение сообщений и ваш мегагибкий BPMS готов. А кроме того, отсюда и до сетевых бизнес-процессов всего пара кликов рукой подать

Сценарии интеграции приложений (3)

Я довольно редко пишу о сценариях интеграции и потому не могу закончить с интеграцией данных и перейти к интеграции приложений и сквозным бизнес-процессам. Тем не менее, интеграция данных это важно. ESB, SOA и прочие трехбуквенные сокращения, занимая наше внимание, отвлекают нас от других, намного более важных трехбуквенных сокращений, таких как ODS и DWH. ODS и DWH – «рабочие лошадки» ИТ архитектуры предприятия, способные избавить нас от множества лишних информационных систем и оппортунистических связей между ними.
Читать далее Сценарии интеграции приложений (3)

Сервисная шина и очереди сообщений

В Москве с 1958 года существовала 3-я улица Строителей, но в 1963 году её переименовали — теперь это улица Марии Ульяновой, а дом 25 по этой улице — хрущёвская пятиэтажка. В Ленинграде (Санкт-Петербурге) 3-ей улицы Строителей не существовало никогда…


Я снова про интеграцию приложений. Читал сегодня отечественный стандарт межведомственного документооборота ГОСТ Р 53898-2010 И стандарт вроде бы «правильный» на XML-е писанный и поля там всякие полезные на 53-х страницах приведены и все дела. Помнится, в конце прошлого века я всячески ратовал за появление стандартов электронных сообщений на страницах журнала Компьютера в заметке Фактор Internet в развитии систем «клиент-банк» В конце прошлого века все выглядело оптимистичней, чем в начале нынешнего. Дот-комы еще не рухнули, небо было выше, трава зеленее, социальные сайты вызывали доверие, а Филдинг еще не защитил диссертацию с названием Representational State Transfer. Что же случилось за десять с небольшим лет и почему идея стандартизации формата электронного документа больше меня не прикалывает? Да ничего важного, просто парадигма интеграции приложений изменилась. Читать далее Сервисная шина и очереди сообщений

Сценарии интеграции приложений (2)

Возвращаюсь к теме интеграции корпоративных информационных систем, начатой в конце июня этого года с сообщения об интеграции посредством СУБД. Как и обещал, рассказываю про более эффективные способы интеграции данных. Вообще, причина возникновения этой темы обусловлена современными(правильней сказать уже не столь современными) технологиями управления базами данных. Вернее двумя ограничениями этих технологий. Читать далее Сценарии интеграции приложений (2)

Content Management Interoperability Services

OASIS единогласно утвердил стандарт Content Management Interoperability Services. Стандарт большой (в DOC формате занимает 229 страниц), что предполагает продолжительно и неспешное чтение.  Я думаю многие решат, что лучше вообще его не читать, а довериться дорогим вендорам. Тем более что встретили они его чрезвычайно восторженно. IBM гордиться своим участием в этой работе, в Alfrecso ждали этого стандарта чуть ли не всю жизнь, а Active Endpoints, оказывается, уже успел нам продемонстрировать интеграцию Системы управления бизнес-процессами (BPMS) с системой управления корпоративным контентом в соответствии с упомянутой спецификацией.

Все это наверное очень хорошо, но как всегда в подобных случаях возникают некоторые вопросы, а именно:

  1. Где же взять референсную имплементацию, чтоб пощупать это великолепие в действии, а заодно прояснить не оговоренные в спецификации  моменты.
  2. Неужели нельзя было вместе  с плоским файлом сделать структурированное описание, например, в виде вики или же того же самого Content management interoperability сервиса
  3. И сакраментальный вопрос: а CMIS это Enterprise 2.0 или нет? Ну и наоборот.

На третий вопрос, я думаю, в скором времени ответят аналитики в своих блогах. Ответы на остальные вопросы я надеюсь найти в стандарте, который отправляюсь изучать. Подозреваю, что вернусь оттуда не скоро B-)

Glassfish ESB v2.2

Вообще-то, версия 2.2 интеграционной шины GlassFishESB появилась еще в январе 2010 года. Но, по целому ряду причин, переходим мы на неё только сейчас. Переходим из-за того, что в это релиз вошел ряд критичных для нас исправлений. Но рассказать я хочу как раз не об исправлениях, а о появившемся в 2.2 новом функционале. Читать далее Glassfish ESB v2.2

RESTful и Enterprise 2.0

В 2006 году профессор Andrew McAfee, по аналогии с термином Web 2.0, придумал термин Enterprise 2.0. Для пояснения этого термина он использовал аббревиатуру SLATES (Search, Links, Authorship, Tags, Extension, Signaling), описывающую набор требований к Enterprise 2.0 решению. В дальнейшем это понятие стали развивать, улучшать и трактовать в разных смыслах, что существенно затуманило понимание вопроса. Зато дало большой простор для дискуссий не темы типа: является ли Sharepoint решением Enterprise 2.0.

В 2000 году Roy Fielding придумал и описал архитектурный стиль RESTful, который частенько позиционируют как стиль Web 2.0. Понять, что же Филдинг подразумевает под «REpresentational State Transfer» могут не многие. Поэтому, в отличии от истории с Макафи трактовки REST, как самим Филдингом, так и его приверженцами оказали бы вполне кстати. Объединяя обоих авторов, я предлагаю свою трактовку приложений Enterprise 2.0: Читать далее RESTful и Enterprise 2.0

HATEOAS

Этот страшный заголовок является аббревиатурой Hypermedia as the Engine of Application State. Википедия указывает указывается на заметку блоге REST APIs must be hypertext-driven , принадлежащую Рою Филдингу. Слабо понятное сокращение скрывает совершенно великолепную архитектурную идею:

Представьте себе, что ваш веб-броузер является конечным автоматом. Ну, может, помните, в институте изучалась такая вещь как конечные автоматы. Это такой черный ящик с некоторым набором состояний. Входные данные изменяют его состояния в соответствии с некоторым графом. Так вот: состояниями нашего браузера-автомата являются страницы всемирной паутины. Изменение состояния производится пользователем посредством перехода по одной из гиперссылок, представленных на текущей странице. Т.е. множество допустимых переходов из текущего состояния определяется используемыми на странице ссылками. Теперь вспоминаем, что любая программа является некоторым конечным автоматом и с удивлением понимаем, что наш броузер является как бы компьютером, исполняющим программу, написанную посредством веб-страниц. Т.е. программа развернута где-то там, в «облаке», а исполнение её происходит прямо у нас под носом, в окошке броузера.

Филдинг говорил об этом применительно к архитектурному стилю REST (Кстати, он его и придумал). Из примеров реализации такой архитектуры мне на память приходят автоответчики, сценарии которых задаются в виде voiceXML страниц. Ну, а вспомнил я об этом, раздумывая об архитектуре BPM систем.