级别： 初级 柴晓路 (fennivel@uddi-china.org)Chief System Architect
2002 年 7 月 01 日 本文应SOAP/1.2规范最新的发展动态，为读者即时带来SOAP/1.2的最新内容，SOAP绑定框架。SOAP绑定框架为SOAP绑定定义了一个描述的规范，使得自定义SOAP绑定可以应用这一套规范，最大可能地减少SOAP绑定规范的二义性以及理解的偏差，为SOAP绑定的大规模出现奠定基础。
绑定框架概述
SOAP提供了一个简单的消息框架，在这个消息框架中，预先提供了一组核心的功能集，同时具备很好的可扩展性。
对于一个SOAP结点来说，接收和发送SOAP消息最终是要通过与某个底层通讯协议进行绑定来完成。SOAP底层协议绑定沿着SOAP消息路径在相邻的SOAP结点间工作着。SOAP协议绑定并不会单独提供一个处理模型也不会通过协议绑定来重新指定SOAP结点。SOAP协议绑定是SOAP结点实现的一个组成部分，从外部来看是SOAP结点的行为特征之一。在整个SOAP消息路径上，我们并不要求在所有的结点间都使用相同的底层传输协议。也就是说，在任意的两个SOAP结点间，可以使用任意的底层传输协议绑定。
协议绑定作为SOAP结点间的通讯部分的机制，我们也许需要为其引入一些抽象的特性，以使得在通讯协议的环境下交换消息更为有效，并更能满足用户的需求。虽然SOAP本身并没有对这些特性的潜在的涉及范围作任何限制，不过典型的，我们可能会考虑"可靠性"、"安全性"、"相关性"以及"路由"等等。同时SOAP规范本身仅仅定义了一种消息交换模式(Message Exchange Pattern，MEP)，单向传输(one-way)消息交换模式，而在通讯协议的环境下，我们需要考虑的消息交换模式远不止此。
在一些应用案例中，底层协议或是直接或是通过扩展，部分或完整地配备了前面所提及的那些特性。这些特性的表现形式是一组模块化的组件，这些组件是基于SOAP结点之间达成的协约以及他们共同支持的协议的。SOAP绑定框架(SOAP Binding Framework)为这些特性及其与SOAP结点的关联的描述提供了一个框架。一个SOAP绑定规范需要声明这个绑定提供的特性，同时描述了所声明的被该绑定支持的特性如何能够通过底层协议服务来支撑和实现。另外，绑定规范同时还定义了根据其所描述的绑定规范，架构规范兼容的软件实现时需要注意的一些需求。
SOAP扩展模型和SOAP绑定框架共同为这些特性的表现提供了保障，这一保障是建立在两者共同的可扩展性和柔性的基础上的：这些特性可以完全在SOAP envelope(或是信息条目)中表现；也可以在SOAP Envelope外表现(典型的，是在底层协议中体现的)；当然也可以结合两者，即在SOAP Envelope内表现也在SOAP envelope外表现。这完全取决与参与通信的结点认为如何表达制订的特性是最优的方法：当某个特性在绑定层被实现后，可能此时我们选择完全在SOAP Envelope中表现，然后再经过一段时间的应用后，发现性能不够，我们就会去优化和调整该软件实现，此时我们可能会将一些机制从SOAP Envelope中移出到底层协议中加以体现。
绑定框架的目标
上面我们已经提到，SOAP消息可以使用多种底层通讯协议进行实际传输。在后面的部分，我会讨论如何将SOAP消息和HTTP协议进行绑定的细节。而关于如何将SOAP消息和协议绑定的一般性的概要介绍我将在本章节中提供。
对于SOAP绑定框架而言，它的目标是：
- 包含并陈述对于所有绑定规范都通用的需求和概念；
- 便利支持通用特性的同构绑定的描述和使用；
- 便利支持通用特性的异构绑定的描述和使用。
这里我们需要注意的是，第二个目标和第三个目标是相互关联的。我们可以想象，两个或者更多的绑定也许为提供同一个制定的特性，例如可靠传输，其中一个绑定也许使用了一个直接支持该特性的底层传输协议(也就是说该协议是可靠的，比如HTTPR)，而另一个绑定也许在逻辑上提供了可靠性(通过日志机制和重发机制来保障)。这个特性应当能在不同的应用之间以一致的方式被支持并投入使用，对于开发人员或应用程序而言不需要知道各个通信方具体使用的绑定的特定实现方式。
绑定框架
对SOAP消息的创建、传输和处理，及其可能穿越一个或多个中间介的可能性，我们能够通过使用一个分布式状态机来描述清楚。一个状态是由一个SOAP结点在指定的时间点上涉及的相关信息所组成的，这些信息包括但不限于正在装配准备传输的消息的内容，或是已经接受到准备处理的消息的内容等。对于每个结点而言，它的状态可以被本地处理所更新，也可以因收到一个邻近结点的信息而更新。
SOAP处理模型中描述了所有SOAP结点在接收到SOAP消息后的通用处理流程。而绑定规范则主要阐述与指定绑定相关的在核心SOAP处理规则之外的任何额外的处理步骤，同时需要描述在消息路径的相邻结点间在使用底层协议来传输信息时所要遵循的一些方式和表现行为。
因此，管理指定的SOAP消息通过消息路径进行传输的分布式状态机需要结合每个结点的核心SOAP处理操作以及在每一个结点对之间使用的绑定规范。
如同前面描述的那样，SOAP可以通过提供可选的特性(比如可靠消息传输、请求/响应消息交换模式、多点传送消息交换模式等等)来扩展。
对于每个这样的特性，特性规范定义必须包含：
- 对于每个结点，为实现该特性所需要了解的信息(状态)；
- 对于每个结点，为满足该特性所承诺的功能而需要实现的处理过程；
- 在结点间传输的信息，以及在消息交换模式下，对于生成额外消息的任何需求(比如在请求/响应消息交换模式下对于请求消息需要有响应消息生成)。
值得注意的是，每一个绑定规范都必须支持传输以及支持对单向消息的支持。一个绑定规范可以声明其支持了那些额外特性，此时，这个规范必须与那些同样支持这些特性的规范以一致的方式提供维护状态、处理实施以及信息传输等方面的功能描述。
当某个绑定规范同时支持多个特性时，该规范必须为能成功组合使用这些特性提供任何必要的信息；对于绑定框架而言，并不会提供任何明确的机制，以确保多个特性的兼容性问题。
在绑定框架中，对于一个给定SOAP结点中的某个状态，组成该状态的信息中的命名方式以及类型定义都没有被提供固定的定义方式。而各个特性和绑定规范都可以使用自己的习惯来描述状态(SOAP结点的状态部分)。不过需要注意的是，无论我们使用何种方式来定义这些绑定规范及其支持的特性，在描述一致性上，我们都需要尽力增强，这是在实现上保证彼此兼容性的基本保障。例如，对于一个认证证书的一致性兼容规范而言，就可以被多种其他的特性所兼容使用。
如同我们在上一章的SOAP消息结构中描述的那样，SOAP消息被建模成一个由单个文档元素，envelope元素，所组成的XML信息集。因此，在传输SOAP消息中的绑定，它起码要指明SOAP XML信息集传送的方法，接受到SOAP消息的SOAP结点重组这些SOAP XML信息集的方法，以及利用底层通讯协议来传输SOAP envelope的方式等。绑定框架并不需要每个绑定都使用XML编序来表示所有的这些信息集；事实上，任何的压缩、加密以及分段表示的传输绑定都是适合于绑定传输的。
对于绑定来说，它也许是要对在SOAP XML信息集之外的状态信息进行建模(比如发送重试次数)，同时也许会需要在相邻的结点之间传送这些信息。例如，一些绑定可能将消息发送地址放在SOAP envelope之外来表示，SOAP HTTP绑定就是这样的一个例子，它使用了一个称为SOAPAction的HTTP头字段来描述消息发送地址，而没有在SOAP XML信息集中，也就是SOAP消息内描述这一信息。
消息交换模式
在SOAP规范中，我们知道SOAP针对的是基础的传输消息的格式，而采用何种传输协议并非是SOAP规范自身的职责。由于基于消息的远程调用的抽象模式(消息交换模式)不外乎是在通信双方进行N(N>=1)次消息交互。通常常用的消息交互模式有N=1、2、3时的情形。
- 当N=1时，相当与从请求方单方向地向接受方发送消息，也就是我们先前提到的单向传输消息交换模式，通常的应用往往有应用服务向系统日志服务发送日志消息，监控服务向应用服务发送警示消息等。
- 当N=2时，用于一般的服务交互，即请求方向接受方发送消息，然后接受方处理同时将处理后地结果消息发送给请求方，也就是请求/响应消息交换模式。这类应用是非常多的，比如用户登录需要包含请求方向接受方发出的登录请求消息，同时也要包含接受方响应请求方的登录是否成功的指示性消息。比如订单查询调用，请求方向接受方发送订单查询消息，而接受方向请求方响应订单明细地消息等。
- 当N=3时，往往这时候对可靠性地要求比较高，应用与事务交互中，请求方向接受方发送消息，然后接受方处理同时将处理后地结果消息发送给请求方，最后请求方再向接受方发送消息确认已经受到结果，这是可靠消息交换模式的一种。这类应用常见于可靠性事务的应用中，请求方向接受方传送事务提交请求，接受方执行事务，并返回事务执行结果，请求方受到执行结果消息后，向接受方发送确认结果消息地指示性消息。
而这些抽象的消息交互模式事实上已经存在于大量地网络通讯协议中了，Internet的绝大多数通用传输协议采用的都是这样的消息交互模式。因此如果将SOAP消息作为Internet网络传输协议所传输的内容来利用这些网络传输协议来传送，可以天然地获得这些协议的消息交互机制。无需自己定义，就能够无缝地利用现有技术的能力完成自己的需求，这正是开放式互操作技术的制订原则。
与应用相关的协议实施绑定
一些底层通讯协议可能是为特定的目的或应用背景而设计的。当SOAP与这些协议实施绑定时，完全可以如同这些底层协议一样使用相同的端点标识(比如，TCP端口号)，以便于有效地重用与该协议相关联的底层架构。
不过，如果SOAP使用了这些广为人熟知的端口的话，势必会引起一些额外的、非计划中的由中间介以及底层实现触发的一些处理。例如，HTTP一般会被认为是一种"Web浏览"协议，网络管理员一般可能会对HTTP协议使用加上一些明确的限制，同时也会有一些底层服务会对HTTP协议通讯有一些额外的操作，比如过滤、内容更改、路由等等。通常，这些底层服务是根据协议使用的端口号来触发的。
因此，对于这些具有广为人熟知的端口或是基于应用广泛的应用背景的底层协议而言，对它们的绑定定义应当对那些通过默认端口或基于默认应用背景下，与部署平台/基础架构之间存在的潜在的(多半是比较危险的)交互的可能详细罗列并规范文档化，以便于在实现的时候注意避免触发这些交互。同时该绑定定义应当指明，可以通过使用非默认端口的绑定来避免这些与底层服务之间存在的、不期望发生的交互可能。
描述特性和绑定
下面我们继续讨论在绑定框架中的特性以及具体的绑定，特别的，是给出了一个包含了特性以及绑定各种属性及其属性值的约定。这一约定对于描述由绑定框架控制的特性和绑定规范的分布式状态是充分的。在后面的内容中，我们会应用这一套约定来描述简单请求/响应消息交换模式(Single-Request-Response MEP)。
同时在约定的描述中，定义了一个信息模型以描述那些特性以及绑定的属性是如何通过SOAP系统来传递的。需要注意的是，这个信息模型的提出只是为了描述更为方便的用途，并不意味着这个信息模型会对任何特定的SOAP实现的结构和层次产生约束.
通常，SOAP消息包含了一个SOAP结点期望与另一个SOAP结点交换的信息，这个交换过程将基于一组包括消息交换模式在内的特性。另外，在交换一个SOAP消息的时候，将会有一些重要的但并非SOAP消息一部分的信息会被使用。这样的信息有时候被称为消息元数据。在我们这个模型中，消息、所有的消息元数据以及总多的使得特性有效工作的信息项都被表示成一个抽象概念：属性。
特性能够通过多个属性来表现，而一个属性也可以表现多个特性。例如，名为User ID的属性和名为Password的属性可以一起来表现成为权限认证的特性。而一个名为Message ID的单一属性则可能用于表现一个称为Transaction(事务)的特性，以及一个称为Message Correlation(消息相关性)的特性。
属性
在下面要描述的约定中，属性被描述如下：
- 属性是使用带命名空间修饰限定的XML名(QName)来命名的。例如，myNS:RetryCount，RetryCount是属性的名，而myNS是关联一个命名空间的命名空间前缀。
- 属性的值是具有类型的，同时属性值的类型是XML Schema中的那些能够应用于属性的简单数据类型。例如，RetryCount的类型是xsi:int。
属性的作用范围
Figure 1. 带授权句柄的SOAP RPC请求表示
在SOAP结点中的属性可以应他们的值的应用领域以及来源而相区别。其中，一些属性仅仅在每次消息交换中被应用，而另一些则有着更广泛的意义。例如，SOAP消息属性的应用领域是每次消息交换，而用户标识属性的应用领域则可以被扩展而超越单次消息交换。另外，一些属性的值是直接来源与SOAP结点的操作以及消息交换的，而另一些属性的值则起源于根据本地环境而定的特别的实现方式。在上面的图1中，我们对于那些应用领域仅存于每个消息交换的属性以及具有更广泛应用领域的属性作出了明确的区别，我们将他们划分在不同的属性容器中，那些应用领域仅存于每个消息交换的属性在容器"消息交换上下文(Message Exchange Context)"中，而具有更广泛应用领域的属性则存于容器"环境(Environment)"中。所有的属性，无论他们的应用领域是如何的，都被SOAP以及一个特定的绑定所共享。
不过，在"环境"中的属性的值可能是基于本地环境的。更具体的，在图1中的"环境"中的属性可以被具体执行消息交换的操作系统用户ID所影响。在特定的实现中，这样的属性的信息映射是在绑定框架的作用领域之外的，虽然如此，这些属性信息的抽象表示却是在绑定框架的作用领域之内。
属性和特性
特性可以通过多个属性来表现，而一个单一的属性也可以用于表现多个特性。例如，名为User ID的属性以及名为Password的属性可以用于表现一个称为Authentication的属性。而一个单一的名为Message ID的属性则可以被同时用于表示两个特性：名为Transaction(事务)的特性，以及名为Message Correlation(消息相关性)的特性。
小结
本文详细地介绍了SOAP绑定框架，在下一篇文章中，将应用SOAP绑定框架所提供的描述方法来实际地描述一个SOAP绑定中使用的消息交换模式，以作为本文的示例。
参考资料
关于作者  | 
| | 柴晓路: 上海得易电子商务技术有限公司(
DealEasy)首席系统架构师、XML Web Sevices技术顾问，
WS-I Working Group成员，U
DDI Advisory Group成员，
UDDI-China.org创始人，IBM developerWorks专栏作家。2000年获复旦大学计算机科学硕士学位，曾在国际计算机科学学术会议(ICSC)、亚太区XML技术研讨会(XML Asia/Pacific'99)、中国XML技术研讨会(北京)、计算机科学期刊等各类国际、国内重要会议与期刊上发表论文多篇。专长于Web Services技术架构、基于XML的系统集成和数据交换应用及方法，同时对数据库、面向对象技术及CSCW等技术比较擅长。
|
对本文的评价
| 
