web-services - Biztalk 和调用 Web 服务的最佳方式

Question

我正在编写一个 biztalk 编排，它需要调用一个 Web 服务，可能是多个 Web 服务，而且可能不止一次。我看到摆在我面前的两个选择；一，在单独的代码项目中使用 wsdl，并从代码中以表达式形式调用 Web 服务，二，从 Biz 使用它，获取模式等，并通过请求/响应端口调用。这里的最佳做法是什么？一方面，如果更新了 wsdl，那么更新代码将比更新模式和端口更容易，而且为多个 Web 服务调用构建足够多的端口似乎会造成很多困惑和工作。另一方面，您可以在端口级别进行的所有调整(重试一次)使调用 Web 服务变得健壮。

Answer 1

另请参阅此问题 here ，其中讨论了第三个选项，即使用 add service reference在 BizTalk 中作为导入 XSD 的替代方法。

IMO 如果您使用 .NET 代理来处理集成，那么您将无法使用 BizTalk。例如:

1. 您正在对协议(protocol) (WCF) 进行硬编码，现在需要将请求和响应消息编码到您的自定义代码或从您的自定义代码中传出。通过发送端口，可以在部署时配置任何请求-响应机制 - 特别适用于单元和集成测试。
2. 您将失去 BizTalk 消息传递机制的所有优势，例如重试、备份传输、恢复挂起的消息、不同端口的不同映射，以及可以说是整个发布订阅功能(例如，如果多个监听器想要听取被调用网络服务的响应？)
3. 您将在哪里存储 WCF serviceModel配置设置，例如端点等？也就是说，您已经失去了绑定(bind)文件的灵 active 。
   • 等

所以，TL;DR 始终在 BizTalk 中使用 WCF 适配器

不过，话虽如此，我同意如果消费的服务发生变化，更新生成的项目可能会很困惑。 FWIW，我们通过以下方式缓解其中一些问题:

• 总是创建一个单独的空文件夹来导入所有导入生成的工件。
• 保留所有生成的项目“原样”，即不要试图移动虚拟 .odx 或删除它(因为它具有预配置的端口类型)

不幸的是，这留下了仍然需要手动应用的以下操作:

• 记得将端口类型的可见性更改为 public如果工件在您的编排的单独程序集中
• 需要重新应用导入模式的提升和区分属性(例如，记住在任何更改后记录屏幕截图)。可能这可以通过在 <xs:annotation> 中保存和重新粘贴来简化或自动化。模式的一部分。
• 如果您在 WCF 服务中使用消息协定，并且在多个应用程序中重复使用相同的引用消息，则您需要手动删除由添加生成的项目创建的重复项，然后重新引用现有架构。 (例如，我们对所有 BizTalk 调用都有一个标准的“响应”消息)