我在一家零售公司工作，我们想要构建一个统一的订单录入系统，与仓库的订单管理应用程序集成。在非常高的层次上，我建议我们有一个BizTalk服务器，它向订单输入应用程序(或其他应用程序)公开统一的web服务，并在传递请求之前，在从SOAP转换时使用规范化消息格式。规范化消息将允许重用编排。
你能告诉我这两个选项哪个最好吗?
我们是否应该使用BizTalk SQL适配器连接到从总部到仓库的托管订单应用程序的数据库(这些应用程序根本不提供任何API，因为它们是第三方)?
我们应该在仓库中构建BizTalk可以使用的简单web服务吗?
我认为#2是多余的工作，因为我们仍然需要在数据库记录和传入SOAP消息之间进行转换(反之亦然)。然而，我的直觉告诉我，这不是一个坏主意。
当您直接写入第三方数据库(特别是您无法控制的数据库)时，您的集成解决方案将与该外部系统紧密耦合。第三方合作伙伴或供应商不会考虑您来设计其数据库，也不会在意它何时更改其数据库并破坏您的集成。
如果除了直接与第三方应用程序的数据库交互之外，您找不到其他在第三方应用程序中存储/检索数据的方法，那么您必须考虑如何以最大限度地减少耦合的方式做到这一点。当然，让您自己的订单输入系统直接与第三方应用程序的数据库对话将是最糟糕的选择。
BizTalk使各种消息格式之间的转换相当容易。如果您只需要在您自己的订单输入系统和单个订单管理系统之间进行映射，那么BizTalk可能对您来说是一个太重的解决方案。只需在第三方应用程序的数据库上编写自己的接收应用程序。
但是，如果您需要从您的订单输入系统转换到无数的订单管理系统，每个系统都有自己独特的模式，那么BizTalk可能很适合您，因为它具有成熟的数据转换映射工具。
在BizTalk之上公开web服务，仅仅是为了给你的订单输入系统提供一种与BizTalk通信的手段，也可能不是最好的选择。BizTalk通过它的适配器支持许多通信协议，SOAP或WCF web服务可以是相当健谈的，并且要求接收系统在发送者尝试发送消息时在线。对于同一网络上的系统，MSMQ通常更有意义，因为它支持异步、事务性消息传递，并且是免费的。
正如白皮书所说:
从客户管理到订单下订单的关键要求管理是为了保证交付，所以我们可能会使用一些排队技术(如IBM MQSeries或MSMQ)来传递消息性能是以更高的可靠性为代价的。
了解MSMQ是如何工作的，以及它的一些缺陷是很重要的:
- <
- 存储考虑/gh>
- 从不从远程消息队列中读取
- 集群MSMQ，使其真正容错
…所以，花点时间去理解你的解决方案中的所有东西是如何协同工作的，即使你发现让。net应用程序通过MSMQ发送消息相当琐碎。
如果您仍然想要从BizTalk公开web服务，请注意不要通过将发送和接收系统硬编码到单个编排中而无意中将所有内容耦合在一起。以下是一些重要的
- 尝试只使用消息框直接绑定端口。它们"产生更加自包含的编排，因此更加可重用，并且更容易独立重新部署。"
- 按照您自己的建议使用规范模式。这个主意不错。
- 抵制直接将业务流程公开为web服务的诱惑。当你这样做时，你就把你的web服务的外部调用者和你的内部业务逻辑紧密地耦合在一起了。
- 保持业务逻辑(编排)与数据(模式)分离。在编排中嵌入BizTalk地图将逻辑和数据结合在一起。在发送/接收端口上配置映射。
- 考虑你是否真的需要使用编排。如果您所做的只是接收消息、转换消息并将其发送出去，那么您可能不需要编排。优化编排性能的第一条规则是消除编排。
如果您遵循上述建议，那么使用WCF SQL适配器写入第三方SQL数据库并不是太糟糕，因为您将从出站SQL操作中解耦入站消息及其处理。当合作伙伴/供应商更新其数据库模式以破坏您的集成时，只需部署一个新模式，更新BizTalk地图，然后重新部署。隔离这种更改的影响意味着您只需要重新测试从规范化模式到外部数据库模式的转换(可能使用将数据保存到数据库的集成测试)。
使用WCF SQL适配器执行CRUD操作非常简单。如果供应商确实提供了API，那么换出不同的BizTalk适配器来处理通信协议，更新模式/映射，您的订单发起系统永远不需要知道其中的区别。
Schellack关于可靠和异步耦合系统(例如通过队列)的观点在我看来永远是头等大奖。
然而，如果你真的不能在你的公司内出售排队解耦策略，并且他们仍然坚持通过SQL直接耦合到第三方系统，那么你应该考虑以下内容:
- 使用WCF SQL适配器
- 确保你没有通过直接访问数据库来取消供应商产品的任何保修或支持协议(尽管即使你编写web或windows服务，如果没有API，这些最终也需要访问供应商数据库)。
- 封装您通过SQL存储过程和视图对供应商数据库的任何访问，并确保您对数据库的任何更改都在您自己的
database schema中-这使得更容易识别对第三方系统的自定义修改，例如在第三方系统升级期间。 - 请注意，在高容量期间，BizTalk可能会对下游系统施加极端负载。你将需要一些机制来限制施加在下游系统上的负载，例如，通过调整适配器设置或在BizTalk中实现单例/多例。
从数据库中提取数据时也是如此:
- 将pull封装在进程中，限制一次记录的数量(例如SELECT TOP *)并调整轮询频率。 在提取数据时，您还需要一个透明的机制来标记记录为
- 对于提取数据，请记住在设计中考虑并发性问题，可以并发触发多个SQL适配器实例(例如
Poll While Data Found)
read，而不会干扰第三方数据库。有一个很好的写在这里写一个好的'pull data'过程。