Розуміння SOAP
Viktor Shatokhin,
Aaron Skonnard, DevelopMentor
Вступ
Спочатку SOAP розшифровувався як "Протокол
доступу простих об'єктів "(Simple Object Access Protocol). Якби ви
запитали кого-небудь про те, що значить SOAP, кілька років тому, то отримали
б приблизно таку відповідь: "це для роботи DCOM і Corba (тобто RPC викликів)
через Internet ". Перші автори визнавали тоді, що вони фокусувалися на
"доступ до об'єктів", але з часом захотілося, щоб SOAP
обслуговував більш широку аудиторію. Таким чином, фокус специфікації швидко
змістився з об'єктів на узагальнену оболонку обміну повідомленнями XML.
Цей перехід створив невелику проблему з "O"
в абревіатурі SOAP. Цікаво, що Робоча група SOAP 1.2 зберегла (до цих
пір) ім'я SOAP (воно таке популярне, як же може бути інакше?), але було вирішено не
розшифровувати його, щоб не вводити в оману розробників. Сьогодні в
офіційному визначенні, що наводиться в найостанніших специфікаціях SOAP 1.2,
об'єкти навіть не згадуються:
SOAP - це полегшений протокол, призначений для
обміну структурованою інформацією в децентралізованої, розподіленої
середовищі. Для визначення нарощуваний оболонки обміну повідомленнями, що забезпечує
структуру повідомлення, яка може бути використана при обміні різними
базовими протоколами, SOAP використовує XML технології. Ця оболонка розроблена
незалежною від будь-якої конкретної моделі програмування та інших особливих
семантик реалізації.
Це визначення дійсно відображає суть того, чим
є SOAP сьогодні. SOAP визначає спосіб переміщення XML повідомлень з
точки А в точку В (див. Малюнок 1). Це робиться шляхом забезпечення оболонки
обміну повідомленнями на базі XML, що є: 1) нарощувати; 2) придатною
до використання різними базовими мережевими протоколами; 3) незалежної від
моделей програмування. Давайте трохи детальніше зупинимося на кожній
з цих трьох характеристик.
Малюнок 1. Простий обмін повідомленнями SOAP
По-перше, ключовим у SOAP є його
нарощуваність. Коли абревіатура ще щось означала, буква "S"
мала значення "Простий". Якщо ми хоч чогось і навчилися в Web, так
це тому, що простота завжди бере гору над ефективністю або
технічним якістю, і коли робиться ставка на здатність до взаємодії,
вона стає абсолютним вимогою. Простота залишається однією з основних
цілей при розробці SOAP, що доводить відсутність у SOAP різних
можливостей розподілених систем, таких як безпека, маршрутизація,
надійність і т.д. SOAP визначає оболонку взаємозв'язку, в якій є
можливість додати ці можливості в майбутньому як багаторівневі розширення.
Microsoft, IBM та інші виробники програмного забезпечення активно працюють
над створенням загального пакету розширень SOAP, які додадуть багато хто з цих
можливостей, очікуваних більшістю розробників. Першим кроком стала Глобальна архітектура XML Web сервісів
(Global XML Web Services Architecture (GXA)). Microsoft вже випустила
реалізацію деяких специфікацій GXA під назвою Розширення сервісів Web 1.0
SP1 для Microsoft. NET (Web Services Enhancements 1.0 SP1 for Microsoft. NET
(WSE )).
По-друге, SOAP може використовуватися в будь-якому
транспортному протоколі, такому як TCP, HTTP, SMTP або навіть MSMQ (див. Малюнок
1). Тим не менше, щоб підтримувати можливість взаємодії, повинні бути
визначені взаємозв'язку co стандартними протоколами, структура яких різна
для кожної середовища. Специфікація SOAP забезпечує гнучку оболонку для
визначення взаємозв'язків довільних протоколів і сьогодні забезпечує явне
зв'язування для HTTP, оскільки він так широко використовується.
По-третє, SOAP дозволений для всіх моделей
програмування і не прив'язаний до RPC. Більшість розробників відразу ж
ототожнили SOAP із здійсненням RPC викликів до розподілених об'єктів (тому що
спочатку йшлося про "організації доступу до об'єктів"), в той
час як насправді фундаментальна модель SOAP більш близька до
традиційним системам обміну повідомленнями, таким як MSMQ. SOAP визначає
модель обробки окремих, односпрямованої повідомлень. Ви можете об'єднати
безліч повідомлень в загальний процес обміну повідомленнями. Малюнок 1 ілюструє
просте однонаправлений повідомлення, при якому відправник не одержує відповіді.
Проте одержувач може надіслати відправнику відповідь (див. Малюнок 2). SOAP
передбачає будь-яку кількість схем обміну повідомленнями, запит/відповідь є
всього лише одним з них. Інші приклади включають вимога/відповідь (зворотний
запиту/відповіді), нотифікації і тривалі однорангові розмови.
Малюнок 2. Схема обміну повідомленнями запит/відповідь
Розробники часто плутають запит/відповідь з RPC, в той
час як це зовсім різні речі. RPC використовує запит/відповідь, але
запит/відповідь необов'язкові для RPC. RPC є моделлю програмування,
яка дає можливість розробникам працювати з викликами методів. RPC вимагає
перетворення сигнатури методу в SOAP повідомлення. Через популярність RPC SOAP
описує угоду про використання RPC з SOAP (див. розділ RPC та кодування
цієї статті)
Збройна цими трьома головними характеристиками,
оболонка обміну SOAP повідомленнями сприяє обміну повідомленнями в XML
гетерогенних середовищах, для яких можливість взаємодії довгий час була
проблемою.
SOAP версії
Від першого опублікованій специфікації SOAP до
сьогоднішньої широко застосовується SOAP 1.1 багато чого змінилося: починаючи від найменших
деталей, закінчуючи значними переміщеннями у мисленні. SOAP 1.1 була
запропонована W3C і опублікована як замітка в травні 2000. Статус "Замітка
W3C "зробило SOAP 1.1 дещо більшим, ніж гарною ідеєю, тому що вона не
пройшла строгості обробки W3C, по закінченні якого остаточно досягла б
статусу "Рекомендації". Тим не менше, з-за широкої підтримки як
великих, так і дрібних виробників, сьогодні SOAP 1.1, фактично, все ще
вважається стандартом.
W3C використовувати замітки SOAP 1.1 в якості джерела
для нової Робочої групи XML протоколу, відповідальної за створення наступної
версії SOAP, SOAP 1.2. Зараз SOAP 1.2 є "Кандидат у
Рекомендації ", це означає, що вона знаходиться на стадії реалізації і
недалека від завершення. Як тільки SOAP 1.2 стане "Рекомендацією",
вона, ймовірно, швидко знайде підтримку у виробників.
Після введення SOAP 1.2 виробники повинні будуть
продовжувати підтримувати SOAP 1.1 для забезпечення зворотної сумісності.
Розробка нових версій SOAP грунтується на просторах імен XML. SOAP 1.1
визначається простором імен http://schemas.xmlsoap.org/soap/envelope/, в той
час як SOAP 1.2 - простором імен http://www.w3.org/2002/12/soap-envelope
(хоча воно зміниться, коли SOAP 1.2 стане Рекомендацією).
У Таблиці 1 представлені простору імен і
місця розташування специфікацій кожної версії. Далі стаття буде присвячена
найбільш важливих питань SOAP 1.1. У цій специфікації SOAP 1.2 ви можете
знайти докладний список відмінностей між цими двома версіями.
Таблиця 1. Інформація по SOAP версіями
SOAP 1.1
Назва простору імен
http://schemas.xmlsoap.org/soap/envelope/
Розташування специфікації
http://www.w3.org/TR/SOAP/
SOAP 1.2
Назва простору імен
http://www.w3.org/2002/12/soap-envelope
Розташування специфікації
http://www.w3.org/TR/soap12-part0/
http://www.w3.org/TR/soap12-part1/
http://www.w3.org/TR/soap12-part2/
Оболонка обміну повідомленнями
Основний розділ специфікації SOAP - це оболонка
обміну повідомленнями. Оболонка обміну повідомленнями SOAP визначає набір елементів
XML для організації пакетів довільних XML повідомлень для передачі їх між
системами.
Оболонка складається з наступних основних елементів XML:
Envelope, Header, Body і Fault. Всі вони з простору імен
http://schemas.xmlsoap.org/soap/envelope/ SOAP 1.1. Я навів тут повне
опис XML Schema для SOAP 1.1. Особисто для себе я знайшов корисним перегляд
схеми при ознайомленні з конструкціями XML.
Опис XML Schema SOAP 1.1
xmlns: tns = "http://schemas.xmlsoap.org/soap/envelope/"
targetNamespace = "http://schemas.xmlsoap.org/soap/envelope/"
>
maxOccurs = "unbounded"
processContents = "lax" />
processContents = "lax" />
maxOccurs = "unbounded"
processContents = "lax" />
processContents = "lax" />
maxOccurs = "unbounded"
processContents = "lax" />
processContents = "lax" />
type = "tns: encodingStyle"
/>
minOccurs = "0" />
minOccurs = "0" />
maxOccurs = "unbounded" processContents = "lax"
/>
processContents = "lax" />
Якщо ви закінчили розгляд complexType для
Envelope, ви можете швидко ознайомитися з тим, яке відношення ці елементи
мають один до одного. Наступний шаблон повідомлення ілюструє структуру конверта
SOAP:
xmlns: soap = "http://schemas.xmlsoap.org/soap/envelope/">
Елемент Envelope завжди є кореневим елементом SOAP повідомлення. Таким чином, додатки можуть, просто поглянувши на
ім'я кореневого елементу, розпізнати "SOAP повідомлення". Програми також
можуть визначити версію використовуваного SOAP, перевіряючи ім'я простору імен
елемента Envelope.
Елемент Envelope містить необов'язковий елемент
Header (детальніше див Розширюваність), за яким слідує
обов'язковий елемент Body. Елемент Body представляє корисний вантаж повідомлення.
Елемент Body є контейнером, в якому може міститися будь-яку кількість
елементів з будь-якого простору імен. Саме тут розміщуються дані, які
ви намагаєтеся відправити.
Наприклад, наступне SOAP повідомлення являє запит
для трансфара фондів між банківськими рахунками:
xmlns: soap = "http://schemas.xmlsoap.org/soap/envelope/">
22-342439
98-283843
100.00
Якщо одержувач підтримує запит/відповідь і може
успішно обробити повідомлення, він відправить інше SOAP повідомлення тому
відправнику. У цьому випадку інформація відповіді також буде міститися в елементі
Body, як показано в даному прикладі:
xmlns: soap = "http://schemas.xmlsoap.org/soap/envelope/">
xmlns: x = "urn: examples-org: banking">
22-342439
33.45
98-283843
932.73
Оболонка обміну повідомленнями також визначає елемент
Fault для представлення помилок в межах елемента Body, коли щось йде не
так. Це важливо, тому що без стандартного подання помилки кожному
додатком доведеться вводити власні, що зробить неможливим для спільної
інфраструктури розрізнити успіх і невдачу. Наступний приклад SOAP повідомлення
містить елемент Fault, який представляє помилку "невідповідною
фонди ", що відбувається при обробці запиту:
xmlns: soap = "http://schemas.xmlsoap.org/soap/envelope/">
soap: Server
Insufficient
funds
22-342439
100.00
89.23
Елемент Fault повинен містити елемент faultcode, за яким слідує елемент faultstring. Елемент faultcode, використовуючи ім'я певного
простору імен, класифікує помилку, у той час як елемент faultstring
забезпечує читабельною опис помилки для людини (подібно до того, як
працює HTTP). У Таблиці 2 наведені короткі описи визначених у SOAP 1.1
кодів помилок (всі вони в просторі імен
http://schemas.xmlsoap.org/soap/envelope/)
Елемент Fault також може містити елемент detail для
надання деталей помилки, які можуть допомогти клієнтам діагностувати
проблему, особливо у випадку кодів помилки Client і Server.
Таблиця 2. Коди помилок в SOAP 1.1
Name
Meaning
VersionMismatch
Обробна сторона
виявила невірне простір імен для SOAP елемента Envelope.
MustUnderstand
Найближчий дочірній елемент
SOAP Header елемента, який був або не зрозумілий, або не підходив
обробної стороні, містить SOAP атрибут mustUnderstand зі значенням
"1".
Client
Клас помилок Client
показує, що повідомлення було неправильно сформований або не містить
відповідної інформації для того, щоб бути успішно оброблених. Це
зазвичай свідчить про те, що не треба повторно відправляти повідомлення, не
змінивши його.
Server
Клас помилок Server
показує, що повідомлення не може бути оброблено не з-за його вмісту,
але, швидше, з-за збою при обробки повідомлення. Повідомлення може пройти
успішно, якщо буде повторно відправлено у більш пізній момент часу.
Тепер уявіть, що ви хочете в оригінальне
повідомлення додати деяку ідентифікаційну інформацію, щоб одержувач міг
визначити, чи має відправник відповідні права на виконання пересилання.
Щоб зробити це, необхідно додати засвідчує інформацію в Body, як
показано нижче:
xmlns: soap = "http://schemas.xmlsoap.org/soap/envelope/">
22-342439
98-283843
100.00
dave
evad
Цей шлях вимагає, щоб кожна операція, що вимагає
ідентифікації, працювала з посвідченнями. Це також означає, що інші
додатка при необхідності забезпечення безпеки повинні розробляти свої
власні рішення проблеми; зрозуміло, страждає можливість взаємодії.
Для загальних потреб, таких як безпека, більше сенсу має визначити
стандартні SOAP заголовки, які будуть узгоджені з усіма. Потім
виробники зможуть вбудувати підтримку для розширених функціональних
можливостей у свою інфраструктуру SOAP, і всі будуть у виграші. Цей підхід
збільшує продуктивність розробника і, в той же час, допомагає
забезпечити більш високий рівень взаємодії. Це саме те, для полегшення
чого була розроблена модель розширюваності SOAP.
Розширюваність
Більшість існуючих протоколів роблять відмінність
між керуючою інформацією (тобто заголовками) і корисною інформацією
повідомлення. У цьому відношенні SOAP нічим не відрізняється. SOAP елементи Header і
Body забезпечують ті ж відмінності в легкообрабативаемом світі XML. Крім простоти
у використанні, ключовим перевагою розширюваного Envelope є те, що
він може використовуватися будь-яким протоколом зв'язку.
Заголовки завжди відігравали важливу роль у протоколах,
таких як HTTP, SMTP та інші, тому що вони дають можливість додаткам на
обох кінцях проводу обговорювати поведінку підтримуваних команд. Хоча сама
специфікація SOAP не визначає вбудовані заголовки, з часом вони будуть
грати в SOAP таку ж важливу роль. Стандартизація GXA та заголовків SOAP
полегшить розробникам визначення протоколів багатьох програм без
необхідності щоразу винаходити колесо.
Елемент Header, так само як і елемент Body, є
контейнером для керуючої інформації. Він може містити будь-яку кількість
елементів з будь-якого пропростору імен (не з простору імен SOAP). На
елементи, поміщені в елемент Header, посилаються як на блоки заголовка. Як і
в інших протоколах, блоки заголовка повинні містити інформацію, що робить
вплив на обробку корисної інформації. Таким чином, це підходяще місце
для розміщення чогось, на зразок елементу credentials, який допомагає
контролювати доступ до операції:
xmlns: soap = "http://schemas.xmlsoap.org/soap/envelope/">
dave
evad
22-342439
98-283843
100.00
Блоки заголовка також можуть бути анотований
глобальним SOAP атрибутом mustUnderstand, щоб визначити необхідність
розуміння заголовка одержувачем до обробки повідомлення. Наступний приклад
ілюструє, як вимагати обробку заголовка credentials:
xmlns: soap = "http://schemas.xmlsoap.org/soap/envelope/">
soap: mustUnderstand = "1"
>
dave
evad
...
Якщо блок заголовка анотувати
mustUnderstand = "1", і одержувач не підтримує цей заголовок,
повідомлення не буде оброблено і відправнику буде повернуто Fault (з кодом
стану soap: MustUnderstand). Коли mustUnderstand = "0" або цього
атрибуту немає, абонент може ігнорувати ці заголовки і продовжувати
обробку. Атрибут mustUnderstand відіграє центральну роль у всій моделі
обробки SOAP.
Модель обробки
SOAP визначає модель обробки, яка містить
основні правила обробки SOAP повідомлень по мірі їх проходження від SOAP
SOAP відправника до одержувача. Малюнок 1 ілюструє найпростіший сценарій обміну SOAP повідомленнями, в
якому один додаток (SOAP відправник) посилає SOAP повідомлення іншому
додатком (SOAP одержувачу).
Однак модель обробки допускає і більш цікаві
архітектури, подібні наведеній на рисунку 3, що містить безліч
проміжних вузлів. Далі я буду використовувати термін SOAP вузол для позначення
будь-якого додатка, що обробляє SOAP повідомлення, незалежно від того,
чи є воно початковим відправником, проміжним або кінцевим одержувачем;
в іншому випадку я буду точним і буду використовувати конкретний термін.
Малюнок 3. Складний обмін SOAP повідомленнями
Посередник розташовується між початковим відправником і
кінцевим одержувачем і перехоплює SOAP повідомлення. Посередник працює
одночасно і як SOAP відправник, і як SOAP одержувач. Проміжні вузли
роблять можливим розробляти деякі цікаві і гнучкі мережеві
архітектури, на які можна впливати вмістом повідомлення.
Маршрутизація SOAP повідомлень є гарним прикладом того, що значно
підсилює значимість SOAP посередників (більш докладно про маршрутизації SOAP
повідомлень див Routing SOAP Messages with Web Services Enhancements 1.0)
Обробляючи повідомлення, SOAP вузол бере на себе одну
або більше ролей, які впливають на те, як обробляються SOAP заголовки. Ролям
даються унікальні імена (у формі URI), таким чином, вони можуть бути
ідентифіковані під час обробки. SOAP вузол, отримавши повідомлення для
обробки, спочатку повинен визначити, які ролі він буде виконувати. Для цього
він може перевірити SOAP повідомлення.
Як тільки він визначиться з ролями, які буде
виконувати, SOAP вузол повинен обробити всі обов'язкові заголовки (зазначені
mustUnderstand = "1"), спрямовані на одну з його ролей. Також SOAP
вузол може вибрати для обробки будь-якої необов'язковий заголовок (зазначений
mustUnderstand = "0"), спрямований на одну з його ролей.
SOAP 1.1 визначає лише одну роль --
http://schemas.xmlsoap.org/soap/actor/next (next для стислості). Кожний SOAP
вузол повинен прийняти роль next. Таким чином, коли SOAP повідомлення приходить в
будь-який даний SOAP вузол, вузол повинен обробити всі обов'язкові заголовки,
націлені на роль next, і він може обробити необов'язкові заголовки, також
націлені на роль next. Крім next, SOAP 1.2 визначає ще кілька ролей
(див. Таблиця 3), додаткам дозволено також визначати власні ролі.
SOAP заголовки націлюються на конкретні ролі з
допомогою глобального атрибуту actor (в SOAP 1.2 цей атрибут названий role). Якщо
цього атрибуту немає, заголовок за замовчуванням націлюється на кінцевого одержувача.
Наступний SOAP повідомлення ілюструє, як використовувати actor:
xmlns: soap = "http://schemas.xmlsoap.org/soap/envelope/">
soap: actor = "http://schemas.xmlsoap.org/soap/actor/next"
soap: mustUnderstand = "1"
>
...
Оскільки заголовок wsrp: path націлений на роль next і
позначений як обов'язковий (mustUnderstand = "1"), перший SOAP вузол,
одержує це повідомлення, повинен обробити його відповідно до специфікації
блоку заголовка, в даному випадку WS-Routing. Якщо SOAP вузол розроблений так, що
не розуміє обов'язкового заголовка, націленого на одну з його ролей, він
повинен згенерувати SOAP помилку з кодом стану soap: MustUnderstand і
перервати обробку. Щоб визначити, що викликало помилку в проходженні
повідомлення, елемент SOAP Fault надає дочірній елемент faultactor.
Значення атрибута faultactor є URI, який ідентифікує SOAP вузол,
що викликав помилку.
Якщо SOAP вузол успішно обробив заголовок, потрібно
видалити цей заголовок з повідомлення. SOAP версій сайту дозволено повторно вставляти
заголовки, але це змінює учасників контракту - тепер заголовки targets
між поточними і такими вузлами. Якщо SOAP вузол виявляється кінцевим
одержувачем, він також повинен опрацювати і SOAP тіло.
Таблиця 3. Ролі SOAP 1.2
Назва SOAP ролі
Опис
http://www.w3.org/2002/06/soap-envelope/role/next
Кожний SOAP посередник і
кінцевий SOAP одержувач ПОВИННІ виконувати цю роль і МОЖУТЬ додатково приймати нуль або
більше за інших SOAP ролей.
http://www.w3.org/2002/06/soap-envelope/role/none
SOAP вузли НЕ ПОВИННІ
виконувати цю роль.
http://www.w3.org/2002/06/soap-envelope/role/ultimateReceiver
Щоб оголосити себе
SOAP кінцевим одержувачем, SOAP вузол МАЄ виконувати цю роль. SOAP
посередники не повинні виконувати цю роль.
Взамодействіе протоколів
Цікаво, що на рисунку 3 SOAP забезпечує обмін
повідомленнями через різні базові протоколи. Оскільки оболонка обміну SOAP
повідомленнями не залежить від базових протоколів, кожен посередник може
використовувати різні протоколи обміну без впливу на SOAP повідомлення. Однак
для забезпечення високих рівнів взаємодії між SOAP програмами та
інфраструктурою необхідні стандартні взаємодії протоколів.
Конкретне взаємодія
протоколів
визначає як саме SOAP повідомлення повинні передаватися за допомогою даного
протоколу. Інакше кажучи, він визначає деталі того, як SOAP узгоджується в
рамках другого протоколу, який, можливо, має власну оболонку обміну
повідомленнями поряд з різноманітністю заголовків. Що дійсно визначає
взаємодія протоколів у великій мірі залежить від функцій і
можливостей протоколу. Наприклад, взаємодія протоколів для TCP буде
сильно відрізнятися від взаємодії для MSMQ або SMTP.
Специфікація SOAP 1.1 кодіфіцірует взаємодія
протоколів тільки для HTTP через його широкого розповсюдження. SOAP
використовується і з іншими протоколами, але реалізації не слідували стандартизованого
взаємодії.
HTTP взаємодія
Взаємодія протоколу HTTP визначає правила
використання SOAP поверх HTTP. SOAP запит/відповідь просто перетворюється на
модель HTTP запиту/відповіді. Малюнок 4 ілюструє багато деталей з'єднання
SOAP HTTP.
Малюнок 4. SOAP HTTP взаємодія
Заголовок Content-Type для HTTP повідомлень запиту та
відповіді повинен бути text/xml (application/soap + xml в SOAP 1.2). Що стосується
повідомлення запиту, вона повинна використовувати як команди слово POST, і URI
повинен визначати SOAP обробник. Специфікація SOAP також визначає новий
HTTP заголовок - SOAPAction, який повинен бути присутнім у всіх SOAP HTTP
запитах (навіть якщо вони порожні). Заголовок SOAPAction призначений для
вираження мети повідомлення. Що стосується HTTP відповіді, він повинен використовувати код
стану 200, якщо не сталася помилка, або 500, якщо тіло містить SOAP
Fault.
RPC та кодування
Хоча специфікація SOAP розвивалася у бік від
об'єктів, вона до цих пір визначає угоду для інкапсуляції та обміну RPC
викликами з використанням оболонки обміну повідомленнями, описаної вище.
Визначення стандартного способу перетворення RPC викликів у SOAP повідомлення
дає можливість інфраструктурі під час виконання автоматично проводити
перетворення між викликами методів і SOAP повідомленнями без доробки коду на
платформі Web сервісів.
Щоб зробити виклик методу, використовуючи SOAP,
інфраструктурі потрібна наступна інформація:
1. Розташування (URI)
2. Назва методу
3. Імена/значення параметра
4. Необов'язково сигнатура методу
5. Необов'язково дані заголовка
Ця інформація може переноситися різними
способами, включаючи бібліотеки типів, IDL файли або краще WSDL файли.
Взаємодія SOAP RPC визначає, як інкапсулювати або представити цю
інформацію в SOAP тілі. Спочатку визначається, як сигнатура методу
перетворюється на прості структури запиту/відповіді, які потім можуть бути
кодовані як XML. З'єднання RPC встановлює, що виклик методу буде зроблений
як struct, названа так само як і метод. Struct буде містити аксессор для
кожного параметра [in] або [in/out], названий так само як і параметр, і в
послідовності, визначеної сигнатурою повідомлення. Відповідь методу також буде
змодельований як struct. Назва struct може бути будь-яким, хоча, згідно з
угодою, треба використовувати ім'я методу, закінчується словом
"Response" (тобто для операції add відповідь методу, відповідно, буде
називатися addResponse). Struct відповіді містить аксессор для повертається
значення (у SOAP 1.1 ім'я не має значення, але в SOAP 1.2 повинно бути
rpc: result), за яким слідує аксессор для кожного параметра [out] або
[in/out].
Давайте розглянемо приклад. Наступна сигнатура методу
на C # допускається для операції add:
double add (ref
double x, double y)
Відповідно до щойно описаними правилами RPC
з'єднання, struct запиту, що представляє виклик методу, буде змодельована
наступним чином:
struct add (
double x;
double y;
)
У той час як struct відповіді буде виглядати так:
struct addResponse
(
double result;
double x;
)
Тепер питання в наступному: як повинні ці структури
перетворюватися в XML? Специфікація SOAP саме для цих цілей визначає ряд
правил кодування. Правила кодування SOAP описують, як перетворювати
найбільш часто використовувані сьогодні структури даних (такі як structs і
масиви) до загального XML формат. Відповідно до правил кодування SOAP, struct запиту
з прикладу, наведеного вище, перетвориться в наступне XML повідомлення (воно
буде поміщено в SOAP тіло):
33
44
І відповідь на цей запит буде перетворений
в XML повідомлення (яке піде в тіло листа у відповідь):
77
33
Правила SOAP кодування були введені в час, коли
робота над XML Schema тільки починалася. Тепер ця XML Schema закінчена,
розробники можуть просто забезпечити літеральние опису XML Schema, які
точно визначають, як повідомлення запиту/відповіді повинні форматуватися в XML.
Через те, що, використовуючи опису XML Schema, стало простіше досягти
можливості взаємодіяти, більшість розробників вирішили повністю
відмовитися від правил SOAP кодування. До речі, що стосується SOAP 1.2,
специфікацією більше офіційно не потрібна підтримка правил SOAP кодування.
Дискусія на цю тему, чому наведена в The Argument Against SOAP Encoding.
Хоча взаємодія SOAP RPC та правила кодування
забезпечують хороший рівень SOAP інтеграції для додатків, які не готові сортувати
такі речі як XML Schema або WSDL, вони сильно вийшли за межі інтересів
спільноти Web сервісів, тому що більше змістилися в бік питань взаємодії.
SOAP стилі
Повторимо, сьогодні існує два основних стилі обміну
SOAP повідомленнями: документ і RPC. Стиль документ свідчить про те, що
тіло просто містить XML документ, формат якого відправник і одержувач
повинні узгодити. З іншого боку, стиль RPC свідчить про те, що тіло
містить XML подання виклику методу, як ми тільки що обговорили.
Також є два техніки для вирішення того, як
серіалізовать дані в тіло: використовуючи літеральние опису XML Schema і
використовуючи правила SOAP кодування. У першому підході опис схеми літерально
визначає XML формат для тіла без неоднозначностей. У другому підході, однак,
SOAP обробник повинен під час виконання перебрати різні правила SOAP
кодування, щоб знайти відповідну сериализации для тіла. Очевидно, що ця
техніка більш схильна до помилок і проблем взаємодії.
Найчастіше використовується стиль документа з літеральнимі
описами схеми (відомий як документ/літеральний) і RPC стиль з правилами
SOAP кодування (відомий як rpc/кодований). Документ/кодований і
rpc/літеральний можливі, але вони не загальноприйняті і не мають особливого сенсу.
Документ/літеральний - це стиль, на якому сфокусовано більшість платформ
Web сервісів, і сьогодні він застосовується за умовчанням в оболонці WebMethod
Microsoft ® ASP.NET.
Висновок
SOAP визначає просту і нарощувану оболонку обміну
XML повідомленнями, яка може використовуватися в багатьох протоколах з
різноманітними моделями програмування, незважаючи на те, що специфікація описує
тільки те, як використовувати SOAP з HTTP і RPC викликами. SOAP також визначає
повну модель обробки, яка описує механізм обробки повідомлень. У
цілому, SOAP надає багату та гнучку оболонку для визначення протоколів
високорівневих додатків, які пропонують поліпшену можливість
взаємодії в розподіленої, гетерогенної середовищі.
Список літератури
Для підготовки даної роботи були використані
матеріали з сайту http://www.realcoding.net/
