Практичне використання Web-сервісів в IBM Lotus Domino 7: Що таке Web-сервіси і чому вони важливі?

1. Серія контенту:
2. Цей контент є частиною серії: Практичне використання Web-сервісів в IBM Lotus Domino 7
3. Що таке Web-сервіс?
4. Зв'язок між трьома і більше машинами
5. Трохи термінології: публікація і використання Web-сервісів
6. XML: рідна мова
7. Малюнок 1. Базова структура XML
8. SOAP: надіслані повідомлення
9. Малюнок 2. Базова структура повідомлення SOAP
10. інструкції SOAP
11. WSDL: визначення Web-сервісів
12. інструкції WSDL
13. Протоколи: як відправляються повідомлення
14. Інші терміни з області Web-сервісів, з якими ви можете зіткнутися
15. слабкі зв'язку
16. UDDI
17. Безпека Web-сервісів
18. Проміжне ПО і Enterprise Service Bus
19. Сервіс-орієнтована архітектура
20. Чому це важліво?
21. Ресурси для скачування

Наша взаимовыгодная связь https://banwar.org/

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

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

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

https://www.ibm.com/developerworks/ru/views/global/libraryview.jsp?series_title_by=Практическое+использование+web-сервисов+в+ibm+lotus+domino+7

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

Цей контент є частиною серії: Практичне використання 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-сервіси можуть використовуватися і для комунікацій між великою кількістю комп'ютерів. Наприклад, перенаправлення або зберігання транзакцій може здійснюватися проміжним пристроєм, або звернення до Web-сервісу на одному сервері може породжувати звернення до сервісу на іншому.

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

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

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

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

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

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

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

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

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

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

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

XML: рідна мова

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

Малюнок 1. Базова структура XML

Як бачите, деяка інформація у файлі (така як ім'я, прізвище) оточена тегами, ув'язненими в трикутні дужки. Ім'я John показано як <firstname> John </ firstname>. Ще є елементи, в які вкладені інші елементи, наприклад в елемент <person> вкладені елементи <firstname>, <lastname> і <birthday ».

Написання 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-ENV: Envelope xmlns: SOAP-ENV = "http://schemas.xmlsoap.org/soap/envelope/" SOAP-ENV: encodingStyle = "http://schemas.xmlsoap.org/soap/encoding/" > <SOAP-ENV: Body> <ns1: GetStockInfo xmlns: ns1 = "urn: thisNamespace"> <symbol> FOO </ symbol> </ ns1: GetStockInfo> </ SOAP-ENV: Body> </ SOAP-ENV: Envelope>

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

інструкції SOAP

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

На випадок проблем в тілі SOAP міститься інформація про помилку в формі SOAP Fault. Fault - це структура XML, що містить опис помилки, наприклад:

<SOAP-ENV: Fault> <faultcode> SOAP-ENV: Server </ faultcode> <faultstring> Server Error </ faultstring> <detail> Database not available </ detail> </ SOAP-ENV: Fault>

Хоча повідомлення SOAP і зберігається в текстовому вигляді в форматі XML, через специфічність визначень просторів імен і властивостей елементів його часом буває непросто зрозуміти або інтерпретувати вручну. На щастя, програм і бібліотек, здатних створити або інтерпретувати вам повідомлення SOAP, багато, і вони беруть на себе більшу частину складнощів. Інструменти можуть зробити за нас складну роботу.

WSDL: визначення Web-сервісів

Кожна програма, яка публікує Web-сервіси, в файлі WSDL описує доступні служби та правила їх виклику. Формат WSDL теж заснований на XML і має певну зрозумілу додатків структуру. WSDL часто вимовляється як "Whiz-dull."

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

• Ім'я, по якому звертаються до методу (в даному випадку - GetTemperature)
• Необхідні параметри в запиті, якщо такі є (визначаються імена і типи даних параметрів)
• Формат повертається або значень, на випадок успішної обробки запиту (знову-таки, імена і типи даних)
• Посилання URL і протокол, за якими слід викликати метод

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

інструкції WSDL

Як і в SOAP, в WSDL є стандартні вимоги, які можна втілити по-різному. Зокрема, є багато регулярно використовуваних стилів ( "styles") WSDL, таких як RPC / Encoded і Document / Literal. Чудовий ресурс, де описані відмінності між типами WSDL - стаття на developerWorks, " Який стиль WSDL мені використовувати? "
Крім того, в інструкціях 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-сервіси клієнтам або системам.

Ресурси для скачування

Схожі тими

Підпішіть мене на ПОВІДОМЛЕННЯ до коментарів