我的任務是設計一個基本上由一個集中共享數據庫和多個胖客戶端（基於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