我要求为以下Java Web应用程序提供合适的架构：
目标是构建多个Web应用程序，这些应用程序都在相同的数据上运行。假设一个银行系统，其中不同的Web应用程序可以访问帐户数据;它可以由客户（网上银行），服务人员（主要是阅读）和帐户管理部门（管理工具）访问。这些应用程序在不同的计算机上作为单独的Web应用程序运行，但它们使用相同的数据和一组常见的数据操作和搜索查询。
一种可行的方法是构建一个适合客户共同需求的核心应用程序，即数据存储，操作和搜索工具。然后，客户端可以调用此核心应用程序来完成其请求。要求是应用程序构建在Wicket / Spring / Hibernate堆栈之上作为WAR。
为了得到一张图片，以下是我们想到的一些可行方法：
一种单一的方法。构建一个适合所有需求的巨大Web应用程序（这不是一个真正的选择）
B API方法。构建核心数据库访问API（JAR）以进行数据访问/操作。每个Web应用程序都构建为一个单独的WAR，它使用API来访问数据库。没有单独的核心应用程序。
C RMI方法。核心应用程序作为独立应用程序（可能是WAR）运行，并通过RMI（或HttpInvoker）提供服务。
D WS方法。就像C一样，但用网络服务取代RMI
E OSGi方法。将所有组件构建为OSGi模块，并在OSGi容器中运行。可能使用SpringSource dm Server或ModuleFusion。由于某些原因，这种方法不适合我们......
希望我能说清楚问题。我们只是选择B，但我对此并不十分自信。你有什么看法？还有其他方法吗？每种解决方案有哪些缺点？
答案 0 :(得分：3)
我认为你必须从相反的方向 - 从下往上。当然，你必须前后回来验证一切正在播放，但这是一般方向：
考虑您的数据 - 数据库方案，交易如何重要（例如在银行系统中，一切都与交易有关）等。
然后定义公共访问方法 - 从存储过程集到分布式事务引擎......
下一步是业务逻辑/演示 - 可以概括的是什么以及定制的主题是什么。
最后阶段是界面，可视化和报告
答案 1 :(得分：2)
B，C和D都是完成同样事情的不同方法。
我的第一个想法是简单地让所有消费者代码连接到公共数据库。这肯定是可行的，并且会消除您不想放在中间的代码。当然，缺点是如果架构发生变化，所有消费者都需要更新。
您可能需要考虑的另一个解决方案是为每个消费者提供自己的数据库，使用某种复制方式使其保持同步。
答案 2 :(得分：2)
由于各种原因，您在问题中说明了A和E看起来不合适。选项A将是一个巨大的应用程序，将来会使维护变得困难。
B，C和D在架构上基本相同，因为它们涉及从各种Web应用程序远程访问公共库，唯一的区别是传输机制。我建议在EJB 3或Spring中实现它，如果可能的话，而不是使用自己的RMI库，因为这些都提供了一个比RMI / Webservices更好的框架。
所以我认为这个问题基本上归结为以下两个选项：
1）将业务和DAO层类包含在所有Web应用程序部署中包含的通用jar中。
优势：
<强>缺点：
2）在单独的应用程序服务器中部署业务服务和DAO层类，并远程公开业务方法。
<强>优点：
<强>缺点：
在这两种情况下，如果接口发生变化，客户端代码将需要更改，因此这不是决策的一个因素。应该在业务服务方法级别处理事务，因此这也不应该是一个因素。
我认为这取决于应用程序的大小以及解决方案需要的可扩展性，以保证上述选项2的额外复杂性。
答案 3 :(得分：1)
我认为您需要一个单独的应用程序，所有客户端应用程序将用作它们的数据层。这样做的原因是您希望确保他们都以相同的方式访问数据库。还有一些竞争条件，你可以进入数据库事务可能无法阻止。另一个原因是使用数据库作为RPC的一种形式是已知的反模式。如果您的所有应用程序直接访问数据库，您几乎不可避免地会得到一些“事件”表，各种应用程序会定期轮询这些表...不要这样做。
答案 4 :(得分：0)
除了提供的响应之外，如果您正在考虑让多个应用程序同时使用数据库，请考虑将分布式缓存作为解决方案的一部分。分布式缓存的优点在于，除了分发之外，它可以由多个应用程序同时访问。我不确定这是否适用于所有Java变体，例如Ehcache等，因为我不是来自Java背景。
我们目前正在做的是将数据抽象得比以前更进一步。我们现在有一个可以直接访问的DAL，但是我们在DAL前面放了一个“模型工厂”。模型工厂的目的是代理缓存和数据层，充当直通。因此，调用者总是直接调用模型工厂而不是DAL或缓存代码。该抽象层基本上将在缓存未命中时从DAL检索数据，而不会增加API的复杂性。