Учебники

1) Архитектура и введение

Октябрь 16, 2019

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

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

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

В этом уроке вы узнаете

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

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

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

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

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

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

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

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

Мы обсудим «WDSL» подробно в этом уроке .

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

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

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

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

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

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

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

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

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

  3. Стандартизированный протокол, который все понимают — веб-сервисы используют стандартизированный промышленный протокол для связи. Все четыре уровня (уровни транспорта служб, сообщений XML, описания служб и обнаружения служб) используют четко определенные протоколы в стеке протоколов веб-служб.

  4. Снижение стоимости связи — веб-сервисы используют протокол SOAP поверх HTTP, поэтому вы можете использовать свой существующий недорогой интернет для реализации веб-сервисов.

Архитектура веб-сервиса

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

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

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

Архитектура веб-сервиса и введение

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

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

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

  1. Они основаны на XML — веб-сервисы используют XML для представления данных на уровнях представления и транспортировки данных. Использование XML устраняет любые зависимости от сетей, операционных систем или платформ, поскольку XML является общим языком, понятным всем.

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

  3. Синхронная или асинхронная функциональность. Синхронность относится к привязке клиента к выполнению службы. В синхронных операциях клиент фактически будет ожидать завершения операции веб-службой. Примером этого, вероятно, является сценарий, в котором выполняются операции чтения и записи в базу данных. Если данные считываются из одной базы данных и впоследствии записываются в другую, то операции должны выполняться последовательно. Асинхронные операции позволяют клиенту вызывать службу и затем параллельно выполнять другие функции. Это один из наиболее распространенных и, вероятно, наиболее предпочтительных методов обеспечения того, чтобы другие службы не останавливались при выполнении определенной операции.

  4. Возможность поддержки удаленных вызовов процедур (RPC) — веб-службы позволяют клиентам вызывать процедуры, функции и методы для удаленных объектов с использованием протокола на основе XML. Удаленные процедуры предоставляют входные и выходные параметры, которые должен поддерживать веб-сервис.

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

 

111
Share: