[转载]BizTalk Server 2004 和 Web 服务(BizTalk Server 2004 and Web Services )
信息来源：微软发布日期： 9/2/2005 | 更新日期： 9/2/2005
Brian Loesgen
Neudesic, LLC
适用于：BizTalk Server 2004
摘要：本白皮书讨论 BizTalk Server 2004 如何支持在生成解决方案的过程中使用 Web 服务。
本页内容
概述
使用 Web 服务
将 BizTalk 编排作为 Web 服务公开
将架构作为 Web 服务公开
高级 Web 服务注意事项
小结
关于作者
概述
面向服务的体系结构 (SOA) 是当前应用程序开发的“灵丹妙药”，而 Web 服务是 SOA 背后的关键性支持技术之一。Web 服务基于广泛使用的、作为行业标准的 SOAP 协议，并且变得越来越普及。
过去的应用程序开发浪潮意味着开发整体式的应用程序，这些应用程序由各自独立且直接控制资源的开发人员团队创建。在企业或部门之间交流信息通常意味着建立脆弱的硬接线连接，并且要求信息交流的双方之间进行协作。面向服务的体系结构将整体式应用程序分解为一套服务，其中，功能元素以模块方式实现并通常公开为 Web 服务。
以这种粒度方式将功能公开为 Web 服务是迈向提供实现解决方案所需的基本构造块的伟大的第一步，但还需要完成更多的工作。需要一个管理层 — 它可以编排 Web 服务，控制它们之间的流和交互，并且可以将单个服务聚合到更大的复合解决方案中。BizTalk Server 2004 非常完美地扮演了这一角色。
BizTalk Server 完全支持生成 Web 服务所依赖的所有开放标准。由于 BizTalk Server 的核心体系结构基于 XML 和 .NET Framework，因此它自然支持 Web 服务。Web 服务支持被紧密集成到该产品中。
BizTalk 解决方案可以通过下列方式使用 Web 服务：
• 使用现有的 Web 服务
• 将业务过程（编排）作为 Web 服务公开
• 通过 Web 服务公开消息处理引擎（发布架构）
• 作为管线处理、自定义适配器或映射执行的一部分调用 Web 服务
该白皮书分析 Web 服务较常见的使用方式，讨论相关原理并在适当情况下提供实现示例。该白皮书不讨论如何将 Web Servicess Enhancements for Microsoft .NET (WSE) 2.0 适配器用于 BizTalk Server。
我们在该白皮书中始终使用的方案是一个新的雇佣过程。作为该过程的一部分，我们在一家工资单处理公司调用了一个 Web 服务，以便向该工资单中添加新雇员。
返回页首
使用 Web 服务
使用 Web 服务是面向服务的体系结构 (SOA) 之所以可行的关键因素。SOA 调用的原则要求将软件解决方案分解为一系列的服务，这些服务聚合在一起以形成更高级别的服务或完整的应用程序。该方法支持更高程度的重用，因为这些服务可以在应用程序之间共享，并且可以用不同的方式组合起来以满足其他业务需要。但是，开发人员仍然需要编写“粘接”层，以便聚合和编排服务，而且还必须关心如何补偿不可用的服务、处理返回的错误等等。
BizTalk 编排（一种对过程进行建模和实现的图形方式）通过提供聚合和管理 Web 服务调用所需的构造块简化了该任务，从而提供了 Web 服务解决方案中需要的“高级大脑功能”。您可以在编排中实现诸如保证传递之类的设计模式，从而使您可以在 Web 服务不可用时采取适当的操作。
BizTalk 编排还提供一种在事务上下文中将操作组合在一起的机制，从而可以在业务事务中的操作无法完成时进行适当的补偿。
如何使用 Web 服务
在较高级别，使用 Web 服务所需的典型步骤是：
1.
向您要使用的服务中添加 Web 引用。
2.
添加编排。
3.
向该编排添加一个端口，将端口类型设置为在添加 Web 引用时创建的 Web 端口类型。
4.
创建一个与 Web 服务请求的类型相同的新消息。
5.
创建一个与 Web 服务响应的类型相同的新消息。
6.
发送请求消息。
7.
接收响应消息。
8.
对程序集进行签名，部署并对其进行测试。
添加 Web 引用
通过 BizTalk Server 使用 Web 服务是有经验的 .NET 开发人员的自然行为。他们会添加 Web 引用，就像他们在任何使用 Web 服务的 .NET Framework 应用程序中所做的一样。当您向 BizTalk 项目中添加 Web 引用时，BizTalk Server 将查询该服务的 Web 服务描述语言 (WSDL)，以确定它公开的类型、操作和端口。然后，将自动创建下列构件，并且可以通过编排使用它们：
• Web 端口类型
• Web 消息类型（请求和响应）
此外，还会添加下列项以作为引用本身的一部分：
• 引用映射（包含指向缓存服务和发现文件的链接）
• WSDL 文件（Web 服务说明、方法签名和类型的本地缓存副本）
• DISCO 文件（Web 服务发现文件、服务和协定的本地缓存副本）
• ODX 文件（BizTalk 编排文件，包含来自 Web 引用的实际类型）
• HTML 文件（WSDL 文件的用户友好版本，隐藏于 IDE）
• Reference.xsd（可选，包含任何复杂类型的架构）
在 Microsoft Visual Studio 集成开发环境 (IDE) 中，上述项显示在 Web 引用的下面，但是，如果您观察文件系统中该项目的文件夹，则会看到一个名为“Web References”的文件夹已经添加到该项目中。添加到该项目中的每个 Web 引用都在 Web References 文件夹下具有一个相应的子文件夹。
Reference.odx 文件定义在查询 WSDL 之后创建的类型，且马上即可在编排中使用。如果在 Visual Studio 中双击该文件，则该文件不会打开。相反，您会看到相应的 HTML 文件。该 HTML 文件为提供对由 WSDL 表示的方法签名和数据类型的更为细化的表示形式。
编排的入口点和出口点需要经过端口（它们具有特定的端口类型）。Web 端口类型具有一系列只读属性，这些属性作为“添加 Web 引用”操作的一部分而设置。这些属性标识 Web 服务 URI、方法和参数。此外，还创建了一个多部分消息，以反映 Web 服务的请求和响应（如果适合）。这就消除了手动创建架构的需要，并确保与请求和响应类型的一致性。
注：默认的 ASP.NET 行为是返回响应（即使方法返回 void）以使该服务可以返回错误信息。BizTalk Server 为 void 返回值创建响应消息。如果能够控制该 Web 服务且它是 .NET Web 服务，则可以通过使用 [SoapDocumentMethod(OneWay=true)] 属性来指定不应该返回响应，从而使其成为真正的发后不理服务。
Web 端口在 BizTalk Orchestration Designer 可视化标识为一个小球图标。Web 端口可包含多个操作，每个操作都表示 Web 方法调用或响应。
如果要使用的 Web 服务接受复杂类型为参数或返回值是复杂类型，则 BizTalk Server 需要这些类型的架构。在该示例中，一个 Reference.xsd 文件添加到 Web References 文件夹中，并且架构文件包含 WSDL 文件发布的复杂类型的定义。
添加 Web 端口
添加新的 Web 端口
1.
右键单击右侧或左侧端口图面，然后单击 Add new configured port。
2.
在“Select a port type”屏幕上，指定要使用的现有端口类型，然后展开 Web Port Types 节点。
这会显示当您向该项目中添加 Web 引用时创建的所有可用 Web 端口类型的清单。请注意，该对话框还显示这些端口类型所公开的 Web 方法。
构建 Web 服务请求和响应
在使用 BizTalk Server 时，您是在面向消息的范型下工作。这意味着您通过构建请求消息并且将其发送到 Web 端口来调用 Web 服务。如果 Web 方法不接受参数，则仍然使用相同的方法，这是因为您创建不包含任何部分的多部分消息。为此，您使用 Construct 形状创建适当的消息，但是在 Construct 内部没有 Transform 或 Assignment 形状。
在创建 Web 消息请求时使用下列两种技术：转换和分配。使用的技术取决于要调用的方法的参数类型。如果它是复杂类型，则您使用转换（映射）或分配（编程）来创建请求。如果您要调用的 Web 服务方法需要简单的参数类型（例如，string），则您可以在表达式形状中直接向请求消息参数分配一个值（在这种情况下，不能进行映射）。
请注意，Web 服务请求和响应具有多个可能需要关注的消息上下文属性。上下文属性的一个常见用途体现在：调用的 Web 服务需要花费很长时间才能返回响应这一情况下。在此情况下，您可以通过使用上下文属性（如下所示）来调整超时。
WSRegistrationRequest(SOAP.ClientConnectionTimeout) = 20000;
注：设置 .ClientConnectionTimeout 属性时，需要以毫秒为单位指定值。默认值是 90000（90 秒）。
在设置 Web 服务请求消息的上下文属性时，端口的绑定类型很重要。只有 .ClientConnectionTimeout 属性是可针对所有端口绑定类型进行更改的属性。只有当发送端口绑定类型设置为 Dynamic 时，才可以在编排中设置其他与 SOAP 相关的上下文属性。
发送和接收
对于 Web 服务而言，发送 Web 服务请求和接收响应与任何其他端口类型相同。您需要在发送和接收中设置消息，以匹配为请求和响应创建的消息；然后，您需要将这些形状连接到 Web 端口的请求和响应操作。
下图显示使用 Web 服务的示例。
[img]http://www.microsoft.com/china/MSDN/library/WebServices/WebServices/art/Local_-1032418138_consumingwebservice.gif[/img]
图 1 使用 Web 服务
在某些情况下，您可能希望动态设置 Web 服务 URI。为此，您可以将 Web 端口制定为动态绑定（与“specify now”或“specify later”相对），然后在脚本表达式中设置该 URI，如下所示：
CallRegistrationService(Microsoft.XLANGs.BaseTypes.Address) = "[url]http://PayrollCompany/RegisterEmployee.amsx[/url]";
尽管上述示例显示一种使用 Web 服务的有效方式，但该模式对于生产级解决方案并不适合，因为它没有考虑所使用的 Web 服务的不可用性或任何其他故障。
添加异常处理
现在，我们将向使用 Web 服务的简单示例中添加异常处理，以使其能够容错且健壮。
正像 SOAP 规范定义的那样，Web 服务通过错误信息传达故障信息。要将 Web 服务视为符合 SOAP 规范，必须采用这一论证清楚并广泛使用的机制。错误可以是任何出错的内容 — 从诸如对象创建故障这样的基础结构级问题到诸如无法满足业务规则这样的应用程序级错误。
通过使用 Scope 形状以及添加异常处理程序以捕获异常这一标准编排机制，可捕获异常。Scope 形状必须是长期运行的事务或为非事务性的。
[img]http://www.microsoft.com/china/MSDN/library/WebServices/WebServices/art/Local_-1892107078_exceptionhandling.gif[/img]
图 2 处理异常
如果要检索特定于 SOAP 协议的信息（如 Actor），可通过向项目添加对 System.Web.Services 的引用以及捕获 System.Web.Services.Protocols.SoapException 类型的异常来完成该任务。
例如，要在 Application 事件日志中创建一个包含异常消息（由引发该异常的 Web 服务返回）的条目，上图中的 Log SOAP Exception 表达式形状可以包含以下代码（假设异常对象的名称为“SOAPException”）：
System.Diagnostics.EventLog.WriteEntry("Detail: "+System.Convert.ToString(SOAPException.Message),"");
返回页首
将 BizTalk 编排作为 Web 服务公开
请注意，要支持将 BizTalk 编排作为 Web 服务公开，不需要新的底层基础结构。BizTalk Web 服务发布向导是一个创建标准 C# Web 服务项目的代码生成过程。.NET 开发人员从创建 .NET Web 服务的过程中获得的所有知识（从分配应用程序池到添加 SOAP 扩展）在这里也适用。
如先前的说明，本白皮书不涉及 WSE 2.0。
如何将编排作为 Web 服务公开
有两种启动 BizTalk Web 服务发布向导的方式：从“Start”菜单项中启动或者从 Visual Studio 中的“Tools”菜单启动。如果要发布的项目是 Visual Studio 中的当前项目，则从“Tools”菜单中启动该向导时会预先填充程序集位置。
选择程序集以后，该向导会在它内部寻找架构和编排。那些包含公共端口的编排列于向导屏幕。请注意，端口类型的默认类型修饰符（它控制可见性）是“Internal”。对于要作为 Web 服务公开的任何端口，都需要将该修饰符更改为“Public”。这些端口作为 Web 方法发布，而它们发送和接收的消息作为类型发布。请注意，可通过更改“Orchestration View”的“Port Types”节点中的属性来更改现有端口的类型修饰符。
SOAP 协议定义一种扩展性机制，您可通过该机制向消息中添加 SOAP 标头。这使您可以随消息一起发送附加信息（如安全标记），而无需修改该消息的内容。此外，您可以指定是否必须理解这些标头；如果指定“是”，则意味着，当带有意外标头的消息到达时，应该将其视为故障，并且应该返回 SOAP 错误。该发布向导包含用于添加附加标头以及指定是否应该允许使用意外标头的机制。
当该向导完成时，最终屏幕将提供一个指向已经创建的 C# 项目的链接。请注意，只有当编排端口或架构更改时，才需要执行这一生成过程。您可以修改编排并重新部署它，并且只要公共接口尚未更改，就无需重新生成该 Web 服务。
该向导过程还为您的 Web 服务生成适当的虚拟根，并且还会为默认的应用程序池配置该虚拟根。一种最佳做法是，创建一个最小权限应用程序池并将生成的 Web 服务分配给该池。如果过程是长期运行且是同步的，则您可能需要调整该服务的超时。对于标准 ASP.NET Web 服务，您可以通过在 Web.config 文件中设置 httpRuntime 元素的 executionTimeout 属性来完成该任务。
添加错误信息
在本白皮书前面部分，我们了解了如何检测由使用的 Web 服务引发的错误并对其作出反应。要使服务符合 SOAP 协议，需要能够将任何错误报告给调用我们的客户端，并且以符合 SOAP 协议的方式执行该任务。
框架为我们完成了大部分困难的工作。我们只需要提供错误信息，它就会作为标准的 SOAP 错误序列化并返回到客户端。实现 SOAP 错误所需的步骤包括：
1.
创建错误信息
2.
向作为 Web 服务公开的请求/响应端口的操作中添加错误信息
3.
如果出现错误条件，则返回该错误信息
该错误信息可以是复杂类型，也可以是简单的字符串。选择哪个类型取决于您的特定解决方案的需要。如果您需要做的所有工作是返回一个简单的消息，则请创建一个新消息并选择 System.String，而不是选择架构作为消息类型。如果您需要返回更加全面的信息作为错误详细信息，则请指定一个消息架构。您可以将值映射并分配给错误信息，就像对任何普通消息所做的那样。该消息的内容将为您自动序列化。
在作为 Web 服务公开时能够返回 SOAP 错误的编排如下图所示。
[img]http://www.microsoft.com/china/MSDN/library/WebServices/WebServices/art/Local_477170921_returningfaultmessage.gif[/img]
图 3 返回错误信息
如何创建非类型化 Web 服务
通常，BizTalk Server 2004 中的所有内容都是强类型的。当在编排中创建接收端口时，可以指定要接收的消息的类型。
但是，在某些情况下，您可能希望在单个终结点接收多个类型的文档。请考虑这一情况 — 供应商公开了一个 Web 服务，而它的合作伙伴可以将该服务用于多种用途：提交定单、发送定单更改请求以及发送取消。如果上述操作都采用不同的架构（实际情况可能如此），则需要创建多个终结点。一种替代方法是，让单个 Web 服务接收文档，然后使用 BizTalk Server 发布/预订机制，基于收到的文档的类型将收到的文档路由到适当的订户。
要实现该方法，需要执行下列步骤：
1.
创建一个虚拟编排，以接收 System.Xml.XmlDocument 类型的消息。确保该端口是 Public，以便 Web 服务发布向导可以公开它。
2.
运行 Web 服务发布向导，接受所有默认设置，指定要 BizTalk Server 创建端口，并授予其 Anonymous 访问权限。（在运行该向导以后，不再需要虚拟编排。创建它的目的只是让发布向导生成 Web 服务项目。）
3.
创建附加编排以接收已知类型（如 Order、Cancellation 和 Order Change）的消息。
在前面创建的附加编排中，设置激活 Receive 形状的筛选器以便只接受您希望接收的类型的消息（例如，BTS.MessageType == "[url]http://GenericXmlDocWS.Invoice#Invoice[/url]"）。请注意，如果您不执行该操作，则该 Web 服务收到的所有文档将由所有绑定到该 Web 端口的编排进行处理。
1.
生成并部署该项目。
2.
将附加编排的接收端口绑定到在发布虚拟编排时创建的 Web 端口。
3.
将接收位置设置为使用 XmlReceive 管线，以便识别传入的文档。
要使该机制发挥作用，需要对生成的 Web 服务的代码稍作更改。（对于不高于 BizTalk Server 2004 Service Pack 1 — 撰写本文时的当前版本，的所有版本，都如此。）打开该项目并查找以下代码：
string bodyTypeAssemblyQualifiedName = "Microsoft.XLANGs.BaseTypes.Any,
Microsoft.XLANGs.BaseTypes, Version=3.0.1.0, Cult" +
"ure=neutral, PublicKeyToken=31bf3856ad364e35";
将其更改为：
string bodyTypeAssemblyQualifiedName = string.Empty;
可以启动该编排。可以向该 Web 服务提交任何 XML 文档，但如果它的类型是 Order，则它将被识别并路由到适当的编排。
返回页首
将架构作为 Web 服务公开
迄今为止，我们只是从编排的观点考察了 Web 服务。但是，正像 BizTalk Server 开发人员了解的那样，可以只基于消息处理引擎生成解决方案，而无需使用任何编排。基于消息处理的解决方案使用基于内容的路由，根据消息的内容、消息上下文属性的值或这两者的某种组合来路由消息。尽管只使用消息处理的解决方案不允许您像插入编排那样将业务过程插入到解决方案中，但可以应用映射以及使用自定义管线，而这在很多情况下是您需要完成的所有工作。
要通过 Web 服务公开只使用消息处理的解决方案，需要一种将消息直接提交给 BizTalk MessageBox 数据库的方式。在将消息放入 MessageBox 时，需要确定消息类型，以便 BizTalk Server 可以识别该消息的订户。这就将我们引向 Web 服务发布向导的第二个选项，即将架构作为 Web 服务公开的选项。
该行为的工作方式类似于将编排作为 Web 服务公开的行为。在运行 Web 服务发布向导以后，它将收集相关信息，然后生成代理项目。与发布编排的情况一样，该代理是标准的 C# Web 服务应用程序。
如何将架构作为 Web 服务公开
在通过 Web 服务发布向导将架构作为 Web 服务发布时，您会看到很多与发布编排相同的页面，但也存在一些区别。
下图显示用来说明 Web 服务的向导屏幕。
[img]http://www.microsoft.com/china/MSDN/library/WebServices/WebServices/art/Local_382825961_webservicedescription.gif[/img]
图 4 Web 服务说明屏幕
在说明可以接收文档并返回响应的 Web 服务时所遵循的典型步骤是：
1.
右键单击 WebService 节点，并将其重命名为某个有意义的名称。该名称将成为 WSDL 文件的名称。
2.
右键单击 WebMethod1 节点，并将其重命名为某个有意义的名称。该名称将成为所公开的 Web 方法的名称。
3.
右键单击 Request 节点，指定一个 DLL，然后从该 DLL 中选择一个表示要接收的文档的架构。
4.
右键单击 Response 节点，指定一个 DLL，然后从该 DLL 中选择一个表示将返回给调用方的文档的架构。
就像发布编排一样，属性屏幕使您可以指定命名空间 URI、对未知标头的支持以及是否支持“一次登录”。
通过 Web 服务项目屏幕，可以指定应该如何命名代理项目、代理项目应该位于何处、是否允许匿名访问以及是否自动创建接收位置。请注意，如果不在这里创建接收位置，则需要您手动完成该工作。
返回页首
高级 Web 服务注意事项
本节提供有关使用 BizTalk Server 2004 和 Web 服务的附加信息。
使用 SOAP 标头
SOAP 协议使您可以向消息标头附加信息。该信息将与消息一同传输，但它不是内容的一部分。下面是一些您可能希望使用 SOAP 标头的场合的示例：
• 系统要求您登录，然后分配一个会话标识符，它必须成为该会话中每个后续消息的一部分
• 需要向消息附加用户凭据
• 通过标头中的数据能够使用可以基于标头信息路由消息的网络设备，而无需理解该消息本身（它可能完全加密或部分加密）
• 您希望使用标头信息来确定处理优先级（例如，白银、黄金、白金客户）并且相应地路由消息
对于 Server，可以在下列场合访问标头：
• 使用 Web 服务
• 将编排作为 Web 服务发布
• 将架构作为 Web 服务发布
有关标头存在这一事实以及是否需要它们的信息都表示为 Web 服务所发布的 WSDL 文件的一部分。标头是可选的。对于请求-响应消息模式，请求和响应消息的标头都是可访问的。
当运行发布向导时，您可以指定针对请求和响应消息加以支持的 SOAP 标头。每个标头类型都是通过指定架构定义的。您还可以选择支持未知的标头，在这种情况下，任何作为请求的一部分接收的未知 SOAP 标头都添加到消息的 SOAP.UnknownHeaders 上下文属性中。
如果收到包含 mustUnderstand 属性的标头，那么 Web 服务总是返回确认它们被理解的结果。
有关使用 Web 服务的提示
下面是在使用 Web 服务时需要知道的一些要点：
• BizTalk Server 2004 不支持数组参数类型。如果您能够控制正在使用的 Web 服务，则可以将其更改为接收/返回复杂对象。例如，在 .NET 中，创建一个类并且使用该类的实例作为参数或返回值。如果您无法控制 Web 服务，则可以编写一个与它交互的 .NET Helper 类。此外，WSE 2.0 适配器支持调用返回复杂类型数组的方法。
• BizTalk Server 2004 不直接支持只使用消息处理的解决方案，这些解决方案接受传入的消息并将其路由到 Web 服务。但是，您可以通过编写管线组件或自定义适配器以与该 Web 服务交互，从而获得相同的结果。此外，WSE 2.0 适配器支持不使用编排的、基于内容的路由。
• 在较高负载下，应该将请求-响应的 SOAP 发送处理函数放到它自己的宿主中。否则，编排会在等待 SOAP 响应通过 MessageBox 返回的同时优先发送 SOAP 请求，并且腾空编排。即使当这些响应返回时，宿主仍然会处于过度繁忙的状态：发送 SOAP 请求和腾空计划，以便查找时间来重新填充编排计划，从而可以获得 SOAP 响应。这一点极为重要，因为您可能看到，SOAP 请求-响应在较高负载下会由于该行为而大大降低速度。添加一个单独的专用于 SOAP 发送处理的发送宿主可以减轻这一性能瓶颈。
有关发布 Web 服务的提示
下面是在发布 Web 服务时需要知道的一些要点：
• 对于将编排作为 Web 服务发布，文档资料中包含有关如何启用跟踪和报告详细错误信息的有用信息。请参阅 BizTalk Server 2004 Help 中的“Debugging Published Web Servicess”。
• 请确保存在 Isolated Host 进程。HTTP 和 SOAP 适配器接收处理程序必须在 Isolated Host 中运行，因为它们位于 BizTalk 进程（它承载在 Internet 信息服务 (IIS) 中）外部。只有一个适配器可以在 Isolated Host 中运行，因此如果要使用 HTTP 和 SOAP 适配器，则您需要为二者分别创建一个 Isolated Host。
• 如果您的 SOAP 发送端口通过防火墙访问 Web 服务，则请确保指定代理服务器信息。您可以在适配器级别或者在发送端口本身中完成该工作（请参见地址的“proxy”选项卡）。
• 可以设置一些标志，以便能够从作为 Web 服务公开的编排中报告更为详细的 SOAP 和安全错误信息。有关详细信息，请参阅 BizTalk Server 2004 Help 中的“Debugging Published Web Services”。
• 与 Microsoft Windows 2000 中的安全性相比，Microsoft Windows Server 2003 中的安全性要更为严格。Web 服务运行时所在的应用程序池的身份需要是 IIS_WPG 和 BizTalk Isolated Hosts Users 组的成员。
• 如果要将编排作为公开简单数据类型（例如，单个字符串请求参数和布尔型响应）的 Web 服务发布，则请在该编排中创建该类型的消息，并且在该端口中发送/接收它们（在该示例中，创建 System.String 类型的请求和 System.Boolean 类型的响应）。
• 如果得不到您所期望的结果，则请不要忘记检查事件日志。
疑难解答
尽管使用 Web 服务和 BizTalk Server 很容易，但您确实需要在整个技术链中生成多个环节。如果其中任何一个环节中断，那么整个过程就可能失败。BizTalk Server 文档资料中包含全面的疑难解答信息，可以帮助您诊断常见的故障原因。
要开发建立在 BizTalk Server 之上的基于 Web 服务的解决方案，最成功的方法是按照系统化的、基于单元的方式进行。生成测试系统，以确保在将所使用的 Web 服务和编排作为 Web 服务公开之前，它们能够按预期方式工作，等等。如果遵循有条不紊的系统化的开发方法，那么您将获得成功并且将从 BizTalk Server 为 Web 服务解决方案带来的高级功能中获益。
作为 Web 服务发布的编排的调试检查列表
可以使用以下检查列表来调试已经作为在 Windows Server 2003 上运行的 Web 服务公开的编排所具有的问题。
首先，隔离问题。它是 IIS 或 BizTalk Server 中的问题吗？
调试 IIS 问题
• 检查 Application 事件日志。
• IIS 承载 SOAP 接收适配器，并且对接收端口和接收位置所做的更改不会立即生效，而是在为 BizTalk 组指定的 Cache Refresh 时间间隔生效。运行 IISRESET 以重新启动该服务，并且刷新缓存的设置。
• 在 IIS 管理器 MMC 管理单元中检查所生成的 Web 服务的应用程序池。它是您已经为 BizTalk Web 服务设置的应用程序池吗？
• 检查该应用程序池运行时所采用的身份。它是 IIS_WPG 和 BizTalk Isolated Host Users 组的成员吗？这两个组赋予 ASMX 页（BizTalk Web 服务发布向导生成的代理 Web 服务）适当的权限，以便将 SOAP 请求消息插入到随后将启动该编排的 SQL Server 中的 BizTalk MessageBox 中。故障现象可能是“SoapException:Internal SOAP Processing Failure”。
• 确保应用程序池的用户帐户具有 %temp% 文件夹上的读/写权限。这是 ASMX 被即时 (JIT) 编译为具有随机的八字符名称 (xxxxxxxx.dll) 的 DLL 的文件夹。故障现象可能是“SoapException:Internal SOAP Processing Failure”。
• 您能使用 IIS MMC 管理单元“浏览”ASMX 文件吗？
• 如果您没有在运行发布向导时指定对 Web 服务的匿名访问，则可以通过使用 IIS（ASMX 文件的属性）来临时允许进行匿名访问，以便消除无效凭据成为故障点的可能性。
• 确保您的 Web 服务测试客户端在 SOAP 方法调用中发送凭据，因为在 Windows Server 2003 中，默认情况下，虚拟目录需要 Windows 身份验证（除非您在运行发布向导时选中了“Allow Anonymous Access”复选框）。当使用 Internet Explorer 测试 Web 服务时，您使用的是自己的登录凭据（这也就是测试成功的原因）。如果您的测试客户端没有向 SOAP 方法调用中添加凭据，则您将获得由安全问题引起的 SOAP 异常。除非您启用附加的调试/跟踪，否则 Windnows Server 2003 只能向您提供非常少的有关该异常的信息。另一个选项是只允许对 Web 服务进行匿名访问，但是，您同样需要非常小心并且对其进行测试，因为匿名访问通过默认身份运行，而该身份同样必须属于 IIS_WPG 和 BizTalk Isolated Host Users 组，并且可能需要 %temp% 文件夹中的读/写访问权限。
• Server 文档资料列出了下列三种可以用来查看跟踪信息以及更为详尽的错误信息的方式：
• 对所发布的 Web 服务 web.config 文件使用 ThrowDetailedError 开关
• 启用 SOAP 消息跟踪
• 注释掉 .exe.config
调试 Server 问题
• 在 Health and Activity Tracking (HAT) 中，观察 Recent Services Instances。您的消息到达了没有？
• 接收端口中的 URI 与 Web 服务的 URI 匹配吗？
• 编排启动了吗？将编排绑定和登记还不够。您必须启动它，以便 Web 服务可以向其提交自身。如果编排尚未启动，则您将收到“SoapException: Internal SOAP Processing Failure”错误。
• 绑定到您的编排的接收位置登记了吗？绑定到它的发送端口启动了吗？
如果不提到 InfoPath — Microsoft Office 产品套件的最新成员，那么任何对 Web 服务如何与 Server 发生关系的讨论都是不完整的。InfoPath 是 Microsoft 对电子表单问题提供的答案。它允许将 XML 数据和表示信息打包在单个软件包中，并且提供丰富的表单开发环境。可以将 XML 处理指令添加到 XML 文档中以将其与 InfoPath 表单相关联，以便可以通过双击该文档显示该表单中的数据。请注意，InfoPath 是客户端应用程序，因此需要安装在将要呈现表单的计算机上。
InfoPath 基于开放标准 XML，并且它对它所呈现的 XML 数据使用标准 XSD 架构，就像 Server 使用 XSD 架构一样。InfoPath 的一个使 Server 开发人员感兴趣的方面是基于 Web 服务创建新表单的功能。这意味着您可以创建 BizTalk 编排，运行 Web 服务发布向导，并且使用 InfoPath 创建可以向 Web 服务提交数据的输入表单 — 全都不需要编写任何代码。这是一种在开发应用程序的同时构建数据输入点的快速且容易的方式。
InfoPath 的一个常见使用模式与需要人工干预的消息有关。您可以将所讨论的消息存放到文件夹（或 Windows SharePoint Services）中，而用户可以对其进行任何编辑或需要的批准；在提交表单时，可以将其发送给由 Web 服务发布向导创建的 Web 服务，而该服务可以将数据返回到编排的接收位置中。
返回页首
小结
使用面向服务的体系结构目前是应用程序设计的首选方法，而 Web 服务可以成为实现 SOA 的关键促进因素。Server 以对开发人员而言自然而直观的方式支持 Web 服务。该白皮书已经说明了 Server 如何使用 Web 服务提供生成健壮而灵活的业务关键性应用程序所需的构造块。
返回页首
关于作者
Brian Loesgen 居住在 San Diego，他是 Neudesic（一家专门从事 .NET 开发和 Microsoft 服务器集成的公司）的首席顾问。Brian 是 BizTalk Server 2004 方面的 Microsoft MVP。他具有超过 18 年的生成高级企业和移动解决方案的经验。他与人合著了六本书（包括“BizTalk Server 2004 Unleashed”），并且已经为 Intel、Microsoft 和其他公司撰写过技术白皮书。Brian 曾经在很多重大国际技术会议上发表过演讲。他是 International .NET Association (ineta.org) 的创始人兼总裁。他是 San Diego .NET 用户组的主席，领导着 San Diego Software Industry Council Web Services SIG，并且是 .NET Developer 杂志编辑委员会的成员。Brian 还是 Microsoft BPI Virtual Technical Specialist Team 的成员。您可以在 blogs.ineta.org/bloesgen 找到他的网络日记。 信息来源：微软
英文版
Brian Loesgen
Neudesic, LLC
May 2005
Applies to: BizTalk Server 2004
Summary: This white paper discusses how Microsoft BizTalk Server 2004 supports the use of Web services in building solutions. (15 printed pages)
Overview
Service-oriented architecture (SOA) is the mantra of current application development, and Web services are one of the key enabling technologies behind SOA. Web services, based on the widely used and industry-standard SOAP protocol, are becoming increasingly ubiquitous.
Past waves of application development have meant monolithic applications, created by teams of developers who worked in isolation with resources under their immediate control. Exchanging information between enterprises or divisions usually meant brittle hard-wired connections that required collaboration between both sides of the exchange. Service-oriented architectures break down monolithic applications into a suite of services, where elements of functionality are implemented in a modular fashion, and often are exposed as Web services.
Exposing functionality as Web services in such a granular fashion is a great first step toward providing the basic building blocks required to implement solutions, but more work is required. A management layer is needed—something that can orchestrate the Web services, controlling the flow and interaction between them and aggregating individual services into a larger composite solution. Microsoft BizTalk Server 2004 fills that role exceptionally well.
BizTalk Server fully supports all the open standards upon which Web services are built. With its core architecture based on XML and the .NET Framework, BizTalk Server supports Web services naturally. Web service support is tightly integrated into the product.
A BizTalk solution can use Web services in the following ways:
Consume existing Web services
Expose business processes (BizTalk orchestrations) as Web services
Expose the messaging engine through Web services (publishing schemas)
Invoke Web services as part of pipeline processing, a custom adapter, or map execution
This white paper examines the more common ways of working with Web services, discussing the principles and showing implementation examples where appropriate. This paper does not address the use of the Web Services Enhancements for Microsoft .NET (WSE) 2.0 adapter with BizTalk Server.
The scenario that we use throughout this white paper is a new hire process. As part of the process, we call a Web service at a payroll processing company to add the new employee to the payroll.
Consuming a Web Service
The use of Web services is a key enabler of service-oriented architectures (SOA). The tenets of SOA call for decomposing software solutions into a series of services that are aggregated to form a higher-level service or a complete application. This approach allows for greater reuse, because the services can be shared between applications and can be combined in different ways to meet other business needs. However, developers still need to write the "glue" layer that aggregates and choreographs the services, and must also be concerned about compensating for unavailable services, handling returned faults, and so on.
A BizTalk orchestration (a graphical way to model and implement processes) simplifies this task by providing the building blocks required to aggregate and manage Web service invocations, thereby providing the "higher brain functionality" required in a Web service solution. You can implement design patterns such as guaranteed delivery in an orchestration, allowing you to take appropriate action if a Web service is unavailable.
A BizTalk orchestration also provides a mechanism to group actions together in a transactional context, allowing appropriate compensation if the operations in a business transaction fail to complete.
How to Consume a Web Service
At a high level, the typical steps required to consume a Web service are:
Add a Web reference to the service you want to consume.
Add an orchestration.
Add a port to the orchestration, setting the port type to the Web port type that was created when you added the Web reference.
Create a new message of the same type as the Web service request.
Create a new message of the same type as the Web service response.
Send the request message.
Receive the response message.
Sign the assembly, deploy it, and test it.
Adding a Web Reference
Consuming a Web service with BizTalk Server is a natural act for experienced .NET developers. They add a Web reference just as they would do from any .NET Framework application that consumes a Web service. When you add a Web reference to a BizTalk project, BizTalk Server queries the service's Web Services Description Language (WSDL) to determine what types, operations, and ports it exposes. The following artifacts are then automatically created and become available from the orchestration:
Web port type
Web message types (request and response)
In addition, the following items are added as part of the reference itself:
Reference map (contains links to the cached service and discovery file URIs)
WSDL file (cached local copy of the Web service description, method signatures, and types)
DISCO file (cached local copy of the Web services discovery file, service, and contract URIs)
ODX file (the BizTalk orchestration file that contains the actual types from the Web reference)
HTML file (a human-friendly version of the WSDL file, hidden in the IDE)
Reference.xsd (optional, contains schemas for any complex types)
In the Microsoft Visual Studio integrated development environment (IDE) these items appear under the Web reference, but if you look at the project's folder in the file system you will see that a "Web References" folder has been added to the project. Each Web reference you add to the project has a corresponding subfolder under the Web References folder.
The Reference.odx file defines the types that are created for you after the WSDL is queried, and are subsequently available in your orchestration. If you double-click this file in Visual Studio, the file is not opened. Instead you see the corresponding HTML file. The HTML file gives you a more refined presentation of the method signatures and data types expressed by the WSDL.
Entry and exit points from orchestrations are through ports, which are of a specific port type. The Web port type has a series of read-only properties that were set as part of the Add Web Reference operation. These properties identify the Web service URI, methods, and parameters. In addition, a multipart message is created that reflects the request and, if appropriate, the response of the Web service. This eliminates the need for you to manually create the schemas, and ensures conformity with the request and response types.
Note: The default ASP.NET behavior is to return a response even if a method returns void, to allow the service to return a fault message. BizTalk Server creates a response message part for the void return. If you are in control of the Web service and it is a .NET Web service, you can specify that a response should not be returned by using the [SoapDocumentMethod(OneWay=true)] attribute, making it truly fire-and-forget.
Web ports are visually identified in BizTalk Orchestration Designer by a small globe icon. A Web port can contain multiple operations, each of which represents a Web method call or response.
If the Web service you are using accepts complex types as parameters, or the return value is a complex type, then BizTalk Server needs a schema for those types. In this case, a Reference.xsd file is added to your Web References folder, and the schema file contains the definitions of the complex types as published by the WSDL file.
Adding a Web Port
To add a new Web port
Right-click the right or left port surface, and then click Add new configured port.
On the Select a port type screen, specify that you want to use an existing port type, and expand the Web Port Types node.
This shows you a listing of all available Web Port Types that were created when you added a Web reference to the project. Note that this dialog box also shows you which Web methods the port types expose.
Constructing Web Service Requests and Responses
When working with BizTalk Server you are working in a message-oriented paradigm. This means that you call a Web service by constructing a request message and sending it to the Web port. If a Web method does not accept a parameter, you still use the same approach, in that you create a multipart message that contains no parts. To do this you use a Construct shape to create the appropriate message, but without a Transform or Assignment shape inside the Construct.
Two techniques are used for creating a Web message request: transformation and assignment. Which one you use depends on the parameter type of the method you are calling. If it is a complex type, then you use a transformation (map) or assignment (programmatic) to create the request. If the Web service method you are calling requires a simple parameter type (for example, string), then you directly assign a value to the request message parameter in an expression shape (in this case, you cannot map).
Note that Web service requests and responses have several message context properties that may be of interest. A common use of the context properties is when you call a Web service that takes a long time to return a response. In this case you can adjust the time-out by using the context property as shown below:
WSRegistrationRequest(SOAP.ClientConnectionTimeout) = 20000;
Note: When setting the SOAP.ClientConnectionTimeout property, you specify the value in milliseconds. The default value is 90000 (90 seconds).
When setting context properties of a Web service request message, the binding type of the port is important. Only the SOAP.ClientConnectionTimeout property can be changed for all port binding types. The other SOAP-related context properties can be set in an orchestration only if the send port binding type is set to Dynamic.
Sending and Receiving
Sending a Web service request and receiving a response is the same with Web services as with any other port type. You need to set the messages in the send and receive to match the messages you created for the request and response, and then you need to connect these shapes to the request and response operations of the Web port.
The following figure shows an example of consuming a Web service.
Figure 1 Consuming a Web service
[img]http://msdn.microsoft.com/library/en-us/BTS_2004WP/local/Local_-1032418138_consumingwebservice.gif[/img]
In some cases you may want to set the Web service URI dynamically. You can do this by specifying that your Web port is dynamically bound (as opposed to "specify now" or "specify later"), and then setting the URI in a script expression as follows:
CallRegistrationService(Microsoft.XLANGs.BaseTypes.Address) = "[url]http://PayrollCompany/RegisterEmployee.amsx[/url]";
Although the preceding example is an effective way to consume a Web service, this pattern is not appropriate for a production-grade solution because it does not take into account unavailability of the consumed Web service, or any other failures.
Adding Exception Handling
We will now add exception handling to our simple example of consuming a Web service to make it fault-tolerant and robust.
As defined by the SOAP specification, Web services communicate failures through fault messages. This is a well-documented and widely used mechanism that is required for a Web service to be considered SOAP-compliant. A fault can be anything that goes wrong, from infrastructure-level issues such as object creation failure to application-level errors such as failure to meet a business rule.
We can catch exceptions with the standard orchestration mechanism of using a Scope shape and adding an exception handler to catch the exception. The Scope shape must be either a long-running transaction or nontransactional.
Figure 2 Handling exceptions
[img]http://msdn.microsoft.com/library/en-us/BTS_2004WP/local/Local_-1892107078_exceptionhandling.gif[/img]
If you want to retrieve SOAP protocol-specific information, such as the Actor, you can do so by adding a reference to System.Web.Services to your project and catching exceptions of type System.Web.Services.Protocols.SoapException.
For example, to create an entry in the Application event log that contains the message of the exception (as returned by the Web service that threw the exception), the Log SOAP Exception expression shape in the preceding figure could contain this code, assuming that the name of the exception object is "SOAPException":
System.Diagnostics.EventLog.WriteEntry("Detail: "+System.Convert.ToString(SOAPException.Message),"");
Exposing a BizTalk Orchestration as a Web Service
It is important to note that there is no new underlying infrastructure required to support publishing BizTalk orchestrations as Web services. The BizTalk Web Services Publishing Wizard is a code-generation process that creates a standard C# Web service project. Everything that .NET developers know from creating .NET Web services applies here, from assigning application pools to adding SOAP extensions.
As stated earlier, this white paper does not address WSE 2.0.
How to Expose an Orchestration as a Web Service
There are two ways to launch the BizTalk Web Services Publishing Wizard: from the Start menu entry or from the Tools menu in Visual Studio. If the project you want to publish is the current project in Visual Studio, then launching the wizard from the Tools menu prepopulates the assembly location for you.
After you select an assembly, the wizard looks through it for schemas and orchestrations. Orchestrations containing public ports are listed on the wizard screen. Note that the default type modifier (which controls visibility) for port types is "Internal". You need to change this to "Public" for any ports that you wish to expose as Web services. These ports are published as Web methods, and the messages they send and receive are published as types. Note that you can change the type modifier of an existing port by changing the property in the Port Types node of the Orchestration View.
The SOAP protocol defines an extensibility mechanism whereby you can add SOAP headers to a message. This allows you to send additional information, such as a security token, with a message without modifying the content of the message. In addition, you can specify whether the headers must be understood, meaning that if a message arrives with an unexpected header then it should be treated as a failure and a SOAP fault should be returned. The publishing wizard includes a mechanism for both adding additional headers and specifying whether unexpected headers should be permitted.
When the wizard completes, the final screen gives you a link to the C# project that has been created. Note that you only need to do this generation process if the orchestration ports or schemas change. You can modify the orchestration and redeploy it, and as long as the public interface has not changed you do not need to regenerate the Web service.
The wizard process also generates the appropriate virtual root for your Web service, and the virtual root is configured for the default application pool. A best practice is to create a minimal permission application pool and assign your generated Web services to that pool. If your process is long running and synchronous, you may need to adjust the time-out of the service. For standard ASP.NET Web services you do this by setting the executionTimeout attribute of the httpRuntime element in the Web.config file.
Adding Fault Messages
Earlier in this white paper we saw how to detect and react to faults raised by Web services we consumed. To be a SOAP protocol-compliant service, we need to be able to report any faults back to the client that called us, and to do so in a manner that conforms to the SOAP protocol.
The framework does most of the hard work for us. We simply need to provide a fault message, and it is serialized and returned to the client as a standard SOAP fault. The steps required to implement a SOAP fault are:
Create a fault message
Add a fault message to the operation of the request/response port that is exposed as a Web service
Return the fault message in the event of an error condition
The fault message can be either a complex type or a simple string. Which one you choose depends on the needs of your particular solution. If all you need to do is return a simple message, then create a new message and instead of choosing a schema as the message type, choose System.String. If you need to return more comprehensive information as the fault detail, then specify a message schema. You can map and assign values to your fault message just as you would to any normal message. The content of the message is automatically serialized for you.
An orchestration that can return a SOAP fault when exposed as a Web service might look as shown in the following figure.
Figure 3 Returning a fault message
[img]http://msdn.microsoft.com/library/en-us/BTS_2004WP/local/Local_477170921_returningfaultmessage.gif[/img]
How to Create an Untyped Web Service
Normally, everything in BizTalk Server 2004 is strongly typed. When you create a receive port in an orchestration, you specify the type of the message being received.
There are, however, cases where you may want to receive multiple types of documents at a single endpoint. Consider the case of a supplier exposing a Web service that its partners can use for multiple purposes: to submit orders, send order change requests, and send cancellations. If these are all different schemas, as likely would be the case, then you need to create multiple endpoints. An alternative approach would be to have a single Web service receive documents, and then use the BizTalk Server publish/subscribe mechanism to route the received documents to the appropriate subscriber based on the type of document received.
The following steps are required to implement this approach:
Create a dummy orchestration that receives a message of type System.Xml.XmlDocument. Make sure that the port is Public so that the Web Services Publishing Wizard can expose it.
Run the Web Services Publishing Wizard, accepting all the defaults, specifying that you want BizTalk Server to create the ports, and granting it Anonymous access. (After you run the wizard, you no longer need the dummy orchestration. You only created it to have the publishing wizard generate the Web service project.)
Create additional orchestrations that receive a message of a known type, such as Order, Cancellation, and Order Change.
In the additional orchestrations created above, set the activating Receive shape's filter to only accept messages of the type you want to receive (for example, BTS.MessageType == "[url]http://GenericXmlDocWS.Invoice#Invoice[/url]"). Note that if you do not do this, all documents received by the Web service are processed by all of the orchestrations bound to the Web port.
Build and deploy the project.
Bind the receive port of the additional orchestrations to the Web port that was created when you published the dummy orchestration.
Set the receive location to use the XmlReceive pipeline, so that the incoming document is identified.
To make this work, you need to make a slight code change to the generated Web service. (This is true up to and including BizTalk Server 2004 Service Pack 1, the current version when this paper was written.) Open the project and locate:
string bodyTypeAssemblyQualifiedName = "Microsoft.XLANGs.BaseTypes.Any, Microsoft.XLANGs.BaseTypes, Version=3.0.1.0, Cult" +
"ure=neutral, PublicKeyToken=31bf3856ad364e35";
And change it to:
string bodyTypeAssemblyQualifiedName = string.Empty;
You can start the orchestration. You can submit any XML document to the Web service, but if it is of type Order then it is identified and routed to the appropriate orchestration.
Exposing a Schema as a Web Service
So far we have looked at Web services only from an orchestration point of view. However, as BizTalk Server developers know, it is possible to build solutions based solely on the messaging engine, without using any orchestrations. Messaging-based solutions use content-based routing to route messages on the content of the message, the values of message context properties, or some combination of those two. Although messaging-only solutions do not allow you to inject business processes into a solution the way you can with orchestrations, you can apply maps and use custom pipelines, which in many cases is all you need to do.
To expose a messaging-only solution through Web services, you need a way to directly submit messages to the BizTalk MessageBox database. The message type needs to be determined when a message is put into the MessageBox so that BizTalk Server can identify subscribers to that message. This brings us to the second option of the Web Services Publishing Wizard, the option to publish schemas as Web services.
The way this works is similar to the act of exposing an orchestration as a Web service. You run the Web Services Publishing Wizard, it collects relevant information, and then it generates a proxy project. As was the case with publishing an orchestration, the proxy is a standard C# Web service application.
How to Expose a Schema as a Web Service
When publishing schemas as Web services with the Web Services Publishing Wizard, you see many of the same pages as when publishing an orchestration, but there are differences.
The following figure shows the wizard screen where you describe your Web service.
Figure 4 Web service description screen
[img]http://msdn.microsoft.com/library/en-us/BTS_2004WP/local/Local_382825961_webservicedescription.gif[/img]
The typical steps you follow to describe a Web service that can receive a document and return a response are:
Right-click and rename the BizTalkWebService node to something meaningful. This becomes the name of the WSDL file.
Right-click and rename the WebMethod1 node to something meaningful. This becomes the name of the exposed Web method.
Right-click the Request node, specify a DLL, and select a schema from the DLL that represents the document you will receive.
Right-click the Response node, specify a DLL, and select a schema from the DLL that represents the document you will return to the caller.
As was the case with publishing orchestrations, the properties screen allows you to specify a namespace URI, support for unknown headers, and whether to support Single Sign-On.
The Web service project screen allows you to specify what the proxy project should be named, where it should be located, whether anonymous access is permitted, and whether to automatically create the receive locations. Note that if you do not create the receive locations here, you will subsequently need to do so manually.
Advanced Web Services Considerations
This section provides additional information about working with BizTalk Server 2004 and Web services.
Working with SOAP Headers
The SOAP protocol allows you to attach information to the message header. This is information that travels with the message, but is not part of the content. The following are examples of where you might want to use SOAP headers:
A system requires you to log on, and assigns a session identifier that must be part of each subsequent message in the conversation
You need to attach user credentials to a message
Data in the header enables use of network appliances that can route messages based on header information, without needing to understand the message itself (which could be completely or partially encrypted)
You want to use header information to determine processing priority (for example, silver, gold, platinum customers) and route messages accordingly
With BizTalk Server, headers can be accessed when:
Consuming a Web service
Publishing an orchestration as a Web service
Publishing a schema as a Web service
The fact that headers are present, and whether they are required, is expressed as part of the WSDL file that the Web service publishes. Headers are optional. In the case of a request-response message pattern, headers are accessible for both the request and response messages.
When you run the publishing wizard, you specify the SOAP headers that you support for both the request and response messages. Each header type is defined by specifying a schema. You can also choose to support unknown headers, in which case any unknown SOAP headers received as part of a request are added to a SOAP.UnknownHeaders context property of the message.
If headers are received that include the mustUnderstand attribute, the Web service always returns that they were understood.
Tips for Consuming Web Services
The following are useful points to be aware of when you are consuming Web services:
BizTalk Server 2004 does not support array parameter types. If you have control over the Web service you are consuming, you can change it to instead receive/return complex objects. For example, in .NET, create a class and use an instance of that as the parameter or return value. If you do not have control over the Web service, you can write a .NET helper class that interacts with it. In addition, the WSE 2.0 adapter supports calling methods that return arrays of complex types.
BizTalk Server 2004 does not directly support messaging-only solutions that accept a message coming in and route it to a Web service. However, you can achieve the same result by writing a pipeline component or custom adapter to interact with the Web service. In addition, the WSE 2.0 adapter supports content-based routing without orchestrations.
Under high stress the SOAP send handler for solicit-response should be placed in its own host. Otherwise the orchestration puts priority on sending SOAP requests and dehydrates the orchestrations while waiting for the SOAP responses to return through the MessageBox. Even when these responses return, the host is still too busy sending SOAP requests and dehydrating schedules to find time to rehydrate orchestration schedules so that they can pick up the SOAP responses. This is extremely important because you may see significant slowness in SOAP solicit-response under high loads due to this behavior. Adding a separate send host that is dedicated to SOAP send processing mitigates this performance bottleneck.
Tips for Publishing Web Services
The following are useful points to be aware of when you are publishing Web services:
For publishing orchestrations as Web services, the documentation contains useful information about how to enable tracing and report detailed error messages. See "Debugging Published Web Services" in BizTalk Server 2004 Help.
Make sure that an Isolated Host process exists. HTTP and SOAP adapter receive handlers must run in an Isolated Host because they are outside of the BizTalk process, which is hosted in Internet Information Services (IIS). Only one adapter can run in an Isolated Host, so if you are using both HTTP and SOAP adapters you need to create an Isolated Host for each.
If your SOAP send port accesses Web services through a firewall, be sure to specify proxy server information. You can do this either at the adapter level or on the send port itself (see the "proxy" tab of the address).
There are flags that can be set to enable reporting of more detailed SOAP and security error information from an orchestration exposed as a Web service. For more information, see "Debugging Published Web Services" in BizTalk Server 2004 Help.
Microsoft Windows Server 2003 security is locked down tighter than it was in Microsoft Windows 2000. The identity of the application pool under which the Web service runs needs to be a member of the IIS_WPG and BizTalk Isolated Hosts Users groups.
If you want to publish an orchestration as a Web service that exposes simple data types (for example, a single string request parameter and a Boolean response), create messages in the orchestration that are of that type and send/receive them in the port (in the example, have a request that is of type System.String and a response that is System.Boolean).
If you are not getting the results you expect, remember to check the event log.
Troubleshooting
Although it is easy to work with Web services and BizTalk Server, you do need to build several technology links in the chain. If any of these links is broken, then the entire process may fail. The BizTalk Server documentation includes comprehensive troubleshooting information that can help you diagnose common failure causes.
The most successful approach to developing Web service-based solutions built on BizTalk Server is to proceed in a systematic and unit-based manner. Build a test harness to make sure that a consumed Web service works, make sure the orchestration works as expected before exposing it as a Web service, and so on. If you follow a methodical and systematic development approach, you will be successful and you will benefit from the advanced capabilities BizTalk Server brings to Web services solutions.
Debugging Checklist for Orchestrations Published as Web Services
You can use the following checklist to debug issues with orchestrations that have been exposed as Web services running on Windows Server 2003.
First, isolate the problem. Is it a problem in IIS or BizTalk Server?
Debugging IIS Problems
Check the Application event log.
IIS hosts the SOAP receive adapter, and changes to receive ports and receive locations do not take effect immediately, but rather are subject to the Cache Refresh interval specified for the BizTalk group. Run IISRESET to restart the service and flush the cached settings.
Check the application pool for the generated Web service in the IIS manager MMC snap-in. Is it the application pool you have set up for BizTalk Web services?
Check the identity under which the application pool is running. Is it a member of the IIS_WPG and BizTalk Isolated Host Users groups? These two groups give the ASMX page (the proxy Web service that the BizTalk Web Service Publishing wizard generated) the appropriate rights to insert the SOAP request message into the BizTalk MessageBox in SQL Server that will then launch the orchestration. Symptom may be "SoapException: Internal SOAP Processing Failure".
Make sure the user account for the application pool has read/write permissions on the %temp% folder. This is the folder where the ASMX is just-in-time (JIT) compiled into a DLL with a random eight-character name (xxxxxxxx.dll). Symptom may be "SoapException: Internal SOAP Processing Failure".
Using the IIS MMC snap-in, can you "Browse" the ASMX file?
If you did not specify anonymous access to your Web service when you ran the publishing wizard, you can temporarily allow anonymous access by using IIS (properties of the ASMX file) to eliminate invalid credentials as a point of failure.
Make sure your Web service test client is sending credentials in the SOAP method call, because in Windows Server 2003 by default the virtual directory requires Windows authentication (unless you selected the "Allow Anonymous Access" check box when you ran the publishing wizard). When you test the Web service using Internet Explorer you are using your own logon credentials, which is why it works. If your test client does not add credentials to the SOAP method call you will get a SOAP exception due to security issues. Windows Server 2003 gives you very little information about this unless you enable additional debugging/tracing. The other option is to allow only anonymous access to the Web service, but again be careful and test it because anonymous access runs with a default identity that also has to be in the IIS_WPG and BizTalk Isolated Host Users groups, and may need access to read/write in the %temp% folder.
The BizTalk Server documentation lists the following three ways in which you can see tracing information as well as more extensive error details:
Use the ThrowDetailedError Switch for the published Web service web.config file
Enable SOAP Message Tracing
Uncomment BTSWebSvcWiz.exe.config
Debugging BizTalk Server Problems
In Health and Activity Tracking (HAT), look at the Recent Services Instances. Did your message arrive?
Does the URI in the receive port match the URI of the Web service?
Is the orchestration started? Having the orchestration bound and enlisted is not enough. It must be started so that the Web service has a place to submit it to. If the orchestration is not started, you will receive a "SoapException: Internal SOAP Processing Failure" error.
Are the receive locations bound to your orchestration enlisted, and are the send ports bound to it started?
InfoPath
No discussion of how Web services relate to BizTalk Server would be complete without mentioning InfoPath, the newest member of the Microsoft Office suite of products. InfoPath is Microsoft's answer to the electronic forms question. It allows bundling XML data and presentation information in a single package, and provides a rich form development environment. An XML processing instruction can be added to an XML document to associate it with an InfoPath form, so that double-clicking the document shows the data in that form. Note that InfoPath is a client-side application, and as such needs to be installed on the computers that will be rendering the forms.
InfoPath is based on open-standards XML, and it uses standard XSD schemas for the XML data it renders, just as BizTalk Server uses XSD schemas. One facet of InfoPath that will interest BizTalk Server developers is the ability to create new forms based on a Web service. This means that you can create a BizTalk orchestration, run the Web Services Publishing Wizard, and use InfoPath to create an input form that can submit data to the Web service—all without writing any code. This is a quick and easy way to construct data input points while developing applications.
A common usage pattern for InfoPath is the case of messages that require human intervention. You can deposit the message in question into a file folder (or Windows SharePoint Services), users can make any edits or required approvals, and upon submission the form can be posted to a Web service created by the Web Services Publishing Wizard that returns the data into an orchestration's receive location.
Conclusion
The use of service-oriented architectures is currently the preferred approach to application design, and Web services can be a key enabler of SOA. BizTalk Server supports Web services in a native and intuitive manner for developers. This white paper has shown how BizTalk Server provides the building blocks required to build robust and agile business-critical applications using Web services.
About the Author
Based in San Diego, Brian Loesgen is a Principal Consultant with Neudesic, a firm that specializes in .NET development and Microsoft server integration. Brian is a Microsoft MVP for BizTalk Server 2004. He has over 18 years of experience in building advanced enterprise and mobile solutions. He is a co-author of six books, including "BizTalk Server 2004 Unleashed," and has written technical white papers for Intel, Microsoft, and others. Brian has spoken at numerous major technical conferences worldwide. He is a co-founder and President of the International .NET Association (ineta.org). He is the President of the San Diego .NET user group, leads the San Diego Software Industry Council Web Services SIG, and is a member of the Editorial Board for the .NET Developer's Journal. Brian is also a member of the Microsoft BPI Virtual Technical Specialist Team. His blog can be found at blogs.ineta.org/bloesgen.
页:
[1]