0

我们正在考虑整合 3 个不同的系统（由不同的公司拥有），这些系统需要协调数据（数据的一个企业所有者）。一种选择是使用 Web 服务将数据从一个系统推送到另一个系统。所有系统都在 sql server 上，因此复制有限数据也是可能的。

任何尝试过这两种技术的人都愿意评论利弊吗？每个系统都可能是要推送到其他系统的数据子集的主控系统。具体来说，我很好奇如何在 Web 服务中处理失败的事务。

4

1 回答 1

3

我们有一个类似的环境，我们在其中保持 3 个系统同步（Access、企业拥有的 SQL Azure 和第 3 方 SQL Azure）。我们从 Web 服务集成开始，但出于性能原因，我们正在慢慢转向更紧密的 SQL 到 SQL 复制。我们的实现是完全自定义的（不使用 SQL Server 提供的任何内置同步或复制服务），基本上使用 BulkImport 和基于集合的查询进行同步。

网页服务

优点

  • 松散耦合（如果设计正确），如果任何部分发生变化或被换掉，可以更好地进行风险管理。
  • 更好的访问控制
  • 与基于数据库的现有应用程序更好地集成。
  • 高度可扩展。

缺点

  • 移动大量数据可能非常慢。
  • 交易和数据处理必须手动处理 - 但可以完成。

SQL 集成

优点

  • 更高的吞吐量。
  • 如果表结构映射起来相对简单，则可以更容易管理。
  • 交易支持。

缺点

  • 容易犯大错误，比如抹掉整张桌子、弄乱整列等等。
  • 如果您必须为基于集合的复制滚动自己的集成，则很难构建可靠的错误处理。
  • 如果表的结构非常不同，即一个是像我们的系统一样的 EAV 模型，系统之间的紧密集成将非常困难。

如果我可以选择并且性能不是问题，我肯定会选择 Web 服务。我们的 3 个系统的本质是它们具有非常不同的表结构，因此将后端表结构抽象为一个简单的 POCO 数据结构的 Web 服务可以让事情变得更简单。此外，三个系统中的一个驱动一个网站，该网站公开一个“正常工作”的 Web 服务，而不用担心缓存记录、同步更新等。

我们目前通过 Web 服务集成处理事务更新的方式是这样的（服务器应该是更复杂且更有可能失败的一方）：

  1. 客户端启动与服务器的连接。
  2. 客户端开始本地事务。
  3. 服务器开始本地事务。
  4. 服务器处理请求。
  5. 服务器根据成功/失败提交/回滚本地事务。
  6. 服务器发回带有成功/失败和错误消息的响应。
  7. 客户端处理响应。
  8. 客户端根据成功/失败提交/回滚本地事务。
于 2013-02-26T22:29:10.790 回答