Содержание к диссертации
Введение
1 Технологии веб-сервисов 13
1.1 Концепции архитектуры, ориентированной на веб-сервисы 13
1.2 Технологии веб-сервисов
1.2.1 Архитектура веб-сервисов 15
1.2.2 Стандарты технологии веб-сервисов
1.3 Семантические веб-сервисы 27
1.4 Языки описания композиций 29
1.5 Веб-сервисы и вопросы безопасности 30
1.6 Постановка задачи диссертации 32
1.7 Выводы 34
2 Моделирование сервис-ориентированных приложений 35
2.1 Сети Петри 37
2.1.1 Модель веб-сервиса 39
2.1.2 Модель операции 40
2.1.3 Модель композитного веб-сервиса 42
2.2 Раскрашенные сети Петри 45
2.2.1 Моделирование композиций веб-сервисов 47
2.2.2 Взаимодействие без непосредственного связывания с веб-сервисом 50
2.2.3 Методика моделирования сервис-ориентированных приложений 52
2.3 Моделирование взаимодействия мобильного приложения с веб-сервисом 54
2.3.1 Задача построения модели 54
2.3.2 Модель мобильного приложения как сеть Петри 57
2.3.3 Модель мобильного приложения как многоцветная сеть Петри 59
2.4 Выводы 66
3 Средства и методы разработки веб-сервисов 67
3.1 Основные платформы для разработки веб-сервисов 67
3.1.1 Платформа J2EE 67
3.1.2 Платформа .NET 68
3.1.3 Сравнительный анализ .NET и J2EE 70
3.2 Разработка веб-сервисов по методу «снизу-вверх» 71
3.2.1 Создание приложения, реализующего функциональность веб-сервиса 71
3.2.2 Развертывание и тестирование веб-сервиса на сервере 74
3.2.3 Генерация WSDL описания веб-сервиса 74
3.2.4 Формирование семантического описания сервиса 75
3.2.5 Создание клиентского приложения для доступа к веб-сервису 75
3.2.6 Преимущества и недостатки подхода «снизу вверх» 77 3.3 Разработка веб-сервисов по методу «сверху-вниз» 78
3.3.1 Состав WSDL документа 79
3.3.2 Генерация программных компонентов по WSDL описанию 82
3.3.3 Преимущества и недостатки подхода «сверху вниз» 82
3.4 Выводы 83
4 Разработка сервис-ориентированных приложений в технологии .NET и Java 84
4.1 Разработка системы прогнозирования инкассации банкоматов 84
4.1.1 Функциональные характеристики модулей 85
4.1.2 Архитектура системы 88
4.1.3 Определение WSDL описаний веб-сервисов 89
4.1.4 Реализация веб-сервисов на технологии Java 98
4.1.5 Вызов Java веб-сервисов из .NET клиента 102
4.2 Разработка системы оперативного управления заданиями 104
4.2.1 Общее описание разработанной системы 105
4.2.2 Проектирование приложения 105
4.2.3 Программная реализация 108
4.2.4 Обеспечение безопасности разработанной системы 110
4.2.5 Отладка взаимодействия программных компонентов разработанной системы. 112
4.3 Выводы 114
Заключение 115
Список использованных источников
- Стандарты технологии веб-сервисов
- Моделирование взаимодействия мобильного приложения с веб-сервисом
- Развертывание и тестирование веб-сервиса на сервере
- Разработка системы оперативного управления заданиями
Введение к работе
Актуальность темы. В последнее время становится популярной покомпонентная сборка приложений на базе сервис-ориентированной архитектуры (SOA, Service-Oriented Architecture). Концепция SOA основана на том, что бизнес-приложение состоит из большого количества компонентов. Каждый такой компонент представляет собой сервис, являющийся модулем системы SOA. Использование сервис-ориентированного подхода позволяет крупному предприятию получить преимущества при дальнейшем развитии своей IT-инфраструктуры.
Для создания сервис-ориентированных приложений, в частности, перспективно использование технологии веб-сервисов. Технология веб- сервисов позволяет приложениям взаимодействовать друг с другом независимо от платформы, на которой они развернуты, а также от языка программирования, на котором они написаны. У веб-сервиса существует программный интерфейс, который описывает набор операций (веб-методов), удаленно вызываемых посредством стандартизованных XML сообщений. В отличие от традиционного веб-приложения, веб-сервис не обслуживает конечных пользователей, так как у него нет пользовательского интерфейса. Его главной задачей является предоставление услуг другим приложениям, таким как веб-приложения, мобильные или консольные приложения.
Ориентация на закрытые стандарты и форматы при разработке информационных систем создает проблемы при интеграции приложений. Веб- сервисы получили широкое распространение, так как они основаны на открытых протоколах обмена и передачи данных и стандартах, поддерживаемых на различных программных платформах. Это создает основу как для использования разработанных сервисов в рамках IT-инфраструктуры предприятия, так и для автоматизации бизнес процессов, в реализации которых участвуют несколько предприятий.
Построение информационных систем на базе веб-сервисов привело к понятию архитектуры, ориентированной на веб-сервисы (Web Services Architecture - WSA), разновидности сервис-ориентированной архитектуры. В диссертации исследуются вопросы разработки и моделирования веб-сервисов, используемых в рамках WSA, поэтому в дальнейшем под словом «сервис» понимается именно веб-сервис.
Сервис-ориентированные приложения - это распределенные приложения, функциональные компоненты которых - веб сервисы - выполняются на разных серверах и образуют «оркестр», управляемый клиентом. В силу этого они работают в значительной степени в условиях неопределенности. В связи с этим, в последнее время появилось большое количество исследований, связанных с построением моделей сервис-ориентированных приложений, выполненных с использованием сетей Петри.
Следует отметить работы К. Бохана и М. Худолея, посвященные построению моделей корпоративных приложений на базе иерархических сетей Петри, работы A. Martens, R. Hamadi, B. Benatallah, P. Xiong, Y. Fan, M. Zhou, связанные с моделями композитных сервисов, и множество других.
В настоящее время, в связи с быстрым распространением мобильных устройств весьма актуальны мобильные приложения, выполняющие самую разнообразную работу. В основном мобильные приложения предназначены для взаимодействия с корпоративной базой данных. Организовать такое взаимодействие легче всего, используя веб-сервис и сеть интернет для транспорта сообщений. При разработке мобильных приложений, как показывает практика, весьма актуально предварительное моделирование, позволяющее оценить как архитектурные решения, так и особенности функционирования мобильного приложения в реальных условиях.
Целью диссертационной работы является повышение эффективности разработки веб-сервисов и систем, ориентированных на применение веб- сервисов, на основе исследования существующих методов и инструментальных программных средств разработки и моделирования, используемых при композиции веб-сервисов и создании мобильных приложений.
Объектами исследований диссертационной работы являются веб- сервисы, как простые, так и композитные, а также приложения, построенные на их основе.
Предметами исследований диссертационной работы являются методы и средства разработки и композиции веб-сервисов.
Методами исследований диссертационной работы являются методы теории сетей Петри.
Научная новизна диссертации заключается в следующем: Разработаны модели веб-сервисов и их композиций на базе простых и
раскрашенных сетей Петри
Разработаны модели статического и динамического обращения к сервису.
Предложен и продемонстрирован метод разработки веб-сервисов «сверху-вниз», в процессе которого сначала разрабатывается синтаксическое описание сервиса, а затем выполняется кодирование его методов.
Практическая значимость диссертации
Разработанные методы и модели могут быть использованы при разрабоке веб-сервисов, как простых, так и композитных;
Проведенный анализ методов разработки веб-сервисов и модели композиции, созданные на базе сетей Петри, могут эффективно использоваться в учебном процессе;
Основные положения, выносимые на защиту
Предлагаемый подход к моделированию веб-сервисов и мобильных приложений, построенных с их использованием.
Модели веб-сервисов и мобильных приложений, построенных с их использованием.
Апробация работы. Основные результаты диссертации докладывались и обсуждались на:
ХК международном научно-техническом семинаре «Современные технологии в задачах управления, автоматизации и обработки информации». Алушта, 2010
XIV международной телекоммуникационной конференции студентов и молодых ученых «Молодежь и наука». Научная сессия НИЯУ МИФИ- 2011
VIII Курчатовской молодежной научной школе, Москва, 2011 г
ХX международном научно-техническом семинаре «Современные технологии в задачах управления, автоматизации и обработки информации». Алушта, 2011
Внедрение результатов исследований
Работа по теме диссертации велась в сотрудничестве с сервисным центром компании БПЦ (). Методы и модели, представленные в диссертации, использованы при разработке:
-
-
Системы моделирования процессов инкассации банкоматов, выполненной в виде композиции 4 веб-сервисов и использованной в качестве прототипа при разработке промышленного варианта;
-
Системы, состоящей из веб-сервиса, работающего с офисной базой данных, и взаимодействующего с ним мобильного приложения, позволяющего планировать, оперативно отслеживать выполнение и изменять задания сотрудников, выполняемых вне офиса. Система внедрена в промышленную эксплуатацию и получен акт об использовании результатов диссертации.
Публикации
По теме диссертации опубликовано 7 печатных работ в период с 2010 по 2012 г, в том числе 3 в российских периодических изданиях, рекомендованных ВАК, тезисы 4 докладов включены в сборники трудов научно-технических конференций. Основные положения диссертационной работы отражены в опубликованных соискателем результатах. Структура и объем диссертации
Диссертация состоит из введения, четырех глав, заключения и списка литературы и приложений. Общий объем основного текста, без учета приложений — 120 страниц, с учетом приложений — 150. Диссертация содержит 62 рисунка, 4 таблицы и 34 листинга программного кода. Список литературы включает 63 источника.
Стандарты технологии веб-сервисов
Построение информационных систем с использованием сервисов привело к понятию архитектуры, ориентированной на веб-сервисы (Web Services Architecture - WSA) [4], разновидности сервис-ориентированной архитектуры (SOA, Service-Oriented Architecture). В диссертации исследуются вопросы разработки и моделирования веб-сервисов, используемых в рамках WSA, поэтому в дальнейшем под словом «сервис» понимается именно веб-сервис.
Первичным структурным элементом приложений WSA является сервис, который может рассматриваться и как основной ее компонент. Другим фундаментальным компонентом сервис-ориентированной архитектуры и WSA, как ее разновидности, является корпоративная сервисная шина (Enterprise Service Bus - ESB). ESB позволяет потребителям и производителям сервисов взаимодействовать друг с другом без установления прямой взаимозависимости. Она является посредником, объединяющим все корпоративные сервисы и приложения, реализующим функции преобразования и передачи данных, управления и мониторинга.
С точки зрения реализации, WSA представляет собой модель программирования, совместимую со стандартами, инструментами и технологиями веб-сервисов.
Если SOA не привязана к какой-то определённой технологии и может быть реализована с использованием широкого спектра технологий, включая RPC, DCOM, CORBA или веб-сервисы, то WSA четко ориентирована на использование веб-сервисов, как основных программных компонентов.
Таким образом, WSA характеризуется использованием независимых сервисов с чётко определёнными интерфейсами, которые для выполнения своих задач могут быть вызваны неким стандартным способом, при условии, что сервисы заранее ничего не знают о приложении, которое их вызовет, а приложение не знает, каким образом сервисы выполняют свою задачу.
WSA также может рассматриваться как стиль архитектуры информационных систем, который позволяет создавать приложения, построенные путём комбинации слабосвязанных и взаимодействующих веб-сервисов. Эти сервисы взаимодействуют на основе какого-либо строго определённого платформо-независимого и языково-независимого интерфейса (например, WSDL). Определение интерфейса скрывает языково-зависимую реализацию сервиса. К примеру, сервисы, написанные на С#, работающие на платформах .NET и сервисы на Java, работающие на платформах Java ЕЕ, могут быть с одинаковым успехом вызваны общим составным приложением. Приложения, работающие на одних платформах, могут вызывать сервисы, работающие на других платформах, что облегчает повторное использование компонентов.
Языки высокого уровня, такие как BPEL [5], или спецификации, такие как WS-CDL [6] и WS-Coordination [7], расширяют концепцию сервиса, предоставляя метод оркестровки для объединения мелких сервисов в более обширные бизнес-сервисы, которые, в свою очередь, могут быть включены в состав технологических процессов и бизнес-процессов, реализованных в виде составных приложений или порталов. WSA имеет следующие характерные особенности: Архитектура является распределенной. Функциональные модули (веб-сервисы) могут быть распределены по множеству вычислительных систем и способны к взаимодействию с использованием локальных или глобальных сетей. Интерфейс функциональных модулей (веб-сервисов) таков, что их использование не зависит от технологии или платформы, в рамках которой они реализованы. Возможен поиск и подключение нужных функциональных модулей. Архитектура базируется на общепринятых отраслевых стандартах. 1.2 Технологии веб-сервисов
Веб-сервис - это программный модуль, идентифицируемый с помощью URI (Unified Resource Identifier), внешние интерфейсы и связи которого определены и описаны с помощью XML. Другие программные системы должны иметь возможность находить описания сервисов. Эти программные системы могут взаимодействовать с веб-сервисом в стиле, определенном в его описании, используя XML-сообщения, передаваемые по некоторому интернет протоколу. Отсюда видно, что технология веб-сервисов базируется на технологии XML, являющейся открытым стандартом. Таким образом, веб-сервисы позволяет приложениям взаимодействовать друг с другом независимо от платформы, на которой они развернуты, а также от языка программирования, на котором они написаны.
Понятие архитектуры веб-сервисов, сложилось в ходе развития инфраструктуры, обеспечивающей разработку, поиск и применение веб-сервисов. Следует отличать понятие архитектуры веб-сервисов от понятия, связываемого с аббревиатурой WSA, хотя они и дополняют друг друга. Архитектура веб-сервисов представляет аспекты разработки, поиска, применения собственно сервисов, в то время как WSA акцентирует внимание на архитектуре систем, основным компонентом которых являются веб-сервисы.
Моделирование взаимодействия мобильного приложения с веб-сервисом
Объектом моделирования в данной работе являются веб-сервисы и приложения, выполненные на их основе. Как показывает анализ литературы понятие «веб-сервис» трактуется достаточно широко. В диссертационном исследовании веб-сервис трактуется как программный компонент, доступный по URL, имеющий на входе SOAP-сообщение и возвращающий SOAP-сообщение на выходе. Таким образом исключаются сервисы, доступные по протоколу XML-RPC [38] и, так называемые, RESTful-сервисы [39] и подразумевается исключительно вызов сервиса из программного кода. Кроме выходного SOAP-сообщения следует иметь в виду возможные эффекты от обращения к веб-сервису, связанные с воздействием на предметную область, в которой работает сервис. Обычно эффект проявляется в изменении состояния базы данных (например, изменение состояния счета).
Кроме того, моделируется только синхронное взаимодействие с веб-сервисом: программа-клиент посылает сервису сообщение и ждет от него ответа. Асинхронное взаимодействие с веб-сервисом, при котором клиент связывается с сервисом, оставляет ему свой адрес (URL) и просит присылать сообщения, связанные с определенными событиями, не рассматривается.
Когда говорят о взаимодействии веб-сервисов, то следует иметь в виду, что два самостоятельных сервиса не могут взаимодействовать непосредственно друг с другом - нужен кто то третий, кто организует это взаимодействие или, как говорят, выполняет «оркестровку» [40]. В качестве этого третьего обычно выступает некое бизнес-приложение. Это может быть веб-приложение, обычное десктопное или мобильное приложение отличительной чертой любого является наличие интерфейса с человеком. Современный подход к проектированию таких сервис-ориентированных приложений требует, чтобы приложение можно преобразовать в «композитный» веб-сервис. Это значит, что компонент, выполняющий интерфейс с человеком, должен быть отделен от компонента, выполняющего обработку информации.
Таким образом, моделирование сервис-ориентированных приложений и композитных веб-сервисов практически идентично и различается только моделью интерфейса, которая автономна.
Позиции сети размечены или маркированы, причем маркировка изменяется в результате срабатывания переходов. Говорят, что в позициях размещаются фишки, способные перемещаться по сети. Связанная с позициями сети маркировка М представляет собой кортеж целых чисел mj,m2,...)mn , т{ 0, причем число /ю, - интерпретируется как количество фишек в ПОЗИЦИИ/?/. Функционирование сети связано с изменением маркировки, что интерпретируется как движение фишек из входных позиций перехода в его выходные позиции в результате «срабатывания» перехода. Оно недетерминировано, что легче всего объяснить на графической диаграмме сети. Переход tk считается активированным, если в каждой его входной позиции находится, по меньшей мере, по одной фишке: показывает конфликтную ситуацию: на позицию претендуют переходы t] и t2 , но только один из них должен сработать. Функционирование сети можно отслеживать по «тактам» перехода от маркировки к маркировке. Основное правило - каждый такт срабатывает только один переход. Хотя такты следуют один за другим их нельзя ассоциировать со временем — переходы осуществляются мгновенно.
Существует достаточно много расширений классической сети Петри. Одно из них связано с введением случайного интервала времени, в течении которого «срабатывает» переход и вероятности разрешения конфликта. Так для сети на рис.2.1 можно задать вероятность срабатывания переходов tj и t2\ вер(//) = 0,2 и вер(/2) = 0,8 при разрешении конфликта, вызванного наличием фишки в позиции р2. Такую сеть иногда называют сетью Петри-Маркова [41].
Именно сети Петри-Маркова целесообразно использовать при анализе сервис-ориентированных приложений и композитных сервисов. При этом можно получить не только решение следующих классических задач, связанных с анализом сетей Петри, но и получить вероятностную оценку результата:
Анализ достижимости. В сети Петри с начальной разметкой Мо требуется определить, достижима ли заданная разметка My и оценить вероятность этого события.
Анализ живучести переходов. Под живучестью перехода понимается возможность его срабатывания при начальной разметке Мо. Требуется оценить вероятность этого события.
Анализ безопасности сети. Безопасной называется сеть Петри, в которой не может появиться более одной метки в каждой из позиций. Требуется оценить безопасность сети и при необходимости изменить ее структуру.
Анализ композиций веб-сервисов с помощью сетей Петри достаточно популярен. Так в работе [42] предлагается алгебра композиции. Однако абстрактное алгебраическое манипулирование моделями вряд ли может привести к семантически осмысленной композиции. Более распространен подход к анализу моделей, полученных из спецификации бизнес-приложений на одном из специализированных языков, в частности WSBPEL. Так как при разработке спецификации бизнес-процесса проектировщик ориентируется на известные ему веб-сервисы или предполагает их найти или, в крайнем случае, разработать, то получаемая сеть Петри семантически осмыслена и интерпретируема, а ее анализ позволяет формально проверить целостность разработки.
Развертывание и тестирование веб-сервиса на сервере
Построение модели способствует, прежде всего, обеспечению взаимопонимания между разработчиком и заказчиком приложения. Между специалистами разрабатывающими и заказывающими приложение практически всегда существует понятийный барьер, который должен быть преодолен в процессе формирования задания на разработку как той, так и другой стороной. Для автора диссертации, как для иностранца, при разработке конкретных приложений, представленных в диссертации, существовал еще и языковый барьер. Именно при обсуждении построенных автором нескольких вариантов моделей удалось окончательно сформулировать задание на разработку, одинаково понимаемое и разработчиком и заказчиком.
Определение сети Петри, данное в начале этого раздела в виде множества объектов и отношений между ними, не связано с ее графическим представлением. Работа с сетью в таком виде предполагает применение аналитических, в частности, алгебраических методов и не дает, по мнению автора, желаемого эффекта. Разумеется, это представление дает полезные результаты, например, в виде алгоритма построения дерева достижимости (рис. 2.8), однако для реальной работы очень важно графическое представление сети. Именно оно, в сочетании с возможностью приведения фишек в движение, в наибольшей степени способствует конечному результату - построению конечного приложения при минимизации затрат на многочисленные переделки.
Реальные приложения достаточно объемны, поэтому их моделирование требует средств композиции и декомпозиции. Важным свойством сетей Петри является возможность их исследования по частям. Исходная сеть разбивается на фрагменты, каждый из которых исследуется независимо, а затем проводится анализ свойств всей сети, в которой каждый фрагмент замещается отдельным переходом или позицией. Как показывает практика исследуемые фрагменты не должны быть слишком объемны. Желательно, чтобы каждый фрагмент представлялся сетью не выходящей за пределы одного экрана.
Использованное в диссертационном исследовании средство CPN Tools дает возможность строить иерархические раскрашенные сети [44], как
композицию нескольких, в общем случае, также иерархических сетей, организованных в «страницы». В результате получается иерархия страниц, листьевые вершины которой содержат только стандартные позиции и переходы. Поведение иерархической сети эквивалентно поведению неиерархической сети, получающейся при замещении всех модулей страницами, которые их представляют. При этом каждый модуль вместе со своими дугами удаляется со страницы, а на его место помещается представляющая его подсеть.
Моделирование приложения в виде иерархической раскрашенной сети связано с переходами с одной страницы на другую, более детально раскрывающей определенный фрагмент, что не способствует общему пониманию. Оно хорошо работает, когда модель отлажена и запускается на определенное количество тактов или на время, чтобы получить определенные статистические характеристики. На этапе построения сети целесообразнее строить автономные фрагменты и исследовать их автономно. Этому способствует и вся идеология построения веб-сервисов, в которых WSDL-операции полностью инкапсулируют внутреннюю реализацию.
В процессе работы над диссертацией разработано мобильное приложение, поддерживающее оперативное управление выполнением заявок на ремонт банкоматов и предназначенное для координации действий сотрудников, выполняющих задания вне офиса. Предполагается, что сотрудники получают план работы на текущий день, не заезжая в офис, и сообщают в офис о начале работы по конкретному заданию, результатах работы и ее окончании. Приложение предполагает интенсивный обмен сообщениями между офисом и сотрудниками, позволяющий оценить состояние исполнения каждого задания и выдать корректирующие распоряжения. Оперативное управление выполнением заявок на ремонт банкоматов в качестве действующих лиц имеет офисного менеджера и мобильный персонал. Менеджер работает непосредственно с офисной базой данных, в которой отражаются текущие заявки на ремонт оборудования. Он составляет план работы мобильного персонала на текущий рабочий день и корректирует его по мере необходимости, отправляя SMS-сообщения. Мобильный персонал, непосредственно выполняющий ремонтные работы на местах, оснащен устройствами типа КПК, на которых развернуто мобильное приложение. В функции мобильного приложения входит получение детальной информации по каждому запланированному заданию и отправка сообщений по состоянию его выполнения в базу офиса. С этой целью на сервере офиса развернут веб-сервис, непосредственно взаимодействующий с базой данных и мобильными приложениями по каналу GPRS.
Разработка системы оперативного управления заданиями
При проектировании приложения должны использоваться соответствующие методы, в частности, при создании объектно-ориентированных приложений разрабатываться хотя бы некоторые UML-диаграммы. Этот аспект разработки в диссертации не рассматривается. В данном разделе кратко описывается методика создания веб-сервиса по методу «снизу-вверх» на двух основных платформах Microsoft .NET и J2EE с пользованием средств разработки Visual Studio 2008 и NetBeans IDE 6.8. 3.2.1.1 На платформе Microsoft .NET
Средство Microsoft Visual Studio позволяет реализовать веб-сервисы на двух объектно-ориентированных языках программирования, С# и Visual Basic .NET в рамках проекта ASP .NET Web Service.
Создав проект, необходимо добавить к нему код, реализующий желаемую функциональность веб-сервиса. Все практические разработки в рамках технологии .NET, выполненные в процессе подготовки диссертации, использовали язык С#, поэтому далее будем ориентироваться только на этот язык. Исходный код будущего веб-сервиса будет храниться в файле, с расширением .asmx.es, который называется файлом отделенного кода (code-behind file).
Для каждого создаваемого веб-сервиса Visual Studio .NET генерирует по умолчанию следующие файлы; Assemblylnfo.cs — хранит общие сведения о сборках проекта. Сборка — это функциональная единица кода, подлежащего совместному многократному использованию с участием общеязыковой исполняющей среды; Servicel.asmx и Servicel.asmx.cs — составляют интерфейс веб-сервиса. Servicel.asmx начинаются директивой @WebService. Эта директива должна содержать атрибут Class, задающий класс, из которого состоит веб-сервис. Файл класса Servicel.asmx.cs — скрытый файл, зависимый от Web Service.asmx; содержит класс отделенного кода веб-сервиса; Web.config — содержит сведения о конфигурации веб-проекта, например описание режима отладки и способа аутентификации, а также определяет нестандартные сообщения об ошибках для данного проекта. В Web.config можно хранить сведения о конфигурации веб-сервисов.
На платформе J2EE существует свободная интегрированная среда разработки приложений NetBeans IDE, которая поддерживает разработку веб-сервисов на языке программирования Java. В средстве NetBeans IDE v6.8 веб-сервисы могут быть развернуты в веб-контейнере или в контейнере EJB. Это зависит от конкретной реализации, но в практических приложениях диссертации, выполненных с использованием Java, использовалось развертывание веб-сервисов в веб-контейнере. Рассмотрим шаги, которые необходимо пройти при разработке веб-сервисов из класса Java. Для создания проекта:
После развертывания проекта, чтобы создать веб-сервис из класса Java необходимо пройти следующие шаги:
1. В диалоговом окне "New Web Service" (рис. 3.1) присвоить веб-сервису имя и ввести название пакета, например "org.myservice", установив кнопку-переключатель "Create Web Service from Scratch".
2. После нажатия кнопки "Finish" в окне "Projects" отображается структура проекта, а в окне редактора - исходный код веб-сервиса, который создается NetBeans IDE.
Диалоговое окно для создания осб-ссршіса в NetBeans IDE IDE NetBeans предлагает диалоговое окно для добавления веб-методов в веб-сервис. Это диалоговое окно можно открыть либо в визуальном конструкторе, либо в контекстном меню веб-сервиса. Диалоговое окно позволяет определить названия и типы параметров и веб-методов. Данная возможность упрощает процесс кодирования при реализации веб-сервисов.
На шаге развертывания необходимо предпринять действия, которые позволят осуществить вызов веб-сервиса на стороне сервера. Необходимые для развертывания действия зависят от реализации веб-сервиса, платформы, на которой он работает, протокола, по которому его вызывают, а также конкретных продуктов, обеспечивающих транспорт и среду работы веб-сервиса [48].
В Visual Studio .NET для развертывания веб-сервиса необходимо выбрать команду "View in Browser". Сервер ASP .NET Development Server автоматически запускается и клиент для тестирования веб-сервиса открывается в браузере.
Для развертывания веб-сервиса в NetBeans необходимо выбрать команду "Deploy". Запускается сервер приложений, выполняется сборка и развертывание приложения на сервере приложений. После развертывания веб-сервиса на сервере можно использовать среду IDE для открытия клиента тестирования, если у сервера имеется такой клиент. Серверы GlassFish и WebLogic предоставляют тестовые клиенты.
Для того чтобы другие разработчики могли использовать веб-сервис, им нужно знать, какие методы сервис предоставляет, какие протоколы поддерживает, сигнатуры методов и адрес веб-сервиса (URL). Вся эта и другая информация описывается на языке WSDL. После развертывания веб-сервиса на сервере WSDL описание, как правило, автоматически генерируется средствами разработки.
Для получения описания веб-сервиса, созданного в технологии .NET, достаточно ввести в адресной строке браузера URL веб-сервиса и добавить строку запроса wsdl. В среде NetBeans, WSDL описание можно получить аналогично. Однако в NetBeans существует другой способ для генерации WSDL описания: в контекстном меню надо выбрать опцию "Generate and Copy WSDL". При этом описание WSDL генерируется в каталог \build\generated-sources\jax-ws\resources.
Семантическое описание веб-сервиса - желательное, но не обязательное описание сервиса. На момент написания диссертации эта функциональность еще не включена в рассматриваемые среды разработки. Суть семантического описания сервиса состоит в том, что с операциями WSDL, с их входами и выходами связывается глобальный информационный ресурс в виде онтологии предметной области. Связывание может быть реализовано в синтаксисе OWL-S - языке, рекомендованном W3C для семантического описания веб-сервисов. В этом языке операциям WSDL соответствуют атомарные процессы, а типам входов и выходов - классы (термины) онтологии.
В настоящее время семантическое описание сервиса в основном используется для поиска сервиса с требуемой функциональностью. Включение семантического описания сервиса в процесс выполнения, то есть обращение к сервису на семантическом уровне и получение результатов на этом уровне связано с переходом от XML-представления к RDF-представлению входных и выходных данных. Так как моделью RDF-представления является граф общего вида, а XML-представления -иерархический граф, то при переходе от RDF к XML могут возникнуть сложности, которые хорошо описаны в [49].
Похожие диссертации на Моделирование и разработка сервис-ориентированных приложений
-
