Что такое веб-службы? Archiтектура, Типы, Пример

Что такое веб-сервис?

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

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

Как работают веб-сервисы?

Как работают веб-сервисы
Как работают веб-сервисы

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

Эти запросы выполняются посредством так называемых удаленных вызовов процедур. Удаленные вызовы процедур (RPC) — это вызовы методов, размещенных на соответствующем веб-сервисе.

В качестве примера, Amazon предоставляет веб-сервис, который предоставляет цены на продукты, продаваемые онлайн через amazon.com. Интерфейс или уровень представления могут быть в .Net или Java но любой язык программирования будет иметь возможность взаимодействовать с веб-сервисом.

Основным компонентом дизайна веб-сервиса являются данные, которые передаются между клиентом и сервером, и это XML. XML (расширяемый язык разметки) является аналогом HTML и простым для понимания промежуточным языком, который понимают многие языки программирования.

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

Веб-службы используют SOAP (простой протокол доступа к объектам) для отправки данных XML между приложениями. Данные передаются по обычному HTTP. Данные, которые отправляются из веб-службы в приложение, называются сообщением SOAP. Сообщение SOAP — это не что иное, как XML-документ. Поскольку документ написан в формате XML, клиентское приложение, вызывающее веб-сервис, может быть написано на любом языке программирования.

Зачем вам нужен веб-сервис?

Современные бизнес-приложения используют различные платформы программирования для разработки веб-приложений. Некоторые приложения могут быть разработаны в Java, другие в .Net, а некоторые в Angular JS, Node.js и т. д.

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

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

Тип веб-службы

В основном существует два типа веб-сервисов.

  1. Веб-сервисы SOAP.
  2. Веб-сервисы RESTful.

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

Давайте рассмотрим эти компоненты более подробно.

SOAP (простой протокол доступа к объектам)

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

Вот из чего состоит сообщение SOAP

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

На диаграмме ниже показан простой пример связи через SOAP.

SOAP-протокол

SOAP-протокол

Мы подробно обсудим SOAP в этом учебник.

WSDL (язык описания веб-сервисов)

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

Во-вторых, клиентское приложение должно знать, что на самом деле делает веб-служба, чтобы оно могло вызвать нужную веб-службу. Это делается с помощью WSDL, известного как язык описания веб-сервисов. Файл WSDL снова представляет собой файл на основе XML, который, по сути, сообщает клиентскому приложению, что делает веб-служба. Используя документ WSDL, клиентское приложение сможет понять, где находится веб-служба и как ее можно использовать.

Пример веб-сервиса

Ниже приведен пример файла WSDL для веб-служб.

<definitions>	
   <message name="TutorialRequest">
      <part name="TutorialID" type="xsd:string"/>
   </message>
     
   <message name="TutorialResponse">
      <part name="TutorialName" type="xsd:string"/>
   </message>

   <portType name="Tutorial_PortType">
      <operation name="Tutorial">
         <input message="tns:TutorialRequest"/>
         <output message="tns:TutorialResponse"/>
      </operation>
   </portType>

   <binding name="Tutorial_Binding" type="tns:Tutorial_PortType">
      <soap:binding style="rpc"
         transport="http://schemas.xmlsoap.org/soap/http"/>
      <operation name="Tutorial">
         <soap:operation soapAction="Tutorial"/>
         <input>
            <soap:body
               encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
               namespace="urn:examples:Tutorialservice"
               use="encoded"/>
         </input>
         
		 <output>
            <soap:body
               encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
               namespace="urn:examples:Tutorialservice"
               use="encoded"/>
         </output>
      </operation>
   </binding>
</definitions>

Важными аспектами приведенных выше примеров объявлений WSDL веб-служб являются следующие:

  1. – Параметр сообщения в определении WSDL используется для определения различных элементов данных для каждой операции, выполняемой веб-службой. Итак, в приведенных выше примерах веб-сервисов у нас есть два сообщения, которыми можно обмениваться между веб-сервисом и клиентским приложением: одно — «TutorialRequest», а другое — операция «TutorialResponse». TutorialRequest содержит элемент TutorialID, который имеет строковый тип. Аналогично, операция TutorialResponse содержит элемент TutorialName, который также является строкой типа.
  2. – На самом деле это описывает операцию, которую может выполнить веб-сервис, который в нашем случае называется Tutorial. Эта операция может обрабатывать 2 сообщения; одно является входным сообщением, а другое — выходным сообщением.
  3. – Этот элемент содержит используемый протокол. Итак, в нашем случае мы определяем использование http (http://schemas.xmlsoap.org/soap/http). Мы также указываем другие детали тела операции, такие как пространство имен и необходимость кодирования сообщения.

Мы подробно обсудим WDSL в этом разделе. учебник.

Universal Descriptион, обнаружение и интеграция (UDDI)

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

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

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

Преимущества веб-сервисов

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

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

  1. Раскрытие бизнес-функциональности в сети – Веб-сервис — это единица управляемого кода, которая предоставляет определенные функциональные возможности клиентским приложениям или конечным пользователям. Эту функцию можно активировать по протоколу HTTP, что означает, что ее также можно активировать через Интернет. В настоящее время все приложения находятся в Интернете, что делает назначение веб-сервисов более полезным. Это означает, что веб-сервис может находиться где угодно в Интернете и обеспечивать необходимую функциональность по мере необходимости.
  2. Взаимодействие между приложениями – Веб-сервисы позволяют различным приложениям взаимодействовать друг с другом и обмениваться данными и услугами между собой. Все типы приложений могут общаться друг с другом. Таким образом, вместо написания конкретного кода, который может быть понятен только конкретными приложениями, теперь вы можете написать общий код, понятный всем приложениям.
  3. Стандартизированный протокол, понятный каждому – Веб-сервисы используют стандартизированный отраслевой протокол для связи. Все четыре уровня (транспорт услуг, обмен сообщениями XML, сервис Description и Service Discovery) использует четко определенные протоколы в стеке протоколов веб-служб.
  4. Снижение стоимости связи – Веб-сервисы используют протокол SOAP поверх HTTP, поэтому вы можете использовать существующий недорогой Интернет для реализации веб-сервисов.

Web-сервисы Archiтекстура

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

  1. Разработчик – Поставщик создает веб-сервис и делает его доступным для клиентского приложения, которое хочет его использовать.
  2. Запрашивающий – Запрашивающая сторона – это не что иное, как клиентское приложение, которому необходимо связаться с веб-сервисом. Клиентское приложение может быть .Net, Javaили любое другое языковое приложение, которое ищет какую-либо функциональность через веб-службу.
  3. брокер – Брокер – это не что иное, как приложение, обеспечивающее доступ к UDDI. UDDI, как обсуждалось в предыдущем разделе, позволяет клиентскому приложению определять местонахождение веб-службы.

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

Web-сервисы Archiтекстура

Web-сервисы Archiтекстура
  1. Опубликовать – Поставщик информирует брокера (реестр услуг) о существовании веб-сервиса, используя интерфейс публикации брокера, чтобы сделать сервис доступным для клиентов.
  2. Найти – Запрашивающая сторона консультируется с брокером, чтобы найти опубликованный веб-сервис.
  3. связующее вещество – Используя информацию, полученную от брокера (реестра служб) о веб-службе, запрашивающая сторона может связать или вызвать веб-службу.

Характеристики веб-сервиса

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

  1. Они основаны на XML – Веб-службы используют XML для представления данных на уровнях представления и транспортировки данных. Использование XML устраняет любую зависимость от сети, операционной системы или платформы, поскольку XML — это общий язык, понятный всем.
  2. Слабо связанный – Слабая связь означает, что клиент и веб-служба не связаны друг с другом, а это означает, что даже если веб-служба меняется со временем, это не должно менять способ вызова веб-службы клиентом. Принятие слабосвязанной архитектуры делает программные системы более управляемыми и упрощает интеграцию между различными системами.
  3. Syncхроническая или асинхронная функциональность – Syncхроничность относится к привязке клиента к выполнению сервиса. В синхронных операциях клиент фактически будет ждать, пока веб-сервис завершит операцию. Примером этого, вероятно, является сценарий, в котором выполняются операции чтения и записи базы данных. Если данные считываются из одной базы данных и затем записываются в другую, то операции должны выполняться последовательно. Асинхронные операции позволяют клиенту вызывать сервис, а затем выполнять другие функции параллельно. Это один из распространенных и, вероятно, наиболее предпочтительных методов обеспечения того, чтобы другие сервисы не останавливались при выполнении определенной операции.
  4. Возможность поддержки удаленных вызовов процедур (RPC). – Веб-службы позволяют клиентам вызывать процедуры, функции и методы удаленных объектов с использованием протокола на основе XML. Удаленные процедуры предоставляют входные и выходные параметры, которые должна поддерживать веб-служба.
  5. Поддерживает обмен документами – Одним из ключевых преимуществ XML является его универсальный способ представления не только данных, но и сложных документов. Эти документы могут быть такими же простыми, как текущий адрес, или такими сложными, как целая книга.