Какво представляват уеб услугите? Archiструктура, типове, пример

⚡ Умно обобщение

Уеб услугите предоставят стандартизирана среда за комуникация между клиентски и сървърни приложения през световната мрежа. Този ресурс обяснява как работят уеб услугите, техните SOAP и RESTful типове, компонентите на WSDL и UDDI, архитектурните роли и ключовите характеристики.

  • 🌐 Основна дефиниция: Уеб услугата е самостоятелен софтуерен модул, който изпълнява определена задача и комуникира между клиент и сървър през интернет.
  • 📨 XML съобщения: Уеб услугите обменят данни като XML, обикновено обвити в SOAP съобщения, изпращани през стандартен HTTP, така че всеки език може да ги използва.
  • 🧱 Основни компоненти: Функционалната уеб услуга разчита на SOAP за обмен на съобщения, WSDL за описание на услугата и UDDI за публикуването и откриването ѝ.
  • 👥 ArchiРоли на тектурата: Архитектурата определя три роли – Доставчик, Заявител и Брокер – които публикуват, намират и обвързват услуги чрез регистър.
  • Основни характеристики: Уеб услугите са базирани на XML, слабо свързани, поддържат синхронни или асинхронни повиквания, активират RPC и позволяват обмен на богати документи.

Уеб услуги Archiтекстура

Какво е уеб услуга?

Уеб услуга е стандартизирана среда за разпространение на комуникация между клиентските и сървърните приложения в WWW (World Wide Web). Уеб услугата е софтуерен модул, предназначен да изпълнява определен набор от задачи.

  • Уеб услугите в облачните изчисления могат да бъдат търсени в мрежата и съответно да бъдат извиквани.
  • Когато бъде извикана, уеб услугата ще може да предостави функционалността на клиента, който извиква тази уеб услуга.

Как работят уеб услугите?

Как работят уеб услугите

Горната диаграма показва много опростен изглед на това как една уеб услуга действително би работила. Клиентът ще извика поредица от извиквания на уеб услуга чрез заявки към сървър, който ще хоства действителната уеб услуга.

Тези заявки се правят чрез така наречените отдалечени процедурни извиквания. Отдалечените процедурни извиквания (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Език за програмиране. 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“ подробно в това настойнически.

Универсален Description, Discovery и Integration (UDDI)

UDDI е стандарт за описване, публикуване и откриване на уеб услугите, които се предоставят от определен доставчик на услуги. Той предоставя спецификация, която помага при хостването на информацията в уеб услугите.

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

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

Предимства на уеб услугите

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

  1. Разкриване на бизнес функционалност в мрежата – Уеб услугата е единица управляван код, която предоставя някакъв вид функционалност на клиентски приложения или крайни потребители. Тази функционалност може да бъде извикана през HTTP протокола, което означава, че може да бъде извикана и през интернет. В днешно време всички приложения са в интернет, което прави целта на уеб услугите по-полезна. Това означава, че уеб услугата може да бъде навсякъде в интернет и да предоставя необходимата функционалност, когато се изисква.
  2. Оперативна съвместимост между приложенията – Уеб услугите позволяват на различни приложения да комуникират помежду си и да споделят данни и услуги помежду си. Всички видове приложения могат да комуникират помежду си. Така че, вместо да пишете специфичен код, който може да бъде разбран само от конкретни приложения, вече можете да пишете общ код, който може да бъде разбран от всички приложения.
  3. Стандартизиран протокол, който всеки разбира – Уеб услугите използват стандартизиран индустриален протокол за комуникация. Всичките четири слоя (транспорт на услуги, XML съобщения, Descriptслоевете ion и Service Discovery) използват добре дефинирани протоколи в стека от протоколи за уеб услуги.
  4. Намаляване на разходите за комуникация – Уеб услугите използват SOAP през HTTP протокол, така че можете да използвате вашия съществуващ евтин интернет за внедряване на уеб услуги.

Уеб услуги Archiтекстура

Всяка рамка се нуждае от някаква архитектура, за да гарантира, че цялата рамка работи както е желано. По подобен начин, в уеб услугите, Уеб услуги Archiтекстура състои се от три отделни роли, както е посочено по-долу:

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

Диаграмата по-долу показва как доставчикът на услуги, заявителя на услуги и регистърът на услугите взаимодействат помежду си.

Уеб услуги Archiтекстура

  1. Публикувам – Доставчикът информира брокера (регистъра на услугите) за съществуването на уеб услугата, като използва интерфейса за публикуване на брокера, за да направи услугата достъпна за клиентите.
  2. Какво – Заявителят се консултира с брокера, за да намери публикувана уеб услуга.
  3. Вържи – С информацията, получена от брокера (регистъра на услугите) за уеб услугата, заявката може да обвърже или извика уеб услугата.

Характеристики на уеб услугата

Уеб услугите имат следните специални поведенчески характеристики:

  1. Те са базирани на XML – Уеб услугите използват XML за представяне на данните на слоевете за представяне и транспортиране на данни. Използването на XML елиминира всякаква зависимост от мрежа, операционна система или платформа, тъй като XML е общият език, разбираем от всички.
  2. Слабо свързани – Слабо свързано означава, че клиентът и уеб услугата не са обвързани една с друга, което означава, че дори ако уеб услугата се промени с течение на времето, това не трябва да променя начина, по който клиентът извиква уеб услугата. Приемането на слабо свързана архитектура прави софтуерните системи по-управляеми и позволява по-проста интеграция между различни системи.
  3. Syncхронична или асинхронна функционалност - 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, за да разберат наличните операции и формати на съобщения.

Обобщете тази публикация с: