Web нового поколения — Web-сервисы

Алексей Федоров

Генезис Web

Сервис-ориентированный Web

Стандарты для Web-сервисов

   SOAP — Simple Object Access Protocol

   WSDL — Web Services Description Language

   UDDI — Universal Description, Discovery and Integration

Средства разработки

Web-сервисы в Microsoft Visual Studio.NET

Заключение

 

В данном обзоре мы рассмотрим Web-сервисы — технологию интеграции Web-приложений, которая приходит на смену традиционным Web-приложениям. Мы начнем с краткого рассказа о развитии Web, а затем более подробно поговорим о сервис-ориентированных Web. Затем рассмотрим концепцию Web-сервисов как таковых, стандарты, описывающие такие сервисы, — SOAP, WSDL и UDDI, средства разработки Web-сервисов, а также выясним, как эта концепция поддерживается в Microsoft Visual Studio.NET.

Генезис Web

Изначально World Wide Web была сетью документов. Web-серверы общались с клиентами по протоколу HTTP (Hypertext Transfer Protocol) и пересылали информацию в форме гипертекстовых документов, созданных средствами языка HTML (Hypertext Markup Language). Такие документы отображались в браузерах и содержали ссылки на другие документы. Этого было вполне достаточно для удовлетворения запросов создателей Web — ученых, которым было необходимо средство для обмена различными документами: результатами исследований, лабораторными протоколами, отчетами и т.п. Таким образом, Web появился как документо-ориентированная сеть.

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

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

Появление разнообразных мобильных устройств привело к тому, что вместо традиционных браузеров многие коммерческие Web-приложения теперь помимо протокола HTTP поддерживают и протокол WAP (Wireless Access Protocol) и способны возвращать информацию не только в стандарте HTML, но и в стандарте, удовлетворяющем пользователей, обращающихся к сервисам через мобильные устройства, — WML (Wireless Markup Language).

Естественно, электронная коммерция не может ограничиваться простой обработкой транзакций — следующим логических шагом в развитии Web стала интеграция бизнес-процессов различных компаний. Таким образом на свет появляется сервис-ориентированный Web. В его основе лежат две относительно новые технологии — SOAP (Simple Object Access Protocol) и XML (Extensible Markup Language). Согласно этому сценарию Web состоит из набора серверов приложений, обменивающихся информацией в формате XML по протоколу SOAP.

Основой сервис-ориентированного Web является Web-сервис — набор логически связанных функций, которые могут быть программно вызваны через Internet. Информация о том, какие функции предоставляет данный Web-сервис, содержится в документе WSDL (Web Service Description Language), а для поиска существующих Web-сервисов предполагается использование специальных реестров, совместимых со спецификацией UDDI (Universal Description, Discovery and Integration).

В начало В начало

Сервис-ориентированный Web

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

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

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

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

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

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

Рассмотрев практическое применение Web-сервисов, обратимся к стандартам, лежащим в основе этих сервисов.

В начало В начало

Стандарты для Web-сервисов

Как мы уже знаем, в основе Web-сервисов лежат Internet-стандарты. Эти стандарты определяют протоколы, а не способы их реализации. Такое утверждение является залогом успеха Internet — ни одна компания не может влиять на Internet-стандарты и задавать собственные правила игры. Например, стандарты Web-сервисов разрабатываются совместно такими компаниями, как IBM, Microsoft, Ariba и некоторыми другими, и обсуждаются комитетом World Wide Web Consortium (W3C).

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

  • SOAP (Simple Object Access Protocol) — на протоколе для посылки сообщений по протоколу HTTP и другим Internet-протоколам;
  • WSDL (Web Services Description Language) — на языке для описания программных интерфейсов Web-сервисов;
  • UDDI (Universal Description, Discovery and Integration) — на стандарте для индексации Web-сервисов.

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

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

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

В следующих разделах мы рассмотрим три основных Web-стандарта, на которых базируются Web-сервисы 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). Запрос вызывает метод удаленного объекта, ответ возвращает результат выполнения данного метода. На рис. 2 и 3 приведены примеры запроса и ответа в формате SOAP.

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

Одной из первых реализаций протокола SOAP была Java-версия, созданная фирмой Developmentor. Компания IBM выпустила собственную Java-версию, известную под названием IBM SOAP4J, доступную на Web-узле alphaWorks (http://www.ibm.com/alphaworks/). Впоследствии эта версия была интегрирована в проект Apache XML (http://www.xml.apache.org/). В настоящее время она носит название Apache SOAP 2.0 и работает под управлением Apache Tomcat, IBM WebSphere Application Server и других серверов, поддерживающих сервлеты. Версия Microsoft, известная под названием SOAP Toolkit, позволяет использовать Visual Basic. Более полный список известных реализаций протокола SOAP можно найти на Web-узле SOAP WebServices Resource Center (http://www.soap-wrc.com/webservices/), а список доступных SOAP Web-сервисов — на Web-узле SOAP Web Services (http://www.xmethods.net/).

В начало В начало

WSDL — Web Services Description Language

Для того чтобы приложения могли использовать Web-сервисы, программные интерфейсы последних должны быть детально описаны — с этой точки зрения язык 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).

На рис. 4 показан скелет описания сервисов на языке WSDL.

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

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

Описание языка WSDL можно найти на Web-сайте компании Microsoft по адресу http://www.msdn.microsoft.com/xml/general/wsdl.asp/.

В начало В начало

UDDI — Universal Description, Discovery and Integration

Задача UDDI — предоставить механизм для обнаружения Web-сервисов. UDDI задает бизнес-реестр, в котором провайдеры Web-сервисов могут регистрировать сервисы, а разработчики — искать необходимые им сервисы. Компании IBM, Microsoft и Ariba создали собственные UDDI-реестры (в скором времени эти реестры будут объединены в Web-реестр), в одном из которых разработчики могут зарегистрировать свои Web-сервисы, после чего данные будут автоматически реплицированы в другие реестры (рис. 5).

UDDI базируется на элементах четырех типов: Business Entity, Business Service, Binding Template и Technology Model. Элемент Business Entity описывает индустрию, предоставляющую данный Web-сервис. Этот элемент может включать описания категорий для данной индустрии, облегчающие более детальный поиск сервисов.

Business Service — это класс сервисов в рамках определенной отрасли промышленности или услуг. Каждая отрасль принадлежит определенному элементу Business Entity.

Вместе Binding Template и Technology Model определяют Web-сервис. Technology Model содержит абстрактное описание, а Binding Template — конкретную спецификацию сервиса. Каждый элемент Binding Template принадлежит определенному элементу Business Service, но несколько элементов Binding Template могут ссылаться на один элемент Technology Model.

Бизнес-реестр UDDI сам является SOAP Web-сервисом. Он поддерживает операции создания, модификации, удаления и поиска элементов всех четырех рассмотренных выше типов.

Полное описание UDDI можно найти на Web-сайте по адресу http://www.uddi.org/.

В начало В начало

Средства разработки

Рассмотрев три основных Web-стандарта, на которых базируются Web-сервисы, — SOAP, WSDL и UDDI, мы теперь знаем, что они являются достаточно комплексными при создании всех необходимых для описания Web-сервиса XML-документов. Эту работу выполняют специальные средства разработки, предоставляя разработчикам возможность сосредоточиться на бизнес-логике создаваемого сервиса, а не на низкоуровневых деталях его реализации. Среди наиболее популярных в настоящее время средств разработки Web-сервисов следует упомянуть Microsoft SOAP Toolkit и IBM XML and Web Services Development Envirоnment (WSDE).

Ниже мы рассмотрим еще одно средство для создания Web-сервисов — Microsoft Visual Studio.NET, которое в скором времени станет основным инструментом для разработчиков, создающих решения для платформы Microsoft .Net.

В начало В начало

Web-сервисы в Microsoft Visual Studio.NET

Для создания Web-сервиса средствами Microsoft Visual Studio.NET необходимо выполнить следующие действия:

  1. Запустить Visual Studio.NET 7.0.
  2. Выполнить команду File | New | Project (или выбрать команду Create New Project на стартовой странице VS Home Page).
  3. В панели New Projects выбрать Visual Basic Projects, в панели Templates выбрать Web Service (рис. 6).
  4. Задать название сервиса и нажать Ok.

В результате мы получим такой скелет сервиса (чтобы увидеть код, следует нажать правую кнопку мыши):

Imports System.ComponentModel  
Imports System.Configuration  
Imports System.Web.Services  
Imports System.Diagnostics  
Imports System.Data  
   
Public Class ExchangeRateService  
Inherits System.Web.Services.WebService  
   
#Region " Web Services Designer Generated Code "  
   
'Required by the WebServices Designer  
Private components As System.ComponentModel.Container  
   
Private Sub InitializeComponent()  
      'CODEGEN: This procedure is required by the WebServices Designer  
      'Do not modify it using the code editor.  
            components = New System.ComponentModel.Container  
End Sub  
   
Overrides Sub Dispose()  
      'CODEGEN: This procedure is required by the WebServices Designer  
      'Do not modify it using the code editor.  
End Sub  
   
#End Region  
   
Public Sub New()  
MyBase.New  
   
      'CODEGEN: This procedure is required by the WebServices Designer  
      'Do not modify it using the code editor.  
      InitializeComponent  
   
      'Add your own initialization code after the InitializeComponent   
' call  
End Sub  
   
End Class  

Microsoft Visual Studio.NET также создаст SDL-файл, который будет содержать описание нашего Web-сервиса, и DISCO-файл, используемый для регистрации и обнаружения сервиса.

В качестве примера создадим Web-сервис, выполняющий конвертацию валюты. Реализация метода Usd2Rub — преобразование суммы в долларах в сумму в рублях — показана ниже:

Public Class ExchangeRateService  
      Inherits System.Web.Services.WebService  
   
Public Function <WebMethod()> Usd2Rub _  
       (ByVal Value As Double) As String  
        Usd2Rub = CStr(Value * 30)  
End Function  
   
End Class  

После создания Web-сервиса вызовем команду Build (выбрав опцию Release) для генерации необходимого кода и внедрения сервиса на Web-сервер. Теперь можно испытать наш сервис в действии. Для этого необходимо запустить Web-браузер и указать адрес, который был указан в панели New Project — Project will be created…

В нашем примере это будет http://terra/mywebservice/ (см. рис. 6). После этого указываем имя класса (в нашем примере — это ExchangeRateService) и расширение ASMX (Assembly). Полный адрес для запуска нашего сервиса будет выглядеть так:

http://terra/mywebservice/ExchangeRateService.asmx

В результате мы получаем тестовую страницу, созданную Visual Studio.NET (рис. 7).

Данная страница содержит описание Web-сервиса, а также список реализованных в нем методов. Например, описание метода Usd2Rub показано на рис. 8.

Введя в строке ввода какую-либо сумму и нажав кнопку Invoke, мы вызовем сервис нашего Web-метода с указанным параметром и получим следующий результирующий XML-документ:

<?xml version=”1.0" ?> 
  <string xmlns=”http://tempuri.org/”>1048.5</string> 

Завершая краткое описание создания Web-сервисов, отметим, что тестовая страница создается на основе информации, хранимой в SDL-файле, который можно просмотреть, указав параметр ?SDL в адресной строке браузера:

http://www.terra/mywebservice/ExchangeRateService.asmx?SDL

Для запуска Web-сервиса из приложения следует использовать следующий URL:

http://www.terra/mywebservice/exchangerateservice.asmx/Usd2Rub?Value=34.95

Обратите внимание также на то, что имя метода указывается после символа «/», а параметр — как обычный параметр URL-строки.

В начало В начало

Заключение

В данном обзоре мы рассмотрели Web-сервисы — новую технологию интеграции Web-приложений. Мы кратко рассказали об истории развития Web, ознакомились с сервис-ориентированным Web, рассмотрели концепцию Web-сервисов и стандарты, их описывающие. Мы также представили вам средства разработки Web-сервисов и рассмотрели, как концепция Web-сервисов поддерживается в Microsoft Visual Studio.NET.

КомпьютерПресс 6'2001