Основні питання

Windows Communication Foundation (WCF) є інфраструктурою зв'язку, що базується на XML. Оскільки дані XML часто кодуються в стандартному текстовому форматі, визначеному в специфікації XML 1.0, пов'язані з ним розробники та архітектори систем, як правило, приділяють велику увагу відстані передачі (або розміру) повідомлень, що надсилаються по мережі, і кодування XML на основі тексту створює особливі проблеми ефективної передачі двійкових даних.

Основні питання

В рамках надання базових відомостей про наступну інформацію для WCF у цьому розділі висвітлюються деякі загальні питання та міркування щодо кодування, двійкових даних та потокової передачі, які зазвичай застосовуються до пов'язаних інфраструктур систем.

Кодування даних: текстовий формат у порівнянні з двійковим

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

У той час як багато з цих і аналогічних питань дійсно актуальні, фактична різниця між повідомленнями з кодуванням у вигляді тексту XML у середовищі веб-служб XML і повідомленнями з двійковим кодуванням у попередньому середовищі віддаленого виклику процедур (RPC) часто набагато менш значуща порівняно з первісними міркуваннями.

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

Однак для деяких типів даних, наприклад чисел, використання двійкових числових уявлень фіксованого розміру (наприклад, 128-розрядного десяткового типу замість звичайного тексту) може показати свою неефективність, оскільки текстове подання може бути на кілька байт менше. Текстові дані також можуть мати переваги щодо розміру завдяки зазвичай більш гнучким варіантам кодування тексту XML, тоді як деякі двійкові формати можуть мати за замовчуванням 16-розрядне або навіть 32-розрядне кодування Юнікод, що непридатне для формату двійкових XML-даних .NET.

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

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

Двійковий вміст

У рядку з кодуванням Base64 кожен символ представляє 6-розрядні дані замість вихідних 8-розрядних, в результаті чого співвідношення кодування-навантаження для Base64 дорівнює 4:3, крім символів додаткового форматування (повернення каретки/перехід на новий рядок), які зазвичай додаються .Тоді як значущість відмінностей між кодуванням XML та двійковим кодуванням зазвичай залежить від сценарію, збільшення розміру більш ніж на 33% при передачі корисного навантаження 500 МБ, як правило, є неприйнятним.

Щоб уникнути такого надмірного навантаження при кодуванні, стандарт підсистеми оптимізації передачі повідомлень (MTOM) дозволяє зовні виражати великі елементи даних, що містяться в повідомленні, і передавати їх з повідомленням як двійкові дані без будь-якого спеціального кодування. При використанні MTOM обмін повідомленнями аналогічний обміну повідомленнями електронної пошти з вкладеннями або впровадженим вмістом (зображення та інший вміст) за протоколом SMTP. Повідомлення MTOM організовуються в пакети як багатоелементні/пов'язані послідовності MIME з кореневою частиною, що є фактичним повідомленням SOAP.

Повідомлення MTOM SOAP змінюється з некодованої версії таким чином, що спеціальні теги елементів, які стосуються відповідних частин MIME, займають місце вихідних елементів у повідомленні, що містить двійкові дані. В результаті цього повідомлення SOAP відноситься до двійкового вмісту, вказуючи на надіслані з ним частини MIME, але передає лише текстові дані XML. Оскільки ця модель тісно пов'язана з надійною моделлю SMTP, існує широка підтримка у вигляді засобів кодування та декодування повідомлень MTOM на багатьох платформах, що забезпечує виняткові можливості взаємодії.

Тим не менш, як і у випадку з Base64, для MTOM також характерний деякий обсяг службових даних для формату MIME, тому переваги використання MTOM виявляються тільки коли розмір елемента двійкових даних перевищує 1 КБ. Через службові дані повідомлення з кодуванням MTOM можуть бути більше повідомлень з кодуванням Base64для двійкових даних, якщо двійкове корисне навантаження залишається у цьому діапазоні. Щоб отримати додаткові відомості, див. розділ "Кодування" в цій темі.

Вміст даних великого обсягу

Якщо не зважати на відстань передачі, раніше згадане корисне навантаження 500 МБ також створює велику проблему в локальному середовищі на рівні служби та клієнта. За замовчуванням WCF обробляє повідомлення у режимі буферизації. Це означає, що весь вміст повідомлення знаходиться в пам'яті до відправлення або після отримання. Хоча це і є гарною стратегією для більшості сценаріїв і необхідно для таких функцій обміну повідомленнями, як цифрові сигнатури та надійна доставка, великі повідомлення можуть вичерпати системні ресурси.

Стратегією обробки великих корисних навантажень є потокове передавання. Хоча повідомлення, особливо виражені в XML, зазвичай вважаються відносно компактними пакетами даних, повідомлення може мати розмір у кілька гігабайт і нагадувати безперервний потік даних, а не пакет даних. Коли дані передаються в потоковому, а не буферизованому режимі, відправник відкриває вміст тіла повідомлення для одержувача як потоку, і інфраструктура повідомлення безперервно направляє дані від відправника одержувачу в міру їх надходження.

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

неможливо легко розбити на послідовність повідомлень;

мають бути своєчасно доставлені;

недоступні повністю на початку передачі.

Дані, які не відповідають цим обмеженням, як правило, краще надсилати у вигляді послідовностей повідомлень у рамках одного сеансу,а не одним великим повідомленням. Щоб отримати додаткові відомості, див. розділ "Потокова передача даних" у цій темі.

Кодування

Кодування визначає набір правил, які стосуються способу подання повідомлень у мережі. Кодувальник реалізує таке кодування і виконує на стороні відправника перетворення повідомлення в пам'яті Message в потік байтів або буфер байтів, який можна передати по мережі. На стороні одержувача кодувальник перетворює послідовність байтів повідомлення в пам'яті.

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

Кожна стандартна прив'язка включає попередньо налаштований кодувальник, відповідно до чого прив'язки з префіксом Net* використовують двійковий кодувальник (шляхом включення класу BinaryMessageEncodingBindingElement), тоді як класи BasicHttpBinding і WSHttpBinding використовують кодувальник текстових повідомлень (за допомогою класу.

TextMessageEncodingBindingElement

Кодувальник текстових повідомлень є кодувальником за замовчуванням для всіх прив'язок на основі HTTP і є правильним вибором для всіх прив'язок користувача, де найбільше значення має взаємодія. Цей кодувальник зчитує та записує текстові повідомлення стандарту SOAP 1.1/SOAP 1.2 без спеціальної обробки двійкових даних. Якщо MessageVersion повідомлення встановлено якNone, програма-оболонка конверта SOAP виключається з виходу, і серіалізується лише вміст тіла повідомлення.

Кодувальник повідомлень MTOM є текстовим кодувальником, який реалізує спеціальну обробку двійкових даних і не використовується за замовчуванням у будь-якій із стандартних прив'язок, оскільки вінє лише програмою індивідуальної оптимізації. Якщо повідомлення містить двійкові дані, що перевищують межу, при якій кодування MTOM має перевагу, дані зовні виводяться в частину MIME за конвертом повідомлення. Див. "Реалізація MTOM" в цьому розділі.

BinaryMessageEncodingBindingElement

Кодувальник двійкових повідомлень є кодувальником за замовчуванням для прив'язок Net* і є правильним вибором, якщо обидві сторони, що взаємодіють, засновані на WCF. Кодувальник двійкових повідомлень використовує формат двійкових XML-даних. .

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

Якщо у вирішенні не використовується взаємодія, але проте слід використовувати транспорт HTTP, можна створитиBinaryMessageEncodingBindingElement у прив'язці користувача, що використовує для транспорту клас HttpTransportBindingElement. Якщо для ряду клієнтів служби необхідно забезпечити взаємодію, рекомендується відкрити паралельні кінцевіточки, щоб кожна з них мала правильні варіанти транспорту та кодування для відповідних клієнтів.

Реалізація MTOM

Якщо потрібно забезпечити взаємодію та планується відправка великих обсягів двійкових даних, як альтернативну стратегію можна використовувати кодування повідомлень MTOM, яке можна реалізувати для стандартних прив'язокBasicHttpBinding абоWSHttpBinding, задавши відповідну властивістьMessageEncoding як Mtom або створившиMtomMessageEncodingBindingElement в CustomBinding. У наступному прикладі коду, взятому зі зразка Кодування MTOM, показаний спосіб реалізації MTOM конфігурації.

---