Що таке веб-сервіс. Що таке "веб-сервіс" простою англійською мовою

Ідея веб-сервісів була розроблена такими гігантами комп'ютерної промисловостіяк Sun, Oracle, HP, Microsoft та IBM. У цій ідеї немає нічого нового, але це великий крок уперед до спрощеного доступу до програм через мережу. На основі стандартних форматів зв'язку, веб-сервіси можуть взагалі змінити наше уявлення про те, як ми повинні робити веб-сайти.

Що таке веб-сервіс?

Завдяки веб-сервісам функції будь-якої програми можуть стати доступними через Інтернет. Таким чином, такі програми як PHP, ASP, JSP скрипти, JavaBeans, COM-об'єкти та всі інші наші улюблені засоби програмування можуть тепер звертатися до якоїсь програми, що працює на іншому сервері (тобто до веб-сервісу), і використовувати відповідь, отримана від неї на своєму веб-сайті, або програмі.

Скажімо, якщо мені потрібно виконати якесь програмне завдання, і я надто зайнятий (або не вижив з розуму, щоб самому винаходити в черговий раз велосипед), я можу скористатися послугами веб-сервісу, до якого мій сайт звертатиметься через Інтернет. Передаючи веб-сервісу запит із параметрами, я очікую отримати відповідь, в якій буде містити результат виконання мого запиту.

Будь-хто, хто хоч раз працював останнім часом з Hotmail, вже частково зіткнувся з веб-сервісами: система аутентифікації користувачів Passport - це один із сервісів, що входять до ініціативи Microsoft .NET. поки він доступний безкоштовно, тому творці веб-сайтів можуть запросто впровадити автентифікацію користувачів на своєму сайті.

Основи

Принципи, що лежать в основі веб-сервісів, напрочуд прості. І вони нічого не додають нового у світ розподілених обчислень та Інтернету:

• особа, відповідальна за веб-сервіс, визначає формат запитів до свого веб-сервісу та його відповідей
• будь-який комп'ютер у мережі робить запит до веб-сервісу
• веб-сервіс обробляє запит, виконує будь-яку дію, а потім надсилає відповідь

Цією дією може бути, наприклад, висновок котирування акцій, виведення ціни на певний продукт, збереження запису в календарі зустрічей, переклад тексту з однієї мови на іншу, або перевірка номера кредитної картки.

Стандарти в основі

Причина, через яку ми всі раптом зацікавилися веб-сервісами, у тому, що в їх основі лежать стандарти, відкриті протоколи обміну та передачі даних.

До цього багато компаній розробляли свої власні закриті стандарти та формати. А зараз нам для роботи потрібно знати лише простий XML (eXtensible Markup Language), який передається по старому знайомому протоколу HTTP. Це означає, що інформація про роботу веб-сервісів доступна для всіх, і веб-розробники, які за професією знайомі з цими технологіями, можуть почати грати з веб-сервісами вже сьогодні.

Різниця між веб-сервісами та іншими технологіями, з якими розробникам доводилося стикатися (наприклад, DCOM, іменовані канали - named pipes, RMI) у тому, що веб-сервіси засновані на відкритих стандартах, ними легко опанувати, і ці стандарти широко підтримуються на всіх платформах Unix та Windows.

Протокол Simple Object Access Protocol (SOAP) є стандартним протоколом, розробленим W3C. Він визначає формат запитів до веб-сервісів.

Повідомлення між веб-сервісом та його користувачем пакуються в SOAP-конверти (SOAP envelopes). Повідомлення містять або запит на здійснення дії, або відповідь - результат виконання цієї дії. Конверт та його вміст закодовано мовою XML, і його досить легко зрозуміти. Ось як виглядає простий SOAP-запит, який надсилається через HTPP до веб-сервісу:

xmlns:env="http://www.w3.org/2001/06/soap-envelope">


xmlns:m="http://www.somesite.com/Postcode">
WC1A8GH
UK

Ключові елементи SOAP-конверта дізнатися досить просто: це два параметри ( ("поштовий індекс") та ("країна")), які містяться всередині елемента під назвою . Цей елемент є назвою веб-сервісу, до якого ми звертаємось із запитом. Інші дані в конверті, такі як кодування тексту та версія SOAP, допомагають веб-сервісу правильно обробити запит.

А відповідь виглядатиме ось так:

xmlns:env="http://www.w3.org/2001/06/soap-envelope" >

env:encodingStyle="http://www.w3.org/2001/06/soap-encoding"
xmlns:m="http://www.somesite.com/Postcode">
Yes

Це повідомлення ще простіше розшифрувати. Елемент у нашому запиті змінився у відповіді запит. Цей елемент містить лише один елемент , значення якого означає, чи вірний наш поштовий індекс чи ні. Таким чином, за допомогою чарівництва SOAP ми створили запит, який робить для нас корисну роботу. У відповідь через мережу ми отримуємо певного виду на мові XML.

Тепер про UDDI

Навіть при всій простоті протоколу SOAP користі у веб-сервісах було б небагато, якби ми не мали жодної можливості їх знайти. На щастя IBM, Microsoft та компанія Ariba виступили з ініціативою та створили проект Universal Description, Discovery and Integration (UDDI), який, як вони сподіваються, стане загальним каталогомвсіх веб-сервісів у Web-і.

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

Як це все працює

То як мені знайти потрібний веб-сервіс?

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

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

Замість того, щоб розщедрюватися на купівлю бази даних, писати самому код, стежити за цілісністю та правильністю всіх даних та налагоджувати роботу скриптів, я просто йду в каталог UDDI та шукаю, чи немає там веб-сервісу, який міг би зробити цю роботу за мене . Прийшовши на сайт www.uddi.org, я запускаю пошук та знаходжу чудовий сервіс від компанії XYZ Corp.

Я уважно розглядаю визначення формату веб-сервісу (визначення записане мовою WSDL (Web Services Description Language), переконуюсь, що сервіс робить саме те, що мені потрібно. Потім я справляюсь у своїх колег про репутацію компанії XYZ Corp., дізнаюся, що вона солідна , і потім звертаюся до компанії XYZ з питанням про ціну. Якщо ціна доступу до сервісу доступна для мого бюджету, я пишу просту JSP-сторінку для свого сайту, який викликає веб-сервіс компанії XYZ Corp, і опля, на сайті з'являється моментальна перевірка поштового індексу.

На це варто витратити час

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

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

Відкиньте страх! Готовий поручитися, що в Мережі вже існує веб-сервіс, який готовий представити вам необхідну функцію, а вартість користування цим веб-сервісом буде набагато нижчою від вартості самостійної розробки його аналога. Таким чином ви уберегаєте свого розробника від зайвого головного болю, вашого клієнта від зайвої витрати грошей, лише витративши пару хвилин на перегляд каталогу UDDI.

Розробка сервісу

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

Вибір інструментів розробки веб-сервісів великий. До нього входять інструментарії таких компаній як Sun (Open Net), Microsoft (.NET), (e-services) та IBM ( Web Services). Існують також інструментарії з відкритими вихідними кодами(Open source frameworks). Наприклад, проект Mono Project прагне замінити собою інструментарій Microsoft .NET, надавши систему компіляції (compilers), виконання коду (runtime) та бібліотек (libraries) для роботи тих самих веб-сервісів на всіх платформах, включаючи Unix.

Незважаючи на різноманітність серверів та засобів розробки веб-сервісів, всі вони підтримують один і той же протокол SOAP, мову XML та систему UDDI.

Мінуси

Перш ніж я повністю відмовлюся від кар'єри програміста і присвячую себе використанню веб-сервісів, я повинен поставити собі питання: "Аж надто рожева картинка. Що в ній не так?". На жаль, за великий потенціал веб-сервісів доводиться платити певну ціну:

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

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

Веб-сервіс (англ. web service) - ідентифікована веб-адресою програмна системазі стандартизованими інтерфейсами. Веб-служби можуть взаємодіяти один з одним і з іншими програмами за допомогою повідомлень, заснованих на певних протоколах. В побуті веб-сервісами називають послуги, що надаються в Інтернеті.

FTP ( File Transfer Protocol)

FTP (англ. File Transfer Protocol – протокол передачі файлів) – стандартний протокол, призначений для передачі файлів по TCP-мережах (наприклад, Інтернет). FTP часто використовується для завантаження мережевих сторінок та інших документів із приватного пристрою розробки на відкриті сервери хостингу.

SSH (Secure Shell)

SSH (англ. Secure SHell - "безпечна оболонка") - мережевий протокол прикладного рівня, що дозволяє виробляти віддалене управління операційною системоюта тунелювання TCP-з'єднань (наприклад, для передачі файлів). Схожий по функціональності з протоколами Telnet і rlogin, але, на відміну від них, шифрує весь трафік, включаючи паролі, що передаються. SSH припускає вибір різних алгоритмів шифрування. SSH-клієнти та SSH-сервери доступні для більшості мережевих операційних систем.

TELNET (англ. TERminaL NETwork) - мережевий протокол для реалізації текстового інтерфейсу по мережі (у сучасній формі - за допомогою транспорту TCP). Назву "telnet" мають також деякі утиліти, що реалізують клієнтську частину протоколу.

SMTP (Send Mail Transfer Protocol)

SMTP (Simple Mail Transfer Protocol — простий протокол передачі пошти) — це широко використовуваний мережевий протокол, призначений передачі електронної пошти у мережах TCP/IP.

DNS (Domain Name Service)

DNS (англ. Domain Name System - система доменних імен) - комп'ютерна розподілена система для отримання інформації про домени. Найчастіше використовується для отримання IP-адреси на ім'я хоста (комп'ютера або пристрою), отримання інформації про маршрутизацію пошти, обслуговуючих вузлах для протоколів у домені (SRV-запис).

DHCP (Dynamic Host Control Protocol)

DHCP (англ. Dynamic Host Configuration Protocol – протокол динамічної конфігурації вузла) – це мережевий протокол, що дозволяє комп'ютерам автоматично отримувати IP-адресу та інші параметри, необхідні для роботи в мережі TCP/IP. Цей протокол працює за моделлю «клієнт-сервер». Для автоматичної конфігурації комп'ютер-клієнт на етапі конфігурації мережевого пристроюзвертається до так званого серверу DHCPі отримує від нього потрібні параметри. Мережевий адміністраторможе встановити діапазон адрес, що розподіляються сервером серед комп'ютерів. Це дозволяє уникнути ручного налаштуваннякомп'ютерів мережі та зменшує кількість помилок. Протокол DHCP використовується у більшості мереж TCP/IP.

HTTP (HyperText Transfer Protocol)

HTTP (англ. HyperText Transfer Prоtocоl - "протокол передачі гіпертексту") - протокол прикладного рівня передачі даних (спочатку - у вигляді гіпертекстових документів). Основою HTTP є технологія «клієнт-сервер», тобто передбачається існування споживачів (клієнтів), які ініціюють з'єднання та надсилають запит, і постачальників (серверів), які очікують на з'єднання для отримання запиту, роблять необхідні дії та повертають назад повідомлення з результатом.

POP3 (Post Office Protocol, version 3)

POP3 (Post Office Protocol Version 3 - протокол) поштового відділення, версія 3) — стандартний Інтернет-протокол прикладного рівня, що використовується клієнтами електронної пошти для отримання електронного повідомленняз віддаленого сервера через TCP/IP-з'єднання.

SFTP (Secure File Transfer Protocol)

SFTP (SSH File Transfer Protocol) — протокол прикладного рівня, призначений для копіювання та виконання інших операцій з файлами поверх надійного та безпечного з'єднання. Протокол розроблений групою IETF як розширення SSH-2, проте SFTP допускає реалізацію і з використанням інших протоколів сеансового рівня.

NNTP (Network New Transfer Protocol)

NNTP (англ. Network News Transfer Protocol) — це мережевий протокол, поширення, запитування, розміщення та отримання груп новин при взаємодії між сервером груп новин та клієнтом.

NTP (Network Time Protocol)

Network Time Protocol (NTP) — мережевий протокол для синхронізації внутрішнього годинника комп'ютера з використанням мереж зі змінною латентністю.

NetBIOS (Network Basic Input/Output System) - протокол для роботи в локальних мережахна персональних ЕОМ типу IBM/PC, розроблений як інтерфейсу, який залежить від фірми-виробника. Був розроблений фірмою Sytek Corporation на замовлення IBM у 1983 році. Він включає інтерфейс сеансового рівня (англ. NetBIOS interface), в якості транспортних протоколів використовує TCP і UDP.

IMAP (Internet Message Access Protocol)

IMAP (Internet Message Access Protocol) — протокол прикладного рівня для доступу до електронної пошти.

SNMP (Simple Network Management Protocol)

SNMP (Simple Network Management Protocol — простий протокол мережного управління) — стандартний інтернет-протокол для управління пристроями в IP-мережах на основі архітектур UDP/TCP. До пристроїв, що підтримують SNMP, відносяться маршрутизатори, комутатори, сервери, робочі станції, принтери, модемні стійки та інші. Протокол зазвичай використовується в системах мережного управління для контролю підключених до мережі пристроїв щодо умов, які вимагають уваги адміністратора. SNMP визначений Інженерною порадою інтернету (IETF) як компонент TCP/IP. Він складається з набору стандартів для мережного керування, включаючи протокол прикладного рівня, схему баз даних та набір об'єктів даних.

LDAP (Lightweight Directory Access Protocol)

LDAP (Lightweight Directory Access Protocol — «полегшений протокол доступу до каталогів») — протокол прикладного рівня для доступу до служби каталогів X.500, розроблений IETF як полегшений варіант розробленого ITU-T протоколу DAP. LDAP — відносно простий протокол, що використовує TCP/IP і дозволяє здійснювати операції авторизації (bind), пошуку (search) і порівняння (compare), і навіть операції додавання, зміни чи видалення записів.

SSL (Secure Socket Layer)

SSL (Secure Sockets Layer — рівень захищених сокетів) — криптографічний протокол, який забезпечує встановлення безпечного з'єднання між клієнтом і сервером. SSL спочатку розроблено компанією Netscape Communications. Згодом на підставі протоколу SSL 3.0 був розроблений та прийнятий стандарт RFC, який отримав ім'я TLS.

NFS (Network File System)

Network File System (NFS) – протокол мережного доступудо файлових систем, спочатку розроблений Sun Microsystems у 1984 році. Заснований на протоколі виклику віддалених процедур. Дозволяє підключати (монтувати) видалені файлові системичерез мережу.

MySQL - вільна системауправління базами даних. Розробку та підтримку MySQL здійснює корпорація Oracle, яка отримала права на торгову марку разом із поглиненою Sun Microsystems, яка раніше придбала шведську компанію MySQL AB. Продукт поширюється як під GNU General Public License, і під власною комерційною ліцензією. Крім цього розробники створюють функціональність на замовлення ліцензійних користувачів, саме завдяки такому замовленню майже в ранніх версіях з'явився механізм реплікації.

Virtual Network Computing (VNC) - система віддаленого доступу до робочого столу комп'ютера, що використовує протокол RFB (Remote FrameBuffer, віддалений кадровий буфер). Управління здійснюється шляхом передачі натискань клавіш на клавіатурі та рухів миші з одного комп'ютера на інший та ретрансляції вмісту екрана через комп'ютерну мережу.

Веб-служба – це програма, до якої можуть звертатися інші програми через Інтернет (http). Наприклад, припустимо, що у вас є функція, яка надає текст у форматі HTML. Ціль програми - це веб-браузер, який відображає результати, і людина зможе легко прочитати цей текст на сторінці.

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

Основною перевагою веб-служби є те, що програми можуть бути написані будь-якою мовою, але вони можуть обмінюватися даними та обмінюватися даними один з одним через веб-службу. Програмні програми, написані різними мовами програмування та працюють на різних платформах, можуть використовувати веб-служби для обміну даними через Інтернет (HTTP). Це взаємодія (наприклад, між Java і Python, або програмами Windowsта Linux) пов'язане з використанням відкритих стандартів (XML, SOAP, HTTP).

• SOAP (простий протокол доступу до об'єктів)
• UDDI (універсальний опис, виявлення та інтеграція)
• WSDL (мова опису веб-сервісів)

Скільки існує різноманітних видів веб-служб?

Насамперед існують два типи веб-служб, простий протокол доступу до об'єктів (SOAP) та репрезентативне перенесення станів (REST).

• Веб-служба SOAP приймає запит у форматі XML та генерує висновок у форматі XML.
• Веб-служба REST більш універсальна і може приймати XML, а також JSON як запит і генерує висновок у XML, а також JSON або навіть HTML

Докладніше це питання може бути вивчений на наших .

Практичне використання Web-сервісів у IBM Lotus Domino 7

Що таке Web-сервіси та чому вони важливі?

Серія контенту:

Цей контент є частиною # із серії # статей: Практичне використання Web-сервісів у IBM Lotus Domino 7

https://www..jsp?series_title_by=Практичне+використання+web-сервісів+в+ibm+lotus+domino+7

Слідкуйте за виходом нових статей цієї серії.

Можливо, ви зустрічалися зі згадками про Web-сервіси в технічних статтях, описах програмних продуктівабо навіть у діалогах із товаришами по службі. Видно, комусь Web-сервіси потрібні і важливі, проте, зустрівшись з визначеннями на кшталт "Граматика XML для визначення наборів кінцевих точок для обміну повідомленнями", ви вирішили, що такі складні речі і чіпати не варто.

На щастя, Web-сервіси можна пояснити і так, щоб зрозуміли все, при цьому не вникаючи в подробиці того, як це все працює. Вам варто спробувати розібратися, що таке Web-сервіси, оскільки область їх (а також сервіс-орієнтованої архітектури, що має до них відношення, SOA) застосування у світі IT постійно розширюється.

Web-сервіси можна сприймати як автомобіль: вам не треба знати технічному рівніЯк працюють поршні, розподільники та паливні інжектори - ви і без цього можете купити автомобіль, керувати ним і розмовляти про машини з друзями (якщо вони, звичайно, не механіки). Те саме і з Web-сервісами, вам як спеціалісту IT досить просто розібратися, що це таке і як вони працюють, щоб зрозуміти, навіщо вони вам потрібні.

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

Ця серія статей допоможе розробникам Domino зрозуміти та використовувати Web-сервіси в IBM Lotus Domino V7.0. Ця вступна стаття містить досить корисну інформацію, і стане в нагоді будь-кому бажаючому зрозуміти, що ж таке Web-сервіси. Технології Lotus Domino V7.0 дозволяють розробникам легко створювати та використовувати Web-сервіси, і пізніше ми детально торкнемося цього.

Спочатку розберемося, що таке Web-сервіс.

Що таке веб-сервіс?

Просто кажучи, Web-сервіс дозволяє комп'ютерним програмамстандартизовано спілкуватися між собою.

Зв'язок між трьома та більше машинами

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

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

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

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

У структуру комунікацій з використанням Web-сервісів включено багато елементів, яких ми торкнемося у цій статті. Однак ідея залишається тією ж, що і у звичайного діалогу - програми спілкуються, використовуючи знайому їм мову, іноді через мережу. Програми можуть як знаходитися на одному комп'ютері, так і розміщуватись на різних машинаху різних точках земної кулі, з'єднані через інтернет маршрутизаторами та серверами. Добре те, що програмам та комп'ютерам не обов'язково бути однаковими. Завдяки Web-сервісам переговорюватися можуть як дві програми Microsoft.NET на одному ноутбуку, так і програма Java на канадському сервері iSeries із програмою C++ на комп'ютері з ОС Linux із Китаю.

У комунікаціях за допомогою Web-сервісів використовуються такі стандартні технології:

• XML.Мова (формат даних), використовуваний компонентами Web-сервісів.
• Протокол SOAP.Повідомлення XML, якими обмінюються програми
• Бібліотека описів веб-сервісів (WSDL).Файл XML, в якому визначено формат повідомлень SOAP і те, як їх надсилати

Для здійснення зв'язку між Web-сервісами також може використовуватися стандартна технологія, відома як Universal Description, Discovery та Integration (UDDI). Ми розглянемо це далі у статті, проте оскільки використання UDDI не обов'язково, багато Web-сервісів її не використовують.

Трохи термінології: публікація та використання Web-сервісів

Перш ніж зайнятися роз'ясненням наших термінів, розглянемо частину пов'язаної з Web-сервісами термінології.

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

Говорячи про використання Web-сервісу, ми маємо на увазі програму, яка надсилає виклик до Web-сервісу на іншій машині. Користувачі Web-сервісів називаються клієнтами.

XML: рідна мова

Мова XML використовується для спілкування між компонентами веб-сервісів. Повідомлення, що пересилаються між програмами, так само як визначальні Web-сервіс файли, мають формат XML. На малюнку 1 показано структуру простого файлу XML.

Рисунок 1. Базова структура XML

Як бачите, деяка інформація у файлі (така як ім'я, прізвище) оточена тегами, укладеними у трикутні дужки. Ім'я John показано як Джон. Ще є елементи, в які вкладені інші елементи, наприклад елемент Вкладені елементи , і .

Написання Web-сервісів мовою XML дає неабиякі переваги, включаючи:

• Структура і граматика XML аналогічна структурі інших мов програмування, тому програмам, що взаємодіють з Web-сервісами, немає потреби проводити структурний аналіз файлів XML безпосередньо.
• Файли XML текстові, і їх може прочитати людина (іншими словами, знаючи мову XML, ви можете відкрити файл XML у текстовому редакторіта зрозуміти його вміст). Це може допомогти при налагодженні.
• XML дозволяє використовувати в повідомленнях будь-яке стандартне кодування, тому повідомлення можна писати як англійською, так і російською або японською мовами.
• XML дозволяє вам користуватися так званим простором імен, в якому ви можете визначити бажану структуру файлового елемента з певним ім'ям. Наприклад, ви можете визначити елемент Price, який завжди повинен бути числом з плаваючою точкою, або PersonName, що включає два рядкових поделемента FirstName і LastName.

  Крім того, при необхідності простору імен дозволяють кільком елементам з однаковими іменамимати різні визначення. Наприклад, елемент StockPrice в одному просторі імен може включати тикерний символ і ціну, а в іншому просторі імен може складатися з тикерного символу, ціни, денних мінімуму і максимуму і 12-місячного максимуму.

Єдиними недоліками XML, якщо це дійсно недоліки, є:

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

Але ці проблеми не мають значення, порівняно з перевагами формату XML.

SOAP: повідомлення, що надсилаються

Ви знаєте, що спілкування Web-сервісів ведеться у форматі XML, але це вирішує лише половину проблеми. Програми можуть розібрати повідомлення, проте звідки їм знати, що робити з результатом, отриманим після аналізу?

Інструкція, яка описує правила форматування повідомлень XML для Web-сервісів, відома як SOAP. У ній визначено структуру повідомлень, завдяки чому програми знають, як надсилати та інтерпретувати дані. Базова структура повідомлення SOAP показана малюнку 2.

Рисунок 2. Базова структура повідомлення SOAP

На мові XML це виглядатиме приблизно так:

У базовому випадку у вас є пакет SOAP, що включає в себе тіло SOAP і тіло, в якому знаходяться дані, що передаються. Іноді є ще необов'язковий заголовок SOAP (всередині пакета перед тілом), що містить додаткову інформацію.

Інструкції SOAP

Хоча формат SOAP стандартний і має однакові інструкції, необхідно пам'ятати, що різні виробники можуть трохи по-різному втілювати ці інструкції. Наприклад, структура іменних просторів і XML у повідомленні SOAP, згенерованому Apache Axis, може сильно відрізнятися від структури, згенерованої Microsoft .NET. Однак, правильно написаний клієнт або сервер може обробити будь-яке правильно написане відповідно до інструкцій SOAP повідомлення.

Крім того, в інструкціях WSDL 1.1 та WSDL 2.0 є деякі важливі відмінності. Хоча інструкція 2.0 на момент написання статті ще тільки на етапі завершення, незабаром почне займати місце версії 1.1.

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

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

Протоколи: як надсилаються повідомлення

Ми ще не торкалися питання, як передаються всі ці повідомлення по SOAP?

А передаються вони зазвичай через мережу (і/або інтернет) за протоколом HTTP, майже як і сторінки передаються з сервера на ваш браузер. HTTP використовується не завжди (його головний конкурент – SMTP, проте він далеко позаду). Протокол, який використовується Web-сервісом, визначений у файлі WSDL.

Зазвичай у файлі WSDL протокол, який використовується передачі SOAP, визначений як HTTP. Клієнт SOAP надсилає повідомлення відповідно до зазначеного протоколу.

Інші терміни в галузі Web-сервісів, з якими ви можете зіткнутися

Ми вже розібралися з основними термінами, однак у розмові про Web-сервіси ви можете почути деякі.

Слабкі зв'язки

Які використовують Web-сервіси програми зазвичай мають слабкі зв'язки з сервісами, тобто необхідні для роботи програми сервіси не прив'язані до неї безпосередньо, так само як і програма не прив'язана до сервісів. Програма може запросто використовувати будь-які необхідні їй сервіси, а вони чекають на виклик від програми - від будь-якої програми, якій потрібна їхня відповідь.

Життєвий приклад слабких зв'язків – це обід із друзями. Декілька друзів якось домовляються між собою (особисто, по телефону, через електронну поштуі т.д.). Кожен самостійно добирається до ресторану і після обіду кожен сам оплачує свою їжу. Незалежно від того, як пройшов обід, кінцевий результат незмінний - це був дружній обід.

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

UDDI

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

Хоча UDDI і досить важливий стандарт визначення Web-сервісів, його значущість сильно зменшена рахунок того, що він є необов'язковим елементом Web-сервісів, а коли є вибір, використовувати чи ні, багато хто вирішує не використовувати.

Більшість організованих корпоративних середовищ із великою кількістю внутрішніх Web-сервісів мають реєстри UDDI. Чудово, коли є корпоративний сайт UDDI, що містить інформацію про доступні у вашій компанії Web-сервіси. Збираючи разом усі сервіси, UDDI дозволяє без проблем та непомітно змінювати їх постачальників. Якщо клієнти шукають сервіси через UDDI, виклики SOAP автоматично надсилаються до нового постачальника.

Однак цей компонент не є обов'язковим в архітектурі Web-сервісів.

Безпека Web-сервісів

Читаючи про SOAP і WSDL, ви можете помітити, що тема безпеки не розкрита. Як проводиться автентифікація під час викликів сервісів, якщо постачальник працює із закритою інформацією? Адже зрозуміло, що не всі Web-сервіси доступні широкому загалу, чи не так?

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

• Чи можуть повідомлення SOAP надходити у вигляді тексту або вони повинні бути зашифровані?
• Чи достатньо вам простої автентифікації за логіном і паролем чи вона повинна бути стійкою та маркерною?
• Якщо використовуються маркери, чи потрібні на них підписи, і як правильно їх включити у повідомлення SOAP?
• А якщо клієнт надсилає повідомлення SOAP не безпосередньо, а через якусь проміжну структуру, таку як черга повідомлень або через ще якийсь Web-сервіс?

Крім того, при обміні повідомленнями не завжди може використовуватися HTTP, тому у вас не вийде просто використовувати системи безпеки Web-сервісів на додаток до існуючим системамбезпеки HTTP.

Є кілька інструкцій, які охоплюють ці та інші аспекти безпеки Web-сервісів: WS-Security, WS-Policy, WS-Trust та WS-Privacy. Деякі виробники ПЗ та комітети працюють над цими питаннями вже кілька років. Хоча не всі варіанти реалізації Web-сервісів підтримують усі інструкції безпеки, проте в стандартах безпеки зазвичай реалізовано хоча б кілька основних шляхів забезпечення безпеки.

Проміжне ПЗ та Enterprise Service Bus

Є ще один великий набір стандартів для Web-сервісів, зібраних разом в одну досить велику грудку, які зазвичай називаються інструкціями WS-*. Разом вони зачіпають багато проектувальних моментів, що виникають, коли ви збираєте багато Web-сервісів в одне середовище. Стандарти WS-* стосуються таких питань, як:

• Безпека
• Надійність
• Обмін повідомленнями
• Транзакції
• Якість обслуговування

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

Для великих виробників програмного забезпечення робота з цими стандартами надає як складності, так і можливості. Деякі виробники представляють на ринку цілі пакети проміжного ПЗ для роботи з Web-сервісами, які часто називають Enterprise Service Bus, або ESB, які дозволяють розібратися відразу з усіма або принаймні деякими з вищезазначених завдань. Ці ESB цінні ще й тому, що можуть зв'язати разом кілька Web-сервісів в рамках однієї організації та забезпечити їхню функціональність, запис їхніх дій та зберігання повідомлень у чергах.

Сервіс-орієнтована архітектура

І нарешті сервіс-орієнтована архітектура. У більшості випадків це просто комбінація всього вищеописаного: слабко пов'язані Web-сервіси від різних постачальників, що взаємодіють відповідно до прийнятих стандартів (можливо і за участю ESB) і зібрані разом різними програмами, що беруть у сервісів дані і їх використовують по-різному.

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

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

Чому це важливо?

Тепер ви вже щось знаєте про те, як працюють Web-сервіси - клієнт читає файл WSDL постачальника, відповідно до нього форматує та відправляє повідомлення SOAP та отримує інше повідомлення SOAP у відповідь. То чому це так важливо? В чому справа?

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

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

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

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

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

Інструментальна панель перетворюється з великої програми на простий інтерфейс. Бажаючи додати нові компоненти, ми просто звертаємось до додаткових сервісів. Якщо нам потрібен інший графік, ми звертаємося до іншого сервісу, що будує графіки. Якщо нам потрібна більш інтерактивна інструментальна панель, з можливістю навчання або сортування, то панель може надсилати повідомлення від користувача відповідним сервісом. Ми можемо навіть повністю поміняти сервіси, що викликаються так, що користувачі цього і не помітять (поки не буде змінюватися файл WSDL), і панель залишиться колишньою.

Будучи професіоналом у сфері IT ви можете займатися як розробкою інтерфейсу, так і сервісів або тим і іншим. Розуміння того, як все це працює разом (або хоча б знання, що це таке) є важливим для роботи в подібному проекті.

Також добре, що є багато інструментів, котлори допоможуть вам постачати та використовувати Web-сервіси і можуть зробити за вас багато важкої роботи. У наступних частинах статті ми розберемося як з використанням IBM Lotus Domino V7.0 ви зможете легко постачати Web-сервіси клієнтам або системам.

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

Вступ

1. SOAP. Перш ніж викликати віддалену процедуру, потрібно описати цей виклик у XML файлі формату SOAP. SOAP – це просто одна з численних розміток XML, яка використовується у веб-сервісах. Все, що ми хочемо кудись відправити через HTTP, спочатку перетворюється на XML опис SOAP, потім засовується в HTTP пакет і посилається на інший комп'ютер у мережі TCP/IP.
2. WSDL. Існує веб-сервіс, тобто. програма, методи якої можна віддалено викликати. Але стандарт вимагає, щоб до цієї програми додався опис, в якому сказано, що «так, ви не помилилися – це дійсно веб-сервіс і можна у нього викликати такі-то методи». Такий опис є ще одним файлом XML, який має інший формат, а саме WSDL. Тобто. WSDL це просто XML файл опису веб-сервісу і більше нічого.

Загальний підхід

1. Описати інтерфейс нашого веб-сервісу
2. Реалізувати цей інтерфейс
3. Запустити наш веб-сервіс
4. Написати клієнта та віддалено викликати потрібний метод веб-сервісу

Сервер

Клієнт

Висновок