«применение ит при автоматизированной компоновке приложений служебно-ориентированной архитктуры» (стр. 1 из 5)

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

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