Взаимодействие BPEL и Entish

В ходе анализа протокола и языка Entish были выявлены существенные его недостатки, которые не могут быть полностью устранены в рамках принципов, заложенных в основу данного языка:

1. Чрезмерное резервирование ресурсов.

2. Огромные объемы данных, циркулирующие по сети.

Одним из путей решения этой задачи является организация взаимодействия BPEL и Entish. BPEL применяется "снаружи", то есть для конструирования сложного бизнес-процесса (и его выполнения), а Entish - "внутри", то есть для опрашивания текущего состояния услуги и получения ее согласия на участие в выполнении бизнес-процесса.

Согласно первоначальному анализу этой проблемы, задача сводится к расширению языка BPEL: необходимо разрешить привязку бизнес-процесса не к конкретным службам, а к абстрактным функциям. Ядро исполнительной системы при выполнении такого бизнес-процесса действует точно так же, как и при обработке процесса, описанного на стандартном нерасширенном языке BPEL. Отличия встречаются лишь в вызове ассоциированных служб: в стандартном варианте – это вызов жестко привязанных компонент, а в расширенном варианте предлагается осуществлять поиск, опрос и привязку компонент, основываясь на языке Entish. То есть по указанной абстрактной функции отыскивается в автоматическом режиме подходящая служба, опрашивается на предмет готовности к взаимодействию, и только потом уже вызывается.

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

Однако для реализации такого подхода надо унифицировать словарь терминов и определения типов для двух различных языков: BPEL и Entish.

Хорошо продуманный и широко поддерживаемый стандарт WSDL имеет один существенный недостаток: описание службы при помощи WSDL содержит только информацию об интерфейсе предоставляемых услуг и никоим образом не характеризует текущее состояние службы и ее семантику. Подобная проблема преодолевается в языке описания документооборота и автоматической компоновки приложений Entish путем проведения опроса вовлеченных в процесс взаимодействия респондентов. В то же время существенным недостатком языка Entish является чрезмерное резервирование ресурсов и использование собственных протоколов. А расширения языка Entish, позволяющие решить некоторые из вышеизложенных проблем (например, сужение на пошаговое исполнение), сводят почти на нет все его основные преимущества.

Исходя из всего выше сказанного, можно сделать вывод, что наиболее приемлемым путем развития идей автоматической компоновки приложений служебно-ориентированной архитектуры будет использование широко распространенных стандартов и протоколов для реализации инновационных идей. В данной работе упор был сделан на использование языков BPEL и WSDL, протоколов SOAP и HTTP, платформы .Net для адаптации и реализации инновационных идей, заложенных в языке описания документооборота и автоматической компоновки приложений Entish. А именно: оперирование абстрактными функциями при создании приложений служебно-ориентированной архитектуры, опрос готовности (определение состояния) респондентов, привязка нескольких исполнителей к одной функции и так далее.

4.1 Общая модель реализации автоматической компоновки приложений служебно-ориентированной архитектуры

Для того, что обойти необходимость разработки и реализации собственных протоколов обмена данными, а также проработки языков описания бизнес-процессов, в основу модели были положены языки BPEL и WSDL и протоколы SOAP и HTTP.

Приложение служебно-ориентированной архитектуры представляет собой реализацию некоторого бизнес-процесса, который с достаточной легкостью может быть описан при помощи языка BPEL. Основной проблемой на данном этапе является необходимость разрешения привязки бизнес-процесса не к конкретным службам, а к абстрактным функциям. Для реализации такой привязки более подробно необходимо рассмотреть способы задания респондентов в нерасширенном языке BPEL: элемент «partnerLinkType» из пространства имен http://schemas.xmlsoap.org/ws/2003/05/partner-link служит для описания типа ссылки на так называемого партнера текущего бизнес-процесса, которым является некоторая служба, а точнее - тип порта некоторой службы. Например, в WSDL описании службы тип порта может быть указан следующий образом

<wsdl:portType name="FileServiceSoap">

<wsdl:operation name="writeLine">

   <wsdl:input message="tns:writeLineSoapIn" />

   <wsdl:output message="tns:writeLineSoapOut" />

</wsdl:operation>

</wsdl:portType>

Тогда описание типа ссылки на «партнера» бизнес-процесса в языке BPEL может принять следующий вид:

<plnk:partnerLinkType name="FileLinkType">

<plnk:role name="application">

   <plnk:portType name="FileServiceSoap" />

</plnk:role>

</plnk:partnerLinkType>

Далее в BPEL описании бизнес-процесса объявляется ссылка на вышеуказанного партнера:

<partnerLinks>

<partnerLink name="file"

partnerLinkType="tns:FileLinkType"ь

yRole="application" />

</partnerLinks>

Для вызова метода ассоциированной службы необходимо использовать элемент invoke:

<invoke partnerLink="file"

portType="tns:FileServiceSoap"

operation="tns:writeLine"

<!--другие параметры--> />

При исполнении такого бизнес-процесса исполняющая среда спускается по цепочке до типа порта, определяет по его значению ассоциированные с ним элементы binding и service WSDL описания службы-партнера. Например:

<wsdl:binding

name="FileServiceSoap"

type="tns:FileServiceSoap">

<soap:binding transport=

   "http://schemas.xmlsoap.org/soap/http" />

<wsdl:operation name="writeLine">

   <soap:operation soapAction=

       "http://tempuri.org/writeLine" />

   <wsdl:input>

       <soap:body use="literal" />

   </wsdl:input>

   <wsdl:output>

     <soap:body use="literal" />

  </wsdl:output>

</wsdl:operation>

</wsdl:binding>

<wsdl:service name="FileService">

<wsdl:port name="FileServiceSoap"

   binding="tns:FileServiceSoap">

   <soap:address location=

       "http://localhost:4085/Site/FileService.asmx" />

</wsdl:port>

</wsdl:service>

Далее из элемента service исполняющая среда извлекает адрес службы-партнера, формирует параметры необходимого метода и, собственно, вызывает саму службу.

В ходе анализа возможных реализаций привязки бизнес-процесса к абстрактной функции было выявлено, что единственным реализуемым и приемлемым вариантом является подмена в элементе service URL адреса службы-партнера на адрес ядра программной системы автоматической компоновки приложений служебно-ориентированной архитектуры. А именно: создается ядро системы в виде сайта, реализуется и регистрируется HTTP обработчик для некоторого нестандартного расширения, например, «func». Пусть http://localhost:4085/Kernel.Web/ адрес ядра системы. Тогда элемент service WSDL-описания службы-партнера примет вид:

<wsdl:service name="FileService">

  <wsdl:port name="FileServiceSoap"

   binding="tns:FileServiceSoap">

    <soap:address location=

   "http://localhost:4085/Kernel.Web/Repository.func" />

  </wsdl:port>

</wsdl:service>

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

Тут также следует заметить, что ядро системы должно выполнять еще и функции репозитория, то есть позволять регистрировать типы и элементы с их словесным и WSDL описанием, а также абстрактные функции и их исполнителей.

Приведенная общая описательная модель реализации автоматической компоновки приложений служебно-ориентированной архитектуры обладает огромным преимуществом перед моделью, предложенной Entish, а именно: она использует исключительно стандартные языки описания и протоколы, и поэтому исполняющей средой может быть любой стандартный сервер, будь это BizTalk от Mircosoft или BPEL Process Manager от Oracle.

4.2 Анализ возможных технических проблем и способов их решения

Как было указано выше, при выполнении бизнес-процесса, описанного в терминах BPEL, исполняющая среда осуществляет invoke-запрос к ядру системы автоматической компоновки. И поэтому одной из ключевых технических задач является решение вопроса низкоуровневой обработки таких запросов с последующей их переадресацией непосредственному исполнителю. То есть возникает необходимость работать на более низком уровне, чем модель web-форм в ASP.NET или Java, для поддержки специализированного вида обработки. Одним из способов решения такой проблемы является расширение конвейера HTTP платформы ASP.NET путем создания собственного обработчика HTTP.

Рисунок 2 –Концептуальная схема работы ядра системы автоматической компоновки

Каждый запрос в приложении ASP.NET обрабатывается специализированным компонентом, известным как обработчик HTTP. Обработчик HTTP является основой платформы обработки запросов ASP.NET. ASP.NET использует различные обработчики HTTP для обслуживания различных типов файлов. Например, обработчик для web-страниц создает страницу и объекты элементов управления, запускает код программиста и генерирует окончательный HTML. Обработчик для web-служб служит для решения более простой задачи – он просто десереализует сообщение SOAP и вызывает соответствующий код.

Рисунок 3 – Архитектура обработки запросов ASP.NET

Таким образом, все, что необходимо сделать для создания специального обработчика HTTP, – это:

1. Создать класс, реализующий интерфейс IHttpHandler.

2. Сконфигурировать web-приложение, которое является ядром системы автоматической компоновки.

3. Сконфигурировать соответствующий виртуальный каталог IIS (Internet Information Services).

Важным вопросом является также выбор исполнителя, а по возможности, и редактора бизнес-процессов, описанных в терминах BPEL. Как было упомянуто выше, это может быть сервер BizTalk от Mircosoft, или сервер BPEL Process Manager от Oracle, или любой другой исполнитель, поддерживающий стандарт BPEL 1.1. Однако тут следует заметить, что BizTalk и BPEL Process Manager являются очень тяжеловесными и дорогостоящими программными системами, к тому же они не приспособлены к импорту описаний типов и абстрактных функций из репозитория ядра системы автоматической компоновки. То есть операции импорта и экспорта придется выполнять вручную по средствам обращения к web-службе, предоставляемой репозиторием.

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

В ходе анализа возможных вариантов реализации клиентского приложения, было решено остановиться на библиотеке «BPEL for WF March CTP», которая позволяет производить преобразования BPEL описания бизнес-процессов в их описание в терминах Microsoft Windows Workflow Foundation (WF) и обратно. В свою очередь, технология WF широко поддерживается рядом инструментальных средств от компании Mircosoft, в том числе Visual Studio 2005 и 2008. Кроме того, поток работ, описанный при помощи WF, может быть скомпилирован и исполнен «на лету».

Рисунок 4 – Схема возможных преобразований бизнес-процесса

Таким образом, оформилась полная цепочка действий при реализации выполнения бизнес-процесса, описанного в терминах языка BPEL, которая в упрощенной форме принимает следующий вид:

1. Преобразования BPEL описания бизнес-процесса в поток работ в терминах WF.

2. Компиляция потока работ.

3. Исполнение скомпилированной сборки