Урок за 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.

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

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

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

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

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

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

Пример за прост SOAP услуга от сложен тип е показан по-долу. Да предположим, че искаме да изпратим структуриран тип данни, който съдържа комбинация от „Име на урок“ и „Урок“. Description“, тогава бихме дефинирали комплексния тип, както е показано по-долу. Комплексният тип се дефинира от тага на елемента Всички необходими елементи на структурата, заедно със съответните им типове данни, след това се дефинират в колекцията от сложни типове.

<xsd:complexType>
   <xsd:sequence>
      <xsd:element name="Tutorial Name" type="string"/>
      <xsd:element name="Tutorial Description" type="string"/>
   </xsd:sequence>
</xsd:complexType>

A 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 съобщение и да видим какво всъщност прави всеки елемент.

1. Както се вижда от горното SOAP съобщение, първата част от SOAP съобщението е елементът на обвивката, който се използва за капсулиране на цялото SOAP съобщение.
2. Следващият елемент е тялото на SOAP, което съдържа подробности за действителното съобщение.
3. Нашето съобщение съдържа уеб услуга, която има името „Guru99УебСервиз“.
4. "Guru„99Webservice“ приема параметър от тип „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 уеб услуга, върнатият отговор може да бъде в два вида: успешен отговор или отговор за грешка. Когато се генерира успех, отговорът от сървъра винаги ще бъде SOAP съобщение. Но ако се генерират SOAP грешки, те се връщат като грешки „HTTP 500“.

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

1. <faultCode> – Това е кодът, който обозначава кода на грешката. Кодът за грешка може да бъде една от следните стойности:
   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 клиентът просто извиква методите в своята заявка и изпраща необходимите параметри на сървъра, а сървърът след това изпраща желания отговор.

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

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

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

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

Практически 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 щракнете върху опцията от менюто Файл->Нов проект.

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

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

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

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

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

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

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

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

Code Обяснение:

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

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

Изход:

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

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

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

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

Code Обяснение:

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

<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>

Code Обяснение:

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

Въпроси и Отговори