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

标签 ipc soa messaging esb middleware

首先,我会写下我认为应该在引起您注意之前解决我的问题的过程。我的问题和现有设置如下。我认为应该采取以下措施以实现 future 的灵活性。请指教:

  1. 创建或修改记录时,数据库触发器会填充 SQL Service Broker 和 Oracle Advanced Queuing。
  2. 进程监视 SQL 和 Oracle 消息队列并将它们发送到 ESB。
  3. ESB(UltraESB?,易于设置和理解)依次将消息发送到真正的消息队列(RabbitMQ?易于设置和理解)。 ESB 可能会丰富、路由等。
  4. 最后,一些其他进程使用 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 应用都可能在未来 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 queuehttp://rusanu.com/2010/03/26/using-tables-as-queues/ 。我已经使用 SQL Service Broker External Activation 从 LOB-A 向 DMS 发出信号以点对点的方式。

哇!你觉得怎么样?

最佳答案

免责声明:我是 AdroitLogic 的 CTO,该公司构建了问题中提到的 UltraESB

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

关于使用ESB和消息中间件的IPC设计,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/18531535/

相关文章:

java - kafka vs 编年史队列 vs 破坏者

rest - 谁需要 (SOAP) 可靠的消息传递?

c - 等待无法同步三个进程

c - 删除消息队列

web-services - OAuth 2.0 多范围(客户端凭据案例)

javascript - 背景内容脚本消息 : message sent before content script is ready

linux - Golang、进程和共享内存

serialization - 通过MessageBox输入数据?

web-services - 使用 Soap 请求发送客户端证书和授权 header 的理想方式是什么

domain-driven-design - 订单和库存 DDD - 应该在哪里处理分配/保留?