你會推薦什麼遠程處理Java應用程序的方法？

我想知道如何集成作爲獨立的J（2）EE應用程序開發的Java模塊。這些模塊中的每一個都公開了Java接口。 POJO實體（Hibernate）與這些Java接口一起使用，沒有DTO對象。集成這些模塊的最佳方式是什麼？即一個模塊遠程調用另一個模塊接口？你會推薦什麼遠程處理Java應用程序的方法？

我在想：EJB3，Hessian，SOAP，JMS。每種方法都有其優點和缺點。

民間，你的意見或你的經驗是什麼？

來源

2009-07-03 Tomasz Błachowicz

已經涉足了幾個遠程訪問技術，發現他們普遍unfun我現在會用Spring遠程從實現的抽象。它允許你專注於編寫你的功能，讓Spring用一些配置來處理遠程部分。你可以選擇幾種實現（RMI，Spring的HTTP調用者，Hessian，Burlap和JMS）。抽象意味着你可以選擇一個實現，只要需要改變就交換它。查看SpringSource docs瞭解更多信息。

來源

2009-07-03 10:47:56

我會去用肥皂。

JMS會更有效，但你需要編寫了驅動bean爲每個接口的消息。在另一方面

SOAP附帶了很多有用的工具包給出的EJB時，將產生你的消息定義（WSDL）和所有neccesary處理程序（客戶端和服務器）的。

使用肥皂時，你可以（但不必須）處理證書的安全性和通過公共網絡的安全連接。由於缺省協議是通過端口80的HTTP，所以對防火牆等問題的影響會很小。對於絕大多數常見平臺上的大多數常見語言的良好支持，SOAP對於異性客戶端（在您的情況下不是J2EE）非常有用。

來源

2009-07-03 10:14:03

JMS專爲異步通信而設計，即消防和遺忘。因此，如果您需要服務電話的響應，則需要兩個消息通道一個接收消息，另一個將回復發送回發件人。 – pjp 2009-07-03 10:20:54

我與SOAP看到的問題是，使用這種技術需要XML模式，我可以再使用綁定到XML對象（JAXB）的定義。正如我在我原來的文章中所述，目標是消除DTO，並儘可能使用模型實體（Hibernate/JPA）。 DTO的問題在於DTO和實體之間需要轉換層。 – 2009-07-03 10:24:07

@pjp：不完全。您可以使用涉及專用隊列（對於會話）的模式來接收響應。基本上，客戶端創建臨時隊列，爲請求消息設置'ReplyTo'屬性並將消息發送到公共請求隊列。響應者接收請求消息，啓動邏輯，創建響應消息並將其發送到請求消息的'ReplyTo'中指定的臨時隊列。 – 2009-07-03 10:30:35

如果需要Java的應用程序只之間的網絡通信，Java RMI的是要走的路。它具有最佳的整合性，最高的透明度和最小的開銷。

但是，如果您的某些客戶端不是基於Java的，您應該考慮其他選項（Java RMI實際上有一個IIOP方言，它允許它與CORBA交互，但是 - 我不會推薦這樣做，除非它是爲了一些遺留代碼集成）。根據您的需求，webservices可能是您的朋友。如果你使用網絡負載，你可以通過Hessian進行web服務。

來源

2009-07-03 10:14:37 cwap

+1 RMI是:-) – ATorras 2009-07-03 10:44:24

你的字面意思是遠程？像在不同的環境中運行一樣，因此具有不同的可用性特徵？有網絡開銷？

假設「是」我的第一個步驟是採取的服務方式，拋開調用技術一會兒。只要考慮你的服務的設計和意義。你知道它們比較昂貴，因此繁忙的小接口往往是一件壞事。你知道服務系統可能在調用之間失敗，所以你可能會傾向於無狀態的服務。您可能需要在失敗後重試請求，以便您可以支持冪等服務設計。

然後考慮可用性關係。你的客戶可以在沒有遠程系統的情況下工在某些情況下，如果遠程系統不可用（例如，如果您無法進入HR系統，則無法啓用員工），您可能無法進展，而在其他情況下，您可以採用「消防和告知後來「哲學;稍後排隊請求並處理響應。

那裏有一個可用性depdency，然後簡單地暴露同步接口似乎適合。如果所有東西都是Java EE，那麼可以使用SLSB EJB執行此操作。我傾向於總結期望如果我的服務是有用的，那麼非Java EE客戶端可能也需要它們。所以SOAP（或REST）往往是有用的。現在，向您的SLSB添加Web服務界面非常簡單。

但我的寵物理論是，任何足夠大的IT系統最終都需要異步通信：您需要解耦可用性約束。所以我會傾向於尋找一種JMS風格的關係。在您的服務或者SOAP/JMS之前的MDB外觀並不難做到。這種方法傾向於強調無論如何可能潛伏的失敗案例設計問題，JMS傾向於讓你想：「假設我沒有得到答案？假設我的答案來得晚？」

來源

2009-07-03 10:20:20 djna

的標準方法是使用普通的RMI的各種服務組件之間，但由此帶來的分享你的Java接口和版本，特別是如果你有很多使用相同的類組件到您的域模型的變化的問題。

你真的運行在一個單獨的虛擬機每個服務？如果這些EJB總是彼此交談，那麼最好將它們放到同一個虛擬機中，並避免任何遠程過程調用，因爲這些服務可以使用它們的LocalInterfaces。

可能會咬你的另一件事是使用Hibernate的POJO。您可能會認爲這些是簡單的POJO，但在幕後，Hibernate一直忙於CGLib嘗試執行諸如允許延遲初始化之類的操作。如果這些bean被序列化並通過遠程邊界傳遞，那麼最終可能會出現奇怪的Hibernate Exception。就個人而言，我寧願創建簡單的DTO或將POJO編寫爲XML以在組件之間傳遞。出於性能原因，我的同事們會更進一步，編寫自定義有線協議來傳輸數據。

最近我一直在使用MULE ESB整合各種服務組件。這很好，因爲你可以混合使用RMI，套接字，Web服務等，而不必編寫大部分的鍋爐代碼。

http://www.mulesource.org/display/COMMUNITY/Home

來源

2009-07-03 10:33:05 pjp

+1的容易和簡單的解決方案，我喜歡的ESB方法 – ATorras 2009-07-03 10:43:24

你爲什麼會去與比對工作最簡單的事情其他什麼嗎？

在你的情況這聽起來像EJB3也許JMS，取決於溝通是否需要同步或異步的。

EJB3到目前爲止最容易建立在RMI之上，容器提供了您可能需要的所有額外功能 - 安全性，事務處理等。推測您的POJO位於共享jar中，因此可以簡單地在您的EJB，儘管我傾向於自己傳遞值對象。 EJB的另一個好處是，如果做得對，它是最高性能的（這只是我的意見btw ;-)。

JMS是一個涉及多一點，但不是很多，基於異步通信的系統得到一定的禮節在並行任務期限等

的網絡服務的性能開銷，必然額外的配置和附加失敗點使他們，恕我直言，不值得麻煩，除非你有一個要求強制他們使用的要求 - 我正在考慮與非Java客戶端交互或向外部提供數據。

來源

2009-07-03 10:38:34

你會推薦什麼遠程處理Java應用程序的方法？

回答

相關問題