协约和组织：B2B 的协议体系结构
来源：百度文库 编辑：神马文学网 时间：2024/10/05 23:29:03
发布日期： 7/5/2004 | 更新日期： 7/5/2004
Marc Levy
Microsoft Corporation
Ulrich Homann
Microsoft Corporation
适用于：
Microsoft Visual Studio .NET
Microsoft BizTalk Server
摘要：通过使用通信协议的体系结构来建立企业交互，在企业及其合作伙伴之间创建更健壮、更有效的交互。
本页内容
在本文中，我们将论证今天的企业对企业 (B2B) 通信自动化方式是造成电子商务无法实现真正突破的主要障碍。首先，仅有数据不足以在交互的参与者之间清楚地交流所期望的信息 - 即指定协约。通过向企业服务规范添加过程说明，新涌现的标准已在正确的方向上取得了进步，但是，甚至在对单个交互的合适说明之上假设协约，第二个问题也会很快出现：在企业及其合作伙伴之间组织 很多交互。要解决这些问题并提高企业交互的自动程度，我们建议将通信协议的体系结构应用于企业交互。该体系结构代表了一种已在网络通信中成功应用的解决协约 和组织 问题的方式。
该方式解决了协约和组织问题：
•
为了解决协约问题，协议指定了通信规则。
•
为了解决组织问题，这种分层的体系结构"分割并征服"了复杂的交互，使之成为单独但连接的会话。
简介
在最近 10 年里，供应链运动（从瘦制造模式到六西格马质量管理）方兴未艾，成为全球企业管理人员重点关注的目标。
图 1. 供应链管理运动的发展过程
这些运动反映了跨越行业、公司规模和位置的普遍趋势：
•
市场需求推动公司向协作网络发展，在这样的网络中，每个公司专注于自己的核心竞争力。有两个常见方式来实现这样的专注：
•
将供应商作为伙伴集成到价值链中。
•
将非核心但必需的企业能力（例如工资册）外包给企业过程服务提供商。
•
作出巨大的努力（像上面的供应链示例一样）将价值链伙伴和服务提供商深入集成到相互连接和组织化的单位中。本质上，就是要形成虚拟组织。
有了内部和外部合作伙伴之间的关系所产生的密度、复杂性和可变性，很显然，简单、线性的方法不足以解决这些复杂、烦乱的结构和过程。
例如，电子数据交换 (EDI) 等只是组织和传输打包为企业文档的信息。客户关系的上下文、关联的功能和过程则不是该标准的组成部分。像 RosettaNet 这样的活动已在该基本方法上进行了改进，例如，为几种企业情况定义了简单的合作伙伴接口过程。虽然标准文档和合作伙伴接口对于解决交互的难题是必需的，但它们不足以完全提供所需的解决方案。
需要做什么呢？我们如何创建能够处理具有个性化、多样性和复杂性要求的环境，而不会导致对底线造成进一步压力的集成和交互成本发生迅速增长？我们如何捕获合作伙伴网络中所有角色不断增长的自动化、交互和通信能力，从而创造市场化的价值？
Web 服务技术 (http://msdn.microsoft.com/webservices/) 和面向服务的体系结构（即 SOA，http://msdn.microsoft.com/library/en-us/dnea/html/EaAppConServices.asp）为开发可支持丰富和自动化交互的环境提供了坚实的技术基础。但是，还有一些其他方法可以支持交互结构架构师和设计人员完成为上述问题提供解决方案这一艰巨的任务。我们认为，B2B 环境中的通信所面对的问题的性质类似于网络通信系统的设计人员所面对的问题；因此，我们将协议体系结构的原则应用于企业交互。该方法的基石首先是为 B2B 交互定义的协约，其次是组织大量这类交互的方法。
期望值交流障碍
几乎所有 B2B 工作所存在的一个主要问题是：现有方法无法清楚地交流参与者之间的期待信息。EDI 模型（及其专门面向数据的关注）已经成为大多数 B2B 工作的主要模型。最近的活动或多或少只是使用新的 Internet 技术将一个格式 (EDI) 替换为另一个格式。虽然向标准技术（主要是 XML）的发展减少了数据处理所涉及的成本，但这只是第一步。
对于使用现有的、以数据为中心的格式在企业之间建立通信，其复杂性的非正式衡量手段是 AribacXML（例如，参阅 cXML 1.2）的用户文档、购买定单 (PO) 和相关文档。文档为以下基本问题提供了答案："PO 的含义是什么？是给我的吗？是给我的合作伙伴的吗？是为交易中所涉及的其他要素？"描述与这些业务文档（您必须了解才能成功使用该标准）相关的交互需要使用大约 100 页打印纸。
该示例显示，描述 PO 这一看起来很简单的任务其实并不简单。为了成功地进行交流，所有相关各方必须了解至少以下几点：
•
交互的目的：以某个价格、数量和日期时间购买或出售（取决于视角）产品。
•
关于角色和通信信道的假设：谁出售？谁购买？消息如何以及何时到达？是否需要加密？
•
词汇：构成会话的消息是什么？谁发送和接收消息？使用什么语言？会话是否使用特定标准（例如 cXML）？
•
消息格式：消息如何编码？必需的具体消息头和详细信息是什么？
•
通信规则：我期望什么时候得到初始请求的答案？正确的答案集是什么？
很明显，顾客和供应商必须了解和尊重这些期待才能成功完成交互。此外，该交易中可能涉及的其他各方（例如，后勤提供商）必须有相同的理解才能在正确的日期和时间完成交易。更糟糕的是，不仅所有相关各方必须首先阅读文档，他们还必须从文档得到相同的结论，然后以兼容的方式将它们应用到各自的电子数据交易系统。
现有 B2B 通信系统无法以系统方式识别这种扩展的协约定义。它们的作用范围局限于对编码和词汇的定义，并依赖于特别的协约、非正式的文档和其他方式，从而最终影响合作伙伴的实现之间的通信。这就产生了倾向复杂、冗长和错误的集成项目，因为人工解释构成了自动化的基础。
杂乱的 Web 交互
实际的企业交互是由很多这样的单独协约构成的。图 2 显示供应链合作伙伴之间的申诉交互。可以看出，只指定用于控制单个交互的协约（在图 2 中间展开的视图仅仅显示了这种交互的一小部分）只是问题的一小部分。通常，必需的、可用的或所希望的业务功能和它们的关联过程是复杂、不清楚和不透明的。
此外，一定要注意到图片只表现了申诉管理的单个 客户/供应商集成图，而没有 与供应商的（或客户的）关联企业功能和系统进行必需的集成。B2B 交互不仅复杂，而且还非常不标准。这些过程反映了合作伙伴之间变化的和单独的关系 (Hammer, M.; Champy, J.:Reengineering the Cooperation; Harper Collins Publishers; New York; 1993; Chapter III)，包括通过个性化客户服务在这些关系中创建价值的活动。因此，除了围绕单个交互指定协约以外，还必须处理管理无数这种交互的复杂性。
图 2. 在项目之前单个供应商/客户的 cc 交互
显然，我们需要某些方法来抽象和管理这些交互。这需要在操作而不仅是数据方面使单独的过程变得透明。大多数当前的方法并非如此。
将协议体系结构应用于 B2B
一开始，网络通信社区面对类似的问题：迅速增加的终结点数，以及不断增长的功能需求。两个核心问题是终结点之间的互操作性，以及对支持丰富功能所需的很多交互类型有意义的整个体系结构组织。这些问题的答案是：
•
使互操作性所需的协约正式化的网络协议模型。
•
建立通信服务模型和分层体系结构，使很多网络协议的功能相关，并产生一个整体，而不仅仅是其各个部分的汇总。
在以下各节中，我们将把这些概念应用于 B2B 交互。
协约
Gerard J. Holzmann 在他的 Design and Validation of Computer Protocols （1991 年出版，Prentice Hall 软件系列，ISBN：0-13-539925-4）一书中将协议定义为"在分布式系统中用于控制并发过程的交互的规则集合"。
我们将使用简单的申诉管理示例来说明 B2B 交易在协议设计方面的确是个问题，并说明为了使 B2B 向前发展企业和协议需要连接的理由。图 3 显示了简化的客户申诉事务的图片（从图 2 展开的视图）。协议控制完成事务所需的每个交互（申诉处理、管理质量提高、信任顾客等等）。
图 3. 简单的申诉管理交互（从图 2 展开）
为了解决有缺陷的交货问题，客户必须通过提供与有缺陷的商品、相关的购买定单、问题的优先级和其他细节有关的详细信息，将他的申诉告诉供应商。而供应商必须通过直接接受或拒绝申诉来对该申诉请求作出响应。另外，供应商可以在对申诉作出任何明确决定之前通过请求其他信息来启动研究。显然：
•
每次用满足所讨论的需求的答案（可能由类似图 3 中所概括的多个响应组成）来响应具体请求时，实体双方将相互交互。
•
交互并发地 移动（每个实体作出自己的决定，但通常与在前面收到的事件相关），直到最后做出决定。
•
交互是分布式 的。
•
交互是由一系列指向特定目标的操作所组成的过程。
最后建立了满足 Holzmann 所提供的协议定义的 B2B 交互以后，我们需要考查该方式的详细信息，以及它的结果和对 B2B 交互的好处。
协议元素
既然我们了解企业交互，让我们开始以一种能够被自动化系统进行处理的方式更精确地收集描述交互所需要的所有元素。
注 Holzmann 在其规范的定义中包括了对协议所提供服务的定义。我们将在"组织"一节中再讨论这个关键的方面。
非正式地说，上述交互读作"客户向企业发送申诉。企业在收到申诉时承认该请求。取决于申诉的优先级，企业有 24 到 72 个小时的时间来解决申诉。"
与环境有关的假设
示例的"环境"由申诉管理服务的两个用户以及一个传输信道组成。可以假设用户只是提交申诉，并等待它得到确认。假设传输信道不会丢失、复制、插入或重新排序消息。
协议词汇
协议词汇定义了在给定交换中允许的消息。在我们的示例中，有六个明显不同的消息类型：
•
COMPLAINT 表示带有操作请求的消息。
•
ACK 表示与对 COMPLAINT 的肯定答复组合在一起的消息。
•
ACCEPTANCE 表示包含对 COMPLAINT 的肯定或否定的确认的消息。
•
如果供应商没有在给定的时间框架内作出回答，则客户发出 DUNNING。
•
INFORMATION REQUEST 表示请求更多信息
•
INFORMATION 表示客户对 INFORMATION REQUEST 作出回答。
消息格式
合作伙伴之间对协约的消息所采用的编码标准（EDI，XML）达成一致是很重要的。注意，交互的词汇（UN/EDIFACT，http://www.unece.org/trade/untdid/welcome.htm；cXML，http://www.cxml.org/）与编码是完全无关的。实际上，保持双方的独立是很关键的，因为相似企业情况的其他环境可能需要不同的实现。
过程规则
规则权威性地定义了为指导行为或操作而提出的原则。甚至我们的简单示例也需要若干组需要双方以共同方式理解的规则，这样才能成功结束希望的企业事务。通过将这些规则正式化，可以让我们对交互进行抽象，然后自动执行它。
事件和序列
首先，必须了解传入的请求以及可能或正确的响应。然后，必须定义事件序列，以便用正确的响应回答发出请求的事件。可以对任何特定事件描述多个有效的回答，但答案必须是预定义的有效回答集合的一部分。对于受支持的序列集合，双方都必须拥有相同的完整理解，这样通信才能成功。
数据
在任何给定的交互中，事件都是高级别、可确认的过程。通常，每个事件都有与之关联的数据，数据携带交互所需的细节。现在，该数据通常格式化为 XML 消息。注意，这些细节的某些部分有时会影响行为。例如，在申诉交互中，priority 字段通常是申诉数据的一部分。这个简单的数字字段描述了来自客户的期待：我收到了使我无法生产的有缺陷商品。请及时并无条件地对该情况采取补救措施。为了保持成功的商业关系，供应商必须了解和尊重该期待。
限制
简单的遵循规定的事件序列将不会为各方提供足够的细节来成功地完成业务。在大多数业务情况下（与我们的申诉示例一样），必须在定义的间隔内作出正确的响应。如果在协约所指定的时间间隔内没有对最初的申诉消息作出反应，则可能出现严重的经济和商业关系后果。注意，不像我们的简单示例，完整和正确的申诉管理过程必须描述处理过程的例外。
相关性
可能会有数百个事件在任何给定时刻到达，需要系统加以处理。问题是，"哪个事件与哪个过程关联？"上面的示例使用申诉跟踪数字作为查找正在管理特定申诉的申诉过程的数据。类似情况是，将引用数字包括在正常的业务通信中。如果仔细审阅图 3 所示的交互模式，这一部分协议设计的目的是将含义（或者也许更好的用词是上下文）添加到单个消息上，并为交互提供端到端的视图。该视图允许双方了解成功的交互所需的期待，并相应地做好准备。
相关性的重点只放在使正确的请求与正确的业务过程匹配上。在该级别没有聚合。
申诉交互的过程规则
该示例交互的过程规则很简单。在为上述规则建立的元素后面，协议如下所示：
交互由下列内容组成：三个必需的事件 (E)、三个可选的事件 (E) 和三个限制 (C)，这里"c"是客户，"s"是供应商：
•
E：(c) 将 COMPLAINT 发送给 (s)。
•
E：(s) 向 (c) 承认 (ACK) 收到申诉消息。
•
C：(s) 在收到消息后立即向 (c) 承认申诉。
•
E：(c) 可以向 (s) 发送 DUNNING 提醒消息。
•
C：(s) 没有在所需期限内响应 (c)。
•
E：(b) 可以从 (c) 请求 INFORMATION。
•
E：(c) 如果 INFORMATION 请求已经发送，则 (c) 必须用所请求的 INFORMATION 对 (s) 作出响应。
•
E：(s) 必须向 (c) 发出 CONFIRM（接受或拒绝申诉）。
•
C：(s) 必须在取决于优先级的期限内接受或拒绝申诉。
组织
既然我们已经看到如何围绕协约解决问题，那么问题是如何封装交互并创建抽象，我们可以操作这样的抽象来生成细致但可管理的系统，从而处理很多这样的交互。
描述交互模式是业务协议设计的重要组成部分，并且完全足以作为规定来改善单个业务活动的执行（例如，"CC 处理"）。但是，"CC 处理"活动本身不会成功地解决申诉。除了启动申诉（"CC 处理"活动中对此进行了说明）以外，解决申诉需要提高质量管理（例如，培训供应商雇员、修复有缺陷的机器）并交换信用注意信息。图 4 概括了解决单个申诉所需要的一组其他业务活动：
图 4. 申诉管理系统的单个服务
在该图中，"CC 处理"服务依赖于进一步的活动（即质量管理和信用管理）以实现全部处理。但是，用解决方案过程来超载由"CC 处理"服务表示的申诉启动是没有意义的，因为这些过程可以基于申诉、合作伙伴或地理上的临近而有所不同。对这些过程进行分解（按图 4 的建议）有业务和技术上的意义，因为它考虑到了灵活性和可扩展性。
但是，如图所示，涉及"CC 处理"的交互是独立的，并且与组成申诉解决办法的其他任何服务无关。我们如何在单个、独立的交互与实际上允许合作伙伴执行业务的、充分完善的业务交互之间架起桥梁？
关键在于将各段聚合成一个有用 的整体。通常，这需要共享或相关的标识符（比如唯一的申诉号），以及对业务交互实际状态的整体理解。就是说，申诉必须在质量管理或信用服务甚至是相关的之前被承认或拒绝。在我们看到如何对申诉管理示例这样做之前，我们将首先描述如何有效地使用服务的概念来封装交互。
通信服务
通常，服务为具体的问题提供业务逻辑和状态管理（有关服务的概述，请访问 http://msdn.microsoft.comlibrary/en-us/dnea/html/EaAppConServices.asp）。好的服务应当基于对包括什么和实现什么作为单独的服务（组织）所作出的明智选择，有效地封装与真实的过程（协约）关联的逻辑和数据。对于 B2B 交互来说，使服务基于协议是这样做的有意义的方式。
网络体系结构的中心概念是通信服务。例如，这些服务提供有用的功能（例如，向分布式的通信各方传递双向、可靠的字节流，即传输控制协议 (TCP)）。
图 5. 通信服务
在良好的工程形式中，通信服务隐藏了用于提供它们所提供的功能的通常很复杂的内部工作机制，这是因为在面向对象编程 (OOP) 中的对象有方法。您不需要了解方法如何工作来调用它。
以传输控制协议 (TCP) 和文件传输协议 (FTP) 为例。它们的通信服务抽象是对网络协议进行全面分层组织的要点。这样的组织让您可以创建更高级别的服务，若以其他方式，则这些服务需要管理一组不可能很复杂的交互。例如，FTP 服务层位于 TCP 所提供的、可靠的字节流传递服务之上。这就允许 FTP 参与有关文件传输的会话，而不用担心如何管理有序数据传递以及所有其他琐碎的细节。如图 6 所示，该 FTP 会话当然是虚拟的，因为实际的通信路径需要通过 TCP。
图 6. 分层的体系结构允许在更高级别实现虚拟通信
在文章的其余部分，以我们的申诉管理为例，我们讨论了如何将类似的全面组织化结构应用于企业交互。在这种情况下，合作伙伴之间的全面申诉过程被抽象为高级别的交互，以管理整个申诉生命周期。该交互受三个管理支持过程的服务的支持：初始申诉、质量改进和信用，如图 7 所示。
图 7. 应用于客户申诉示例的分层体系结构
分层/复合结构
在给定的组织中，一旦识别了交互及其关联各项所需的业务能力，就可以构造它们并以文档描述它们的层次结构。这为透明化提供了需要的基础，以便可以抽象通用功能，并将通用功能隔绝在可交换的层中。图 8 以客户申诉情形为例，显示了这种结构化映射的高度抽象示例：
图 8. 客户申诉情形的高级别视图
在我们的示例中，结构以 Customer Complaint 系统的形式出现，该系统被组织为可为客户和供应商之间的申诉提供解决方案的服务。Customer Complaint 服务本身是通过初始处理、质量管理和财务补偿来管理申诉的复合实体。这些功能中的每一个分别由服务提供。整体效果是在系统的组件之间获得更好的交互因子分解。例如，质量管理服务现在封装了所有详细的 QM 交互，并允许它们有所变化（例如，可以将 ISO 过程替换为六西格马过程）而不会影响系统的其余部分。
还可以在该结构中很容易地识别传统的网络通信系统组织，在该组织中非常复杂的交互被作为分层服务进行管理。与 TCP 向 HTTP 提供可靠的基于流的通信同样类似的是，QM 服务向申诉服务提供质量管理，而不用显示（在该作用范围内）杂乱和不相关的细节。注意图 8 和图 7 之间的相似性。
将申诉系统上的该视图与图 2 中的视图进行对照也具有指导意义，在图 2 的视图中，通过提供两个主要角色（客户和供应商公司）之间非常复杂的交互这种方式，对系统进行因子分解。这里我们已经引入了额外的角色（即申诉服务），所得到的是封装很多交互复杂性的实际好处。
B2B 交互采用协议方式的好处
将示例交互映射到协议定义之后明显体现的优点：
•
为（更）完整和明确地描述 B2B 交互提供了框架：经验性证据（主要基于查阅现有的 EDI 实现）显示，单独基于数据的交互不足以为自动进行业务通信提供坚实和清晰的基础。具体来说，这样的情况不包括异常处理。与此形成对照的是，协议设计强制对以可靠方式进行通信所需要的所有元素进行文档记录。实际上，协议说明为系统自动执行交互提供了基础。传输控制协议/Internet 协议 (TCP/IP) 允许在全球网络内的匿名节点之间进行可靠和普遍被理解的二进制数据传输，这并不需要复杂的集成项目，只需要遵守一组良好定义和被认同的规则。同样，业务协议将构成健壮的 B2B 通信的基础。一旦存在这样的框架，我们就可以使用它来：
•
设计可实现参与合作伙伴的业务目标的有效交互。
•
与合作伙伴共享这些交互的定义。
•
将定义用于与其他过程的有效集成。
•
有效地实现这些交互。
•
确定所需功能：遵守协议设计的规定，具体来说就是将所有所需的元素以显式方式用文档记录在机器可处理的位置，这将允许参与处理的系统动态确定所需的功能，并报告丢失的功能。
•
对所需输入/输出内容的机器可验证性：通过理解所应用协议的需求，软件就可以确定输入/输出是否满足所概括的限制条件，并且可以进行纠正操作。
小结
Web 服务技术（例如，XML、SOAP、BPEL4WS）和产品（比如 Microsoft?Visual Studio?.NET 和 Microsoft?BizTalk?Server 2004）为在合作伙伴之间实现丰富的交互提供了功能强大并且价格适中的工具。这些技术和工具与面向服务的体系结构原理组合在一起，构成了良好的软件设计的基础。
但是，正如在注重通信的其他领域中显示的一样，为实现自动化而设计交互是一项复杂和容易犯错误的冒险。通过从通信服务设计中吸取经验，并使用本文所概括的协议设计的原则，交互结构架构师可以更有效地使用 Web 服务技术和 SOA。
将这些要素集合在一起，基于对给定交互的所有方面进行清晰地标识和封装、对这些协议加以组织并通过服务进行正确的分割，协约将：
•
允许对更改作出更快的反应。
•
限制更改的作用范围。
•
允许合作伙伴自定义交互的某些方面。
关于作者
在过去的五年里，Marc Levy 一直从事业务过程自动化方面的研究。作为 BizTalk 团队的架构师，他是实现协调功能的重要负责人。参与 BizTalk 之前，Marc 负责 COM+ 安全性（参与撰写"Designing Secure Web-Based Applications for Microsoft Windows 2000"）。Marc 对分布式系统的热情是从九十年代初开始的开放式软件基础 (OSF) 和分布式计算环境 (DCE) 的统一主题。
作为解决方案架构师，Ulrich Homann 负责 Web 服务的设计和体系结构，以及 .NET 平台与业务应用程序的提供商和使用者的集成。后一项责任需要他参与关键合作伙伴和策略的客户项目并与它们密切交互，从而深入地洞察各个所影响的产品组。这还需要大量的旅行预算……
以前，Uli 是企业程序管理团队的程序经理，并负责开发与关键合作伙伴（主要是 SAP AG）的关系。Uli 还参加过 Microsoft Consulting Services，当时，他在德国负责过几个关键的分布式数据库应用程序项目。
Uli 于 1991 年加入 Microsoft，此前他为几个小咨询公司设计和开发分布式系统。
Uli 在系统行业有超过 15 年的经验。他的大部分职业时间都花在使用良好定义的应用程序和体系结构来简化业务应用程序的开发并使之顺畅运行。他对通过与客户及其应用程序密切配合来提高产品计划性充满热情，这驱使他对这项追求不断作出贡献。
_xyz
Marc Levy
Microsoft Corporation
Ulrich Homann
Microsoft Corporation
适用于：
Microsoft Visual Studio .NET
Microsoft BizTalk Server
摘要：通过使用通信协议的体系结构来建立企业交互，在企业及其合作伙伴之间创建更健壮、更有效的交互。
本页内容
在本文中，我们将论证今天的企业对企业 (B2B) 通信自动化方式是造成电子商务无法实现真正突破的主要障碍。首先，仅有数据不足以在交互的参与者之间清楚地交流所期望的信息 - 即指定协约。通过向企业服务规范添加过程说明，新涌现的标准已在正确的方向上取得了进步，但是，甚至在对单个交互的合适说明之上假设协约，第二个问题也会很快出现：在企业及其合作伙伴之间组织 很多交互。要解决这些问题并提高企业交互的自动程度，我们建议将通信协议的体系结构应用于企业交互。该体系结构代表了一种已在网络通信中成功应用的解决协约 和组织 问题的方式。
该方式解决了协约和组织问题：
•
为了解决协约问题，协议指定了通信规则。
•
为了解决组织问题，这种分层的体系结构"分割并征服"了复杂的交互，使之成为单独但连接的会话。
简介
在最近 10 年里，供应链运动（从瘦制造模式到六西格马质量管理）方兴未艾，成为全球企业管理人员重点关注的目标。
图 1. 供应链管理运动的发展过程
这些运动反映了跨越行业、公司规模和位置的普遍趋势：
•
市场需求推动公司向协作网络发展，在这样的网络中，每个公司专注于自己的核心竞争力。有两个常见方式来实现这样的专注：
•
将供应商作为伙伴集成到价值链中。
•
将非核心但必需的企业能力（例如工资册）外包给企业过程服务提供商。
•
作出巨大的努力（像上面的供应链示例一样）将价值链伙伴和服务提供商深入集成到相互连接和组织化的单位中。本质上，就是要形成虚拟组织。
有了内部和外部合作伙伴之间的关系所产生的密度、复杂性和可变性，很显然，简单、线性的方法不足以解决这些复杂、烦乱的结构和过程。
例如，电子数据交换 (EDI) 等只是组织和传输打包为企业文档的信息。客户关系的上下文、关联的功能和过程则不是该标准的组成部分。像 RosettaNet 这样的活动已在该基本方法上进行了改进，例如，为几种企业情况定义了简单的合作伙伴接口过程。虽然标准文档和合作伙伴接口对于解决交互的难题是必需的，但它们不足以完全提供所需的解决方案。
需要做什么呢？我们如何创建能够处理具有个性化、多样性和复杂性要求的环境，而不会导致对底线造成进一步压力的集成和交互成本发生迅速增长？我们如何捕获合作伙伴网络中所有角色不断增长的自动化、交互和通信能力，从而创造市场化的价值？
Web 服务技术 (http://msdn.microsoft.com/webservices/) 和面向服务的体系结构（即 SOA，http://msdn.microsoft.com/library/en-us/dnea/html/EaAppConServices.asp）为开发可支持丰富和自动化交互的环境提供了坚实的技术基础。但是，还有一些其他方法可以支持交互结构架构师和设计人员完成为上述问题提供解决方案这一艰巨的任务。我们认为，B2B 环境中的通信所面对的问题的性质类似于网络通信系统的设计人员所面对的问题；因此，我们将协议体系结构的原则应用于企业交互。该方法的基石首先是为 B2B 交互定义的协约，其次是组织大量这类交互的方法。
期望值交流障碍
几乎所有 B2B 工作所存在的一个主要问题是：现有方法无法清楚地交流参与者之间的期待信息。EDI 模型（及其专门面向数据的关注）已经成为大多数 B2B 工作的主要模型。最近的活动或多或少只是使用新的 Internet 技术将一个格式 (EDI) 替换为另一个格式。虽然向标准技术（主要是 XML）的发展减少了数据处理所涉及的成本，但这只是第一步。
对于使用现有的、以数据为中心的格式在企业之间建立通信，其复杂性的非正式衡量手段是 AribacXML（例如，参阅 cXML 1.2）的用户文档、购买定单 (PO) 和相关文档。文档为以下基本问题提供了答案："PO 的含义是什么？是给我的吗？是给我的合作伙伴的吗？是为交易中所涉及的其他要素？"描述与这些业务文档（您必须了解才能成功使用该标准）相关的交互需要使用大约 100 页打印纸。
该示例显示，描述 PO 这一看起来很简单的任务其实并不简单。为了成功地进行交流，所有相关各方必须了解至少以下几点：
•
交互的目的：以某个价格、数量和日期时间购买或出售（取决于视角）产品。
•
关于角色和通信信道的假设：谁出售？谁购买？消息如何以及何时到达？是否需要加密？
•
词汇：构成会话的消息是什么？谁发送和接收消息？使用什么语言？会话是否使用特定标准（例如 cXML）？
•
消息格式：消息如何编码？必需的具体消息头和详细信息是什么？
•
通信规则：我期望什么时候得到初始请求的答案？正确的答案集是什么？
很明显，顾客和供应商必须了解和尊重这些期待才能成功完成交互。此外，该交易中可能涉及的其他各方（例如，后勤提供商）必须有相同的理解才能在正确的日期和时间完成交易。更糟糕的是，不仅所有相关各方必须首先阅读文档，他们还必须从文档得到相同的结论，然后以兼容的方式将它们应用到各自的电子数据交易系统。
现有 B2B 通信系统无法以系统方式识别这种扩展的协约定义。它们的作用范围局限于对编码和词汇的定义，并依赖于特别的协约、非正式的文档和其他方式，从而最终影响合作伙伴的实现之间的通信。这就产生了倾向复杂、冗长和错误的集成项目，因为人工解释构成了自动化的基础。
杂乱的 Web 交互
实际的企业交互是由很多这样的单独协约构成的。图 2 显示供应链合作伙伴之间的申诉交互。可以看出，只指定用于控制单个交互的协约（在图 2 中间展开的视图仅仅显示了这种交互的一小部分）只是问题的一小部分。通常，必需的、可用的或所希望的业务功能和它们的关联过程是复杂、不清楚和不透明的。
此外，一定要注意到图片只表现了申诉管理的单个 客户/供应商集成图，而没有 与供应商的（或客户的）关联企业功能和系统进行必需的集成。B2B 交互不仅复杂，而且还非常不标准。这些过程反映了合作伙伴之间变化的和单独的关系 (Hammer, M.; Champy, J.:Reengineering the Cooperation; Harper Collins Publishers; New York; 1993; Chapter III)，包括通过个性化客户服务在这些关系中创建价值的活动。因此，除了围绕单个交互指定协约以外，还必须处理管理无数这种交互的复杂性。
图 2. 在项目之前单个供应商/客户的 cc 交互
显然，我们需要某些方法来抽象和管理这些交互。这需要在操作而不仅是数据方面使单独的过程变得透明。大多数当前的方法并非如此。
将协议体系结构应用于 B2B
一开始，网络通信社区面对类似的问题：迅速增加的终结点数，以及不断增长的功能需求。两个核心问题是终结点之间的互操作性，以及对支持丰富功能所需的很多交互类型有意义的整个体系结构组织。这些问题的答案是：
•
使互操作性所需的协约正式化的网络协议模型。
•
建立通信服务模型和分层体系结构，使很多网络协议的功能相关，并产生一个整体，而不仅仅是其各个部分的汇总。
在以下各节中，我们将把这些概念应用于 B2B 交互。
协约
Gerard J. Holzmann 在他的 Design and Validation of Computer Protocols （1991 年出版，Prentice Hall 软件系列，ISBN：0-13-539925-4）一书中将协议定义为"在分布式系统中用于控制并发过程的交互的规则集合"。
我们将使用简单的申诉管理示例来说明 B2B 交易在协议设计方面的确是个问题，并说明为了使 B2B 向前发展企业和协议需要连接的理由。图 3 显示了简化的客户申诉事务的图片（从图 2 展开的视图）。协议控制完成事务所需的每个交互（申诉处理、管理质量提高、信任顾客等等）。
图 3. 简单的申诉管理交互（从图 2 展开）
为了解决有缺陷的交货问题，客户必须通过提供与有缺陷的商品、相关的购买定单、问题的优先级和其他细节有关的详细信息，将他的申诉告诉供应商。而供应商必须通过直接接受或拒绝申诉来对该申诉请求作出响应。另外，供应商可以在对申诉作出任何明确决定之前通过请求其他信息来启动研究。显然：
•
每次用满足所讨论的需求的答案（可能由类似图 3 中所概括的多个响应组成）来响应具体请求时，实体双方将相互交互。
•
交互并发地 移动（每个实体作出自己的决定，但通常与在前面收到的事件相关），直到最后做出决定。
•
交互是分布式 的。
•
交互是由一系列指向特定目标的操作所组成的过程。
最后建立了满足 Holzmann 所提供的协议定义的 B2B 交互以后，我们需要考查该方式的详细信息，以及它的结果和对 B2B 交互的好处。
协议元素
既然我们了解企业交互，让我们开始以一种能够被自动化系统进行处理的方式更精确地收集描述交互所需要的所有元素。
注 Holzmann 在其规范的定义中包括了对协议所提供服务的定义。我们将在"组织"一节中再讨论这个关键的方面。
非正式地说，上述交互读作"客户向企业发送申诉。企业在收到申诉时承认该请求。取决于申诉的优先级，企业有 24 到 72 个小时的时间来解决申诉。"
与环境有关的假设
示例的"环境"由申诉管理服务的两个用户以及一个传输信道组成。可以假设用户只是提交申诉，并等待它得到确认。假设传输信道不会丢失、复制、插入或重新排序消息。
协议词汇
协议词汇定义了在给定交换中允许的消息。在我们的示例中，有六个明显不同的消息类型：
•
COMPLAINT 表示带有操作请求的消息。
•
ACK 表示与对 COMPLAINT 的肯定答复组合在一起的消息。
•
ACCEPTANCE 表示包含对 COMPLAINT 的肯定或否定的确认的消息。
•
如果供应商没有在给定的时间框架内作出回答，则客户发出 DUNNING。
•
INFORMATION REQUEST 表示请求更多信息
•
INFORMATION 表示客户对 INFORMATION REQUEST 作出回答。
消息格式
合作伙伴之间对协约的消息所采用的编码标准（EDI，XML）达成一致是很重要的。注意，交互的词汇（UN/EDIFACT，http://www.unece.org/trade/untdid/welcome.htm；cXML，http://www.cxml.org/）与编码是完全无关的。实际上，保持双方的独立是很关键的，因为相似企业情况的其他环境可能需要不同的实现。
过程规则
规则权威性地定义了为指导行为或操作而提出的原则。甚至我们的简单示例也需要若干组需要双方以共同方式理解的规则，这样才能成功结束希望的企业事务。通过将这些规则正式化，可以让我们对交互进行抽象，然后自动执行它。
事件和序列
首先，必须了解传入的请求以及可能或正确的响应。然后，必须定义事件序列，以便用正确的响应回答发出请求的事件。可以对任何特定事件描述多个有效的回答，但答案必须是预定义的有效回答集合的一部分。对于受支持的序列集合，双方都必须拥有相同的完整理解，这样通信才能成功。
数据
在任何给定的交互中，事件都是高级别、可确认的过程。通常，每个事件都有与之关联的数据，数据携带交互所需的细节。现在，该数据通常格式化为 XML 消息。注意，这些细节的某些部分有时会影响行为。例如，在申诉交互中，priority 字段通常是申诉数据的一部分。这个简单的数字字段描述了来自客户的期待：我收到了使我无法生产的有缺陷商品。请及时并无条件地对该情况采取补救措施。为了保持成功的商业关系，供应商必须了解和尊重该期待。
限制
简单的遵循规定的事件序列将不会为各方提供足够的细节来成功地完成业务。在大多数业务情况下（与我们的申诉示例一样），必须在定义的间隔内作出正确的响应。如果在协约所指定的时间间隔内没有对最初的申诉消息作出反应，则可能出现严重的经济和商业关系后果。注意，不像我们的简单示例，完整和正确的申诉管理过程必须描述处理过程的例外。
相关性
可能会有数百个事件在任何给定时刻到达，需要系统加以处理。问题是，"哪个事件与哪个过程关联？"上面的示例使用申诉跟踪数字作为查找正在管理特定申诉的申诉过程的数据。类似情况是，将引用数字包括在正常的业务通信中。如果仔细审阅图 3 所示的交互模式，这一部分协议设计的目的是将含义（或者也许更好的用词是上下文）添加到单个消息上，并为交互提供端到端的视图。该视图允许双方了解成功的交互所需的期待，并相应地做好准备。
相关性的重点只放在使正确的请求与正确的业务过程匹配上。在该级别没有聚合。
申诉交互的过程规则
该示例交互的过程规则很简单。在为上述规则建立的元素后面，协议如下所示：
交互由下列内容组成：三个必需的事件 (E)、三个可选的事件 (E) 和三个限制 (C)，这里"c"是客户，"s"是供应商：
•
E：(c) 将 COMPLAINT 发送给 (s)。
•
E：(s) 向 (c) 承认 (ACK) 收到申诉消息。
•
C：(s) 在收到消息后立即向 (c) 承认申诉。
•
E：(c) 可以向 (s) 发送 DUNNING 提醒消息。
•
C：(s) 没有在所需期限内响应 (c)。
•
E：(b) 可以从 (c) 请求 INFORMATION。
•
E：(c) 如果 INFORMATION 请求已经发送，则 (c) 必须用所请求的 INFORMATION 对 (s) 作出响应。
•
E：(s) 必须向 (c) 发出 CONFIRM（接受或拒绝申诉）。
•
C：(s) 必须在取决于优先级的期限内接受或拒绝申诉。
组织
既然我们已经看到如何围绕协约解决问题，那么问题是如何封装交互并创建抽象，我们可以操作这样的抽象来生成细致但可管理的系统，从而处理很多这样的交互。
描述交互模式是业务协议设计的重要组成部分，并且完全足以作为规定来改善单个业务活动的执行（例如，"CC 处理"）。但是，"CC 处理"活动本身不会成功地解决申诉。除了启动申诉（"CC 处理"活动中对此进行了说明）以外，解决申诉需要提高质量管理（例如，培训供应商雇员、修复有缺陷的机器）并交换信用注意信息。图 4 概括了解决单个申诉所需要的一组其他业务活动：
图 4. 申诉管理系统的单个服务
在该图中，"CC 处理"服务依赖于进一步的活动（即质量管理和信用管理）以实现全部处理。但是，用解决方案过程来超载由"CC 处理"服务表示的申诉启动是没有意义的，因为这些过程可以基于申诉、合作伙伴或地理上的临近而有所不同。对这些过程进行分解（按图 4 的建议）有业务和技术上的意义，因为它考虑到了灵活性和可扩展性。
但是，如图所示，涉及"CC 处理"的交互是独立的，并且与组成申诉解决办法的其他任何服务无关。我们如何在单个、独立的交互与实际上允许合作伙伴执行业务的、充分完善的业务交互之间架起桥梁？
关键在于将各段聚合成一个有用 的整体。通常，这需要共享或相关的标识符（比如唯一的申诉号），以及对业务交互实际状态的整体理解。就是说，申诉必须在质量管理或信用服务甚至是相关的之前被承认或拒绝。在我们看到如何对申诉管理示例这样做之前，我们将首先描述如何有效地使用服务的概念来封装交互。
通信服务
通常，服务为具体的问题提供业务逻辑和状态管理（有关服务的概述，请访问 http://msdn.microsoft.comlibrary/en-us/dnea/html/EaAppConServices.asp）。好的服务应当基于对包括什么和实现什么作为单独的服务（组织）所作出的明智选择，有效地封装与真实的过程（协约）关联的逻辑和数据。对于 B2B 交互来说，使服务基于协议是这样做的有意义的方式。
网络体系结构的中心概念是通信服务。例如，这些服务提供有用的功能（例如，向分布式的通信各方传递双向、可靠的字节流，即传输控制协议 (TCP)）。
图 5. 通信服务
在良好的工程形式中，通信服务隐藏了用于提供它们所提供的功能的通常很复杂的内部工作机制，这是因为在面向对象编程 (OOP) 中的对象有方法。您不需要了解方法如何工作来调用它。
以传输控制协议 (TCP) 和文件传输协议 (FTP) 为例。它们的通信服务抽象是对网络协议进行全面分层组织的要点。这样的组织让您可以创建更高级别的服务，若以其他方式，则这些服务需要管理一组不可能很复杂的交互。例如，FTP 服务层位于 TCP 所提供的、可靠的字节流传递服务之上。这就允许 FTP 参与有关文件传输的会话，而不用担心如何管理有序数据传递以及所有其他琐碎的细节。如图 6 所示，该 FTP 会话当然是虚拟的，因为实际的通信路径需要通过 TCP。
图 6. 分层的体系结构允许在更高级别实现虚拟通信
在文章的其余部分，以我们的申诉管理为例，我们讨论了如何将类似的全面组织化结构应用于企业交互。在这种情况下，合作伙伴之间的全面申诉过程被抽象为高级别的交互，以管理整个申诉生命周期。该交互受三个管理支持过程的服务的支持：初始申诉、质量改进和信用，如图 7 所示。
图 7. 应用于客户申诉示例的分层体系结构
分层/复合结构
在给定的组织中，一旦识别了交互及其关联各项所需的业务能力，就可以构造它们并以文档描述它们的层次结构。这为透明化提供了需要的基础，以便可以抽象通用功能，并将通用功能隔绝在可交换的层中。图 8 以客户申诉情形为例，显示了这种结构化映射的高度抽象示例：
图 8. 客户申诉情形的高级别视图
在我们的示例中，结构以 Customer Complaint 系统的形式出现，该系统被组织为可为客户和供应商之间的申诉提供解决方案的服务。Customer Complaint 服务本身是通过初始处理、质量管理和财务补偿来管理申诉的复合实体。这些功能中的每一个分别由服务提供。整体效果是在系统的组件之间获得更好的交互因子分解。例如，质量管理服务现在封装了所有详细的 QM 交互，并允许它们有所变化（例如，可以将 ISO 过程替换为六西格马过程）而不会影响系统的其余部分。
还可以在该结构中很容易地识别传统的网络通信系统组织，在该组织中非常复杂的交互被作为分层服务进行管理。与 TCP 向 HTTP 提供可靠的基于流的通信同样类似的是，QM 服务向申诉服务提供质量管理，而不用显示（在该作用范围内）杂乱和不相关的细节。注意图 8 和图 7 之间的相似性。
将申诉系统上的该视图与图 2 中的视图进行对照也具有指导意义，在图 2 的视图中，通过提供两个主要角色（客户和供应商公司）之间非常复杂的交互这种方式，对系统进行因子分解。这里我们已经引入了额外的角色（即申诉服务），所得到的是封装很多交互复杂性的实际好处。
B2B 交互采用协议方式的好处
将示例交互映射到协议定义之后明显体现的优点：
•
为（更）完整和明确地描述 B2B 交互提供了框架：经验性证据（主要基于查阅现有的 EDI 实现）显示，单独基于数据的交互不足以为自动进行业务通信提供坚实和清晰的基础。具体来说，这样的情况不包括异常处理。与此形成对照的是，协议设计强制对以可靠方式进行通信所需要的所有元素进行文档记录。实际上，协议说明为系统自动执行交互提供了基础。传输控制协议/Internet 协议 (TCP/IP) 允许在全球网络内的匿名节点之间进行可靠和普遍被理解的二进制数据传输，这并不需要复杂的集成项目，只需要遵守一组良好定义和被认同的规则。同样，业务协议将构成健壮的 B2B 通信的基础。一旦存在这样的框架，我们就可以使用它来：
•
设计可实现参与合作伙伴的业务目标的有效交互。
•
与合作伙伴共享这些交互的定义。
•
将定义用于与其他过程的有效集成。
•
有效地实现这些交互。
•
确定所需功能：遵守协议设计的规定，具体来说就是将所有所需的元素以显式方式用文档记录在机器可处理的位置，这将允许参与处理的系统动态确定所需的功能，并报告丢失的功能。
•
对所需输入/输出内容的机器可验证性：通过理解所应用协议的需求，软件就可以确定输入/输出是否满足所概括的限制条件，并且可以进行纠正操作。
小结
Web 服务技术（例如，XML、SOAP、BPEL4WS）和产品（比如 Microsoft?Visual Studio?.NET 和 Microsoft?BizTalk?Server 2004）为在合作伙伴之间实现丰富的交互提供了功能强大并且价格适中的工具。这些技术和工具与面向服务的体系结构原理组合在一起，构成了良好的软件设计的基础。
但是，正如在注重通信的其他领域中显示的一样，为实现自动化而设计交互是一项复杂和容易犯错误的冒险。通过从通信服务设计中吸取经验，并使用本文所概括的协议设计的原则，交互结构架构师可以更有效地使用 Web 服务技术和 SOA。
将这些要素集合在一起，基于对给定交互的所有方面进行清晰地标识和封装、对这些协议加以组织并通过服务进行正确的分割，协约将：
•
允许对更改作出更快的反应。
•
限制更改的作用范围。
•
允许合作伙伴自定义交互的某些方面。
关于作者
在过去的五年里，Marc Levy 一直从事业务过程自动化方面的研究。作为 BizTalk 团队的架构师，他是实现协调功能的重要负责人。参与 BizTalk 之前，Marc 负责 COM+ 安全性（参与撰写"Designing Secure Web-Based Applications for Microsoft Windows 2000"）。Marc 对分布式系统的热情是从九十年代初开始的开放式软件基础 (OSF) 和分布式计算环境 (DCE) 的统一主题。
作为解决方案架构师，Ulrich Homann 负责 Web 服务的设计和体系结构，以及 .NET 平台与业务应用程序的提供商和使用者的集成。后一项责任需要他参与关键合作伙伴和策略的客户项目并与它们密切交互，从而深入地洞察各个所影响的产品组。这还需要大量的旅行预算……
以前，Uli 是企业程序管理团队的程序经理，并负责开发与关键合作伙伴（主要是 SAP AG）的关系。Uli 还参加过 Microsoft Consulting Services，当时，他在德国负责过几个关键的分布式数据库应用程序项目。
Uli 于 1991 年加入 Microsoft，此前他为几个小咨询公司设计和开发分布式系统。
Uli 在系统行业有超过 15 年的经验。他的大部分职业时间都花在使用良好定义的应用程序和体系结构来简化业务应用程序的开发并使之顺畅运行。他对通过与客户及其应用程序密切配合来提高产品计划性充满热情，这驱使他对这项追求不断作出贡献。
_xyz