Водич за СОАП веб услуге: Шта је СОАП протокол? ПРИМЕР

Шта је СОАП?

СОАП је протокол заснован на КСМЛ-у за приступ веб услугама преко ХТТП-а. Има неке спецификације које се могу користити у свим апликацијама.

СОАП је познат као протокол једноставног приступа објектима, али је у каснијим временима управо скраћен на СОАП в1.2. СОАП је протокол или другим речима је дефиниција начина на који веб услуге међусобно разговарају или разговарају са клијентским апликацијама које их позивају.

СОАП је развијен као средњи језик, тако да апликације изграђене на различитим програмским језицима могу лако да разговарају једна са другом и избегну екстремне напоре у развоју.

У овом упутству за СОАП веб услуге научићете-

• Увод у СОАП
• Предности СОАП-а
• СОАП Грађевински блокови
• Структура СОАП поруке
• Елемент коверте СОАП
• СОАП модел комуникације
• Пример практичног СОАП-а

Увод у СОАП

У данашњем свету постоји огроман број апликација које су изграђене на различитим програмским језицима. На пример, може постојати веб апликација дизајнирана на Јави, друга на. Нету и друга на ПХП-у.

Размена података између апликација пресудна је у данашњем умреженом свету. Али размена података између ових хетерогених апликација била би сложена. То ће бити и сложеност кода за постизање ове размене података.

Једна од метода која се користи за борбу против ове сложености је употреба КСМЛ (Ектенсибле Маркуп Лангуаге) као посредног језика за размену података између апликација.

Сваки програмски језик може да разуме КСМЛ језик за означавање. Отуда је КСМЛ коришћен као основни медијум за размену података.

Али не постоје стандардне спецификације за употребу КСМЛ-а у свим програмским језицима за размену података. Ту долази СОАП софтвер.

СОАП је дизајниран за рад са КСМЛ-ом преко ХТТП-а и има неку врсту спецификације која се може користити у свим апликацијама. Даље детаље о СОАП протоколу размотрићемо у наредним поглављима.

Предности СОАП-а

СОАП је протокол који се користи за размену података између апликација. Испод су неки од разлога зашто се користи СОАП.

• Када развијате веб услуге засноване на СОАП-у, морате да имате неки језик који може да се користи за веб услуге да разговарају са клијентским апликацијама. СОАП је савршен медијум који је развијен да би се постигла ова сврха. Овај протокол такође препоручује конзорцијум В3Ц који је управно тело за све веб стандарде.
• СОАП је лагани протокол који се користи за размену података између апликација. Обратите пажњу на кључну реч „ светло“ . Будући да се СОАП програмирање заснива на КСМЛ језику, који је сам по себи лак језик за размену података, отуда СОАП као протокол који такође спада у исту категорију.
• СОАП је дизајниран да буде неовисан о платформи и такође је дизајниран да буде независан од оперативног система. Дакле, СОАП протокол може радити са било којим апликацијама заснованим на програмском језику и на Виндовс и на Линук платформи.
• Ради на ХТТП протоколу -СОАП ради на ХТТП протоколу, који је задати протокол који користе све веб апликације. Стога не постоји врста прилагодбе која је потребна за покретање веб услуга изграђених на СОАП протоколу за рад на Ворлд Виде Вебу.

СОАП Грађевински блокови

Спецификација СОАП дефинише нешто што се назива „ СОАП порука “, а то је оно што се шаље веб услузи и клијентској апликацији.

Дијаграм доле СОАП архитектуре приказује различите градивне елементе СОАП поруке.

СОАП порука није ништа друго до пуки КСМЛ документ који садржи доленаведене компоненте.

• Елемент Енвелопе који идентификује КСМЛ документ као СОАП поруку - Ово је део СОАП поруке који садржи и користи се за инкапсулирање свих детаља у СОАП поруци. Ово је основни елемент у СОАП поруци.
• Елемент заглавља који садржи информације о заглављу - Елемент заглавља може садржати информације као што су акредитиви за потврду идентитета које апликација за позивање може да користи. Такође може садржати дефиницију сложених типова који се могу користити у СОАП поруци. СОАП порука подразумевано може садржати параметре који могу бити једноставних типова као што су низови и бројеви, али могу бити и сложени тип објекта.

Пример једноставног СОАП сервиса сложеног типа приказан је у наставку.

Претпоставимо да смо желели да пошаљемо структурирани тип података који је имао комбинацију „Назив упутства“ и „Опис водича“, онда бисмо дефинисали сложени тип као што је приказано у наставку.

Комплексни тип је дефинисан ознаком елемента <ксд: цомплекТипе>. Сви потребни елементи структуре заједно са њиховим одговарајућим типовима података тада се дефинишу у збирци сложених типова.

• Елемент Боди који садржи информације о позиву и одговору - Овај елемент садржи стварне податке које треба послати између веб услуге и апликације која позива. Испод је пример СОАП веб услуге за тело СОАП-а које заправо ради на сложеном типу дефинисаном у одељку заглавља. Ево одговора имена водича и описа упутства који се шаљу апликацији која позива и која позива ову веб услугу.

Web ServicesAll about web services

Структура СОАП поруке

Треба напоменути да се СОАП поруке обично аутоматски генеришу од стране веб услуге када је позвана.

Кад год клијентска апликација позове метод у веб услузи, веб услуга ће аутоматски генерисати СОАП поруку која ће садржати потребне детаље података који ће се са веб услуге послати клијентској апликацији.

Као што је размотрено у претходној теми овог СОАП туторијала, једноставна СОАП порука има следеће елементе -

• Елемент коверте
• Елемент заглавља и
• Елемент тела
• Елемент грешке (опционално)

Погледајмо пример једноставне СОАП поруке у наставку и видећемо шта заправо чини елемент.

1. Као што се види из горње СОАП поруке, први део СОАП поруке је елемент омотнице који се користи за инкапсулацију целокупне СОАП поруке.
2. Следећи елемент је тело СОАП-а које садржи детаље стварне поруке.
3. Наша порука садржи веб услугу која има назив „Гуру99ВебСервице“.
4. „Гуру99Вебсервице“ прихвата параметар типа „инт“ и има име ТуториалИД.

Сада ће горња СОАП порука бити прослеђена између веб услуге и клијентске апликације.

Можете видети колико су горње информације корисне за клијентску апликацију. СОАП порука говори клијентској апликацији како се зове Веб услуга, као и које параметре очекује, а такође и који је тип сваког параметра који узима веб услуга.

Елемент коверте СОАП

Први бит грађевинског блока је СОАП омотница.

СОАП коверта се користи за инкапсулирање свих потребних детаља СОАП порука, које се размењују између веб услуге и клијентске апликације.

Елемент СОАП омотнице користи се за означавање почетка и краја СОАП поруке. Ово омогућава клијентској апликацији која позива веб услугу да зна када се завршава СОАП порука.

Следеће тачке могу се приметити на елементу СОАП коверте.

• Свака СОАП порука мора имати основни елемент Енвелопе. Апсолутно је обавезно да СОАП порука има елемент коверте.
• Сваки елемент коверте мора да има најмање један елемент тела сапуна.
• Ако елемент Енвелопе садржи елемент заглавља, не сме садржати више од једног и мора се појавити као прво подређено место омотнице, пре елемента боди.
• Коверат се мења када се промене верзије СОАП-а.
• СОАП процесор компатибилан с в1.1 генерира грешку по пријему поруке која садржи вимен простор омотнице в1.2.
• СОАП процесор компатибилан са в1.2 генерише грешку у неусаглашавању верзије ако прими поруку која не укључује простор имена в омотници в1.2.

Испод је пример СОАП АПИ верзије 1.2 елемента СОАП омотнице.

int

Порука грешке

Када се поднесе захтев за СОАП веб услугу, враћени одговор може бити у два облика који су успешан одговор или одговор на грешку. Када се генерише успех, одговор сервера ће увек бити СОАП порука. Али ако се генеришу СОАП грешке, враћају се као грешке „ХТТП 500“.

Порука СОАП грешке састоји се од следећих елемената.

1. <фаултЦоде> - Ово је код који означава код грешке. Код грешке може бити било која од вредности испод
   1. СОАП-ЕНВ: ВерсионМисматцх - Ово је случај када се наиђе на неважећи простор имена за елемент СОАП Енвелопе.
   2. СОАП-ЕНВ: МустУндерстанд - Не разуме се непосредни подређени елемент елемента Хеадер, са атрибутом мустУндерстанд постављеним на „1“.
   3. СОАП-ЕНВ: Клијент - Порука је погрешно обликована или садржи нетачне информације.
   4. СОАП-ЕНВ: Сервер - Дошло је до проблема са сервером, па порука није могла да се настави.
2. <фаултСтринг> - Ово је текстуална порука која даје детаљан опис грешке.
3. <фаултАцтор> (Опционално) - Ово је текстуални низ који указује на то ко је изазвао грешку.
4. <детаил> (опционално) - Ово је елемент за поруке о грешкама специфичне за апликацију. Тако да апликација може имати одређену поруку о грешци за различите сценарије пословне логике.

Пример поруке о грешци

Пример поруке о грешци дат је у наставку. Грешка се генерише ако сценарио у којем клијент покуша да користи методу која се назива ТуториалИД у класи ГетТуториал.

Доленаведена порука о грешци генерише се у случају да метода не постоји у дефинисаној класи.

SOAP-ENV:ClientFailed to locate method (GetTutorialID) in class (GetTutorial)

Излаз:

Када извршите горњи код, приказаће се грешка попут „Није успело лоцирање методе (ГетТуториалИД) у класи (ГетТуториал)“

СОАП модел комуникације

Сва комуникација путем СОАП-а врши се путем ХТТП протокола. Пре СОАП-а, пуно веб услуга користило је стандардни РПЦ (Ремоте Процедуре Цалл) стил комуникације. Ово је била најједноставнија врста комуникације, али имала је пуно ограничења.

Сада у овом упутству за СОАП АПИ, размотримо дијаграм у наставку како бисмо видели како функционише ова комуникација. У овом примеру, претпоставимо да сервер хостује веб услугу која је обезбедила 2 методе као

• ГетЕффициее - Ово ће добити све детаље о запосленима
• СетЕффициее - Ово би у складу са тим поставило вредност детаља, као што су одељење запослених, плата итд.

У нормалној комуникацији у РПЦ стилу, клијент би само позвао методе у свом захтеву и послао потребне параметре серверу, а сервер би затим послао жељени одговор.

Горњи модел комуникације има доња озбиљна ограничења

1. Није независан од језика - сервер који хостује методе био би на одређеном програмском језику и обично би позиви серверу били само на том програмском језику.
2. Није стандардни протокол - Када се упути позив даљинској процедури, позив се не врши путем стандардног протокола. То је био проблем јер се углавном сва комуникација путем Интернета морала одвијати путем ХТТП протокола.
3. Заштитни зидови - Будући да РПЦ позиви не иду преко уобичајеног протокола, на серверу морају бити отворени одвојени портови како би клијент могао да комуницира са сервером. Обично би сви заштитни зидови блокирали ову врсту промета, а обично је била потребна велика конфигурација како би се осигурало да таква врста комуникације између клијента и сервера функционише.

Да би превазишао сва горе наведена ограничења, СОАП би тада користио доњи модел комуникације

1. Клијент ће информације у вези са позивом процедуре и било којим аргументима форматирати у СОАП поруку и послати их серверу као део ХТТП захтева. Овај поступак капсулирања података у СОАП поруку био је познат као маршалирање.
2. Сервер би тада распаковао поруку коју је послао клијент, видео би шта је клијент тражио, а затим би клијенту послао одговарајући одговор као СОАП поруку. Пракса размотавања захтева који је послао клијент позната је под називом Демарсхаллинг.

Пример практичног СОАП-а

Сада у овом водичу за СоапУИ, погледајмо практични пример СОАП-а,

Вероватно је један од најбољих начина да се види како се генеришу СОАП поруке заправо видети веб услугу на делу.

Ова тема ће се бавити употребом оквира Мицрософт.Нет за изградњу АСМКС веб услуге. Ова врста веб услуга подржава СОАП верзије 1.1 и верзију 1.2.

АСМКС веб услуге аутоматски генеришу документ Веб Сервице Дефинитион Лангуаге (ВСДЛ). Овај позивни клијентски програм захтева овај ВСДЛ документ како би апликација знала шта је веб услуга способна да уради.

У нашем примеру ћемо створити једноставну веб услугу која ће се користити за враћање низа у апликацију која позива веб услугу.

Ова веб услуга ће бити хостована у веб апликацији Асп.Нет. Затим ћемо позвати веб услугу и видети резултат који је вратила веб услуга.

Висуал Студио ће нам такође показати која се СОАП порука преноси између веб услуге и апликације која позива.

Први предуслов за подешавање апликације за веб услуге који се може извршити следећи кораке у наставку.

Уверите се да је на овом систему инсталиран Висуал Студио 2013 за овај пример.

Корак 1) Први корак је стварање празне АСП.Нет веб апликације. У Висуал Студио 2013 кликните на опцију менија Датотека-> Нови пројекат.

Једном када кликнете на опцију Нови пројекат, Висуал Студио ће вам дати други дијалошки оквир за одабир врсте пројекта и давање потребних детаља о пројекту. Ово је објашњено у следећем кораку.

Корак 2) У овом кораку,

1. Обавезно прво одаберите Ц # веб шаблон АСП.НЕТ веб апликације. Пројекат мора бити ове врсте да би се креирао пројекат СОАП услуга. Одабиром ове опције, Висуал Студио ће затим извршити неопходне кораке за додавање потребних датотека које су потребне било којој веб апликацији.
2. Дајте име свом пројекту који је у нашем случају добио назив вебсервице.асмк. Затим осигурајте локацију на којој ће се чувати датотеке пројекта.

Када завршите, видећете датотеку пројекта створену у вашем истраживачу решења у Висуал Студио 2013.

Корак 3) У овом кораку,

У наш пројекат ћемо додати датотеку веб услуге

1. Прво кликните десним тастером миша на датотеку пројекта као што је приказано испод

2. Једном када десним тастером миша кликнете на датотеку пројекта, имаћете прилику да изаберете опцију „Додај-> Веб услуга (АСМКС) да бисте додали датотеку веб услуге. Само наведите име Туториал Сервице за датотеку имена веб услуге.

Корак 4) Додајте следећи код у своју асмк датотеку Туториал Сервице.

Објашњење кода:

1. Овај ред кода пружа назив датотеке ваше веб услуге. Ово је важан корак, јер клијентској апликацији даје место да позове веб услугу преко имена веб услуге.
2. Датотека класе обично се користи за инкапсулирање функционалности веб услуге. Тако ће датотека класе имати дефиницију свих веб метода које ће пружити одређену функционалност клијентској апликацији.
3. Овде је [ВебМетход] познат као атрибут који описује функцију. Следећи корак ствара функцију која се назива „Гуру99ВебСервице“, али укључивањем овог корака додавања атрибута [ВебМетход] осигурава да клијентска апликација може да позове овај метод. Ако овај атрибут није на месту, тада клијентска апликација никада не може да позове метод.
4. Овде дефинишемо функцију која се назива 'Гуру99ВебСервице' која ће се користити за враћање низа у позивајућу клијентску апликацију. Ова функција је веб услуга коју може позвати било која клијентска апликација.
5. Користимо изјаву ретурн да бисмо клијентској апликацији вратили низ „Ово је Гуру99 веб услуга“.

Ако се код успешно изврши, следећи излаз ће се приказати када покренете свој код у прегледачу.

Излаз:

• Резултат јасно показује да је име наше веб услуге „Гуру99 Веб Сервице“, што је резултат давања имена нашој веб услузи.
• Такође можемо видети да можемо да се позовемо на веб услугу. Ако кликнемо на дугме Призови, добићемо одговор у наставку у веб прегледачу.

Горе наведени излаз,

• Јасно показује да се позивањем на веб метод враћа низ „Ово је Гуру99 веб услуга“.
• Висуал Студио такође вам омогућава да видите захтев и одговор СОАП поруке који се генеришу када се позове горе наведена веб услуга.

СОАП захтев који се генерише када се позове веб услуга приказан је у наставку.

Објашњење кода:

1. Први део СОАП поруке је елемент коверте о чему је било речи у претходним поглављима. Ово је енкапсулирајући елемент који је присутан у свакој СОАП поруци.
2. Тело СОАП-а је следећи елемент и садржи стварне детаље СОАП поруке.
3. Трећи део је елемент који одређује да желимо да позовемо услугу која се зове „Гуру99ВебСервице“.

string

Објашњење кода:

1. Први део СОАП поруке је елемент коверте о чему је било речи у претходним поглављима. Ово је енкапсулирајући елемент који је присутан у свакој СОАП поруци.
2. Тело СОАП-а је следећи елемент и садржи стварне детаље СОАП поруке.
3. Занимљив део који ћете сада видети је атрибут 'стринг'. Ово говори клијентској апликацији да се веб услуга која се зове враћа објект типа типа. Ово је врло корисно, јер ако клијентска апликација која иначе не би знала шта веб услуга враћа.

Резиме

• СОАП је протокол који се користи за размену података између апликација које су изграђене на различитим програмским језицима.
• СОАП је заснован на КСМЛ спецификацији и ради са ХТТП протоколом. То га чини савршеним за употребу у веб апликацијама.
• Грађевински блокови СОАП састоје се од СОАП поруке. Свака СОАП порука састоји се од елемента омотнице, заглавља и елемента тела.
• Елемент коверте је обавезни елемент у СОАП поруци и користи се за инкапсулирање свих података у СОАП поруци.
• Елемент заглавља може се користити за садржавање информација као што су подаци за потврду идентитета или дефиниција сложених типова података.
• Елемент боди је главни елемент који садржи дефиницију веб метода, заједно са било којим информацијама о параметрима, ако је потребно.