Урок за SOAP уеб услуги: Какво е SOAP протокол? ПРИМЕР

Какво е SOAP?

SOAP е базиран на XML протокол за достъп до уеб услуги през HTTP. Има някои спецификации, които могат да се използват във всички приложения.

SOAP е известен като Simple Object Access Protocol, но в по-късни времена беше просто съкратен до SOAP v1.2. SOAP е протокол или с други думи е дефиниция за това как уеб услугите си говорят помежду си или с клиентски приложения, които ги извикват.

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

Въведение в SOAP

В днешния свят има огромен брой приложения, които са изградени на различни езици за програмиране. Например, може да има уеб приложение, проектирано в Java, друг в .Net и още един в PHP.

Обменът на данни между приложения е от решаващо значение в днешния мрежов свят. Но обменът на данни между тези хетерогенни приложения би бил сложен. Така ще бъде и сложността на кода за осъществяване на този обмен на данни.

Един от методите, използвани за борба с тази сложност, е използването на XML (Extensible Markup Language) като междинен език за обмен на данни между приложения.

Всеки език за програмиране може да разбере езика за маркиране на XML. Следователно XML беше използван като основна среда за обмен на данни.

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

SOAP е проектиран да работи с XML през HTTP и има някаква спецификация, която може да се използва във всички приложения. Ще разгледаме допълнителни подробности за SOAP протокола в следващите глави.

Предимства на SOAP

SOAP е протоколът, използван за обмен на данни между приложения. По-долу са някои от причините, поради които се използва SOAP.

  • Когато разработвате SOAP базирани уеб услуги, трябва да имате някакъв език, който може да се използва за уеб услуги за комуникация с клиентски приложения. SOAP е перфектната среда, разработена за постигане на тази цел. Този протокол се препоръчва и от консорциума W3C, който е ръководният орган за всички уеб стандарти.
  • SOAP е лек протокол, който се използва за обмен на данни между приложения. Обърнете внимание на ключовата дума „светлина.' Тъй като програмирането на SOAP се основава на езика XML, който сам по себе си е лек език за обмен на данни, следователно SOAP като протокол, който също попада в същата категория.
  • SOAP е проектиран да бъде независим от платформата и също така е проектиран да бъде независим от операционната система. Така че протоколът SOAP може да работи с всяко приложение, базирано на език за програмиране и на двете Windows намлява Linux платформа.
  • Работи по HTTP протокола – SOAP работи по HTTP протокола, който е протоколът по подразбиране, използван от всички уеб приложения. Следователно няма персонализиране, което да се изисква, за да стартирате уеб услугите, изградени върху протокола SOAP, за да работят в World Wide Web.

SOAP градивни блокове

Спецификацията на SOAP дефинира нещо, известно като „SOAP съобщение”, което е това, което се изпраща до уеб услугата и клиентското приложение.

Диаграмата по-долу на SOAP архитектурата показва различните градивни елементи на едно SOAP съобщение.

SOAP градивни блокове
Изграждащи блокове за SOAP съобщения

SOAP съобщението не е нищо друго освен обикновен XML документ, който има следните компоненти.

  • Елемент Envelope, който идентифицира XML документа като SOAP съобщение – Това е съдържащата част от SOAP съобщението и се използва за капсулиране на всички подробности в SOAP съобщението. Това е основният елемент в SOAP съобщението.
  • Заглавен елемент, който съдържа заглавна информация – Заглавният елемент може да съдържа информация като идентификационни данни за удостоверяване, които могат да се използват от извикващото приложение. Може също да съдържа дефиницията на сложни типове, които могат да се използват в SOAP съобщението. По подразбиране SOAP съобщението може да съдържа параметри, които могат да бъдат от прости типове като низове и числа, но могат да бъдат и сложен тип обект.

Пример за проста SOAP услуга от сложен тип е показан по-долу.

Да предположим, че искаме да изпратим структуриран тип данни, който има комбинация от „Име на урок“ и „Руководство Descriptйон”, тогава бихме дефинирали комплексния тип, както е показано по-долу.

Сложният тип се определя от етикета на елемента . След това всички необходими елементи на структурата заедно със съответните им типове данни се дефинират в колекцията от сложни типове.

<xsd:complexType>     
 <xsd:sequence>       
 	<xsd:element name="Tutorial Name" type="string"/>         
  	<xsd:element name="Tutorial Description"  type="string"/>
  </xsd:sequence>
</xsd:complexType>
  • Елемент Body, който съдържа информация за повикване и отговор – Този елемент съдържа действителните данни, които трябва да бъдат изпратени между уеб услугата и извикващото приложение. По-долу е пример за SOAP уеб услуга на тялото на SOAP, което всъщност работи върху сложния тип, дефиниран в секцията за заглавка. Ето отговора на името на урока и урока Descriptйон, който се изпраща до извикващото приложение, което извиква тази уеб услуга.
<soap:Body>
   <GetTutorialInfo>
		<TutorialName>Web Services</TutorialName> 
		<TutorialDescription>All about web services</TutorialDescription> 
   </GetTutorialInfo>
</soap:Body>

Структура на SOAP съобщение

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

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

Както беше обсъдено в предишната тема на този SOAP урок, едно просто SOAP съобщение има следните елементи –

  • Елементът Envelope
  • Заглавният елемент и
  • Елементът на тялото
  • Елементът за грешка (по избор)

Нека да разгледаме пример по-долу за просто SOAP съобщение и да видим какво всъщност прави елементът.

Структура на SOAP съобщение

Структура на SOAP съобщение
  1. Както се вижда от горното SOAP съобщение, първата част от SOAP съобщението е елементът на обвивката, който се използва за капсулиране на цялото SOAP съобщение.
  2. Следващият елемент е тялото на SOAP, което съдържа подробности за действителното съобщение.
  3. Нашето съобщение съдържа уеб услуга с името „Guru99WebService“.
  4. “Guru99Webservice” приема параметър от типа 'int' и има име TutorialID.

Сега горното SOAP съобщение ще бъде предадено между уеб услугата и клиентското приложение.

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

SOAP Envelope Element

Първият елемент от градивния елемент е SOAP Envelope.

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

Елементът SOAP envelope се използва за указване на началото и края на SOAP съобщение. Това позволява на клиентското приложение, което извиква уеб услугата, да знае кога приключва SOAP съобщението.

Следните точки могат да бъдат отбелязани върху елемента SOAP envelope.

  • Всяко SOAP съобщение трябва да има основен елемент Envelope. Абсолютно задължително е SOAP съобщението да има елемент envelope.
  • Всеки елемент Envelope трябва да има поне един елемент от сапунено тяло.
  • Ако елемент Envelope съдържа заглавен елемент, той не трябва да съдържа повече от един и трябва да се показва като първия дъщерен елемент на Envelope, преди елемента body.
  • Пликът се променя, когато версиите на SOAP се променят.
  • SOAP процесор, съвместим с v1.1, генерира грешка при получаване на съобщение, съдържащо пространството от имена на плика v1.2.
  • SOAP процесор, съвместим с v1.2, генерира грешка за несъответствие на версията, ако получи съобщение, което не включва пространството от имена на плика v1.2.

По-долу е пример за SOAP API на версия 1.2 на елемента SOAP envelope.

<?xml version="1.0"?>
<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://www.w3.org/2001/12/soap-envelope" SOAP-ENV:encodingStyle=" http://www.w3.org/2001/12/soap-encoding">
          <soap:Body>
        <Guru99WebService xmlns="http://tempuri.org/">
                  <TutorialID>int</TutorialID>
                </Guru99WebService>
          </soap:Body>
</SOAP-ENV:Envelope>

Съобщението за грешка

Когато се направи заявка към SOAP уеб услуга, върнатият отговор може да бъде от 2 форми, които са успешен отговор или отговор за грешка. Когато се генерира успех, отговорът от сървъра винаги ще бъде SOAP съобщение. Но ако се генерират SOAP грешки, те се връщат като грешки „HTTP 500“.

Съобщението за SOAP грешка се състои от следните елементи.

  1. – Това е кодът, който обозначава кода на грешката. Кодът за повреда може да бъде една от следните стойности
    1. SOAP-ENV:VersionMismatch – Това е, когато се срещне невалидно пространство от имена за елемента SOAP Envelope.
    2. SOAP-ENV:MustUnderstand – Непосредствен дъщерен елемент на елемента Header с атрибута mustUnderstand, зададен на „1“, не беше разбран.
    3. SOAP-ENV:Клиент – Съобщението е неправилно формирано или съдържа неправилна информация.
    4. SOAP-ENV:Сървър – Имаше проблем със сървъра, така че съобщението не можа да продължи.
  2. – Това е текстовото съобщение, което дава подробно описание на грешката.
  3. (по избор)– Това е текстов низ, който показва кой е причинил грешката.
  4. (по избор) – Това е елементът за съобщения за грешка, специфични за приложението. Така че приложението може да има конкретно съобщение за грешка за различни сценарии на бизнес логика.

Пример за съобщение за грешка

Пример за съобщение за грешка е даден по-долу. Грешката се генерира, ако сценарият, при който клиентът се опитва да използва метод, наречен TutorialID в класа GetTutorial.

Съобщението за грешка по-долу се генерира в случай, че методът не съществува в дефинирания клас.

<?xml version='1.0' encoding='UTF-8'?>
<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance" xmlns:xsd="http://www.w3.org/1999/XMLSchema">
      <SOAP-ENV:Body>
         <SOAP-ENV:Fault>
         <faultcode xsi:type="xsd:string">SOAP-ENV:Client</faultcode>
        <faultstring xsi:type="xsd:string">
            Failed to locate method (GetTutorialID) in class (GetTutorial)
         </faultstring>
    </SOAP-ENV:Fault>
   </SOAP-ENV:Body>
</SOAP-ENV:Envelope>

Изход:

Когато изпълните горния код, той ще покаже грешка като „Неуспешно намиране на метод (GetTutorialID) в клас (GetTutorial)“

SOAP комуникационен модел

Цялата комуникация чрез SOAP се извършва чрез HTTP протокола. Преди SOAP, много уеб услуги използва стандартния RPC (Remote Procedure Call) стил за комуникация. Това беше най-простият тип комуникация, но имаше много ограничения.

Сега в този урок за SOAP API, нека разгледаме диаграмата по-долу, за да видим как работи тази комуникация. В този пример нека приемем, че сървърът хоства уеб услуга, която предоставя 2 метода като

  • GetEmployee – Това ще получи всички подробности за служителите
  • SetEmployee – Това ще зададе съответно стойността на детайлите като служители, заплата и т.н.

При нормална комуникация в стил RPC клиентът просто извиква методите в своята заявка и изпраща необходимите параметри на сървъра, а сървърът след това изпраща желания отговор.

SOAP комуникационен модел

Горният комуникационен модел има следните сериозни ограничения

  1. Не е независим от езика – Сървърът, хостващ методите, ще бъде на конкретен език за програмиране и обикновено извикванията към сървъра ще бъдат само на този език за програмиране.
  2. Не е стандартният протокол – Когато се осъществи повикване към отдалечената процедура, повикването не се осъществява по стандартния протокол. Това беше проблем, тъй като най-вече цялата комуникация в мрежата трябваше да се извършва чрез HTTP протокола.
  3. Защитните стени – Тъй като RPC повикванията не преминават през нормалния протокол, отделни портове трябва да бъдат отворени на сървъра, за да се позволи на клиента да комуникира със сървъра. Обикновено всички защитни стени биха блокирали този вид трафик и обикновено се изискваше много конфигурация, за да се гарантира, че този вид комуникация между клиента и сървъра ще работи.

За да преодолее всички ограничения, цитирани по-горе, SOAP ще използва следния комуникационен модел

SOAP комуникационен модел

  1. Клиентът ще форматира информацията относно извикването на процедурата и всички аргументи в SOAP съобщение и ще го изпрати на сървъра като част от HTTP заявка. Този процес на капсулиране на данните в SOAP съобщение е известен като Маршалиране.
  2. След това сървърът ще разопакова съобщението, изпратено от клиента, ще види какво е поискал клиентът и след това ще изпрати съответния отговор обратно на клиента като SOAP съобщение. Практиката за разопаковане на заявка, изпратена от клиента, е известна като Демаршалинг.

Практически SOAP пример

Сега в този урок за SoapUI нека видим практичен пример за SOAP,

Вероятно един от най-добрите начини да видите как се генерират SOAP съобщения е действително да видите уеб услуга в действие.

Тази тема ще разгледа използването на Microsoft.Net framework за изграждане на ASMX уеб услуга. Този тип уеб услуга поддържа SOAP версия 1.1 и версия 1.2.

Уеб услугите на ASMX автоматично генерират Език за дефиниране на уеб услуги (WSDL) документ. Този WSDL документ се изисква от извикващото клиентско приложение, така че приложението да знае какво може да прави уеб услугата.

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

Тази уеб услуга ще бъде хоствана в Asp.Net уеб приложение. След това ще извикаме уеб услугата и ще видим резултата, който се връща от уеб услугата.

Visual Studio също ще ни покаже какво SOAP съобщение се предава между уеб услугата и извикващото приложение.

Първата предпоставка за настройка на нашето приложение за уеб услуги, което може да се направи, като следвате стъпките по-долу.

Моля, уверете се, че имате инсталиран Visual Studio 2013 на вашата система за този пример.

Стъпка 1) Първата стъпка е да създадете празно уеб приложение ASP.Net. От Visual Studio 2013 щракнете върху опцията от менюто Файл->Нов проект.

Пример за SOAP съобщение

След като щракнете върху опцията Нов проект, Visual Studio ще ви даде друг диалогов прозорец за избор на типа проект и за предоставяне на необходимите подробности за проекта. Това е обяснено в следващата стъпка.

Стъпка 2) В този етап,

  1. Уверете се, че първо изберете C# уеб шаблон на уеб приложение ASP.NET. Проектът трябва да бъде от този тип, за да създадете проект за SOAP услуги. Избирайки тази опция, Visual Studio ще извърши необходимите стъпки за добавяне на необходимите файлове, които се изискват от всяко уеб базирано приложение.
  2. Дайте име за вашия проект, което в нашия случай е дадено като webservice.asmx. След това се уверете, че сте посочили място, където ще се съхраняват файловете на проекта.

Пример за SOAP съобщение

След като приключите, ще видите файла на проекта, създаден във вашия изследовател на решения във Visual Studio 2013.

Пример за SOAP съобщение

Стъпка 3) В този етап,

Ще добавим файл на уеб услуга към нашия проект

  1. Първо щракнете с десния бутон върху файла на проекта, както е показано по-долу

Пример за SOAP съобщение

  1. След като щракнете с десния бутон върху файла на проекта, имате възможност да изберете опцията „Добавяне->Уеб услуга(ASMX), за да добавите файл на уеб услуга. Просто предоставете име на Tutorial Service за файла с името на уеб услугата.

Пример за SOAP съобщение

Стъпка 4) Добавете следния код към вашия asmx файл на Tutorial Service.

Пример за SOAP съобщение

Обяснение на кода:

  1. Този ред код предоставя име за файла на вашата уеб услуга. Това е важна стъпка, защото дава възможност на клиентското приложение да извика уеб услугата чрез името на уеб услугата.
  2. Обикновено файлът на класа се използва за капсулиране на функционалността на уеб услуга. Така файлът на класа ще има дефиницията на всички уеб методи, които ще осигурят известна функционалност на клиентското приложение.
  3. Тук [WebMethod] е известен като атрибут, който описва функция. Следващата стъпка създава функция, наречена „Guru99WebService“, но с включването на тази стъпка на добавяне на атрибут [WebMethod] гарантира, че този метод може да бъде извикан от клиентско приложение. Ако този атрибут не е на място, тогава методът никога не може да бъде извикан от клиентско приложение.
  4. Тук дефинираме функция, наречена „Guru99WebService“, която ще се използва за връщане на низ към извикващото клиентско приложение. Тази функция е уеб услуга, която може да бъде извикана от всяко клиентско приложение.
  5. Използваме оператора return, за да върнем низа „Това е уеб услуга на Guru99“ на клиентското приложение.

Ако кодът се изпълни успешно, ще се покаже следният изход, когато стартирате кода си в браузъра.

Изход:

Пример за SOAP съобщение

  • Резултатът ясно показва, че името на нашата уеб услуга е „Guru99 Web Service“, което е резултат от даването на име за нашата уеб услуга.
  • Можем също да видим, че можем да извикаме уеб услугата. Ако щракнете върху бутона Извикване, ще получим следния отговор в уеб браузъра.

Пример за SOAP съобщение

Горният изход,

  • Ясно показва, че чрез извикване на уеб метода се връща низът „Това е уеб услуга на Guru99“.
  • Visual Studio също ви позволява да видите заявката за SOAP съобщение и отговора, който се генерира при извикване на горната уеб услуга.

SOAP заявката, която се генерира при извикване на уеб услугата, е показана по-долу.

Пример за SOAP съобщение

Обяснение на кода:

  1. Първата част от SOAP съобщението е елементът envelope, който беше обсъден в предишните глави. Това е капсулиращият елемент, който присъства във всяко SOAP съобщение.
  2. SOAP Body е следващият елемент и съдържа действителните подробности за SOAP съобщението.
  3. Третата част е елементът, който указва, че искаме да извикаме услугата, която се нарича „Guru99WebService“.

Пример за SOAP съобщение

<soap:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
  
    <soap:Body>
      
        <Guru99WebServiceResponse xmlns="http://tempuri.org/">
          
            <Guru99WebServiceResult>string</Guru99WebServiceResult>
          
        </Guru99WebServiceResponse>
    </soap:Body>
</soap:Envelope>

Обяснение на кода:

  1. Първата част от SOAP съобщението е елементът envelope, който беше обсъден в предишните глави. Това е капсулиращият елемент, който присъства във всяко SOAP съобщение.
  2. SOAP Body е следващият елемент и съдържа действителните подробности за SOAP съобщението.
  3. Интересната част, която ще видите сега, е атрибутът 'string'. Това казва на клиентското приложение, че извикваната уеб услуга връща обект от типа низ. Това е много полезно, защото ако клиентското приложение, което иначе не би знаело какво връща уеб услугата.

Oбобщение

  • SOAP е протокол, който се използва за обмен на данни между приложения, които са изградени върху различни програмни езици.
  • SOAP е изграден върху XML спецификацията и работи с HTTP протокола. Това го прави идеален за използване в уеб приложения.
  • SOAP градивните елементи се състоят от SOAP съобщение. Всяко SOAP съобщение се състои от елемент на обвивката, заглавка и елемент на тялото.
  • Елементът envelope е задължителният елемент в SOAP съобщението и се използва за капсулиране на всички данни в SOAP съобщението.
  • Заглавният елемент може да се използва за съдържане на информация като информация за удостоверяване или дефиниция на сложни типове данни.
  • Елементът body е основният елемент, който съдържа дефиницията на уеб методите заедно с всяка информация за параметрите, ако е необходимо.

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