| СТАТЬЯ |
22.11.02
|
© Хартвиг Ганзер, инженер отдела продаж, Borland
Переведено БНТП по заказу
Interface Ltd.
Сегодня много внимания уделяется веб-сервисам. При этом почти в каждой компании создается свое, собственное определение для этого понятия, хотя все они схожи между собой. Эта статья начинается с исторического обзора распределенного программирования. Цель данного обзора - показать, что веб-сервисы являются не повторным "изобретением колеса", а новым шагом в развитии этой технологии.
Затем представлен обзор веб-сервисов, а также их формальное определение. При этом вместо создания еще одного нового определения веб-сервисов обсуждается определение, опубликованное на сайте WebServices.org. В заключительной части статьи объясняются три основные технологии, используемые при работе с веб-сервисами: SOAP, WSDL и UDDI.
В различных главах документа эти технологии применяются к одному примеру, представляющему собой функцию, которая возвращает сокращенное обозначение для названия заданной компании.
Этот документ полезен для руководителей, нуждающихся в развернутой презентации веб-сервисов, а также для разработчиков, которым необходимы технические подробности. Поскольку технологии SOAP, WSDL и UDDI имеют в своей основе стандарт XML, у читателя должны быть определенные базовые представления о том, что представляет собой этот язык, его схемы и пространства имен. В разделе со справочной информацией в конце документа указано, где можно найти соответствующую информацию.
Парадигма распределенных вычислений возникла одновременно с появлением компьютерных сетей. Приложения были поделены на две части: первая, клиентская, инициировала распределенные операции, а вторая, серверная, обеспечивала их выполнение. Такая децентрализация снижала вероятность возникновения узких мест, распределяя рабочую нагрузку между несколькими системами. Также обеспечивалась гибкость дизайна приложений, которая была недоступна раньше, в эпоху централизованных сетевых узлов (хостов). Но в такой двухзвенной архитектуре имелись и свои ограничения. Для решения проблем связанных с отказоустойчивостью и масштабируемостью был предложена трехзвенная модель, разделяющая приложения на презентационную часть (промежуточное звено, содержащее бизнес-логику) и третье звено, непосредственно связанное с данными. Такая модель распределения стала наиболее популярным способом разделения приложений. Она позволила сделать прикладные системы масштабируемыми. Основой для взаимодействия между распределенными частями приложения в ней являются вызовы удаленных процедур (RPC). Чтобы избавить разработчиков от выполнения заданий нижнего уровня, например, от преобразования данных или от их побайтового упорядочивания на различных машинах, на рынок был выпущено программное обеспечение нового уровня. Это промежуточное ПО скрывает различия между типами сетевых узлов. Оно размещается над операционными системами и сетевыми службами, установленными на этих хостах, обслуживая находящиеся на более высоком уровне приложения.
Первые промежуточные программные продукты, например DCE, основывались на модели процедурного программирования. Им на смену пришла объектно-ориентированная модель, реализуемая в промежуточных программных продуктах CORBA, DCOM или RMI, которые являются наиболее популярным программным обеспечением этого класса в настоящее время.
Как уже обсуждалось ранее, существует три основных технологии промежуточного программного обеспечения: DCOM, CORBA и RMI. Каждая из них имеет свои преимущества и недостатки. В этой главе осуждаются только основные возможности, без углубления в подробности этих технологий. Это обеспечит представление о том, как веб-сервисы вписываются в общую картину.
CORBA представляет собой основанное на открытых стандартах решение для выполнения распределенных вычислений. Промышленный консорциум OMG (группа по развитию стандартов управления программными объектами) разработал спецификацию для CORBA и определил протокол Internet InterORB Protocol (IIOP), являющийся стандартным протоколом коммуникации между диспетчерами объектных запросов ORB (Object Request Brokers).
Основное преимущество CORBA состоит в том, что и клиенты, и серверы могут быть написаны на любом языке программирования. Это становится возможным, поскольку объекты определяются с высоким уровнем абстракции, обеспечиваемым языком определения интерфейса IDL (Interface Definition Language). После того, как определение будет выполнено в IDL-файле, компилятор обеспечивает его преобразование в определенный язык программирования. Взаимодействия между объектами, клиентами и серверами обрабатываются с помощью диспетчеров объектных запросов ORB. Если от распределенного приложения требуется высокая производительность, тогда CORBA является лучшим выбором промежуточного программного обеспечения. Однако написание распределенных приложений с помощью CORBA - это очень сложная задача. Для того чтобы обеспечить преобразование IDL на различные языки программирования, приходится ограничиваться теми базовыми концепциями, которые реализованы в поддерживаемых языках. Таким образом, IDL является для них чем-то вроде общего знаменателя.
Для охвата различных областей применения CORBA использует так называемые "сервисы". Это сильно утяжеляет спецификацию, делает ее очень сложной. Кроме того, до сих пор поставщиками выпущен относительно небольшой набор таких сервисов.
Чтобы обеспечить взаимодействие между клиентскими и серверными объектами, диспетчеры объектных запросов должны размещаться по обе стороны такого соединения.
Технология вызова удаленных методов RMI (Remote Method Invocation) позволяет создавать распределенные приложения Java-to-Java. В них методы удаленных Java-объектов могут вызываться из других виртуальных машин Java (JVM), наиболее вероятно находящихся на различных узлах сети. Java-программа может выполнить вызов удаленного объекта после получения на него ссылки, либо выполнив поиск удаленного объекта в самозагружаемом пространстве имен, предлагаемом RMI, либо получив ссылку в качестве аргумента или возвращаемого значения. Клиент может вызвать удаленный объект на сервере. Этот сервер в свою очередь тоже может быть клиентом для других удаленных объектов. RMI использует сериализацию объектов, чтобы упорядочить и разупорядочить их параметры и предотвратить усечение типов, поддерживая подлинный объектно-ориентированный полиморфизм. Для коммуникаций используется протокол JRMP (Java Remote Method Protocol).
Программирование с использованием RMI не вызывает проблем, если разработчик приобрел определенный опыт создания распределенных приложений и программирования на языке Java. При этом не требуется использование абстрактных языков (таких как IDL) для описания удаленного серверного объекта. Кроме того, RMI поддерживает распределенный механизм регенерации освобождаемой памяти.
С другой стороны, для использования этой технологии необходимо наличие Java-машин на обеих сторонах соединения. Благодаря относительной простоте этого промежуточного ПО, его удобно и легко использовать. При этом не создается никаких сервисов, как это было в случае с CORBA. Все эти аспекты должны учитываться разработчиками.
Технология DCOM (Microsoft Distributed Component Object Model) позволяет осуществлять вызовы удаленных объектов с помощью звена, надстраиваемого поверх механизма DCE RPC и взаимодействующего с оперативными COM-сервисами. Сервер DCOM публикует свои методы для клиентов, поддерживая различные интерфейсы. Они пишутся на языке IDL, схожем с C++. Данный компилятор IDL создает модули доступа (заместители), заглушки и скелетные элементы программы так же, как это делает IDL-компилятор CORBA, но регистрирует их также в системном реестре. Кроме этого создаются библиотеки типов. Они представляют собой файлы, в которых описываются удаленные объекты и указывается, какие из них могут запрашиваться интерфейсами, обеспечиваемыми механизмом COM.
Для этого используется протокол вызовов удаленных объектных процедур ORPC (Object Remote Procedure Call).
Спецификация DCOM на двоичном уровне позволяет использовать различные языки для программирования серверных объектов.
Также как и RMI, технология DCOM поддерживает распределенный механизм регенерации памяти, освобождаемой удаленными серверными объектами. Это достигается благодаря использованию механизма опроса, проверяющего, по-прежнему ли активно подключение клиента. На серверной стороне для клиентов поддерживается соответствующий счетчик ссылок. Если показываемое им значение сокращается до нуля, происходит освобождение ресурсов, занимаемых объектом.
Большинство пользователей связывают технологию DCOM с операционными системами Microsoft. Однако уже существуют портированные версии DCOM для Unix, VMS и Apple Macintosh.
Как было показано в предыдущем разделе, все эти три технологии использования промежуточного ПО работают по одному схожему сценарию. Их отличия проявляются, прежде всего, в разных поддерживаемых возможностях, а также в уровне сложности. Все они приводят к установлению надежного соединения клиента с сервером, поэтому любое из вышеперечисленных промежуточных ПО пригодно для использования. Из-за различия в протоколах нельзя осуществить вызов DCOM-сервера из RMI-клиента. (Одним из шагов по решению этой проблемы является обращение к механизму, вызывающему RMI поверх IIOP, который используется при разработке с применением Enterprise JavaBeans). При этом устанавливается соединение по принципу "от точки к точке".
Следует также упомянуть, что данное промежуточное программное обеспечение обычно используется для интранет-приложений и организовать его работу через брандмауэр весьма проблематично. Для подключения к серверу за брандмауэром все эти технологии предусматривают механизм HTTP-туннелирования.
В этом разделе описываются веб-сервисы и то, как они соотносятся с традиционным промежуточным программным обеспечением. После короткого обзора будет представлено три фундаментальных составляющих веб-сервисов: SOAP, WSDL и UDDI.
Условно говоря, веб-сервисами называют приложения, которые могут быть опубликованы, обнаружены и запущены с помощью Интернет. Классическими примерами веб-сервисов являются:
Для выполнения своих задач одни веб-сервисы могут использовать другие веб-сервисы.
Поэтому различий между веб-сервисом и сервером для распределенного приложения не существует. Разницу можно обнаружить глубже, на уровнях, где выполняется логика приложений и происходит обработка данных.
Эти упомянутые в заключении к предыдущей главе моменты являются наиболее важными причинами того, почему это промежуточное программное обеспечение нельзя рассматривать как веб-сервисы. В Интернете, где как на серверной, так и на клиентской стороне могут быть гетерогенные среды, никогда заранее неизвестно, какого типа промежуточное ПО использует каждая из соединяющихся сторон. Поэтому для реализации веб-сервисов требуется принципиально новый подход.
В качестве формальной предпосылки приведем определение, опубликованное на сайте WebServices.org:
"Веб-сервисы - это выделенные в самостоятельный элемент, слабосвязанные сжатые функции, предлагаемые по стандартным протоколам",
где:
Согласно традиционным представлениям клиент-серверного подхода существовал сервер, предлагающий какие-либо функциональные возможности, которые могли быть использованы или вызваны клиентом. Механизм, похожий на поисковую службу, исполнял роль агента между этими клиентом и сервером.
Поскольку веб-сервисы представляют просто еще одну парадигму для распределенных приложений, они состоят их тех же самых трех компонентов:
Следующий рисунок иллюстрирует отношения между компонентами веб-сервисов.
|
Подписи к рисунку
|
|
| Service Broker | Сервисный агент |
| Inquire | Запрос |
| Publish | Публикация |
| Internet | Интернет |
| Service Requester | Инициатор сервисного запроса |
| Service Provider | Поставщик сервисов |
| Bind | Соединение |
Промежуточное программное обеспечение, обсуждавшееся до сих пор, использовалось в качестве двоичного протокола связи. Однако веб-сервисы используют XML поверх протокола HTTP. Поэтому не возникает никаких проблем при работе через брандмауэры, поскольку они обычно не блокируют порт HTTP. Если вернуться к определению, можно заметить, что веб-сервисы не обязательно должны использовать только HTTP. В качестве альтернативы могут быть рассмотрены протоколы FTP и SMTP.
XML является общепризнанным форматом обмена данными и соответствующей им семантики. Он является фундаментальным конструктивным элементом практически всех остальных уровней, используемых при создании веб-сервисов.
Вместе эти уровни образуют так называемый стек веб-сервисов, состоящий из следующих частей:
Показанная выше картина ни в коей мере не является законченной. Отображенные на ней уровни образуют основание, которое позволяет разрабатывать веб-сервисы, которые в соответствии с их формальным определением состоят из трех сервисных компонентов.
В следующих разделах будут подробно объясняться именно эти лежащие поверх XML уровни.
Поскольку веб-сервисы будут выполняться в гетерогенных средах, протоколы, используемые для переноса данных между функциями, должны быть независимы от среды выполнения. SOAP - это протокол, обладающий такими свойствами.
Сам по себе он не определяет ни семантику приложения, такую как модель программирования, ни семантику, зависящую от реализации, т.е. распределенный механизм регенерации освобождаемой памяти. Он скорее задает простейший механизм выражения семантики приложения, обеспечивая создание модели модульной компоновки и механизмов кодирования, для преобразования данных внутри модулей.
В сообщении SOAP в качестве корневого элемента содержится тег ENVELOPE (на русский язык его можно перевести как "конверт"). Этот конверт содержит два элемента:
Такой заголовок может содержать набор так называемых строк заголовка, которые можно использовать для предоставления информации, например, при аутентификации или кодировании данных.
Кроме того, два атрибута заголовка предназначены для предоставления информации о том, как должен обрабатывать сообщение SOAP его получатель:
Этот атрибут может использоваться для указания получателя определенной строки заголовка. Этим получателем не должен быть кто-либо, кроме конечного получателя. Даже если сообщение SOAP на своем пути к нему прошло несколько промежуточных получателей. Если сообщение содержит строки заголовка, вложенные для промежуточного получателя, последнему запрещается передавать такую строку заголовка кому- либо из последующих получателей. Однако при этом не запрещено добавлять любые дополнительные строки заголовков.
Добавляя этот атрибут со значением "1" к строке заголовка, можно заставить получателя выполнить обработку данной строки. Таким образом, можно обеспечить должное внимание данной сроке.
Если атрибут не указывается, то семантика имеет тот же вид, как если бы для него было задано значение "0".
Все строки заголовка должны получать названия согласно пространству имен.
Кроме того, пространства имен для конверта и стиль кодирования (encodingStyle) определяются в рамках спецификации SOAP.
Основная часть содержит информацию для последнего из получателей в порядке их следования. Эта информация включена в строки основной части. Если конверт содержит заголовок, основная часть не должна быть первым элементом внутри этого конверта. Строки основной части могут называться в соответствии с пространством имен.
Спецификация определяет одну строку основной части, которая используется для переноса информации об ошибке или статусе, связанной с этим сообщением. В сообщении SOA может быть только одна такая строка. Все остальные описания элемента <fault> будут даны в конце данной главы.
В данной главе будет показано использование SOAP для одной, конкретной функции. В Java это будет выглядеть следующим образом.
public String getSymbol ( String company );
Эта функция получает на входе один параметр, обозначающий название компании. На выходе возвращается строка, показывающая символ, который используется для получения курса акций.
На следующем рисунке показано, какие элементы обязательно должны содержаться в сообщении SOAP, чтобы оно описывало рассматриваемую функцию.
<Envelope>
<Body>
<GetSymbol>
<Company>
Borland
</Company>
</GetSymbol>
</Body>
</Envelope>
Хотя этот пример был создан в соответствии со спецификацией, он не содержит достаточного объема информации, чтобы выполняться как RPC-вызов, например, в нем не указан тип параметра.
Инкапсуляция RPC-вызовов является важнейшим аспектом использования SOAP. С этой целью в спецификации определяются глобальные атрибуты, называемые "стилем кодирования" (encodingStyle), которые используются для сериализации данных и, таким образом, могут применяться для их упорядочивания при RPC-вызовах. Они могут появляться в любом элементе. Дочерние элементы, не имеющие своего собственного атрибута encodingStyle, попадают под действие стиля кодирования ближайшего к ним в иерархии родительского элемента. Хотя правил кодирования данных, задаваемых спецификацией схемы XML, было бы достаточно, SOAP использует подмножество этих правил.
Подобно языкам программирования в SOAP определяются простые типы данных (такие как short, int, float), а также строковые, перечислимые, составные типы данных и массивы. Каждый элемент составных типов также содержит свой тип данных. Эти типы адаптируются из спецификации схемы XML (см. ссылку в разделе справочной информации).
RPC-вызовы кодируются в основной части сообщения. Чтобы вызвать метод, необходимы следующие данные:
URI вызываемого объекта не указывается в рамках конверта сообщения. Это выполняется при установлении связи по протоколу. Если в качестве основного используется протокол HTTP, то запрашиваемый им URI определяет целевой объект.
Каждый из методов SOAP содержит только один вызов метода. Вызов, описываемый составным типом данных, имеет такое же название, что и данный метод. Для каждого параметра, имеющего такое же имя и тип, что и указанный параметр, существует "средство доступа". Порядок параметров должен быть таким же, как и в указанной функции.
Таким образом, чтобы рассматриваемый простейший пример являлся RPC, он должен выглядеть следующим образом. В него внесены улучшения с помощью пространств имен.
<SOAP-ENV:Envelope
xmlns:SOAP-ENV=
"http://schemas.xmlsoap.org/soap/envelope/"SOAP-ENV:encodingStyle=
"http://schemas.xmlsoap.org/soap/encoding/"><SOAP-ENV:Body>
<mtd:GetSymbol xmlns:mtd="an URI"
<company xsi:type="xsd:string">
Borland
</company>
</mtd:GetSymbol>
</SOAP-ENV:Body></SOAP-ENV:Envelope>
Как можно видеть, SOAP, по существу, задает протокол для передачи в одну сторону.
Для того чтобы установить связь типа "запрос/ответ" будет отправляться второе сообщение SOAP от поставщика к инициатору сервисного запроса.
Оба эти сообщения не имеют очевидной связи между собой. То есть SOAP не определяет, как должны выглядеть названия для средств доступа. Однако должно существовать средство доступа для возвращаемого значения, а также средства доступа для каждого выходного и каждого входного/выходного параметров. Необходимо соблюдать то же порядок, что и в сообщении запроса: средство доступа для возвращаемого значения должно быть первым.
Дополнительно в соглашении по программированию предложено именовать ответное сообщение также как и сообщение запроса, добавляя в конце строку "Response" ("ответ").
На следующей иллюстрации показан ответ на ранее отправленный запрос.
<SOAP-ENV:Envelope
xmlns:SOAP-ENV=
"http://schemas.xmlsoap.org/soap/envelope/"SOAP-ENV:encodingStyle=
"http://schemas.xmlsoap.org/soap/encoding/"><SOAP-ENV:Body>
<mtd:GetSymbolResponse
xmlns:mtd="an URI">
<return xsi:type="xsd:string">
BORL
</return>
</mtd:GetSymbolResponse>
</SOAP-ENV:Body></SOAP-ENV:Envelope>
Что еще не было до сих пор упомянуто, так это связывание SOAP с основным транспортным протоколом. Для HTTP обязательно наличие поля заголовка с названием SOAPAction. Это поле может использоваться, чтобы показать назначение запроса SOAP HTTP. Этим значением является URI, показывающий цель. SOAP не накладывает ограничений на формат или особенности URI, а также на возможность его разрешения. HTTP-клиент должен использовать это поле заголовка при отправлении запроса SOAP HTTP.
Это поле может обрабатываться серверами или брандмауэрами в целях фильтрации соответствующих сообщений.
В конечном счете, полный пример отправки RPC-вызова SOAP по HTTP будет выглядеть следующим образом.
POST /Symbol HTTP/1.1
Host: www.borland.com
Content-Type: text/xml; charset="utf-8"
Content -Length: nnnn
SOAPAction: "www.borland.com/Symbol"<SOAP-ENV:Envelope
xmlns:SOAP-ENV=
"http://schemas.xmlsoap.org/soap/envelope/"SOAP-ENV:encodingStyle=
"http://schemas.xmlsoap.org/soap/encoding/"><SOAP-ENV:Body>
<mtd:GetSymbol
xmlns:mtd="an URI">
<return xsi:type="xsd:string">
BORL
</return>
</mtd:GetSymbol>
</SOAP-ENV:Body>
Если по каким-либо причинам происходит сбой запроса, элемент <fault> в основной части будет использован для объяснения ошибки. Обычно элемент <fault> в SOAP содержит следующие четыре подчиненных элемента:
В спецификации определяется четыре кода для описания типа ошибки:
1. VersionMismatch (несоответствие версий):
Данная версия не содержит пространства имен http://schemas.xmlsoap.org/soap/envelope/
2. MustUnderstand:
Элемент с атрибутом mustUnderstand, для которого задано значение "1" не был правильно обработан.
3. Client (Клиент):
Сообщение было неверно оформлено.
4. Server (Сервер):
Сообщение не может быть правильно обработано, но ошибка не связана с его содержимым.
Предлагается удобное для чтения объяснение.
Указывается объект, вызывающий сбой при передаче сообщения по месту его назначения.
Содержит специфичную для конкретного приложения информацию об ошибке.
Для рассматриваемого примера будет показано полное сообщение SOAP с возможной строкой <fault> для случая, когда не удается найти определенный символ.
POST /Symbol HTTP/1.1
Host: www.borland.com
Content-Type: text/xml; charset="utf-8"
Content -Length: nnnn
SOAPAction: "www.borland.com/Symbol"<SOAP-ENV:Envelope
xmlns:SOAP-ENV=
"http://schemas.xmlsoap.org/soap/envelope/"SOAP-ENV:encodingStyle=
"http://schemas.xmlsoap.org/soap/encoding/"><SOAP-ENV:Body>
<mtd:GetSymbol
xmlns:mtd="an URI">
<return xsi:type="xsd:string">
BORL
</return>
</mtd:GetSymbol>
</SOAP-ENV:Body>
На следующем рисунке показан способ, которым SOAP используется в рассматриваемом
примере веб-сервисов.
|
Подписи к рисунку
|
|
| Service Broker | Сервисный агент |
| Service Requester | Инициатор сервисного запроса |
| Service Provider | Поставщик сервисов |
| Internet | Интернет |
| inquire Service using SOAP | Запрос сервиса с помощью SOAP |
| bind to Service using SOAP | Запрос сервиса с помощью SOAP |
| publish Service using SOAP | Публикация сервиса с помощью SOAP |
Теперь, когда у Вас появилось некоторое представление о том, что такое SOAP, мы постараемся объяснить, как описываются функциональные возможности веб-сервисов.
WSDL описывает сетевые сервисы с помощью грамматики XML. В рамках этой технологии обеспечивается документация для распределенных систем. Ее цель - дать приложениям возможность взаимодействовать друг с другом в автоматическом режиме.
В то время как SOAP определяет взаимодействие между инициатором запроса и поставщиком, WSDL описывает сервисы, предлагаемые поставщиком (в "конечной точке"), которые могут использоваться как средство создания правильных сообщений SOAP для доступа к сервисам. WSDL-документ играет роль, сходную с ролью IDL-файла в CORBA или дистанционного интерфейса при внедрении Java RMI. Структура документа и его элементы описываются в следующих главах.
Корневым элементом любого WSDL-документа являются <определения> элементов. В каждом документе содержится шесть элементов, которые можно поделить на две группы: абстрактные определения и конкретные определения.
Элементы содержат ссылки друг на друга, как это показано на следующем рисунке.
Описание, следующее за стрелкой, отображает имя атрибута элемента, который содержит
эту ссылку.
Каждый элемент в документе может содержать элемент <documentation>, обеспечивающий удобочитаемое объяснение описываемого элемента. Кроме того, все элементы содержат атрибут "name", который служит в качестве идентификатора. Хотя в контексте веб-сервисов WSDL используется для описания того, как создавать запросы SOAP и какого вида ответы SOAP следует ожидать, этот протокол также спроектирован для поддержки других соединений.
Атрибут имени данного элемента указывает имя веб-сервиса. Обычно это соответствует имени файла. Вслед за уже упомянутым элементом в нем содержится набор определений пространств имен, которые используются в документе.
Примеры пространств имен, используемых в WSDL-документе, приведены ниже.
<?xml version="1.0"?>
<definitions name="StockQuote"
targetNamespace=
"http://borland.com/symbol/definitions"xmlns:tns="http://borland.com/symbol/definitions"
xmlns:xsd1="http://borland.com/symbol/schemas"
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
xmlns="http://schemas.xmlsoap.org/wsdl/"></definitions>
Атрибут targetNamespace объявляет пространство имен, которому будут принадлежать все имена, объявляемые в этом документе.
Используя оператор импорта <import>, можно разделить один документ WSDL на несколько независимых документов, сохраняя при этом понятную и удобную для сопровождения структуру. Одним из признаков для выделения различных разделов может быть уровень абстракции, к которому принадлежит каждый из них.
После этого элементы могут быть импортированы по мере необходимости. Для элемента импорта используется следующий синтаксис:
<import namespace="an uri" location="an uri"/>
В каждом документе может быть несколько операторов импорта <import>.
Элемент типов <types>
Все определения типов данных, связанные с отправкой и получением описанных сообщений, содержатся в элементе типов <types>. Спецификация предлагает использовать определения схемы XML.
Чтобы описать ранее использованный пример в WSDL, необходимо начать со следующего определения типа.
<types>
<schema
targetNamespace="http://borland.com/symbol.xsd"
xmlns="http://www.w3.org/2000/10/XMLSchema">
<element name="SymbolResponseType">
<complexType>
<all>
<element name="tickerSymbol" type="string"/>
</all>
</complexType>
</element>
<element name="SymbolRequestType">
<complexType>
<all>
<element name="company" type="string"/>
</all>
</complexType>
</element>
</schema>
</types>
На протяжении всего документа WSDL будут использоваться два определения типов, с названиями "tickerSymbol" и "companyName", оба представляющие тип "string".
Теперь, когда определен требуемый элемент типов <types>, необходимо указать данные, которые будут передаваться инициатором сервисного запроса и поставщиком сервисов.
Для этого в спецификации определяется элемент сообщения <message>. Элемент сообщения может использоваться несколько раз и состоять из имени и одного или нескольких элементов разделов <part>. Элементы разделов ссылаются на уже определенные типы, используя атрибут "type". Говоря другими словами, эти элементы разделов определяют содержимое данного элемента сообщения.
Поскольку в рассматриваемом примере используется один входной параметр и одно возвращаемое значение, то указывается следующий элемент сообщения. Обратите внимание, что до сих пор это всего лишь абстрактное определение потока данных. Ничто не говорит о том, что оба эти сообщения принадлежат одной и той же операции.
<message name="GetSymbolInput">
<part name="inputparam"
element="xsd1:SymbolRequestType"/>
</message>
<message name="GetSymbolOutput">
<part name="returnvalue"
element="xsd1:SymbolResponseType"/>
</message>
Элемент типа порта <portType> в действительности является набором связанных операций. Поэтому для него вводится элемент операции <operation>, имеющий атрибут имени и другой, вспомогательный атрибут, которым указывается порядок параметров, используемых в этой операции. Дополнительно, чтобы определить вид операции, в спецификации могут использоваться четыре так называемых "примитива передачи":
В пределах элемента операции эти примитивы описываются с помощью трех вспомогательных элементов:
Все эти элементы содержат атрибуты "name" и "message", ссылающиеся на ранее определенный элемент сообщения. Применяются следующие правила:
С помощью <portType> можно определить операцию "GetSymbol" с сообщением "GetSymbolInput" с качестве входного параметра, которая выдает сообщение "GetSymbolOutput" на выходе. Таким образом определяется операция вопроса/ответа.
<portType name="SymbolPortType">
<operation name="GetSymbol">
<input message="tns:GetSymbolInput"/>
<output message="tns:GetSymbolOutput"/>
</operation>
</portType>
Атрибут "name" для входного и выходного элементов не указывался. Согласно спецификации они получают в качестве значение по умолчанию имя операции, к которому добавляется "Request" или "Response" соответственно.
Представлявшиеся до этого элементы описывают рассматриваемую операцию в общем виде. Сказать что-либо о ее конкретной реализации нельзя. Можно даже предположить, что она реализована с помощью CORBA. Следующая задача состоит в том, чтобы связать эту операцию с протоколом SOAP
В этих целях в спецификации WSDL вводится специальный элемент связи <binding>. Следом за атрибутом имени в нем содержится атрибут типа, который ссылается на portType и обеспечивает предварительно определенную связь с такими протоколами, как SOAP, HTTP и MIME. Его грамматика выглядит так же, как и грамматика для portType. Для каждого portType должно быть не меньше одной связи.
Повторим еще раз, имеется элемент операции <operation>, у которого есть три подэлемента: <input>, <output> и <fault>. Каждая операция соответствует подэлементу <operation> в элементе <portType>.
Чтоб связать элемент <portType> с SOAP, в этом протоколе существует специальный элемент расширения <soap:binding>. Он обеспечивает два параметра: протокол передачи и стиль запроса, который может быть или "rpc", или "document". Это значение служит в качестве значения по умолчанию для операций SOAP.
Поскольку в рассматриваемом примере требуется использовать SOAP для отправки RPC-запроса по HTTP, указывается следующее.
<soap:binding style="rpc"
transport="http://schemas.xmlsoap.org/soap/http"/>
Теперь требуется предоставить информацию для операции. Для этого необходимо использовать элемент <soap:operation>. В нем содержится атрибут "style", который заменяет заданный по умолчанию стиль для этой конкретной операции, а также атрибут "soapAction", используемый для HTTP-заголовка сообщения SOAP. (См. дополнительную информацию в главе, посвященной SOAP.) Чтобы не нарушить целостности нашего примера, необходимо написать следующее:
<soap:operation style = "rpc"
soapAction="www.borland.com/Symbol"/>
Используя стиль "rpc" каждая часть сообщения будет появляться с элементом-оберткой, содержащим имя операции. Это как раз то, что требуется для нашего сообщения SOAP.
Чтобы указать способ, которым сообщение должно появляться в основной части сообщения SOAP в рамках спецификации WSDL задается элемент <soap:body>. Он появляется либо в <input>, либо в <output> элементе определения связи <binding>.
В основной части SOAP содержится четыре элемента:
Этот вспомогательный атрибут может использоваться, чтобы указать, какая часть и где должна появляться в данном сообщении. Если он пропущен, то в основную часть сообщения SOAP будут включены все описанные разделы.
Этот обязательный атрибут указывает, закодированы ли данные разделы сообщения с помощью стиля кодирования (значение "encoded"), а также есть ли в разделе ссылки на определение конкретной схемы (значение "literal").
Этот атрибут имеет точно такую же семантику, что и в спецификации SOAP.
Можно определить другое пространство имен, чтобы избежать их пересечения.
Элемент <soap:fault> предназначен для того, чтобы указывать строку <fault> в SOAP. Он имеет такую же структуру, что и элемент <soap:body>.
Чтобы определить строки заголовка и элементы <fault> используются элементы <soap:header> и <soap:headerfault>. Они употребляются таким же образом, что и описанные выше элементы SOAP. Кроме того <soap:header> содержит два атрибута: "message" и "part". Они указывают на раздел сообщения в WSDL-документе, который определяет тип заголовка.
В качестве примера приводится полный элемент <binding>.
<binding name="SymbolSoapBinding"
type="tns:SymbolPortType">
<soap:binding style="rpc"
transport=
"http://schemas.xmlsoap.org/soap/http"/>
<operation name="GetSymbol">
<soap:operation style = "rpc"
soapAction="www.borland.com/Symbol"/>
<input>
<soap:body
use="encoded"
encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" />
</input>
<output>
<soap:body
use="encoded"
encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" />
</output>
</operation>
</binding>
Элемент сервиса <service> в действительности является набором связанных портов. Вот почему элемент сервиса содержит только атрибут имени и подэлемент <port>, который может использоваться несколько раз.
При наличии нескольких реализаций одной и той же связи, для них используются разные порты.
Эта связь указывается внутри элемента <port>.
Для связи с протоколом SOAP определяется элемент <soap:address>. В нем содержатся имя и местоположение, определяющие адрес такого же типа, что указывается в атрибуте "transport" в элементе <soap:binding>. Это означает, что необходимо определить адрес HTTP.
В заключение этого раздела покажем, как будет выглядеть элемент <service> для нашего примера.
<service name="SymbolService">
<documentation>a simple web service
</documentation>
<port name="SymbolPort"
binding="tns:SymbolSoapBinding">
<soap:address
location="http://borland.com/symbol"/>
</port>
</service>
UDDI (Universal Description, Discovery, and Integration) - это стандарт, разработанный для создания пригодного к поиску каталога предприятий и предоставляемых ими веб-сервисов. Таким образом, он является чем-то вроде сервисного агента, который помогает инициаторам сервисных запросов находить подходящих поставщиков сервисов. В отношении многих аспектов UDDI проектируется также как телефонная книга. В нем предусмотрена поддержка для следующих типов данных:
Чтобы получить доступ к UDDI-сервисам, каталог UDDI предлагает набор программных интерфейсов API в виде созданных на основе SOAP веб-сервисов. Эти интерфейсы поделены на две логических части: интерфейс API для запросов и интерфейс API для публикаций. Интерфейс API для запросов состоит из двух следующих частей: одна из них используется для создания программ, позволяющих осуществлять поиск информации в реестре UDDI, а затем просматривать ее, а вторая часть используется в случае возникновения сбоев.
Основным компонентом UDDI является система регистрация предприятий, в которой для описания бизнес-единицы и ее веб-сервисов используется XML-файл. Для регистрации и обнаружения веб-сервисов спецификация определяет использующий SOAP протокол программирования на основе HTTP. Используя поисковые сервисы UDDI, поставщики самостоятельно регистрируют информацию о веб-сервисах, которые они выставляют для использования другими предприятиями. Эта информация может быть добавлена к реестру предприятий UDDI либо через веб-сайт, либо с помощью инструментария, использующего интерфейсы программных сервисов, которые описаны в спецификации программирования API для UDDI.
Схема UDDI XML определяет четыре основных типа данных, которые необходимы разработчикам
для связи с веб-сервисами. На следующем рисунке показаны отношения между различными
этим структурами.
Как показано выше, структуры данных состоят из следующего:
Эта структура данных содержит информацию о компании, публикующей веб-сервисы. Эта информация обязательно должна включать название компании, но также может содержать сведения о URL для поиска, предлагаемых сервисах, а также о том, как связаться с представителем данной компании (почтовый адрес, телефонный номер, адрес электронной почты и т.п.).
Каждая бизнес-единица может содержать несколько бизнес-сервисов.
Используйте структуру данных <businessService>, чтобы в бизнес-терминах описать каждый предлагаемый сервис. В ней обязательно должны быть заданы имя и шаблон связи.
Каждый бизнес-сервис должен содержать один или несколько шаблонов связи.
В каждой из структур шаблонов связи <bindingTemplates>может содержаться один или несколько таких шаблонов. Структура шаблона связи описывает, как получить доступ к сервису.
Эти так называемые точки доступа представляют собой адреса URL. Адекватными для элемента точки доступа <accessPoint> являются следующие значения.
Другой атрибут с названием <hostingRedirector> может использоваться, если данный шаблон связи указывает на другой шаблон, который уже был определен. Поэтому в таком случае в повторном определении точки доступа нет необходимости.
Еще один элемент с названием <tModelInstanceDetails> содержит информацию для определенной модели tModel, на которую ссылается его ключ. Описание элементов tModel можно найти в следующем разделе.
Эти элементы используются для описания технических спецификаций, например, сетевых протоколов, форматов обмена или правил упорядочивания. Они позволяют сторонам обнаруживать друг друга, при условии их совместимости. Если в дальнейшем стороны пожелают установить соответствие со спецификацией, им просто необходимо предоставить ссылку на подходящую модель.
В tModel существует два следующих обязательных атрибута.
1. tModelKey
Этот атрибут служит в качестве идентификатора, уникального среди всех элементов tModel. Если требуется обновить существующий элемент tModel, необходимо указать ключ данной модели
2. name
Этот атрибут должен быть определен, чтобы обеспечить значимое имя для элемента tModel.
Другие атрибуты обеспечивают поддержку интерфейса API, используемого для поиска в реестре UDDI, а также для последующего документирования. Вспомогательным, но очень важным атрибутом является <overviewDoc>. Эта структура с помощью URL указывает на находящийся удаленно документ, содержащий описательную информацию или инструкции.
<businessService businessKey="..."
serviceKey="...">
<name> SymbolService </name>
<description> a description </description>
<bindingTemplates>
<bindingTemplate>
...
<accessPoint urlType="http">
http://borland.com/symbol
</accessPoint>
<tModelInstanceDetails>
<tModelInstanceInfo
tModelKey="123123">
</tModelInstanceInfo>
</tModelInstanceDetails>
</bindingTemplate>
</bindingTemplates>
</businessService>
Теперь UDDI будет подключен к нашей картинке веб-сервисов, показывая как регистрировать WSDL-документы в UDDI.
Каждый WSDL-документ будет указан в элементе tModel. Каждый такой элемент tModel должен классифицироваться как элемент с типом "wsdlSpec" и иметь <overviewDoc>, указывающий на требуемый WSDL-документ.
Используемые типы принадлежат к систематике "uddi-org:types". Теперь будем использовать UDDI с нашим примером из предыдущих глав.
Начнем со структуры <tModel>, содержащей элемент <overviewURL>, указывающей на WSDL-файл.
<tModel
authorizedName="..." operator="..."
tModelKey="123123>
<name> StockQuote Service </name>
<description xml:lan="en">
WSDL description of a Symbol lookup service
</description>
<overviewDoc>
<description xml:lang="en">
WSDL source document.
</description>
<overviewURL>
http://www.borland.com/symbol.wsdl
</overviewURL>
</overviewDoc>
<categoryBag>
<keyedReference
tModelKey="UUID:123123"
keyName="uddi-org:types"
keyValue="wsdlSpec"/>
</categoryBag>
</tModel>
Описав ключевые технологии, теперь можно представить полную картину распределенных
приложений в том виде, как она применима к SOAP, WSDL и UDDI.
|
Подписи к рисунку
|
|
| UDDI Registry | Реестр UDDI |
| Service Requester | Инициатор сервисного запроса |
| Service Provider | Поставщик сервисов |
| Internet | Интернет |
| inquire WSDL using SOAP | запрос WSDL с помощью SOAP |
| bind using SOAP | подключение с помощью SOAP |
| publish WSDL using SOAP | публикация WSDL с помощью SOAP |
Хотя подготовка всех необходимых документов выглядит непростой задачей, следует обратить внимание, что все эти документы обычно создаются в соответствии со структурой других промежуточных программных продуктов. Поэтому разработчикам нет необходимости беспокоиться о проблемах, связанных с обменом информацией. Наборы инструментов и интерфейсы API будут автоматически создавать соответствующие документы XML.
В некоторых разделах данной статьи веб-сервисы рассматривались как "еще один тип промежуточного ПО", похожий на другие аналогичные продукты, такие как CORBA и RMI, но определенно более пригодный для использования через Internet.
Поэтому обычные вопросы, связанные с программированием распределенных приложений, такие как производительность, масштабируемость, отказоустойчивость и безопасность, также должны рассматриваться при работе с веб-сервисами. Представьте себе, что ваш собственный веб-сервис использует другой веб-сервис для аутентификации кредитной карточки. Что произойдет с этим веб-сервисом, да и вообще со всем вашим бизнесом, если не будет предусмотрена служба обеспечения безопасности? Как должен реагировать веб-сервис, если на него обрушится поток клиентов с тысячами запросов? Решения этих вопросов являются следующими шагами, которые необходимо предпринять веб-сервисам, чтобы стать действительно зрелой платформой. Однако первые многообещающие шаги уже были сделаны.
Дополнительная информация
За дополнительной информацией обращайтесь в компанию Interface Ltd.
| INTERFACE Ltd. |
| ||||
