У своєму розвитку протоколи Web-сервісів пройшли довгий шлях, починаючи підтримкою дуже простих запитів з нескладними параметрами і закінчуючи повною підтримкою сучасних об'єктно-орієнтованих мов. Специфікація XML-RPC (Віддалений виклик процедури на XML), що є, мабуть, однією з найбільш ранніх форм Web-сервісів, підтримувала тільки прості типи - рядки, цілі числа, логічні вирази і т.п. Наступним кроком стала поява в SOAP правил кодування для об'єктів. Нарешті, останній крок - поліпшення бінарного коду - було введено в документі консорціуму W3C "SOAP з вкладеннями" (SOAP with attachments).
Спочатку "SOAP з вкладеннями" був запропонований в якості розширення SOAP 1.1, і сьогодні ця технологія підтримується в більшості інструментальних засобів SOAP. Незважаючи на те, що вкладення поки не підтримуються в офіційній версії специфікації W3C SOAP 1.2, зараз ведуться роботи з метою їх включення в цей документ в (умоглядно) найближчому майбутньому.
Web-сервіс і бінарні дані
І все ж використання текстового кодування має і свої «темні сторони», а XML не має дієвим способом включення бінарних даних. Згідно з рекомендацією консорціуму W3C «XML-схема» (W3C XML Schema), бінарні дані повинен бути закодовані з використанням коду Base-64 або шістнадцятирічного коду. На жаль, розмір даних, закодованих за допомогою шестібітного коду (Base-64), виявляється в півтора рази більше в порівнянні з розміром незакодованих даних. Розмір даних, перетворених в систему числення з основою 16, виявляється в два рази більше початкового. Такі накладні витрати прийнятні в разі невеликих фрагментів бінарних даних, але для великих наборів даних такий підхід неприйнятний.
Разом з тим бінарні дані зручні для багатьох додатків, наприклад:
- Для систем забезпечення безпеки необхідні ключі, знаки "решітка", сертифікати, самі закодовані дані.
- Мультимедійні програми використовують фото, музику і фільми.
- У деяких додатках застосування XML-вистави виявляється неефективним, наприклад, в разі автоматизованого проектування (CAD) або автоматизованого виробництва (CAM).
- Існують тисячі файлових форматів, які з'явилися до XML - формати текстових процесорів, електронних таблиць, шрифтів, векторної графіки і т.д.
Хоча створення XML-версій цих файлових форматів можливо (аналогічно формату SVG (Scalable Vector Graphics, масштабована векторна графіка) для векторної графіки), бінарні дані існують вже давно і навряд чи втратять популярність.
Нарешті, існують проблеми і з самим XML! Наприклад, включення одного XML-документа в інший XML-документ не є тривіальним завданням (синтаксично коректне рішення спирається на розділи CDATA і перехід на інші символи).
MIME і код base 64
Щоб уникнути часто виникають непорозуміння, підкреслимо, що MIME не вимагає обов'язкового використання кодування base 64. Точніше реалізації HTTP не кодують включення; їх кодують тільки поштові клієнти, щоб обійти обмеження SMTP (тому при порівнянні з XML будь-яких переваги відсутні).
Тому, щоб реалізувати вимоги всіх цих додатків, Web-сервіси повинні ефективно підтримувати бінарні дані. Пропоноване рішення - SOAP з вкладеннями, який, якщо спробувати сказати коротко, видаляє бінарну інформацію з корисного навантаження XML і зберігає її безпосередньо в запиті HTTP в якості змісту MIME multipart / related.
Таким чином, при проектуванні Web-сервісу, який використовує бінарні дані, слід скористатися один з наступних підходів:
- Якщо набір даних невеликий, можна використовувати код Base-64 для корисного навантаження XML; накладні витрати для невеликих фрагментів даних не є серйозною проблемою.
- Якщо набір даних значний, включення - єдиний практично розумний вибір.
Нижче наведено Лістинг 1 (запит SOAP з параметром, закодованим за допомогою шестібітного коду, в якому особливу увагу заслуговує елемент address.
Лістинг 1. Параметр в системі числення з основою 64r
Реалізація включень
Розробники Java можуть скористатися включеннями, використовуючи JAX-RPC (API на Java для RPC, заснованого на XML) і SAAJ (API SOAP з включеннями для Java). Читачеві слід звернути увагу на абревіатуру SAAJ: JAX-RPC підтримує включення (див. Наприклад, схожі теми). Різниця між JAX-RPC і SAAJ полягає в рівні абстракції, а не в функціональних можливостях.
JAX-RPC - це API високого рівня, він більш абстрактний у порівнянні з SAAJ. JAX-RPC приховує за шаром протоколу RMI (Remote Method Invocation, технологія побудови розподілених додатків в специфікації мови Java) більшість орієнтованих на протокол аспектів SOAP. Розробник займається об'єктами Java, а препроцесор перетворює їх в вузли SOAP. Для уявлення включень JAX-RPC використовує класи java.awt.Image і javax.activation.DataHandler.
SAAJ ближчий до протоколу. Оскільки для створення SOAP-повідомлень за допомогою SAAJ потрібно більше зусиль, ніж з JAX-RPC (і, отже, він не надає автоматичних зв'язків з WSDL), в більшості випадків читач віддасть перевагу JAX-RPC. Разом з тим, низькорівневі аспекти більш зручні для ілюстрації того, як насправді працюють включення. Лістинг 2 - це запит SOAP з включенням. Цей запит просить сервер змінити розмір фотографії; оскільки розмір файлу фотографії великий, використання включення більш переважно.
Лістинг 2. Параметр включення
Наведений нижче Лістинг 3 демонструє створення запиту SOAP. Цей запит просить сервер змінити розмір зображення. Для реалізації цієї процедури необхідно виконати наступну послідовність дій:
Сервіс надає відповідь із зображенням, розміри якого змінені, причому це зображення представлено у вигляді включення. Щоб витягти його, можна протестувати SOAP на предмет несправності (тобто помилки). Якщо несправностей немає, включення слід витягти як файл, а потім обробити.
Лістинг 3. Використання SAAJ
Варто звернути увагу на те, що в лістингу 3 включення знаходиться поза XML-повідомлення. Такий підхід підвищує продуктивність.
Говорячи про продуктивність, розглянемо Лістинг 4, в якому показана більш загальна (і істотно коротша) версія JAX-RPC лістингу 3. прекомпілятора JAX-RPC генерує перехідник (stub), яка значно спрощує кодування. У цьому випадку в якості параметра методу передається об'єкт DataHandler. а JAX-RPC автоматично генерує це включення.
Лістинг 4. Більш ефективний JAX-RPC
висновок
Можливість вибору завжди бажана і SOAP надає таку можливість при роботі з бінарними даними: їх можна або кодувати за допомогою коду base 64 всередині корисного навантаження XML, що є хорошим рішенням для невеликих наборів даних, або приєднувати більші бінарні незакодований файли до цього запиту.