如何用Java设计2/3层分布式应用程序？

Question

我的任务是设计一个分布式系统，该系统基本上由一个集中共享数据库和多个胖客户端（基于Swing的GUI）组成，这些客户端应该与该数据库交互。我基本上想管理一些地址，截止日期，任务等。我目前正在使用Java 6 SE，JPA（eclipse-link）和MySQL数据库。现在我遇到了一些问题：

• 客户端1如何通知客户端1对数据库提交的数据更改？使用RMI方法进行消息传递是一个好主意吗？

• 我正在处理过时的数据，因为JPA EntityManager会缓存查询结果。向所有活动客户端广播“db-change”消息是否有意义，可以刷新本地缓存的实体对象？

• 使用像GlassFish这样的应用服务器，是否有更简单的方法来实现这些目标？或者Java EE应用程序服务器的使用是否只对Web开发有利？ （对不起这些新手问题，但我真的没有通过阅读Java EE文档找到任何明确的答案，或者我根本没有得到它： - / ...）

非常感谢任何帮助 - 非常感谢提前！

Answer 1

使用像GlassFish这样的应用服务器，是否有更简单的方法来实现这些目标？

这是3层设置中应用程序服务器（与Web服务器不同）的精确点。当然，您可以轮询和/或使用消息传递来为元数据（例如数据库更改事件）通信提供额外的挂钩，但是最终会很难重新发明一个众所周知的（并且非平凡的）轮（例如，分布式中的数据同步）层）。

如果你可以在没有缓存客户端的查询结果的情况下生活，并且可以接受访问服务器（第二层）进行数据访问的延迟，那么显然这是可行的方法。

[下面是相当晚的p.s.但是今天碰巧再次阅读这个问题，并且个人觉得需要澄清。]

Java EE是一种基于分布式容器/组件的企业级架构。撇开J2EE组件市场的失败（虽然有些人尝试过），剩下的就是其COA的事实及其作为架构基础关注的分发的固有支持。请注意，Java EE的Web配置文件（例如“web-server”）也是同一架构的一部分。

那么当您使用其中一个Java EE应用程序服务器时，您会得到什么？它将如何解决您的需求/设计问题。

Java EE提供的分发支持的两个重要关键方面是它（a）分布式名称空间（JNDI），以及（b）跨层连接的产品菜单（纯RMI（你自己推出）基于分布式RPC的系统），Enterprise Beans又称EJB（远程和本地公开的组件接口，在可分发容器中的查找和生命周期方面具有明确定义的语义）。在EJB风格中，就连接语义而言，您有消息传递（JMS） ）和直接RPC。

对于您的情况，您可以选择具有胖客户端JMS端点和MessageDrivenBean EJB的JMS消息总线。您可以设计一个包含基于主题/订阅和直接队列的消息传递域。这些可以声明性地配置为持久或不持久等。

您的应用程序服务器c /将提供此JMS提供程序，或者您可以选择最佳类型，例如TIBCO，根据您的需求，满足您的需求。

你并没有重新发明任何上述非常重要的问题。您的重点仍然是您的域名要求，并且您拥有在某些合理的SLA中创建平台所需的所有工具。

一个可行的替代方案是使用独立的OSS软件（例如，使用独立的OSS软件）来构建可归结为同样精确的东西，减去Java EE的COA方法（这两种方法都可以获得声明性魔法和皮塔开发仪式）。 ØMQ用于你的总线，REST远程RPC，以及可能的REDIS，以加强你的消息的持久性保证，并协调（没有JNDI ..）你的分布式球在空中。

我个人更喜欢后者，因为它对我来说是更有趣。由于对分布层的更直接控制而获得的效率允许在非常严格的要求（例如，极少数要求）的情况下获得可扩展性增益。

企业的分布式系统设计（“已经完成任务”）需要考虑的业务需求不仅仅是应用程序域。这是等式的一部分。

希望这有用（及时;）

Answer 2

由于您使用的是JPA，因此可以从entity locking and concurrency mechanisms中受益。

JPA有两个主要概念（引用自Java EE 6教程）：

  

乐观锁定：

     

默认情况下，持久性提供程序使用乐观锁定，其中，   在提交对数据的更改之前，持久性提供程序会进行检查   自从没有其他事务修改或删除数据   数据已被阅读。这是通过中的版本列来完成的   数据库表，在实体中具有相应的版本属性   类。修改行时，版本值会递增。

     

悲观锁定：

     

悲观锁定比乐观锁定更进一步。同   悲观锁定，持久性提供程序创建一个事务   在事务发生之前获得对数据的长期锁定   已完成，可防止其他事务修改或   删除数据直到锁定结束。悲观锁定是一种   当底层数据是乐观锁定时，策略更好   经常被许多交易访问和修改。

选择最适合您的应用行为和功能要求的策略。

Answer 3

胖客户端可以按配置的时间间隔进行轮询。这类似于outlook等邮件客户端，用于查询新的电子邮件。

Answer 4

您的客户从概念上连接到包含“业务逻辑”的“中间层”。

您的客户端将所有请求发送到“中间层”，而“中间层”会将它们预先形成。这意味着，如果中间层关心协调客户端，则中间层可以记住哪些客户端“查看”了一个重要对象，并且（如果技术支持它）可以将更新传输到适当的客户端。

客户端主要包含用于在此方案下显示数据的代码，以及它们包含的用于接受请求的代码，主要代理请求到中间层。