Що таке Web-сервіси та чому вони важливі? Що таке "веб-сервіс" простою англійською мовою

Олександр Качанов

Ідея веб-сервісів була розроблена такими гігантами комп'ютерної індустрії як 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 та шукаю, чи немає там веб-сервісу, який міг би зробити цю роботу за мене . Прийшовши на сайт http://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-сервісів для платформи. Опис та виявлення web-сервісу

Що таке XML Web Service?

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

Застосування сервісно-орієнтованих підходів дозволяє говорити про повторне використання (reuse) на макрорівні (рівні сервісів), на відміну від мікрорівня (рівня об'єктів). Сервісно-орієнтований підхід передбачає використання простих і загальноприйнятих стандартів, що дозволяє різним додаткам використовувати функціональність один одного. Сервіси можуть бути написані з використанням різних мов програмування, на різних платформах. Крім того, сервіси можуть бути розгорнуті окремо або в рамках програмного комплексу в будь-якій точці земної кулі і таким чином надаватиме доступ до своєї функціональності по мережі.

Назвемо сервісом (service)ресурс , що реалізує бізнес-функцію і має такі властивості:

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

Окремим випадком сервісу є XML web-сервіс.

XML Web-сервіс- це особливий тип web-додатку, який:

розгортається на web-сервері;
публікує web-методи, які можуть бути спричинені зовнішніми клієнтами;
очікує надходження HTTP-запитів, які є командами дзвінків web-методів;
виконує web-методи та повертає результати.

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

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

Web-сервіси – не власність конкретної компанії. Це промисловий стандарт на основі відкритих протоколів (SOAP, HTTP тощо). Web-сервіси розгортаються на різних платформах (у тому числі на серверах під керуванням Windows або UNIX). Web-сервіси можна розробляти із застосуванням багатьох засобів розробки (від текстового редактора до сімейства Microsoft Visual Studio).

Методи більшості web-сервісів викликаються HTTP-запитами, що містять повідомлення SOAP SOAP - це XML-мова (XML vocabulary) для виклику віддалених процедур за HTTP та іншими протоколами (повний опис SOAP http://www.w3.org/TR/SOAP) .

Місце web-сервісів серед інших технологій віддаленого виклику

Існує чимало протоколів і технологій віддаленого виклику: Microsoft Distributed Component Object Model ( DCOM ), Object Management Group "Common Object Request Broker Architecture ( CORBA ), Sun "s Remote Method Invocation ( RMI ), . NET Remoting, XML Web Services.

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

На відміну від даних технологій, XML Web Services та. NET Remoting повною мірою реалізують об'єктно-орієнтований підхіддля web-програмування.

XML Web Service- Компонент, що надає Internet-клієнтам набір функцій API або web-методів. XML входить у назву, оскільки web-сервіси та його клієнти використовують його обмінюватись даними. В основі web-сервісів лежать відкриті стандарти, такі як HTTP, XML (Extensible Markup Language), SOAP (Simple Object Access Protocol) - стандарт Intenet, що описує, як програми можуть взаємодіяти, тобто викликати методи один одного, за допомогою HTTP та інших протоколів ). Основне завдання web-сервісів – забезпечення міжпрограмної взаємодії. Багато хто працює на UNIX-серверах, при цьому до них звертаються Windows-клієнти. Дані, що передаються web-сервісам, серіалізуються в XML і передаються в пакеті SOAP. Метадані про вміст таких повідомлень зберігаються у WSDL-контракті web-сервісу та схемах XSD. Головна перевага такого підходу – читабельність метаданих. Розробник може легко переглянути весь опис web-сервісу і навіть створити власний модуль, який розбирає SOAP-пакети.

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

Розробка web-сервісів на платформі.

Є багато способів написання web-сервісів. Їх можна розробляти вручну або за допомогою SOAP-інструментів, що надаються Microsoft, IBM та ін. Написання web-сервісів за допомогою Microsoft. NET має дві переваги:

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

створення

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

Web-сервіси реалізуються як ASMX-файли. ASMX – це особливе розширення імені файлу, зареєстроване за ASP .NET (точніше, за HTTP-обробником ASP.NET) у головному файлі конфігурації ASP .NET Machine.config.
ASMX-файли починаються директивою @WebService. Ця директива повинна містити хоча б атрибут Class, що задає клас, з якого складається веб-сервіс.
Класи web-сервісів можуть мати необов'язкові атрибути WebService. У даному прикладітакий атрибут призначає ім'я web-сервісу та опис, який відображається на сторінці HTML, коли користувач викликає в браузері AdditionService.asmx .
Web-методи оголошуються шляхом призначення відкритим методам класу Web-сервісу атрибута WebMethod. Для допоміжних методів, які застосовуються всередині нього, але недоступні зовнішнім клієнтам, цей атрибут просто не вказується.
HTTP, XML та SOAP "невидимі". Роботу з XML-даними та повідомленнями SOAP виконує .NET Framework.

AdditionService.asmx<%@ WebService language="C#" Class="AddService" %>using System using System.Web.Services class AddService ( public int Add (int a, int b) ( return a + b ) )

Незважаючи на малі розміри, AdditionService.asmx – повноцінний web-сервіс, якщо його встановити на web-сервер з ASP.NET. Його методи викликаються за допомогою SOAP, HTTP GET та HTTP POST, і він може повертати результати як SOAP-відгуки або як прості XML-оболонки.

Використовуючи код фону, класи web-сервісу можна винести з asmx-файлів в окремі файли.

Web-сервіси підтримують використання складних типів данихяк вхідні або вихідні параметри. Складні типи даних підтримуються, тому що XML дозволяє легко серіалізувати більшість типів даних. Однак при автоматичному тестуванні web-сервісу ASP .NET не генерує тестових сторінок для методів, що приймають складні типиданих. Це тому, що не можна передати складні типи даних web-методу за допомогою HTTP GET і POST.

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

Web-сервіси можна створювати за допомогою інструментальних засобів, наприклад, Microsoft Visual Studio 2005. Для створення web-сервісів там передбачено окремий типпроект ASP .NET Web Service. Visual Studio генерує asmx-файл, файл із фоновим кодом для опису класів web-сервісу, файл конфігурації web-сервісу і т. д. При запуску проекту на виконання відбувається компіляція класів сервісу та відкриття asmx-файлу у вікні браузера.

Опис web-сервісів за допомогою контрактів

Для того, щоб інші розробники могли використовувати AdditionService, їм потрібно знати, які методи він надає, які протоколи підтримує, сигнатури методів та адресу веб-сервісу (URL). Вся ця та інша інформація може бути описана мовою Web Service Description language (WSDL).

Виявлення web-сервісів

Як інші розробники дізнаються про існування AdditionService?

По-перше, за допомогою DISCO (скорочення від слова discovery) – файлового механізму пошуку локальних web-сервісів, тобто механізму отримання списку доступних web-сервісів із DISCO-файлів, розміщених на web-серверах. Крім того, DISCO-файли містять записи про розташування WSDL-контрактів сервісів. DISCO-файл є XML-файлом із записами.

Також можливо використовувати VSDISCO-файли, які аналогічні DISCO-файлам, але їх вміст є результатом динамічного пошуку web-сервісів у зазначених каталогах і всіх вкладених підкаталогах. ASP .NET відображає розширення імені файлу. З міркувань безпеки динамічний пошук у ряді версій.NET Framework вимкнено, але його можна увімкнути, змінивши записи файлу Machine.config.

А як здійснюється пошук web-сервісів у глобальній мережі? Для пошуку web-сервісів у глобальній мережі Microsoft, IBM і Ariba спільно розробили UDDI (Universal Description Discovery and Integration) - специфікацію побудови розподілених баз даних, що дозволяє шукати web-сервіси. UDDI підтримується сотнями компаній. UDDI-сайти є веб-сервісами. Кожен може опублікувати свій реєстр на основі UDDI. Більшість розробників ніколи не використовують UDDI API безпосередньо. Натомість до реєстрів UDDI звертаються інструментальні засоби розробки. Вони також генерують класи-оболонки виявлених та вибраних web-сервісів.

Підсумки

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

Ми роздивились загальні поняттявикористання механізму « Web-Сервісів».Освіжимо деякі знання.

Web-сервіси застосовуються для обміну даними між сервером та клієнтом; формат XML використовується для «упаковування» даних для взаєморозуміння між обома учасниками спілкування.

РОЗДІЛI

ПРИКЛАД РЕАЛІЗАЦІЇWEB-СЕРВІСУ В СИСТЕМІ «1С:ПІДПРИЄМСТВО»

ЗАВДАННЯ:Необхідно створити web-сервіс, звертаючись до якого клієнти можуть визначити всю необхідну інформацію за своїми заявками.

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

РІШЕННЯ:

Крок 1.Створимо нову інформаційну базу без конфігурації розробки нової конфігурації.

Крок 2Додамо до конфігурації кілька нових об'єктів

Довідник "Клієнти";

Документ "Заявка";

Перелік «СтатусиЗаявок».

Крок 3Створимо новий XDTO пакет.

Чому і навіщо ми створюємо XDTO-пакет? Докладніше про використання механізму XDTO можна прочитати в розділі 16. Посібник розробника та .

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

У нашому випадку пакет XDTO створюється для опису значення web-сервісу, що повертається.

Розкриємо гілку "Загальні" → "XDTO-пакети" → Додати…

Вкажемо ім'я XDTO-пакету « DocumentsData» та його простір імен http://localhost/request або http://192.168.1.76/request (для полегшення розуміння та процесу навчання, ми вказуємо локальну IP-адресу комп'ютера, де встановлено web-сервер (підтримувані web-сервера: IIS або Apache)). Кожен Web-сервіс може бути однозначно ідентифікований за своїм ім'ям та URI простором імен, якому він належить.

Наш пакет містить два типи об'єктів XDTO:

1) Сустомер- для передачі даних елемента довідника "Клієнти".

- Name ;

2) Document- для передачі даних документа "Заявки"

Цей тип об'єкта XDTO міститиме такі властивості:

- Сустомер- Тип Суstomer з простору імен http://192.168.1.76/request; є посилання на об'єкт XDTO, який ми визначили вище;

- Status- Тип string з простору імен http://www.w3.org/2001/XMLSchema;

- Numder- Тип string з простору імен http://www.w3.org/2001/XMLSchema.

Крок 4.Додамо до конфігурації новий Web-сервіс

Розкриємо гілку "Загальні" → "Web-сервіси" → Додати…

Для Web-сервісу вкажемо наступні значення властивостей:

Ім'я DocumentsData

URI Простір імен - http://192.168.1.76/request

Пакети XDTO - DocumentsDataабоhttp://192.168.1.76/request

Ім'я файлу публікації - request.1cws

Крок 5.У створеного Web-сервісу визначимо операцію « GetData»

Значення властивостей операції:

Тип значення, що повертається - Document (http://192.168.1.76/request)

Можливе порожнє значення - Істина

Ім'я процедури - GetData.

Крок 6У операції GetDataвизначимо параметр Суstomer зі наступними значеннямивластивостей:

Тип значення – тип stringіз простору імен http://www.w3.org/2001/XMLSchema;

Напрямок передачі - вхідний.

Крок 7.Відкриємо модуль створеного Web-сервісу та помістіть у нього функцію Отримати(), яка буде виконуватися під час виклику даного Web-сервісу.

Функція GetData (Сustomer) // Отримати типи об'єктів XDTO КлієнтТип = Фабрика XDTO. Тип ("http://192.168.1.76/request", "Сustomer"); Заявка Тип = Фабрика XDTO. Тип ("http://192.168.1.76/request", "Document"); // Отримуємо клієнта КлієнтПосилання = Довідники.Клієнти.ЗнайтиПо Найменуванню(Сustomer); Якщо Не ЗначенняЗаповнено(КлієнтПосилання) Тоді Повернення Невизначено; КінецьЯкщо; Запит = Новий Запит; Запит.Текст = "ВИБРАТИ ПЕРШІ 1 | Заявка.Посилання, | ПРЕДСТАВЛЕННЯ(Заявка.Статус) ЯК Статус, | Заявка.Номер |З | Документ.Заявка ЯК Заявка |ДЕ | Заявка.Клієнт = &Клієнт"; Запит.ВстановитиПараметр("Клієнт", КлієнтПосилання); РезультатЗапиту = Запит.Виконати(); Якщо РезультатЗапроса.Пустой() Тоді Повернення Невизначено; КінецьЯкщо; Вибірка = Результат Запиту. Вибрати (); Вибірка.Наступний(); Документ = Вибірка.Посилання.ОтриматиОб'єкт(); // Створити об'єкт XDTO заявки Заявка = Фабрика XDTO. Створити (Заявка Тип); Заявка.Numder = Вибірка.Номер; Клієнт = Фабрика XDTO. Створити (Клієнт Тип); Клієнт.Name = КлієнтПосилання.Найменування; Заявка. Сустомер = Клієнт; Заявка. Status = Вибірка. Статус; // Повернути заявку Повернення Заявка; КінецьФункції

Крок 8Опублікуємо створений Web-сервіс на веб-сервері.

Пункт меню Конфігуратор: "Адміністрування" → "Публікація на Web-сервері".

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

РОЗДІЛII

ПРИКЛАД ЗВЕРНЕННЯ ДОWEB-СЕРВІСУ СИСТЕМИ «1С:ПІДПРИЄМСТВО» З СТОРІННОГО ДОДАТКУ

Основне призначення механізму Web-сервісів у системі «1С:Підприємство» - це передача необхідних даних стороннім програмам.

Розглянемо приклад розробки програми на Delphi звернення до нашого web-сервісу з першого розділу цієї статті.

Крок 1.Створимо новий проекті на формі розмістимо кілька елементів керування

Текстове поле – використовується для виведення отриманої від web-сервісу інформації;

Дві кнопки - очищення текстового поля та звернення до web-сервісу;

Поле введення - параметр, що передається в web-сервіс.

Крок 2Виконуємо імпорт WSDL-файлу

В результаті ми отримуємо новий модуль request(Таке найменування ми визначили безпосередньо в 1С). В даному модулі є вся необхідна інформація по web-сервісу.

Крок 3Напишемо обробник виклику web-сервісу

Змінна DocumentDataPortType вже визначена у модулі request

Крок 4.Запустити програму та виконати перевірку.

РОЗДІЛIII

ПРИКЛАД ЗВЕРНЕННЯ ДОWEB-СЕРВІСУ В СИСТЕМІ «1С:ПІДПРИЄМСТВО»

Крок 1.Створимо нову зовнішню обробку з ім'ям WEB_Service

Крок 2Для обробки визначимо нову форму

Крок 3У форми вкажемо кілька реквізитів

Клієнт - тип «Рядок»

КлієнтПовернення - тип «Рядок»

НомерПовернення - тип «Рядок»

СтатусПовернення - тип «Рядок».

Виведемо реквізити на форму.

Крок 4.Додамо команду форми « ОтриматиДані»

Вкажемо обробник команди

&НаКлієнті Процедура ОтриматиДані(Команда) ОтриматиДаніНаСервері(Клієнт); КінецьПроцедури Процедура ОтриматиДаніНаСервері(Клієнт) // Створити WS-проксі на основі посилання та виконати операцію Отримати() Визначення = Новий WSВизначення("http://192.168.1.76/WEB_Service/ws/request.1cws;ws Проксі = Новий WSПроксі (Визначення, "http://192.168.1.76/request", "DocumentsData", "DocumentsDataSoap"); Дані Заявки = Проксі. GetData (Клієнт); Якщо Дані Заявки = Невизначено Тоді КлієнтПовернення = "Невизначено"; СтатусПовернення = "Невизначено"; Номер Повернення = "Невизначено"; Повернення; КінецьЯкщо; КлієнтПовернення = ДаніЗаявки.Сustomer.Name; СтатусПовернення = ДаніЗаявки.Status; НомерПовернення = ДаніЗаявки.Numder; КінецьПроцедури

Система «1С:Підприємство» може використовувати веб-сервіси, що надаються іншими постачальниками, двома способами:

За допомогою статичнихпосилань, створюваних у дереві конфігурації;

"плюс":велика швидкість роботи;

"мінус":повторний імпорт WSDL-опису засобами конфігуратора та збереження зміненої конфігурації.

За допомогою динамічнихпосилань, створюваних засобами вбудованої мови

(відповідно «мінуси» статичних для динамічних – «плюси»)

РОЗДІЛIV

НАЛАДКА WEB-СЕРВІСІВ У СИСТЕМІ «1С:ПІДПРИЄМСТВО»

Для локального web-сервісу необхідно:

Крок 1.Покласти на клієнт, де запускається система 1С файлик webservicecfg.xmlз наступним вмістом

Крок 2У файл default. vrdпублікації конфігурації додати рядок

Крок 3У конфігураторі виберіть пункт меню

«Налагодження» → «Підключення» → «Автоматичне підключення» → «Web-сервіси на сервері»

Крок 4.Натиснути кнопку «OK»

Для серверного варіанта ще треба сервер 1с запускати в режим налагодження з ключем /debug

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

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

Основи

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

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

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

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

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

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

Тепер про UDDI

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

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

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

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

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

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

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

Мінуси

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

Практичне використання 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 це виглядатиме приблизно так:

FOO

У базовому випадку у вас є пакет 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-сервіси клієнтам або системам.