Введення у веб-сервіси - Програмні продукти

Передмова

У різних розділах документа ці технології застосовуються до одного прикладу, що є функцією, яка повертає скорочене позначення для назви заданої компанії.

Цей документ корисний для керівників, які потребують розгорнутої презентації веб-сервісів, а також для розробників, яким потрібні технічні подробиці. Оскільки технології SOAP, WSDL і UDDI мають у своїй основі стандарт XML, у читача мають бути певні базові уявлення про те, що є цією мовою, її схемами та простором імен. У розділі з довідковою інформацією наприкінці документа зазначено, де можна знайти відповідну інформацію.

Історичний ракурс

Парадигма розподілених обчислень виникла одночасно із появою комп'ютерних мереж. Програми були поділені на дві частини: перша, клієнтська, ініціювала розподілені операції, а друга, серверна, забезпечувала їхнє виконання. Така децентралізація знижувала можливість виникнення вузьких місць, розподіляючи робоче навантаження між кількома системами. Також забезпечувалась гнучкість дизайну додатків, яка була недоступна раніше, в епоху централізованих мережевих вузлів (хостів). Але в такій дволанковій архітектурі були свої обмеження. Для вирішення проблем пов'язаних з відмовостійкістю та масштабованістю була запропонована триланкова модель, що розділяє програми на презентаційну частину (проміжне ланка, що містить бізнес-логіку) та третю ланку, безпосередньо пов'язану з даними. Така модель розподілу стала найпопулярнішим способом поділу додатків. Вона дозволила зробити прикладні системи масштабованими. Основою взаємодії між розподіленими частинами докладання у ній є викликидистанційних процедур (RPC). Щоб позбавити розробників виконання завдань нижнього рівня, наприклад, від перетворення даних або від їх побайтового впорядкування на різних машинах, на ринок було випущено програмне забезпечення нового рівня. Це проміжне ПЗ приховує різницю між типами мережевих вузлів. Воно розміщується над операційними системами і мережевими службами, встановленими цих хостах, обслуговуючи які до більшому рівні докладання.

Перші проміжні програмні продукти, наприклад, DCE, ґрунтувалися на моделі процедурного програмування. Їм на зміну прийшла об'єктно-орієнтована модель, що реалізується в проміжних програмних продуктах CORBA, DCOM або RMI, які є найпопулярнішим програмним забезпеченням цього класу.

Поточна ситуація

Як вже обговорювалося раніше, існує три основні технології проміжного програмного забезпечення: DCOM, CORBA та RMI. Кожна з них має свої переваги та недоліки. У цьому розділі засуджуються лише основні можливості, без заглиблення у подробиці цих технологій. Це забезпечить уявлення, як веб-сервіси вписуються в загальну картину.

CORBA є заснованим на відкритих стандартах рішенням для виконання розподілених обчислень. Промисловий консорціум OMG (група розвитку стандартів управління програмними об'єктами) розробив специфікацію для CORBA і визначив протокол Internet InterORB Protocol (IIOP), що є стандартним протоколом комунікації між диспетчерами об'єктних запитів ORB (Object Request Brokers).

Основна перевага CORBA полягає в тому, що клієнти і сервери можуть бути написані будь-якою мовою програмування. Це стає можливим, оскільки об'єкти визначаютьсяз високим рівнем абстракції, що забезпечується мовою визначення інтерфейсу IDL (Interface Definition Language). Після того, як визначення буде виконано в IDL-файлі, компілятор забезпечує його перетворення на певну мову програмування. Взаємодії між об'єктами, клієнтами та серверами обробляються за допомогою диспетчерів об'єктних запитів ORB. Якщо від розподіленої програми потрібна висока продуктивність, то CORBA є найкращим вибором проміжного програмного забезпечення. Однак написання розподілених програм за допомогою CORBA - це дуже складне завдання. Щоб забезпечити перетворення IDL на різні мови програмування, доводиться обмежуватися тими базовими концепціями, які реалізовані мовами. Таким чином, IDL є для них чимось на зразок спільного знаменника.

Для охоплення різних галузей застосування CORBA використовує звані " сервіси " . Це дуже ускладнює специфікацію, робить її дуже складною. Крім того, до цього часу постачальниками випущено відносно невеликий набір таких сервісів.

Щоб забезпечити взаємодію між клієнтськими та серверними об'єктами, диспетчери об'єктних запитів повинні розміщуватись по обидва боки такого з'єднання.

Технологія виклику віддалених методів RMI (Remote Method Invocation) дозволяє створювати розподілені програми Java-to-Java. Вони методи віддалених Java-об'єктів можуть викликатися з інших віртуальних машин Java (JVM), які найімовірніше перебувають у різних вузлах мережі. Java-програма може виконати виклик віддаленого об'єкта після отримання на нього посилання, або виконавши пошук віддаленого об'єкта в простір імен, що пропонується RMI, або отримавши посилання в якості аргументу або повертається значення. Клієнтможе викликати віддалений об'єкт на сервері. Цей сервер також може бути клієнтом для інших віддалених об'єктів. RMI використовує серіалізацію об'єктів, щоб упорядкувати та розпорядити їх параметри та запобігти усіканню типів, підтримуючи справжній об'єктно-орієнтований поліморфізм. Для комунікацій використовується протокол JRMP (Java Remote Method Protocol).

Програмування з використанням RMI не викликає проблем, якщо розробник набув певного досвіду створення розподілених програм та програмування на мові Java. При цьому не потрібне використання абстрактних мов (наприклад IDL) для опису віддаленого серверного об'єкта. Крім того, RMI підтримує розподілений механізм регенерації пам'яті, що звільняється.

З іншого боку, для використання цієї технології потрібна наявність Java-машин на обох сторонах з'єднання. Завдяки відносній простоті цього проміжного ПЗ, його зручно та легко використовувати. При цьому немає ніяких сервісів, як це було у випадку з CORBA. Усі ці аспекти мають враховуватися розробниками.

Технологія DCOM (Microsoft Distributed Component Object Model) дозволяє здійснювати виклики віддалених об'єктів за допомогою ланки, що надбудовується поверх механізму DCE RPC та взаємодіє з оперативними COM-сервісами. DCOM публікує свої методи для клієнтів, підтримуючи різні інтерфейси. Вони пишуться мовою IDL, схожому з C++. Цей компілятор IDL створює модулі доступу (заступники), заглушки та скелетні елементи програми так само, як це робить IDL-компілятор CORBA, але реєструє їх також у системному реєстрі. Крім цього, створюються бібліотеки типів. Вони є файлами, в яких описуються віддалені об'єкти і вказується, які з них можуть запитуватися.інтерфейсами, які забезпечуються механізмом COM.

Для цього використовується протокол дзвінків віддалених об'єктних процедур ORPC (Object Remote Procedure Call).

Специфікація DCOM на бінарному рівні дозволяє використовувати різні мови для програмування серверних об'єктів.

Як і RMI, технологія DCOM підтримує розподілений механізм регенерації пам'яті, що звільняється віддаленими серверними об'єктами. Це досягається завдяки використанню механізму опитування, що перевіряє, як і активне підключення клієнта. На серверній стороні клієнтів підтримується відповідний лічильник посилань. Якщо показуване їм значення скорочується нанівець, відбувається звільнення ресурсів, займаних об'єктом.

Більшість користувачів пов'язують технологію DCOM із операційними системами Microsoft. Проте вже існують портовані версії DCOM для Unix, VMS та Apple Macintosh.

Попередній висновок

Як було показано в попередньому розділі, всі ці три технології використання проміжного програмного забезпечення працюють за одним схожим сценарієм. Їх відмінності виявляються насамперед у різних підтримуваних можливостях, а також у рівні складності. Всі вони призводять до встановлення надійного з'єднання клієнта з сервером, тому будь-яке з перерахованих вище проміжних ПЗ придатне для використання. Через різницю в протоколах не можна здійснити виклик DCOM-сервера з RMI-клієнта. (Одним із кроків вирішення цієї проблеми є звернення до механізму, що викликає RMI поверх IIOP, який використовується при розробці із застосуванням Enterprise JavaBeans). При цьому встановлюється з'єднання за принципом від точки до точки.

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

Майбутні перспективи: веб-сервіси

У цьому розділі описуються веб-сервіси та те, як вони співвідносяться з традиційним проміжним програмним забезпеченням. Після короткого огляду буде представлено три фундаментальні складові веб-сервісів: SOAP, WSDL і UDDI.

Короткий огляд

  • отримання інформації про курс акцій;
  • отримання прогнозу погоди;
  • резервування авіаквитків.

Для виконання завдань одні веб-сервіси можуть використовувати інші веб-сервіси.

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

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

Визначення

"Веб-сервіси - це виділені в самостійний елемент, слабко пов'язані стислі функції, що пропонуються за стандартними протоколами",

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

Архітектура

Згідно з традиційними уявленнями клієнт-серверного підходу існував сервер, що пропонує будь-які функціональні можливості, які могли бути використані або викликані клієнтом. Механізм, схожий на пошукову службу, виконував роль агента між цими клієнтом та сервером.

Оскільки веб-сервіси представляють просто ще одну парадигму для розподілених додатків, вони складаються з тих самих трьох компонентів:

  • Сервісного агента, що грає роль пошукової служби між постачальником та ініціатором сервісного запиту.
  • Постачальника сервісів, який публікує свої послуги для сервісного агента.
  • Ініціатора сервісного запиту, який запитує у сервісної інформації агента про те, де знайти відповідного постачальника сервісів, а потім зв'язується з цим постачальником.

Наступний рисунок ілюструє відносини між компонентами веб-сервісів.