我的任务是设计一个基本上由一个集中共享数据库和多个胖客户端（基于Swing的GUI）组成的分布式系统，这些客户端应该与此数据库进行交互。我基本上想管理一些地址，截止日期，任务等。我目前使用Java 6 SE，JPA（eclipse-link）和MySQL数据库。现在我面临一些问题：如何在Java中设计2/3层分布式应用程序？
客户端2如何通知客户端1向数据库提交的数据更改？使用RMI方法进行消息传递是一个好主意吗？
我正在处理陈旧的数据，因为JPA EntityManager会缓存查询结果。向所有活动客户端广播“db-change”消息是否有意义，他们可能会刷新本地缓存的实体对象？
是否有更简单的方法通过使用像GlassFish这样的应用服务器来实现这些目标？或者，Java EE应用程序服务器的使用仅适用于Web开发？ （对不起，这些新手的问题，但我真的没有发现通过阅读Java EE的文档的任何明确的答案，或者我根本没有得到它： -/...）
任何帮助是高度赞赏 - 非常感谢提前！
是否有更简单的方法通过使用像GlassFish这样的应用服务器来实现这些目标？
这是3层设置中应用程序服务器（与Web服务器不同）的精确要点。当然，您可以轮询和/或使用消息传递来为元数据（例如数据库更改事件）通信提供额外的挂钩，但最终很难重新发明一个非常知名的（并且非平凡的）轮（例如分布式中的数据同步层）。
如果您可以在客户端无需高速缓存查询结果而生存，并且访问服务器（第二层）的数据访问延迟是可以接受的，那么显然这是要走的路。
[下面是一个相当晚的p.s.但恰巧今天再次阅读这个问题，并且个人觉得需要澄清。]
Java EE是一个基于分布式容器/组件的企业级架构。抛开J2EE组件市场的失败（尽管一些人尝试过），剩下的就是它的COA事实以及它作为该体系结构的基本关注点的固有支持。请注意，Java EE的web配置文件（例如“web-server”）也是同一架构的一部分。
那么当您使用这些Java EE应用程序服务器之一时，您会得到什么？它将如何解决您的需求/设计问题。 （a）分布式名称空间（JNDI）和（b）跨层连接的产品菜单（纯RMI（在您将滚动条自己的分布式基于RPC的系统），Enterprise Beans aka EJB（远程和本地公开的组件接口，在可分发容器中的查找和生命周期方面具有明确定义的语义）在EJB风格中，就连接语义而言， JMS）和直接RPC。
对于您的情况，例如，您可以选择带有胖客户端JMS端点和MessageDrivenBean EJB的JMS消息总线。基于主题/订阅和直接队列，这些都可以有条理地配置为耐用或不可用等。
您的应用程序服务器c /将提供此JMS提供程序，或者您可以选择最好的品种，例如， TIBCO，满足您的需求，满足您的要求。
你不是在重新创造任何上述非常平常的担忧。您的重点仍然是您的域名要求，并且您拥有在某些合理的SLA中创建平台所需的所有工具。
一个可行的替代方案是用独立的OSS软件构建归结为Java EE的COA方法（它们都可以让你声明性的魔术和皮塔饼开发仪式）的相同的东西。 Ø为您的巴士提供MQ，REST远程RPC以及可能的REDIS，以加强对您的信息的持久性保证并协调（无JNDI）您的分布式球。
我个人比较喜欢后者，因为它对我来说是更有趣。由于对分布层更直接的控制，所以提高了效率，由于非常严格的要求（例如极少数要求），可以提高可扩展性。
企业的分布式系统设计（“已被分配”）需要考虑业务需求，而不仅仅是应用领域。这是等式的一部分。
希望这是有帮助的（和及时;）
由于您使用的是JPA，因此您可以从其entity locking and concurrency mechanisms中受益。
有JPA的两个主要概念（从Java EE 6教程引用）：
乐观锁：
默认情况下，持久性提供者使用开放式锁定，其中， 提交更改之前对于数据，持久性提供程序检查 自从读取数据 以来没有其他事务修改或删除数据。这通过 数据库表中的版本列实现，在实体 类中具有相应的版本属性。当一行被修改时，版本值增加。
悲观锁：
悲观锁更进一步比乐观锁。通过 悲观锁定，持久性提供程序创建一个事务 ，该事务获得对数据的长期锁定，直到事务完成为 ，这样可以防止其他事务修改或删除数据直到锁定结束。当底层数据是经常被许多交易访问和修改的底层数据时，悲观锁定是比乐观锁定更好的策略。
选择最适合您的应用程序行为和功能需求的策略。
嗨马特 - 谢谢你的回复。悲观锁定似乎是我需要的更好选择。 – salocinx 2012-03-10 21:19:24
胖客户端可以轮询一个配置的时间间隔。这与Outlook等邮件客户端类似，它们轮询新的电子邮件消息。
非常感谢。轮询确实是更新问题的简单方法，但效率不高。我正在寻找一种消息传递替代方法，如果数据由远程客户端更改，则会涉及GUI更新等事件。 – salocinx 2012-03-10 21:24:06
然后你可以使用jms主题。把数据库访问放在应用程序服务器后面，然后可以将任何更新发布到jms主题。所有胖客户端都可以通过api更新并订阅该主题以获取其他客户端的更新。 – Kevin 2012-03-10 23:20:23
这是一个好主意。我知道已经建立了一个JMS主题。只要使用@ PostUpdate，@ PostPersist＆@ PostRemove生命周期侦听器修改@Entities，服务器就会发布更新消息。感谢您的输入。 – salocinx 2012-04-20 15:01:52
您的客户在概念上连接到其中包含“商业逻辑”一“中间层”。
您客户端发送的所有请求的“中间层”和“中间层”瓶坯他们。这意味着，如果中间层关心协调客户端，中间层可以记住哪些客户端“查看”了重要对象，并且（如果技术支持的话）可以将更新传送给适当的客户端。
客户端主要包含用于在此场景下呈现数据的代码，它们包含的用于接受请求的代码通常会将请求代理到中间层。
是的，这是非常有帮助和及时的:-) @All：非常感谢伟大的投入！ – salocinx 2012-05-03 14:33:39