«применение ит при автоматизированной компоновке приложений служебно-ориентированной архитктуры» (стр. 4 из 5)
Приведенная общая описательная модель реализации автоматической компоновки приложений служебно-ориентированной архитектуры обладает огромным преимуществом перед моделью, предложенной 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. Исполнение скомпилированной сборки
Обсуждение результатов
Рассмотрим сценарий, который описывает процесс ипотечного кредитования.
Рисунок 5 – Общая схема предоставления ипотечного кредита
Клиент, обращаясь за кредитом, обычно звонит в несколько банков, чтобы найти наилучшие условия. Каждый банк в свою очередь запрашивает у клиента личную информацию для оценки рисков и определяет индивидуальные условия кредитования. Как только клиент получает от банков все предложения, он может выбрать из них наиболее подходящее. Так как количество задействованных банков не существенно сказывается на организации всего потока работ, то с целью упрощения примера будет использоваться только один банк. Также добавим в приведенную выше схему посредника – брокера, который будет предоставлять клиенту услуги по сбору и обработке информации.
Далее подробно рассмотрим последовательность потока работ:
1. Пользователь, которому требуется кредит, через интернет заходит на предоставленный ему web-сайт.
2. Пользователь вводит свои личные данные (имя, адрес, SSN и т.д.) и жмет кнопку “Submit” («Подтвердить»).
3. Создается запрос на кредит и записывается в базу данных. Также генерируется идентификатор запроса и возвращается пользователю. Текущий статус запроса пользователя – SUBMITTED (подтвержденный).
4. Идентификатор запроса передается как параметр web-службе брокера для обработки. Брокер выставляет запросу статус “BROKER PROCESSING” («Обрабатывается брокером»).
5. Web-служба брокера выполняет BPEL-процесс брокера, который обращается в кредитное бюро, предоставляя идентификатор запроса.
6. В кредитном бюро по идентификатору запроса определяют SSN-код пользователя и получают по нему кредитную историю.
7. Кредитная история передается BPEL-процессу кредитного бюро, который анализирует ее и вызывает web-службу брокера, передавая ей идентификатор запроса и отчет по истории пользователя.
8. Процесс брокера далее вызывает web-службу банка и передает ей необходимые идентификаторы. Web-служба выполняет BPEL-процесс банка, который принимает решение о целесообразности выделения кредита и предает брокеру идентификатор, указывающий на заключительный отчет.
9. BPEL-процесс брокера возвращает web-службе брокера идентификатор заключительного отчета. Web-служба помечает запрос как “PROCESSED” («Обработанный»).
10. Когда пользователь следующий раз заходит на предоставленный ему сайт, он может по идентификатору запроса увидеть решение, принятое банком.
Как видно из описанной последовательности работ, BPEL бизнес-процессы необходимо обернуть кодом соответствующих web-служб (это можно легко сделать при помощи утилиты wsdl.exe, которая поставляется вместе с Visual Studio 2005/2008).
Рисунок 6 – Взаимодействие web-служб и BPEL-процессов
Таким образом, для поддержки автоматической компоновки всего приложения, необходимо
1. Зарегистрировать описания типов и абстрактных функций.
2. Создать соответствующие проекты в BPEL-редакторе.
3. Импортировать определения абстрактных функций.
4. Написать соответствующие BPEL-процессы, ссылаясь на импортированные данные.
5. При помощи wsdl.exe утилиты сгенерировать интерфейсы web-служб.
6. При помощи предоставленного вместе с BPEL-редактором шаблона реализовать тела web-служб.
7. Зарегистрировать написанные web-службы как исполнителей.
8. Написать web-сайт, который позволит взаимодействовать пользователю с системой.
Следует также заметить, что можно, например, зарегистрировать несколько кредитных бюро, реализовав в каждой web-службе дополнительную функцию проверки. Тогда ядро системы автоматической компоновки сможет выбрать из них то бюро, которое способно предоставить информацию о конкретном владельце SSN-кода.
Заключение
В результате проделанной работы было проведено исследование эволюции методологий разработки программного обеспечения, осуществлен анализ языков описания бизнес-процессов WSCI и BPEL, проработаны проблемы компоновки служебно-ориентированных приложений при помощи языка описания документооборота и автоматической компоновки приложений Entish, выявлены возможные пути расширения протокола и языка Entish, сделан общий анализ принципов взаимодействия языков описания высокого уровня и языков автоматического документооборота и компоновки на примере BPEL и Entish. Также был предложен ряд улучшений по повышению производительности системы на основе протокола и языка Entish, в том числе расширение на новую схему взаимодействия компонент. Практическим результатом работы является разработка и реализация программной системы автоматической компоновки приложений служебно-ориентированной архитектуры на базе широко распространенных стандартов и протоколов (SOAP, WSDL, XSD, HTTP) с внедрением основных идей заложенных в язык описания документооборота и автоматической компоновки приложений Entish. Также был проведен анализ возможных технический проблем при реализации такой программной системы, обоснована необходимость в использовании предложенной в данной работе архитектуры для решения поставленной задачи.
Список литературы к реферату
1. Сайт организации по продвижению стандартов для структурированной информации (Organization for the Advancement of Structured Information Standards) [Электронный ресурс]. - Режим доступа: http://docs.oasis-open.org/wsbpel/2.0/wsbpel-specification-draft.html.
2. Сайт с документацией по исполнительному языку описания бизнес процессов (Business Process Execution Language) [Электронный ресурс]. - Режим доступа: http://www.bpelsource.com/bpel_info/spec.html.