Що таке веб-служби? Archiтектура, типи, приклад

⚡ Розумний підсумок

Веб-сервіси забезпечують стандартизоване середовище для взаємодії клієнтських і серверних програм через Всесвітню павутину. У цьому ресурсі пояснюється, як працюють веб-сервіси, їхні типи SOAP та RESTful, компоненти WSDL та UDDI, ролі архітектури та ключові характеристики.

  • 🌐 Основне визначення: Веб-сервіс — це автономний програмний модуль, який виконує визначене завдання та взаємодіє між клієнтом і сервером через Інтернет.
  • 📨 XML-повідомлення: Веб-сервіси обмінюються даними у форматі XML, зазвичай обгорнутими в SOAP-повідомлення, що надсилаються через стандартний HTTP, тому будь-яка мова може їх використовувати.
  • 🧱 Основні компоненти: Функціональний веб-сервіс використовує SOAP для обміну повідомленнями, WSDL для опису сервісу та UDDI для його публікації та виявлення.
  • 👥 ArchiРолі в текстурі: Архітектура визначає три ролі — Постачальник, Запитувач і Брокер — які публікують, знаходять та прив’язують сервіси через реєстр.
  • ️ Основні характеристики: Веб-сервіси базуються на XML, слабо пов'язані, підтримують синхронні або асинхронні виклики, дозволяють використовувати RPC та забезпечують обмін документами з широким спектром функцій.

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

Що таке веб-сервіс?

Веб-сервіс це стандартизоване середовище для поширення зв’язку між клієнтськими та серверними програмами у WWW (Всесвітній павутині). Веб-сервіс — це програмний модуль, призначений для виконання певного набору завдань.

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

Як працюють веб-сервіси?

Як працюють веб-сервіси

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

Ці запити здійснюються через так звані виклики віддалених процедур. Виклики віддалених процедур (RPC) – це виклики методів, розміщених у відповідному веб-сервісі.

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

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

Отже, коли програми взаємодіють одна з одною, вони фактично взаємодіють у XML. Це забезпечує спільну платформу для взаємодії програм, розроблених різними мовами програмування.

Веб-служби використовують протокол SOAP (Simple Object Access Protocol) для надсилання 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 підручник.

WSDL (веб-сервіси Descriptіонна мова)

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

По-друге, клієнтська програма повинна знати, що насправді робить веб-сервіс, щоб вона могла викликати правильний веб-сервіс. Це робиться за допомогою WSDL, відомого як веб-сервіси. DescriptМова ion. Файл 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. – Це фактично описує операцію, яку може виконати веб-сервіс, що в нашому випадку називається Tutorial (Посібник). Ця операція може приймати 2 повідомлення: одне – вхідне, а інше – вихідне.
  3. – Цей елемент містить протокол, який використовується. Тож у нашому випадку ми визначаємо його для використання HTTP (http://schemas.xmlsoap.org/soap/http). Ми також вказуємо інші деталі для тіла операції, такі як простір імен та чи слід кодувати повідомлення.

Ми детально обговоримо «WSDL» у цій підручник.

Universal Descriptіон, відкриття та інтеграція (UDDI)

UDDI — це стандарт для опису, публікації та пошуку веб-служб, які надаються певним постачальником послуг. Він надає специфікацію, яка допомагає розміщувати інформацію у веб-службах.

У попередній темі ми обговорювали WSDL і те, як він містить інформацію про те, що насправді робить веб-служба. Але як клієнтська програма може знайти файл WSDL, щоб зрозуміти різні операції, які пропонує веб-служба? Тож UDDI є відповіддю на це питання та надає репозиторій, у якому можна розміщувати файли WSDL. Отже, клієнтська програма матиме повний доступ до UDDI, який діє як база даних, що містить усі файли WSDL.

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

Переваги веб-сервісів

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

  1. Розкриття бізнес-функціональності в мережі – Веб-сервіс – це одиниця керованого коду, яка надає певну функціональність клієнтським програмам або кінцевим користувачам. Цю функціональність можна викликати через протокол HTTP, а це означає, що її також можна викликати через Інтернет. Сьогодні всі програми знаходяться в Інтернеті, що робить призначення веб-сервісів більш корисним. Це означає, що веб-сервіс може бути будь-де в Інтернеті та надавати необхідну функціональність за потреби.
  2. Взаємодія між програмами – Веб-сервіси дозволяють різним програмам взаємодіяти одна з одною та обмінюватися даними й послугами. Усі типи програм можуть взаємодіяти одна з одною. Тож замість того, щоб писати специфічний код, який можуть зрозуміти лише певні програми, тепер можна писати універсальний код, який можуть зрозуміти всі програми.
  3. Стандартизований протокол, зрозумілий усім – Веб-сервіси використовують стандартизований галузевий протокол для зв’язку. Усі чотири рівні (транспортування сервісів, обмін повідомленнями XML, Descriptшари ion та Service Discovery) використовують чітко визначені протоколи у стеку протоколів веб-сервісів.
  4. Зниження вартості зв'язку – Веб-сервіси використовують протокол SOAP через HTTP, тому ви можете використовувати існуючий недорогий Інтернет для впровадження веб-сервісів.

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

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

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

На діаграмі нижче показано, як постачальник послуг, запитувач послуг та реєстр послуг взаємодіють один з одним.

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

  1. Публікувати – Постачальник інформує брокера (реєстр сервісів) про існування веб-сервісу, використовуючи інтерфейс публікації брокера, щоб зробити сервіс доступним для клієнтів.
  2. знайти – Запитувач звертається до брокера, щоб знайти опублікований веб-сервіс.
  3. Bind – За допомогою інформації, отриманої від брокера (реєстру сервісів) про веб-сервіс, запитувач може прив’язати або викликати веб-сервіс.

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

Веб-сервіси мають такі особливості поведінки:

  1. Вони засновані на XML – Веб-сервіси використовують XML для представлення даних на рівнях представлення та транспортування даних. Використання XML усуває будь-яку залежність від мережі, операційної системи чи платформи, оскільки XML є загальною мовою, зрозумілою всім.
  2. Слабко зчеплені – Слабко пов’язаний означає, що клієнт і веб-служба не пов’язані один з одним, що означає, що навіть якщо веб-служба змінюється з часом, це не повинно змінювати спосіб виклику клієнтом веб-служби. Прийняття слабозв’язаної архітектури робить програмні системи більш керованими та дозволяє простішу інтеграцію між різними системами.
  3. Synchronous або Asynchronous функціональність - Syncхронічність відноситься до прив'язки клієнта до виконання послуги. У синхронних операціях клієнт фактично чекатиме, поки веб-служба завершить операцію. Прикладом цього, ймовірно, є сценарій, у якому виконується операція читання та запису бази даних. Якщо дані зчитуються з однієї бази даних, а потім записуються в іншу, то операції повинні виконуватися послідовно. Асинхронні операції дозволяють клієнту викликати службу, а потім паралельно виконувати інші функції. Це один із поширених і, мабуть, найбільш бажаних методів для забезпечення того, щоб інші служби не зупинялися під час виконання певної операції.
  4. Можливість підтримки віддалених викликів процедур (RPC) – Веб-сервіси дозволяють клієнтам викликати процедури, функції та методи на віддалених об’єктах за допомогою протоколу на основі XML. Віддалені процедури надають вхідні та вихідні параметри, які має підтримувати веб-служба.
  5. Підтримує обмін документами – Однією з ключових переваг XML є його загальний спосіб представлення не лише даних, але й складних документів. Ці документи можуть бути такими ж простими, як поточна адреса, або такими ж складними, як ціла книга.

Поширені запитання

Моделі штучного інтелекту зазвичай постачаються як веб-сервіси, тому програми надсилають дані через HTTP та отримують прогнози у форматі XML або JSON. Штучний інтелект також може контролювати трафік веб-сервісів, виявляти аномалії та автоматично генерувати клієнтський код, що робить інтеграцію швидшою та надійнішою.

Так. Інструменти штучного інтелекту можуть генерувати визначення WSDL, пропонувати структури кінцевих точок, створювати тестові випадки та перевіряти відповіді SOAP або REST. Розробникам все одно слід переглядати вихідні дані, щоб переконатися в правильності...tracTS та правила безпеки правильні перед розгортанням.

SOAP — це суворий протокол обміну повідомленнями на основі XML із вбудованими стандартами безпеки та транзакцій. REST — це архітектурний стиль, який використовує прості методи HTTP та часто JSON. SOAP підходить для формальних корпоративних систем, тоді як REST є легшим та популярнішим для веб-API.

WSDL (веб-сервіси Description Language) — це XML-файл, який описує, що робить веб-сервіс, де він розташований і як його викликати. Клієнтські програми зчитують WSDL, щоб зрозуміти доступні операції та формати повідомлень.

Підсумуйте цей пост за допомогою: