1.5 Протоколи проміжного рівня

1. Протокол soap

Протокол SOAP (Simple Object Access Protocol) є протоколом проміж- ного рівня за моделлю OSI, тобто він визначає формат повідомлень, що пере- силаються за допомогою деякого транспортного протоколу, яким зазвичай є HTTP, HTTPS, TCP, іноді SMTP.

Формат повідомлень SOAP грунтується на XML, SOAP-повідомлення складається з таких частин:

• конверт (envelope) – містить повідомлення цілком;

• заголовок (header) – містить значення деяких додаткових атрибутів повідомлення, використовуваних під час його обробки або переадресації. Заголовку може не бути або його можуть використовувати зазвичай для пе- редачі інформації про координацію декількох повідомлень, ідентифікацію сеансів і передачі різних сертифікатів для захисту інформації;

• тіло (body) – основний вміст повідомлення, який має належати одному з типів повідомлень, якими можна обмінюватися з певною службою відпо- відно до опису її інтерфейсу. Тіло має бути в будь-якому повідомленні.

Простий приклад SOAP-повідомлення наведено нижче.

<SOAP-ENV: Envelope

xmlns: SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"

SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">

<SOAP-ENV: Header>

<t: Transaction

xmlns: t="http: //company.com/soap-headers/attrs " SOAP-ENV:mustUnderstand="1">

</t: Transaction>

</SOAP-ENV: Header>

<SOAP-ENV: Body>

<m: GetLastTradePrice xmlns: m="http://company.com/web-services/ trading">

<symbol> DEF</symbol>

</m: GetLastTradePrice>

</SOAP-ENV:Body>

</SOAP-ENV:Envelope>

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

2. Сімейство протоколів xmpp

Сімейство протоколів XMPP (Extensible Messaging and Presence Protocol) прийнято як стандарт RFC (Request for Comments), стандартний порт для XMPP – 5222, але також використовують порт 80 та/або 443, якщо виникають проблеми у процесі роботи з брандмауером (firewall).

Переваги сімейства протоколів XMPP, такі:

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

• Відкритий стандарт. Інженерна рада Internet (IETF - Internet Engineering Task Force) формалізувала XMPP як стандарт миттєвого обміну повідомленнями й технологію присутності під назвою XMPP; специфікації XMPP було опубліковано як стандарти RFC 3920 і RFC 3921. Розробка цих специфікацій не прив’язана до якогось розробника. Існує багато реалізацій серверів і клієнтів, а також бібліотек з відкритим вихідним кодом.

• Історія. Технологію XMPP впроваджено 1998 року за підтримки та- ких великих компаній, як Sun Microsystems і Google, створено значну кіль-

кість доповнень до стандартів XMPP для клієнтів, серверів, компонентів і бібліотек кодів.

• Безпека. XMPP-сервери можуть бути ізольованими від публічних мереж XMPP (наприклад у внутрішній мережі компанії) та добре захищеними (завдяки використанню механізмів SASL (Simple Authentication and Security Layer) і TLS (Transport Layer Security)), вбудованими в ядро XMPP специфікаціями. Для можливості використання шифрування каналу XMPP Standards Foundation також застосовують додаткову службу certification authority в xmpp.net, забезпечуючи цифрові сертифікати для адміністраторів XMPP серверів у разі використання StartCom Certification Authority. Багато реалізацій серверів застосовують SSL під час обміну між клієнтом і сервером, чимало клієнтів мають можливість шифрування за допомогою PGP/GPG усередині протоколу.

• Гнучкість. Функціональність, яка налаштовується, може бути над- будованою поверх XMPP для підтримки взаємодії різних мереж, стандартні розширення підтримують XMPP Software Foundation.

Недоліки сімейства протоколів XMPP, такі:

• Надлишковість інформації, що передається. Більше 70 % міжмереж- ного трафіку XMPP стосується повідомлень зі службовою інформацією, бли- зько 60 % яких є зайвими. На сьогодні XMPP створює надлишковий трафік під час доставки «статус-повідомлень» (повідомлень про присутність) декіль- ком користувачам. Для розв’язання цієї проблеми розробляють нові протоколи, розширяють XEP-0138 (компресія переданих даних протоколу алгоритмами lzw і zlib), а також використовують компресію в межах шифрування з’єднання TLS RFC 3749;

• Масштабованість. XMPP має також проблему надмірності, але сто- совно чат-кімнат і можливостей публікації інформації. Розв’язання цієї про- блеми передбачається у застосуванні XEP-розширень.

• Неефективність передачі бінарних даних. Оскільки XMPP є одним XML-документом, неможливо передавати немодифіковану двійкову інфор- мацію, тому для передачі файлів застосовують додаткові протоколи, напри-

клад HTTP, а для передачі файлів й іншої бінарної інформації безпосередньо в XMPP-потоці використовують кодування base64.

Адресація. ^{Кожен користувач у мережі Jabber має унікальний ідентифі-} катор – JID (Jabber ID). Адреса JID, подібна адресі електронної пошти, міс- тить ім’я користувача й доменне ім’я сервера, на якому зареєстровано корис- тувача, розділені знаком @.

Приклад. Користувач user, зареєстрований на сервері example.com, ма- тимеме

адресу: user@example.com.

Користувач може мати одночасно кілька підз’єзднань, для розрізнення яких використовують додаткові значення JID, які називають ресурсом та додають через знак «/» у кінці адреси.

Приклад. Нехай повна адреса користувача буде user@example.com/work, тоді повідомлення, надіслані на адресу user@example.com, дійдуть на зазна- чену адресу незалежно від імені ресурсу, але повідомлення для user@example.com/work дійдуть на зазначену адресу тільки за умови відповідності під’єднаному ресурсу.

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

З’єднання з іншими протоколами. ^{Корисною особливістю XMPP- систем є транспорти, або} шлюзи^{, які дозволяють користувачам отримувати} доступ до мережі, побудованої на основі інших протоколів, зокрема протоко- лів миттєвого обміну повідомленнями або SMS і електронної пошти.

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

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

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