我写一个BizTalk业务流程将需要调用Web服务，可能是多个Web服务，并且可能不止一次。 我看到在我面前两个选项; 一个，消耗在一个单独的代码项目的WSDL，并调用从代码的Web服务中的表达形状，和两个，从商务消费它，得到的模式等，并通过调用请求/响应端口。 什么是这里最好的做法是什么？ 一方面，如果WSDL更新它会更容易更新比模式和端口的代码，这似乎是一个很大的混乱，并努力建立足够多的Web服务调用接口。 在另一方面，所有的调整，你可以在端口级别（重试是一个），这样做使得它稳健的调用Web服务。
Answer 1:
也看到这个问题在这里 ，它讨论了第三选项，即使用add service reference的BizTalk作为一种替代方法导入XSD的。
IMO你会打败使用BizTalk使用.NET代理来处理的结合点。 例如：
- 您是硬编码协议（WCF），现在需要从您的自定义代码元帅请求和响应消息/。 与发送端口，任何请求 - 响应机制可以在部署时被配置 - 为单元和集成测试特别有用。
- 你将失去所有的BizTalk的消息传递机制，如重试，备份传输，恢复暂停的消息，不同的地图不同的端口，可以说是整个酒吧子的能力，（例如，如果有什么多的听众要听的益处从所谓的Web服务的反应？）
- 你会在哪里存储WCF
serviceModel配置设置，如端点等？ 即你已经失去的绑定文件的灵活性。- 等等
因此，TL; DR始终使用在BizTalk的WCF适配器
但是，这么说，我在更新生成项目，如果食用服务的变化可以是混乱的协议。 FWIW，我们减轻一些具体步骤如下：
- 总是创建在其中导入所有导入的生成的工件的单独的空文件夹。
- 保留所有生成的项目“原样”，即做到不动心移动虚拟.odx，或者将其删除（因为它具有预配置的端口类型）
不幸的是这叶子仍然需要手动应用以下操作：
- 记住的端口类型的可见性改变
public如果文物是在一个单独的组件，您的业务流程 - 提倡和需要重新应用在导入的模式杰出的性能（如记住任何变更后记录截屏）。 可能这可以简化或通过保存并重新粘贴在自动化
<xs:annotation>的SCHMA的部分。 - 如果您使用的是WCF服务合同的消息，并重复使用跨多个应用程序相同的引用的消息，您将需要手动删除添加生成项目创建的副本，然后再参考现有的模式。 （例如，我们有一个标准的“响应”消息发送回所有的BizTalk呼叫）
Answer 2:
有趣的是，你可以同时拥有INFACT的混合物。 检查这出由Saravana库马尔！
它采用直通接收和使用消耗的发送端口上的dll Web服务，而无需通过创建模式和webports的痛苦去。
这给了Biztalk的所有的电源（路由响应，发送端口配置等），还可以灵活地更改架构无需大惊小怪。
文章来源: Biztalk and the best way to call web service
