Web-технологии развиваются стремительно. На смену первоначальному языку разметки HTML пришел более универсальный XML. Из способа представления документов в электронном виде Web превращается в среду взаимодействия приложений и сервисов. Однако протокол передачи данных остается неизменным — это все тот же HTTP со всеми своими недостатками (отсутствие сохранения состояния сеанса, существование независимых сеансов для каждого типа данных). Особенности унаследованного протокола требуют от разработчиков современных Web-сервисов определенных технических ухищрений, которые часто ухудшают характеристики системы.
Идя навстречу веяниям времени, группа IETF разработала и утвердила новый протокол BEEP — Blocks Extensible Exchange Protocol (протокол для расширяемого обмена блоками информации). Он создан с целью адекватной замены HTTP и предназначен для передачи данных в формате XML. Его ключевыми особенностями являются поддержка нескольких каналов передачи данных в одном сеансе и возможность одновременной транспортировки нескольких независимых информационных блоков. Каждый блок соответствует стандарту MIME, то есть, как и почтовое сообщение, может содержать несколько типов данных. За протоколом даже «закреплен» определенный MIME-тип данных application/beep+ xml — он используется для передачи служебных сообщений, обеспечивающих настройку сеанса и управление каналами. Блок состоит из заголовка, «тела» и завершающей строки. Как и в HTTP, заголовок от тела отделяется пустой строкой. Блок заканчивается строкой END, за которой может следовать новый блок.
Новый стандарт предусматривает три режима взаимодействия клиента с сервером: «запрос — ответ», «запрос — сообщение об ошибке» и режим уточняющих запросов. Первые два примерно соответствуют возможностям, обеспечиваемым протоколом HTTP, а последний позволяет серверу запрашивать у клиента уточняющую информацию. В этом случае обмен сообщениями выполняется до тех пор, пока клиент и сервер не передадут друг другу нулевое сообщение, после которого сеанс прекращается. Таким образом, протокол предусматривает пять типов сообщений: запрос (MSG), ответ (RPY), сообщение об ошибке (ERR), уточняющий запрос сервера (ANS) и финальное нулевое сообщение (NUL).
Важной особенностью протокола BEEP является управление каналами. С каждым каналом связан определенный профиль, который позволяет взаимодействующим сторонам договариваться о правилах работы с передаваемой информацией. Во время сеанса организуется один служебный (tuning) канал, который может быть дополнен несколькими информационными каналами. Отметим, что BEEP является протоколом уровня приложения, то есть установление самих сеансов связи и правила передачи данных в этом протоколе не описываются. Сейчас существуют только рекомендации по использованию BEEP поверх TCP, однако возможно, что вскоре появятся аналогичные правила его применения поверх другого протокола сеансового уровня — SCTP.
Изначально предполагалось использовать BEEP для передачи сообщений между приложениями в формате SOAP, поэтому группа разработчиков стандарта активно взаимодействовала с W3C. В частности, вся служебная информация протокола передается в формате XML. Так, чтобы настроить служебный канал (номер «0»), клиент и сервер должны обменяться сообщениями, включающими в себя тег greeting, а для создания нового канала — передать друг другу тег start с указанием номера канала (см. листинг). Внутри этих тегов приложения могут содержать дополнительную информацию, определяющую, где искать профили канала или на каком естественном языке нужно выдавать информацию.
Основным применением BEEP является передача коротких сообщений между приложениями в формате SOAP. Поскольку приложений, поддерживающих этот формат, пока не так уж много, своевременное принятие стандарта BEEP позволяет разработчикам сразу перейти на новый протокол, а не следовать рекомендациям W3C, в соответствии с которыми в качестве транспорта предполагается использовать HTTP. Таким образом, BEEP явно имеет большое будущее, поскольку он удовлетворяет современным требованиям создания Web-приложений.