我们有一个J2EE应用程序，我们仍在使用它。它在Oracle DB上运行。并且业务层使用具有丰富客户端接口的EJB 2.0进行编码。
现在，该应用程序将部署在多个站点上。每个网站都将创建新项目（新合同等）。
我们想要实现的是使用与本地数据库模式相同的数据库模式复制添加到中央位置数据库的所有新项目。
您认为最有效的方法是什么？
我考虑过序列化所有创建的新项目并将它们发送到远程站点以便通过Java Message Service队列进行集成。那方法好吗？
并且还会有一些变化被复制回卫星。
答案 0 :(得分：2)
我想说与中心的同步关系引入了你不想要的耦合。因此，你的异步想法似乎对我很好。您可能在记录中有一些与位置相关的标识符，这样不同位置的新合同创建就不会发生冲突，并且您在向中心复制时会接受一些延迟。
因此，简单的情况是只使用从每个位置到中心的JMS消息。
关于这个appraoch的好处是，卫星甚至不需要知道中心的数据库结构，它可以完全理想地设计。
如果您还需要将更改从中心复制回卫星，事情会变得更有趣。最大的问题是，我们是否可能会在中心的变化和卫星的变化之间产生冲突。
简单案例：任何数据项都有一个“主页”。例如，原始卫星是进行改变的地方。或者在创建之后，中心是唯一可以进行更改的地方。在这种情况下，我们可以将中心视为“枢纽”，它可以传播卫星的变化。简单的JMS就可以了。
稍微更难的情况：可以在任何地方进行更改，但一次只能在一个地方进行。因此，如果锁定方案我们可以引入somne类型。我倾向于将Center作为所有者，并使用同步Web服务来锁定和更新数据。现在我们已经结合了，但如果我们要拥有一个明确的所有者，这是必要的。
相当复杂的情况：任何人都可以在没有锁定的情况下改变任何地方这是一种“先行动，后来道歉”的方法。我们采取乐观的态度，改变不会发生冲突。我们可以将更改发送给中心，中心可以使用乐观锁定或合并非冲突的更改方法。我倾向于通过对发起者进行排队更改来实现这一点，但实际上是通过同步调用来处理它们。因此，将变更规范与中心的可用性脱钩。一些更复杂的数据库具有差异/合并功能，可能有助于此。
重大问题是您希望与中心的可用性以及发生冲突变化的可能性相关联的程度。狡猾的应用程序设计通常可以大大降低冲突的可能性。