级别： 初级 Edd Dumbill (edd@xml.com), 编辑兼发行人, xmlhack.com
2001 年 12 月 01 日 在关于重新使用 HTTP 作为连接应用程序的便利方法的争论继续的同时，一个称为 BEEP 的新的协议 ― 块可扩展交换协议（Blocks Extensible Exchange Protocol）― 已经被国际工程任务小组（Internet Engineering Task Force（IETF））标准化。BEEP 本身也利用 XML，它对因特网协议的作用正如同 XML 对文档和数据的作用。经验丰富的 XML 观察员 Edd Dumbill 在他为 developerWorks 写的第一篇专栏文章中解释了 BEEP 如何提供一个框架，从而使开发人员可以关注于他们的应用程序的重要方面而不是把时间浪费在有关建立通信通道的细节上。
欢迎阅读研究使用新的基于 XML 技术的实用性的系列文章的第一篇。在这些专栏文章中，我将研究 XML 技术，并试着在实际的系统中部署它。除了汇报部署经历之外，我希望同时还能有些有趣的东西。我不要求读者具备太多预备知识，不过对于基本的 Web 标准（如 XML 和 HTTP）有一些基础的话将是有帮助的。
介绍 BEEP
对于初学者，接下来的几篇专栏文章将研究 BEEP，它是众多潜藏在 Web 服务词汇表里的字首组合词中的一个。本文的目的就是介绍 BEEP 协议框架并就它适合在哪里使用提出建议。
BEEP 代表 Blocks Extensible Exchange Protocol（块可扩展交换协议），这样的全称和只说
BEEP一样没有意义，坦白地说更没有趣味。不过，XML 用户或许会被
可扩展的（extensible）这个词吸引，而的确正是扩展性使 BEEP 值得首先研究。稍后将会对此有更详细的讨论；让我们首先来看看 BEEP 所解决的问题。
假设您正在编写一个网络应用程序而且想让程序的实例能通过 TCP/IP 通信。在您开始考虑应用程序逻辑本身以前，需要解决程序如何连接，如何验证它们自己，如何发送消息，如何接收消息以及如何报告错误等问题。您花在这些问题上的累积时间可能会超过解决应用程序逻辑本身所需的时间。简单地说，这就是 BEEP 解决的问题。它实现了创建新的网络协议的所有“纯净因素”，因此您不必为它们担心。
这时您可能正在疑惑，这并不是没有道理的，为什么在有了 CORBA/IIOP，SOAP，XML-RPC 和其它协议以后还要加上另一种分布式计算协议呢？答案是，您需要认识到 BEEP 位于不同的层。它是一个框架。SOAP 可以恰当地在 BEEP 之上实现。BEEP 负责在消息的 TCP/IP 层连接、验证和封装 ― SOAP 有意回避的问题。BEEP 真正地和 HTTP 在同一层上竞争。
重新使用和重新整理要素
最近的应用程序协议的设计者考察过 HTTP，发现它很好。是足够好。因此 WebDAV，也就是 Windows 中的“网络文件夹”特性背后的协议，为 HTTP 添加了几个动词以允许分布式编写。因特网打印协议（Internet Printing Protocol）则创造了一些 HTTP 头以便使用 HTTP/1.1 做它的工作，而 SOAP 到 HTTP 的绑定也做了类似的事情（有关这三个 HTTP 协议使用的背景知识，请参阅
参考资料）。
大体上，已经做了正确的事。HTTP 这个普遍存在并被广泛实现的协议，已经以一种有效的方式被重新使用。但也存在一些令人遗憾的结果：首先是造成 80 端口的超负荷。因为现在不仅有 Web 页面的请求而且还有潜在的强调安全的交易请求通过 80 端口传递，所以需要增强警惕性。许多影响 80 端口的 Web 高速缓存和其它设备的交互必须得到重视。这些问题在别的地方有详细的叙述（请参阅
参考资料），所以这里不再详细说明。
重新使用 HTTP 的第二个结果是只能使用它的交互模型。HTTP 是无状态的面向请求-响应的协议。不存在带响应的请求，也不存在不带请求的响应。而且，两个请求之间没有状态保存。不幸的是，这对许多交互模式而言不够好，因为它排除了象异步性、有状态的交互和对等通信这样的情况。这些问题可以而且已经通过在 HTTP 上分层解决了，但大部分解决方案都很难使用。
有经验的程序员就会在这个时候指出
重新整理要素的时候到了，即，将系统的职责置于它们正确的层并且提取共同的功能性。这是看待 BEEP 的最好方式：它本质上是对超负荷的 HTTP 重新整理要素以支持当今因特网应用协议的普遍要求。
那么它能做什么？
经过足够的背景知识描述之后，是看看 BEEP 能做什么和不能做什么的时候了，这样可以明白为什么需要使用它。
在 Marshall Rose（BEEP 规范的作者）所给的介绍中（请参阅
参考资料），BEEP 的应用程序“目标市场”在下列术语中描述：
-
面向连接：使用 BEEP 传递数据的应用程序被期望连接、做它们的交易然后断开连接。这使得通信具有有序、可靠和对拥塞敏感的特征。（IP 层上的并行和使用 TCP 而不是 UDP 有许多相同特征。）
-
面向消息：使用 BEEP 传递数据的应用程序被期望用已定义的结构化数据包通信。这意味着正在通信的应用程序是松散耦合的而且不需要详尽地了解彼此的接口。
-
异步的：不象 HTTP，BEEP 不限于请求和响应的特殊定序。异步性允许对等样式的通信，但它也不排除常规的客户机／服务器通信。
尽管这些特征包含了大量的潜在的应用程序（例如，它们会恰当地允许 HTTP、FTP、SMTP 和各种即时消息传递协议的重新实现），还有许多应用程序不在 BEEP 的作用域之内。其中包括只有一次的交换，如 DNS 查找，这里由 BEEP 引起的成本将不成比例，还包括紧密耦合的 RPC 协议，如 NFS。
倘若一个应用程序符合目标市场，那么 BEEP 能提供什么呢？它的功能性的主要方面是：
- 将一个消息与下一个分离（分帧）
- 消息编码
- 允许多个异步请求
- 报告错误
- 协商加密
- 协商认证
不必担心这些事情这一事实使您能腾出手来给网络应用程序增加其它成分。例如，您可以开始考虑消息类型和结构。
BEEP 概念
BEEP 是一个对等协议，这就意味着它没有客户机或服务器的概念，不象 HTTP。然而，就象吵架或谈恋爱那样，某个人必须迈出第一步。为了便利我将把启动连接的一端称为
发起者，而把接收连接的一端称为
侦听者。当二者之间的连接建立以后，一个 BEEP 会话就被创建了。
图 1. BEEP 会话，通道和配置文件
通道
一个会话中的所有通信发生在一个或多个
通道中，正如
图 1中列举说明的那样。这些端只需要一个 IP 连接，这个连接随后被多路复用以创建通道。那个通道中可能的通信性质由它支持的
配置文件决定（每个通道有一个或多个）。
第一个通道（通道 0）有一个特殊目的。它支持 BEEP 管理配置文件，该配置文件用来协商更多通道的设置。所支持的配置文件决定特殊通道中端之间的精确交互。使用 BEEP 定义协议归结为配置文件的定义。
两类配置文件
会话建立后，发起者为它希望使用的特殊配置文件或配置文件集请求启动一个通道。如果侦听者支持配置文件（配置文件集），通道将被创建。配置文件本身采取两种格式中的一种：用于初始化调整的和用于数据交换的。
在通信开始时设置的调整配置文件以某种方式影响会话的其余部分。例如，请求 TLS 配置文件确保通道使用“传输层安全性（Transport Layer Security）”加密。其它的调整配置文件执行象认证这样的步骤。
数据交换配置文件在两端间建立关于通道中允许什么种类的交换的期望，类似于 Java 接口在交互对象间建立关于什么方法可用的期望。如 XML 的名称空间一样，配置文件由一个 URI 标识。例如，BEEP Java 工具中的示例“Echo”配置文件的 URI 为 http://xml.resource.org/profiles/NULL/ECHO。
数据类型
BEEP 对通道能够携带的数据类型没有限制。BEEP 使用 MIME 标准来支持任意类型的有效负载。这个方法巧妙地避开了 SOAP 所引起的这类问题：如何在 SOAP 消息中发送 XML 文档或二进制文件。
XML 连接
在本文的开头我预示过 BEEP 利用 XML，此时对在哪里进行利用感到疑惑是可以理解的。事实上，负责通道初始化的 BEEP 管理配置文件是作为 XML DTD 定义的（有关管理配置文件定义的指示，请参阅
参考资料）。这就是为什么 XML 和 BEEP 一起配合得这么好的原因：因为 BEEP 负责协议的基础设施，XML 负责数据的结构组织。因此对于 BEEP 配置文件中的消息语法的定义而言，XML 是自然而然的选择（尽管，如以上提到的，配置文件可以使用任何 MIME 类型）。
除了通道管理配置文件以外，许多新出现的 BEEP 应用程序配置文件使用了 XML 作为它们消息的编码。这就是一个好处，因为它意味着任何根据 XML 文档定义的现有消息传递标准都有一个相当直接的对 BEEP 配置文件的映射。
总结本次介绍
在本文中，我解释了使用 BEEP 的基本原理并概述了它的目标应用程序区域。我给出了一个有关 BEEP 交互如何发生的非常高级的概述。下一篇专栏文章将详细介绍通信如何通过通道和配置文件完成，并带有一个用 Java 编写的示例实现。
参考资料
关于作者
对本文的评价
| 
