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

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

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

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

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

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

Минск – 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. Тестирование полученной системы, выявление недостатков, определение возможных путей их решения.

Примечание: здесь под методологией разработки программного обеспечения понимается система теоретических и практических принципов и способов организации и построения программных систем.

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

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

Служебно-ориентированное приложение представляет собой результат агрегирования служб в одно логически завершенное, связанное приложение – по аналогии с тем, как объектно-ориентированное приложение образуется в результате агрегирования объектов.

Само приложение может представить агрегат как новую службу, по аналогии с тем, как объекты строятся из меньших объектов.

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

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

Поскольку служебно-ориентированные инфраструктуры предоставляют готовый вторичный код для объединения служб, чем выше степень детализации службы, чем интенсивнее приложение использует эту инфраструктуру и тем меньше вторичного кода приходится писать разработчикам. Если довести эту концепцию до крайности, каждый класс и примитив должен быть оформлен в виде службы — тем самым обеспечивается максимальная степень использования готовых средств взаимодействия и предотвращается необходимость «ручного» создания вторичного кода. Однако на практике существует предел детализации, определяемый в основном производительностью используемой инфраструктуры (такой, как WCF). Думаю, с течением времени и по мере развития служебно-ориентированных технологий границы служб будут непрерывно сужаться, и службы будут становиться все более детализированными, до тех пор, пока самые примитивные структурные блоки не будут оформлены в виде служб.

Если считать повышение повторной используемости кода и ряд других вышеперечисленных аспектов единственными преимуществами служебно-ориентированного программирования, то это означает сильно ошибаться. Большой ошибкой будет не замечать наличие возможности перехода на новые принципы создания программного обеспечения: речь идет о полной замене "кустарного" кодирования программ на "промышленную" сборку приложений из "стандартных комплектующих", как в автомобильной или других "традиционных" отраслях промышленности.

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

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

Языки описания

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

Задача компоновки

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