ПредишенСледващото

В своето развитие, протоколи за услуги в мрежата е отишло от подкрепа много прости искания с прости параметри напълно да подкрепя модерни, обектно-ориентирани езици. Спецификация XML-RPC (Remote Procedure призив към XML), което е може би една от най-ранните форми на услуги в мрежата, само поддържа прости вида - низове, числа, логически изрази и т.н. Следващата стъпка е появата на правилата за SOAP кодиране за показване на обекти. И накрая, последната стъпка - подобряване на двоичния код - той е въведен в документ консорциум W3C "SOAP с прикачени файлове" на (SOAP с прикачени файлове).

Първоначално, "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, Scalable Vector Graphics) за векторни графики), съществуват двоични данни за дълго време и едва ли губят своята популярност.

И накрая, има проблеми с самия XML! Например, включването на XML-документ в друг XML-документ не е тривиална задача (синтактично правилно решение разчита на CDATA секции и други символи).

MIME и код база 64

За да се избегне честото объркване, ние подчертаваме, че MIME не предвижда използването на шифроване база 64. По-конкретно HTTP реализации не кодират включване; те кодират само за електронна поща, за да се справите с ограниченията в SMTP (така в сравнение с XML някакви ползи не са налични).

Следователно, за да изпълни изискванията на тези приложения, уеб услуги, трябва да подкрепят двоични данни ефективно. Предложеното решение - сапун с прикачени файлове, което, накратко, премахва бинарна информация от XML полезния товар и го съхранява директно в искането за HTTP като съдържание MIME Многопластови / свързани.

По този начин, в дизайна на уеб-услуга, която използва двоични данни, трябва да използвате един от следните начини:

  • Ако набор от данни е малък, можете да използвате код за XML полезния товар Base-64; режийни разходи за малки части данни не са сериозен проблем.
  • Ако набора от данни, е значителен, включването - на практика единственият разумен избор.

Под Обявата 1 (параметър на заявката SOAP кодиран в кода на шест-малко, което заслужава специално внимание адрес елемент.

Обява 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 позоваването метод, технология за изграждане на разпределени приложения в спецификацията Java език), по-голямата част се фокусира върху аспекти на протокола SOAP. Предприемачът работи на Java обекти и Препроцесорът ги превръща в SOAP възли. Да представлява включвания JAX-RPC използва класове и java.awt.Image javax.activation.DataHandler.

SAAJ по-близо до протокола. Що се отнася до създаването на сапун съобщения чрез SAAJ изисква повече усилия, отколкото с JAX-RPC (и, следователно, тя не предвижда автоматични връзки към WSDL), в повечето случаи ще JAX-RPC. В същото време, аспекти от ниско ниво са по-удобни за илюстриране как всъщност да се превърне работа. Обява 2 - включване искане сапун. Това искане пита сървъра, за да промените размера на снимки; като размера на снимката файл е голям, използването на включването е за предпочитане.

Обява 2. Мощност Вариант

Следващият списък 3 показва как да създадете заявка сапун. Това искане пита сървъра, за да промените размера на изображението. За изпълнение на тази процедура, трябва да изпълните следните стъпки:

Услугата предоставя в отговор на промяната на размерите на изображението, както и този образ е представен под формата на включване. За да го премахнете, можете да пробвате повреда SOAP (т.е. грешка). Ако няма вина, включването трябва да се отстрани като файл и след това процес.

Обява 3. С помощта SAAJ

Заслужава да се отбележи, че в Обява 3 превключване е извън XML-съобщения. Този подход подобрява производителността.

От гледна точка на производителност, помисли Обявата 4, която показва по-общ (и значително по-кратък) JAX-RPC Обява 3. Предкомпилаторът генерира JAX-RPC адаптер (коляно), което значително опростява кодиране. В този случай, обектът DataHandler се предава като параметър на метода. и JAX-RPC автоматично генерира прикрепване.

Обявата 4. по-ефективно JAX-RPC

заключение

Избор е добро и SOAP дава възможност за избор при работа с двоични данни: Можете да го кодира с помощта на кодовата база 64 в XML полезния товар, което е добро решение за малки набори от данни, или да се прикрепят по-големи двоични некриптирани файлове на това искане.

Изтегляне ресурси

Свързани теми

Подкрепете проекта - споделете линка, благодаря!