Что такое веб-службы? 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 и т. д.

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

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

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

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

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

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

Универсальное описание, обнаружение и интеграция (UDDI)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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