.net - 我应该使用 BizTalk 直接连接到第 3 方数据库还是在它们之间建立一个单独的层？

Question

我在一家零售公司工作，我们希望构建一个与仓库订单管理应用程序集成的统一订单输入系统。在非常高的层次上，我建议我们有一个 BizTalk 服务器，它向订单输入应用程序(或其他应用程序)公开统一的 Web 服务，并在从 SOAP 转换时使用规范的消息格式，然后再传递请求。规范消息将允许重用编排。

你能帮我理解这两个选项中哪一个最好:

我们是否应该使用 BizTalk SQL 适配器连接到托管订单应用程序的数据库(它们根本不提供任何 API，因为它们是第 3 方)从总部到仓库？

我们是否应该在 BizTalk 可以使用的仓库中构建简单的 Web 服务？

我认为 #2 是多余的工作，因为我们仍然需要在数据库记录和传入的 SOAP 消息之间进行转换(反之亦然)。然而，我的直觉告诉我这不是一个坏主意。

Answer 1

当您直接写入第三方数据库(尤其是您无法控制的数据库)时，您 tightly couple您对该外部系统的集成解决方案。第三方合作伙伴或供应商在设计其数据库时不会考虑到您，并且不会在意它何时更改其数据库并破坏您的集成。

如果除了直接与其数据库交互之外，绝对没有其他方法可以在第三方应用程序中存储/检索数据，那么您必须考虑如何以最大限度地减少耦合的方式进行。让您自己的订单输入系统直接与第三方应用程序的数据库对话当然是最糟糕的选择。

BizTalk 使得在各种消息格式之间进行转换相当容易。如果您只会在您自己的订单输入系统和单个订单管理系统之间进行映射，那么 BizTalk 对您来说可能是一个太重的解决方案。只需将您自己的接收应用程序写入第三方应用程序数据库的站点即可。

但是，如果您需要将订单输入系统转换为无数的订单管理系统，每个系统都有自己独特的架构，那么 BizTalk 可能适合您，因为它已经成熟 mapping tool用于数据转换。

在 BizTalk 之上公开 Web 服务，只是为了给您的订单输入系统提供一种与 BizTalk 通信的方式，也可能不是最佳选择。 BizTalk 通过其 adapters 支持多种通信协议(protocol)。 ，和 SOAP 或 WCF web 服务可以相当chatty并且要求接收系统在发送方尝试发送消息时在线。对于同一网络上的系统，MSMQ通常更有意义，因为它支持异步、事务性消息传递，并且随 Windows 免费提供。

如 this white paper说:

the key requirement to place an order from Customer Managment to Order Management is for guaranteed delivery, so we might use some queuing technology (such as IBM MQSeries or MSMQ) to deliver the message where performance is traded for a higher level of reliability.

掌握好 how MSMQ works 很重要，以及它的一些陷阱:

storage considerations

never read from remote message queues

cluster MSMQ to make it truly fault tolerant

...所以花点时间了解您的解决方案中的所有内容如何协同工作，即使您认为它是公平的 trivial to make a .NET application send a message via MSMQ .

如果您仍然希望从 BizTalk 公开 Web 服务，请注意不要通过将发送和接收系统硬编码到单个编排中而无意中将所有内容耦合在一起。这里有一些重要的

尽量只使用 MessageBox Direct Bound Ports .他们"yield orchestrations that are more self-contained, and therefore more reusable and easier to redeploy independently."

按照您自己的建议使用规范模式。 It's a good idea.

抵制将您的编排直接公开为 Web 服务的诱惑。当你这样做时，you tightly couple external callers of your web service to your internal business logic .

将业务逻辑(编排)与数据(模式)分开。在业务流程中嵌入 BizTalk 映射将您的逻辑和数据结合在一起。在 send 上配置您的 map /receive端口代替。

想想你是否真的需要使用编排。如果您所做的只是接收一条消息、对其进行转换并将其发送出去，那么您可能不需要编排。 The first rule of optimizing orchestration performance is to eliminate orchestrations.

如果您遵循上述建议，请使用 WCF SQL adapter写入第三方 SQL 数据库还不错，因为您已经将入站消息及其处理与出站 SQL 操作分离。当合作伙伴/供应商确实更新其数据库架构以破坏您的集成时，只需部署一个新架构，更新您的 BizTalk 映射，然后重新部署。隔离此类更改的影响意味着您只需重新测试从规范模式到外部数据库模式的转换(也许通过将数据保存到数据库的集成测试)。

表演 CRUD operations with the WCF SQL adapter很简单。如果供应商确实提供了 API，则更换不同的 BizTalk 适配器来处理通信协议(protocol)、更新您的架构/映射，并且您的订单发起系统永远不需要知道差异。