首先,我会在失去你的注意力之前写下我认为应该解决问题的过程。我的问题和现有设置在下面进一步说明。以下是我认为应该允许未来的灵活性。请指教:
三重排队,MSSQL,Oracle和RabbitMQ看起来有点矫枉过正,但另一方面它们都表现不同。
我有一个绿地消息/ ESB /中间件/ SOA环境,并且想要正确设置它以便首先处理下面的问题。
两个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。
呼!你觉得怎么样?
答案 0 :(得分:3)
免责声明:我是AdroitLogic的首席技术官,负责构建问题中提到的UltraESB
您可以轻松获取ESB本身以轮询MS SQL和Oracle数据库以执行新操作。这可以在ESB中安排给出cron时间表等,或者简单的延迟(例如每小时)。 ESB可以丰富,转换和路由等,但是您需要一种方法来跟踪哪些记录已成功处理 - 可能是轮询表中的新列?一旦可用,您实际上不需要持久消息队列,因为ESB可以轮询未处理的记录,对它们执行任何预期操作,并将它们发布到DMS - 并将状态更新为成功或失败。除非DMS拒绝或变得不可用,否则没有真正的重试点,但您可能想要这样做,这也是可能的。如果DMS接受记录,则ESB可以直接更新表列。如果你真的想要使用消息队列 - 这当然也是可能的,并且取决于你的选择。