WSDL: погляд зсередини, частина I, Сервери, Інтернет-технології, статті

Автор: Джоан Пітерз (Johan Peeters)

Нещодавно автору статті довелося використовувати мову WSDL (Web Services Description Language, Мова опису Web-сервісів) для декількох існуючих Web-сервісів – на одному клієнті працював сервер і клієнтська реалізація. У цього клієнта і фахівців з обслуговування сервера вже склалися тісні робочі відносини, але настав момент, коли виникла необхідність у ще одній клієнтської реалізації, яку повинна була виконати група розробників, що знаходяться в протилежний точці земної кулі. У зв’язку з цим потрібна чітка специфікація, що описує такі сервіси, а саме для цього і призначений WSDL. Тому автор намірився грунтовно вивчити те, що раніше не було достатньо освітлене. В результаті, він придбав цінний досвід – йому вдалося згадати стару і добру практику проектування програмного забезпечення та виявити ряд проблем, характерних для Web-сервісів, WSDL і XML Schema.

На самому початку, на етапі проектування, було допущено кілька помилок, які спочатку важко помітити. Ймовірно, ці недоліки не були б допущені, якщо б проектувальники дали формальне визначення для своїх сервісів на WSDL. Так що, ось основна думка цих двох статей: пишіть WSDL заздалегідь, не генерує його потім, як це часто радять постачальники.

При всій увазі, яким були обдаровані Web-сервіси, часто складно відокремити бажане від дійсного. У пропонованому циклі статей акцент буде зроблений на реальному, а не на потенційному. В них читач не знайде короткого огляду WSDL, крім того передбачається, що він знайомий з W3C XML Schema. У першій статті розповідається, чим можуть бути корисні при проектуванні Web-сервісів практика проектування програмного забезпечення та досвід в області розподіленої обробки даних. У ній розглядаються деякі рішення, які повинен приймати проектувальник Web-сервісів, наводяться необхідні поради та рекомендації. В інших статтях буде описаний процес проектування: у другій статті будуть перераховані деякі “темні сторони” специфікації WSDL 1.1. У неї не увійдуть визначення типів даних – теми третьої статті, в якій буде представлена ​​W3C XML Schema з позиції того, хто використовує її для визначення даних, що передаються через інтерфейси Web-сервісів.

Проектування Web-сервісів

Вживається автором термін Web-сервісів відноситься виключно до того виду технології, яка зосередив на взаємодії (interoperability). Це означає, що ця технологія стандартизована: гетерогенні системи працюють тільки при наявності відритих стандартів. В цьому випадку доречне запитання: чи будуть Web-сервіси рішенням вашої проблеми? Сьогодні одного слова Web-сервіси вже недостатньо, щоб говорити про солідність компанії, їх використовує, тому буде краще, якщо є інші вагомі підстави для їх використання. Якщо ви контролюєте обидва кінці каналу, не виключено, що існують більш відповідні технології. Зараз – тільки зоря ери відкритих стандартів розподіленої обробки даних. Тому ціна підтримки Web-сервісів на цьому ще не сформованій ринку залишається високою – це і зниження продуктивності, і збільшення витрат на розробку, і погіршення захищеності.

Теза про те, що Web-сервіси є “дружніми по відношенню до брандмауеру” (“firewall friendly”), оманливий. Дійсно, звичайні брандмауери оберігають корпоративні цінності від “зловмисників”, які використовують слабкі місця в прикладному програмному забезпеченні, що з’явилися в результаті відкриття портів, на яких виконуються захищені сервіси. З іншого боку, Web-сервіси через цих порти “Виставляють” прикладне програмне забезпечення. Іншими словами, вони послаблюють безпеку, надаючи стороннім особам доступ до додатків – саме те, чого мережевий брандмауер мав би перешкодити. Тому необхідне нове покоління брандмауерів. На ринку вже з’явилося кілька нових гравців, що пропонують такі продукти. Постачальники звичайних брандмауерів також починають звертати увагу на цю проблему. Але це тільки початок, і така технологія повинна ще виправдати себе.

Навіть якщо передбачається застосовувати Web-сервіси, необхідно пам’ятати, що необов’язково використовувати SOAP. Наприклад, автор статті бачив форми, що передаються як аргумент запиту на віддалений виклик процедури SOAP (SOAP-RPC). Йому також траплялися форми, які поверталися як частина відповіді віддаленого виклику процедури SOAP. Він так і не зміг знайти додаткову користь від застосування SOAP. Хіба не був би простіше звичайний XML або HTML через HTTP?

Неприпустимість генерації WSDL

Відповімо на запитання: чи призначений WSDL 1.1 для сприйняття людиною. Типовий рада – генерувати WSDL, а не писати вручну. Автор з цього питання дотримується наступної думки. Можливо, це і вірно, якщо таким чином розробляється простий, демонстраційний сервіс, але даний підхід приречений на провал, коли він застосовується до великих систем. Навіть програміст, який працює самостійно, швидко втратить загальне уявлення про проблему; ситуація ускладнюється якщо розробку спільно ведуть різні, територіально рознесені групи фахівців. Великі розподілені системи вимагають проектування; Очікування того, що після об’єднання вони будуть спільно працювати, призведе до катастрофи.

Якщо розподілені компоненти можуть розроблятися на різних мовах програмування, то для того, щоб вказати, як повинні бути задіяні сервіси, необхідний Мова опису інтерфейсів (Interface Definition Language, IDL), нейтральний по відношенню до мови програмування. У CORBA (Загальна архітектура посередника запитів до об’єктів, Common Object Request Broker Architecture), як і у DCOM (Розподілена модель компонентних об’єктів, Distributed Component Object Model), така мова є. IDL – це контракт між ініціатором на обслуговування і постачальником, але він тільки збирає синтаксис. Семантика залишається неосвітленій: IDL залишає відкритим питання про те, що робить сервіс.

WSDL – це IDL Web-сервісів. Він описує, як викликати Web-сервіси. Він також визначає відповіді, які можуть бути отримані як при успішному виклик, так і немає. Специфікація WSDL жорстко регламентує формат повідомлень, які використовуються протоколи та адреса, за якою знаходяться сервіси. На жаль, навіть чітке і суворе описі на WSDL не гарантує високу якість проектування. Подібно до всіх мов IDL, WSDL сильний у синтаксисі і слабкий в семантиці. Однак, не варто їм нехтувати – в кінцевому рахунку важлива саме семантика, синтаксис ж використовується просто, щоб її розкривати.

Проектування інтерфейсів

Перш ніж приступити до написання WSDL, необхідно узгодити з замовниками те, що Web-сервіс повинен робити. Слід записати випадки використання, чітко визначивши, як цей сервіс взаємодіє зі своєю середовищем. Припустимо, що програма-агент (actor) з будь-якою метою викликає Web-сервіс. В цьому випадку, потрібно створити не тільки сценарій “сонячного дня”, який реалізує поставлену задачу, але сценарій “Дощового дня”, коли результат негативний. Які гарантії може запропонувати система, що мета успішно досягнута? А коли ні? Де знаходиться межа відповідальності клієнтської частини і сервера?

Важко переоцінити важливість чіткого визначення вимог. На цьому етапу варто задуматися про мету проекту. У чому конкретно вона полягає? Які дані необхідно отримувати від клієнта, і що повинен поставляти сервер? Вчинення помилки на цьому кроці загрожує великими витратами.

Наприклад, розглянемо Web-сервіс, який у якості параметрів приймає список встановлених програм і величину вільного місця на диску. Потім цей сервіс повинен повернути список програм, які підлягають оновленню. У разі якщо місця достатньо, проблем не виникає. Однак, як бути, якщо його недостатньо? Як вибрати продукти, для яких необхідно встановити нові версії? Чи передбачається, що клієнт сам видаляє старі редакції програм, щоб звільнити місце для нових? Це непрості питання, для вирішення яких потрібно розробляти складні алгоритми, при реалізація яких не виключені помилки. Зрозуміло, ні одну систему не слід визначати подібним чином. Сервер повинен надавати перелік програм, залежності між ними і вимоги, які вони пред’являють до ресурсів. Рішення ж про тому, який пакет встановити, є завданням клієнта. Тому доручивши серверу це завдання, клієнт нічого не виграє, він тільки підвищить витрати на розробку серверної частини.

Таким чином, необхідно проводити аналіз витрат на початковому етапі. При цьому можна проігнорувати технічні деталі – сервіс можна розглядати як чорний ящик. Але не можна нехтувати деталями, що стосуються взаємодії між цим сервісом і його середовищем.

Наступний крок – проаналізувати, як можна реалізувати випадки використання. Чи буде єдиний інтерфейс (portType в WSDL версії 1.1), що забезпечує всю функціональність? Або кілька інтерфейсів? Кожен інтерфейс може бути запропонований у кількох кінцевих точках, але, як правило, він повинен бути неподільним. Тобто кінцева точка повинна надавати або всю функціональність, або нічого. Аналогічно, інтерфейс повинен бути семантично послідовним. Сказане носить рекомендаційний характер і спирається на здоровий сенс, хоча ніщо в специфікації WSDL не перешкоджає іншій інтерпретації.

Потрібні якісь підтримують інтерфейси? Як і коли вони повинні викликатися? Яка природа цієї залежності? Поки немає стандартів, а тільки рекомендації про те, як поводитися з “хореографією сервісів “(service choreographies), як вирішувати сервісів виконувати гіперпосилання до інших сервісів. Іншими словами, це недосліджена проблемна область.

Повертає чи розробляється сервіс результат клієнтові? Чи повинен клієнт мати інформацію про те, що сервіс успішно відпрацював? Чи повинен клієнт викликати сервіс синхронно? Або асинхронно? Або ж сервіс буде підтримувати обидва типи виклику?

Непрозорість мережі

Мережа не є прозорою – виклик локального сервісу і його віддалений виклик істотно відрізняються один від одного. У якості “пам’ятки розробнику” можна порекомендувати тези Пітера Дойча (Peter Deutsh) “Вісім помилок про розподіленої обробки даних” (eight fallacies of distributed computing).

Невірна семантика різна для мережевого оточення та локальної реалізації: при невдалому виклик не завжди відомо, виповнився сервіс чи ні.

WSDL 1.1 описує наступні види викликів: односторонній (one-way), запит-відповідь (request-response), відповідь на вимогу (solicit-response) і повідомлення (notification). Проте, зв’язування WSDL підтримують тільки односторонній виклик і виклик виду запит-відповідь. Також слід розуміти, що реально, а що – ні. Іншими словами, сьогодні неможливо реалізувати ситуацію, коли клієнт чекає з сервера асинхронне отримання практичного, “промислового якості” та узгодженого із стандартами результату. Це слід розцінювати як прикру обставину, оскільки це саме той механізм, який є найбільш гнучким у ситуації часткового збою.

WSDL дозволяє перемішувати і погоджувати види виклику і транспорт (transport). На цьому етапі важливо вдатися до здорового глузду. Перша вимога – а це не завжди очевидно – необхідно чітко уявити, як стек протоколів пропонованого Web-сервісу буде себе вести. Як приклад розглянемо, що станеться якщо асинхронно викликати Web-сервіс поверх механізму синхронного транспорту. Припустимо, що SOAP-повідомлення пересилається в одну сторону по HTTP: бізнес логіка на клієнті формує SOAP повідомлення, щоб викликати віддалений сервіс. В результаті запит HTTP надсилається на сервер. Коли сервер отримує запит, він повинен негайно повернути відповідь HTTP, не обслуговуючи цей запит. Бізнес логіка на сервері повинна відпрацьовувати після того, Як ця відповідь була повернуто. Ця відповідь не повинен містити SOAP-повідомлення. Відповідь HTTP з кодом стану 200 або 202 не означає, що сервіс успішно відпрацював. Код збою, з іншого боку, повинен гарантувати, що виклик сервісу не виповнився. Шар SOAP на клієнті не формує нових повідомлень до тих пір, поки він не отримає відповідь, або поки не закінчиться час очікування.

Таким чином, односторонній виклик НЕ “Усуває” затримки або несправності в мережі. Найбільше – він допомагає уникнути затримки з бізнес логікою на сервері. Автор використав “найбільше”, маючи на увазі, що цю функціональність варто протестувати на інструментальній ланцюжку сервера, перш ніж покладатися на неї-коректна реалізація є нетривіальним завданням для будь-якого постачальника.

Використовуючи HTTP в в якості транспортного протоколу, клієнт може бути впевнений, що його запит був доставлений. Варто зауважити, однак, що якщо клієнт не отримав відповідь, це не означає, що сервер не отримав і не обробив коректно цей запит. Наприклад, мережа може “впасти” під час відправки відповіді. Іншими словами, реалізувати виклик просто, правильно завершений виклик – немає.

Відмінність Web-сервісів від розподілених об’єктів

Об’єкти характеризуються станом. Слід уникати стану, оскільки воно пов’язує ресурси і послаблює масштабованість. Слабозв’язаних архітектура дозволяє окремим компонентам змінюватися, не руйнуючи систему. Досить імовірно, що в майбутньому буде потрібно розширювати Web-сервіс. Як же при цьому зберегти зворотну сумісність?

Незважаючи на те, що гідність віддаленого виклику процедури (RPC) в легкості реалізації, він не дуже добре уживається зі слабкою пов’язаністю: необхідно передавати фіксований список параметрів при кожному виклику Web-сервісу. Цю проблему можна в деякій мірі зробити менш гострою, дозволивши деяким параметрам “не мати значення”. Залишимо без розгляду виникають в цьому випадку проблеми, пов’язані із забезпеченням можливості взаємодії, – більш фундаментальне обмеження полягає в тому, що цей прийом дозволяє виключати параметри, а не додавати їх. Виклики в стилі документа проявляють себе краще, коли частини документа можуть бути визначені як необов’язкові. Вони також можуть бути спроектовані для розширюваності.

Визначення обмежених інтерфейсів

Слід уважно вивчити те, що пропонується: і на рівні даних, і на рівні кодування даних. Необхідно пам’ятати, що доведеться продовжити підтримувати поставляється інтерфейс. Чим обмеженішими інтерфейс, тим легше його реалізація. WSDL ж спроектований для гнучкості .. Через цю гнучкості легко помилитися в специфікації Web-сервісів і залишити багато опції реалізації неохопленими. Слід уникати цього – Клієнти і сервери повинні вміти обробляти все повідомлення, які допустимі за контрактом.

Типова помилка, чинена при реалізації серверних систем, – встановлення з’єднання з базою даних при кожному запиті до цієї бази. Автор зробив таку помилку – з’ясувалося, що встановлення з’єднання з базою даних займає більше часу, ніж все інше, разом узяте. Щоб мінімізувати це падіння продуктивності, можна вдатися до одного з двох прийомів: скористатися пулом з’єднань (Connection pool) або збереженої процедурою.

При використанні Web-сервісів вартість установки з’єднання також висока. Знову-таки додаткові витрати на виклик можуть бути зменшені повторним використанням існуючого з’єднання. З іншого боку, необхідно враховувати, що підтримка відкритого з’єднання вимагає ресурсів. Однак, важливо пам’ятати, що витрати, пов’язані з викликами Web-сервісу, набагато вищі в порівнянні з викликом локальної функції і, отже, їх слід рідше використовувати.

Тут доречно провести аналогію з збереженими процедурами. Замість відправки даних і обробки їх на клієнта, тільки щоб з’ясувати, що потрібні ще дані, збережені процедури оперують з даними в адресному просторі бази даних. Застосування збережених процедур в додатках баз даних є спірним моментом – принаймні, з двох причин. По-перше, мова написання збережених процедур не стандартизований, і тому їх використання веде до залежності від постачальника БД. По-друге, бізнес логіка повинна знаходитися в окремому шарі, а не в базі даних.

Тим не менш, збережені процедури вирішують реальну проблему, і їх недоліки повинні бути співвіднесені з достоїнствами в кожному окремому випадку. Аналогічно, в області Web-сервісів, клієнту надається контроль над логікою за рахунок безлічі дрібно структурних викликів. Крупно структурні сервіси більш нагадують збережені процедури. Вони не тільки поліпшать продуктивність, але й умовив процес реалізації, впровадження і управління всією системою.

Отже, практична рекомендація – проектувати Web-сервіси під обмежені, але крупно структурні інтерфейси. Обмеженість дозволяє показувати як можна менше, крупність структури – виконувати як якомога більше для одного дзвінка.

Рознесення бізнес логіки і політики

Не слід реалізовувати аутентифікацію і авторизацію в бізнес логіці. Безпека транспортного рівня може бути як задовільною, так і немає. У розділі Ресурси наведено посилання на статті, в яких розглядається це питання. Навіть якщо безпека транспортного рівня і не урізається, все одно поки немає стандартів – вони тільки розробляються, і з них варто відзначити створювані Технічним комітетом OASIS “Захищеність Web-сервісів” (OASIS Web Services Security Technical Committee). Пропоновані підходи дійсно сприяють розділенню бізнес логіки і політики (policy): заголовки SOAP вставляються в сервіс, щоб забезпечити характеристики безовасності, а інформативна частина повідомлення зберігається для бізнес логіки.

Але як же без ложки дьогтю – пропонований стандарт застосовний тільки до Web-сервісів, які використовують SOAP. Ще одна неприємність – відсутність стандартизованого способу вказати Якість захисту (Quality of Protection, QoP) сервісу в документі WSDL. Microsoft, BEA, SAP і IBM опублікували специфікацію для “Додатків політики Web-сервісів” (Web Services Policy Attachments), В якій розглядається це питання. Наскільки відомо автору, цей документ ще не був переданий ні в один орган стандартизації.

Поділ проектування і реалізації

В ідеалі при проектуванні Web-сервісів варто залишити питання реалізації в стороні. Суть проектування-подивитися на систему на високому рівні абстракції, не звертаючи уваги на проблеми реалізації. Однак, можна вибрати такий, здавалося б відповідний по всіх параметрах дизайн проекту, який виявиться марним, якщо інструментальні ланцюжки, які передбачається використовувати, не підтримують конструкції в розробленому WSDL. Автор наполегливо рекомендує створення макета з технічних специфікацій для перевірки реальності здійснення проекту. Поки цей момент ще не опрацьований.

Подяки

Автор висловлює глибоку подяку Марку Портайеру (Mark Portier) і Керолайн Грінмен (Caroline Greenman) за їх конструктивні зауваження.

Ресурси

“Мильна опера” на тему захищеність Web-сервісів буде тривати ще довго. Нижче приведено “зміст перших серій”:

У статті “IDL, якого немає” (The IDL That Isn’t) Мартіна Гуджино (Martin Gudgin) і Тімоті Іуолда (Timothy Ewald) наводиться більш глибокий аналіз WSDL з позицій IDL.

У білому папері “Хто пише контракти Ваших Web-сервісів” (Who Writes Your Web Service Contracts?) Корпорації Karniak розповідається про те, як точний опис спрощує процес розробки Web-сервісу.

Оригінальний текст статті можна подивитися тут:

WSDL Tales From The Trenches, Part 1

Схожі статті:


Сподобалася стаття? Ви можете залишити відгук або підписатися на RSS , щоб автоматично отримувати інформацію про нові статтях.

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*