БЕЛОРУССКИЙ ГОСУДАРСТВЕННЫЙ УНИВЕРСИТЕТВыпускная работа по«Основам информационных технологий» Магистранткафедры технологий программирования Литвин Александр Руководители:доцент Войтешенко Иосиф Станиславович, ст. преподаватель Кожич П.П.Минск – 2010 г. ОГЛАВЛЕНИЕ ОГЛАВЛЕНИЕ 3 СПИСОК ОБОЗНАЧЕНИЙ 4 РЕФЕРАТ НА ТЕМУ «ПРИМЕНЕНИЕ ИТ ПРИ АВТОМАТИЗИРОВАННОЙ КОМПОНОВКЕ ПРИЛОЖЕНИЙ СЛУЖЕБНО-ОРИЕНТИРОВАННОЙ АРХИТКТУРЫ» 5 Введение 5 Обзор литературы 6 Методика исследований 6 Основные результаты 7 1 Служебно-ориентированное приложение и проблема компоновки 7 2 Языки описания 8 3 Задача компоновки 10 4 Взаимодействие BPEL и Entish 13 Обсуждение результатов 19 Заключение 21 Список литературы к реферату 22^ ПРЕДМЕТНЫЙ УКАЗАТЕЛЬ К РЕФЕРАТУ 23 ИНТЕРНЕТ РЕСУРСЫ В ПРЕДМЕТНОЙ ОБЛАСТИ ИССЛЕДОВАНИЯ 24 ДЕЙСТВУЮЩИЙ ЛИЧНЫЙ САЙТ В WWW 25 ГРАФ НАУЧНЫХ ИНТЕРЕСОВ 26^ ТЕСТОВЫЕ ВОПРОСЫ ПО ОСНОВАМ ИНФОРМАЦИОННЫХ ТЕХНОЛОГИЙ 27 ПРЕЗЕНТАЦИЯ МАГИСТЕРСКОЙ ДИССЕРТАЦИИ 28 СПИСОК ЛИТЕРАТУРЫ К ВЫПУСКНОЙ РАБОТЕ 29 ПРИЛОЖЕНИЕ А 30 ПРИЛОЖЕНИЕ В. КОД ПРОГРАММЫ 34 ^ СПИСОК ОБОЗНАЧЕНИЙ BPEL – business process execution language, WWF – windows workflow foundation, ИТ – информационные технологии, WSDL – web services description language РЕФЕРАТ НА ТЕМУ «ПРИМЕНЕНИЕ ИТ ПРИ АВТОМАТИЗИРОВАННОЙ КОМПОНОВКЕ ПРИЛОЖЕНИЙ СЛУЖЕБНО-ОРИЕНТИРОВАННОЙ АРХИТКТУРЫ» Введение Большинство современных проектов в области информационных технологий являются большими программными системами с множеством тысяч строк кода. Производители программного обеспечения крайне заинтересованы в повторном использовании уже написанных и протестированных участков кода для экономии средств и избежания повторных ошибок. Именно по этой и ряду других причин методологии разработки программного обеспечения двигались от процедурного (функционального) программирования в сторону служебно-ориентированного программирования, эволюционно развиваясь и проходя стадии объектно-ориентированного и компонентно-ориентированного программирования. Эра служебно-ориентированного программирования преподносит разработчикам программного обеспечения множество преимуществ в области повторного использования кода, динамического распределения компонент системы, надежности и изолированности вторичного кода, межплатформенного взаимодействия, повышения масштабируемости приложений. Вместе с тем, служебно-ориентированное программирование ставит новые задачи, решение которых может послужить прорывом в традиционном понимании программирования. Одна из таких проблем – это проблема автоматической компоновки приложений служебно-ориентированной архитектуры. Решение этой проблемы, например, позволит значительно снизить затраты на разработку систем электронной коммерции, повысить их надежность и отказоустойчивость.Служебно-ориентированная архитектура (SOA) – это парадигма организации и использования распределенных информационных ресурсов таких как: приложения и данные, находящихся в сфере ответственности разных владельцев, для достижения желаемых результатов потребителем, которым может быть: конечный пользователь или другое приложение. Основная причина появления служебно-ориентированной архитектуры – это идея индустрии программирования о полной замене "кустарного" кодирования программ на "промышленную" сборку приложений из "стандартных комплектующих", как в автомобильной или других "традиционных" отраслях промышленности. На сегодняшний день существует ряд стандартов, принципов и наработок в этой и смежных областях (язык высокого уровня BPEL, языки спецификации WS-CDL и WS-Coordination, язык описания документооборота и автоматической компоновки приложений Entish и другие). Однако на сегодняшний день отсутствуют четкие принципы их взаимодействия, наличие которых могло бы позволить расширить концепции сервиса, предоставляя метод оркестрации, для объединения мелких сервисов в более обширные бизнес-сервисы, которые, в свою очередь, могут быть включены в состав технологических процессов и бизнес-процессов, реализованных в виде составных приложений или порталов. К тому же, некоторые из существующих наработок нуждаются в значительно доработке и оптимизации.Вообще говоря, использование компонентной архитектуры для реализации SOA - это область текущих исследований.^ Обзор литературы В литературе достаточно часто встречаются работы, в которых рассматриваются задачи компоновки приложений служебно-ориентированной архитектуры [1, 2, 7]. Однако работ, связанных с автоматизацией этого процесса, крайне мало. Одна из таких работ базируется на языке автоматизированной компоновки и описания документооборота Entish [5]. Основным недостатком метода, основанного на данном языке, является необходимость разработки и реализации пользовательских протоколов, а также общая низкая производительность всей системы из-за обширного применения резервирования ресурсов.^ Методика исследований Данную работу можно разбить на две основные части: теоретическую и практическую.Целью теоретической части работы являлись:Исследование эволюции методологий разработки программного обеспечения.Анализ языков описания бизнес-процессов WSCI и BPEL.Проработка проблемы компоновки служебно-ориентированных приложений при помощи языка описания документооборота и автоматической компоновки приложений Entish.Выявление возможных путей расширение протокола и языка Entish.Проработка принципов взаимодействия языков описания высокого уровня и языков автоматического документооборота и компоновки на примере BPEL и Entish.Целью практической части работы являлись:Разработка архитектуры программной системы (серверная и клиентская части), которая бы реализовывала одну из проработанных моделей автоматической компоновки служебно-ориентированных приложений.Реализация программной системы на языке CSharp. Тестирование полученной системы, выявление недостатков, определение возможных путей их решения.Примечание: здесь под методологией разработки программного обеспечения понимается система теоретических и практических принципов и способов организации и построения программных систем.^ Основные результаты 1 Служебно-ориентированное приложение и проблема компоновки Служебно-ориентированное приложение представляет собой результат агрегирования служб в одно логически завершенное, связанное приложение – по аналогии с тем, как объектно-ориентированное приложение образуется в результате агрегирования объектов.Само приложение может представить агрегат как новую службу, по аналогии с тем, как объекты строятся из меньших объектов.Внутри служб разработчики по-прежнему используют конкретные языки программирования, версии, технологии и инфраструктуры, операционные системы, API и т. д. Однако взаимодействие между службами организуется с применением стандартных протоколов и сообщений, контрактов и обмена метаданными.Разные службы приложения могут находиться в одном месте, быть распределенными в интрасети или Интернете; они могут быть созданы разными разработчиками, работать на разных платформах и технологиях, менять версии независимо друг от друга и даже выполняться в разных временных интервалах. Все эти вторичные аспекты остаются скрытыми от клиентов приложения, взаимодействующих со службами. Клиент отправляет стандартные сообщения службам, а вторичный код на обоих концах маскирует различия между клиентами и службами, преобразуя сообщения в нейтральное канальное представление, и наоборот.Поскольку служебно-ориентированные инфраструктуры предоставляют готовый вторичный код для объединения служб, чем выше степень детализации службы, чем интенсивнее приложение использует эту инфраструктуру и тем меньше вторичного кода приходится писать разработчикам. Если довести эту концепцию до крайности, каждый класс и примитив должен быть оформлен в виде службы — тем самым обеспечивается максимальная степень использования готовых средств взаимодействия и предотвращается необходимость «ручного» создания вторичного кода. Однако на практике существует предел детализации, определяемый в основном производительностью используемой инфраструктуры (такой, как WCF). Думаю, с течением времени и по мере развития служебно-ориентированных технологий границы служб будут непрерывно сужаться, и службы будут становиться все более детализированными, до тех пор, пока самые примитивные структурные блоки не будут оформлены в виде служб.Если считать повышение повторной используемости кода и ряд других вышеперечисленных аспектов единственными преимуществами служебно-ориентированного программирования, то это означает сильно ошибаться. Большой ошибкой будет не замечать наличие возможности перехода на новые принципы создания программного обеспечения: речь идет о полной замене "кустарного" кодирования программ на "промышленную" сборку приложений из "стандартных комплектующих", как в автомобильной или других "традиционных" отраслях промышленности.Предположим, что организация (поставщик услуг) выполняет некоторую услугу и предоставляет информацию об этой услуге в понятной форме всем заинтересованным сторонам (например, через репозиторий услуг). Другая сторона при выполнении сложного бизнес-процесса уже не нуждается в реализации всех мельчайших подпроцессов: она просто выполняет декомпозицию исходного бизнес-процесса до уровня, позволяющего передать работу поставщикам услуг, которые зарегистрировались в репозитории.Но тут следует заметить, что такой подход может быть реализован и при помощи простого взаимодействия, основанного, например, на веб-службах. Для того, что такой подход дал существенные преимущества, в него надо добавить возможность автоматической компоновки потока работ бизнес-процесса, который может быть описан на языке высокого уровня (например, BPEL). Далее в этой работе исследуются возможности языка Entish по автоматической компоновке таких приложений, анализируются его преимущества и недостатки, предлагается ряд усовершенствований.^ 2 Языки описания Возможность компоновки (composability) веб-служб часто рассматривают как одно из основных преимуществ технологии, обеспечивающее их многократное повторное использование. Вообще говоря, компоновка веб-служб — нахождение набора атомарных сервисов, необходимых для реализации запроса пользователя, и определение порядка их выполнения.Функциональные возможности каждого веб-сервиса определяются его входами, выходами, предварительными условиями и действиями, которые обозначают как IOPEs (inputs, outputs, preconditions, and effects). IOPE сервиса содержится в его WSDL-описании.Веб-службы с точки зрения их выполнения можно разделить на атомарные, которые не делятся на подпроцессы и могут быть вызваны пользователем через Интернет непосредственно, и составные, которые имеют подпроцессы, связанные конструкциями управления. Как правило, бизнес-задачи пользователя реализуют именно составные сервисы, которые могут быть скомпонованы из уже существующих атомарных.Концепция веб-служб подразумевает, что отдельные службы обладают определенной ограниченной функциональностью, в то время как для решения более-менее сложных задач требуется использовать функциональность нескольких служб. Поэтому в ходе развития архитектуры веб-служб возникли такие понятия, как композиция и поток, оркестровка и хореография. Они отражают взаимодействие сервисов и последовательность их выполнения; приложения, построенные с использованием веб-служб, рассматривают как основанные на потоках работ.Под оркестровкой понимают то, как сервисы взаимодействуют друг с другом на уровне сообщений, включая бизнес-логику и кооперацию при выполнении сложных процессов в пределах одного предприятия. Хореография охватывает более широкий круг участников взаимодействия, в том числе поставщиков, потребителей и партнеров предприятия. Она ассоциируется с публичным обменом сообщениями между множеством веб-служб, а не с одним бизнес-процессом, осуществляемым на одном предприятии. Стандарты хореографии и оркестровки опираются на WSDL. На уровне модели бизнес-процесса предложены такие проекты стандартов, как Wf-XML (Workflow Management Coalition), WSFL (IBM Web Services Flow Language), XLANG (Microsoft's XLANG: Business modeling language for BizTalk), PIPs (RosettaNet's Partner Interface Process). Наиболее распространены BPEL4WS (Business Process Execution Language for Web Services) от IBM, Microsoft, BEA Systems и отражающий концепцию хореографии WSCI (Web Service Choreography Interface), подготовленный компанией Sun. BPEL4WS предназначен для реализации оркестровки сервисов.В нижеследующих подразделах данной работы приводится концептуальное описание некоторых из вышеперечисленных стандартов.2.1 Язык BPELНа сегодняшний день создано огромное количество технологий и продуктов, которые решают задачи автоматизации бизнес-процессов предприятия. При этом главными проблемами в контексте предприятия в целом были и остаются задачи взаимодействия приложений от разных производителей и возможности динамического создания новых бизнес-цепочек на основе существующих модулей автоматизации.Язык BPEL (Business Process Execution Language) и концепция web-сервисов, с которой он тесно связан, представляет собой новый подход к описанию как собственно бизнес-процессов, так и механизмов их взаимодействия. Он открывает новые возможности для создания гибких, динамических бизнес-цепочек, способных быстро адаптироваться к меняющимся требованиям.На сегодняшний день BPEL представляет собой фактически единственный перспективный стандарт описания бизнес-процессов, на который ориентируются все ведущие производители программных продуктов и технологий. С момента включения BPEL в продукты таких вендоров, как Microsoft, IBM, Oracle начался постепенный процесс вытеснения собственнических (proprietary) технологий и интеграции корпоративных приложений.Теперь стандартный сценарий автоматизации бизнес-процессов состоит из двух этапов. На первом этапе предполагается создание набора компонентов, реализующих элементы бизнес функциональности, которые обычно реализуются в виде web-сервисов (хотя и не ограничиваются этим форматом). Второй этап - это организация взаимодействия приложений (сервисов) в рамках бизнес-процессов, так называемая "оркестровка".По существу, язык BPEL объединяет возможности языка WSFL (Web services flow language, Язык организации потоков Web-сервисов), разработанного компанией IBM, и языка XLANG, используемого в Microsoft BizTalk Server 2002. BPEL включает WSFL для поддержки графоориентированных процессов, а XLANG - для поддержки структурных конструкций для процессов. Таким образом, BPEL предназначен для поддержки реализации бизнес-процессов любой сложности, а также для описания интерфейсов бизнес-процессов. Надо отметить, что язык BPEL "неразрывно связан" со спецификациями WS-Coordination ("Координация Web-сервисов") и WS-Transaction ("Транзакции Web-сервисов"), которые были определены для совместного использования с BPEL и разработаны для координации транзакций и процессов. Так, в спецификации WS-Coordination описываются стандартные механизмы создания и регистрации протоколов транзакций, которые координируют выполнение распределенных операций в среде Web-сервисов. С помощью спецификации WS-Transaction можно отслеживать успех или неудачу каждого отдельного скоординированного действия в бизнес-процессе, задавать гибкую модель транзакций, которая обеспечивает целостность и надежность операций в распределенной среде Web-сервисов и позволяет бизнес-процессам обрабатывать сбои в ходе выполнения.2.3 Описательный язык WSCIWSCI - это описательный язык интерфейсов на основе XML, который работает в связке с WSDL. Его цель — позволить корпорациям использовать возможности веб-служб для создания процессов, отражающих меняющиеся требования бизнеса. Язык позволяет компаниям представлять свои прикладные программы и ресурсы в виде веб-служб, чтобы другие фирмы могли оперативно находить их и применять в своих бизнес-процессах.^ 3 Задача компоновки Большинство составных сервисов формируются вручную, используя основанные на WSDL описания (например, WSCI). Для автоматической компоновки программы должны уметь отбирать нужные службы и комбинировать их. При этом результат должен являться приемлемым решением поставленной задачи. Информация, содержащаяся в UDDI (Universal Description, Discovery, and Integration), недостаточна для автоматической компоновки сервисов, так как не позволяет интерпретировать их семантику. Ни WSDL, ни UDDI не дают программе понять, для чего именно с точки зрения клиента служит сервис. Поэтому так важны механизмы отображения семантики сервисов и ее автоматизированного сопоставления с семантикой запросов клиентов. Проблемы компоновки можно решить, связав параметры сервисов с понятиями определенной предметной области и их семантическим обоснованием.Как было уже сказано выше, проблема компоновки служебно-ориентированного приложения возникает, когда разработчик хочет избавиться от проблемы ручной привязки частей приложения к конкретным конечным точкам веб-сервисов (или просто сервисов). Для этого необходим протокол, позволяющий приложению-клиенту выражать свои намерения, а сервису-поставщику понимать эти намерения, анализировать их и при необходимости предоставлять информацию клиенту о готовности выполнить то или иное действие при условии удовлетворения некоторых предусловий.Одной из разработок в направлении автоматической компоновки служебно-ориентированных приложений является язык описания и компоновки Entish, который подробно рассмотрен в следующих подразделах этой работы.3.1 Основные компоненты языка EntishЯзык описания, включенный в Entish, базируется на использовании расширенного языка разметки, то есть языка xml. Подробное описание всех схем и структур, используемых в языке описания, приводиться не будет, так как их всех можно посмотреть в литературе, которая указана в списке источников. В этом разделе будет схематично указана иерархия основных понятий и структур данных.Имена описываются типом Concept, который состоит из короткого и длинного имени. Длинное имя является URI указателем и может быть опущено в случае, когда имя ссылается на константу.Описание типов, отношений и функций на макро уровне состоит из двух частей: определяющего выражения (definiens) и определяемого выражения (definiendum), то есть из того, что определяется, и из того, как определяется.Формулы определяются как простые (состоят из одной операции) или как составные (состоят из нескольких формул, связанных отношением «и», «или» или «влечет»).Состояние определяется адресом, целями, намерениями, обязательствами и знаниями владельца. Цели и обязательства описываются как два списка формул, каждый из которых формирует предусловия и постусловия соответственно. Намерения в свою очередь состоят из трех списков формул: плана (используется для поддержки процесса конструирования потока работ и выражения текущих намерений), потока работ (описывает сконструированный, конструируемый или выполняемый поток работ), реализованный список формул (хранит уже реализованные формулы).Тип «сообщение» описывает конструкцию, которая содержит заголовок (используется для служебной информации, такой как адрес отправителя и получателя, версия протокола, тип сообщения, идентификатор сессии) и тело (содержит формулу или список формул).3.2 Распределение компонент соответствии с требованиями EntishНа рисунке 1 схематично представлен один из вариантов размещения компонент системы. Далее более подробно будут описаны назначения и функции каждого компонента.Dictionary – это служба, которая служит словарем терминов, то есть она регистрирует, хранит и предоставляет данные о зарегистрированных функциях и типах.InfoService – это репозиторий данных, в котором хранятся сведения о всех зарегистрированных службах. Например, некоторая служба реализует абстрактную функцию F, которая уже описана в словаре терминов. Тогда эта служба должна дать знать потенциальным клиентом о ее готовности осуществить ту или иную операции (в данном случае это функция F). Поэтому служба высылает запрос в репозиторий, в котором она говорит, что может выполнить функцию F и указывает, какие предусловия для этого должны быть выполнены. Репозиторий регистрирует эти данные и высылает службе уведомление, в котором указывает срок действия регистрации.Рисунок 1 – Распределение компонент системы в соответствии с требованиями EntishTask manager в данной схеме предоставляет клиентам возможность через браузер (в данном случае через Internet Explorer) взаимодействовать с системой и запускает работу агента по выполнению той или иной абстрактной функции (а именно, по поиску необходимых служб, их компоновке и запуску).Web service – это один из многих поставщиков услуг, который должен зарегистрировать в репозитории и при необходимости добавить записи в словарь терминов.3.3 Предложения по расширению протокола и языка EntishВ ходе анализа протокола и языка Entish был выявлен ряд недостатков:Чрезмерное резервирование ресурсов.Огромные объемы данных, циркулирующие по сети.Нерешенная проблема выбора из множества поставщиков однотипных услуг.^ 4 Взаимодействие BPEL и Entish В ходе анализа протокола и языка Entish были выявлены существенные его недостатки, которые не могут быть полностью устранены в рамках принципов, заложенных в основу данного языка:Чрезмерное резервирование ресурсов.Огромные объемы данных, циркулирующие по сети.Одним из путей решения этой задачи является организация взаимодействия 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 описании службы тип порта может быть указан следующий образомТогда описание типа ссылки на «партнера» бизнес-процесса в языке BPEL может принять следующий вид:Далее в BPEL описании бизнес-процесса объявляется ссылка на вышеуказанного партнера:partnerLinkType="tns:FileLinkType"ь yRole="application" />Для вызова метода ассоциированной службы необходимо использовать элемент invoke: portType="tns:FileServiceSoap" operation="tns:writeLine" другие параметры--> />При исполнении такого бизнес-процесса исполняющая среда спускается по цепочке до типа порта, определяет по его значению ассоциированные с ним элементы binding и service WSDL описания службы-партнера. Например: name="FileServiceSoap" type="tns:FileServiceSoap"> "http://schemas.xmlsoap.org/soap/http" /> "http://tempuri.org/writeLine" /> binding="tns:FileServiceSoap"> "http://localhost:4085/Site/FileService.asmx" />Далее из элемента service исполняющая среда извлекает адрес службы-партнера, формирует параметры необходимого метода и, собственно, вызывает саму службу.В ходе анализа возможных реализаций привязки бизнес-процесса к абстрактной функции было выявлено, что единственным реализуемым и приемлемым вариантом является подмена в элементе service URL адреса службы-партнера на адрес ядра программной системы автоматической компоновки приложений служебно-ориентированной архитектуры. А именно: создается ядро системы в виде сайта, реализуется и регистрируется HTTP обработчик для некоторого нестандартного расширения, например, «func». Пусть http://localhost:4085/Kernel.Web/ адрес ядра системы. Тогда элемент service WSDL-описания службы-партнера примет вид: binding="tns:FileServiceSoap"> "http://localhost:4085/Kernel.Web/Repository.func" />В таком случае при выполнении бизнес-процесса веб запрос придет прямиком в ранее зарегистрированный 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, – это:Создать класс, реализующий интерфейс IHttpHandler.Сконфигурировать web-приложение, которое является ядром системы автоматической компоновки.Сконфигурировать соответствующий виртуальный каталог 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, которая в упрощенной форме принимает следующий вид: Преобразования BPEL описания бизнес-процесса в поток работ в терминах WF.Компиляция потока работ.Исполнение скомпилированной сборки^ Обсуждение результатов Рассмотрим сценарий, который описывает процесс ипотечного кредитования.Рисунок 5 – Общая схема предоставления ипотечного кредитаКлиент, обращаясь за кредитом, обычно звонит в несколько банков, чтобы найти наилучшие условия. Каждый банк в свою очередь запрашивает у клиента личную информацию для оценки рисков и определяет индивидуальные условия кредитования. Как только клиент получает от банков все предложения, он может выбрать из них наиболее подходящее. Так как количество задействованных банков не существенно сказывается на организации всего потока работ, то с целью упрощения примера будет использоваться только один банк. Также добавим в приведенную выше схему посредника – брокера, который будет предоставлять клиенту услуги по сбору и обработке информации.Далее подробно рассмотрим последовательность потока работ:Пользователь, которому требуется кредит, через интернет заходит на предоставленный ему web-сайт.Пользователь вводит свои личные данные (имя, адрес, SSN и т.д.) и жмет кнопку “Submit” («Подтвердить»).Создается запрос на кредит и записывается в базу данных. Также генерируется идентификатор запроса и возвращается пользователю. Текущий статус запроса пользователя – SUBMITTED (подтвержденный).Идентификатор запроса передается как параметр web-службе брокера для обработки. Брокер выставляет запросу статус “BROKER PROCESSING” («Обрабатывается брокером»).Web-служба брокера выполняет BPEL-процесс брокера, который обращается в кредитное бюро, предоставляя идентификатор запроса.В кредитном бюро по идентификатору запроса определяют SSN-код пользователя и получают по нему кредитную историю.Кредитная история передается BPEL-процессу кредитного бюро, который анализирует ее и вызывает web-службу брокера, передавая ей идентификатор запроса и отчет по истории пользователя.Процесс брокера далее вызывает web-службу банка и передает ей необходимые идентификаторы. Web-служба выполняет BPEL-процесс банка, который принимает решение о целесообразности выделения кредита и предает брокеру идентификатор, указывающий на заключительный отчет.BPEL-процесс броке