стандарты для веб-сервисов SOAP, WSDL, UDDI
Веб-сервисы представляют собой технологию интеграции приложений, которая может использоваться в Internet. В качестве примера возможного использования веб-сервисов рассмотрим планирование путешествий. Обычно в такой ситуации требуются: заказ билетов на самолет, бронирование мест в гостинице, аренда автомобиля и, возможно, использование услуг местных компаний, организующих экскурсии.
Традиционно используя Internet, вам придется посетить сервер авиакомпании, сервер гостиницы или сети гостиниц, сервер компании по аренде автомобилей и сервер компании, специализирующейся на организации экскурсий в выбранном вами месте. Все эти действия могут занять достаточно много времени, прежде чем вы достигнете цели. И при этом ни одна из задействованных вами компаний не будет знать, каковы ваши планы, а следовательно, не сможет оптимизировать ваше время. Проблема заключается в том, что компании, специализирующиеся на отдельных областях — авиа, гостиничной, прокате автомобилей и т.п., в большинстве случаев замкнуты сами на себя и используют собственные средства хранения и представления данных.
Более удобно было бы запустить приложение, которое бы приняло от вас необходимую информацию и выполнило все рутинные действия — заказ билетов, бронирование гостиницы и т. п. — автоматически, без вашего участия. Чтобы это стало возможным, вы должны использовать веб-сервисы. Давайте рассмотрим, что изменится в этом случае.
Предположим, авиакомпания предоставляет веб-сервис, позволяющий приложениям получать список рейсов между двумя городами для заданной даты. В этом случае больше не требуется обращаться к веб-узлу авиакомпании и указывать различные критерии поиска — вся необходимая информация доступна в виде единого XML-документа. Теперь предположим, что авиакомпания, отель и агентство по прокату автомобилей предоставляют веб-сервисы, позволяющие программно приобретать билеты, бронировать номера и арендовать автомобили. В этом случае можно объединить вызовы всех этих сервисов в единое приложение, которое сможет выполнить всю рутинную работу без участия пользователя.
Впрочем, на этом функциональность нового класса веб-приложений не заканчивается. Наше приложение может, например, периодически обращаться к веб- сервису авиакомпании для определения статуса рейса и в случае его задержки оповещать сервисы гостиницы, службы проката и т.п. для продления бронирования.
Помимо очевидного повышения качества обслуживания клиентов использование веб-сервисов имеет множество других преимуществ. Например, если агентство проката автомобилей знает, что ваш рейс задерживается, оно может более гибко распорядиться своими автомобилями. По мере возрастания числа веб-сервисов мы сможем увидеть более комплексные примеры их использования. Однако следует отметить, что внедрение концепции веб-сервисов требует не только пересмотра многих бизнес-правил и схем взаимодействия между отраслями и секторами той или иной отрасли, но и повышения безопасности обмена данными.
Рассмотрев практическое применение веб-сервисов, обратимся к стандартам, лежащим в основе этих сервисов.
стандарты
Как мы уже знаем, в основе веб-сервисов лежат Internet-стандарты. Эти стандарты определяют протоколы, а не способы их реализации. Такое утверждение является залогом успеха Internet — ни одна компания не может влиять на Internet-стандарты и задавать собственные правила игры. Например, стандарты веб-сервисов разрабатываются совместно такими компаниями, как IBM, Microsoft, Ariba и некоторыми другими, и обсуждаются комитетом World Wide Web Consortium (W3C).
Веб-сервисы базируются на трех основных веб-стандартах:
- SOAP (Simple Object Access Protocol) — протокол для посылки сообщений по протоколу HTTP и другим Internet-протоколам;
- WSDL (Web Services Description Language) — язык для описания программных интерфейсов веб-сервисов;
- UDDI (Universal Description, Discovery and Integration) — стандарт для индексации веб-сервисов.
Серверы приложений являются хранилищами веб-сервисов и делают их доступными через протоколы HTTP GET, HTTP POST и HTTP SOAP.
Существующие веб-сервисы описываются в WSDL-документах, которые располагаются либо на сервере приложений, либо в специальных XML-хранилищах. WSDL-документ может ссылаться на другие WSDL-документы и документы XSD (XML Schema), в которых описаны типы данных, используемые веб-сервисами. XML-хранилища используются для управления WSDL-документами. Внутри WSDL-документа находится адрес (URL) веб-сервиса. Веб-сервисы описаны и проиндексированы в бизнес-реестре, содержащем адреса (URL) WSDL-документов.
В следующих разделах мы рассмотрим три основных веб-стандарта, на которых базируются веб-сервисы - SOAP, WSDL и UDDI - более подробно.
SOAP — Simple Object Access Protocol
SOAP — это стандарт для отсылки и получения сообщений по Internet. Изначально этот протокол был предложен фирмой Microsoft в качестве средства для удаленного вызова процедур (RPC, Remote Procedure Call) по протоколу HTTP, а спецификация SOAP 1.0 (Userland, Microsoft, Developmentor) была тесно связана с Component Object Model. Фирма IBM и ряд других компаний, в том числе Lotus, внесли определенный вклад в развитие этого протокола, и его спецификация была направлена на рассмотрение комитетом W3C.
Спецификация SOAP определяет XML-«конверт» для передачи сообщений, метод для кодирования программных структур данных в формате XML, а также средства связи по протоколу HTTP.
SOAP-сообщения бывают двух типов: запрос (Request) и ответ (Response). Запрос вызывает метод удаленного объекта, ответ возвращает результат выполнения данного метода. Приведем пример запроса в формате SOAP:
<SOAP-ENV:Envelope><br>
xmlns:SOAP-ENV="http://[soaporg]/envelope"
SOAP-ENV:encodingStyle="http://[soapporg]/encoding//"
<SOAP-ENV:BODY>
<m:GetStockRespense xmlns:m="SOME-URL">
<Symbol>HST</Symbol>
<m:GetLastStock>
<SOAP-ENV:Body>
</SOAP-ENV:Envelope>
А вот ответ:
<SOAP-ENV:Envelope><br>
xmlns:SOAP-ENV="http://[soaporg]/envelope"
SOAP-ENV:encodingStyle="http://[soapporg]/encoding//"
<SOAP-ENV:BODY>
<m:GetStockRespense xmlns:m="SOME-URL">
<price>48.6</price>
<m:GetLastStockResprnse>
<Soap-ENV:Body>
</SOAP-ENV:Envelope>
Спецификация SOAP определяет формат кодирования, который, в свою очередь, задает способ представления данных в XML-формате.
WSDL — Web Services Description Language
Для того чтобы приложения могли использовать веб-сервисы, программные интерфейсы последних должны быть детально описаны — с этой точки зрения язык WSDL играет ту же роль, что и язык Interface Definition Language (IDL) в распределенных вычислениях. Описание может включать такую информацию, как протокол, адрес сервера, номер используемого порта, список доступных операций, формат запроса и ответа и т. п.
Для описания этой информации было предложено несколько языков. Одним из них был язык Service Description Language (SDL), разработанный Microsoft и входивший в первую версию Microsoft SOAP Toolkit. Компания IBM переработала спецификацию и, использовав спецификацию Network Accessible Service Specification Language (NASSL), выпустила NASSL Toolkit как часть SOAP4J. Идеи, реализованные в NASSL, повлияли на спецификацию языка SOAP Contract Language (SCL), предложенную Microsoft. В настоящее время обе спецификации (NASSL и SDL/SCL), а также предложения других фирм учтены в спецификации языка WSDL. Для описания бизнес-логики IBM и Microsoft работают над спецификацией языка Web Services Flow Language (WSFL). Вот пример скелета описания сервисов на языке WSDL:
<?xml version="1.0" ?>
<definitions name="Stocks" tsrgetNamespace=url
xmlns:soap="http://(soaporg)/wsdl/soap"
xmlns="http://(soaporg)/wsdl/">
<types>
<elements>...</elements>
</types>
<message>...</message>
<portType>...</portType>
<binding>
<operation>
<input>...</input>
<output>...</output>
</operation>
</binding>
<service>...</service>
</definitions>
Как мы видим, описание сервисов представляет собой XML-документ, состоящий из нескольких элементов, в том числе из описания пространства имен (namespace), описания типов и элементов, сообщений, порта, а также возможных операций — запросов и ответов.
Файл, содержащий описание сервисов, является достаточно сложным документом, поэтому для его создания по возможности следует пользоваться автоматическими генераторами, включенными в состав средств разработки.
UDDI — Universal Description, Discovery and Integration
Задача UDDI — предоставить механизм для обнаружения веб-сервисов. UDDI задает бизнес-реестр, в котором провайдеры веб-сервисов могут регистрировать сервисы, а разработчики — искать необходимые им сервисы. Компании IBM, Microsoft и Ariba создали собственные UDDI-реестры (в скором времени эти реестры будут объединены в веб-реестр), в одном из которых разработчики могут зарегистрировать свои веб-сервисы, после чего данные будут автоматически реплицированы в другие реестры.
UDDI базируется на элементах четырех типов: Business Entity, Business Service, Binding Template и Technology Model.
Элемент Business Entity описывает индустрию, предоставляющую данный веб-сервис. Этот элемент может включать описания категорий для данной индустрии, облегчающие более детальный поиск сервисов.
Business Service — это класс сервисов в рамках определенной отрасли промышленности или услуг. Каждая отрасль принадлежит определенному элементу Business Entity.
Вместе Binding Template и Technology Model определяют веб-сервис. Technology Model содержит абстрактное описание, а Binding Template — конкретную спецификацию сервиса. Каждый элемент Binding Template принадлежит определенному элементу Business Service, но несколько элементов Binding Template могут ссылаться на один элемент Technology Model.
Бизнес-реестр UDDI сам является SOAP веб-сервисом. Он поддерживает операции создания, модификации, удаления и поиска элементов всех четырех рассмотренных выше типов.
Реферат слушателя ИКСИ, научный руководитель – Сергей Кунегин
Традиционно используя Internet, вам придется посетить сервер авиакомпании, сервер гостиницы или сети гостиниц, сервер компании по аренде автомобилей и сервер компании, специализирующейся на организации экскурсий в выбранном вами месте. Все эти действия могут занять достаточно много времени, прежде чем вы достигнете цели. И при этом ни одна из задействованных вами компаний не будет знать, каковы ваши планы, а следовательно, не сможет оптимизировать ваше время. Проблема заключается в том, что компании, специализирующиеся на отдельных областях — авиа, гостиничной, прокате автомобилей и т.п., в большинстве случаев замкнуты сами на себя и используют собственные средства хранения и представления данных.
Более удобно было бы запустить приложение, которое бы приняло от вас необходимую информацию и выполнило все рутинные действия — заказ билетов, бронирование гостиницы и т. п. — автоматически, без вашего участия. Чтобы это стало возможным, вы должны использовать веб-сервисы. Давайте рассмотрим, что изменится в этом случае.
Предположим, авиакомпания предоставляет веб-сервис, позволяющий приложениям получать список рейсов между двумя городами для заданной даты. В этом случае больше не требуется обращаться к веб-узлу авиакомпании и указывать различные критерии поиска — вся необходимая информация доступна в виде единого XML-документа. Теперь предположим, что авиакомпания, отель и агентство по прокату автомобилей предоставляют веб-сервисы, позволяющие программно приобретать билеты, бронировать номера и арендовать автомобили. В этом случае можно объединить вызовы всех этих сервисов в единое приложение, которое сможет выполнить всю рутинную работу без участия пользователя.
Впрочем, на этом функциональность нового класса веб-приложений не заканчивается. Наше приложение может, например, периодически обращаться к веб- сервису авиакомпании для определения статуса рейса и в случае его задержки оповещать сервисы гостиницы, службы проката и т.п. для продления бронирования.
Помимо очевидного повышения качества обслуживания клиентов использование веб-сервисов имеет множество других преимуществ. Например, если агентство проката автомобилей знает, что ваш рейс задерживается, оно может более гибко распорядиться своими автомобилями. По мере возрастания числа веб-сервисов мы сможем увидеть более комплексные примеры их использования. Однако следует отметить, что внедрение концепции веб-сервисов требует не только пересмотра многих бизнес-правил и схем взаимодействия между отраслями и секторами той или иной отрасли, но и повышения безопасности обмена данными.
Рассмотрев практическое применение веб-сервисов, обратимся к стандартам, лежащим в основе этих сервисов.
стандарты
Как мы уже знаем, в основе веб-сервисов лежат Internet-стандарты. Эти стандарты определяют протоколы, а не способы их реализации. Такое утверждение является залогом успеха Internet — ни одна компания не может влиять на Internet-стандарты и задавать собственные правила игры. Например, стандарты веб-сервисов разрабатываются совместно такими компаниями, как IBM, Microsoft, Ariba и некоторыми другими, и обсуждаются комитетом World Wide Web Consortium (W3C).
Веб-сервисы базируются на трех основных веб-стандартах:
- SOAP (Simple Object Access Protocol) — протокол для посылки сообщений по протоколу HTTP и другим Internet-протоколам;
- WSDL (Web Services Description Language) — язык для описания программных интерфейсов веб-сервисов;
- UDDI (Universal Description, Discovery and Integration) — стандарт для индексации веб-сервисов.
Серверы приложений являются хранилищами веб-сервисов и делают их доступными через протоколы HTTP GET, HTTP POST и HTTP SOAP.
Существующие веб-сервисы описываются в WSDL-документах, которые располагаются либо на сервере приложений, либо в специальных XML-хранилищах. WSDL-документ может ссылаться на другие WSDL-документы и документы XSD (XML Schema), в которых описаны типы данных, используемые веб-сервисами. XML-хранилища используются для управления WSDL-документами. Внутри WSDL-документа находится адрес (URL) веб-сервиса. Веб-сервисы описаны и проиндексированы в бизнес-реестре, содержащем адреса (URL) WSDL-документов.
В следующих разделах мы рассмотрим три основных веб-стандарта, на которых базируются веб-сервисы - SOAP, WSDL и UDDI - более подробно.
SOAP — Simple Object Access Protocol
SOAP — это стандарт для отсылки и получения сообщений по Internet. Изначально этот протокол был предложен фирмой Microsoft в качестве средства для удаленного вызова процедур (RPC, Remote Procedure Call) по протоколу HTTP, а спецификация SOAP 1.0 (Userland, Microsoft, Developmentor) была тесно связана с Component Object Model. Фирма IBM и ряд других компаний, в том числе Lotus, внесли определенный вклад в развитие этого протокола, и его спецификация была направлена на рассмотрение комитетом W3C.
Спецификация SOAP определяет XML-«конверт» для передачи сообщений, метод для кодирования программных структур данных в формате XML, а также средства связи по протоколу HTTP.
SOAP-сообщения бывают двух типов: запрос (Request) и ответ (Response). Запрос вызывает метод удаленного объекта, ответ возвращает результат выполнения данного метода. Приведем пример запроса в формате SOAP:
<SOAP-ENV:Envelope><br>
xmlns:SOAP-ENV="http://[soaporg]/envelope"
SOAP-ENV:encodingStyle="http://[soapporg]/encoding//"
<SOAP-ENV:BODY>
<m:GetStockRespense xmlns:m="SOME-URL">
<Symbol>HST</Symbol>
<m:GetLastStock>
<SOAP-ENV:Body>
</SOAP-ENV:Envelope>
А вот ответ:
<SOAP-ENV:Envelope><br>
xmlns:SOAP-ENV="http://[soaporg]/envelope"
SOAP-ENV:encodingStyle="http://[soapporg]/encoding//"
<SOAP-ENV:BODY>
<m:GetStockRespense xmlns:m="SOME-URL">
<price>48.6</price>
<m:GetLastStockResprnse>
<Soap-ENV:Body>
</SOAP-ENV:Envelope>
Спецификация SOAP определяет формат кодирования, который, в свою очередь, задает способ представления данных в XML-формате.
WSDL — Web Services Description Language
Для того чтобы приложения могли использовать веб-сервисы, программные интерфейсы последних должны быть детально описаны — с этой точки зрения язык WSDL играет ту же роль, что и язык Interface Definition Language (IDL) в распределенных вычислениях. Описание может включать такую информацию, как протокол, адрес сервера, номер используемого порта, список доступных операций, формат запроса и ответа и т. п.
Для описания этой информации было предложено несколько языков. Одним из них был язык Service Description Language (SDL), разработанный Microsoft и входивший в первую версию Microsoft SOAP Toolkit. Компания IBM переработала спецификацию и, использовав спецификацию Network Accessible Service Specification Language (NASSL), выпустила NASSL Toolkit как часть SOAP4J. Идеи, реализованные в NASSL, повлияли на спецификацию языка SOAP Contract Language (SCL), предложенную Microsoft. В настоящее время обе спецификации (NASSL и SDL/SCL), а также предложения других фирм учтены в спецификации языка WSDL. Для описания бизнес-логики IBM и Microsoft работают над спецификацией языка Web Services Flow Language (WSFL). Вот пример скелета описания сервисов на языке WSDL:
<?xml version="1.0" ?>
<definitions name="Stocks" tsrgetNamespace=url
xmlns:soap="http://(soaporg)/wsdl/soap"
xmlns="http://(soaporg)/wsdl/">
<types>
<elements>...</elements>
</types>
<message>...</message>
<portType>...</portType>
<binding>
<operation>
<input>...</input>
<output>...</output>
</operation>
</binding>
<service>...</service>
</definitions>
Как мы видим, описание сервисов представляет собой XML-документ, состоящий из нескольких элементов, в том числе из описания пространства имен (namespace), описания типов и элементов, сообщений, порта, а также возможных операций — запросов и ответов.
Файл, содержащий описание сервисов, является достаточно сложным документом, поэтому для его создания по возможности следует пользоваться автоматическими генераторами, включенными в состав средств разработки.
UDDI — Universal Description, Discovery and Integration
Задача UDDI — предоставить механизм для обнаружения веб-сервисов. UDDI задает бизнес-реестр, в котором провайдеры веб-сервисов могут регистрировать сервисы, а разработчики — искать необходимые им сервисы. Компании IBM, Microsoft и Ariba создали собственные UDDI-реестры (в скором времени эти реестры будут объединены в веб-реестр), в одном из которых разработчики могут зарегистрировать свои веб-сервисы, после чего данные будут автоматически реплицированы в другие реестры.
UDDI базируется на элементах четырех типов: Business Entity, Business Service, Binding Template и Technology Model.
Элемент Business Entity описывает индустрию, предоставляющую данный веб-сервис. Этот элемент может включать описания категорий для данной индустрии, облегчающие более детальный поиск сервисов.
Business Service — это класс сервисов в рамках определенной отрасли промышленности или услуг. Каждая отрасль принадлежит определенному элементу Business Entity.
Вместе Binding Template и Technology Model определяют веб-сервис. Technology Model содержит абстрактное описание, а Binding Template — конкретную спецификацию сервиса. Каждый элемент Binding Template принадлежит определенному элементу Business Service, но несколько элементов Binding Template могут ссылаться на один элемент Technology Model.
Бизнес-реестр UDDI сам является SOAP веб-сервисом. Он поддерживает операции создания, модификации, удаления и поиска элементов всех четырех рассмотренных выше типов.
Реферат слушателя ИКСИ, научный руководитель – Сергей Кунегин
Сетевые решения. Статья была опубликована в номере 04 за 2007 год в рубрике технологии
