Siebel 集成中的“发布-订阅”与“阅读”

将 Siebel 应用程序中存储的数据提供给企业中的其他应用程序时，通常需要遵循以下两种基本模式之一：

1. 发布-订阅
2. 阅读

“发布-订阅”是一种机制，根据该机制，一个系统（发布者）将更改或更新的数据提供给其他系统；其他系统（订阅者）注册以示它们希望接收数据更改以及数据事件的通知。

“阅读”机制实际是大量其他模式（如事件驱动的客户、点对点、选择性客户、事务客户端等）的混合。任何符合“使用者请求数据，提供者发送数据”这一原则的模式都可视为该超集的一部分。与“阅读-发布”模式不同，“阅读”模式不需要使用某种中间件（或者在
Siebel 应用程序中进行大量编码），因此该模式无疑可被视为点对点模式。

这两种模式都具有自己的优点和缺点，都具有自己关于特定集成以及整个企业集成基础架构的需要和假设。Siebel（或任何其他应用程序）的需要和约束通常会与融合中间件平台截然不同，有时可能是对一方直观而对另一方不直观。

发布-订阅

“发布-订阅”模式的基本概念是，订阅者接收数据集 更新，这暗示每个订阅者必须拥有一份要使用的数据的副本。因此，如果使用“发布-订阅”模式的企业有 n 个订阅者，就会有 n 个记录。

对于小型数据集，该数量不会过大；但是对于大型数据集，例如销售报价或订单，该数量很快就会影响整个企业的容量规划。

“发布-订阅”模型另一个要考虑的问题是主数据问题，即“您对复制的数据有多信任？”，或许应该是“ Blade Runner”问题！如果使用“发布-订阅”模式的企业有多个数据副本，那么每个系统从哪里获取数据？当然，正确答案是从中间件以及数据的主系统获取，但是如果下游系统直接访问众多副本中的一个，会发生什么情况呢？如果访问的副本并不是最新数据副本，会发生什么情况？
啊，太可怕了。因此，如果需要事务数据，使用“发布-订阅”模式需要慎重考虑。

那么，从应用程序的角度来看，“发布-订阅”模式的优点是什么？对于易变性相对较低的参考数据集（例如，“联系人”或“帐户”），使用“订阅-发布”模式可以很好地将数据复制到下游系统，以允许它们使用数据集并以“接近实时”的方式进行更新（我只是喜欢“接近实时”这种表达，事物或者是实时的，或者不是实时的……“接近”毫无意义）！

阅读

“阅读”模式和“发布-订阅”模式最基本的差异是效率。假设某个帐户以“发布-订阅”模式进行了更新并且该更改将传送到
10 个下游系统，则将从 Siebel 传递一个消息到中间件，然后再传出 10 个消息，分别到达各个订阅系统。使用“阅读”模式时，如果这 10
个下游系统需要访问该帐户，则 每次请求该数据时 都需要总共 40 个消息。

“阅读”模式的数据传输“低效性”是集成架构师更喜欢采用“发布-订阅”模式的首要原因。但是有些情况下，确实需要使用“阅读”模式。“发布-订阅”模式出现问题时就需要“阅读”模式大显身手了，如以下情况：不需要复制数据，否定整个企业的数据完整性问题，以及避免整个订阅系统的容量“复杂化”。对于易变性较高的事务数据，“阅读”模式通常是不错的选择。

因此，总的来说，没有任何一种方法是执行集成的“正确”方法，每个客户情况都不一样，在各个阶段，都需要慎重考虑技术和组织双方面的驱动因素，然后再给出一致的策略。我个人认为，应该始终对采取决策所涉及的相关事项加以试验和考虑，因为孤立地进行
Siebel 集成甚至 Oracle 部署的时代已经过去了。