Що таке web служба
Основною концепцією Web-служб є обмін даними між комп'ютерами за допомогою стандартизованих протоколів і повідомлень. Ця ідея далеко не нова. Проте, за останні пару років гіганти ринку зібралися разом, і слава богу, визначили кілька основних стандартів. Результатом цього стало те, що тепер можливо "говорити" з іншими системами або комп'ютерами без втручання людини або без глибоких пізнань того, як влаштована Web-служба на іншій стороні. Ви просто Новомосковскете стандарти і прямуєте ім. Отже, Архітектура SOA - архітектура, орієнтована на служби - ця "розумна фраза" дуже добре пояснює ролі, властиві додатком, орієнтованому на Web-служби. Всього в ньому є три учасники;
Споживач шукає послугу в довіднику, а постачальник публікує інформацію про послугу в цьому довіднику. Потім споживач може запросити інформацію у постачальника, який (хочеться вірити) із задоволенням виконає прохання. Наочно ці взаємини показані на малюнку нижче. Для обміну інформацією між цими трьома учасниками системи SOA необхідні стандарти для вирішення наступних трьох задач:
- Передача повідомлень.
- Опис.
- Пошук в довіднику UDDI.
Передача повідомлень за допомогою SOAP
Передача повідомлень зазвичай здійснюється за допомогою протоколу HTTP, тому що брандмауери, як правило, пропускають HTTP-трафік, хоча деякі виробники апаратних брандмауерів вже почали вносити в свої системи зміни, які дозволяють фільтрувати небажані запити Web-служб. Втім, слід зазначити, що HTTP - не єдино можливий транспортний протокол. Крім нього ще використовується (правда дуже рідко) протокол SMTP.
Протокол SOAP инкапсулирован в HTTP. Колись SOAP розшифровувався як Simple Object Access Protocol (простий протокол доступу до об'єктів). Однак з цією назвою виникло дві проблеми: по-перше, протокол SOAP аж ніяк не простий, а по-друге, він не має нічого спільного з доступом до об'єктів. Тому, починаючи з версії 1.2, SOAP позначає. SOAP ( "мило") і більше нічого.
Подібно до звичайного повідомленням, SOAP-повідомлення містить три частини: конверт, заголовок і тіло. Основним елементом SOAP-документа є конверт, який містить заголовок і тіло (втім, заголовок є необов'язковим і рідко використовується в сучасних додатках). Нижче представлений приклад SOAP-повідомлення:
Що тут відбувається? Спочатку ми створюємо SOAP конверт, який викликає службу із зазначенням URN (Uniform Resource Name - уніфікованого імені ресурсу) phpSunleashed-guid. Потім викликається метод getGuid з передачею йому параметра prefix зі значенням РНР_. SOAP-відповідь цього виклику web-служби може виглядати так, як показано нижче. Зверніть увагу на значення, що повертається - в даному випадку: PHP_411f663ce6ce5.
Протокол SOAP дозволяє виконувати набагато більше, ніж просто повернення рядків. Крім усього іншого, він підтримує призначені для користувача типи даних. Крім того, вам зовсім не потрібно турбуватися про це, оскільки про більшу частину технічних деталей піклується PHP-модуль SOAP. який перетворює структури даних SOAP до відповідних структур даних РНР.
Опис за допомогою WSDL
SOAP працює дуже добре, якщо про Web-службі все відомо. Однак це не завжди так. Засобом опису інтерфейсу для доступу до Web-службі є мова WSDL (Web Services Description Language - мова опису Web-служб). Цей стандарт спільно розроблений компаніями IBM, Microsoft і webMethods. У кожної з цих трьох компаній був власний підхід до розробки стандарту для опису Web-служб: IBM створила NASSL, Microsoft розробила SCL, а компанія webMethods придумала WIDL.
Результатом їх співпраці стала версія 1.1 мови WSDL, З приводу W3C слід зазначити, що так само як і з SOAP, консорціум W3C на основі версії 1.1 розробив версію WSDL 1.2, яка тепер є рекомендацією W3C. WSDL-опис Web-служби містить всю необхідну для використання цієї служби інформацію, включаючи доступні методи і їх параметри. Ця інформація міститься в наступних п'яти елементах:
- підтримувані протоколи. - повідомлення Web-служби (запит, відповідь). - всі доступні методи. - URI служби. - використовувані типи даних.
Вся ця інформація зберігається в кореневому елементі WSDL-опису
WSDL-опис Web-служби
Що ж. без склянки не розбереш, але ж це один з найбільш простеньких (!) WSDL файлів. На жаль, один з недоліків SOAP-розширення для РНР 5 пов'язаний з тим, що на відміну від інших реалізацій SOAP, воно не дозволяє створювати WSDL-опису автоматично (у всякому разі, поки що). Напевно цей недолік виправлять в майбутніх версіях РНР.
Для автоматичного створення WSDL-опису ви можете використовувати альтернативні реалізації протоколу SOAP в РНР:
Пошук в довіднику за допомогою UDDI
Тепер, після того як ми знаємо, як отримувати інформацію про Web-службі і як її запитувати, потрібно навчитися знаходити таку службу. Для цієї мети існує щось схоже на "Жовті сторінки", а саме - реєстри UBR (Universal Business Registries - універсальні бізнес-реєстри) - довідники Web-служб.
Існує кілька таких реєстрів, серед яких реєстри компаній IBM, Microsoft, NTT-Com і SAP. Ці реєстри синхронізують свої дані, тому можна користуватися будь-яким з них. Поточною версією стандарту UDDI є версія UDDI 3.0, хоча більшість реалізацій використовують версію 2. Серед розробників цього стандарту такі компанії-гіганти, як HP, Intel, Microsoft і Sun.
Для взаємодії з UBR існує два типи API-інтерфейсів: Inquiry API і Publish API. Інтерфейс Inquiry API (Запит) призначений для запиту служб в реєстрах UBR, а інтерфейс Publish API (Публікація) дозволяє розробникам реєструвати свої служби. Схоже, що заповнення вмісту реєстрів спамом - це тільки питання часу :)
Існують тестові реєстри, призначені для тестування реєстрації служб перед їх розміщенням в "справжніх" реєстрах.
Так виглядає запит Web-служби:
В наведеному вище прикладі видно, що UDDI-запит инкапсулирован в SOAP-повідомлення, тому виглядає він досить знайомим. Відповіддю на запит є також SOAP-документ, показаний нижче:
Встановити SOAP-розширення для PHP5 досить легко. У Windows цей модуль знаходиться в підкаталозі ext каталогу установки РНР. Для його використання необхідно в файл php.ini додати наступний рядок: extension = php_soap.dll Для роботи цього модулю потрібно. яка включена в РНР 5 за замовчуванням, по крайней мере, в Windows-версії.
В Unix / Linux / Mac буде потрібно встановити бібліотеку libxml версії не нижче 2.5.4 Крім того, при конфігуруванні РНР необхідно вказати ключ --enable-soap
Створення Web-служб
Перш ніж розробляти Web-службу, необхідно мати її WSDL-опис. Однак створення WSDL-опису з нуля це повний атас. Тому краще за все взяти за основу опис існуючої Web-служби, яка робить те ж саме (або, принаймні, методи якої мають схожі сигнатури).
Отже, створювана нами Web-служба буде повертати GUID (Globally Unique Identifier - глобально унікальний ідентифікатор) з префіксом, що передаються службі в якості параметра. Як відомо, в РНР для цієї мети існує функція uniqid (), В дійсності наша Web-служба є оболонкою для uniqid (). Функція getGuid () виглядає наступним чином:
Залишилося зробити лише три кроки - або рядки коду:Створити SOAP-сервер, вказавши WSDL-опис.
Додати до сервера функцію getGuid ().
Доручити сервера обробку всього іншого.
Під час розробки програми, на етапі тестування, завжди забороняйте кешування WSDL-документів. інакше застарілі WSDL-опису можуть привести до виникнення непередбачуваних помилок.
Заборонити кешування можна також і в конкретному PHP-сценарії за допомогою функції ini_set ():
Лістинг нижче містить завершений хід цього прикладу, включаючи заборону на кешування WSDL.
Використання Web-служб
Щоб використовувати цю службу (і отримати бажаний GUID) нам буде потрібно клієнт. Для вирішення цього завдання розширення SOAP для РНР 5 пропонує простий спосіб доступу до Web-службі за умови доступності її WSDL-Oписание. Конструктор класу SoapClient приймає в якості аргументу ім'я файлу з WSDL-опісаніемі створює проксі-об'єкт. Поведінка цього локального об'єкта точно таке ж, як і віддаленої служби.
Перевага такого підходу полягає в тому, що ви можете працювати зі службою як з локальним об'єктом, не піклуючись про такі речі, як відкриття з'єднання, створення і синтаксичний розбір SOАР-документа тощо. По суті запит до Web-службі зводиться до двох рядках коду. У лістингу нижче додана ще одна рядок, що забороняє WSDL-кешування.
Результатом буде рядок: PHP_411f663ce6ce5
Однак цей клас містить набагато більше можливостей. Однією з них є обробка помилок. Наприклад, може знадобитися, щоб переданий префікс мав непорожнє значення і не був символом нового рядка або рядком, що містить лише пробільні символи. Якщо ці умови не дотримані, має повертатися повідомлення про помилку. Для цих цілей скористаємося вбудованим об'єктом SoapFault, призначеним для обробки помилок SOAP. У лістингу шіже показаний оновлений сервер нашої Web-служби, на цей раз повертає ще і повідомлення про помилку.
Приклад нижче містить оновлений код клієнта, який тепер за допомогою конструкції try. catch перевіряє повертається відповідь на наявність помилок.
SOAP-клієнт з обробкою помилок:
Якщо замінити виклик getGuid ( 'РНР_') на getGuid (), то SOAP-сервер поверне повідомлення про помилку: "He вказано префікс."
Отже ми дізналися, як працювати з Web-службами за допомогою розширення SOAP для РНР 5. Хоча базові технології, такі як SOAP і WSDL. є самі по собі досить складними, користуватися ними в РНР досить просто. За винятком підготовки WSDL-описів, вся інша робота зводиться до написання кількох рядків PHP-коду.
Для отримання додаткової інформації зверніться до опису згадуваних в цій статті стандартів: