Поштові протоколи

💸 Как сделать бизнес проще, а карман толще?

Тот, кто работает в сфере услуг, знает — без ведения записи клиентов никуда. Мало того, что нужно видеть свое раписание, но и напоминать клиентам о визитах тоже. Проблема в том, что средняя цена по рынку за такой сервис — 800 руб/мес или почти 15 000 руб за год. И это минимальный функционал. Нашли самый бюджетный и оптимальный вариант: сервис VisitTime.
⚡️ Для новых пользователей первый месяц бесплатно. А далее 290 руб/мес, это в 3 раза дешевле аналогов. За эту цену доступен весь функционал: напоминание о визитах, чаевые, предоплаты, общение с клиентами, переносы записей и так далее.
✅ Уйма гибких настроек, которые помогут вам зарабатывать больше и забыть про чувство «что-то мне нужно было сделать».
Сомневаетесь? нажмите на текст, запустите чат-бота и убедитесь во всем сами!

Поштові протоколи

Хоча telnet і FTP були (і залишаються) корисними, першим додатком, який здійснив переворот у свідомості користувачів комп’ютерів мережі ARPANET, стала електронна пошта. До мережі ARPANET існували системи електронної пошти, але всі вони були однокомп’ютерними системами. В 1972 р. Рей Томлінсон (Ray Tomlinson) з компанії BBN написав перший пакет, який надає розподілені поштові послуги в комп’ютерній мережі з декількох комп’ютерів. Вже до 1973 р. дослідження управління ARPA показали, що 3/4 всього трафіку мережі ARPANET складала електрона пошта. Електронна пошта стала настільки популярною, що все більше користувачів прагнуло підключитися до мережі ARPANET, в результаті чого збільшувалася потреба додавати нові вузли і використовувати високошвидкісні лінії. Таким чином, появилася тенденція, яка зберігається і до сьогодні.

- POP3 (Post Office Protocol Version 3 – RFC 1939) — даний протокол поштовий клієнт використовує для отримання повідомлень електронної пошти з поштового сервера;

- IMAP (Internet Message Access Protocol – RFC 3501) — протокол доступу до електронної пошти. Аналогічний протоколу POP3, проте надає користувачу великі можливості роботи з поштовими скриньками, які розміщені на центральному сервері. Немає необхідності постійного пересилання з сервера і назад файлів з повним вмістом листів, оскільки електронними листами можна маніпулювати з комп’ютера користувача (клієнта).

- SMTP (Simple Mail Transfer Protocol — RFC 2821) — протокол передачі електронної пошти. Використовується для відправлення пошти між серверами для подальшого пересилання до отримувача та від користувачів до серверів. Для прийому пошти поштовий клієнт повинен використовувати протоколи POP3 або IMAP.

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

Протокол передачі гіпертексту HTTP (протокол передачі гіпертексту, RFC 1945, 2068) призначений для передачі гіпертекстових документів від сервера до клієнта. Протокол HTTP належить до протоколів прикладного рівня. На практиці в переважній більшості випадків транспортним протоколом для HTTP є протокол TCP, причому сервер HTTP (сервер Web) знаходиться в стані очікування з'єднання з боку клієнта стандартно по порту 80 TCP, а клієнт HTTP (браузер веб) є ініціатором з'єднання.

У термінах Web все, до чого може отримати доступ користувач, - документи, зображення, програми, - називається ресурсами. Кожен ресурс має унікальний для Web адреса, званий універсальним ідентифікатором ресурсу (URI - Universal Resource Identifier). У найзагальнішому випадку URI виглядає наступним чином:

Протокол: // користувач: пароль @ хост:? порт / шлях / файл параметрів # фрагмент

- Протокол - прикладної протокол, за допомогою якого отримують доступ до ресурсу;

- Користувач - користувач, від імені якого отримують доступ до ресурсу або сам користувач в якості ресурсу;

- пароль - пароль користувача для аутентифікації при доступі до ресурсу;

- хост - IP-адреса або ім'я сервера, на якому розташований ресурс;

- Порт - номер порта, на якому працює сервер, що надає доступ до ресурсу;

- параметри - параметри для обробки ресурсом-програмою;

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

Взаємодія між клієнтом і сервером Web здійснюється шляхом обміну повідомленнями. Повідомлення HTTP діляться на запити клієнта серверу та відповіді сервера клієнту.

Повідомлення запиту і відповіді мають загальний формат. Обидва типи повідомлень виглядають наступним чином: спочатку йде початкова рядок (початок рядка), потім, можливо, одне або кілька полів заголовка, званих, також, просто заголовками, потім порожній рядок (то є рядок, що складається з символів CR і LF), яка вказує кінець полів заголовка, а потім, можливо, тіло повідомлення:

Формат початкового рядка клієнта і сервера розрізняються і будуть розглянуті далі. Заголовки бувають чотирьох видів:

- загальні заголовки (генерал-заголовки), можуть бути присутніми як в запиті, так і у відповіді;

- заголовки запитів (запит-заголовки), можуть бути присутніми тільки в запиті;

- заголовки відповідей (відповідь-заголовки), можуть бути присутніми тільки у відповіді;

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

Кожен заголовок складається з назви, символу двокрапки ": " і значення. деякі важливі заголовки наведені в табл. 2.4.

Таблиця 2.4 - Приклади заголовків протоколу HTTP

Детальний опис заголовків HTTP / 1.0 можна знайти в RFC 2068.

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

Повідомлення запиту від клієнта до сервера складається з рядка запиту (запит-лінія), заголовків (загальних, запитів, об'єкта) і, можливо, тіла повідомлення.

Рядок запиту починається з методу, потім йде ідентифікатор запитуваного ресурсу, версія протоколу і завершальні символи кінця рядка:

Метод вказує команду протоколу HTTP, яку потрібно застосувати до запитуваного ресурсу. Ідентифікатор визначає запитуваний ресурс. версія HTTP позначається рядком такого вигляду:

HTTP / < версія>. < Підверсій> (В RFC 2068 представлений протокол HTTP / 1.1.)

Метод OPTIONS виконує запит інформації про опції з'єднання (наприклад, методах, типах документів, кодуваннях), які підтримує сервер для запитуваної ресурсу. Цей метод дозволяє клієнту визначати опції і / або вимоги, пов'язані з ресурсом, або можливості сервера, не проводячи ніяких дій над ресурсом і не ініціюючи його завантаження

Метод GET дозволяє отримувати будь-яку інформацію, пов'язану із запитуваною ресурсом. У більшості випадків, якщо ідентифікатор запитуваного ресурсу вказує на документ (наприклад, документ HTML, текстовий документ, графічне зображення, відеоролик), то сервер повертає вміст цього документа. якщо запитуваний ресурс є додатком, що формує в процесі своєї роботи деякі дані, то в тілі повідомлення відповіді повертаються ці дані. Це використовується, наприклад, пристворенні додатків CGI. Якщо ідентифікатор запитуваного ресурсу вказує на директорію (каталог, папку), то, в залежності від налаштувань сервера, може бути повернуто або вміст директорії (список файлів), або вміст одного з файлів, знаходиться в цій директорії (як правило, index.html або Default.htm).

Різновидами методу GET є " умовний GET" (" conditional GET"), при якому повідомлення запиту містить заголовки запиту If-Modified-Since, If-UnmodifiedSince, Якщо-Match, If-None-Match, або If-Range. Умовний метод GET запрошувати передачу об'єкта, тільки якщо він задовольняє умовам, описаним в наведених заголовках.

Розрізняють також " частковий GET" (" partial GET"), який запитує передачу тільки частини об'єкта за допомогою заголовка Range. Повідомлення відповіді у разі запиту з частковим методом GET повинно містити заголовок Content-Range, в якому вказується передаваний діапазон.

Метод HEAD ідентичний GET, за винятком того, що сервер не повертає у відповіді тіло повідомлення. Цей метод може використовуватися для отримання інформації про об'єкт запиту без безпосередньої пересилки тіла об'єкта, наприклад з метою тестування зв'язків і ін.

Метод POST використовується для запиту, при якому адресується сервер приймає дані, включені в тіло повідомлення запиту, і відправляє їх на обробку додатком, вказаному як запитуваний ресурс. Поряд з методом GET метод POST використовується при створенні серверних додатків. Відмінність від GET полягає в способі передачі даних запиту (в GET параметри передаються в ідентифікаторі запитуваного ресурсу, а в POST - В тілі повідомлення запиту), а також у тому, що GET може повернути вміст ресурсу, а POST завжди запускає додаток.

Тіло повідомлення, яке передається в запиті з методом PUT, зберігається на сервері причому ідентифікатор запитуваного ресурсу буде ідентифікатором збереженого документа. Якщо ідентифікатор запитуваного ресурсу вказує на вже існуючий ресурс, то включений в тіло повідомлення об'єкт замінює існуючий. Різниця між методами POST і PUT полягає в різному призначенні ідентифікатора ресурсу. URI в запиті POST ідентифікує ресурс, який обробляє включений в тіло повідомлення об'єкт (додаток). Навпаки, URI в запиті PUT призначається для створюваного ресурсу (об'єкта, включеного в запит у вигляді тіла повідомлення).

Метод DELETE запитує сервер про видалення ресурсу, що має запитуваний ідентифікатор.

Метод TRACE використовується для повернення переданого запиту на рівні протоколу HTTP. Одержувач запиту (сервер Web) відправляє отримане повідомлення назад клієнтові як тіло повідомлення відповіді з кодом стану 200 (OK).

Детальну інформацію про методи протоколу HTTP / 1.1 можна знайти в RFC 2068. Після отримання та інтерпретації повідомлення запиту сервер відповідає повідомленням

Перший рядок відповіді - це рядок стану (Status-Line). Вона складається з версії протоколу, числового коду стану, яка б пояснила фрази, розділених пробілами і завершальних символів кінця рядка:

< Версія HTTP> < Код стану> < Пояснююча фраза> < CR> < LF>

Версія протоколу має той же зміст, що й у запиті.

Елемент код стану (Status-Code) - це цілочисельний трьохрозрядний

(Тризначний) код результату розуміння і задоволення запиту. яка пояснює фраза

(Пояснююча фраза) являє собою короткий текстовий опис коду стану. Код стану призначений для обробки програмним забезпеченням, а яка пояснює фраза призначена для користувачів.

Перша цифра коду стану визначає клас відповіді. Останні дві цифри не мають певної ролі в класифікації. Мається 5 значень першої цифри:

1xx: Інформаційні коди - запит отримано, триває обробка.

2xx: Успішні коди - дія була успішно отримано, зрозуміле і оброблено.

3xx: Коди перенаправлення - для виконання запиту повинні бути зроблені

4xx: Коди помилок клієнта - запит має помилку синтаксису або не може бути

5xx: Коди помилок сервера - сервер не в змозі виконати допустимий запит.

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

Детальну інформацію про коди відповіді і заголовках, супроводжуючих дані відповіді, можна отримати в RFC 2068.

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

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

Концепція Web-сервісів виникла наприкінці 90-х років XX ст. і стала галузевим стандартом у сфері ІКТ. Стандарти Web-сервісів розроблені такими компаніями, як IBM, Microsoft, Ariba, Sun Microsystems, SAP за підтримки Консорціуму W3C. У межах W3C було створено робочу групу Web Services Architecture Working Group, яка опублікувала глосарій термінів у сфері Web-сервісів.

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

Web-сервіси - це реалізована програмними засобами система для підтримки міжкомп'ютерної взаємодії телекомунікаційних мереж, що підтримується такими стандартами: SOAP (Simple Object Access Protocol) - протокол обміну повідомленнями; WSDL - мова опису програмних інтерфейсів Web-сервісів; UDDI (Universal Description, Discovery and Integration) - класифікатор Web-сервісів.

ІКТ, що реалізують архітектуру Web-сервісів, подано на рис. 2.8.

Рисунок 2.8 - Технології реалізації Web-cepвiciв

Динамічні, гнучкі Web-сервіси спрощують бізнес-процеси підприємств і дають можливість швидко знайти бізнес-парт нерів. Концепція архітектури Web-cepвiciв підприємства має такі переваги:

- оптимізація процесів управління підприємством за рахунок спрощення процедур об'єднання інформаційних потоків і бізнес-процесів;

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

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

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

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

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

Інформація про те, які функції пропонує конкретний Web-сервіс, міститься в його описі - WSDL-документі. Інші системи взаємодіють з Web-послугами, використовуючи повідомлення у стандарті за протоколом SOAP, передані з використанням НТТР і XML і в поєднанні з іншими Web-стандартами.

Для пошуку Web-сервісів використовують спеціальні реєстри, що підтримують UDDI. Є два основні методи публікації Web-сервісів для користувачів - UDDI і DISCO. UDDI - це централізований структурований сервіс реєстру, a DISCO пропонує вільну форму механізму пошуку через браузер. Реєстр UDDI - центральне сховище для специфікацій та інформації про підприємства, включаючи послуги, які компанії надають шляхом Internet.

Web-сервіси стають доступними через протоколи НТТР GET, НТТР POST, НТТР SOAP.

SOAP - стандарт передачі повідомлень через Internet, розроблений фірмою Microsoft для віддаленого виклику процедур (RPC, Remote Procйdure Call) через протокол НТТР. Він дає змогу передавати інформацію мережею у форматі XML. Можуть використовуватися будь-яка мережа, будь-який протокол передачі даних, довільна інформація, різні обчислювальні пристрої (зокрема мобільні). Специфікація SOAP визначає ХМЬ-" конверт" для передачі повідомлень, метод для кодування програмних структур даних у форматі XML, а також засоби зв'язку через протокол НТТР.

WSDL - заснований на XML стандарт опису того, як користуватися сервісом, запропонований Консорціумом W3C. Опис Web-сервісу мовою WSDL містить технічні деталі, необхідні для інтеграції Web-сервісу у застосування (формат повідомлень, операції). На сьогодні WSDL підтримують продукт від Microsoft - SOAP Toolkit 2.0 (WSDL Generator) і продукт від IBM - WSDL Toolkit. Мова опису Web-сервісів (Web Services Description Language (WSDL)) визначає синтаксис того, як Web-сервіс може бути викликаний.

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

Компанії IBM, Microsoft та Ariba створили власні UDDI-реєстри (Web-реєстри), де розробники можуть реєструвати свої Web-сервіси. Інформація в UDDI-реєстрах складається з трьох компонентів:

- ^ибілі сторінки" дозволяють підприємствам реєструвати їх назви і послуги, що забезпечує пошук іншими компаніями згідно з довідниками, які містять їх адресу та інші ідентифікатори;

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

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

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

- бізнес об'єкт (Business Entity) - безпосередньо визначає бізнес;

- бізнес-сервіс (Business Service) - містить інформацію про набір послуг;

- шаблон зв'язування (Binding Template) - містить інформацію про точки входу послуги;

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

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

Бізнес-сервіс (Business Service) - це клас послуг у межах певної галузі промисловості. Кожна галузь належить певному елементу Business Entity.

Шаблон зв'язування та модель технології визначають Web-сервіс. TModel містить абстрактний опис, a Binding Template - конкретну специфікацію послуги.

Поняття архітектури, орієнтованої на послуги, сформувалося упродовж розвитку концепції Web-сервісів. Архітектура Web-сервісів є однією з реалізацій COA (є також інші підходи до реалізації COA: Java RMI (від Sun Microsystems), CORBA (від консорціуму OMG), DCOM (від Microsoft), DCE (запропонований асоціацією Open Group) тощо. COA має такі характеристики: розподілена, інтерфейс функціональних модулів такий, що використання модулів не залежить від технології або платформи, у межах якої вони реалізовані; можливий динамічний пошук і підключення потрібних функціональних модулів; архітектура базується на загальноприйнятих галузевих стандартах'.

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

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

Сервіс-орієнтовані обчислення (СОО) - обчислювальна парадигма, яка використовує сервіси як фундаментальні елементи для розробки застосувань. СОО базуються на COA і забезпечують виконання операцій управління сервісами. Розробка системи СОО - це процес пошуку, підбору і компонування сервісів, що задовольняють вимоги користувача.

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

Функціональні можливості Web-сервісів визначаються входом, виходом, попередніми умовами і діями сервісу. їх позначають як ЮРЕ (inputs, outputs, preconditions, and effects). Наприклад, для сервісу купівлі попередня умова - це коректне введення номера кредитної картки, вихід - генерація квитанції, а дія - оплата товарів/послуг; електронний магазин може мати такі входи: назва товару, адреса споживача і номер його кредитної картки з попередньою умовою перевірки справжності цієї кредитної картки.

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

Більшість послуг, необхідних користувачам, формується вручну з використанням заснованих на WSDL описів елементарних сервісів. Для автоматичного компонування програми мають бути здатними відбирати потрібні Web-сервіси і компонувати їх.

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

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

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

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

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

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

Найбільшою проблемою при виявленні сервісу є їх розподілений характер. Фіксація семантики запитів і досліджень сервісів, так само як контексту запропонованої взаємодії з сервісом, вимагає адекватних засобів подання сервісів і взаємодій. У зв'язку з цим можуть бути застосовані онтології. Для інтеро-перабельного подання онтологій розроблено мову OWL і її модифікацію для сервісів OWL-S (Web Ontology Language for Services).

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

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

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

Використовуючи OWL-S, Web-сервіс може повідомляти потенційним користувачам про свої функціональні можливості. Запит на обслуговування може бути узгоджений з оголошенням Web-сервісів за допомогою процесу підбору (matchmaking).

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

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

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

Загальний словник (тезаурус) містить базові терміни (при* мітиви) ПрО, які комбінуються в локальні онтології для того, щоб описати складнішу семантику. Іноді загальний словник також є онтологією. ПрО може мати декілька онтологій. Будь-яка ПрО характеризується своєю дійсністю, тобто множиною ситуацій, які мали місце у минулому, мають місце у теперішньому і матимуть місце в майбутньому. Інтеграцію онтологій можна розглядати як процес знаходження схожості між різними онтологіями. Нова онтологія може бути використана як посередник між різними системами. Залежно від змін, які необхідно зробити, щоб одержати нову онтологію, можна розрізняти такі рівні інтеграції: відповідність (alignment), часткова сумісність (partial compatibility), удосконалення і уніфікація (unification).

Основою архітектури, орієнтованої на послуги, є взаємодія її учасників: постачальника, споживача та реєстру послуг (рис. 2.9).

Концепція Web-сервісів означає, що вони мають певну обмежену функціональність. Для вирішення складних завдань потрібно використовувати функціональність кількох послуг. Тому в процесі розвитку архітектури Web-сервісів виникло поняття компонування Web-сервісів і потік Web-послуг, або ще використовують термін оркестровка (Web Service Choreography) і хореографія (Web Service Choreography) Web-сервісів. Ці поняття відображають взаємодію послуг і послідовність їх виконання. Застосунки, побудовані з використанням Web-сервісів, базуються на потоках робіт (Workflow-based applications).

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

Для опису бізнес-систем, що базуються на архітектурі Web-сервісів, IT-компанії запропонували використання різних стандартів: Wf-XML (від Workflow Management Coalition), WSFL (IBM Web Services Flow Language), XLANG (Microsoft^ XLANG: Business modeling language for BizTalk), PIPs (Roset-taNet's Partner Interface Process) тощо.

На сьогодні набули поширення BPEL4WS (Business Process Execution Language for Web Services), розроблений IBM, Microsoft i BEA Systems, i WSCI (Web Service Choreography Interface) корпорації Sun Microsystems.

Ще одна корисна технологія підтримки Web-сервісів відома за назвою.NET. Microsoft.NET Му Services надають набір Web-сервісів, які дають змогу клієнтам управляти своїми персональними даними. Компанія Microsoft розробила Global XML Web Services Architecture (GXA - глобальна архітектура Web-сервісів XML).

GXA складається з таких специфікацій: WS-Security, WS-Licensing, WS-Referral, WS-Routing i WS-Inspection. Кожна специфікація представлена як модульна надбудова над SOAP-повідомленням. Отже, будь-яка GXA-специфікація може використовуватися в комбінації з рештою GXA-спсцифінацій.

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

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

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

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

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

SOAP — протокол обміну структурованими повідомленнями в розподілених обчислювальних системах, базується на форматі XML.

Спочатку SOAP призначався, в основному, для реалізації віддаленого виклику процедур (RPC), а назва була абревіатурою: Simple Object Access Protocol — простий протокол доступу до об'єктів. Зараз протокол використовується для обміну повідомленнями в форматі XML, а не тільки для виклику процедур. SOAP є розширенням мови XML-RPC.

SOAP може використовуватись з будь-яким протоколом прикладного рівня: SMTP, FTP, HTTP та інш. Проте, його взаємодія з кожним із цих протоколів має свої особливості, які потрібно відзначити окремо. Найчастіше SOAP використовується разом з HTTP.

SOAP є одним із стандартів, на яких ґрунтується технологія веб-сервісів.