Glassfish ESB v2.2

Вообще-то, версия 2.2 интеграционной шины GlassFishESB появилась еще в январе 2010 года. Но, по целому ряду причин, переходим мы на неё только сейчас. Переходим из-за того, что в это релиз вошел ряд критичных для нас исправлений. Но рассказать я хочу как раз не об исправлениях, а о появившемся в 2.2 новом функционале.
Наверное, самый интересный компонент релиза это Worklist Manager – приложение для управления деятельностью сотрудников. Worklist Manager включает в себя базу данных задач и web приложения как для конечных пользователей, так и для формирующих шаблоны задач аналитиков. Программ для управления задачами много, но в данной реализации интересна архитектура решения. Напомню, что архитектура ориентированных на людей систем управления бизнес-процессами формировалась под влиянием стандартов BPEL4People и WS-Human Task. Эти стандарты появились в 2007 году и были восприняты довольно неоднозначно. Почему так произошло – вопрос отдельный, нас же больше интересует одна из предложенных в этих стандартах архитектур. Предполагается, что система управления задачами делается отдельно от процессного движка. Такая система осуществляет хранение пользователей, групп пользователей, конкретных задач и т.д., а так же организует пользовательский интерфейс к этому хранилищу, благодаря которому пользователи могут видеть и решать назначенные на них задачи. Но, что достаточно важно, бизнес-логика управления задачами реализуется отдельно в виде обычных BPEL сценариев. Когда BPEL-сценарию требуется то или иное действие от человека, он вызывает  web-сервис, упомянутой выше системы. Когда задача решена(не решена, отклонена, потеряла актуальность) система возвращает управление BPEL-сценарию. Именно такую архитектуру и реализует Worklist Manager из GlassFish ESB.

Другие интересные дополнения релиза 2.2 — Email и REST binding компоненты. В архитектуре JBI (java business integration) binding компоненты отвечают за взаимодействие с внешними системами. Ваш BPEL-сценарий, как бы парадоксально это не звучало, совершенно не обязан являться SOAP сервисом. Различные бандинги позволяют запустить сценарии для обработки разных событий: появления сообщения в очереди, сохранение в каталоге файла и т.п. Вот теперь арсенал возможностей расширился сообщениями по e-mail и вызовами RESTful сервисов. Кроме того, ваш BPEL-сценарий может использовать эти же бандинги для вызова внешних приложений, не обеспечивающих SOAP интерфейсы.

И еще два интересных компонента BPEL Monitor и Event Manager я не успел посмотреть. Но думаю, по мере поступления новых задач они наверняка окажутся востребованными.

Реклама

4 Comments

  1. Email binding еще в 2.0 был доступен, кстати. А насчет ожидания BPEL-процессом возврата управления из Worklist Human Interaction — всё упирается в то, что нормальный Instance Passivation для BPEL-процессов пока отсутствует. Или будем самостоятельно докручивать?

    Ответить

  2. Ну, нам пока вроде бы пока это не надо. Потому как одному «длинному» процессу мы пока предпочитаем несколько маленьких молотилок, общающихся через общую БД.

    А вообще, согласен. Это блокирующий фактор применения технологии.

    Ответить

Добавить комментарий

Заполните поля или щелкните по значку, чтобы оставить свой комментарий:

Логотип WordPress.com

Для комментария используется ваша учётная запись WordPress.com. Выход / Изменить )

Фотография Twitter

Для комментария используется ваша учётная запись Twitter. Выход / Изменить )

Фотография Facebook

Для комментария используется ваша учётная запись Facebook. Выход / Изменить )

Google+ photo

Для комментария используется ваша учётная запись Google+. Выход / Изменить )

Connecting to %s