使用 ESB 和消息中间件的 IPC 设计

Question

首先，在我失去你的注意力之前，我会写下我认为解决我的问题的过程。我的问题和现有设置如下。这是我认为应该发生的事情，以允许 future 的灵活性。请指教:

创建或修改记录时，数据库触发器会填充 SQL Service Broker 和 Oracle Advanced Queuing。

进程监视 SQL 和 Oracle 消息队列并将它们发送到 ESB。

ESB(UltraESB？，易于设置和理解)依次将消息发送到真正的消息队列(RabbitMQ？易于设置和理解)。 ESB 可能会丰富、路由等。

最后，其他一些进程使用 RabbitMQ 并指示 DMS 做什么:创建新策略文件夹、更新策略元数据等。

三重队列 MSSQL、Oracle 和 RabbitMQ 似乎有点矫枉过正，但另一方面，它们都执行不同的操作。

现有设置:

我有一个全新的消息传递/ESB/中间件/SOA 环境，并希望正确设置它以首先处理下面的问题。

LOB-A:在 MS SQL 2008 数据库上用 JAVA 编写的保险应用程序

LOB-B:在 Oracle 10.2 数据库上用 Visual Basic 6 编写的保险应用程序

DMS:Microsoft SharePoint 2010

这两个 LOB 应用程序都可能在 future 18 个月内被替换

future 可能会有更多的保险应用程序以及CRM

问题:

两个 LOB 应用程序都需要通过在创建新策略、客户等以及修改它们时发出信号来与文档管理系统交互。我们无权访问 LOB-A 源代码进行修改。我们确实可以访问 LOB-B 源代码，但开发人员正忙于其他项目。无论如何，我们认为更容易让数据库在记录更改时向 DMS 发出警报，而不是在应用程序的源代码中定位记录可能更改的所有位置并通过应用程序层发出警报。

我知道 Database-as-IPC 是一种反模式，尽管我已经阅读了有关如何最好地实现这一点的建议，至少对于 SQL Server: Best way to use a DB table as a message/job queue和 http://rusanu.com/2010/03/26/using-tables-as-queues/ .我已经使用 SQL Service Broker External Activation 从 LOB-A 向 DMS 发送信号以点对点的方式。

哇!你怎么看？

Answer 1

免责声明:我是 AdroitLogic 的 CTO，它构建了问题中提到的 UltraESB

您可以轻松地让 ESB 本身轮询 MS SQL 和 Oracle 数据库以获取要执行的新操作。这可以在 ESB 中安排，给出一个 cron 时间表等，或者一个简单的延迟(例如每小时)。 ESB 可以丰富、转换和路由等，但是您需要一种方法来跟踪哪些记录已被成功处理——也许是轮询表中的一个新列？一旦可用，您就真的不需要持久消息队列，因为 ESB 可以轮询未处理的记录，对它们执行任何预期的操作，并将它们发布到 DMS - 并将状态更新为成功或失败。除非 DMS 拒绝或变得不可用，否则没有重试的真正意义，但您可能想要这样做，这也是可能的。如果 DMS​​ 接受记录，ESB 可以直接更新表列。如果您真的想使用消息队列 - 这当然也是可能的，这取决于您的选择。