«применение ит при автоматизированной компоновке приложений служебно-ориентированной архитктуры» - реферат

БЕЛОРУССКИЙ ГОСУДАРСТВЕННЫЙ УНИВЕРСИТЕТ

Выпускная работа по
«Основам информационных технологий»

Магистрант

кафедры технологий программирования

Литвин Александр

Руководители:

доцент Войтешенко Иосиф Станиславович,

ст. преподаватель Кожич П.П.

Минск – 2010 г.

ОГЛАВЛЕНИЕ

ОГЛАВЛЕНИЕ.. 1

СПИСОК ОБОЗНАЧЕНИЙ.. 3

РЕФЕРАТ НА ТЕМУ «ПРИМЕНЕНИЕ ИТ ПРИ АВТОМАТИЗИРОВАННОЙ КОМПОНОВКЕ ПРИЛОЖЕНИЙ СЛУЖЕБНО-ОРИЕНТИРОВАННОЙ АРХИТКТУРЫ». 4

Введение. 4

Обзор литературы.. 5

Методика исследований. 5

Основные результаты.. 6

1 Служебно-ориентированное приложение и проблема компоновки. 6

2 Языки описания. 7

3 Задача компоновки. 9

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

Обсуждение результатов. 18

Заключение. 20

Список литературы к реферату. 21

ПРЕДМЕТНЫЙ УКАЗАТЕЛЬ К РЕФЕРАТУ.. 22

ИНТЕРНЕТ РЕСУРСЫ В ПРЕДМЕТНОЙ ОБЛАСТИ ИССЛЕДОВАНИЯ.. 23

ДЕЙСТВУЮЩИЙ ЛИЧНЫЙ САЙТ В WWW... 24

ГРАФ НАУЧНЫХ ИНТЕРЕСОВ.. 25

ТЕСТОВЫЕ ВОПРОСЫ ПО ОСНОВАМ ИНФОРМАЦИОННЫХ ТЕХНОЛОГИЙ.. 26

ПРЕЗЕНТАЦИЯ МАГИСТЕРСКОЙ ДИССЕРТАЦИИ.. 27

СПИСОК ЛИТЕРАТУРЫ К ВЫПУСКНОЙ РАБОТЕ.. 28

ПРИЛОЖЕНИЕ А.. 29

ПРИЛОЖЕНИЕ В. КОД ПРОГРАММЫ... 33

СПИСОК ОБОЗНАЧЕНИЙ

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]. Основным недостатком метода, основанного на данном языке, является необходимость разработки и реализации пользовательских протоколов, а также общая низкая производительность всей системы из-за обширного применения резервирования ресурсов.

Методика исследовани й

Данную работу можно разбить на две основные части: теоретическую и практическую.

Целью теоретической части работы являлись:

1. Исследование эволюции методологий разработки программного обеспечения.

2. Анализ языков описания бизнес-процессов WSCI и BPEL.

3. Проработка проблемы компоновки служебно-ориентированных приложений при помощи языка описания документооборота и автоматической компоновки приложений Entish.

4. Выявление возможных путей расширение протокола и языка Entish.

5. Проработка принципов взаимодействия языков описания высокого уровня и языков автоматического документооборота и компоновки на примере BPEL и Entish.

Целью практической части работы являлись:

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

2. Реализация программной системы на языке 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 Описательный язык WSCI

WSCI - это описательный язык интерфейсов на основе 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 – Распределение компонент системы в соответствии с требованиями 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 описанием, а также абстрактные функции и их исполнителей.

Приведенная общая описательная модель реализации автоматической компоновки приложений служебно-ориентированной архитектуры обладает огромным преимуществом перед моделью, предложенной 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.

3. Сайт с документацией по средствам работы с исполнительным языком описания бизнес процессов (Business Process Execution Language) [Электронный ресурс]. - Режим доступа: - http://www.ibm.com/developerworks/library/specification/ws-bpel.

4. Сайт-энциклопедия [Электронный ресурс]. - Режим доступа: http://www.wikipedia.org.

5. Stanistaw Ambroszkiewicz. EnTish: an Approach to Service Description and Composition: Berlin, 2003.

6. Mike Marin, Robert Shapiro. Process Definition Interface – XML Process Definition Language: The Workflow Management Coalition, 2003.

7. Tony Andrews, Yaron Goland, Francisco Curbera. Business Process Execution Language for Web Services Version 1.1: BEA Systems, International Business Machines Corporation, Microsoft Corporation, SAP AG, Siebel Systems, 2003.

8. Сайт с документацией MSDN [Электронный ресурс]. – Режим доступа: http://msdn.microsoft.com.

ПРЕДМЕТНЫЙ УКАЗАТЕЛЬ К РЕФЕРАТУ

A

ASP.NET, 16

B

Business Process Execution Language, 8

E

Entish, 10

H

HTTP, 13

S

SOAP, 13

U

Universal Description, Discovery, and Integration, 9

W

Web services flow language, 9

Windows Workflow Foundation, 18

WSCI, 9

С

Служебно-ориентированная архитектура, 4

Служебно-ориентированное приложение, 6

ИНТЕРНЕТ РЕСУРСЫ В ПРЕДМЕТНОЙ ОБЛАСТИ ИССЛЕДОВАНИЯ

http://docs.oasis-open.org/wsbpel/2.0/wsbpel-specification-draft.html

Сайт организации по продвижению стандартов для структурированной информации (Organization for the Advancement of Structured Information Standards) .

http://www.bpelsource.com/bpel_info/spec.html

Сайт с документацией по исполнительному языку описания бизнес процессов (Business Process Execution Language) .

http://www.ibm.com/developerworks/library/specification/ws-bpel

Сайт с документацией по средствам работы с исполнительным языком описания бизнес процессов (Business Process Execution Language).

http://msdn.microsoft.com

Сайт с документацией MSDN.

ДЕЙСТВУЮЩИЙ ЛИЧНЫЙ САЙТ В WWW

http://cool-alexander.narod.ru/

ГРАФ НАУЧНЫХ ИНТЕРЕСОВ

магистранта Литвина А.В. факультета прикладной математики и информатики

Специальность - прикладная математика

ТЕСТОВЫЕ ВОПРОСЫ ПО ОСНОВАМ ИНФОРМАЦИОННЫХ ТЕХНОЛОГИЙ

Вопрос 1

Вопрос 2

ПРЕЗЕНТАЦИЯ МАГИСТЕРСКОЙ ДИССЕРТАЦИИ

http://cool-alexander.narod.ru/Litvin.ppt

СПИСОК ЛИТЕРАТУРЫ К ВЫПУСКНОЙ РАБОТЕ

1. Сайт высшей аттестационной комиссии Республики Беларусь [Электронный ресурс] / Нац ВАК Беларуси © 2004-2007. – Режим доступа: http://www.vak.org.by. – Дата доступа: 20.11.2009.

2. О внесении изменений и дополнений в Инструкцию по оформлению диссертации и автореферата: Постановление Гос. высш. аттестац. ком. Респ. Беларусь, 22 февраля 2006г., № 2 // ВАК Белоруси [Электронный ресурс].

3. Stanistaw Ambroszkiewicz. EnTish: an Approach to Service Description and Composition: Berlin, 2003

ПРИЛОЖЕНИ Е А

ПРИЛОЖЕНИЕ В . КОД ПРОГРАММЫ

using System;

using System.Collections.Generic;

using System.IO;

using System.Linq;

using System.Net;

using System.Text;

using System.Web;

using System.Xml;

using Kernel.Kernel;

namespace Kernel.HTTP

{

/// <summary>

/// Kernel invoker HTTP handler.

/// </summary>

public class KernelInvokerHTTPHandler: IHttpHandler

{

#region Interface implementation

public void ProcessRequest(HttpContext context)

{

try

{

//Search executor.

var wrUrl = KernelSearcher.

Instance.

GetServiceUrl(context.Request);

//Create request object.

var wr = context.Request.Copy(wrUrl);

//Invoke request object and get response object.

var response = wr.GetResponse();

//Update current context response object.

context.Response.Update(response);

}

catch(NotSupportedException nsE)

{

//AL: TODO: Log and handle.

}

catch(Exception e)

{

//AL: TODO: Log and handle.

}

}

public bool IsReusable

{

get { return true; }

}

#endregion

}