Web-сервіси в корпоративному середовищі

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

ОГЛЯД

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

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

Для створення відносно нескладних систем цих трьох стандартів досить. Однак уже скільки-небудь нетривіальні рішення (а саме такі, як правило, і потрібні в корпоративному середовищі) вимагають використання таких речей, як гарантована асинхронна доставка повідомлень, управління транзакціями, шифрування пересилаються між системами даних і забезпечення їх непідробності (докладніше ці питання розглядалися під другій частині огляду "Інтеграція: нове рішення старих проблем", PC Week, N 36/2003, с. 31). Всі ці напрямки так чи інакше споріднені WS, і активно створюється деяка надбудова різних специфікацій, що дозволяє вписати ці технології в світ WS. (Вони давно застосовувалися і без жодних Web-сервісів, але найчастіше убудовувалися в погано сумісні фірмові продукти вендорів.)

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

Ринок дорослішає: в результаті конкурентної боротьби різні виробники об'єдналися в кілька угруповань, які змагаються тепер між собою. На різних напрямках WS цей набір угруповань свій. Наприклад, в області управління транзакціями і бізнес-процесами об'єдналися IBM, BEA і Microsoft (умовно IBM +) проти Sun, Fujitsu і Oracle. Звичайно, таке "кучкованіе" скоротило темп зростання числа специфікацій, але їх все одно багато і вони не дуже-то сумісні, що підриває основу ідеології світу WS. В даному огляді я постараюся виділити і описати принаймні головні із запропонованих технологій.

Компоненти базового набору

SOAP (Simple Object Access Protocol)

Призначення: транспортний протокол, віддалений виклик функціоналу.

Розробляється: XML Protocol Working Group консорціуму W3C.

Статус: версія 2.0 затверджена OASIS, фактично галузевий стандарт.

Цей протокол, найбільш розрекламований зі світу WS, призначений для організації взаємодії віддалених систем за допомогою асинхронного обміну XML-відформатованими документами (застосовується XML Infoset). Такі документи мають три частини: конверт (обгортка), заголовок і тіло, загальне призначення яких ясно вже з їх назви.

Подібний розподіл викликано тим, що в загальному вигляді SOAP створює свою віртуальну транспортну середу. SOAP-повідомлення здатне слідувати за маршрутом, який містить кілька вузлів, кожен з яких може вносити в нього зміни або якось ще його обробляти. Статус цих змін відбивається в блоках заголовка повідомлення. Тема являє собою механізм розширення, за допомогою якого можна передавати в SOAP-повідомленні дані, які не є власне основною робочою навантаженням (наприклад: директиви та / або інформація про контекст, необхідні для обробки повідомлення). Це дозволяє розширювати повідомлення специфічним для конкретного додатка способом. Другий великий і обов'язковий розділ - "тіло", в ньому міститься XML-блок з інформацією, яка повинна бути доставлена ​​кінцевому адресату. Обидва цих розділу містяться всередині конверта.

SOAP є простим "містком", що забезпечує взаємодію додатків: в нього закладена парадигма однонаправленої обміну повідомленнями, без підтримки збереження стану цього обміну. Тому для створення систем зі складними послідовностями обміну інформацією потрібні додаткові кошти, щоб забезпечити перетин кордонів брандмауерів, багатовузлових маршрутизацію, гарантовану доставку. Однак SOAP задає інфраструктуру, в рамках якої приватна для кожної програми інфраструктура може бути описана в щодо уніфікованою формою. Крім того, в стандарті викладені загальні принципи, за якими може бути здійснена прив'язка SOAP-повідомлень до абстрактного транспортного протоколу (необхідна для цього інформація буде міститися в заголовку повідомлень), описана загальна схема створення SOAP-оболонок для RPC-оріентірірованних інтерфейсів (віддалений виклик процедур ), наведені конкретні механізми (в першу чергу способи повернення повідомлень про збої), а також зафіксована конкретна реалізація способу оформлення повідомлень SOAP в якості вмісту команд GET і POST протоколу HTTP.

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

Наприклад, протокол HTTP вже має кошти для забезпечення кореляції повідомлень (т. Е. Кошти логічного зв'язування запиту і відповіді), і програмісту не потрібно піклуватися про кореляцію запит - відповідь. Прив'язка до HTTP також дозволяє зробити Web-сервіси більш відповідними загальному стилю WWW і чіткіше передавати повідомлення про помилки. Скажімо, сервіс класу "тільки для читання" може ідентифікуватися в Web деякою адресою URI і по команді GET, що не має параметрів, видавати вже SOAP-отформатированную інформацію. Але така прив'язка дійсна тільки між двома сусідніми вузлами, що підтримують транспортний протокол.

Примітка 2. Група специфікацій SOAP 1.2 сьогодні містить дві основні частини (SOAP 1.2 Part 1: Messaging Framework і SOAP 1.2 Part 2: Adjuncts), три допоміжних документа (SOAP 1.2 Message Normalization, SOAP 1.2 E-mail Bindings, Specification Assertions and Test Collection ) і "Введення" (SOAP 1.2 Primer).

Типове SOAP-повідомлення (приклад з SOAP Version

1.2 Message Normalization)

WSDL (Web Services Description Language)

Призначення: опис властивостей сервісу.

Розробляється: W3C.

Статус: W3C Working Draft 26 березня 2004, фактично галузевий стандарт.

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

Згідно з цим стандартом WSDL-опис сервісу складається з п'яти частин.

1. За допомогою нотацій XML Schema описуються типи даних, що використовуються сервісом (розділ <wsdl: types>).

2. Здається опис вхідних WSDL-повідомлень (<wsdl: message>), що складаються з елементів, що мають типи, описані в <wsdl: types>.

3. Описуються порти (<wsdl: portType>) - їх імена, назви і специфікації допустимих по ним операцій (<wsdl: operation>). Кожна така операція характеризується трійкою повідомлень - вхідним, вихідним і повідомленням про збій. У стандарті задано чотири типи операцій - односпрямовані, запит - відповідь, підтвердження - відповідь і повідомлення (дві останні є інверсіями двох перших). Відповідно, WSDL-порт може бути односпрямованим і двонаправленим. Інформування про збої - функція двонапрямлених портів.

4. Здається прив'язка (<wsdl: binding>) до транспортного протоколу. Тут відбувається перехід від логічної моделі даних до реальної фізичної моделі, т. Е. Того, як саме передаються дані по SOAP. Для опису переходу використовуються так звані SOAP-розширення WSDL (визначені також прив'язки WSDL до HTTP і MIME). За допомогою цих розширень можна, наприклад, просто вказати серверу, що для формування реального SOAP-документа в його тіло потрібно скопіювати тіла описаних WSDL-повідомлень. Тут же задається адреса сервісу в WWW.

5. Групуються опису сервісу (<wsdl: service>) - зводяться разом ім'я сервісу, дані про порти, привязках і людино-якого читають коментар про цілі сервісу. За допомогою цього розділу сервіс можна прив'язати до декількох альтернативних дзеркалам.

Примітка. Група специфікацій WSDL 2.0 складається з трьох основних документів - WSDL Part 1: Core language ( "Основна мова"), WSDL Part 2: Message exchange patterns ( "Шаблони обміну повідомленнями"), WSDL Part 2: Bindings ( "Прив'язки"). Є також незакінчена "Введення".

UDDI (Universal Description Discovery & Integration)

Призначення: стандарт на функціонал і структуру бази даних описів сервісів.

Статус: OASIS UDDI Spec Technical Committee Specification, 14 жовтня 2003.

Разом з SOAP і WSDL утворює трійку базових стандартів Web-сервісів. Являє собою стандарт на внутрішній устрій і зовнішні інтерфейси бази даних (сховища), що зберігає опису сервісів. Задає модель даних і стандартизує API, в тому числі Web-сервісний. Всі описи в БД зберігаються у вигляді XML-записів.

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

У той час як версія UDDI 2.0 призначалася для підтримки каталогів електронного бізнесу, версія 3.0 орієнтована і на внутрішньокорпоративний використання - для побудови корпоративних систем в рамках ідеології Service Oriented Architecture. Тому вона допускає створення реєстрів кількох типів (загальнодоступний, приватний і з розділяються доступом).

Приклад реплікації реєстрів UDDI

Для спрощення пошуку UDDI-реєстр пропонує стандартні механізм для класифікації, каталогірованія, пошуку і управління web-сервісами:

1) він дозволяє задати різні таксономії (класифікатори) в одному реєстрі, т. Е. Один елемент може бути одночасно класифікований по-різному в рамках різних логічних моделей;

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

3) UDDI Inquiry API дозволяє вказувати в параметрах пошуку класифікатор і класифікаційні ознаки, а також проводити з'єднання даних різних пошукових запитів.

Примітка. UDDI спирається на WSDL і XML Schema.

Оптимізації базових специфікацій

У стандартному вигляді SOAP виявився дуже неефективною з точки зору споживання обчислювальних ресурсів технологією. Наприклад, повідомлення EDI (electronic data interchange - електронний обмін даними), що описує дані накладної, має довжину близько 80 байт, в той час як аналогічний XML-повідомлення вже 1,5 Кб. SOAP додасть до нього заголовок і теги розмітки, що ще більше збільшить його розмір. Якщо в тілі SOAP-повідомлення виявляються мультимедійні дані, то ситуація стає зовсім катастрофічною.

Ось тільки деякі з виникаючих проблем:

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

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

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

Тому були створені кілька специфікацій, що описують правила оптимізації трафіку.

SOAP 1.2 Attachment Feature

Призначення: описує абстрактну модель формування SOAP-повідомлень з вкладеннями.

Статус: W3C Working Group Note 8 June 2004.

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

Специфікація описує абстрактну складову структуру, що складається з головної частини, яка містить SOAP-повідомлення, і пов'язаних з ним вторинних частин - вкладень, в які, власне, і поміщаються мультимедіа-дані. Кожна частина такої структури характеризується одним або більше URI-покажчиком, використовуваним для посилань на нього з інших частин. Головною і вторинної частинам присвоєні імена SOAPMessage і SecondaryPartBag щодо якогось базового URI.

Складова структура не є ні узагальненням структурної моделі SOAP, ні узагальненням конверта SOAP і не визначає модель обробки основного повідомлення (всі ці завдання відводяться специфікації SOAP). Це просто абстрактна модель, базові "правила гри", яких потрібно дотримуватися при подальшій реалізації прив'язок SOAP до конкретного транспортного протоколу. Насправді специфікація схиляється до прив'язки до протоколу HTTP.

Складений повідомлення у відповідності зі специфікацією SOAP Attachments Feature

Ось приклади можливого застосування SOAP Attachment Feature:

- головна частина і JPEG-картинка можуть бути вміщені в одне DIME-повідомлення (див. WS-Attachments) і передані через TCP або HTTP;

- головна частина і JPEG-картинка можуть бути вміщені в MIME Multipart / Related message і передані через HTTP;

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

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

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

WS-Attachments і DIME

Призначення: оптимізація довічних вкладень в SOAP-документах і формат їх передачі

Статус: авторська специфікація, робочий документ Internet Engineering Task Force (IETF) 17 червня 2002.

Автори: IBM, Microsoft.

Специфікація спирається на SOAP Attachment Feature і вирішує додатково третю з перерахованих у введенні в розділ проблем. Фактично вона є реалізацією SOAP AF. Автори відзначають, що застосування MIME (технології широкого призначення) призводить до зростання витрат на синтаксичний розбір, наприклад, ресурсоємним виявляється виділення різних частин в MIME-пакеті. Тому вони пропонують свій спеціалізований і полегшений формат: DIME (Direct Internet Message Exchange).

Специфікація WS-Attachments дозволяє оформляти SOAP-повідомлення та їх виконавчі вкладення в блоки DIME-даних. DIME розглядається як спадкоємець MIME-multipart. Він спирається на записи фіксованої довжини, що більш ефективно, ніж використання роздільників в MIME. У нього є заголовок з вмістом, а це дозволяє, зокрема, забезпечити до окремих записів не послідовно, а довільний доступ. Виходить, що DIME - це механізм упаковки набору довільно відформатованих записів в потік даних.

XOP (XML-binary Optimized Packaging Mechanism)

Призначення: оптимізація обсягів XML-документа та подання в ньому даних (кодування).

Статус: W3C Working Draft, 8 червня 2004.

Задає альтернативний загальноприйнятій спосіб сериализации XML Infoset. Корисний, коли всередині SOAP-повідомлень передається мультимедійний та інший двійковий контент. У звичайній формі цей контент повинен бути закодований у вигляді base64 і поміщений в тіло SOAP. За допомогою XOP його можна винести в послідовність MIME-блоків, що знаходяться за межами конверта SOAP-документа. У тілі ж документа залишаються лише посилання на ці дані.

Діаграма стану XOP

Примітка. Формат можна застосувати не тільки до SOAP, а й будь-якого XML-документу.

SOAP Message Transmission Optimization Mechanism

Призначення: оптимізація SOAP-трафіку.

Статус: W3C Working Draft 8 June 2004.

Автори: IBM, BEA, Canon.

Розвиває напрямок економії трафіку і мережевих ресурсів. Описує Abstract Transmission Optimization Feature - дуже неконкретний механізм прив'язки SOAP до транспортного протоколу, що дозволяє кодувати частини повідомлень SOAP, зберігаючи відповідність вимогам XML Infoset. Оптимізація для тих елементів контенту, які є канонічними XML-уявленнями даних в форматі xs: base64Binary. Зокрема, визначається структура і порядок кодування ATO-повідомлень, а також правила їх розкодування. Алгоритмів, як саме це робити, не дається, формулюються тільки загальні положення - якими полями які дані розмічати.

Хоча Специфікація опісує и більш конкретні РЕЧІ - реализации ATO. Так, розглядається спосіб оптимальної сериализации SOAP-повідомлення для передачі його у вигляді послідовності блоків MIME-кодованого тексту, прив'язка до HTTP і тип MIME-даних application / soap_xop + xml. Для вирішення цих завдань активно використовується формат XOP (XML-binary Optimized Packaging Mechanism), фактично специфікація задає його адаптацію до ATO.

SOAP Resource Representation Header

Призначення: розширення SOAP для оптимізації трафіку.

Статус: W3C Working Draft, 28 квітня 2004.

Автори: Oracle, Microsoft, W3C.

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

***

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

Далі буде

Версія для друку

Тільки зареєстровані Користувачі могут залішаті Коментарі.