BPEL: состав сервисов для SOA

BPEL (Business Process Execution Language) стал одной из важнейших технологий SOA (сервис-ориентированной архитектуры) и позволяет легко и гибко объединять сервисы в бизнес-процессы. BPEL особенно важен, потому что он вводит новую концепцию в разработку приложений - программирование в целом. Эта концепция позволяет нам быстро разрабатывать процессы, определяя порядок, в котором будут вызываться службы. Таким образом, приложения (и информационные системы) становятся более гибкими и могут лучше адаптироваться к изменениям в бизнес-процессах.

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

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

Сервис-ориентированный подход

Подход SOA для эффективной автоматизации бизнес-процессов требует:

  • Стандартизованный способ предоставления и доступа к функциям приложений как служб
  • Инфраструктура корпоративной шины для связи и управления услугами, включая перехват сообщений, маршрутизацию, преобразование и т. Д.
  • Специализированный язык для компоновки открытых функций приложений в бизнес-процессы

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

С точки зрения BPEL, бизнес-процесс - это совокупность скоординированных вызовов служб и связанных действий, которые дают результат либо в рамках одной организации, либо в нескольких. Например, бизнес-процесс для планирования деловых поездок будет задействовать несколько сервисов. В упрощенном сценарии бизнес-процесс потребует от нас указать имя сотрудника, место назначения, даты и другие детали поездки. Затем процесс вызовет веб-службу для проверки статуса сотрудника. В зависимости от статуса сотрудника он выберет соответствующий класс обслуживания. Затем он вызовет веб-службы нескольких авиакомпаний (например, American Airlines, Delta Airlines и т. Д.), Чтобы проверить стоимость авиабилетов и купить ту, которая стоит дешевле.

Для клиентов процесс BPEL будет раскрывать свои функции так же, как и любой другой Web-сервис. С точки зрения клиента он будет выглядеть точно так же, как и любой другой веб-сервис. Это важно и полезно, поскольку позволяет нам объединять сервисы в простые процессы, простые процессы в более сложные процессы и так далее. Это также означает, что каждый процесс BPEL будет описан с помощью описания WSDL (язык описания веб-служб).

Основные концепции

BPEL - это язык на основе XML. Процесс BPEL состоит из шагов. Каждый шаг называется действием. BPEL поддерживает примитивные и структурные операции. Примитивные действия представляют собой базовые конструкции и используются для общих задач, таких как перечисленные ниже:

  • Вызов веб-служб, использование
  • Ожидание запроса, используя
  • Управление переменными данных с помощью
  • Обозначение неисправностей и исключений, использование и т. Д.

Затем мы можем объединить эти действия в более сложные алгоритмы, которые определяют этапы бизнес-процесса. Для объединения примитивных действий BPEL поддерживает несколько структурных действий. Наиболее важные из них:

  • Sequence ( ) для определения набора действий, которые будут вызываться в упорядоченной последовательности.
  • Flow ( ) для определения набора действий, которые будут вызываться параллельно
  • Конструкция case-switch ( ) для реализации ветвей
  • While ( ) для определения циклов и т. Д.

Как мы увидим, BPEL не сильно отличается от языков программирования, таких как Java. Но мы увидим, что BPEL отличается от Java и поддерживает характеристики бизнес-процессов. BPEL также предоставляет обработчики ошибок и компенсации, обработчики событий и наборы корреляции. Он предоставляет средства для выражения сложных параллельных потоков. Это также позволяет относительно легко вызывать асинхронные операции и ждать обратных вызовов.

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

Однако выбор правильного сервера BPEL может быть довольно трудным, поскольку есть несколько вариантов. Некоторые из самых популярных серверов BPEL, основанных на Java EE (новое название Sun для J2EE), включают Oracle BPEL Process Manager, IBM WebSphere Business Integration Server Foundation, BEA WebLogic Integration и AquaLogic. Также доступно как минимум четыре сервера BPEL с открытым исходным кодом: ActiveBPEL Engine, FiveSight PXE, bexee и Apache Agila.

Пример процесса

Давайте теперь посмотрим на пример процесса BPEL для деловых поездок, который мы описали выше. Мы разработаем асинхронный процесс, который будет использовать синхронный вызов для проверки статуса командировки сотрудника и два асинхронных вызова для получения цен на билеты на самолет. На рисунке ниже показана общая структура нашего процесса. Слева мы видим клиента, который вызывает процесс. Процесс сначала вызывает веб-службу статуса командировки сотрудника. Затем он вызывает веб-службы обеих авиакомпаний одновременно и асинхронно. Это означает, что процесс должен будет реализовать операцию обратного вызова (и тип порта), через которую авиакомпании будут возвращать подтверждение авиабилета. Наконец, процесс возвращает клиенту лучшее предложение авиабилета. В этом примере для простоты мы не будем реализовывать обработку ошибок,что имеет решающее значение в реальных сценариях.

Давайте теперь напишем код BPEL. Мы начинаем с объявления процесса - корневого элемента, где мы определяем имя процесса и пространства имен:

Далее мы должны определить партнерские ссылки. Партнерские ссылки определяют разные стороны, которые взаимодействуют с процессом BPEL. Сюда входят все вызываемые веб-службы и клиент процесса. Каждая партнерская ссылка указывает до двух атрибутов: myRoleкоторый указывает роль самого бизнес-процесса и partnerRoleуказывает роль партнера. В нашем примере мы определяем четыре партнерские ссылки:

Чтобы хранить сообщения, переформатировать и преобразовывать их, нам нужны переменные. Обычно мы используем переменную для каждого сообщения, отправленного веб-службам и полученного от них. В нашем примере нам понадобится несколько переменных. Для каждой переменной мы должны указать тип. Мы можем использовать тип сообщения WSDL, простой тип XML-схемы или элемент XML-схемы. В нашем примере мы используем типы сообщений WSDL для всех переменных:

Теперь мы готовы написать основное тело процесса. Он содержит только одно действие верхнего уровня. Обычно это позволяет нам определить несколько действий, которые будут выполняться последовательно. В последовательности мы сначала указываем входное сообщение, которое запускает бизнес-процесс. Мы делаем это с помощью конструкции, которая ожидает соответствующего сообщения. В нашем случае это TravelRequestсообщение. Внутри конструкции мы не указываем сообщение напрямую. Вместо этого мы указываем партнерскую ссылку, тип порта, имя операции и, необязательно, переменную, которая содержит полученное сообщение для последующих операций. Мы связываем получение сообщения с партнером-клиентом и ждем, пока TravelApprovalоперация будет вызвана для типа порта TravelApprovalPT. Мы сохраняем полученное сообщение вTravelRequest переменная:

Затем нам нужно вызвать веб-службу «Статус командировки сотрудника». Перед этим мы должны подготовить ввод для этой веб-службы. Мы можем создать такое сообщение, скопировав служебную часть сообщения, отправленного клиентом. Теперь мы можем вызвать веб-службу статуса командировки сотрудника. Мы делаем синхронный вызов, для чего используем активность. Мы используем employeeTravelStatusпартнерскую ссылку и вызываем EmployeeTravelStatusоперацию над EmployeeTravelStatusPTтипом порта. Мы подготовили входное сообщение в EmployeeTravelStatusRequestпеременной. Поскольку это синхронный вызов, вызов ожидает ответа и сохраняет его в EmployeeTravelStatusResponseпеременной:

Следующим шагом является вызов обеих веб-служб авиакомпаний. Опять же, сначала мы готовим требуемое входное сообщение (которое одинаково для обеих веб-служб). Мы сделаем одновременные асинхронные вызовы. Чтобы выразить параллелизм, BPEL предоставляет действие. Вызов каждой веб-службы будет состоять из двух шагов:

  1. Действие используется для асинхронного вызова
  2. Действие используется для ожидания обратного вызова

Мы используем для группировки оба вида деятельности. Эти два вызова отличаются только названием партнерской ссылки. Мы используем AmericanAirlinesдля одного и DeltaAirlinesдругого:

...