我正在编写一个 biztalk 编排，需要调用一个 Web 服务，可能是多个 Web 服务，而且可能不止一次。我面前有两个选择：一，在单独的代码项目中使用 wsdl，并从表达式形状的代码中调用 Web 服务，二，从 Biz 使用它，获取架构等，并通过请求/响应端口进行调用。这里的最佳实践是什么？一方面，如果更新了 wsdl，那么更新代码将比更新架构和端口更容易，而且构建足以用于多个 Web 服务调用的端口似乎会很混乱，需要做很多工作。另一方面，您可以在端口级别进行的所有调整（重试一次）使得调用 Web 服务变得稳健。
另请参阅这个问题here，其中讨论了第三个选项，即使用add service reference在 BizTalk 中作为导入 XSD 的替代方法。
在我看来，如果您使用 .NET 代理来处理集成，那么您就失去了使用 BizTalk 的意义。例如：
- 您正在对协议 (WCF) 进行硬编码，现在需要将请求和响应消息编组到自定义代码/从自定义代码编组。通过发送端口，可以在部署时配置任何请求-响应机制 - 对于单元和集成测试特别有用。
- 您将失去 BizTalk 消息传递机制的所有优势，例如重试、备份传输、恢复挂起的消息、不同端口的不同映射，以及可以说的整个 pub sub 功能（例如，如果多个侦听器想要侦听来自被调用 Web 服务的响应？）
- Where will you store the WCF
serviceModel config settings, such as the endpoint etc? i.e. You've lost the flexibility of binding files.
因此，TL;DR 始终在 BizTalk 中使用 WCF 适配器
然而，话虽如此，我同意如果消费的服务发生变化，更新生成的项目可能会很混乱。 FWIW，我们通过以下方式缓解了其中的一些问题：
- 始终创建一个单独的空文件夹，在其中导入所有
导入生成的工件。
- 将所有生成的项目保留为“原样”，即不要试图移动虚拟 .odx，或删除它（因为它具有预配置的端口类型）
不幸的是，这使得以下操作仍然需要手动应用：
- 请记住将端口类型的可见性更改为
public如果工件位于与您的编排不同的程序集中
- 需要重新应用导入模式上的升级和区分属性（例如，记住在进行任何更改后记录屏幕截图）。可能可以通过保存并重新粘贴来简化或自动化
<xs:annotation>架构的部分。
- 如果您在 WCF 服务中使用消息协定，并且在多个应用程序中重复使用相同的引用消息，则需要手动删除由添加生成的项目创建的重复项，然后重新引用现有架构。 （例如，我们有一个标准的“响应”消息返回所有 BizTalk 调用）
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
