BizTalk Server 2006 Web 服务

BizTalk Server 2006 的构建基于一个灵活的消息传送子系统，该系统可改善异类应用程序之间联系松散的消息传送交互。消息传送层可提供许多集成的益处，如消息路由、架构变换和格式转换。消息传送层的核心是一个被称为 MessageBox 的 SQL Server™ 数据库。由消息传送层处理的所有消息都要经过 MessageBox，以进行路由选择、跟踪和错误的处理。MessageBox 的运行原则是“不在后台保留任何消息”，这一功能对于可靠性至上来说是非常关键的。但公平地讲，如果对性能要求更为重要，使用该功能也许会适得其反。

通过在 MessageBox 中定义消息订阅（也称为“筛选器”），可以控制消息在应用程序之间的传送方式。筛选器的定义可以在管理控制台上（发送端口上）进行，也可以通过定义逻辑端口在业务流程中间接进行定义。如图 1 所示，在发布消息时，MessageBox 根据订阅对传入消息进行评估，并将消息传送给所有匹配的订阅服务器（发送端口或业务流程）。这一发布/订阅体系结构使接收人与发送人完全分离。

图 1 BizTalk 消息传送体系结构 (单击该图像获得较小视图)

图 1 BizTalk 消息传送体系结构 (单击该图像获得较大视图)

BizTalk 与外界的交互是通过适配器来进行的。适配器采用特定的传输模式接收字节，并创建一个新的 BizTalk 消息，当接收管道和映射（XSLT 变换）有机会对传入消息执行操作后，该消息就会发布到 MessageBox（参见图 2）。反之传送传出消息也是如此。映射和发送管道有机会对传出消息执行操作后，适配器将生成的字节传送到传输模式。在 BizTalk 中，这些详细信息是通过发送和接收端口来进行配置的。

图 2  BizTalk 内部端口 (单击该图像获得较小视图)

图 2  BizTalk 内部端口 (单击该图像获得较大视图)

BizTalk 支持单向和双向端口。在接收端，您可以定义单项接收端口，仅接收消息而不返回任何内容。也可以定义请求-响应接收端口，在收到请求时将响应消息回发给呼叫方。同样，在发送端，您也可以定义单向端口或要求-响应端口。

BizTalk Server 2006 附带了多种可支持众多传输模式和协议的适配器，其中有几个是专为 SOAP 和 WS-* 而设计的。除了 SOAP 和 WS-* 外，BizTalk 还支持许多通讯机制，这是其最吸引人的特点之一。 对于那些必须在维持旧有应用程序和对新式服务进行投入二者之间权衡取舍的系统来说，这一点使 BizTalk 成为他们关注的焦点。

Web 服务适配器

BizTalk Server 2006 要与 SOAP 和 WS-* 集成，需要借助图 3 所列的彼此不同的 Web 服务适配器来实现。SOAP 适配器随 BizTalk Server 2004 及更高版本附带，可支持 WS-I Basic Profile 1.1 (BP 1.1) 消息。如果您需要支持 WS-* 协议，则必须借助市面提供的 WSE 适配器，或等待 BizTalk Server 2006 R2 版本中附带的 Windows Communication Foundation 适配器。

Microsoft 提供了一种 WSE 2.0 适配器，您可以从 microsoft.com/biztalk/evaluation/adapter/adapters/wse 下载使用。该 WSE 2.0 适配器可运行于 BizTalk Server 2004 和 BizTalk Server 2006 之上，尽管后者需要 SP1 版本。Microsoft 决定不推出 WSE 3.0 适配器，因为即将推出的 Windows Communication Foundation 适配器具有同样效果的功能。但是有很多第三方 WSE 3.0 适配器可供我们选择。

图 4 使用 Web 服务适配器 (单击该图像获得较小视图)

图 4 使用 Web 服务适配器 (单击该图像获得较大视图)

您可以从这些适配器中任选一款，用于在 BizTalk 中发送和接收 SOAP 消息。这些适配器可以配合单向或双向端口使用。例如，您可以使用 SOAP 适配器发送和接收符合 BP 1.1 的简单 SOAP 消息，也可以使用 WSE 2.0 适配器发送和接收按照 WS-Security、WS-Trust 和 WS-SecureConversation 规范加以保护的 SOAP 消息。

在接收端，处理 SOAP 和 WS-* 并将消息正文发布到 MessageBox 的任务统统由适配器负责。在图 4 中，ASMX 终结点从本质上看就是适配器。在运行时，ASMX 代码与 BizTalk 进行通讯，从配置数据库检索有关接收位置的详细信息，以便在发布期间可以使用已设置的接收管道和映射集。实际上您可以借助传统的 BizTalk 管道和映射对传入的 SOAP 消息进行预处理，这种功能强大的组合将为您的集成带来更多的可选方案。

BizTalk 要求所有基于 HTTP 的接收位置都要运行于独立的主机进程（例如 IIS），而不是由 BizTalk 托管的进程。这意味着 BizTalk 并未完全控制对 SOAP/HTTP 接收位置的配置。相反，它认为独立主机将控制各种 SOAP/HTTP 处理方面的细节。您还不得不编写（或者更好，自动生成）独立主机的应用程序代码。

通常是使用向导来生成要运行于独立主机的适配器的代码。但是您也不必非得使用向导，可以编写一个能够接受任何 SOAP 消息并将其发布到 BizTalk 中的通用 SOAP 端点。

另外您还可以使用图 3 所列的任意一款 Web 服务适配器，以将 BizTalk 消息从 MessageBox 发送到外部 Web 服务。只需定义一个发送端口（使用所列适配器之一），然后使用其提供的任意一种设置方式进行配置，以便能够传送传出的 SOAP 消息。

值得注意的是，这些操作可以直接在 BizTalk 中执行，而不必借助业务流程。当然，您也可以在业务流程中使用 Web 服务。这一可选方案很有吸引力，因为业务流程设计师可以在大大简化开发人员体验的同时，为长时间运行的进程、关联和错误处理提供高级支持。也可以将业务流程作为 Web 服务发布，以自动公开其公共接收端口。

现在，让我们进一步了解如何使用目前的 SOAP 和 WSE 适配器执行刚才介绍的一些任务。

使用 SOAP 适配器

让我们假定用于处理订单的 BizTalk 解决方案已经准备就绪。为通过不同的传输模式（例如，MSMQ 和 FTP）接收订单，您已经对几个接收位置进行了配置，用于处理已发布订单消息的订阅也已准备就绪。除了需要完成的每件事情外，现在您只希望添加对通过 SOAP 接收订单的支持。在这种情况下，由于订单消息架构已有，因此只需根据它生成一个 ASMX 服务即可。

可以运行 BizTalk Web 服务发布向导来从现有架构类型生成 ASMX 服务。该向导允许您在发布架构或业务流程之间做出选择。该案例中，您希望发布架构。

接下来，将要求您描述希望公开的 Web 服务约定。由于只是发布一个架构，因此必须手动定义 Web 服务的名称和希望创建的每个 WebMethod 操作的名称。然后，对于每个 WebMethod，可以将请求/响应消息映射到 BizTalk 程序集内找到的一个特定架构类型（参见图 5）。该向导将要求您提供有关要生成的 ASMX 代码的其他详细信息，如目标命名空间、ASMX 参数样式以及是否希望做出 BP 1.1 一致性声明。此外还会询问您是否希望支持其他的或未知的 SOAP 标头以便将来进行处理。

图 5 发布一个架构 (单击该图像获得较小视图)

图 5 发布一个架构 (单击该图像获得较大视图)

最后，会要求您提供虚拟目录，生成的 ASMX 代码将部署于该目录中。另外向导还会在一个现有的 BizTalk 应用程序中为您创建一个对应的接收位置。向导程序在完成时会生成 ASMX 代码，将代码发布到指定目录，并创建一个 BizTalk 接收位置，为服务进行配置。

但是，在能够浏览已生成的 ASMX 端点之前，您需要先验证虚拟目录已配置为运行于有权访问 BizTalk 数据库的应用程序池之中（应用程序池的身份需要为 IIS_WPG 和 BizTalk 独立主机用户的成员）。此时，还可以使用 IIS 和 Microsoft^® .NET Framework 中的传统配置方法对 HTTP 和 ASP.NET 处理的其他方面进行配置。

另一半配置位于 BizTalk 接收位置。如果打开 BizTalk 管理控制台，您将发现向导所创建的 SOAP 接收位置。接收位置属性与图 6 所示类似。注意，它已配置为在独立主机实例中运行。而且，如果单击“配置”按钮来配置 SOAP 传输，您会发现其中仅包含了服务的地址（这是独立主机运行时查找 BizTalk 配置的其他内容（如接收管道和映射）所用的关键字）。

图 6 SOAP 接收位置配置 (单击该图像获得较小视图)

图 6 SOAP 接收位置配置 (单击该图像获得较大视图)

正确配置虚拟目录后，即可浏览到已生成的 ASMX 终结点，并将看到传统的 ASMX 文档页。如果查看操作的详细信息，会发现每条 SOAP 消息的正文的确是您在向导中指定的架构类型。这时，客户端就可以访问 ASMX 终结点，检索服务的 Web Services 描述语言 (WSDL) 定义以生成客户端代码。WSDL 代码的生成使得可识别 SOAP 的客户端能够更加轻松地与 BizTalk 解决方案集成在一起。

现在，假设您需要一个外部帐单服务，以便响应传入的订单消息来向帐单发送方发送消息。另外我们还假设，一个用于与外部 Web 服务进行通讯的 Web 服务代理类已经开发完毕。（要使用 wsdl.exe 或“添加 Web 引用”创建该类。）

您可以创建一个能够将消息发送到该外部帐单服务的发送端口。只需选择 SOAP 适配器，并指定外部 Web 服务的地址（参见图 7）。然后，在“Web 服务”选项卡上，选择要使用的 Web 服务代理类和方法（参见图 8）。BizTalk 将在发送消息时使用该代理类。程序集在运行时要位于全局程序集缓存 (GAC) 中。

图 7 SOAP 发送端口配置 (单击该图像获得较小视图)

图 7 SOAP 发送端口配置 (单击该图像获得较大视图)

图 8 指定一个代理类 (单击该图像获得较小视图)

图 8 指定一个代理类 (单击该图像获得较大视图)

要使操作成功，最困难的任务是在运行时为 SOAP 适配器提供正确的消息。如果指定的代理类方法有多个参数，BizTalk 会希望您提供一条包含多个部分的消息，其中每个部分均对应签名中的一个参数。BizTalk 会先将消息的每个部分反序列化为对应的 .NET Framework 类型，然后再调用 Web 服务代理方法，该方法随后又将所有内容序列化为一条 SOAP 消息。

注意，当您需要使用一个现有的 WSDL 定义时，可以使用 BizTalk 业务流程执行语言 (BPEL) 导入向导通过 WSDL 生成一个业务流程窗体。也可以配合使用传统的 wsdl.exe /server 和一些手动的干预手段来生成正确的适配器代码。有关各种约定优先 (contract-first) 技术的更多详细信息，请参阅 msdn.microsoft.com/library/en-us/bts_2004wp/html/7f82d724-4f6f-4440-9b01-921d0cb51fc0.asp。

SOAP 传输属性

在使用 SOAP 适配器时，有许多针对 SOAP 的消息上下文属性供您使用。这些属性均位于 SOAP 命名空间，您可以从管道组件和业务流程形状内访问它们。

例如，SOAP.AssemblyName 和 SOAP.MethodName 标识通过 SOAP 发送端口发送消息时使用的 Web 服务代理类和方法。您还可能希望通过 SOAP.Username 和 SOAP.Password 动态地配置客户端凭据。还可能需要通过设置 SOAP.ClientConnectionTimeout 来增大响应超时值。这些属性可用于在运行时对各种动态发送端口的属性进行配置。有关 SOAP 适配器属性的完整列表及其工作原理，请参考 SOAP 适配器文档。

在接收端上，您可能需要处理各种从传入 SOAP 消息中找到的 SOAP 标头。有两种方法可以完成该任务。首先，如果在使用发布向导时定义的是任何已知的 SOAP 标头，则这些标头将作为一个特殊的 SOAPHeader 命名空间内的自定义属性供您使用。否则，所有未知的 SOAP 标头都被存储在 SOAP.UnknownHeaders 属性中。此外，如果需要添加更多的 SOAP 标头到传出的 SOAP 消息中，可以在发送消息前填充 SOAP 标头属性。

在继续下一步操作前，我要提醒您的最后一点是，BizTalk Server 2006 中新增了失败消息路由功能。发送/接收端口启用该功能后，会将失败消息重新发布到 MessageBox，消息上下文将额外带有错误报告属性（位于 ErrorReport 命名空间）。这样，就可以订阅各种 ErrorReport 属性，以便在 SOAP 发送/接收端口中出现某些错误时获得通知。

在业务流程中使用 SOAP 适配器

到目前为止，我已经介绍了在不使用 BizTalk 业务流程的情况下，在消息传送层中使用 SOAP 适配器的基础知识。当然，您可以将 SOAP 适配器与业务流程配合使用，而通常这一建议也是更容易实施的。

运行相同的 BizTalk Web 服务发布向导可以将业务流程作为一项 Web 服务来发布，但在运行向导时需要选择发布一个业务流程。向导会要求您选择一个业务流程和希望公开的公共端口。服务约定将派生自您选择的端口，因此您无需像之前那样手动定义约定。向导中的其余步骤与之前的步骤相同：要求您提供各种 IIS 和 ASP.NET 设置，并生成一个 ASMX 服务。而主要的差异在于，该向导能够从业务流程自动派生约定。

您也可以使用业务流程中的 Web 服务。首先，使用 Visual Studio^® 中的“添加 Web 引用”命令。这将引入所需的架构和端口类型，您需要使用它们来从业务流程调用外部服务。然后定义一个新的业务流程端口，并选择“添加 Web 引用”命令所添加的 Web 端口类型。使用生成的 Web 端口类型可确保将向 Web 服务发送或从其接收正确的 XML 消息。最后，只需将“发送”和“接收”形状连接到 Web 端口以模拟 Web 服务调用即可。

也可以从业务流程表达式形状内调用 Web 服务。在这种情况下，消息并不是从 BizTalk 消息传送层传送，因此不具有传统 Web 服务调用的低延迟特征。但是，频繁使用该方法也可能使业务流程在部署之后变得更难以管理。

通过使用“范围”形状和异常处理块，您可以在业务流程内处理服务返回的 SOAP 错误。如果要对 SOAP 错误的详细信息进行处理，则应该将异常处理块配置为捕获 System.Web.Services.Protocols.SoapException 类型的异常。同样，在将业务流程作为服务发布后，业务流程可以将 SOAP 错误返回给调用方。

WSE 2.0 适配器

WSE 2.0 适配器的使用过程与之前所述的 SOAP 适配器的使用过程是相似的。我们要着重谈一下二者的不同之处。

首先您会发现，WSE 2.0 适配器附带有属于自己的发布向导。运行该向导时，直到图 9 所示的步骤之前，其步骤与 SOAP 适配器是几乎完全相同的，而在图 9 所示步骤中，则要求您配置请求、响应和错误消息的安全策略。您可以指定要使用的令牌类型，甚至可以在向导内指定某些令牌的详细信息。

如果查看 WSE 2.0 向导生成的代码，您首先会发现，应用程序是通过虚拟目录中的 WSE 2.0 策略文件进行配置的。该策略是向导根据您提供的设置生成的。在某些情况下，使用向导后，可能需要运行 WSE 2.0 配置工具来完成策略配置，而且您完全可以这样做。

您可能还会注意到，生成的代码不再使用 ASMX 编程模型，而是使用 WSE 2.0 消息传送 API。生成的 BizTalk 接收位置看上去也与 SOAP 版本的相似，但是 WSE 传输配置对话框则稍有不同，因为它公开了另外一些与安全性相关的配置选项。

发送端执行的操作要比 SOAP 适配器的更简单一些。使用 WSE 2.0 发送端口，您将无需再指定 Web 服务代理类。而只需指定 Web 服务 URL 和相应的策略配置即可，适配器会负责自动生成和发送相应的消息。

借助 WSE 2.0 适配器在业务流程中使用 Web 服务时，您也不必再使用“添加 Web 引用”命令。取而代之地，使用“添加生成的项”命令并选择“添加适配器元数据”选项。当“添加适配器向导”出现时，从已注册适配器列表中选择“WSE”，然后单击“下一步”。会出现 BizTalk Adapter for WSE 架构生成向导。

BizTalk Adapter for WSE 架构生成向导会要求您提供 WSDL 定义的地址并稍后下载该定义，以检索可能服务和操作的列表。按照向导的要求，您需要从该列表中选择一项服务和一组方法。然后向导会要求您对与服务进行通讯所需的 WSE 2.0 策略文件进行配置。策略可以从 URL（如果可用）下载，也可以使用图 9 所示的策略配置对话框手动进行配置。

与“添加 Web 引用”一样，向导会添加与服务进行通讯所需的架构和端口类型。而且还会生成一份名为 PolicyCache.xml 的 WSE 2.0 策略文件，该文件被保存到 WSE 2.0 适配器安装目录内的 Policy 目录（请参阅 %PROGRAMFILES%/Microsoft BizTalk Server Adapter for WSE 2.0/Policy）。BizTalk 在这里可以找到所有的 WSE 2.0 策略。在安装 WSE 2.0 适配器时，它实际上是通过一个引用了该全局 PolicyCache.xml 文件的 <policy> 元素对 BTSNTSvc.exe.config 进行更新。

WSE 2.0 适配器还引入了各种新的消息属性（例如，WSE.SoapAction、WSE.SoapHeaders、WSE.AddressingHeaders、WSE.ReferralHeaders、WSE.SecurityHeaders 和 WSE.ClientCertificate），用于提供对有关 WSE 的信息的访问。有关详细信息，请查阅 WSE 2.0 适配器文档。

总而言之，WSE 2.0 适配器提供的这些主要的新功能是支持基于消息的安全策略的，同时在无法使用业务流程的仅允许消息传送的解决方案中，还可以对基于内容的路由提供支持。

BizTalk 资源

• Understanding BizTalk Server 2006（英文）
• BizTalk Web Services FAQ（英文）
• BizTalk Server 2004 and Web Services（英文）
• Implementing Service Contracts with BizTalk Server 2004（英文）
• Walkthrough for BizTalk Adapter for WSE 2.0（英文）

Close [x]

WCF 适配器

BizTalk Server 2006 R2 版本将附带几个 Windows Communication Foundation 适配器，这些适配器将共同为 WS-* 和与传输模式无关的消息传送提供完全支持。对于许多内置的 Windows Communication Foundation 绑定（例如，BasicHttpBinding、WSHttpBinding、NetTcpBinding、NetNamedPipeBinding 和 NetMsmqBinding）来说，实际上都会有一个单独的适配器。而且还提供了一个自定义的 Windows Communication Foundation 适配器，您可以对其绑定进行完全的配置。虽然该自定义适配器将是您唯一真正需要的适配器，但对于某种常见的消息传送方案，其他绑定会更易于使用。

该自定义适配器不仅可以执行 SOAP 和 WSE 适配器所能执行的操作，而且还远不止于此。它将提供对 WS-* 堆栈的完全支持，其中包括各种安全性、可靠消息传送以及事务规范。对这些规范的支持将允许您处理更为复杂的安全和路由方案，甚至能够将 MessageBox 包含在 Web 服务事务中。

此外，它还将提供简化的承载、通讯和配置选项。例如，使用 Windows Communication Foundation 适配器，只需配置一个接收位置并在 BizTalk 管理控制台中加以启用（无需发布）即可在 BTSNtSvc.exe 中承载非 HTTP 服务。

但是，最吸引人的功能或许是合一性。具体说来，Windows Communication Foundation 适配器将 SOAP 和 WSE 适配器提供的功能合而为一，因此您完全不必再依赖它们。将来在对各种不同的服务配置进行集成时，应该只需要各种 Windows Communication Foundation 适配器即可实现目的。有关 Windows Communication Foundation 及其与 ASP.NET 和 WSE Web 服务的互操作性的详细信息，请参阅 msdn2.microsoft.com/ms735119.aspx 上的 Windows SDK。

总结

BizTalk Server 2006 通过前面讨论的内置 SOAP 适配器和 WSE 适配器为当今的 Web 服务技术提供支持。（有关 BizTalk 的详细信息，请参阅“BizTalk 资源”侧栏。）SOAP 适配器提供 BP 1.1 通讯，而 WSE 适配器则提供更高级的 WS-* 支持。但是，与传输模式无关的 WS-* 消息传送这一激动人心的发展只有在 BizTalk Server 2006 携 Windows Communication Foundation 适配器一同出现后才可以完全实现，但不要着急，这一刻即将来临。本文仅仅介绍了 Windows Communication Foundation 适配器的主要特点。我保证，在今后的专栏中我们还会进行更加深入的探讨，对第一个公开测试版进行更详细的介绍。