Обзор технологии Web-сервисов. Исследование и разработка методов построения

02.08.2019

5.1.1 Основы Web-сервисов

Web-сервисы - это новая перспективная архитектура, которая обеспечивает новый уровень распределенности. Вместо разработки или приобретения компонентов и их встраивания в ИС предлагается покупать время их работы и формировать программную систему, которая осуществляет вызовы методов из компонентов, которые принадлежат и поддерживаются независимыми провайдерами. Благодаря Web-сервисам функции любой программы в сети могут стать доступными через Интернет. Самый простой пример Web-сервиса - система Passport на Hotmail, которая позволяет создать аутентификацию пользователей на собственном сайте.

В основе Web-сервисов лежат следующие универсальные технологии:

TCP/IP – универсальный протокол, понимаемый всеми сетевыми устройствами, от мэйнфреймов до мобильных телефонов и PDA;

HTML – универсальный язык разметки, применяемый для отображения информации устройствами пользователей;

XML (Extensible Markup Language)– универсальный язык для работы с любыми типами данных.

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

Веб-сервисы - это XML-приложения, осуществляющие связывание данных с программами, объектами, базами данных либо с деловыми операциями целиком. Между веб-сервисом и программой осуществляется обмен XML-документами, оформленными в виде сообщений. Стандарты веб-сервисов определяют формат таких сообщений, интерфейс, которому передается сообщение, правила привязки содержания сообщения к реализующему сервис приложению и обратно, а также механизмы публикации и поиска интерфейсов.

Веб-сервисы могут использоваться во многих приложениях. Независимо от того, откуда запускаются веб-сервисы, с настольных компьютеров клиентов или с переносных, они могут использоваться для обращения к таким интернет-приложениям, как система предварительных заказов или контроля выполнения заказов. Веб-сервисы пригодны для В2В-интеграции (business-to-business), замыкая приложения, выполняемые различными организациями, в один производственный процесс. Веб-сервисы также могут решать более широкую проблему интеграции приложений предприятия (Enterprise Application Integration, EAI), осуществляя связь нескольких приложений одного предприятия с несколькими другими приложениями. Во всех перечисленных случаях технологии веб-сервисов являются "связующим звеном", объединяющим различные части программного обеспечения.

Как видно из рис. 5.1, веб-сервисы представляют собой оболочку, обеспечивающую стандартный способ взаимодействия с прикладными программными средами, такими как системы управления базами данных (СУБД), .NET, J2EE (Java2 Platform, Enterprise Edition), CORBA (Common Object Request Broker Architecture), посредники пакетов планирования ресурсов предприятия (Enterprise Resource Planning, ERP), брокеров интеграции и пр.

Рис.5.1. Веб-сервисы взаимодействуют с прикладными системами

Интерфейсы веб-сервисов получают из сетевой среды стандартные XML-сообщения, преобразуют XML-данные в формат, "понимаемый" конкретной прикладной программной системой, и отправляют ответное сообщение (последнее - не обязательно). Программная реализация веб-сервисов (базовое программное обеспечение, нижний уровень) может быть создана на любом языке программирования с использованием любой операционной системы и любого связующего программного обеспечения (middleware).

Простой пример: поиск информации

В настоящее время большинство сервисов вызываются по Сети посредством ввода данных в HTML-формы и отправки этих данных сервису путем добавления их в строку унифицированного указателя информационного ресурса (Uniform Resource Locator, URL):

http://www.google.com/search?q=Skate+boots&btnG=Google+Search

Этот пример иллюстрирует простоту веб-взаимодействия (например, поиска, покупки акций или запроса маршрута движения), где параметры и ключевые слова внедряются непосредственно в URL. В данном случае представлен простой запрос поиска skate boots (ботинки с коньками) в строке обращения к поисковой машине Google. Ключевое слово search (искать) представляет сервис, к которому будет осуществлено обращение, а параметр Skate+boots является строкой поиска, которая была введена в HTML-форме на странице веб-сайта Google. Сервис поиска Google передаст этот запрос к различным поисковым машинам, которые вернут список URL для страниц, на которых имеется соответствие параметру поиска Skate+boots. Данный малоэффективный способ поиска в Сети полностью основан на установлении соответствия указанной текстовой строки и индексированных HTML-страниц.

XML - лучший способ отправки данных. XML предоставляет значительные преимущества при передаче данных через Интернет. Теперь предыдущий запрос можно представить в виде XML-документа:

xmlns:s="www.xmlbus.com/SearchService">

Skate

boots

size 7.5

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

Данный пример представлен в форме SOAP-сообщения (Simple Object Access Protocol) - стандартной формы обмена XML-сообщениями - одной из технологий, лежащих в основе веб-сервисов. В SOAP-сообщении имя запрашиваемого сервиса и входные параметры представлены в виде отдельных XML-элементов. Рассматриваемый пример также иллюстрирует использование пространства имен XML (xmlns:), еще одного важного элемента веб-сервисов. Благодаря тому, что XML-документы поддерживают разные типы данных, сложные структуры и объединение схем, современные технологии веб-сервисов обеспечивают значительное преимущество над существующими возможностями обращения к программным приложениям посредством HTML и URL.

Следующее поколение Сети

Следующее поколение Сети будет основано на программно-ориентированных взаимодействиях. Веб-сервисы предполагают использовать созданные для взаимодействия людей глобальные сети совершенно в иных целях.

Использование веб-сервисов очень выгодно с коммерческой точки зрения. За счет повсеместного распространения веб-сервисов Интернет становится более эффективным, особенно при осуществлении коммерческих сделок. Сочетая прямой доступ к программным приложениям и коммерческим документам, веб-сервисы следующего поколения Сети обеспечат полностью автоматическое взаимодействие, что позволит обращаться непосредственно к данным программ, игнорируя знакомые веб-страницы. Более того, основные компоненты веб-сервисов, скорее всего, будут предоставляться и публиковаться множеством различных компаний, специализирующихся на отдельных функциональных элементах (проверка полномочий, координация сделок, ведение счетов). Это обеспечит непосредственное взаимодействие "приложение-приложение" - принцип, лежащий в основе веб-сервисов и определяющий их суть и реализацию.

ОБЩЕЕ ВЗАИМОПОНИМАНИЕ

Технология веб-сервисов существует на очень высоком уровне абстракции, позволяя поддерживать множество одновременных определений, которые иногда бывают противоречивы. На простейшем уровне веб-сервисы могут восприниматься как интернет-ориентированные текстовые брокеры интеграции. Любые данные могут преобразовываться в ASCII-текст и обратно, и этот подход в течение долгого времени был общим знаменателем для систем графического вывода и систем управления базами данных. Ориентированные на использование текста системы также лежат в основе успешного развития Интернета, на котором базируется дополнительная абстракция веб-сервисов. Любой компьютер или операционная система может поддерживать HTML, браузеры и веб-сервисы; и при получении по сети файлов им совершенно безразлично и даже неизвестно, с каким типом прикладной системы они взаимодействуют.

Преимущества и недостатки веб-сервисов.

К преимуществам веб-сервисов можно отнести следующее:

Веб-сервисы позволяют компании интегрировать свои бизнес-процессы с бизнес-процессами бизнес-партнеров и клиентов при меньшей стоимости, чем с использованием других интеграционных технологий. Стоимость подобных решений на основе веб-сервисов доступна даже для SMB (Small and Medium Business), что откроет для таких компаний новые перспективы развития;

Поскольку веб-сервисы организуются в публичные реестры (UDDI-реестры, ebXML-реестры или иные), доступные заинтересованным лицам по всему миру, порог выхода компаний на новые рынки снижается, возможности же для наращивания клиентской базы напротив возрастают;

Веб-сервисы обеспечивают преемственность в отношении уже имеющихся в компании ИС, т. е. можно сказать, что веб-сервисы надстраиваются над существующими ИС, но не вместо них. Таким образом, обеспечивается сохранность уже сделанных инвестиций в IT-инфраструктуру и не идет увеличения требуемых, поскольку нет необходимости в радикальных изменениях;

Построение новых корпоративных решений с применением веб-сервисов реализуется быстрее и совокупно дешевле, поскольку основное внимание сосредотачивается на создании бизнес-логики решения, программирование самих веб-сервисов лишь по необходимости “обрамляет” этот процесс, не требуя больших трудозатрат за счет эффективного применения повторно используемого кода и адаптированных средств разработки (IDE и SDK).

К недостаткам (минусам) веб-сервисов можно отнести:

Стандарты интеграции бизнес-процессов, вопросы управления транзакциями и выработка единых бизнес- и IT-политик взаимодействующих посредством веб-сервисов компаний находятся пока на стадии разработки (мы отметим следующие начинания: Web Services Flow Language (WSFL), Business Process Execution Language 4 Web Services (BPEL4WS (аббревиатура “BPEL” произносится кратко как “бипль”)) корпорации IBM, XLANG корпорации Microsoft и спецификации WS-Coordination и WS-Transaction – результат сотрудничества IBM, Microsoft и BEA). Очевидно, без их четкой формализации и опубликования построение ИС на основе веб-сервисов может идти лишь с переменным успехом;

Динамическое использование информации бизнес-реестров веб-сервисов, вызов веб-сервисов, требует решения вопросов доверительности отношений между различными бизнес-реестрами. Кроме того, есть трудности в совместном использовании бизнес-реестров различных форматов (например, задача поиска определенного веб-сервиса в UDDI-реестре и ebXML-реестре требует различных подходов в силу различия XML-документов, описывающих один и тот же веб-сервис в каждом из этих реестров. Хотя, надо отметить, что есть попытки решить эту проблему созданием единого браузера реестров. В качестве примера - графическая утилита Registry Browser корпорации Sun Microsystems, реализующая набор интерфейсов JAXR (Java API for XML Registries);

Добавление к функциям сервера приложений функциональности провайдера веб-сервисов в силу новизны технологий может представлять определенную трудность;

Вопросы безопасности функционирования ИС на основе веб-сервисов пока не урегулированы до конца. Спецификация WS-Security – продукт деятельности корпораций IBM и Microsoft – в настоящее время достаточно молода, не “устоялась” и частично все еще дорабатывается. Однако, в силу общности положений спецификации WS-Security, уже готовится к выпуску следующий слой спецификаций, посвященных вопросам безопасности: Web Services Policy Assertions, Web Services Policy Attachments, Web Services Policy Framework, Web Services Trust, Web Services Secure Conversation, Web Services Federation.

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

Определение веб-сервиса

Назовем сервисом (service) ресурс, реализующий бизнес-функцию, обладающий следующими свойствами:

является повторно используемым;

определяется одним или несколькими явными технологически-независимыми интерфейсами;

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

Веб-сервисом (см. документ W3C “Web-services architecture requirements”) называется программная система, идентифицируемая строкой URI, чьи интерфейсы и привязки определены и описаны посредством XML. Описание этой программной системы может быть найдено другими программными системами, которые могут взаимодействовать с ней согласно этому описанию посредством сообщений, основанных на XML, и передаваемых с помощью Интернет-протоколов.

Лекция 10. Технологии веб-сервисов

План

8.1. Основы веб-сервисов

8.2. Веб 2.0 и веб-сервисы

8.4. Взаимодействие с веб-сервисами

8.6. Компоновка веб-сервисов

8.7. Веб-сервисы в ASP.Net

8.1. Основы веб-сервисов

Веб-сервисом (Веб-службой) (см. документ W3C “Web-services architecture requirements”) называется программная система, идентифицируемая строкой URI, чьи интерфейсы и привязки определены и описаны на языке XML. Описание этой программной системы может быть найдено другими программными системами, которые могут взаимодействовать с ней согласно этому описанию посредством сообщений , основанных на XML, и передаваемых с помощью Интернет-протоколов .

Концепция веб-сервисов возникла в конце 90-х годов XX века. Однако, к настоящему моменту эта концепция успела устояться и архитектура, которую она предлагает, стала отраслевым стандартом в сфере IT.

Стандартизацией архитектуры веб-сервисов занимаются рабочие группы комитета W3C.

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

Механизм обмена сообщениями определяется в описании сервисов (Web Services Description), которое представляет собой спецификацию интерфейса сервиса и охватывает форматы сообщений, типы данных, транспортные протоколы, используемые при обмене между агентами заказчика и поставщика услуг. Кроме того, описание сервиса содержит указание на одну или несколько точек в сети (endpoint), откуда доступен поставщик.

Благодаря веб-сервисам функции любой программы в сети могут стать доступными через Интернет.

В основе веб-сервисов лежат следующие универсальные технологии:

HTML – универсальный язык разметки, применяемый для отображения информации устройствами пользователей;

XML (Extensible Markup Language)– универсальный язык для работы с любыми типами данных.

Таким образом, веб-сервисы решают исходную задачу – задачу интеграции приложений различной природы и построения распределенных ИС.

В этом заключается основное принципиальное отличие веб-сервисов от предшественников - технологий взаимодействия распределенных приложений, позволявших реализовать обмен данными между приложениями (Remote Procedure Calls (RPC), Distributed COM (DCOM), Remote Method Invocation (RMI) и Common Object Request Broker Architecture (CORBA)). Однако каждая из них была довольно сложна в реализации, не обладала необходимой универсальностью (т. е. все же зависела от выбора, например, одной и той же операционной системы для всех участников обмена) и, что особенно плохо, эти технологии с большим трудом стыковались между собой.

Преимущества и недостатки веб-сервисов

Преимущества

веб-сервисы обеспечивают взаимодействие программных систем независимо от платформы;
веб-сервисы основаны на открытых стандартах и протоколах. Благодаря использованию XML достигается простота разработки и отладки веб-сервисов;
Использование интернет-протокола HTTP обеспечивает взаимодействие программных систем через межсетевой экран.

Недостатки

Меньшая производительность и больший размер сетевого трафика по сравнению с технологиями RMI, CORBA, DCOM за счет использования текстовых XML-сообщений.

Платформы

Веб сервисы выполняются на серверах приложений. Сегодня практически все веб-серверы приложений поддерживают эту технологию:

Axis и Tomcat (оба являются проектами Apache).
Mono development platform от Novell
Microsoft .NET серверы от Microsoft
Java Web Services Development Pack (JWSDP) от Sun Microsystems (основан на Jakarta Tomcat)
Zope является объектно ориентированным web application server написанным на Python
Application Server от IBM (основан на Apache и платформе J2EE)
Cordys WS-AppServer
infoRouter Document Management software Web Services API
JOnAS (является частью ObjectWeb Open Source initiative)
Web Application Server от SAP (Web AS является ключевой частью стека SAP NetWeaver)
Pramati Application Server от Pramati Technologies Limited
OpenEdge Platform от Progress Software
Oracle Application Server от Oracle Corporation
Zend Framework - от Zend Technologies
Pythomnic - платформа для написания распределенных сетевых сервисов.
Google App Engine - платформа для высокомасштабируемых приложений, использующих инфраструктуру компании Google .

Веб-сервисы подобны DLL-библиотекам, но имеют следующие отличительные особенности:

выполняются на стороне сервера;
предоставляют набор методов, доступных внешним клиентам;
исполняют веб-методы и возвращают результаты клиентам;
веб-сервисы и их клиенты могут быть написаны на разных языках и/или разных платформах.

8.2. Веб 2.0 и веб-сервисы

Технологии веб-сервисов являются основополагающими для Веб 2.0.

Термин “Веб 2.0” был предложен в 2005 году известным американским издателем Тимом О’Рейли для обозначения совокупности прогрессивных тенденций в развитии веб-технологий.

Сегодня под этим термином понимается не столько совокупность каких-то конкретных технологий, сколько философия представления информации в веб-ориентированной среде и построение информационных отношений.

Феномен Веб 2.0 можно разделить в пределах нескольких общих тенденций в развитии веб-среды.

Веб как платформа . Эта концепция является базовой в философии веб 2.0.

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

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

Тут уже речь идёт о другом важном принципе Веб 2.0 - “мэшап” (Mash-up – “смешивание”). Этот принцип означает, что путём интегрирования программных возможностей нескольких независимых друг от друга веб-сервисов возможно создать новый уникальный веб-проект.

8.3. Стек технологий веб-сервисов

Веб-сервисы требуют использования нескольких смежных XML-технологий, образующих стек технологий (рис. 8.1).

Язык XML - фундамент, на котором строятся веб-сервисы. Он предоставляет язык определения данных и порядок их обработки. XML представляет семейство связанных спецификаций, публикуемых и поддерживаемых интернет-консорциумом (W3C) и другими организациями.
SOAP (Simple Object Access Protocol), разработанный консорциумом W3C, определяет формат запросов к веб-сервисам. Сообщения между веб-сервисом и его пользователем пакуются в так называемые SOAP-конверты (SOAP envelopes, иногда их ещё называют XML-конвертами). Само сообщение может содержать либо запрос на осуществление какого-либо действия, либо ответ - результат выполнения этого действия.
WSDL (Web Services Description Language) - технология, основанная на XML, определяющая интерфейсы веб-сервисов, типы данных и сообщений, а также модели взаимодействия и протоколы связывания. Перед развертыванием сервиса разработчик составляет его описание на языке WSDL, указывает адрес веб-сервиса, поддерживаемые протоколы, перечень допустимых операций, форматы запросов и ответов.
Технология UDDI (Universal Description, Discovery and Integration) - реестр веб-сервисов и механизм поиска. Он используется для хранения и упорядочения информации о веб-сервисах, а также для нахождения указателей на интерфейсы веб-сервисов.

Рис. 8.1. Стек технологий веб-сервисов

Эти технологии обеспечивают реализацию базовых свойств веб-сервиса, описанных в его определении.

На их основе разрабатываются новые языки взаимодействия и сервисо-ориентированные архитектуры.

8.4 Взаимодействие с веб-сервисами

Интерфейсы веб-сервисов получают из сетевой среды стандартные XML-сообщения, преобразуют XML-данные в формат, "понимаемый" конкретной прикладной программной системой, и отправляют ответное сообщение (последнее - не обязательно). Программная реализация веб-сервисов (базовое программное обеспечение, нижний уровень) может быть создана на любом языке программирования с использованием любой операционной системы и любого промежуточного программного обеспечения (middleware).

Взаимодействие программных систем с веб-сервисами представлено на рис. 8.2.

Рис. 8.2. Взаимодействие c веб-сервисами

Различают следующие три основных архитектурных компонента сервисно-ориентированной архитектуры:

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

Каждый компонент может играть либо лишь одну роль (быть, например, только пользователем сервиса) либо одновременно сразу несколько ролей (например, быть провайдером одних сервисов и пользователем других).

В ходе взаимодействия друг с другом компоненты сервисо-ориентированной архитектуры выполняют следующие основные операции:

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

Рассматривая взаимодействие компонентов сервисо-ориентированной архитектуры необходимо отметить наличие (и различие) следующих двух артефактов:

описание сервиса : определяет формат запроса и отклика при взаимодействии пользователя сервиса и провайдера сервиса, а также требуемое качество сервиса;
сервис : собственно сервис, который может быть вызван и использован пользователем сервиса в соответствии с опубликованным интерфейсом сервиса.

8.5. Сервисно-ориентированная архитектура приложений

8.5.1. Основы сервисо-ориентированной архитектуры

Архитектуру, в рамках которой все функции приложения являются независимыми сервисами с четко определенными интерфейсами, которые можно вызывать в нужном порядке для формирования бизнес-процессов, называют сервисо-ориентированной (SOA).

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

8.5.2. Технологии реализации сервисо-ориентированной архитектуры

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

Рис. 8.3. Расширенный стек технологий веб-сервисов

Расширенный стек технологий веб-сервисов принципиально разбивается на следующие две составляющие:

технологии, обеспечивающие функциональность веб-сервисов (Functions);
технологии, обеспечивающие качество сервиса веб-сервисов (Quality of service).

Эти составляющие в свою очередь образуются несколькими слоями (layers):

технологии, обеспечивающие функциональность веб-сервисов:

транспортный слой (transport layer);
коммуникационный слой (service communication layer);
слой описаний сервисов (service description layer);
сервисный слой (service layer);
слой бизнес-процессов (business process layer);
слой реестров сервисов (service registry layer).

технологии, обеспечивающие качество веб-сервисов:

слой политик (policy layer);
слой безопасности (security layer);
слой транзакций (transaction layer);
слой управления (management layer).

В целях понимания назначения слоев, дадим краткое описание каждого из них.

№ п/п	Наименование слоя	Назначение слоя	Технологии, реализующие слой
Функциональность (Functions)
1	Транспортный слой (Transport layer)	Описывает средства обмена данными между веб-сервисами	Стандартные: HTTP, JMS (для Java-приложений), SMTP Новые: WS-ReliableMessaging, BEEP
2	Коммуникационный слой (Service communication layer)	Описывает средства формализации механизмов использования транспортных протоколов веб-сервисами.	Стандартные: SOAP Новые:REST
3	Слой описаний сервисов (Service description layer)	Описывает средства формализации интерфейсов веб-сервисов с целью обеспечения их функционирования независимо от программно-аппаратной платформы реализации или языка программирования.	Стандартные: XML, WSDL Нарождающиеся: ebXML
4	Сервисный слой (Service layer)	Описывает программное обеспечение, вызываемое с помощью WSDL-описаний интерфейсов веб-сервисов. В частности, это сами веб-сервисы
5	Слой бизнес-процессов (Business process layer)	Описывает возможности организации веб-сервисов для реализации бизнес-процессов и потоков работ. При этом определяются правила, задающие последовательность взаимодействия веб-сервисов с целью удовлетворения бизнес-требованиям	Новые: BPEL4WS, WCF, WF
6	Слой реестров сервисов (Service registry layer)	Описывает возможности организации веб-сервисов в иерархические библиотеки, позволяющие публикацию, поиск и вызов веб-сервисов по их WSDL-описаниям интерфейсов	Стандартные: UDDI Нарождающиеся: WS-Inspection
Качество сервиса (Quality of service)
7	Слой политик (Policy layer)	Описывает правила и условия, согласно которым веб-сервисы могут быть использованы. Поскольку данные правила и условия относятся как к функциональному аспекту веб-сервисов, так и к аспекту обеспечения качества сервиса на рис. 8.3, данный слой является общим для обоих аспектов	Стандартные: в настоящее время нет Новые: WS-Policy, WS-PolicyAssertions и WS-PolicyAttachment
8	Слой безопасности (Security layer)	Описывает возможности обеспечения безопасности веб-сервисов и безопасности их функционирования (авторизация, аутентификация и разделение доступа)	Стандартные: WS-Security Новые: WS-SecureConversation, WS-Federation, WS-Authorization, WS-Trust и WS-Privacy
9	Слой транзакций (Transaction layer)	Описывает свойство транзакционности распределенных систем на основе веб-сервисов для обеспечения надежности их функционирования	Стандартные: в настоящее время нет Новые: WS-Transaction и WS-Coordination
10	Слой управления (Management layer)	Описывает возможности управления веб-сервисами и характеристиками их функционирования	Новые:

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

8.6. Компоновка веб-сервисов

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

Функциональные возможности каждого веб-сервиса определяются его входами, выходами, предварительными условиями и действиями, которые обозначают как IOPEs (inputs, outputs, preconditions, and effects). IOPE сервиса содержится в его WSDL-описании.

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

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

Термины оркестровка и хореография описывают два аспекта разработки бизнес-процессов на основе объединения веб-сервисов. На рис. 8.5 в общем виде показана взаимосвязь этих аспектов, которые в какой-то мере дополняют друг друга.

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

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

Стандарты хореографии и оркестровки опираются на 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 Microsystems.

Язык BPEL4WS предназначен для реализации оркестровки сервисов.

Язык WSCI отражает концепцию хореографии сервисов.

WSCI (Web Service Choreography Interface)- это описательный язык интерфейсов на основе XML, который работает в связке с WSDL. Его цель - позволить корпорациям использовать возможности веб-сервисов для создания процессов, отражающих меняющиеся требования бизнеса. Язык позволяет компаниям представлять свои прикладные программы и ресурсы в виде веб-сервисов, чтобы другие фирмы могли оперативно находить их и применять в своих бизнес-процессах.

WSCI с 2002 года развивается рабочей группой консорциума W3C (организована рабочая группа Web Services Choreography Working Group);
для развития BPEL4WS в 2003 году в консорциуме OASIS был создан технический комитет - OASIS Web Services Business Process Execution Language TC (WS-BPEL TC).

BPEL определяет конструкции, необходимые для составления набора сервисов для бизнес-процессов, связанных с совместной деятельностью и сделками.

BPEL определяет поведение бизнес-процессов, базирующихся на dt,-сервисах.

BPEL реализует функциональность экспорта и импорта, используя исключительно интерфейсы веб-сервисов.

BPEL вписывается в архитектуру основных веб-сервисов, построенную поверх UDDI, WSDL, XML и XML Schema.

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

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

Flow coordination. (Координация потоков) Координация потоков включает параллельный поток выполнения, образцы соединений и динамические потоки. В реальных приложениях бизнес-потоки могли бы включать образцы сложных взаимодействий, и с синхронными, и с асинхронными сервисами. Координация потока включает интерфейс с WSDL, действия потока, переменные XML и отвечает за компенсацию. BPEL использует WSDL для обращения к обмениваемым сообщениям, вызванным операциям и типам портов. Действия с потоком используют общие переменные XML, так что компенсационные обработчики (compensation handlers) должны сохранять снимки данных, которые могут быть использованы обработчиком. Компенсационные обработчики могут отменить шаги, которые были уже завершены.

BPEL includes basic and structured activities. (В BPEL включены основные и структурированные действия). Основные действия состоят из индивидуальных шагов для взаимодействия с сервисом, манипулирования обмениваемыми данными или обработки исключительных состояний, с которыми сталкиваются в течение выполнения. Структурированные действия определяют последовательность выполнения и описывают создание процесса, транслируя выполняемые ими действия в структуры; в состав этих структур включены поток данных, шаблоны управления, обработка внешних событий, обработка ошибок и координация сообщений.

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

8.7. Веб-сервисы в ASP.Net

Технология веб-сервисов в ASP.Net расширяет возможности создания веб-приложений. В настоящее время в ASP.Net поддерживается два способа разработки и вызова веб-сервисов:

Через протокол HTTP (однонаправленный синхронный вызов) - XML-веб-сервисы;

Через MCF (Microsoft Communication Fundation) – ассинхронный двунаправленный обмен сообщениями – MCF- веб-сервисы.

Создание веб-сервиса (веб-службы) в Visual Studio похоже на создание веб-страницы. Также можно использовать средство веб-разработки Microsoft Visual Web Developer для ссылок и использовать веб-службы, находящиеся в решении Visual Web Developer, на локальном компьютере, а также в локальном или внешнем каталоге UDDI.

Мы рассмотрим выполнение следующих задач:

создание простого XML-веб-сервиса в Visual Web Developer;
создание отдельного веб-сайта, использующего веб-сервис.

Реализовывать эту задачу будем в виде двух отдельных решений.

8.7.1. Создание веб-сервиса в ASP .Net. Пошаговое руководство

http://msdn.microsoft.com/ru-ru/library/8wbhsy70.aspx

Откройте Visual Web Developer.
В меню Файл выберите пункт Создать веб-сайт .

File – New- WebSite

Откроется диалоговое окно Новый веб-сайт

В разделе выберите Веб-сервис ASP.NET .

ASP.Net Web Service

Нажмите кнопку Обзор и выберите путь и имя сервиса.
В списке Язык выберите С#
Нажмите кнопку ОК .

Будет создан файл Service.asmx со ссылкой на код сервиса

@ WebService Language="C#" CodeBehind="~/App_Code/Service.cs" Class="Service" %>

И файл с кодом сервиса: Service.cs

using System;

using System.Linq;

using System.Web;

using System.Web.Services;

Public Service () {

// InitializeComponent();

Public string HelloWorld() {

Return "Hello World";

Атрибут определяет пространство имен для веб-сервиса

Атрибут касается способа определения WSDL

Добавление метода, доступного через веб-сервис делается написанием соответствующего кода и указания квалификатора доступа к методу как public .

Метод должен иметь атрибут

2. Компиляция и тестирование веб-сервиса

Сохраняем сервис и запускаем браузер

Следующие операции поддерживаются. Формальное определение см. в Описание службы .

По ссылке Описание службы находится описание сервиса на WSDL

По ссылке – HelloWorld описание вызова сервиса. Структура SOAP-запроса и ответа и как они будут выглядеть при использовании HTTP-методов GET и POST.

Для тестирования вызова метода нужно нажать кнопку Запуск.

Http://tempuri.org/">Hello World

Пример

Сервис, который содержит два метода.

Метод Example1() возвращает строку "Привет от ASP.Net!";

Метод Summa возвращает сумму двух целых чисел, которые передаются через параметры.

using System;

using System.Web;

using System.Web.Services;

using System.Web.Services.Protocols;

public class Service: System.Web.Services.WebService

Public Service () {

//Uncomment the following line if using designed components

//InitializeComponent();

Public string Example1() {

Return "Привет от ASP.Net!";

Public int Summa(int a, int b)

В VS есть встроенный Web DeveloperServer , который должен быть запущен при вызове сервиса. Созданный веб-сервис размещается на этом сервере.

Создадим еще один веб-сервис для перевода температуры (пример из MSDN)

Предстоит создать веб-сервис, который преобразует температуру по шкале Фаренгейта в температуру по шкале Цельсия и наоборот.

Создание веб-сервиса

В обозревателе решений (Solution Explorer ) щелкните правой кнопкой мыши имя созданного веб-сервиса

(http://localhost/TemperatureWebService), а затем выберите команду Добавить новый элемент .

В разделе Установленные шаблоны Visual Studio выберите (Web Service) и в поле Имя введите Convert.
Убедитесь, что установлен флажок Размещать код в отдельном файле и нажмите кнопку Добавить .

Visual Web Developer создаст новый веб-сервис, состоящий из двух файлов. Файл Convert.asmx является файлом, который может быть вызван для вызова методов веб-сервиса, и он указывает на код для веб-сервиса. Сам код находится в файле класса (CONVERT.cs) в папке App_Code. Файл кода содержит шаблон для веб-сервиса. Файл кода включает некоторый код для метода веб-службы.

В данном примере будет создано два метода в одной веб-службе. Первый метод преобразует температуру по шкале Фаренгейта в температуру по шкале Цельсия, а второй метод преобразует температуру по шкале Цельсия в температуру по шкале Фаренгейта.

Чтобы создать методы преобразования, выполните следующие действия:

Добавьте следующий код в класс сразу после метода HelloWorld:

Обратите внимание, что имена функций предваряются атрибутом ( >) как часть объявления функции.

После ввода функций сохраните файл.

Полный код приведен ниже.

using System.Collections;

using System.Linq;

using System.Web;

using System.Web.Services;

using System.Web.Services.Protocols;

using System.Xml.Linq;

/// Summary description for Convert

// To allow this Web Service to be called from script, using ASP.NET AJAX, uncomment the following line.

public class Convert: System.Web.Services.WebService {

public Convert () {

//Uncomment the following line if using designed components

//InitializeComponent();

Public string HelloWorld() {

Return "Hello World";

Public double FahrenheitToCelsius(double Fahrenheit)

Return ((Fahrenheit - 32) * 5) / 9;

Public double CelsiusToFahrenheit(double Celsius)

Return ((Celsius * 9) / 5) + 32;

Теперь можно протестировать веб-службу в Visual Web Developer.

Чтобы протестировать веб-службу, выполните следующие действия:

В обозревателе решений выберите Convert.asmx и нажмите сочетание клавиш CTRL+F5.

Будет вызвана веб-служба и в обозревателе появится страница, отображающая методы, предоставляемые веб-службой.

Нажмите кнопку CelsiusToFahrenheit , которая вызывает этот метод.

Появится страница, которая запросит значения параметров для метода CelsiusToFahrenheit.

В поле Celsius введите 100 и нажмите кнопку Вызвать .

Новое окно отображает XML-данные, возвращаемые веб-службой при вызове метода CelsiusToFahrenheit. Значение 212 отображается в XML.

Закройте браузер, содержащий результаты метода.
В исходном обозревателе нажмите кнопку Назад , чтобы вернуться к списку методов.
Нажмите FahrenheitToCelsius и убедитесь, что метод возвращает ожидаемый результат.

Если ввести 212, метод FahrenheitToCelsius возвратит 100 .

Закройте браузер.

После окончания создания веб-службы, следующим шагом является ее использование.

8.7.2. Использование веб-сервиса в приложении

Теперь, когда веб-служба создана, предстоит создать веб-узел, в котором будет использоваться созданная веб-служба. Необходимо создать отдельный веб-сайт со страницей, из которой будут запускаться только что созданные методы веб-сервиса.

Для этого нужно создать приложение-клиент (потребитель сервиса). Создадим в качестве такого клиента ASP.Net страницу.

Например, создадим страницу с двумя кнопками, при нажатии на которые будут вызываться сервисы.

Вызов веб-сервиса из приложения-клиента выполняется через класс-посредник (proxy-класс).

1. Создайте веб-сайт:

В меню Файл выберите пункт Создать веб-сайт .
В разделе Установленные шаблоны Visual Studio выберите Веб-узел ASP.NET .
Введите имя TemperatureWeb.
В списке Язык выберите C#
Нажмите кнопку ОК .

Visual Web Developer создаст новый локальный веб-узел IIS и новую страницу с именем Default.aspx.

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

Для создания ссылки на веб-сервис, выполните следующие действия:

В меню Веб-сайт выберите команду Добавить веб-ссылку .

Откроется диалоговое окно Добавление веб-ссылки , как показано на следующем снимке экрана.

В списке URL-адреса введите следующий URL-адрес для веб-службы и нажмите кнопку Переход :

http://localhost/TemperatureWebService/Convert.asmx

Когда Visual Web Developer находит веб-службу, сведения о веб-службе отображаются в диалоговом окне Добавление веб-ссылки .

Примечание

Если не удается добавить ссылку на веб-службу, возможно, что прокси-сервер настроен неправильно. В Microsoft Internet Explorer, в меню Сервис выберите пункт Свойства обозревателя , выберите вкладку Подключения и затем нажмите кнопку Параметры LAN . Установите флажок Не использовать прокси-сервер для локальных адресов . Кроме того, задайте в поле для адреса прокси-сервера точное имя прокси-сервера, вместо разрешения Internet Explorer самостоятельно обнаруживать прокси-сервер. Для получения дополнительных сведений обратитесь к администратору сети.

Выберите одну из ссылок метода.

Откроется страница тестирования для метода.

Нажмите кнопку Добавить ссылку .

Visual Web Developer создает папку App_WebReferences и добавляет в нее папку для новой веб-ссылки. По умолчанию для веб-ссылок назначаются пространства имен, соответствующее имени их сервера (в данном случае localhost). Запишите имя для пространства имен веб-ссылки. Visual Web Developer добавляет в папку WSDL-файл, который ссылается на веб-службу. Он также добавляет вспомогательные файлы, такие как файлы обнаружения (файлы с расширениями DISCO и DISCOMAP), содержащие сведения о расположении веб-службы.

Примечание.

Должен быть запущен сервер Web Developer Server/

3. Вызовите сервис из из ASP страницы

Пример 1. Вычисление суммы чисел

1. Создайте форму с двумя текстовыми полями и кнопкой Сумма.

В обработчике кнопки добавьте вызов метода.

Подключите пространство имен localhost

using System;

using System.Data;

using System.Configuration;

using System.Web;

using System.Web.Security;

using System.Web.UI;

using System.Web.UI.WebControls;

using System.Web.UI.WebControls.WebParts;

using System.Web.UI.HtmlControls;

using localhost;

public partial class _Default: System.Web.UI.Page

Protected void Page_Load(object sender, EventArgs e)

Protected void Button1_Click(object sender, EventArgs e)

Service myService= new Service();

Label1.Text = myService.Example1();

Protected void Button2_Click(object sender, EventArgs e)

Int a, b,summa;

A = int.Parse(txt_a.Text);

B = int.Parse(txt_b.Text);

// summa = a + b;

Service myService1 = new Service ();

Summa = myService1.Summa(a,b);

Txt_summa.Text = summa.ToString();

Пример 2. Вызов методов перевода температуры

Создайте на странице форму со следующими полями:

Чтобы вызвать методы веб-службы, выполните следующие действия:

Откройте страницу Default.aspx и переключитесь в представление "Конструктор".
Из группы Стандартные в панели элементов перетащите следующие элементы управления на страницу и задайте их свойства, как показано в следующей таблице:

protected void ConvertButton_Click(object sender, EventArgs e)

Localhost.Convert wsConvert = new localhost.Convert();

Double temperature =

System.Convert.ToDouble(TemperatureTextbox.Text);

FahrenheitLabel.Text = "Fahrenheit To Celsius = " +

WsConvert.FahrenheitToCelsius(temperature).ToString();

CelsiusLabel.Text = "Celsius To Fahrenheit = " +

WsConvert.CelsiusToFahrenheit(temperature).ToString();

Нажмите клавиши CTRL+F5 для запуска страницы.
В текстовом поле введите значение, например 100, и нажмите кнопку Преобразовать .

На странице отображается результат преобразования значения температуры по шкале Фаренгейта и Цельсия.

Отладку веб-службы можно выполнить так же, как отладку веб-страниц.

Сначала необходимо настроить веб-узел, содержащий веб-службу, для включения отладки.

Чтобы включить отладку на веб-узле веб-службы, выполните следующие действия:

Средство администрирования веб-узла создаст файл Web.config для веб-узла и установит параметры конфигурации для включения отладки.

Закройте Средство администрирования веб-узла.

Теперь необходимо включить отладку для веб-узла, использующего веб-службу.

Чтобы включить отладку на веб-узле, выполните следующие действия:

Visual Web Developer откроет файл кода для страницы.

Поместите указатель в следующей строке:

Обнаружение web-сервисов

Каким образом другие разработчики узнают о существовании веб-сервиса?

Во-первых, с помощью DISCO (сокращение от слова discovery) - файлового механизма поиска локальных web-сервисов, то есть механизма получения списка доступных web-сервисов из DISCO-файлов, размещенных на web-серверах. Кроме того, DISCO-файлы содержат записи о расположении WSDL-контрактов имеющихся сервисов. DISCO-файл представляет собой XML-файл с записями.

Также возможно использовать VSDISCO-файлы, которые аналогичны DISCO-файлам, но их содержимое есть результат динамического поиска web-сервисов в указанных каталогах и всех вложенных подкаталогах. ASP .NET отображает расширение имени файла.vsdisco на HTTP-обработчик, который отыскивает в данном каталоге и его подкаталогах asmx и disco и возвращает динамически генерируемый DISCO-документ. По соображениям безопасности динамический поиск в ряде версий.NET Framework отключен, но его можно включить, изменив записи файла Machine.config.

А как же осуществляется поиск web-сервисов в глобальной сети? Для поиска web-сервисов в глобальной сети Microsoft, IBM и Ariba совместно разработали UDDI (Universal Description Discovery and Integration) - спецификацию построения распределенных баз данных, которая позволяет отыскивать web-сервисы. UDDI поддерживается сотнями компаний. UDDI-сайты сами являются web-сервисами. Каждый может опубликовать свой реестр на основе UDDI. Большинство разработчиков никогда не используют UDDI API напрямую. Вместо этого к реестрам UDDI обращаются инструментальные средства разработки. Они также генерируют классы-оболочки обнаруженных и выбранных web-сервисов.

8.8. Итоги

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

Веб-сервисы решают задачу интеграции приложений различной природы и построения распределенных ИС. В этом заключается основное принципиальное отличие веб-сервисов от предшественников - технологий взаимодействия распределенных приложений, так или иначе позволявших реализовать обмен данными между приложениями (среди получивших наибольшее развитие - Remote Procedure Calls (RPC), Distributed COM (DCOM), Remote Method Invocation (RMI) и Common Object Request Broker Architecture (CORBA)). Однако каждая из них была довольно сложна в реализации, не обладала необходимой универсальностью (т. е. все же зависела от выбора, например, одной и той же операционной системы для всех участников обмена) и, что особенно плохо, эти технологии с большим трудом стыковались между собой.

«ИССЛЕДОВАНИЕ И РАЗРАБОТКА МЕТОДОВ ПОСТРОЕНИЯ РАСПРЕДЕЛЕННЫХ СИСТЕМ АВТОМАТИЗИРОВАННОГО ПРОЕКТИРОВАНИЯ НА ОСНОВЕ ТЕХНОЛОГ...»

На правах рукописи

Анисимов Денис Андреевич

ИССЛЕДОВАНИЕ И РАЗРАБОТКА МЕТОДОВ ПОСТРОЕНИЯ

РАСПРЕДЕЛЕННЫХ СИСТЕМ АВТОМАТИЗИРОВАННОГО

ПРОЕКТИРОВАНИЯ НА ОСНОВЕ ТЕХНОЛОГИИ ВЕБ-СЕРВИСОВ

Специальность: 05. 13. 12 – Системы автоматизации проектирования

диссертации на соискание ученой степени

кандидата технических наук

Санкт Петербург 2013

Работа выполнена в федеральном государственном бюджетном образовательном учреждении высшего профессионального образования «Санкт-Петербургский государственный электротехнический университет «ЛЭТИ» им. В. И. Ульянова (Ленина), кафедра системы автоматизированного проектирования

Научный руководитель – доктор технических наук, профессор Дмитревич Геннадий Даниилович

Официальные оппоненты :

доктор технических наук, профессор, «Санкт-Петербургский государственный электротехнический университет «ЛЭТИ» им. В. И.

Ульянова (Ленина), кафедра автоматизированные системы обработки информации и управления Кутузов Олег Иванович кандидат технических наук, Открытое Акционерное Общество "Концерн

«НАУЧНО-ПРОИЗВОДСТВЕННОЕ ОБЪЕДИНЕНИЕ «АВРОРА»,

начальник лаборатории Пахоменков Юрий Михайлович

Ведущая организация : Федеральное государственное бюджетное образовательное учреждение высшего профессионального образования «Санкт-Петербургский национальный исследовательский университет информационных технологий, механики и оптики»

Защита диссертации состоится «23» мая 2013 г. в 16.30 часов на заседании диссертационного совета Д212.238.02 Санкт-Петербургского государственного электротехнического университета «ЛЭТИ» им. В.И.

Ульянова (Ленина) по адресу: 197376, г.Санкт-Петербург, ул. Профессора Попова, д. 5.

С диссертацией можно ознакомиться в библиотеке СПбГЭТУ Автореферат разослан «___»__________ 2013 г.

Ученый секретарь Диссертационного совета Д212.238.02 Н. М. Сафьянников

ОБЩАЯ ХАРАКТЕРИСТИКА РАБОТЫ

Актуальность исследования Широкое внедрение систем автоматизированного проектирования в практику инженерных задач существенно ограничивается высокой стоимостью лицензионного программного обеспечения. Наряду с этим создание собственных САПР связано с огромными затратами ресурсов и не может быть реализовано в сжатые строки, так как на разработку современных САПР требуются сотни человеколет. Проблема усложняется также и потому, что в реальных ситуациях эксплуатации многофункциональные интегрированные САПР используются, как правило, крайне неэффективно, поскольку при решении конкретных задач из основного состава этих систем часто применяется не более 10-20% программного обеспечения, наиболее специфичного для каждого подразделения.

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

Такие независимо управляемые приложения являются автономными и могут взаимодействовать друг с другом в процессе выполнения общей задачи.

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

Самым эффективным методом объединения подсистем в распределенное приложение следует считать организацию удаленного вызова процедур на базе сервис-ориентированной архитектуры с использованием веб-сервисов. Интеграция на базе веб-сервисов при разработке децентрализованных САПР позволяет перейти к описанию интерфейсов и взаимодействий на базе XML, обеспечивая возможность модификации и развития построенного программного обеспечения в условиях сохранения выбранного интерфейса. Это позволяет вследствие слабосвязанности отдельных подсистем обеспечивать взаимодействие между сервисами на произвольной платформе и проводить адаптацию существующих приложений к меняющимся условиям проектирования.

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

При разработке САПР с использованием вебсервисов могут быть применены следующие типы клиентских приложений:

приложение консольного типа, приложение оконного типа и вебприложение.

Особенностью консольных приложений является отсутствие графического интерфейса, однако их использование может оказаться полезным при реализации простейших САПР для карманных компьютеров с небольшой площадью экрана.

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

Веб-приложения обеспечивает возможность целиком разместить все используемое программное обеспечение САПР в сети. Достоинством приложения этой структуры является открытый доступ к использованию распределенной САПР через броузер любого типа, недостатком приложения такого типа является увеличение времени, которое требуется для описания компонентов проектируемой системы из-за ожидания реакции на отдельных шагах ввода данных.

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

Цель работы и основные задачи исследования Настоящая диссертация посвящена исследованию и разработке методов построения платформенно-независимых распределенных САПР с использованием веб-сервисов. Для конкретной реализации выбрана задача разработки распределенной системы автоматизации схемотехнического проектирования.

Для достижения поставленной цели следует решить следующие задачи:

1. Разработать общую методику построения, автономного тестирования и развертывания на выбранном сервере веб-сервисов Java.

2. Выполнить исследование общих методов построения программного обеспечения веб-сервисов Java для распределенной системы автоматизации схемотехнического проектирования.

3. Исследовать и разработать методику построения веб-сервисов Java с использованием технологии сжатия данных.

4. Провести исследование и разработку общей методики построения шаблонов клиентских приложений консольного и оконного типов, а также клиентских веб-приложений.

5. Разработать методику реализации функционирования вебсервисов и клиентских приложений в гетерогенных средах.

Методы исследования При выполнении поставленных задач в диссертации использованы основы общей теории САПР, тория систем моделирования, основы теории матриц и графов.

Достоверность научных результатов Подтверждается основными положениями общей теории САПР, теории моделирования, корректностью применяемого математического аппарата, и результатами, полученными при тестировании созданного программного обеспечения веб-сервисов и клиентских приложений.

Новые научные результаты

1. Предложена сервис-ориентированная архитектура распределенной САПР с использованием веб-сервисов.

2. Разработана общая методика реализации, автономного тестирования, а также развертывания на сервере распределенной САПР вебсервисов Java.

3. Исследованы и разработаны методы построения программного обеспечения веб-сервисов Java для решения типовых задач проектирования электронных схем.

5. Разработана общая методика построения консольных и оконных клиентских приложений, а также клиентских веб-приложений.

6. Разработана методика реализации программного обеспечения распределенной САПР для организации взаимодействия в гетерогенных средах веб-сервисов и клиентских приложений.

Основные положения , выносимые на защиту

1. Архитектура распределенной сервис-ориенировнной САПР на основе веб-сервисов.

2. Общая методика восходящего проектирования веб-сервисов Java

3. Методика реализации программного обеспечения веб-сервисов Java на основе сжатия данных.

Практическая ценность

1. Предложенная структура распределенной САПР обеспечивает возможность организовать взаимодействие между различными вебсервисами на выбранной платформе и адаптировать приложения к изменяющимся условиям проектирования.

3. Разработанная методика реализации клиент-серверного взаимодействия обеспечивает работу распределенных САПР в средах гетерогенного типа.

4. Программное обеспечение разработанной распределенной системы автоматизации схемотехнического проектирования содержит инвариантное ядро для организации как символьного, так и численного этапов работы Java-программ, которое можно использовать в качестве базы при построении систем проектирования широкого перечня объектов.

Реализация и внедрение результатов Разработанная в диссертации распределенная САПР с использованием веб-сервисов была реализована на языке Java c использованием платформы WTP (Web Tools Platform). Практическим результатом является платформенно-независимая распределенная схемотехническая САПР, которая осуществляет многовариантное моделирование нелинейных схем в стационарном режиме, в динамическом режиме, для расчета частотных характеристик, а также обеспечивает расчет чувствительности передаточных функций и чувствительности переменных стационарного режима к вариации параметров.

Результаты диссертационной работы использовались в госбюджетных НИР по теме «Разработка моделей и методов анализа и синтеза интеллектуальных систем поддержки принятия решений для управления сложными распределенными объектами» (шифр САПР-47 тем. плана СПбГЭТУ 2011 г.) и по теме «Математико-логические основы построения сред виртуальных инструментов» (шифр САПР-49 тем. плана СПбГЭТУ 2012 г.) Результаты диссертации внедрены в инженерную практику научнопроизводственной фирмы «Модем» и используются в учебном процессе кафедры САПР СПБГЭТУ для изучения методики построения программного обеспечения систем автоматизации схемотехнического проектирования при подготовке бакалавров и магистров по направлению «Информатика и вычислительная техника».

Апробация работы Основные положения диссертации докладывались и обсуждались на следующих конференциях:

1. 9-ая конференция молодых ученых «Навигация и управление движением».– СПб.;

2. 5-ая международная конференция «Приборостроение в экологии и безопасности человека».– СПб., ГУАП;

3. XIII, XIV, XVII -ая международные конференции « Современное образование: содержание, технологии, качество». – СПб., СПбГЭТУ;

4. 60, 61, 63-ая научно-технические конференции профессорскопреподавательского состава ГЭТУ.

Публикации Основное теоретическое и практическое содержание диссертации опубликовано в 16 научных работах, в числе которых 4 статьи в ведущих рецензируемых изданиях, рекомендованных в действующем перечне ВАК, 1 свидетельство об официальной регистрации программы для ЭВМ, зарегистрированной в Федеральной службе по интеллектуальной собственности, патентам и товарным знакам.

Структура и объем диссертации Диссертация содержит введение, четыре главы основного содержания, заключение и список литературы, содержащий 69 источников. Работа изложена на 154 страницах текста, и содержит 21 рисунок и одну таблицу.

Во введении дается обоснование актуальности темы диссертации, сформулированы цели исследования и приведен перечень решаемых в работе задач.

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

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

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

Для построения распределенных САПР в диссертации предлагается использовать сервис-ориентированную архитектуру (SOA) на основе модульной структуры программного обеспечения и стандартизированных интерфейсов. SOA использует унификацию основных операционных процессов, принципы неоднократного применения функциональных элементов, организацию на базе платформы интеграции. Хотя архитектура SOA не связана с какой-то определённой технологией удаленного вызова процедур, программные подсистемы, разработанные согласно с SOA, обычно реализуются как совокупность веб-сервисов, связанных при помощи основных протоколов (SOAP, WSDL).

Системы на основе сервис-ориентированной архитектуры относятся к классу мультиагентных систем (МАС), которые образованы несколькими взаимодействующими интеллектуальными агентами, обеспечивающими автономность, ограниченность представления и децентрализацию отдельных подсистем распределенной информационно-вычислительной системы.

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

Конкретная методика реализации веб-сервисов существенно зависит от выбранного языка программирования. В работе показано, что предпочтение при выборе языка программирования для построения веб-сервисов следует отдать языку Java, который наиболее полно обеспечивает платформенную независимость реализованных решений. Немаловажным обстоятельством в пользу такого выбора является также наличие мощной инструментальной поддержки разработки веб-ориентированных приложений на Java, которая обеспечивается средой WTP (Web Tools Platform).

В диссертационной работе проведен сравнительный анализ двух основных методов построения веб-сервисов Java – восходящего (Bottom-Up), когда сначала создается Java-класс веб-сервиса, а затем на его основе генерируется WSDL-документ, и нисходящего (Top-Down), когда сначала создается требуемый документ WSDL, а затем на его базе формируется код реализации веб-сервиса. На основании сравнительной оценки показано, что проектирование веб-сервисов следует выполнять восходящим методом, поскольку при этом WSDL-документ формируется на основании созданного заранее Java-класса, в котором описаны все передаваемые методу вебсервиса параметры и возвращаемые этим методом значения. При этом вся имеющаяся в Java-классе информация автоматически преобразуется в соответствующий WSDL-документ, содержание которого точно соответствует базовой структуре спецификации WSDL и основным характеристикам вызываемого метода веб-сервиса, что обеспечивает полную достоверность содержащейся в WSDL-документе информации.

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

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

Во второй главе рассматриваются методы построения веб-сервисов распределенной САПР, при помощи которой осуществляется расчет нелинейных схем в стационарном режиме, расчет схемных функций линейных и линеаризованных схем для частотной области, выполняется расчет нелинейных схем в динамических режимах. Помимо этого, в число включаемых в распределенную систему подсистем входит веб-сервис для расчета чувствительности схемных функций в частотной области, и вебсервис для расчета чувствительности переменных стационарного режима нелинейных схем к вариации параметров. В качестве компонентов проектируемых на базе разработанных веб-сервисов схем можно использовать двухполюсники типа R, C, L, линейные частотно-зависимые управляемые источники, нелинейные управляемые источники, трансформаторы, биполярные и униполярные транзисторы, операционные усилители, а также задающие источники тока и напряжения.

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

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

Для решения первой группы задач расчета частотных свойств электронных схем при выполнении диссертационной работы построен вебсервис ModService_Java. Для возможности работы с комплексными числами при его построении создан пользовательский класс Complex, поскольку на момент выполнения настоящей работы такой класс не входит в состав стандартных средств API Java. Класс Complex содержит конструкторы и вспомогательные функции для обработки комплексных данных и все необходимые функции для выполнения арифметических и логических операций с комплексными числами, поскольку в языке Java отсутствует оператор переопределения этих операций. Веб-сервис получает в качестве аргументов описание компонентов схемы и директивы расчета и возвращает массив с описанием результатов расчета частотных характеристик.

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

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

При разработке методики построения веб-сервиса для расчета динамических режимов нелинейных систем используется математическое описание схемы в модифицированном расширенном базисе узловых потенциалов, что позволяет получить в наиболее общей форме систему уравнений алгебро-дифференциального типа. Исключение производных из компонентных уравнений выполняется на основе формул коррекции, которые вытекают из многошаговых неявных методов высших порядков, при этом принят в качестве основного метод Гира второго порядка с возможностью увеличения его порядка. В качестве компонентов, из уравнений которых исключаются производные, выступают двухполюсники типа С и L, диоды, трансформаторы, биполярные и униполярные транзисторы, операционные усилители, а также частотно-зависимые управляемые источники. Для вычисления значений автономных источников, сохраняющих значения соответствующих переменных на предшествующих шагах, построены вспомогательные функции дискретизации dis_cmp для всех перечисленных компонентов cmp с частотно-зависимыми свойствами.

Разработанная методика реализована при построении веб-сервиса Dyn2Service_Java, который возвращает на клиентскую сторону массив с описанием результатов расчета динамических характеристик.

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

Это обстоятельство ставит задачу изменения общепринятых подходов к формированию и решению уравнений в целях экономии памяти и повышения быстродействия, что имеет решающее значение для функционирования вебориентированных систем.

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

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

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

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

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

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

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

Основанный на дифференцировании уравнений метод веб-сервиса VaryService позволяет рассчитать значения абсолютной и относительной векторной чувствительности схемных функций для частотной области к выбранному вариируемому параметру для всей совокупности базисных переменных. В качестве вариируемых параметров могут выступать значения сопротивления, емкости, или индуктивности произвольного двухполюсника схемы типа R, C или L, и параметры передач управляемых частотнозависимых источников типа ИТУН, ИНУН, ИТУТ или ИНУТ.

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

Для расчета чувствительности переменных, задающих стационарный режим нелинейных схем, к вариации их параметров, разработан веб-сервис StVaryService, который так же содержит два метода, один из которых основан на дифференцировании уравнений, а второй – на присоединенной схеме. В качестве вариируемого параметра в обоих методах могут выступать значения сопротивлений резисторов и параметры передачи управляемых источников типа ИТУН, ИНУН, ИТУТ или ИНУТ.

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

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

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

В четвертой главе рассматриваются методы построения пользовательских клиентских приложений, обеспечивающих взаимодействие с веб-сервисами, которые после окончания их построения в инструментальной среде разработки Java-приложений должны быть развернуты на сервере распределенной САПР. Для развертывания вебсервиса необходимо знать его основные характеристики, в числе которых имя сервиса, имя класса, имена методов, тип WSDL-документа.

Соответствующая информация о разработанных и описанных выше вебсервисах для распределенной системы схемотехнического проектирования приводится в диссертации, и в информационных методах с именем getInf, которые входят во все разработанные веб-сервисы. В работе предлагается простая методика непосредственного развертывания на сервере веб-сервисов, и рассматриваются возможные способы импортирования на клиентскую сторону файла WSDL. На основании сравнительного анализа в работе показывается, что корректность выполнения операции доставки WSDLфайла из удаленного веб-сервиса в клиентское приложение наиболее эффективно может быть обеспечена путем использования инструмента Web Services Explorer, и устанавливается наиболее оптимальная последовательность импортирования WSDL-файла в начальный каркас клиентского приложения.

После доставки WSDL-файла в проект клиентского приложения дальнейшие преобразования начального каркаса проекта в законченное клиентское приложение предлагается проводить в два этапа. Первым этапом такого преобразования является создание прокси-объекта в начальном каркасе проекта, а вторым этапом – формирование классов, содержащих методы, поддерживающие функционирование прокси-объекта и взаимодействие удаленного сервиса с клиентским приложением. Реализация первого этапа сводится к дополнению проекта операторами, создающими прокси-объект, второй этап выполняется при помощи инструмента Web Services платформы WTP, наиболее эффективные способы использования которого приводятся в диссертации.

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

При выполнении диссертации для всех перечисленных выше вебсервисов распределенной САПР были реализованы клиентские консольные приложения. Их исходные файлы могут быть доставлены стандартными средствами через сеть Интернет клиенту и использованы, как для построения простейшего варианта консольного приложения для взаимодействия с сервисами распределенной САПР, так и в качестве методического пособия для разработки более совершенных оконных приложений.

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

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

Положительным свойством этой архитектуры является возможность организации доступа к распределенной САПР через произвольный вебброузер без необходимости построения собственного клиентского приложения, недостатком такого подхода к организации распределенной САПР является неизбежное увеличение интервала времени, которое требуется для описания компонентов системы в процессе диалогового взаимодействия.

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

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

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

Стандартизация SOAP предоставляет возможность соединения между собой слабосвязанных приложений независимо от платформы их реализации, что позволяет при использовании веб-сервисов обеспечить эффективное и оптимальное использование широкого ряда гетерогенных, слабосвязанных ресурсов в распределенных приложениях. В диссертации приводится общая методика построения программного обеспечения для осуществления взаимодействия объекта прокси-класса приложения среды.NET с сервисом среды Java/J2EE. На основании этой методики реализована организация взаимодействия разработанных веб-сервисов Java с клиентскими Windowsприложениями, построенными в среде.NET на основе языка C#.

Возможность функционирования распределенной САПР в гетерогенных средах существенно расширяет область ее применения.

В заключении сформулированы основные научные и практические результаты, полученные на основе проведенных в диссертации исследований.

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

1. Разработана архитектура распределенной сервисориентированной САПР на основе веб-сервисов, отличающаяся децентрализованной структурой, платформенной независимостью и возможностью проведения непрерывной модернизации отдельных подсистем для адаптации их свойств к изменяющимся условиям проектирования.

2. Реализована общая методика построения восходящим методом веб-сервисов Java и соответствующих WSDL-документов, а также доставки их на сервер распределенной САПР после проведения автономного тестирования в среде разработки.

3. Разработана методика построения программного обеспечения веб-сервисов Java для решения типовых задач моделирования непрерывных систем при автоматизированном проектировании электронных схем.

4. Построена библиотека вспомогательных функций для реализации программного обеспечения веб-сервисов Java на основе сжатия данных.

5. Разработана общая методика построения шаблонов консольных и оконных клиентских приложений распределенной системы автоматизации схемотехнического проектирования и реализована организация функционирования распределенной САПР с клиентскими вебприложениями.

6. Разработана методика построения распределенных САПР, обеспечивающая взаимодействие веб-сервисов Java и клиентских приложений произвольного типа в гетерогенных средах.

1. Анисимов Д.А. Построение систем автоматизированного проектирования на основе Web-сервисов [Текст] / Анисимов Д.А. Гридин В.Н., Дмитревич Г.Д. // Автоматизация в промышленности – 2011. – №1 – С. 9-12.

2. Анисимов Д.А. Построение систем автоматизированного проектирования на основе Web-технологий [Текст] / Гридин В.Н., Дмитревич Г.Д., Анисимов Д.А // Информационные технологии – 2011. – №5. – С. 23-27.

3. Анисимов Д.А. Построение веб-сервисов систем автоматизации схемотехнического проектирования [Текст] / Гридин В.Н., Дмитревич Г.Д., Анисимов Д.А // Информационные технологии и вычислительные системы – 2012. – №4. – С. 79-84.

4. Анисимов Д.А. Методы построения систем автоматизации схемотехнического проектирования на основе веб-сервисов [Текст] /Анисимов Д.А // Известия СПбГЭТУ «ЛЭТИ» – 2012. – №10. – СПб.: Изд-во СПбГЭТУ «ЛЭТИ»,– С. 56-61.

5. Анисимов Д.А. Доступ к Web-ресурсам в САПР систем навигации и управления [Текст] / Ларистов Д.А., Анисимов Д.А. // Гироскопия и навигация. 2007. № 2. –С. 106.

В данной статье мне хотелось бы обсудить вопросы, связанные с проектированием web сервисов, предназначенных для межпрограммного взаимодействия. Так называемых – интеграционных web сервисов. Прежде всего, это сервисы, которым предстоит работать в различных решениях класса Enterprise Applications Integration (EAI), а также в B2B решениях. Вопросам разработки web сервисов с использованием различных платформ посвящено множество книг и статей, а вот вопросы проектирования освещены гораздо хуже. Вы можете найти массу статей с заклинаниями на тему SOA, которые будут совершенно бесполезны, когда вы приступите к проектированию своего web сервиса.
Итак, давайте рассмотрим ситуацию, когда у вас на руках есть две работающие системы (либо проекты двух систем), и перед вами стоит задача организовать взаимодействие между ними. Вам надоели схемы синхронизации на основе файлов импорта / экспорта, и вы остановили свой выбор на модной, современной и удобной технологии web сервисов. Я попытаюсь рассказать о том, на что следует обратить внимание и как избежать типичных ошибок при проектировании web сервиса для взаимодействия двух систем.

Немного SOA

И все же, сначала пару слов о небезызвестной SOA. Термин Service Oriented Architecture (SOA) довольно серьезно пострадал от беспорядочного употребления в маркетинговых целях. Его так часто употребляют в различных контекстах, что теперь сказать что-то определенное о SOA, кроме того, что это - «сервис ориентированная архитектура», уже трудно.
Тем не менее, SOA имеет такое же право на жизнь, как и «клиент – серверная архитектура» или «много уровневая архитектура». Как и любая другая «архитектура», SOA вводит ряд абстракций и правил, которые помогают нам в разработке определенного класса приложений. В данном конкретном случае, руководствоваться принципами SOA полезно при разработке механизмов взаимодействия и интеграции приложений в масштабе предприятия (Enterprise Applications Integration - EAI).
Итак, начнем с того, что SOA рассматривает приложения как сервисы или совокупности сервисов, которые обмениваются сообщениями напрямую, либо посредством некоторых интеграционных механизмов. Эти сервисы должны удовлетворять ряду условий или требований.
Во-первых, сервис должен иметь определенное «business value», иными словами, сервис должен иметь прикладное значение. Если вы не можете простыми словами объяснить заказчику или пользователю системы для чего нужен ваш сервис, то с точки зрения SOA это неудачный сервис. Пример плохого сервиса: «Сервис для получения глобально – уникальных идентификаторов». Пример хороших сервисов: «Сервис данных о сотрудниках предприятия» или «Сервис приема и обработки счетов к оплате» (Accounts Payable).
Во-вторых, с точки зрения SOA, сервисы должны быть автономными и независимыми. Это необходимо для того, чтобы как это принято в SOA, мы могли комбинировать одни сервисы с другими в зависимости от потребностей бизнеса. Если мы захотели использовать «Сервис приема и обработки счетов к оплате» и при этом узнаем, что нам придется установить и использовать «Сервис бюджетирования и финансового планирования», «Сервис ведения главной книги», и еще дюжину сервисов, то с точки зрения SOA все это выглядит просто отвратительно.
В-третьих, сервис должен быть функционально полным с прикладной точки зрения. Это требование комплиментарно предыдущему. Например, «Сервис приема и обработки счетов к оплате» позволяет добавить заявку, а отследить ее статус не позволяет. Но в принципе мы можем получить отчет по заявкам, из которого можно узнать о статусе заявки. Не правда ли, знакомая ситуация? С точки зрения SOA, да и с любой точки зрения – это не правильно. Сервис должен обеспечивать выполнение всех основных бизнес операций, связанных с прикладной областью или бизнес процессом, который он обеспечивает.
В-четвертых, все сервисы должны уметь предоставлять свои описания в некотором стандартизированном формате. WSDL и UDDI - это варианты форматов описания сервисов.
В-пятых, сервисы должны быть ориентированы на распределенное асинхронное взаимодействие без хранения состояния. Это типично для большинства современных распределенных систем, и это очень важное требование. Достаточно вспомнить, что клиент-серверная архитектура ориентирована на синхронное взаимодействие с хранением состояния, и именно это обстоятельство стало ключевым ограничением для дальнейшего развития этой архитектуры.
В-шестых, SOA предполагает, что благодаря выполнению предыдущих требований, сервисы будут способны объединяться для взаимодействия друг с другом при помощи различных интеграционных инструментов, типа брокеров и маршрутизаторов сообщений, серверов workflow и т.д. и т.п. Ключевым моментом здесь является тот факт, что интеграционные сценарии будут основываться на конфигурировании, часто визуальном, а не на разработке специального «интегрирующего» кода, как это делается в большинстве случаев сейчас.
Вот примерно так выглядят основные вехи, на которые мы должны ориентироваться и которые должны ограничивать нашу разыгравшуюся дизайнерскую мысль в процессе проектирования и разработки интеграционных web сервисов.

Проектирование контракта сервиса.

После того, как Microsoft в своей платформе Windows Communication Foundation – WCF (бывшая Indigo) использовала термин «контракт сервиса», он имеет все шансы сделаться стандартным термином де-факто.
Контракт сервиса - это описание сигнатур всех его операций (методов), плюс описание форматов данных, которыми он оперирует в качестве входных и выходных сообщений.
Для web сервисов контракт исчерпывающе описывается WSDL схемой сервиса. Однако согласитесь, что WSDL не очень хорошо приспособлен для человеческого восприятия. Гораздо нагляднее контракт можно изобразить в виде UML диаграммы классов. К счастью, большинство современных платформ для разработки web сервисов обеспечивают функцию автоматической генерации WSDL описания сервисов.
Правильно спроектированный контракт сервиса, залог успеха, и гарантия того, что ваш сервис проживет долгую и счастливую жизнь, и умрет своей смертью, потому что на смену ему придет новая технология, о которой мы сейчас ничего не знаем.
Microsoft предлагает специальный термин – “contract first” для описания подхода к проектированию, ориентированного в первую очередь, на контракт. Он предполагает, что проектирование сервиса должно начинаться с описания XSD схем сообщений (данных), затем создается WSDL описание операций сервиса, по которому генерируется код класса сервиса. И лишь после этого приступают к имплементации логики. Идея здравая, однако, я повторюсь, что работать с XSD и WSDL не очень удобно, даже с использованием визуальных средств типа XmlSpy. Кроме того, сам по себе принцип “contact first” не гарантирует нам получения правильного контракта сервиса.
Для меня принцип “contact first” означает, что при проектировании сервиса мы должны в первую очередь думать о его контракте и в последнюю - о деталях реализации. Следует взглянуть на будущий сервис c внешней стороны, глазами потребителя данных этого сервиса. Такой взгляд упрощает транспонирование требований предъявляемых к сервису в набор предоставляемых им операций. Например, мы разрабатываем сервис, предоставляющий данные о сотрудниках предприятия. Логично предусмотреть в нем операцию, возвращающую список всех сотрудников. Однако, в ходе анализа требований может оказаться, что потребителю данных нашего сервиса будет интересен, в первую очередь, список сотрудников конкретного подразделения. Это говорит нам о том, что в контракт операции, возвращающей список сотрудников, следует добавить параметр, позволяющий отфильтровать сотрудников конкретного подразделения, либо, нам следует выделить это действие в отдельную операцию сервиса. Такой подход будет соответствовать принципу “contract first”. И напротив, мы могли бы возложить на потребителя данных нашего сервиса обязанность выбрать сотрудников нужного ему отдела из общего списка. Придерживаться подобной стратегии при проектировании интеграционных сервисов – плохая практика. Разбирая конкретный данный случай, мы можем говорить о том, что такое решение не оптимально с точки зрения нагрузки на сервис или объема трафика, а также что такое решение снижает безопасность. Обобщая, можно сказать, что основания простоты и универсальности не должны превалировать при проектировании сервиса. Универсальность сервиса должна достигаться тщательным дизайном. Крайне сложно дать какие либо практические рекомендации в данном направлении. Не легко создать сервис, который бы не состоял из одного метода, вываливающего все внутренние данные системы наружу, и в тоже время был достаточно универсальным для того, чтобы его смог использовать не только тот потребитель, для которого вы проектировали сервис, но и любой другой. Чтобы добиться этого, следует обращать внимание на функциональную полноту контракта сервиса.
Давайте рассмотрим пример. Предположим, существует некая система учета и согласования счетов к оплате, из разряда тех, что обозначаются термином Accounts Payable. Система позволяет вводить данные счетов к оплате, обеспечивает бизнес процесс их согласования и, далее взаимодействует с бухгалтерской системой для формирования платежей. Ввод счетов и их согласование осуществляется, через UI системы. Перед нами стоит задача: создать web сервис, посредством которого другие системы могли создавать счета и отслеживать их статус.
Для простоты, будем считать, что счет к оплате имеет следующую структуру:

Где:
Number – уникальный номер счета, присваиваемый при создании
RecipientID – ссылка на справочник контрагентов, в котором хранятся все реквизиты получателя платежа
Amount – сумма к оплате
PaymentDate – дата оплаты
CategoryID – ссылка на справочник категорий платежей
Owner - имя сотрудника, который создал счет
Description – описание
State – состояния счета, вокруг которого строится бизнес процесс согласования счета.
Итак, исходные требования нам ясны. Схема данных для представления счета, тоже понятна. На основе представленной диаграммы будет создана вот такая XML схема, которая нас вполне устраивает:

Теперь попробуем набросать сигнатуру методов сервиса. Исходя из требований нам понятно, что сервис должен содержать методы, которые позволяют создавать, просматривать и удалять счета к оплате. Получился сервис с тремя методами:

Выглядит просто ужасно! Давайте разберем, что здесь не так.
Метод добавления счета AddPayment() принимает в качестве параметра структуру Payment, а возвращает номер, присвоенный счету. Структура Payment не очень подходящий тип данных для параметра этого метода, потому что она содержит ряд полей, заполнение которых подчиняется внутренней бизнес логике системы. Это поля Number, State и Owner. Мы не знаем этих бизнес правил, и не знаем, как заполнять эти поля. Для создания счета мы должны указать: получателя, сумму платежа, дату, категорию и описание. Поэтому имеет смысл создать метод именно с такими параметрами, который создаст счет к оплате и вернет его в структуре Payment.
Метод ListPayments() возвращает список счетов в виде массива структур Payment. Возможно, система должна возвращать только те счета, которые были созданы данным пользователем. Однако отсутствие соответствующего параметра в сигнатуре метода не должно вас удивлять. Более надежный и безопасный способ получить данные о пользователе, - взять их из данных аутентификации. Со временем в системе может накопиться огромное количество счетов, и данному методу не помешали бы параметры для фильтрации выдаваемого списка по датам.
Наконец, метод RemovePayment() - принимает номер счета и возвращает true в случае успешного удаления и false в противном случае. Использование Boolean в качестве результата не лучшее решение в данном случае. Причины неудачи операции удаления могут быть самыми различными от простого отсутствия счета с указанным номером, до нарушения логических ограничений системы (например, нельзя удалить счет со статусом Commited). Ситуация довольно распространенная. Ошибка может случиться при выполнении любого метода web сервиса, и, к счастью, инфраструктура web сервисов предлагает стандартный подход к решению этой проблемы. Для передачи данных об ошибке используется SOAP сообщение, в теле которого содержится элемент Fault с информацией об ошибке. Таким образом, нам не нужно расширять контракт нашего web сервиса для передачи сообщений об ошибках, и в случае метода RemovePayment() мы можем вполне обойтись без возвращаемого значения. В случае неудачи удаления счета, информация о причине будет передана в сообщении об ошибке.
После всех изменений наш web сервис будет выглядеть так:

Выглядит значительно лучше, но проблемы остались.
Давайте посмотрим на метод CreatePayment(). Для того чтобы создать счет, нам надо передать пять параметров. С параметрами amount, date, desc, у нас проблем нет. Но вот откуда взять ссылки на получателя (recipient) и категорию (category)? Как я уже упоминал, эти данные представляют собой ссылки на элементы соответствующих справочников нашей системы. И теперь нам становится понятно, что для успешного использования нашего web сервиса, мы должны предоставить доступ к значениям этих справочников.

Таким образом, окончательный вид контракта нашего web сервиса дополнился двумя методами EnumRecipient() и EnumCategory() и двумя типами данных RecipientInfo и CategoryInfo. Их не было в первоначальном контракте и необходимость этих методов не определяется первоначальными требованиями. Они служат для обеспечения синтаксической полноты контракта нашего сервиса. Теперь потребитель данных сервиса может вызвать методы EnumRecipient() и EnumCategory() для получения списков получателей и категорий, выбрать из них необходимые значения, и затем вызвать метод CreatePayment() для создания счета.
Теперь мы можем сказать, что мы спроектировали функционально и синтаксически полный сервис. Также, наш сервис достаточно универсален, и с большой вероятностью его удастся использовать для интеграции с другими системами, перед которыми будут стоять похожие задачи. Кроме того, контракт сервиса и его WSDL описание, включают в себя полные схемы данных всех сообщений. Это очень важно для того, чтобы наш сервис смогли использовать инструменты интеграции типа BizTalk Server, Fiorano ESB, Sonic ESB и др.
На последнем моменте хочется заострить внимание. Формат данных, которыми обменивается сервис, очень важен. Разработчики нередко впадают в одну из двух крайностей. Первая из них, это использование в качестве формата для всех сообщений «голого Xml». Причины тому могут быть самые разные, от попыток использования существующего кода импорта - экспорта Xml данных, до слишком буквального понимания сути web сервисов, как механизма обмена Xml сообщениями. Недостаток такого подхода достаточно очевиден, - схема данных не попадает в WSDL описание контракта сервиса, и это затрудняет его использование. На мой взгляд, существует единственный случай, когда такой подход оправдан. Это случай, когда нам заранее не известен формат передаваемых данных. Во всех остальных случаях, следует использовать типизированные сообщения.
Вторая крайность, это противоположность первой, и выражается она в том, что разработчики пытаются использовать в контракте сервиса существующие в системе внутренние форматы представления данных. Действительно, если в системе уже определены структуры и классы для представления данных (Data Transfer Objects), то почему бы не использовать их в контракте сервиса? Это не всегда это хорошая идея. Внутренние форматы данных могут оказаться не удобными для клиента сервиса. Они могут иметь специфический формат, который не поддерживается клиентской стороной. Пример такого формата DataSet из Microsoft ADO.NET. Данные DataSet прекрасно преобразуются XML и могут быть использованы ASP.NET web сервисами. Однако, это внутренний формат Microsoft, который не является отраслевым стандартом, он имеет свои особенности форматирования Xml представления, которые могут затруднить использование этих данных другими программными платформами web сервисов. Существует масса случаев, в которых использование DataSet оправданно и удобно, но интеграционные сервисы не относятся к их числу.
Таким образом, общие рекомендации по проектированию форматов сообщений web сервисов сводятся к следующему. Всегда старайтесь использовать типизированные сообщения, формат которых описывается определенной Xsd схемой. Проектируйте формат сообщений исходя из функциональных требований, и лишь в том случае, когда полученный формат совпадает с внутренним форматом данных системы, можно подумать об использовании внутреннего формата.

Протокол взаимодействия и его влияние на контракт

Под протоколом взаимодействия web сервиса мы понимаем ту часть требований, которая описывает последовательность взаимодействия сервиса и клиента, направление передачи данных, а также такие аспекты поведения сервиса, как транзакционность, асинхронность, и т.д.
Протокол взаимодействия и контракт сервиса очень тесно связанны. Помимо достаточно простых случаев, когда существует один сервис и его клиент, существуют и более сложные, в которых протокол взаимодействия требует наличия двух и более сервисов. Примером такого протокола может служить протокол асинхронного взаимодействия ASAP
Я не открою большого секрета, если скажу, что отличным способом построить контракт сервиса (по крайней мере, в плане используемых операций) является использование UML диаграмм взаимодействия. Мое личное мнение, наилучшие результаты дает применение Sequence diagram. На рисунке приведена Sequence diagram взаимодействия клиента и сервиса из примера AccountsPayable, рассмотренного выше. К сожалению данный пример достаточно прост, чтобы почувствовать насколько Sequence diagram облегчают проектирование контракта сервиса.

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

Вопросы безопасности

После того, как контракт сервиса разработан, а иногда и раньше, перед проектировщиком в полный рост встают проблемы обеспечения безопасности. Времена, когда web сервисы называли незрелой технологией, не способной обеспечить безопасность данных, давно прошли. Web сервисы могут быть надежными и безопасными. А могут и не быть. Тут все зависит от нас.
Очертим круг вопросов, которые надо решить, для того чтобы спроектировать безопасный сервис:

Аутентификация клиентов сервиса
Авторизация клиентов сервиса
Безопасность передачи данных
Хранение удостоверений для подключения клиентов к сервису

Аутентификация – это процесс подтверждения подлинности пользователя на основе предъявленных им удостоверений. Надежность механизмов аутентификации является критичной для обеспечения безопасности приложения в целом. Поэтому сразу стоит забыть об «анонимном доступе». Наилучший сценарий обеспечения аутентификации, воспользоваться средствами, предоставляемыми платформой web сервисов, которую вы используете. Обычно для аутентификации используются специализированные протоколы (Kerberos, NTLM) и их поддержка встраивается в платформу. Реализация собственных механизмов аутентификации наверняка потребует значительных затрат и чревата потенциальными сложностями реализации и дальнейшей поддержки.
Авторизация - это процесс предоставления пользователю полномочий по доступу к функциям и данным. Естественно, для того чтобы авторизовать пользователя, предварительно он должен быть аутентифицирован. Уловите разницу между аутентификацией и авторизацией. Аутентификация отвечает на вопрос «кто» такой клиент, а авторизация – на вопрос «что» может делать этот клиент. В подавляющем большинстве случаев, бизнес правила по которым тому или иному пользователю предоставляются права доступа к тем или иным данным и операциям определяются в самом приложении. И, следовательно, авторизация – это область ответственности приложения, предоставляющего сервис. Существует множество методов, практик и шаблонов реализации механизмов авторизации, описание которых может быть предметом отдельной статьи.
Помимо аутентификации и авторизации, защита данных при транспортировке их между сервисом и его клиентом является третьей составной частью в обеспечении безопасности web сервиса. Степень защиты определяется характером данных. Различают два способа защиты данных: цифровая подпись и шифрование.
Цифровая подпись используется для подтверждения подлинности данных. Она не защищает данные от несанкционированного прочтения, потому что данные не шифруются. Цифровая подпись позволяет удостовериться в том, что данные принадлежат именно владельцу подписи, а также в том, что данные не были изменены с момента подписи. Механизм цифровой подписи довольно прост. Он основан на использовании не симметричных алгоритмов шифрования, в которых используется пара ключей, один из которых приватный (закрытый) а второй публичный (открытый). Особенность не симметричных алгоритмов состоит в том, что данные, которые зашифрованы одним ключом, можно расшифровать только другим ключом. Цифровая подпись формируется следующим образом. Для данных вычисляется контрольная сумма (хэш код), которая шифруется приватным ключом владельца цифровой подписи. Это и есть цифровая подпись, она добавляется к данным. Так же, к данным может быть добавлен открытый ключ. С помощью открытого ключа, любой пользователь может расшифровать цифровую подпись и получить контрольную сумму, которую можно сравнить с контрольной суммой рассчитанной над текущими данными и, таким образом узнать, изменились ли данные.
В случае, когда нам необходимо не только обеспечить неизменность данных, но и скрыть от посторонних их содержимое, применяется шифрование. Обычно, при передаче данных применяется схема с сеансовым ключом, на механизме которой я не буду останавливаться, поскольку обычно она обеспечивается на инфраструктурном уровне. Итак, цифровая подпись и шифрование являются основными механизмами защиты данных при передаче. Мы можем задействовать эти механизмы на уровне транспортного протокола, либо на уровне сообщений SOAP. Каждый из способов имеет свои преимущества и недостатки.
Для обеспечения защиты данных на уровне транспортного протокола обычно применяют хорошо зарекомендовавший себя механизм SSL. При этом между клиентом и сервером устанавливается защищенное соединение, в котором шифруется весь трафик. Преимущество данного подхода состоит в том, что он практически не требует дополнительных усилий со стороны разработчика (за исключением, может быть некоторых особенностей при установлении соединения). Основная работа по настройке защищенного SSL соединения производится при развертывании приложения. К недостаткам такого подхода можно отнести то, что шифруется весь трафик, а не только те данные, которые действительно являются конфиденциальными, и это требует больших затрат вычислительных ресурсов. Описание того, как использовать SSL совместно с web сервисами ASP.NET 1.1 вы можете найти в моей статье по адресу http://stump-workshop.blogspot.com/2006/10/web-https-ssl.html
Механизмы защиты данных на уровне SOAP сообщений строятся на использовании таких расширений SOAP протокола, как WS-SecureConversation , WS-Trust , WS-SecurityPolicy и WS-Security . Обычно поддержка этих спецификаций встроена на уровне платформы, реализующей web сервисы, и для разработчика они доступны как на декларативном уровне (атрибуты или конфигурирование) так и в виде API. К преимуществам использования данных механизмов относится их гибкость и универсальность. Вы можете использовать как шифрование, так и цифровую подпись. Можно обеспечить защиту только сообщений отдельных операций сервиса, и даже отдельных частей SOAP сообщения. К сожалению не все платформы web сервисов в полной мере поддерживают данные спецификации. Например, в широко распространенном.NET Framework 1.1 нет поддержки WS-Security. Поэтому при использовании данной платформы придется реализовывать защиту на транспортном уровне.
Наконец есть третий путь, - реализовать свой механизм защиты как, например, описано . Следует, однако, понимать, что такой путь резко сокращает возможности использования вашего сервиса.
В заключении, стоит остановиться на таком вопросе, как хранение удостоверений для подключения к web сервисам. Мы уже говорили о том, что доступ к web сервисам следует предоставлять только аутентифицированным пользователям. Обратная сторона медали состоит в том, что нам необходимо указывать удостоверения (credentials) при подключении клиента к сервису. А следовательно, нам необходимо где-то хранить эти удостоверения. Когда нашей системе приходится взаимодействовать с несколькими сервисами, каждый из которых требует свои удостоверения, проблема приобретает особую остроту.
Что такое удостоверения. В большинстве случаев - это пара значений логин – пароль. Иногда это может быть клиентский сертификат или другой тип удостоверений, - все зависит от используемого протокола аутентификации. Следует четко понимать, что клиентские удостоверения относятся к данным, которые могут быть использованы для атаки злоумышленника на систему. Следовательно, эти данные требуют защиты. Вам следует учитывать это обстоятельство еще на стадии проектирования. При реализации интеграционных web сервисов, вам наверняка придется затратить некоторые усилия на разработку механизмов защищенного хранения клиентских удостоверений и их настройки / редактирования.

Вопросы реализации

Вопросы реализации web сервисов сильно зависят от платформы, с которой вы работаете, а их на сегодняшний день существует великое множество. Только Microsoft предлагает 4 платформы (ASP.NET 1.1, ASP.NET 2.0, WSE 1.0-3.0, WCF-Indigo). В мире Java их еще больше. Поэтому давать конкретные рекомендации весьма затруднительно. Однако есть моменты, на которые следует обратить внимание в любом случае.
Большинство платформ берут на себя формирование WSDL описания сервиса, предоставляя разработчику возможность работать с сервисом как с обычным классом. Поэтому, следует уделять постоянное внимание тем деталям, которые оказывают влияние на формирование правильного WSDL описания и XSD схем данных. К этим вещам относится использование Xml Namespace и префиксов, управление порядком сериализации данных, порядком и стилем генерации WSDL.
Следует стараться отделить бизнес логику от реализации сервиса. Хорошо, если у вас получится использовать единую бизнес логику внутри приложения и в web сервисе. В идеальном случае методы вашего web сервиса будут лишены всякой логики, кроме проверки параметров, формирования результатов и обработки ошибок, как показано на рисунке:

Заключение

Итак, в данной статье мы рассмотрели круг вопросов, связанных с проектированием интеграционных web сервисов.
Мы остановились на общих принципах концепции SOA. Рассмотрели практические вопросы проектирования контракта сервиса, обеспечения его функциональной и синтаксической полноты. Мы уделили внимание влиянию протокола взаимодействия на контракт сервиса. Рассмотрели варианты решения вопросов безопасности web сервисов. И в конце остановились на некоторых практических аспектах проектирования. Я надеюсь, что данная статья будет полезна вам при проектировании интеграционных web сервисов.

ПРОЕКТИРОВАНИЯ НА ОСНОВЕ ТЕХНОЛОГИИ ВЕБ-СЕРВИСОВ

Специальность: 05. 13. 12 – Системы автоматизации проектирования

Санкт Петербург 2013 2

Научный руководитель – доктор технических наук, профессор Дмитревич Геннадий Даниилович

Официальные оппоненты :

«НАУЧНО-ПРОИЗВОДСТВЕННОЕ ОБЪЕДИНЕНИЕ «АВРОРА»,

начальник лаборатории Пахоменков Юрий Михайлович

Ульянова (Ленина) по адресу: 197376, г.Санкт-Петербург, ул. Профессора Попова, д. 5.

С диссертацией можно ознакомиться в библиотеке СПбГЭТУ Автореферат разослан «_» 2013 г.

Ученый секретарь Диссертационного совета Д212.238.02 Н. М. Сафьянников

ОБЩАЯ ХАРАКТЕРИСТИКА РАБОТЫ

приложение консольного типа, приложение оконного типа и вебприложение.

Для достижения поставленной цели следует решить следующие задачи:

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

3. Исследовать и разработать методику построения веб-сервисов Java с использованием технологии сжатия данных.

Новые научные результаты распределенной САПР с использованием веб-сервисов.

Основные положения , выносимые на защиту 1. Архитектура распределенной сервис-ориенировнной САПР на основе веб-сервисов.

2. Общая методика восходящего проектирования веб-сервисов Java 3. Методика реализации программного обеспечения веб-сервисов Java на основе сжатия данных.

Практическая ценность 1. Предложенная структура распределенной САПР обеспечивает возможность организовать взаимодействие между различными вебсервисами на выбранной платформе и адаптировать приложения к изменяющимся условиям проектирования.

2. Построенная библиотека вспомогательных функций на основе сжатия данных повышает эффективность создания программного обеспечения веб-сервисов Java для систем автоматизации схемотехнического проектирования 3. Разработанная методика реализации клиент-серверного взаимодействия обеспечивает работу распределенных САПР в средах гетерогенного типа.

Апробация работы Основные положения диссертации докладывались и обсуждались на следующих конференциях:

1. 9-ая конференция молодых ученых «Навигация и управление движением».– СПб.;

2. 5-ая международная конференция «Приборостроение в экологии и безопасности человека».– СПб., ГУАП;

3. XIII, XIV, XVII -ая международные конференции « Современное образование: содержание, технологии, качество». – СПб., 4. 60, 61, 63-ая научно-технические конференции профессорскопреподавательского состава ГЭТУ.

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

Обзор технологии Web-сервисов. Исследование и разработка методов построения

5.1.1 Основы Web-сервисов

8.1. Основы веб-сервисов

8.3. Стек технологий веб-сервисов

8.4 Взаимодействие с веб-сервисами

8.5. Сервисно-ориентированная архитектура приложений

8.5.1. Основы сервисо-ориентированной архитектуры

8.5.2. Технологии реализации сервисо-ориентированной архитектуры

8.6. Компоновка веб-сервисов

8.7. Веб-сервисы в ASP.Net

Создание веб-сервиса

В обозревателе решений (Solution Explorer ) щелкните правой кнопкой мыши имя созданного веб-сервиса

(http://localhost/TemperatureWebService), а затем выберите команду Добавить новый элемент .

Чтобы создать методы преобразования, выполните следующие действия:

Чтобы протестировать веб-службу, выполните следующие действия:

1. Создайте веб-сайт:

Для создания ссылки на веб-сервис, выполните следующие действия:

Чтобы вызвать методы веб-службы, выполните следующие действия:

Чтобы включить отладку на веб-узле веб-службы, выполните следующие действия:

Чтобы включить отладку на веб-узле, выполните следующие действия:

Обнаружение web-сервисов

8.8. Итоги

«ИССЛЕДОВАНИЕ И РАЗРАБОТКА МЕТОДОВ ПОСТРОЕНИЯ РАСПРЕДЕЛЕННЫХ СИСТЕМ АВТОМАТИЗИРОВАННОГО ПРОЕКТИРОВАНИЯ НА ОСНОВЕ ТЕХНОЛОГ...»

ИССЛЕДОВАНИЕ И РАЗРАБОТКА МЕТОДОВ ПОСТРОЕНИЯ

РАСПРЕДЕЛЕННЫХ СИСТЕМ АВТОМАТИЗИРОВАННОГО

ПРОЕКТИРОВАНИЯ НА ОСНОВЕ ТЕХНОЛОГИИ ВЕБ-СЕРВИСОВ

«НАУЧНО-ПРОИЗВОДСТВЕННОЕ ОБЪЕДИНЕНИЕ «АВРОРА»,

Немного SOA

Проектирование контракта сервиса.

Протокол взаимодействия и его влияние на контракт

Вопросы безопасности

Вопросы реализации

Заключение

ПРОЕКТИРОВАНИЯ НА ОСНОВЕ ТЕХНОЛОГИИ ВЕБ-СЕРВИСОВ

«НАУЧНО-ПРОИЗВОДСТВЕННОЕ ОБЪЕДИНЕНИЕ «АВРОРА»,

Сообщить об опечатке

Текст, который будет отправлен нашим редакторам:

Ваш комментарий (необязательно):