«применение ит при автоматизированной компоновке приложений служебно-ориентированной архитктуры» (стр. 3 из 5)
Тип «сообщение» описывает конструкцию, которая содержит заголовок (используется для служебной информации, такой как адрес отправителя и получателя, версия протокола, тип сообщения, идентификатор сессии) и тело (содержит формулу или список формул).
3.2 Распределение компонент соответствии с требованиями Entish
На рисунке 1 схематично представлен один из вариантов размещения компонент системы. Далее более подробно будут описаны назначения и функции каждого компонента.
Dictionary – это служба, которая служит словарем терминов, то есть она регистрирует, хранит и предоставляет данные о зарегистрированных функциях и типах.
InfoService – это репозиторий данных, в котором хранятся сведения о всех зарегистрированных службах. Например, некоторая служба реализует абстрактную функцию F, которая уже описана в словаре терминов. Тогда эта служба должна дать знать потенциальным клиентом о ее готовности осуществить ту или иную операции (в данном случае это функция F). Поэтому служба высылает запрос в репозиторий, в котором она говорит, что может выполнить функцию F и указывает, какие предусловия для этого должны быть выполнены. Репозиторий регистрирует эти данные и высылает службе уведомление, в котором указывает срок действия регистрации.
Рисунок 1 – Распределение компонент системы в соответствии с требованиями Entish
Task manager в данной схеме предоставляет клиентам возможность через браузер (в данном случае через Internet Explorer) взаимодействовать с системой и запускает работу агента по выполнению той или иной абстрактной функции (а именно, по поиску необходимых служб, их компоновке и запуску).
Web service – это один из многих поставщиков услуг, который должен зарегистрировать в репозитории и при необходимости добавить записи в словарь терминов.
3.3 Предложения по расширению протокола и языка Entish
В ходе анализа протокола и языка Entish был выявлен ряд недостатков:
1. Чрезмерное резервирование ресурсов.
2. Огромные объемы данных, циркулирующие по сети.
3. Нерешенная проблема выбора из множества поставщиков однотипных услуг.
4 Взаимодействие 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 описанием, а также абстрактные функции и их исполнителей.