Web-службы

Распределение функций приложений и возможность использования данных за пределами предприятия, на котором они хранятся, — следующий шаг в развитии компонентной технологии. Количество служб, которые разработчики могут интегрировать в свои приложения, настолько велико, что не приходится даже мечтать о том, чтобы создать их все самостоятельно. Рассмотренный нами конкретный пример, — система бронирования Acme (Acme Reservation System), — представляет собой простую службу. Бюро путешествий Acme (Acme Travel Agency), в состав которого входит система бронирования билетов на авиарейсы и система бронирования мест в гостинице, предоставляет клиентам более широкий спектр услуг.
Отдельному производителю не по силам создать для технологии распределенной обработки данных соответствующую инфраструктуру. Это означает, что и дальше будут сосуществовать, как минимум, миры Java, .NET, переносных компьютеров (ноутбуков) и традиционных (унаследованных) систем. К счастью, протоколы TCP/IP (Transmission Control Protocol/Internet Protocol — протокол управления передачей/протокол Internet) и HTTP (Hypertext Transfer Protocol — протокол передачи гипертекстовых файлов) приобрели статус сетевых стандартов. Они могут послужить базисом при попытке организовать взаимодействие неоднородных (гетерогенных) систем. Поскольку протокол передачи гипертекстовых файлов HTTP — протокол текстовый, то имеет смысл описывать взаимодействие таких систем на языке XML (extensible Markup Language — расширяемый язык разметки), который имеет статус промышленного стандарта. В Web-службах протоколы, основанные на языке XML и протоколе передачи гипертекстовых файлов HTTP, используются в качестве промышленных стандартов, которые обеспечивают взаимодействие разнообразных систем.
Web-службы — вторая часть истории распределенной обработки данных (распределенных вычислений) на платформе .NET. Если все приложения и службы, которые должны взаимодействовать, используют общеязыковую среду выполнения CLR (Common Language Runtime), то для организации распределенной обработки данных можно воспользоваться средствами дистанционной обработки, предусмотренными в платформе .NET. Преимущество средств дистанционной обработки, предусмотренных в платформе .NET, состоит в том, что с помощью удаленной сериализации (преобразования в последовательную форму) объектов, можно получить доступ практически к любой структуре данных .NET. В то же время среда, которая не поддерживает платформу .NET, не позволяет обрабатывать все типы данных, имеющиеся в .NET. Следовательно, набор структур данных, передаваемых Web-службами, значительно уже, чем тот, который может быть описан с помощью протоколов, основанных на языке XML. Именно поэтому в Web-службах часто используются протоколы, основанные на языке XML. Поэтому также в версии протокола SOAP (Simple Object Access Protocol — простой протокол доступа к объектам), которая используются Web-службами, и в версии, на базе которой организована удаленная обработка данных в .NET, предусмотрены разные модели программирования. Так, протокол SOAP, используемый в .NET, полностью совместим с общеязыковой средой выполнения CLR (Common Language Runtime). На версию протокола SOAP, посредством которого взаимодействуют Web-службы, накладывают некоторые ограничения стандарты, определяющие способность к взаимодействию.
Как уже было сказано, Web-службы позволяют соединить неоднородные (гетерогенные) системы. Кроме этого, Web-службы позволяют деловым партнерам совместно использовать информацию. С помощью Web-служб можно объединить унаследованные (традиционные) системы с используемыми, не разрабатывая для их соединения специализированного промежуточного программного обеспечения. Использование Web-служб может оказаться полезным даже в пределах одного предприятия, поскольку с их помощью можно объединить информацию, полученную от внутренних и внешних источников. Однако для того, чтобы превратить Web-службы в нечто большее, чем средство разработки распределенных приложений, нужно разработать финансовую и правовую инфраструктуру, а также инфраструктуру, обеспечивающую надежность и безопасность передаваемых данных.

Протоколы

В основе Web-служб используется несколько протоколов: язык XML (extensible Markup Language), пространства имен XML (XML Namespaces), Схема XML (XML Schema), SOAP (Simple Object Access Protocol, простой протокол доступа к объектам) и WSDL (Web Services Description Language, язык описания Web-служб). Некоторые из этих протоколов утверждены Консорциумом W3C в качестве промышленных стандартов. Некоторые же, например WSDL, лишь приобретают широкое распространение и в качестве стандарта еще не признаны.

Язык XML

Язык XML, который принят Консорциумом W3C в качестве промышленного стандарта [Формально, окончательные версии документов, разработанных Консорциумом W3C, называют рекомендациями. Мы же будем называть их стандартами или спецификациями. Документы, разрабатываемые Консорциумом W3C, которые еще не приобрели статус рекомендации, называют именами, присвоенными им Консорциумом W3C: proposed recommendation (предложенная рекомендация), candidate recommendation (претендент на статус рекомендации), last-call working draft (окончательная версия рабочего черновика), working draft (рабочий черновик) и notes (записки). ], описывает структуру документа путем указания связей между базовыми элементами документа. Элементы документа могут содержать описательную информацию, называемую атрибутами. Сами элементы могут содержать другие элементы, т.е. иметь сложную структуру. Поскольку такие документы можно записать в текстовом виде [Но не обязательно в виде текста. Можно построить приложение, используя абстракции, описанные в разработанном Консорциумом W3C документе Information Set (Информационный набор, класс информации, информационное множество, сокращенно Infoset), который имеет статус претендента на рекомендацию (proposed recommendation). Используя такие абстракции, как документ, пространство имен, элемент, символ и атрибут, можно описать иерархию XML-документа, не привязываясь к конкретному формату, в котором хранятся XML-данные. Например, в решениях, предназначенных для переносных систем, естественно использовать более экономный двоичный формат XML-документов, а не представлять их в виде текста. Рекомендация XML Schema (схема XML), была разработана на основе Infoset, и потому в ней не используются синтаксические конструкции с угловыми скобками. Для применения Информационного набора (Information Set) необходимо пространство имен XML (XML Namespeces).], то на языке XML их можно представить в таком виде, который не зависит от используемой платформы и пригоден для передачи по сети. Так как порт 80, используемый протоколом передачи гипертекстовых файлов HTTP, всегда открыт, представленные в текстовом виде данные беспрепятственно проходят через брандмауэры (аппаратно-программные средства сетевой защиты). Ниже приведено описание списка CustomerList (СписокКлиентов), который состоит из нескольких клиентов, в формате XML.
<CustomerList> <Customer>
<FirstName>John</FirstName>
<LastName>Smith</LastName>
<EmailAddress>smith@smith.org</EmailAddress> </Customer> <Customer>
<FirstName>Sally</FirstName>
<LastName>Rutherford</LastName>
<EmailAddress>srutherford@cando.com</EmailAddress> </Customer> </CustomerList>

Пространства имен XML (XML Namespeces)
Множество элементов и атрибутов, которые содержатся в ХМL-документе, называется словарем. Словарь может оказаться очень полезным, если он моделирует многократно используемую информацию. Например, можно создать финансовый или химический словарь. Наличие пространства имен позволяет предотвратить возможные конфликты, так как словарям могут быть присвоены уникальные имена. А благодаря этому словари можно использовать в разных приложениях.
Ниже приведен пример ХМL-документа. Для того чтобы отличить элементы <FirstName> (<Имя>), <LastName> (<Фамилия>) и <EmailAddress> от любых других определений, которые могут описываться тем же тэгом, но при этом иметь другое значение или употребляться в другом контексте, используется атрибут пространства имен, которому принадлежит элемент. Из данного примера можно видеть, что допускается сокращение названия пространства имен. С практической точки зрения очень удобно использовать в документе составные пространства имен.
<CustomerList xmlns:cl= "urn:uuid 28833F1C-CBE4-4042-9B35-BF641DFB35DC">
<cl:FirstName>John</cl:FirstName>
<cl:LastName>Smith</cl:LastName>
<cl:EmailAddress>smith@smith.org</cl:EmailAddress> </CustomerList>
Пространство имен XML идентифицируется с помощью универсального идентификатора ресурса (Uniform Resource Identifier— URI). Универсальным идентификатором ресурса (URI) может выступать унифицированный указатель информационного ресурса (Uniform Resource Locator— URL) или унифицированное имя ресурса (Uniform Resource Name — URN). Они оба определяют уникальное имя. С унифицированными указателями информационного ресурса (URL), которые, по сути, являются адресами Web-узлов, мы уже знакомы. Они уникальны, поскольку присваиваются централизованно ведомством, ответственным за назначение имен. Унифицированное имя ресурса, URN, — это всего лишь уникальная строка. Можно использовать URN, определенное с помощью глобально уникального идентификатора (GUID) [Глобально уникальный идентификатор (Globally Unique Identifier — GUID), представляет собой 128-битовый идентификатор, уникальность которого гарантируется. Глобально уникальные идентификаторы (GUID) широко используются в модели компонентных объектов Microsoft (COM). Свой собственный глобально уникальный идентификатор (GUID) вы можете сгенерировать при помощи сервисной программы guidgen.exe (имеет Windows-интерфейс) или uuidgen. exe (имеет интерфейс командной строки). Эти сервисные программы расположены в каталоге ...\Microsoft Visual Studio.NET\Common7\Tools. ], например urn:uuid:28833F!C-CBE4-4042-9B35-BF641DFB35DC [В данном примере глобально уникальные идентификаторы (GUID) используются из соображений простоты, а также для того, чтобы гарантировать уникальность, а не просто существование самого идентификатора. В реальных системах используются имена на основе унифицированных указателей информационных ресурсов (URL), независимо от того, существуют ли эти унифицированные указатели информационных ресурсов (URL) на самом деле. ]. Универсальный идентификатор ресурса (URI), который идентифицирует пространство имен, не обязан совпадать с идентификатором, обозначающим какой-либо Web-pecypc.

Схема XML (XML schema)
Пространства имен языка XML не приписывают никакой семантики используемым данным. В спецификации XSD (XML Schema Definition — Определение схемы XML) определяется набор базовых типов данных и их смысл, на основе чего можно определять новые типы данных. Другими словами, схема XML присваивает определенный смысл структуре документа. Сама схема описывается средствами языка XML. Приведенный раньше документ CustomerList можно описать следующей схемой:
<schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:cl="http://www.acme.com/CustomerList"
targetNamespace="http://www.acme.com/CustomerList">
<xsd:complexType name="Customer"> <xsd:sequence>
<xsd:element name="FirstName" type="xsd:string" />
<xsd:element name="LastName" type="xsd:string" />
<xsd:element name="EmailAddress" type="xsd:string"/>
</xsd:sequence>
</xsd:complexType>
</schema>
Элемент targetNamespace обозначает имя схемы. В качестве имени используется определенный спецификацией XSD (XML Schema Definition— Определение схемы XML) элемент "string" ("строка"). Спецификация XSD позволяет ограничить диапазон принимаемых значений, указать количество вхождений экземпляра и приписать элементам атрибуты. Сама схема создается средствами языка XML. Как документ, так и связанная с ним схема проверяются на правильность и обрабатываются как обычные XML-документы. Один и тот же документ, интерпретируемый двумя разными схемами, имеет два разных смысла.

Протокол SOAP
С помощью схемы XML можно определить типы используемых данных. Но, кроме этого, необходимо принять еще ряд соглашений о способе передачи данных и их типов по сети. С этой целью протокол SOAP (Simple Object Access Protocol — простой протокол доступа к объектам), использует язык XML. (Иными словами, язык XML сам выступает в качестве протокола.)
Тип данных, передаваемых по протоколу SOAP, определяется с помощью схемы XML. Но протокол SOAP разработан гораздо раньше, чем была завершена работа над спецификацией Схема XML (XML Schema). Поэтому эти две спецификации несколько отличаются. Отличие состоит в следующем. Схема XML описывает иерархическую, или древовидную структуру. Протокол SOAP предназначен для представления объектов, а объекты могут иметь куда более сложные отношения, чем иерархические. Классы, например, могут иметь несколько родительских классов. Как мы увидим дальше, данное отличие проявилось также и в усложнении Web-служб. В данный момент Консорциум W3C пытается согласовать протокол SOAP со Схемой XML (XML Schema).
Протокол SOAP версии 1.1 для передачи данных может использовать не только протокол передачи гипертекстовых файлов HTTP, но и несколько других транспортных протоколов.
Протокол SOAP используется Web-службами различных платформ Microsoft, а не "только в .NET. Компания Microsoft выпустила комплект инструментальных средств SOAP Toolkit (Инструментарий SOAP), с помощью которого можно разрабатывать Web-службы на базе любой Windows-платформы. Но поддержка SOAP встроена в .NET. В состав SOAP Toolkit (Инструментарий SOAP) входит сервисная программа SOAP Trace Utility (Утилита трассировки SOAP), которая особенно полезна при отслеживании обычных и форматированных сообщений, передаваемых по протоколу SOAP.

Язык описания Web-служб WSDL

Объекты содержат описание своего состояния и поведения. Схемы описывают данные. Язык описания Web-служб WSDL (Web Services Description Language) описывает Выходящие в состав Web-службы методы и данные. Вскоре мы рассмотрим простой при-||лер, с помощью которого проиллюстрируем, как создать Web-службу, не используя язык PVSDL. Но если вы хотите, чтобы автоматически создавались классы, вызывающие Web-ьслужбу или Web-службы выполняли действия, которые могут потребовать автоматического вмешательства машины, тогда без языка WSDL не обойтись [Это напоминает библиотеку типов среды Visual Basic 6, которая упрощает программирование в модели Компонентных объектов Microsoft COM. В отличие от библиотеки типов, которая описывает не все rCOM-объекты и интерфейсы, язык WSDL обеспечивает исчерпывающее описание Web-служб. ]. Ибо в противном Ьсяучае составлять и отсылать SOAP-сообщения вам придется вручную. Р Как вы узнаете из следующего примера, протокол SOAP, который описывает формат пересылаемых Web-службами данных, определен в языке WSDL. В данный момент документ Консорциума W3C, описывающий язык WSDL, имеет статус записки (note).

Архитектура Web-службы
Информационный сервер Internet компании Microsoft (Internet Information Server — HIS) взаимодействует как со страницами ASP.NET так и с Web-службами, которые отсыпают ему запросы по протоколу передачи гипертекстовых файлов HTTP. Запросы кодируются как часть унифицированного указателя информационного ресурса (URL) или представляются в виде XML-текста. В ответ на запрос Web-службы информационный сервер Internet (US) создает запрошенный объект. Затем информационный сервер Internet (US) вызывает метод объекта, который обрабатывает соответствующий запрос. Любые возвращаемые данные преобразуются в XML-формат и возвращаются клиенту как ответ по протоколу передачи гипертекстовых файлов HTTP.

Пример Web-службы Add (Сложение)
Чтобы ознакомиться с архитектурой Web-служб, построенных на базе платформы Microsoft .NET, и протоколами, которые они используют, мы рассмотрим простую Web-службу. Она расположена в каталоге SimpleWebService. Web-служба Add (Сложение) складывает два числа. С целью облегчить восприятие материала, мы создадим Web-службу наиболее простым способом и не будем использовать шаблон проекта Web-службы на управляемом C++ (Managed C++ Web Service project template). Максимально упрощая реализацию данной службы, мы воспользуемся шаблоном приложения на основе библиотеки классов управляемого C++ (Managed C++ Class Library). Чтобы запустить пример SimpleWebService на выполнение, следуйте пошаговым инструкциям:
Откройте проект SimpleWebService\WebService\WebService. sin в среде Visual Studio.NET. Постройте решение.
Скопируйте полученный в результате этого файл WebService.dll в каталог Simple-WebService\WebService\bin. Несмотря на то, что все эти действия уже сделаны за вас, желательно, чтобы вы проделали их самостоятельно.
В окне проводника Windows (Windows Explorer) щелкните правой кнопкой мыши на каталоге SimpleWebService\WebService и выберите из контекстного меню команду Properties (Свойства). В окне Properties (Свойства) перейдите на вкладку Web Sharing (Совместное использование в Web). Откройте папку для совместного доступа, указав в качестве псевдоимени SimpleWebService. Чтобы закрыть окно Properties (Свойства), щелкните на ОК.
Просмотрите пример, для чего введите следующий унифицированный указатель информационного ресурса (URL) Http://localhost/Simple\VebService/Add.asmx в адресной строке вашего броузера. Его также можно открыть в среде Visual Studio.NET стандартным способом. Данный проект сконфигурирован так, что при этом запустится Internet Explorer (IE).
Дальше необходимо написать код и сохранить его в файле с расширением asmx в подкаталоге или виртуальном подкаталоге корневого каталога информационного сервера Internet (US). Таким образом мы создали простую Web-службу [По умолчанию корневым каталогом является каталог \metpub\wwwroot. ]. Информационный сервер Internet (US) использует понятие виртуального каталога. Это означает, что каталог, в котором фактически расположены файлы, необходимые информационному серверу Internet (IIS), не обязательно должен на самом деле находиться в корневом каталоге информационного сервера Internet (IIS). Проще всего создать виртуальный каталог следующим образом. Выделите нужный каталог в окне Проводника NT (NT Explorer). Щелкните правой кнопкой мыши на каталоге и выберите из контекстного меню команду Sharing (Совместное использование). Перейдите на вкладку WebSharing (Совместное использование в Web) и создайте на базе данного каталога виртуальный каталог информационного сервера Internet (US).
Файл Add.asmx содержит ссылку на класс Test (Тест), с помощью которого реализована Web-служба. Этот файл нужно разместить в каталоге SimpleWebService.
<%@ WebService Class=Test %>
Файл WebService. h содержит класс Test (Тест), который является производным от класса WebService, принадлежащего пространству имен System: :Web: :Services (Система::Сеть::Службы). Метод, содержащийся в этом классе, может использоваться в качестве метода Web-службы, если он имеет атрибут WebMethod, как показано на примере метода Add (Сложение), реализованного в файле WebService. h.
// WebService.h
fusing <mscorlib.dll>
fusing <System.dll>
fusing <System.Web.dll>
fusing <Systern.EnterpriseServices.dll>
fusing <System.Web.Services.dll>
using namespace System;
// использование пространства имен Система;
using namespace System::Web;
// использование пространства имен Система::Сеть;
using namespace System::Web::Services;
// использование пространства имен Система::Сеть::Службы;
public _gc class Test : public WebService
{
public:
[WebMethod]
long Add(long x, long y) {
return x + y; }
};
Этот файл находится в подкаталоге WebService каталога SimpleWebService данной главы. Создайте на базе каталога WebService виртуальный каталог с псевдоименем (псевдонимом) SimpleWebService [Как указывается в главе 10 "ASP NET и Web-формы", проще всего создать виртуальный каталог с помощью Проводника Windows (Windows Explorer). Щелкните правой кнопкой мыши на нужном каталоге и из контекстного меню выберите команду Properties (Свойства). На вкладке Web Sharing (Совместный доступ в Web), вы можете открыть папку для совместного доступа и присвоить ей псевдоимя (псевдоним). ]. После построения службы Add (Сложение) в виртуальном каталоге WebService создайте каталог bin и скопируйте в него сборку WebService.dll. Информационный сервер Internet (US) автоматически ищет требуемые файлы в этом каталоге.

Просмотр Web-службы Add (Сложение) при помощи броузера
Internet Explorer можно применять в качестве простой клиентской программы, которая использует возможность кодирования запросов к Web-службе в унифицированном указателе информационного ресурса (URL) для метода GET (ПОЛУЧИТЬ) протокола передачи гипертекстовых файлов HTTP Результат просмотра унифицированного указателя информационного ресурса (URL) http://localhost/SimpleWebService/Add.asmx в окне Internet Explorer показан на рис. 11.1

 

Отладка Web-службы Add (Сложение)
Проекты Web-служб отлаживаются аналогично ASP NET-примерам, рассмотренным в предыдущей главе Сначала щелкните правой кнопкой мыши на проекте Web-службы в окне решения (Solution Explorer) и выберите из контекстного меню команду Properties (Свойства). Затем в окне Project Property Page (Страница свойств проекта) выберите команду Configuration Properties (Свойства конфигурации) Теперь выберите команду Debugging (Отладка) и внесите указанные изменения [По вашему усмотрению, вы можете использовать другую программу-клиент ].
• В строке Command (Команда) введите aspnet_wp. ехе
• В строке Attach (Прикрепить) введите Yes (Да)
• В строке HTTP URL (унифицированный указатель информационного ресурса (URL) для протокола передачи гипертекстовых файлов HTTP) введите
http://localhost/SimpleWebService/Add.asmx.
Кроме этого, необходим конфигурационный файл web.config, в котором нужно включить режим отладки Этот файл следует разместить в том же каталоге, в котором находится Web-служба Ниже приведен пример конфигурационного файла
<?xml version="l.О" encoding="utf-8" ?> <configuration>
<system.web>
<compilation debug="true"/>
</system.web> </configuration>
После того как выполните указанные действия, вы сможете отлаживать проекты Web-служб, используя стандартный отладчик среды Visual Studio.NET. Каждый раз после внесения изменений в проект или нового построения проекта не забывайте копировать динамически подключаемую библиотеку (DLL), в которой содержится Web-служба, из каталога проекта в виртуальный каталог Web-службы. Если этого не сделать, информационный сервер Internet (US) будет использовать старую версию Web-службы.

Клиент для Web-службы Add (Сложение)
Безусловно, у вас возникнет желание написать клиентские программы, которые входят в состав распределенного приложения и используют Web-службу. Вскоре мы это сделаем. Пока же в качестве клиента мы будем использовать Internet Explorer. С его помощью мы изучим протокол, который используется для обмена данными с Web-службой. Чтобы начать, введите в адресной строке Internet Explorer следующий унифицированный указатель информационного ресурса (URL):
http: //localhost/SimpleWebService/Add.asmx.
Если вы щелкните на ссылке Add (Сложение), то будет выведена форма, заполнив которую, вы сможете отослать запрос Web-службе Add (Сложение). Вслед за формой, на этой же странице, будет приведено описание различных протоколов, которые протокол передачи гипертекстовых файлов HTTP использует для того, чтобы отослать запрос. В наших целях заслуживают внимания два протокола- HTTP GET и SOAP.
Мы рассмотрим протокол HTTP GET, поскольку именно он используется формой, отображаемой в окне Internet Explorer. В этом протоколе, метки-заполнители, которые заменяются фактическими данными, выделены жирным шрифтом:
GET /SimpleWebService/Add.asmx/Add?x=string&y=string HTTP/1.1 1
Введенные в форму данные кодируются как часть унифицированного указателя информационного ресурса (URL). (Это стандартный способ выполнения запроса с помощью метода GET протокола передачи гипертекстовых файлов HTTP.) Возвращаемые данные имеют следующий формат:
НТТР/1.1 200 ОК
Content-Type: text/xml; charset=utf-8
Content-Length: length
<?xml version="l.0" encoding="utf-8"?> <int xmlns="http://tempuri.org/">int</int>
На рис. 11.2 показана заполненная форма с введенными значениями слагаемых Если теперь щелкнуть на кнопке Invoke (Активизировать), будет вызвана соответствующая Web-служба.
Затем появится окно Internet Explorer, в котором будет отображена часть данных ответа, сгенерированного Web-службой и передаваемого ею по протоколу передачи гипертекстовых файлов HTTP Фактическое возвращаемое значение (результат) содержится среди этих данных
<?xml version="1.0" encoding="utf-8" ?>
<int xmlns="http://tempuri.org/">9</int>
Возвращаемые данные имеют формат, определенный в описании протокола, однако вместо метки-заместителя подставлен ответ (9). Следует обратить внимание, что по протоколу HTTP GET могут передаваться лишь простые типы данных.
Более интересным является протокол SOAP Он кодирует запросы и ответы с помощью метода POST протокола передачи гипертекстовых файлов HTTP Данные, которые фактически передаются в запросе, подставляются вместо меток-заполнителей В листинге метки-заполнители выделены жирным шрифтом
Сначала мы рассмотрим формат запросов протокола SOAP, передаваемых с помощью метода POST протокола передачи гипертекстовых файлов HTTP Первая часть такого запроса содержит набор заголовков, относящийся к протоколу передачи гипертекстовых файлов HTTP В информационной части (в разделе данных) запроса (теле объекта), передаваемого по протоколу передачи гипертекстовых файлов HTTP, содержатся данные Для описания этих данных протокол SOAP использует язык XML Описание данных всегда отделяется от заголовков пустой строкой Заголовок content-length (длина содержимого) определяет длину данных, которая зависит от размера параметров в информационной части (в разделе данных) запроса
Заголовок method (метод) указывает файл, которому будет направлен запрос Здесь также можно указать имя объекта, который будет обрабатывать запрос (конечную точку) В заголовке SOAPAction (SOAP-Действие) указывается имя метода, который вызывается Web-службой, и пространство имен, которому он принадлежит [Читатели, знакомые с моделью компонентных объектов Microsoft (COM), увидят аналогию между описанием методов с помощью пространства имен и определением глобально уникального идентификатора интерфейса (Interface Identifier— IID) с помощью глобально уникального идентификатора (Globally Unique Identifier — GUID) ].
Для описания параметров метода в протоколе SOAP используется язык XML [Аналогом языка описания интерфейсов (Interface Definition Language — IDL), используемого в модели компонентных объектов Microsoft (COM), является язык описания Web-служб (Web Services Description Language — WSDL), который будет рассмотрен несколько позже Протокол SOAP является аналогом сетевого формата NDR (Network Data Representation), который используется в распределенной модели компонентных объектов DCOM (Distributed Component Object Model) Все параллели, которые можно провести между технологией Web стужб и моделью компонентных объектов Microsoft (COM), описаны в статье Дона Бокса (Don Box) A Young Person's Guide to the Simple Object Access Protocol (Руководство для молодого человека по Простому протоколу доступа к объектам) которая появилась в 2000 году в мартовском выпуске собрания документов компании Microsoft MSDN (Microsoft Developer Network)]. В информационной части (теле) SOAP-запроса содержатся параметры, передаваемые вызываемому методу При реальном вызове метода вместо меток-заполнителей int будут подставлены фактические параметры, которые нужно передать методу Web-службы
POST /SimpleWebService/Add.asmx HTTP/1.1
Host: localhost
Content-Type: text/xml; charset=utf-8
Content-Length: length
SOAPAction: "http.//tempuri.org/Add"
<">xml version="l 0" encoding="utf-8'"5>
<soap:Envelope xmlns xsi="http://www.w3 org/2001/XMLSchemainstance"
xmlns:xsd="http.//www.w3.org/2001/XMLSchema"
xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
<soap:Body>
<Add xmlns="http //tempun.org/"> <x>int</x> <y>int</y> </Add>
</soap.Body> </soap:Envelope>
Ниже мы опишем ответ, передаваемый по протоколу SOAP с помощью метода POST протокола передачи гипертекстовых файлов HTTP В ответе метка-заполнитель int замещается фактическим возвращаемым значением
НТТР/1.1 200 ОК
Content-Type: text/xml; charset=utf-8
Content-Length, length
<?xml version="1.0" encoding="utf-8'">>
<soap:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchemainstance"
xmlns:xsd="http.//www.w3 org/2001/XMLSchema"
xmlns soap="http //schemas.xmlsoap org/soap/envelope/">
<soap.Body>
<AddResponse xmlns="http //tempuri org/">
<AddResult>int</AddResult>
</AddResponse>
</soap.Body>
</soap:Envelope>

Язык описания Web-служб (Web Services Description Language — WSDL)
Протокол SOAP описывает передаваемые данные Интерфейс Web-служб он не описывает Данные, передаваемые по протоколу SOAP, можно закодировать и самостоятельно Но лучше для этой цели создать вспомогательные классы (классы-заместители), которые будет использовать программа-клиент Ведь чтобы самостоятельно закодировать данные, необхсцшо знать спецификацию SOAP до мельчайших подробностей и провести синтаксичесий разбор возвращаемого XML-пакета.
Язык WSDl(Web Services Description Language — язык описания Web-служб) предназначен для опиания интерфейса Web-служб. В качестве примера мы опишем с помощью языка WSDL нтерфейс Web-службы SimpleWebService, имеющей один метод Add (Сложение). Ипользовать язык WSDL для описания интерфейса Web-служб, которые для передачи днных используют другие протоколы, а не протокол SOAP, мы не будем. Чтобы увидетюписание на языке WSDL Web-службы SimpleWebService, введите в адресной строе броузера следующий унифицированный указатель информационного ресурса (URL)http: //localhost/SimpleWebService/Add.asmx?WSDL. Описание Web-службы в языке WSDL состоит из нескольких разделов. В разделе <types> (<типы>) опредлены следующие типы:
• Add (Сложение). Описывает данные, передаваемые Web-службе по протоколу SOAP;
• Addresponse. Описывает результаты, возвращаемые Web-службой клиенту по протжолу SOAP.
Тип Add (Сложение) имеет два элемента, каждый из которых встречается лишь один раз. Элементьимеют имена х и у и принадлежат типу long, определенному спецификацией XSD (XMLSchema Definition — Определение схемы XML). Возвращаемый параметр AddResponsecoдepжит один элемент AddResult, который встречается один раз и также принадлеэмт типу long, определенному, как мы уже знаем, в спецификации XSD (XML SchemaDefinition — Определение схемы XML). Обратите внимание, как рассмотренные типы >ке использовались ранее, при описании протокола SOAP.
<types>
<s:elemerz name="Add"> <s: comjl.exType> <s: sequence>
<salement minOccurs="1" maxOccurs="1"
name="x" type="s:int" />
<s:element minOccurs="1" maxOccurs="1"
name="y" type="s:int" />
</s:sequence>
</s:complexType>
</s:element>
<s:element name="AddResponse">
<s:complexType>
<s:sequence>
<s:element minOccurs="1" maxOccurs="1"
name="AddResult" type="s:int" />
</s:sequence>
</s:complexType>
</s :elment>
</types>
В разделе :message> (<сообщение>) описывается использование этих типов в качестве параметре.
<message name="AddSoapIn"> <!-- сообщение -->
<part name="parameters" element="s0:Add" /> <!-- параметры -->
</message> <!-- сообщение -->
<message name="AddSoapOut"> <!-- сообщение -->
<part name="parameters" element="s0:AddResponse" />
<!-- параметры -->
</message> <!-- сообщение -->
В разделе <portType> (тип порта) с Web-службой сопоставляются отдельные Web-методы, которые описаны в элементах <operation> (<действие>). Если бы данная Web-служба использовала большее количество методов, тогда в разделе <portType> (тип порта) было бы больше элементов operation (действие) [Читатели, склонные проводить параллели, увидят здесь аналогию с интерфейсом модели компонентных объектов Microsoft (COM). ]. Операции ввода и вывода каждого метода связаны с соответствующими сообщениями, которые были определены раньше.
<portType name="TestSoap">
<operation name="Add"> <!-- операция -->
<input message="s0:AddSoap!n" />
<output message="s0:AddSoapOut" />
</operation> <!-- операция -->
</portType>
В разделе <binding> (<связывание>) каждому действию ставится в соответствие способ кодирования и протокол передачи данных.
<binding name="TestSoap" type="s0:TestSoap">
<soap:binding
transport="http://sohemas.xmlsoap.org/soap/http"
style="dooument" /> <!-- стиль = "документ" -->
<operation name="Add"> <!-- название операции -->
<soap:operation soapAction="http://tempuri.org/Add" style="document" />
<!-- стиль = "документ -->
<input> <!-- ввод -->
<soap:body use="literal" />
</input> <!-- ввод -->
<output> <!-- вывод -->
<soap:body use="literal" />
</output> <!-- вывод -->
</operation> <!-- операция -->
</binding>
В разделе <service> (<служба>) указывается порт, используемый Web-службой, и адрес, по которому можно активизировать Web-службу.
<service name="Test"> <!-- имя = "Испытание -->
<
port name="ТезtSoap" binding="s0:TestSoap">
<!-- порт -->
<soap:address location=
"http://localhost/SimpleWebService/Add.asmx" />
</port> <!-- порт -->
</service>

Классы-заместители
Сервисная программа Wsdl. exe считывает описание Web-службы на языке WSDL и генерирует класс-заместитель, который формирует SOAP-запрос Web-службы. По умолчанию эта сервисная программа генерирует код класса-заместителя на языке С# [Можно выбрать CS, VB, JS или (в случае доступности) указать реализацию класса System::CodeDom::Compiler::CodeDomProvider (Система::СоёеОот::Компилятор::Сос1еОогпРгоУ1с1ег) на любом языке. ]. Язык C++ в данный момент она не поддерживает. Следовательно, в нашем примере класс-заместитель будет создан на С#. По умолчанию сервисная программа Wsdl. exe использует протокол SOAP [В конфигурационном файле можно указать также протоколы HttpGet, HttpPost или другой специальный протокол.]. В результате выполнения команды, приведенной ниже, будет сгенерирован класс-заместитель addproxy. cs на языке С#.
wsdl /out:addproxy.cs
http://localhost/SimpleWebService/Add.asmx?WSDL
В файле addproxy. cs содержится исходный код класса-заместителя, в котором определен один конструктор и три метода. Конструктор устанавливает унифицированный указатель информационного ресурса (URL) данной Web-службы. Один из трех имеющихся методов реализует синхронный блокирующий вызов Web-службы. С помощью оставшихся двух методов реализован шаблон асинхронного вызова Web-службы, который обсуждался в главе 8 "Классы каркаса .NET Framework". Для асинхронного вызова Web-службы можно использовать методы BeginXXX и EndXXX созданного класса-заместителя [Очевидно, что в данном примере XXX = Add.]. Класс-заместитель имеет имя WebService, т.е. его имя совпадает с именем класса WebService.
Метод Invoke (Активизировать) класса SoapHttpClientProtocol формирует запросы, передаваемые по протоколу передачи гипертекстовых файлов HTTP, и обрабатывает ответы, получаемые по тому же протоколу. Сами же запросы и ответы содержатся в отсылаемых и получаемых SOAP-пакетах. Описанный выше пример класса-заместителя расположен в подкаталоге SimpleAddClient каталога SimpleWebService.
public class Test :
System.Web.Services.Protocols.SoapHttpClientProtocol
// общедоступный класс Испытание:
// Система.Сеть.Службы.Протоколы.SoapHttpClientProtocol
{
public Test ()
{
this.Url =http://localhost/SimpleWebService/Add.asmx";
}
public int Add(int x, int y)
{
object [] results = this.Invoke("Add", // результаты
new object[] {x, y}); return ((int)(results[0]));
}
public System.lAsyncResult BeginAddfint x, int y,
System.AsyncCallback callback, object asyncState)
{
return this.Beginlnvoke("Add",
new object[] {x, y}, callback, asyncState);
}
public int EndAdd(System.lAsyncResult asyncResult)
{
object[] results = this.Endlnvoke(asyncResult) ;
// результаты
return ( (int) (results [0]));
}
}
Немного раньше мы показали, как получить доступ к Web-службе с помощью броузера. Вызов Web-службы с помощью броузера может оказаться полезным на этапе тестирования приложения. Но, как правило, Web-служба взаимодействует со специально разработанной для этого клиентской программой. Можно написать клиентскую программу, которая будет отсылать запрос Web-службе, используя созданные нами классы-заместители. В каталоге SimpleWebService\SimpleAddClient расположен файл Main, cs с кодом клиентской программы. Клиент реализован на языке С#. Язык С# выбран только из соображений удобства, ведь ранее созданные нами классы-заместители также написаны на С#. Клиентская программа отсылает запрос Web-службе. Web-служба вычисляет результат сложения 1 и 2, и возвращает значение 3, которое отображается в окне, представляющем консоль клиентской программы.
public class AddClient
// общедоступный класс AddClient
{
public static void Main(string[] args)
{
Test 2 = new Test();
long f = z.Addd, 2) ;
Console.WriteLine(f) ;
return;
}
}
Смешивать в одном модуле языки С# и C++ нельзя. Если же вы пишите код клиентской программы на C++, его затем нужно скомпилировать и создать выполняемую сборку. Далее следует скомпилировать класс-заместитель, сгенерированный на С#, в результате чего будет получена отдельная сборка (динамически связываемая библиотека (DLL)). Таким образом, чтобы получить доступ к Web-службе, клиентская программа, написанная на C++, использует класс-заместитель, написанный на С#. Мы проиллюстрируем вышеизложенное позже в примере Arithmetic (Арифметика).

Клиент web-службы, использующий необработанные данные SOAP и протокол передачи гипертекстовых файлов HTTP
Чтобы проиллюстрировать возможности класса SoapHttpClientProtocol, окончательный вариант клиентской программы использует сокеты. Сокеты позволяют отсылать как заголовки протокола передачи гипертекстовых файлов HTTP, так и сами данные в формате SOAP, а также получать ответ от Web-служб. Клиентская программа расположена в подкаталоге RawAddClient каталога SimpleWebService.
Сначала главная (main) функция программы читает файл SoapAdd.txt. Этот файл содержит SOAP-заголовки вызываемой Web-службы. Данная функция возвращает длину содержимого, которое фигурирует в соответствующем заголовке запроса, формируемого методом POST протокола передачи гипертекстовых файлов HTTP.
long contentLength = 0;
StringBuilder *contentData =
BuildContent(
"SoapAdd.txt", ScontentLength);
StringBuilder *requestHeader =
BuildHeader(contentLength);
Затем клиентская программа устанавливает связь с сервером, отсылает ему данные и получает от сервера ответ, который выводится на консоль.
IPEndPoint *endPoint =
new IPEndPoint(
dynamic_cast<IPAddress *>
(Dns::Resolve(httpServer)->AddressList->
get_Item(0)),
httpPort);
Socket *sock =
new Socket(
AddressFamily::Internetwork,
SocketType::Stream,
ProtocolType::Tcp);
sock->Connect(endPoint);
...
sock->Send(
header, header->Length, SocketFlags::None);
// заголовок, заголовок-> Длина
sock->Send( // Посылает
content, content->Length, SocketFlags::None);
// содержание, содержание-> Длина
...
bytes = sock->Receive( // Получить
receivedData,
receivedData->Length, // Длина
SocketFlags::None);
Console::WriteLine(
ASCII->GetString(receivedData, 0, bytes));
sock->Close();
...
Функция BuildHeader с помощью метода POST протокола передачи гипертекстовых файлов HTTP формирует стандартный запрос, дополненный заголовком SOAPAction.
StringBuilder *sb = new StringBuilder(1024);
sb->Append( // Добавить в конец
"POST /SimpleWebService/Add.asmx HTTP/1.l\r\n") ;
sb->Append("Host: localhost\r\n"); // Добавить в конец
sb->Append( // Добавить в конец
"Content-Type: text/xml; charset=utf-8\r\n");
String *line = // Строка
String::Format("Content-Length: {0}\r\n", // Строка:: Формат
contentLength.ToString());
sb->Append(line); // Добавить в конец (строка)
sb->Append( // Добавить в конец
"SOAPAction: \"http://tempuri.org/Add\"\r\n") ;
sb->Append("\r\n");; // Добавить в конец
...
Функция BuildContent считывает в буфер содержимое файла и вычисляет размер буфера в байтах.
*contentLength = 0;
String *line; // Строка
while ((line = fileStream->ReadLine()) != 0)
{
sb->Append(line); // Добавляет в конец (строка)
sb->Append("\r\n"); // Добавляет в конец ("\r\n")
*contentLength += line->Length + 2;
// *contentLength + = строка-> Длина + 2;
}
fileStream->Close();
Данные в файле SoapAdd. txt представлены в SOAP-формате. Как и следовало ожидать, этот файл имеет вид, описанный выше. Входные параметры 9 и 3 представляются в соответствии со спецификацией WSDL.
<?xml version="l.О" encoding="utf-8"?>
<soap:Envelope
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
<soap:Body>
<Add xmlns="http://tempuri.org/">
<x>9</x>
<y>3</y>
</Add>
</soap:Body>
</soap:Envelope>
Сначала программа формирует запрос. Для этого используется метод POST протокола передачи гипертекстовых файлов HTTP. Запрос содержит стандартные заголовки протокола передачи гипертекстовых файлов HTTP и дополнительный заголовок SOAPAction. Затем запрос кодируется согласно спецификации SOAP. Вывод программы приведен ниже:
POST /SimpleWebService/Add.asmx HTTP/1.1
Host: localhost
Content-Type: text/xml; charset=utf-8
Content-Length: 355
SOAPAction: "http://tempuri.org/Add"
<?xml version="l.0" encoding="utf-8"?>
<soap:Envelope
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
<soap:Body>
<Add xmlns="http://tempuri.org/">
<x>9</x>
<y>3</y>
</Add>
</soap:Body>
</soap:Envelope>
Затем программа записывает ответ. Ответ, снова-таки, начинается с заголовков протокола передачи гипертекстовых файлов HTTP. За ними следует возвращаемый результат, 12, закодированный в соответствии со спецификацией SOAP.
НТТР/1.1 200 ОК
Server: Microsoft-IIS/5 . О
Date: Tue, 30 Oct 2001 16:49:42 GMT
Cache-Control: private, max-age=0
Content-Type: text/xml; charset=utf-8
Content-Length: 358
<?xml version="l.0" encoding="utf-8"?>
<soap:Envelope
xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/2001/XM LSchema">
<soap:Body>
<AddResponse xmlns="http://tempuri.org/">
<AddResult>12</AddResult>
</AddResponse>
</soap:Body>
</soap:Envelope>

 

Резюме


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

 
На главную | Содержание | < Назад....Вперёд >
С вопросами и предложениями можно обращаться по nicivas@bk.ru. 2013 г. Яндекс.Метрика