2.3.4 Push-сервіс

Взаємодія з ініціатором доставки контента відбувається зазвичай через WAP Push Gateway. Іноді його посередництво стає життєво необхідним, наприклад, коли термінал і постачальник інформації не можуть знайти “спільний” протокол. Перетворення форматів, а також надання ініціатору передачі відомостей про можливості термінала є основними функціями сервера. Діалог між сторонами-учасниками процесу здійснюється за допомогою двох протоколів: між терміналом і шлюзом ? це OTA (Over-The-Air), словник, якого складають XML-повідомлення, і між сервером-ініціатором доставки і шлюзом ? PAP (Push Access Protocol). В залежності від протоколу нижнього рівня до назви OTA додають різні суфікси: OTA-WSP, OTA-HTTP. Власне суб’єкт push-доставки упаковується в MIME-повідомлення з заголовками, які представляють собою суміш з стандартних HTTP headers і додаткових WAP headers. В заголовках розташовуються відомості про додаток-отримувач (оскільки один порт може бути поділений між декількома), адреса ініціатора доставки, тип контента, кінцевий строк вживання тощо. Доставка здійснюється з встановленням з’єднання і без нього. Останній варіант реалізується виключно за допомогою протоколу WSP. 

2.3.5 Wireless Session Protocol

Абревіатура WSP розшифровується як Wireless Session Protocol, і застосовується цей мережевий рівень для керування передачею даних. Протокол підтримує асинхронні запити, котрі економлять час при використанні ненадійного та повільного каналу зв’язку. Під асинхронністю тут ми розуміємо послідовну видачу пакетів запитів без очікування відповідей на кожний з них.

Щоб легше було, зрозуміти роль та призначення WSP, перерахуємо основні типи запитів: Connect, Suspend, Resume, MethodInvoke і Push. Кожний запит має набір обов’язкових та необов’язкових параметрів. Наприклад, для простенького Connect це будуть Address (комбінація з Client Address і Server Address), Body, Headers (сумісний з HTTP), Capabilities (довільний набір параметрів, які описують можливості терміналу або сервісу, такі як найбільший розмір повідомлення, кодування заголовка тощо), Status і  Request URI. Також в якості параметра необхідно вказати Transaction Identifier ? індекс, який дозволяє розрізняти повідомлення, згенеровані у відповідь на пакет запитів в асинхронному режимі.

Що стосується WTP (Wireless Transaction Protocol), то для визначення його місця в ієрархії WAP достатньо сказати, що WTP займається практичною реалізацією системи односторонніх, надійних і ненадійних запитів, котрими користується WSP для організації сесії з встановленням зв’язку. 

2.3.6 Формати даних, засоби та способи збереження й передачі

Є два способи відображення значків-піктограм: стандартний набір символів Unicode і графічні зображення. Незважаючи на очевидну перевагу компактних UTF-символів (максимум 4 байта) над ресурсномісткою графікою, для реалізації таких можливостей, як анімація, прийшлось піти на компроміс. Вже підготовлена велика бібліотека-словник зображень.

В загальному розділ, який декларує стандартні типи даних для WAP-пристроїв, небагатий. В даний час уніфіковані тільки формати запису міжнародних та міжміських кодів, символьні послідовності набору, елементи адресної книги і DTMF-послідовності (Dual Tone Multi-Frequency). З набору форматів обміну контактною інформацією популярними є vCard і vCalendar.

З форматів файлів особливої уваги заслужив тільки WBMP (Wireless BMP), котрий був успадкований з попередньої версії WAP, на перший погляд, без змін. WBMP підтримує виключно чорно-білі зображення (без градації яскравості), що знімає необхідність таблиці кольорів. Не дивлячись на спрощення, можливий запис анімації на 15 кадрів. Всі інші типи файлів залишені на розсуд специфікації MIME, що, не буде недоліком, оскільки це покращує сумісність з загальновизнаними та прийнятими стандартами.

Сервіс MMS, призначений в першу чергу для передачі мультимедійних повідомлень (зображення, відео, аудіо). Але не тільки їх. Архітектура сервісу не орієнтована на режим реального часу, а повідомлення відправляються за допомогою серверів MMS Proxy-Relay і тимчасово (до встановлення зв’язку з реципієнтом) можуть зберігатися на серверах MMS. Передбачений обмін повідомленнями з поштовою системою Internet. На MMS Proxy-Relay покладена задача перетворення MMS в MIME з відповідною заміною заголовної інформації. Заголовки, які не мають аналогів в форматі MIME, кодуються за допомогою префіксів X-Mms, котрі будуть просто проігноровані клієнтом, несумісним з MMS. Однак наявність таких префіксів дозволить потім відновити вихідний вид повідомлення для подальшого пересилання на інший мобільний термінал. 

Оскільки питання перетворення знято, то стає можливим завантаження MIME-повідомлень з віддалених поштових серверів POP3 або IMAP. Зі сторони термінала організацією процесу створення і пересилки MMS займається MMS User-agent. Для економії пропускної здатності зміст та заголовки MMS-повідомлень перетворюються в байткодову форму.

Дуже незвично виглядає декларація такої екзотики, як MMS-презентації. В повідомлення наряду з мультимедійним контентом може бути впроваджений сценарій, який визначає послідовність показу. В якості мови пропонується використовувати WML або SMIL (динамічне розширення XML).

Проектуючи систему зберігання даних, учасники WAP-форуму намагались домогтися максимальної подібності з найбільш розповсюдженою структурою: файл ? каталог ? носій. Щоб побудувати ієрархію, котра лягла в основу WAP Persistent Storage Interface, необхідно замінити слово “файл” на "Storage objects", носій ? на "Storage medium", а слово "каталог" залиши в спокої. Зміст виразу "Storage medium" випливає зі списку значень цього параметру: EEPROM, FLASH, SIM, SmartCard і т. д.

На транспортному рівні