Какие технологии применяются для построения архитектуры web сервиса
Перейти к содержимому

Какие технологии применяются для построения архитектуры web сервиса

  • автор:

25. Сервис-ориентированная архитектура (Service-Oriented Architecture, SOA), сервисы, Web-сервисы и Web-службы. Основные технологии Webсервисов, используемые для построения Web-сервисов (XML, SOAP, WSDL, UDDI). Технология вызова сервиса.

Се́рвис-ориенти́рованная архитекту́ра (англ. SOA, service-oriented architecture) — модульный подход к разработке программного обеспечения (в дальнейшем ПО), основанный на использовании сервисов (служб) со стандартизированными интерфейсами, которые иденцифицируются web-адресом.

Сервис-ориентированная архитектура (SOA) представляет собой стиль создания архитектуры ИТ, направленный на превращение бизнеса в ряд связанных сервисов — стандартных бизнес-задач, которые можно при необходимости вызывать через сеть.

Архитектура не привязана к какой-то определённой технологии. Она может быть реализована с использованием широкого спектра технологий, включая такие технологии как REST, RPC, DCOM, CORBA или веб-сервисы.

Для крупных информационных систем уровня предприятия и выше:

  • сокращение издержек при разработке приложений, за счёт упорядочивания процесса разработки;
  • расширение повторного использования кода;
  • независимость от используемых платформ, инструментов, языков разработки;
  • повышение масштабируемости создаваемых систем;
  • улучшение управляемости создаваемых систем.
  • Архитектура, как таковая, не привязана к какой-то определённой технологии.
  • Независимость организации системы от используемой вычислительной платформы (платформ).
  • Независимость организации системы от применяемых языков программирования.
  • Использование сервисов, независимых от конкретных приложений, с единообразными интерфейсами доступа к ним.
  • Организация сервисов как слабосвязанных компонентов для построения систем.

Web-сервисы (Web-службы) это технология, которая позволяет приложениям взаимодействовать друг с другом независимо от платформы, на которой они развернуты, а также от языка программирования, на котором они написаны. Web-cервис — это программный интерфейс, который описывает набор операций, которые могут быть вызваны удаленно по сети посредством стандартизированных XML сообщений.

Основными технологиями, используемые для построения Web-сервисов являются:

  • XML: Extensible Markup Language (расширяемый язык разметки, XML) – это язык разметки, который лежит в основе большинства спецификаций, используемых в Web-сервисах. XML – это исходный язык, с помощью которого можно описать любые данные в структурированном виде, независимо от их представления в конкретном устройстве;
  • SOAP: Simple Object Access Protocol (простой протокол доступа к объектам, SOAP) – это сетевой, транспортный и программный язык, а также не зависимый от платформы протокол, позволяющий клиенту вызвать удаленный сервис. Сообщения имеют формат XML;
  • WSDL: Web Services Description Language (язык описания Web-сервиса, WSDL) – это интерфейс, основанный на XML, а также язык описания реализации. Поставщик сервиса использует WSDL-документ для описания операций, выполняемых Web-сервисом, а также параметров и типов данных, которые она использует. WSDL- документ также содержит информацию для доступа к сервису;
  • WSIL: Web Services Inspection Language (язык обследования Web-сервисов, WSIL) – это спецификация на основе XML, которая позволяет находить Web-сервис без использования UDDI. Тем не менее, WSIL также можно использовать в сочетании с UDDI, т.е. он является не зависимым от UDDI и не подменяет его;
  • UDDI: Universal Description, Discovery, and Integration (универсальное описание, поиск и взаимодействие, UDDI) – это клиентский API, а также серверная реализация на основе SOAP, которые можно использовать для хранения и получения информации о поставщиках сервисов и Web-сервисах

Конспектики

  • by kvckr
  • kvckrr@gmail.com

Веб-сервисы в теории и на практике для начинающих

Прежде всего, веб-сервисы (или веб-службы) — это технология. И как и любая другая технология, они имеют довольно четко очерченную среду применения.

Если посмотреть на веб-сервисы в разрезе стека сетевых протококолов, мы увидим, что это, в классическом случае, не что иное, как еще одна надстройка поверх протокола HTTP.

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

Но и сам Интернет — разнороден, т. е. различные приложения на различных узлах сети функционируют на разных аппаратно-программных платформах, и используют различные технологии и языки.

Чтобы связать все это и предоставить возможность одним приложениям обмениваться данными с другими, и были придуманы веб-сервисы.

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

Именно с появлением веб-сервисов развилась идея SOA — сервис-ориентированной архитектуры веб-приложений (Service Oriented Architecture).

Протоколы веб-сервисов

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

  • SOAP (Simple Object Access Protocol) — по сути это тройка стандартов SOAP/WSDL/UDDI
  • REST (Representational State Transfer)
  • XML-RPC (XML Remote Procedure Call)

На самом деле, SOAP произошел от XML-RPC и является следующей ступенью его развития. В то время как REST — это концепция, в основе которой лежит скорее архитектурный стиль, нежели новая технология, основанный на теории манипуляции объектами CRUD (Create Read Update Delete) в контексте концепций WWW.

Безусловно, существуют и иные протоколы, но, поскольку они не получили широкого распространения, мы остановимся в этом кратком обзоре на двух основных — SOAP и REST. XML-RPC ввиду того, что является несколько «устаревшим», мы рассматривать подробно не будем.

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

SOAP против REST

Проблемы данного противостояния хорошо описаны в статье Леонида Черняка, найденой на портале www.citforum.ru.

По мнению же автора, кратко можно выделить следующее:

SOAP более применим в сложных архитектурах, где взаимодействие с объектами выходит за рамки теории CRUD, а вот в тех приложениях, которые не покидают рамки данной теории, вполне применимым может оказаться именно REST ввиду своей простоты и прозрачности. Действительно, если любым объектам вашего сервиса не нужны более сложные взаимоотношения, кроме: «Создать», «Прочитать», «Изменить», «Удалить» (как правило — в 99% случаев этого достаточно), возможно, именно REST станет правильным выбором. Кроме того, REST по сравнению с SOAP, может оказаться и более производительным, так как не требует затрат на разбор сложных XML команд на сервере (выполняются обычные HTTP запросы — PUT, GET, POST, DELETE). Хотя SOAP, в свою очередь, более надежен и безопасен.

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

Практическое применение веб-сервисов

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

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

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

Этап первый — реализация приложения сбора информации о курсах валют.

Информацию о курсах валют мы будем собирать со страниц сайта НБУ (Национального Банка Украины) ежедневно и складывать в базу данных под управлением СУБД MySQL.

Создадим структуру данных.

Таблица валют (currency):

+-------------+------------------+ | Field | Type | +-------------+------------------+ | code | int(10) unsigned | | charcode | char(3) | | description | varchar(100) | | value | int(10) unsigned | | base | tinyint(1) | +-------------+------------------+

Таблица номиналов обмена (exchange):

+------------+------------------+ | Field | Type | +------------+------------------+ | id | bigint(20) ai | | rate_date | timestamp | | rate_value | float | | code | int(10) unsigned | +------------+------------------+

Для работы с базой данных воспользуемся ORM слоем на базе пакета PHP Doctrine. Реализуем граббер:

класс Grubber (models/Grabber.php):

([A-Z]+)(\d+)(.+?)(\d+\.\d+)/i', $content, $m) == false) < throw new Exception( 'Can not parse data!'); >/** * Preformatting data to return; */ $data = array(); foreach ($m[1] as $k => $code) < $data[] = array( 'code' =>$code, 'charcode' => $m[2][$k], 'value' => $m[3][$k], 'description' => $m[4][$k], 'rate_value' => $m[5][$k] ); > return $data; > public static function run() < $data = self::getData(); /** * Sets default currency if not exists */ if (!Doctrine::getTable( 'Currency')->find( 980)) < $currency = new Currency(); $currency->setCode( 980) ->setCharcode( 'UAH') ->setDescription( 'українська гривня') ->setValue( 1) ->setBase( 1) ->save(); > foreach ($data as $currencyData) < /** * Updating table of currencies with found values */ if (!Doctrine::getTable( 'Currency')->find( $currencyData['code'])) < $currency = new Currency(); $currency->setCode( $currencyData['code']) ->setCharcode( $currencyData['charcode']) ->setDescription( $currencyData['description']) ->setValue( $currencyData['value']) ->setBase( 0) ->save(); > /** * Updating exchange rates */ $date = date( 'Y-m-d 00:00:00'); $exchange = new Exchange(); $exchange->setRateDate( $date) ->setRateValue( $currencyData['rate_value']) ->setCode( $currencyData['code']) ->save(); > > > ?>

и сам граббер (grabber.php):

Теперь заставим наш граббер отрабатывать раз в сутки в 10:00 утра, путем добавления команды запуска граббера в таблицы cron:

0 10 * * * /usr/bin/php /path/to/grabber.php

Все — у нас есть достаточно полезный сервис.

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

Реализация SOAP сервиса

Для реализации веб-сервиса на базе SOAP протокола, мы воспользуемся встроенным пакетом в PHP для работы с SOAP.

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

WSDL (Web Service Definition Language) — представляет из себя XML файл определенного формата. Подробное описание синтаксиса можно найти здесь.

На практике будет удобно воспользоваться функцией автоматической генерации файла, которую предоставляет IDE Zend Studio for Eclipse. Данная функция позволяет генерировать WSDL файл из классов PHP. Поэтому, прежде всего, мы должны написать класс, реализующий функциональность нашего сервиса.

класс CurrencyExchange (models/CurrencyExchange.php):

find( $code); $exchange = $currency->getExchange( $date); return $exchange ? (float)$exchange->getRateValue() : null; > /** * Retrievs all available currencies * * @return array - list of all available currencies */ public function getCurrencyList() < return Doctrine::getTable( 'Currency')->findAll()->toArray(); > > ?>

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

Не пишите в докблоках param void или return void — для WSDL это не критично, но вот при реализации REST доступа к тому-же классу у вас возникнут проблемы.

Теперь в Zend Studio входим в меню File->Export. выбираем PHP->WSDL, добавляем наш класс, прописываем URI-адрес нашего сервиса и создаем WSDL-файл. Результат должен быть примерно таким: http://mikhailstadnik.com/ctws/currency.wsdl

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

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

Реализация же самого сервера не предстваляет теперь никакой сложности:

setClass( 'CurrencyExchange'); $server->handle(); ?>

Вы можете попробовать веб-сервис в работе по адресу: http://mikhailstadnik.com/ctws/
Там же доступен тестовый клиент: http://mikhailstadnik.com/ctws/client.php

Код простейшего клиента может быть таким:

getExchange( 840, date( 'Y-m-d')); ?>

Реализация REST сервиса

REST — это не стандарт и не спецификация, а архитектурный стиль, выстроенный на существующих, хорошо известных и контролируемых консорциумом W3C стандартах, таких, как HTTP, URI (Uniform Resource Identifier), XML и RDF (Resource Description Format). В REST-сервисах акцент сделан на доступ к ресурсам, а не на исполнение удаленных сервисов; в этом их кардинальное отличие от SOAP-сервисов.

И все же удаленный вызов процедур применим и в REST. Он использует методы PUT, GET, POST, DELETE HTTP протокола для манипуляции объектами. Кардинальное отличие его от SOAP в том, что REST остается HTTP-запросом.

Поскольку в PHP пока еще нет реалзации REST, мы воспользуемся Zend Framwork, в который включена реализация как REST клиента, так и REST севера.

Воспользуемся уже готовым классом CurrencyExchange. Напишем сам сервер:

setClass( 'CurrencyExchange'); $server->handle(); ?>

Как видите все очень сходно и просто.

Однако, следует оговорить, что наш REST-сервис менее защищен, чем SOAP-сервис, так как любой добавленый метод в класс CurrencyExchange при его вызове отработает (сам класс определяет сруктуру сервиса).

Проверим работу нашего сервиса. Для этого достаточно передать параметры вызова метода в сроке GET-запроса:

?method=getExchange&code=840&date=2008-11-29
?method=getExchange&arg1=840&arg2=2008-11-29

При желании или необходимости вы можете самомтоятельно задавать структуру ваших XML ответов для сервиса REST. В этом случае, также будет необходимо позаботиться и о создании определения типа вашего XML документа (DTD — Document Type Definition). Это будет минимальным описанием API вашего сервиса.

Простейший тестовый клиент к REST сервису может быть в нашем случае таким:

getExchange( 840, date( 'Y-m-d'))->get(); if ($result->isSuccess()) < echo 'USD exchange: ' . $result->response; > ?>

В принципе, Zend_Rest на сегодняшний день нельзя назвать наиболее точной реализацией принципов REST. Утрируя, можно говорить о том, что эта реализация свелась к удаленному вызову процедур (RPC), хотя философия REST гораздо шире.

Вы можете скачать пример в исходных кодах c PHP Doctrine и Zend Framework (4,42 Мб).

Заключение

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

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

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

Стандарты веб-сервисов для создания распределенных информационных систем Текст научной статьи по специальности «Компьютерные и информационные науки»

Аннотация научной статьи по компьютерным и информационным наукам, автор научной работы — Воронцов Юрий Алексеевич, Козинец Артур Валерьевич

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

i Надоели баннеры? Вы всегда можете отключить рекламу.

Похожие темы научных работ по компьютерным и информационным наукам , автор научной работы — Воронцов Юрий Алексеевич, Козинец Артур Валерьевич

Пример построения web-сервиса Asp. Net

Пример построения распределенной информационной системы на Ajax с использованием php и IIS (Internet information Services)

Архитектура распределенных сервис-ориентированных систем автоматизированного проектирования
Сервисные средства Интернет для решения бизнес-задач
Пример построения web-сервиса с использованием Apache и MySQL
i Не можете найти то, что вам нужно? Попробуйте сервис подбора литературы.
i Надоели баннеры? Вы всегда можете отключить рекламу.

Standards of web-services for building distributed information systems

In the article considered a set of standards used to build distributed information systems . In a narrow sense from the software perspective, a distributed information system is a set of software components with interaction between themselves. Each component can be considered as a software module or application executable as a separate process. The interaction techniques implementation is provided by a family of interactive protocols. The possibility of applying standard protocols UDDI , WSDL and SOAP was described, as well as specificity of their usage.

Текст научной работы на тему «Стандарты веб-сервисов для создания распределенных информационных систем»

Электронный научный журнал «Век качества» ISSN 2500-1841 http: //www .agequal.ru 2015, № 3 http://www.agequal.ru/pdf/2015/AGE QUALITY 3 2015.pdf Ссылка для цитирования этой статьи:

Воронцов Ю.А. Козинец А.В. Стандарты веб-сервисов для создания распределенных информационных систем // Электронный научный журнал «Век качества». 2015. №3. С. 55-72. Режим доступа: http://www.agequal.ru/pdf/2015/315005.pdf (доступ свободный). Загл. с экрана. Яз. рус., англ.

Стандарты веб-сервисов для создания распределенных информационных

Воронцов Юрий Алексеевич

доктор технических наук, профессор,

заведующий кафедрой информационных систем, Московский технический университет связи и информатики 125993, Москва, ул. Народного Ополчения, 32, каб.409а

\voronlsov. 1943@шаИ. ги

Козинец Артур Валерьевич

заведующий лабораториями кафедры информационных систем Московский технический университет связи и информатики 125993, Москва, ул. Народного Ополчения, 32, каб.407

ко2\не1н @т1и €¡2. ги

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

Электронный научный журнал «Век качества» Online scientific journal «Age of Quality»

№ 3 (2015) ISSN 2500-1841

Ключевые слова: распределенные информационные системы; веб-сервисы; веб-службы; JavaScript; UDDI; WSDL; SOAP.

Веб-служба, веб-сервис (англ. web service) — идентифицируемая веб-адресом программная система со стандартизированными интерфейсами [1].

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

Рис. 1. Схема обработки WEB-запроса. Разработано авторами.

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

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

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

Программы на клиентских языках обрабатываются на стороне web-клиента. Как правило, их выполняет (интерпретирует) браузер. Одним из типов программ, предназначенных для выполнения на клиент-машине, являются сценарии, например, JavaScript (VBScript) [3]. Исходный текст сценария представляет собой часть HTML веб-страницы, поэтому сценарий JavaScript передается клиенту вместе с документом, в состав которого он входит. Обрабатывая HTML-документ, браузер обнаруживает исходный текст сценария и запускает его на выполнение. Код скрипта JavaScript размещается непосредственно на HTML-странице. Простой пример:

Это обычный HTML документ.

document-writeC^ это JavaScript!»)

Вновь документ HTML.

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

Это обычный HTML документ. А это JavaScript! Вновь документ HTML.

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

такой программы, сервер запускает ее и передает параметры, входящие в состав запроса. Средства для генерации подобного запроса обычно входят в состав HTML-документа. Результаты своей работы программа оформляет в виде HTML-документа и передает их веб-серверу, а последний, в свою очередь, дополняет полученные данные HTTP-заголовком и передает их клиенту. Этот файл может иметь расширения: HTML, PHP, ASP, ASPX, Perl, SSI, XML, DHTML, XHTML. К серверным языкам программирования можно отнести: PHP [4], Perl [5], Python [6], любой .NET язык программирования (технология ASP.NET [7]).

В отличие от клиентских скриптов, которые выполняются непосредственно при загрузке страницы браузером клиента, серверные скрипты требуют предварительной компиляции. А потому для их выполнения необходимо на сервере установить специальное программное обеспечение (компилятор). К технологиям веб-программирования, предназначенным для создания серверных скриптов, относят PHP, Perl, ASP.NET, Ruby. Среди них наиболее популярными являются технологии PHP и ASP.NET.

Наиболее распространённый способ внедрения серверного JavaScript в HTML-страницу — тэг . Вы можете использовать тэг в любой ситуации; обычно, однако, вместо него используются обратные кавычки, если Вы генерируете имена или значения атрибутов для HTML-страницы.

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

Простой пример приложения:

This time you are

write(request.newname); client.oldname = request.newname;

Enter your name

Получив данный участок кода, машина выполнения генерирует HTML на базе значения request.newname в операторе write. Во втором операторе она просто выполняет операцию JavaScript, присваивая значение request.newname свойству client.oldname. Она не генерирует никакого HTML. Итак, если request.newname будет «Mr. Ed,» машина выполнения генерирует из предыдущего отрывка следующий HTML-фрагмент:

This time you are

Enter your name

Возможности серверных скриптов довольно богаты. Серверные скрипты могут, например, обрабатывать данные с форм, генерировать динамические страницы или отсылать и принимать cookies. С помощью серверных скриптов можно создавать гостевые книги, чаты, опросы, хранить защищенные паролем данные. Также ни один интернет-магазин не обойдется без серверных скриптов. С их помощью пользователь может рассчитать общую стоимость покупки, вносить изменения в свою покупательскую «корзину», фиксировать время и дату заказа и т.п. Кроме того, при помощи серверных скриптов можно создавать целые системы управления сайтом (так называемые «движки») со встроенными визуальными редакторами, форумами и т.п.

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

Рис. 2. Взаимодействие веб-сервера и сервера БД. Разработано

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

Рассмотрим пример. Мы уже подключились к серверу БД, где есть таблица users. Для того чтобы прочитать список пользователей сайта необходимо выполнить SQL-запрос «SELECT * FROM users». Ниже приведен текст скрипта, выполняющего запрос данных о пользователях сайта (идентификатор, логин, адрес электронной почты) и формирование HTML-таблицы на основании полученных данных:

$sql = «SELECT * FROM users»; $result = mysql_query($sql)

while ($row = mysql_fetch_assoc($result))

Распределенная информационная система.

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

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

Рис. 3. Последовательность обмена сообщениями. Разработано

Диаграмма последовательности, соответствующая взаимодействию трех служб, показанному на Рис. 3 представлена на Рис. 4.

Рис. 4. Диаграмма последовательности. Разработано авторами.

Иногда распределенной информационной системой называют такую распределённую систему, в которой функционирует более одного сервера БД [2]. Пример архитектуры такой распределённой клиент-серверной информационной системы представлен на Рис. 5, а архитектура ее комплекса технических средств на Рис. 6.

Представление результата обработки

Рис. 5. Архитектура распределенной ИС. Разработано авторами.

Рис. 6. Архитектура КТС. Разработано авторами.

Примеры задач, для решения которых используются распределенные информационные системы:

• портал государственных услуг;

• электронные торговые площадки;

• доступ к информации о курсах валют;

• сервис предоставления котировки акций;

• сервис поиска минимальной цены;

• сервис проверки номера кредитной карточки;

• сервис проверки недействительных (украденных) документов;

• сервис бронирования авиационных билетов.

Требования, которые выдвигаются при построении распределенных

информационных систем, обычно включают:

• Необходима поддержка неоднородного информационного пространства, в том числе возможность получать данные из разных типов СУБД.

• Нужная информация распределена и хранится на физически разных, географически разнесённых серверах БД.

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

i Не можете найти то, что вам нужно? Попробуйте сервис подбора литературы.

• Запрос на сервис не должен требовать от web-клиента программирования.

Решение задач распределенных информационных систем возможно с использованием Web-сервисов.

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

Веб-служба XML (Web Service XML) — это приложение или блок находящегося на web-cepвере выполняемого кода, функционирование которого основано на применении стандартных форматов XML (SOAP, WSDL, UDDI).

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

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

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

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

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

методов из компонентов, которые принадлежат и поддерживаются независимыми провайдерами.

Веб-сервисы решают задачу интеграции приложений различной природы и построения распределенных ИС. В этом заключается основное принципиальное отличие веб-сервисов от предшественников — технологий взаимодействия [8].

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

TCP/IP — широко распространенный протокол, понимаемый всеми сетевыми устройствами, от мэйнфреймов до смартфонов и планшетов;

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

XML (extensible Markup Language) — расширяемый язык разметки, в настоящее время применяется для работы с любыми типами данных.

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

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

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

• выполняются на стороне сервера;

• предоставляют набор методов, доступных внешним клиентам;

• исполняют веб-методы и возвращают результаты клиентам;

• веб-сервисы и их клиенты могут быть написаны на разных языках и/или разных платформах.

Web-сервисы базируются на трех основных Web-стандартах.

Стандарт SOAP (Simple Object Access Protocol) —это протокол, т. е. набор правил для создания приложений, которые могут вызывать методы удаленных объектов SOAP поставщика сервиса. Где именно находятся эти удаленные объекты — в другом каталоге, где-то в корпоративной интрасети или в Интернете — для клиентских программ, использующих SOAP, абсолютно неважно. SOAP основан на XML. По сути дела, каждая передача информации между клиентом и сервисом является отдельным XML-документом, который написан по правилам SOAP. Спецификация SOAP определяет ХМL «конверт» для передачи сообщений [9], метод для кодирования программных структур данных в формате XML, а также средства связи по протоколу HTTP.

Стандарт WSDL (Web Services Description Language) — язык для описания программных интерфейсов Web-сервисов [10]. Описание может включать протокол, адрес сервера, номер используемого порта, список доступных операций, формат запроса и ответа и т.п.

Стандарт UDDI (Universal Description, Discovery and Integration) — стандарт для индексации Web-сервисов [9]. UDDI задает бизнес-реестр, в котором провайдеры Web-сервисов могут регистрировать сервисы, а разработчики — искать необходимые им сервисы.

На Рис. 7 показано, как эти три стандарта взаимодействуют друг с другом.

Рис. 7. Сценарий работы веб-сервиса. Разработано авторами.

Серверы приложений являются хранилищами Web-сервисов и делают их доступными через протоколы HTTP GET, HTTP POST и НТТР БОДР.

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

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

Существующие Web-сервисы описываются в WSDL-документах, которые располагаются либо на сервере приложений, либо в специальных XML-хранилищах. WSDL-документ может ссылаться на другие WSDL-документы и документы XSD (XML Schema), в которых описаны типы данных, используемые

Web-сервисами. XML-хранилища используются для управления WSDL-документами. Внутри WSDL-документа находится адрес (URL) Web-сервиса. Web-сервисы описаны и проиндексированы в бизнес — реестре, содержащем адреса (URL) WSDL-документов.

Рис. 8. Архитектура SOAP. Разработано авторами.

Сообщения между веб-сервисом и его пользователем пакуются в SOAP-конверты (SOAP envelopes). Сообщения содержат либо запрос на осуществление какого-либо действия, либо ответ — результат выполнения этого действия. Конверт и его содержимое закодировано языком XML, и его достаточно просто понять. Вот как выглядит простой SOAP-запрос, который отправляется через HTPP к веб-сервису:

env:encodi ngStyle=http://www.w3.org/2001/06/soap-encodi ng

Ключевые элементы SOAP-конверта узнать достаточно просто: это два параметра ( («почтовый индекс») и («страна»)), которые содержатся внутри элемента под названием . Этот элемент является названием веб-сервиса, к которому мы обращаемся с запросом. Прочие данные в конверте, такие как кодировка текста и версия SOAP помогают веб-сервису правильно обработать запрос. Ответ будет выглядеть:

env:encodi ngStyle=http://www.w3.org/2001/06/soap-encodi ng

Элемент из запроса поменялся на элемент в ответе на запрос. В этом элементе содержится только один элемент , значение которого обозначает, запрошенный почтовый индекс верен.

1. Википедия — Веб-служба [Электронный ресурс]. — Режим доступа: https://ru.wikipedia.org/wiki/Веб-служба (дата обращения 11.07.15г.).

2. Architecture of user applications for network with mobile nodes / Vorontsov Y.A., Farkhadov M.P., Blinova O.V., Abramenkov A.N. // 18-я международная конференция «Распределенные компьютерные и коммуникационные сети: управление, вычисление, связь» (DCCN-2015). С 460-465.

3. JavaPortal.ru — всё о Java и Javascript: Управление сценариями просмотра Web-страниц [Электронный ресурс]. — Режим доступа: http: //www.j avaportal. ru/j avascript/articles/j suspw. html (дата обращения 11.07.15г.).

4. Opennet: Введение в PHP [Электронный ресурс]. — Режим доступа: http://www.opennet.ru/docs/RUS/php intro/ (дата обращения 11.07.15г.).

5. Opennet: Краткий экскурс в Perl-программирование [Электронный ресурс]. — Режим доступа: http://www.opennet.ru/docs/RUS/perl_help/ (дата обращения 11.07.15г.).

6. Сообщество MoscowPython [Электронный ресурс]. — Режим доступа: https://www.python.ru/ (дата обращения 11.05.15г.).

7. Адам Фримен ASP.NET 4.5 с примерами на C# 5.0 для профессионалов, 5-е издание = Pro ASP.NET 4.5 in C#, 5th Edition. — М.: «Вильямс», 2014. — 1120 с. — ISBN 978-5-8459-1878-9.

8. Anatomy of a Web Service: XML, SOAP and WSDL for Platform-independent Data Exchange [Электронный ресурс]. — Режим доступа: http://www.webreference.com/authoring/web service/index.html (дата обращения 11.07.15г.).

9. IBM developerWorks Россия: Практическое использование Web-сервисов в IBM Lotus Domino [Электронный ресурс]. — Режим доступа: http://www.ibm.com/developerworks/ru/library/web-services1/index.html (дата обращения 11.05.15г.).

10.Хабрахабр — Разработка: Веб-сервисы в теории и на практике для начинающих [Электронный ресурс]. — Режим доступа: https://habrahabr.ru/post/46374/ (дата обращения 11.05.15г.).

Standards of web-services for building distributed information systems

Vorontsov Yuri Alexeevich

Doctor of technics, Professor,

Head of the Department of information systems, Moscow Technical University of Communications and Informatics #32, Narodnogo Opolcheniya street, Moscow, 123993, Russain Federation

Kozinets Arthur Valerievich

Head of laboratories of the Department of information systems Moscow Technical University of Communications and Informatics #32, Narodnogo Opolcheniya street, Moscow, 123993, Russain Federation

Abstract. In the article considered a set of standards used to build distributed information systems. In a narrow sense from the software perspective, a distributed information system is a set of software components with interaction between themselves. Each component can be considered as a software module or application executable as a separate process. The interaction techniques implementation is provided by a family of interactive protocols. The possibility of applying standard protocols UDDI, WSDL and SOAP was described, as well as specificity of their usage.

Key words: distributed information systems; web-services; JavaScript; UDDI; WSDL; SOAP.

1. Vikipediya — Veb-sluzhba [Elektronnyy resurs]. — Rezhim dostupa: https://ru.wikipedia.org/wiki/Veb-sluzhba (data obrashcheniya 11.07.15g.).

2. Architecture of user applications for network with mobile nodes / Vorontsov Y.A., Farkhadov M.P., Blinova O.V., Abramenkov A.N. // 18-ya mezhdunarodnaya konferentsiya «Raspredelennye komp’yuternye i kommunikatsionnye seti: upravlenie, vychislenie, svyaz’» (DCCN-2015). S 460-465.

3. JavaPortal.ru — vse o Java i Javascript: Upravlenie stsenariyami prosmotra Web-stranits [Elektronnyy resurs]. — Rezhim dostupa:

http : //www.j avaportal. ru/j avascript/articles/j suspw. html (data obrashcheniy a 11.07.15g.).

4. Opennet: Vvedenie v PHP [Elektronnyy resurs]. — Rezhim dostupa: http://www.opennet.ru/docs/RUS/php_intro/ (data obrashcheniya 11.07.15g.).

5. Opennet: Kratkiy ekskurs v Perl-programmirovanie [Elektronnyy resurs]. -Rezhim dostupa: http://www.opennet.ru/docs/RUS/perl_help/ (data obrashcheniya 11.07.15g.).

6. Soobshchestvo MoscowPython [Elektronnyy resurs]. — Rezhim dostupa: https://www.python.ru/ (data obrashcheniya 11.05.15g.).

7. Adam Frimen ASP.NET 4.5 s primerami na C# 5.0 dlya professionalov, 5-e izdanie = Pro ASP.NET 4.5 in C#, 5th Edition. — M.: «Vil’yams», 2014. — 1120 s. — ISBN 978-5-8459-1878-9.

8. Anatomy of a Web Service: XML, SOAP and WSDL for Platform-independent Data Exchange [Elektronnyy resurs]. — Rezhim dostupa: http : //www. webreference. com/authoring/web_service/index. html (data obrashcheniya 11.07.15g.).

Технологии для Web-сервисов

В этом обзоре мы рассмотрим основные технологии, на которых базируются Web-сервисы, а также различные дополнения, предлагаемые ведущими производителями и соответствующими органами стандартизации. Мы рассмотрим такие технологии, как eXtensible Markup Language (XML), Simple Object Access Protocol (SOAP), Web Services Description Language (WSDL) и Universal Description, Discovery and Integration (UDDI), а также такие спецификации, как ebXML, XML Digital Signatures, Security Assertions Markup Language, Extensible Key Management Specification, Web Services Flow Language, WS-Inspection, WS-Security, WS-License, WS-Routing и WS-Referral.

Ключевые технологии для Web-сервисов

eb-сервисы базируются на четырех ключевых технологиях: eXtensible Markup Language (XML), Simple Object Access Protocol (SOAP), Web Services Description Language (WSDL) и Universal Description, Discovery and Integration (UDDI). Эти технологии используются для обеспечения функционирования Web-сервисов и связаны между собой так, как показано на следующем рисунке.

Обсуждение ключевых технологий для Web-сервисов мы начнем с протокольного уровня, показанного в нижней части диаграммы. Протокольный уровень содержит стандартные Internet-протоколы, используемые для вызова Web-сервисов по сети. Изначально Web-сервисы базируются на протоколе HTTP/1.1 (или HTTP), но ничто не мешает использовать и другие транспортные протоколы, например SMTP или FTP. Протокол HTTP/1.1 — это текстовый протокол в стиле «запрос-ответ», подразумевающий следующую последовательность действий: клиент открывает соединение с сервером и посылает запрос в специфичном для протокола формате. Сервер отвечает на данный запрос и при необходимости оставляет соединение открытым.

Язык XML

Язык XML играет важную роль в Web-сервисах — он является основой для таких технологий, как SOAP и WSDL, а также определяет формат данных, используемый для обмена информацией между потребителем сервиса и самим сервисом. XML не является языком как таковым — это синтаксис для описания структур данных, мета-язык, позволяющий осуществлять кросс-платформенный обмен данными с помощью стандартных методов для кодирования и форматирования информации. В отличие от HTML, XML позволяет не только описывать структуру информации, но и ее контекст. Посредством XML структуру документа, ее содержимое и способы ее отображения можно представить в виде трех различных компонентов. Таким образом, один и тот же документ может быть отображен различными способами, например в зависимости от типа клиента или от типа запрашиваемого документа. Следует отметить, что все средства создания и потребления Web-сервисов содержат библиотеки для обработки XML-документов. Это могут быть библиотеки, поддерживающие XML Document Object Model (DOM), SAX или, как в случае с .NET Framework, — «pull»-модель для извлечения и обработки информации из XML-документов.

SOAP

SOAP (Simple Object Access Protocol, хотя более актуальным следует считать название Services-Oriented Architecture Protocol) — это основанный на языке XML стандарт для взаимодействия между сервисами и их потребителями. Версия SOAP 1.0 была разработана рядом компаний, таких как Userland, Microsoft и Developmentor, и содержала элементы, специфичные для COM и HTTP, — протокол SOAP обязан своим рождением прототипу XML-RPC, использовавшемуся для реализации удаленных вызовов процедур через XML (http://www.xmlrpc.com/spec/). Предложенная в апреле 2000 года версия SOAP 1.1 (http://www.w3.org/TR/SOAP/) пополнилась вкладом от таких фирм, как IBM и Lotus, и содержала следующие изменения:

  • нейтральность к транспортному уровню (возможно использование не только протокола HTTP);
  • нейтральность к языку программирования и платформе (Java);
  • нейтральность к кодировке данных;
  • полная независимость от компаний;
  • полная независимость от объектных моделей и операционных систем.

В настоящее время развитием протокола SOAP занимается комитет World Wide Web Consortium — в сентябре 2000 года была создана рабочая группа под названием XML Protocol (XMLP), задачей которой является разработка протокола, нейтрального ко всему (транспортному уровню, языку программирования, объектной модели, операционной системе и т.п.), кроме языка XML, используемого для представления данных. Более подробно о деятельности этой группы можно узнать по адресу: http://www.w3.org/2000/xp/Group/. Протокол SOAP 1.2 является текущим рабочим документом комитета W3C (SOAP Version 1.2 Working Draft: 9 July 2001) и в скором времени должен стать рекомендацией. Отметим, что данный протокол будет называться именно SOAP 1.2, а не XML Protocol 1.0.

На сегодняшний день в различной степени готовности находятся стандарты:

  • SOAP Version 1.2 Working Draft: 9 July 2001;
  • XML Protocol Abstract Model Working Draft: 9 July 2001;
  • XML Protocol Requirements Document;
  • SOAP Security Extensions: Digital Signature (http://www.w3.org/TR/SOAP-dsig/);
  • SOAP Messages with Attachments (http://www.w3.org/TR/SOAP-attachments/).

Протокол SOAP базируется на сообщениях, которые разделяются на два типа: запросы (вызов метода удаленного объекта) и ответы (результат работы удаленного метода). SOAP поддерживает два механизма доступа — SOAP RPC и SOAP Message. SOAP RPC представляет собой простой протокол «запрос-ответ» и базируется на объекте Call. Этот объект (и некоторые низкоуровневые методы для создания и отсылки сообщений) используется для синхронного удаленного вызова методов Web-сервисов.

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

Протокол SOAP основан на понятии «конвертов», внутри которых и располагаются сообщения со специфичными для того или иного приложения данными. Ниже показан пример SOAP-запроса, посылаемого потребителем сервиса сервису.

   IBM

В ответ на данный запрос Web-сервис возвращает данные, также упакованные в SOAP-конверт:

   95.25

С точки зрения приложения при использовании SOAP для вызова методов Web-сервисов требуется генерация запроса и обработка XML-документа, содержащего ответ. Мы можем использовать XSLT, SAX, DOM или JDOM для преобразования XML-документа в вид, более подходящий для конкретного приложения. По мере увеличения числа средств для создания и потребления Web-сервисов необходимость в непосредственной обработке XML-документов будет уменьшаться.

WSDL

Интерфейс для доступа к Web-сервису описывается на основанном на языке XML языке Web Services Description Language (WSDL) и содержит всю информацию, необходимую для доступа к данному сервису, — WSDL-документы можно сравнить с описаниями интерфейсов на языке IDL, только в первом случае используется язык XML. WSDL появился как результат объединения двух технологий: Network Accessible Service Specification Language (NASSL) фирмы IBM и Service Description Language (SDL) фирмы Microsoft. Спецификация WSDL 1.1 находится по адресу: http://www.w3.org/TR/wsdl/.

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

WSDL-документ состоит из ряда элементов, описывающих Web-сервис:

  • типы — контейнеры для описания типов данных, базирующиеся на XML Schema;
  • сообщения — абстрактное, типизованное описание способов обмена данными;
  • операции — абстрактное описание действий, поддерживаемых данным Web-сервисом;
  • «порты» — абстрактный набор операций, поддерживаемых одной или более конечными точками;
  • связки — спецификация конкретных протоколов и форматов данных для той или иной конечной точки;
  • сервис — коллекция связанных точек.

С точки зрения WSDL-документа Web-сервис представляет собой коллекцию портов, которые, в свою очередь, являются коллекцией абстрактных операций и сообщений. Абстракция операций и сообщений позволяет связывать их с различными протоколами и форматами данных типа SOAP, HTTP GET/POST или MIME.

Ниже показан пример WSDL-документа для Web-сервиса, предоставляющего всего один метод.

                                Greets the user     Greets the user     Greets the user                                  Basic Web Service Example

Корневым элементом WSDL-документа является элемент , который содержит следующие вложенные элементы:

  • Types — контейнер для описания типов данных, которые представлены в виде описаний XML Schema (XSD);
  • Message — формат для индивидуальной передачи. Каждый метод имеет два типа сообщений — входное и выходное сообщение. Входное сообщение описывает параметры метода, а выходное — возвращаемые методом данные. Средства генерации WSDL-документов фирмы Microsoft, входящие в состав Microsoft .NET, используют следующее соглашение о наименовании сообщений: Имя метода + Протокол + In/Out — например GreetUserSoapIn указывает входное сообщение для протокола SOAP для метода GreetUser;
  • PortType — группа сообщений в виде одной логической операции. Для каждого поддерживаемого Web-сервисом протокола существует отдельный элемент PortType. Все операции определяются элементами , вложенными в элемент PortType;
  • Operation — описание одного действия, поддерживаемого Web-сервисом;
  • Binding — ассоциация элемента PortType с реализацией. Для каждого поддерживаемого Web-сервисом протокола существует отдельный элемент Binding;
  • Service — описание физического местонахождения конечной точки. Для каждого поддерживаемого Web-сервисом протокола существует отдельный элемент Port;
  • Port — описание протокола и формата данных для одной конечной точки;
  • Data Schema — низкоуровневая типизация параметров сообщения.

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

UDDI

И наконец, четвертой технологией, связанной с Web-сервисами, является спецификация Universal Description, Discovery and Integration (UDDI). Задача UDDI — предоставить механизм для публикации информации о Web-сервисах, а также обеспечить поддержку поиска доступных Web-сервисов. В целом UDDI — это регистрационная система, куда входят набор XML-файлов и ассоциированные схемы, которые содержат описания предоставляемых Web-сервисами услуг. В ближайшее время будут доступны различные UDDI-реестры, способные реплицировать данные между собой.

В качестве примера UDDI-реестров можно привести следующие:

  • Реестр фирмы IBM — UDDI Business Registry (https://www-3.ibm.com/services/uddi/protect/registry.html);
  • UDDI-реестр фирмы Microsoft (http://uddi.microsoft.com/default.aspx);
  • UDDI-реестр фирмы Hewlett-Packard (https://uddi.hp.com/uddi/index.jsp).

Версия UDDI 1 была завершена в сентябре 2000 года — в ее разработке принимало участие около 50 компаний, включая IBM, Microsoft Corp, Ariba, Inc., American Express Co и Merrill Lynch & Co, Inc. Стандарт UDDI разделен на три секции, которые облегчают нахождение информации о Web-сервисах:

  • секция «белые страницы» описывает компании и предоставляет контактную информацию и идентификаторы компаний. Поддерживаются такие классификаторы, как North American Industry Classification System (NAICS) и the Standard Industrial Classification (SIC);
  • секция «желтые страницы» содержит список бизнес-категорий, к которым относятся компании, включая разделение по географическим признакам, секторам индустрии и продуктам;
  • секция «зеленые страницы» содержит информацию о том, как выполняются бизнес-транзакции с каждой компанией, включая информацию о бизнес-процессах и форматах данных.

В июне 2001 года UDDI Project, включающий уже более 200 компаний, завершил работу над UDDI 2 — в спецификации этой версии поддерживались следующие расширения:

  • возможность описания комплексных организаций, включая описание структур организаций, подразделений, департаментов, отделов и т.п.;
  • улучшенная поддержка международных организаций, в том числе мультиязычная поддержка описаний продуктов и сервисов;
  • добавлены дополнительные категории и идентификационные схемы. Корпорации могут использовать специфичные для сегментов рынка категории и идентификаторы для описания продуктов и сервисов;
  • более надежные средства поиска, поддержка большего числа параметров поиска, комбинаций критериев поиска;
  • более удобные средства моделирования бизнес-процессов;
  • помимо этого в UDDI 2 расширена возможность репликации глобальных реестров, и компании HP, IBM и Microsoft объявили о реализации полной поддержки этих возможностей к середине текущего года.

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

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

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

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

  • http://uddi.microsoft.com/inquire/;
  • http://www-3.ibm.com/services/uddi/inquiryapi/.

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

Для вызова функций API мы посылаем SOAP-сообщения с определенным содержимым параметров. Например, для поиска компании ABC Supply мы должны послать следующее SOAP-сообщение:

 ABC Supply

SOAP-ответ от UDDI-реестра содержит все компании, соответствующие критерию запроса, а также реализуемые ими сервисы. Эта информация возвращается в виде XML-структуры, называемой businessInfos. Помимо этой структуры UDDI API использует и другие структуры данных — наиболее важные из них показаны выше.

Структура businessEntity представляет данные о компании и содержит набор структур businessService, описывающих сервисы, предоставляемые данной компанией. Каждый сервис может быть доступен различными способами. Например, это может быть Web-сервис, управляемый SOAP-сообщениями, Web-форма или просто телефонный номер. Для того чтобы описать способы доступа к сервису, используется структура bindingTemplate, которая связана со структурой tModel.

Более подробно о протоколе UDDI и поддерживаемых им API и структурах данных можно узнать по адресу: http://www.uddi.org/.

Дополнительные стандарты и технологии для Web-сервисов

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

ebXML

ebXML (Electronic Business using eXtensible Markup Language) — это совместный проект UN-CEFACT и OASIS, представляющий собой описание открытой, основанной на XML инфраструктуры для обеспечения возможностей глобального использования электронной бизнес-информации.

XML Digital Signatures (XML-DSIG)

XML-DSIG — это совместный проект W3C и IETF, в котором описаны правила и синтаксис для создания цифровых подписей в XML-документах.

Дополнительная информация доступна по адресу: http://www.w3.org/TR/xmldsig-core/.

Security Assertions Markup Language (SAML)

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

Extensible Key Management Specification (XKMS)

XKMS устанавливает протоколы для определения и регистрации ключей и использования их в составе XML-документов.

Дополнительная информация доступна по адресу: http://www.w3.org/TR/xkms/.

Web Services Flow Language (WSFL)

WSFL — это язык, позволяющий указать, каким образом Web-сервисы могут быть объединены для описания бизнес-процессов.

Помимо этого следует упомянуть архитектуру Global XML Web Services Architecture (http://msdn.microsoft.com/webservices/), предлагаемую Microsoft и IBM и базирующуюся на спецификациях:

  • WS-Inspection — XML-формат для поиска доступных сервисов на том или ином узле. Дополнительная информация доступна по адресу: http://msdn.microsoft.com/ws/2001/10/Inspection/;
  • WS-Security — расширение SOAP, описывающее, как в состав SOAP-сообщений должны интегрироваться цифровые подписи и как должна обеспечиваться поддержка ключей и криптографии. Эта спецификация была разработана Microsoft, IBM и VeriSign, Inc., и ее первая версия была опубликована в апреле нынешнего года. Дополнительная информация доступна по адресу: http://msdn.microsoft.com/library/en-us/dnglobspec/html/ws-security.asp;
  • WS-License — описывает, как можно использовать стандартные форматы лицензий (сертификаты X.509, Kerberos и т.п) совместно с WS-Security. Дополнительная информация доступна по адресу: http://msdn.microsoft.com/library/en-us/dnglobspec/html/ws-license.asp;
  • WS-Routing — расширение SOAP для посылки асинхронных сообщений по протоколам TCP, UDP, HTTP. Дополнительная информация доступна по адресу: http://msdn.microsoft.com/library/en-us/dnglobspec/html/ws-routing.asp;
  • WS-Referral — расширение SOAP для перенаправления сообщений с динамической конфигурацией. Это расширение позволяет, например, эффективно переложить часть или всю обработку запроса на другие сервисы. Дополнительная информация доступна по адресу: http://msdn.microsoft.com/library/en-us/dnglobspec/html/ws-referral.asp.

Заключение

этом обзоре мы рассмотрели ключевые технологии для Web-сервисов — eXtensible Markup Language (XML), Simple Object Access Protocol (SOAP), Web Services Description Language (WSDL) и Universal Description, Discovery and Integration (UDDI), познакомились с их назначением и получили представление об их роли в жизнеобеспечении Web-сервисов. Мы также рассказали о дополнительных стандартах и технологиях, связанных с Web-сервисами, и привели их краткие описания.

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

  • ПК и комплектующие
    • Настольные ПК и моноблоки
    • Портативные ПК
    • Серверы
    • Материнские платы
    • Корпуса
    • Блоки питания
    • Оперативная память
    • Процессоры
    • Графические адаптеры
    • Жесткие диски и SSD
    • Оптические приводы и носители
    • Звуковые карты
    • ТВ-тюнеры
    • Контроллеры
    • Системы охлаждения ПК
    • Моддинг
    • Аксессуары для ноутбуков
    • Принтеры, сканеры, МФУ
    • Мониторы и проекторы
    • Устройства ввода
    • Внешние накопители
    • Акустические системы, гарнитуры, наушники
    • ИБП
    • Веб-камеры
    • KVM-оборудование
    • Сетевые медиаплееры
    • HTPC и мини-компьютеры
    • ТВ и системы домашнего кинотеатра
    • Технология DLNA
    • Средства управления домашней техникой
    • Планшеты
    • Смартфоны
    • Портативные накопители
    • Электронные ридеры
    • Портативные медиаплееры
    • GPS-навигаторы и трекеры
    • Носимые гаджеты
    • Автомобильные информационно-развлекательные системы
    • Зарядные устройства
    • Аксессуары для мобильных устройств
    • Цифровые фотоаппараты и оптика
    • Видеокамеры
    • Фотоаксессуары
    • Обработка фотографий
    • Монтаж видео
    • Операционные системы
    • Средства разработки
    • Офисные программы
    • Средства тестирования, мониторинга и диагностики
    • Полезные утилиты
    • Графические редакторы
    • Средства 3D-моделирования
    • Веб-браузеры
    • Поисковые системы
    • Социальные сети
    • «Облачные» сервисы
    • Сервисы для обмена сообщениями и конференц-связи
    • Разработка веб-сайтов
    • Мобильный интернет
    • Полезные инструменты
    • Средства защиты от вредоносного ПО
    • Средства управления доступом
    • Защита данных
    • Проводные сети
    • Беспроводные сети
    • Сетевая инфраструктура
    • Сотовая связь
    • IP-телефония
    • NAS-накопители
    • Средства управления сетями
    • Средства удаленного доступа
    • Системная интеграция
    • Проекты в области образования
    • Электронный документооборот
    • «Облачные» сервисы для бизнеса
    • Технологии виртуализации
    1999 1 2 3 4 5 6 7 8 9 10 11 12
    2000 1 2 3 4 5 6 7 8 9 10 11 12
    2001 1 2 3 4 5 6 7 8 9 10 11 12
    2002 1 2 3 4 5 6 7 8 9 10 11 12
    2003 1 2 3 4 5 6 7 8 9 10 11 12
    2004 1 2 3 4 5 6 7 8 9 10 11 12
    2005 1 2 3 4 5 6 7 8 9 10 11 12
    2006 1 2 3 4 5 6 7 8 9 10 11 12
    2007 1 2 3 4 5 6 7 8 9 10 11 12
    2008 1 2 3 4 5 6 7 8 9 10 11 12
    2009 1 2 3 4 5 6 7 8 9 10 11 12
    2010 1 2 3 4 5 6 7 8 9 10 11 12
    2011 1 2 3 4 5 6 7 8 9 10 11 12
    2012 1 2 3 4 5 6 7 8 9 10 11 12
    2013 1 2 3 4 5 6 7 8 9 10 11 12
    Похожие публикации:
    1. Как обновить яндекс в опере gx
    2. Как один слой наложить на другой в фотошопе
    3. Как получить таблицу с сайта python
    4. Как сделать больше ярлыков в гугл хром

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *