2012-04-17 39 views
11

這可能聽起來類似於this,但事實並非如此。當您可以實現Web服務(SOA/REST)時,使用RMI實現EJB仍然有用嗎?

我有點理解EJB和RMI,而且我一直在SOA下使用Web服務。我想知道爲什麼使用EJB公開RMI下的遠程接口而不是發佈Web服務(SOA/REST,但主要是SOA)是有用的。我並不是問哪一個更好,只是我想知道爲什麼我更喜歡通過Web服務實現具有遠程接口的EJB。

我回顧了很多網頁,但都顯得過時。到目前爲止,我所擁有的是在與Java遺留系統集成時,暴露遠程接口的EJB只比WS更好。如果我想管理事務,我可以用本地接口實現EJB。另外我不認爲選擇EJB over RMI比Web Service接口更有效率。

我對不對?有什麼我失蹤?

真的在此先感謝。

回答

21

EJB是更好,如果

  • 您需要執行哪些應該在一個 交易完成呼叫數(在理論上,我們有事務的web服務,但不 每個執行提供的話),(狀態)當談到事務管理時,EJB發光。幾乎在任何時候你需要有狀態EJB都會比Web Service更好;
  • 你需要性能 - Web 服務很慢 - 它們使用通過HTTP推送的XML/JSON,RMI通過 EJB使用的IIOP協議更有效;
  • 您需要連接到一些遺留系統,該遺留系統使用Java Web服務的過時規範(醜陋的Axis 1.0東西,與JAX-WS不兼容),將所有與Web服務連接起來可能是一場噩夢,處理不兼容的WSDL定義,奇怪的SOAP信封。 EJB向後兼容,可以連接舊的EJB 2而沒有EJB 3.1的任何問題;
  • 現代的EJB(EJB 3.X)可以通過添加兩個或三個簡單的註解

爲什麼(REST)Web服務暴露它們的JAX-WS SOAP/WSDL服務或JAX-RS REST服務接口那麼受歡迎呢? EJB只能連接到另一個Java應用程序。大多數現代富互聯網應用程序都是用JavaScript編寫的,因此將它們與任何後端連接的唯一方法是使用某種Web服務(通常爲REST + JSON)。對於這樣的應用程序來說,EJB是非常沒用的。

+0

謝謝,但之前將其標記爲已回答,第一個不會是一個有效的原因,因爲我可以使用暴露本地接口的EJB來實現Web服務嗎?所以交易是一樣的。 – 2012-04-17 20:16:59

+2

的確,當您需要在一個事務中執行多個分離的調用時,問題就開始了。 Web服務通常是無狀態的,並且必須「手動」管理事務,這可能很麻煩。有狀態的EJB將免費提供。 – 2012-04-17 20:22:23

+0

那麼,即使使用之前給出的最後一個原因,您也可以擁有有狀態的Web服務。所以我會考慮第二個和第三個原因,效率(有點我猜)和遺產。謝謝! – 2012-04-17 20:27:11

6

如果您使用RMI作爲有線協議,則客戶端和服務都必須用Java編寫。

SOAP使用XML over HTTP,REST使用純HTTP進行客戶端與服務之間的通信。對話的任何一端都可以使用任何可以通過HTTP發送適當請求的語言來編寫,而這種限制要少得多。

我認爲這是通過HTTP的Web服務已經勝過RMI的原因之一。簡單而開放的勝利,每一次。

+0

因此,不再需要繼續使用遠程接口來學習EJB嗎?就像我想學習Smalltalk(只是爲了好玩和學習,但沒用)? – 2012-04-17 20:12:12

+0

我不會那麼遠。這個問題的答案取決於你的情況。 – duffymo 2012-04-17 20:23:22

+0

好的,但現在唯一有用的環境是與Java遺留系統集成,對嗎? – 2012-04-17 20:28:32

6

對於不同的目的他們是不同的東西。

EJB可用於N -ier系統,它緊密耦合,並且您可以控制所有元素。它們使用語言中的普通方法調用提供直接編碼,以及IIOP上的局域網類型性能或EE供應商部署的任何其他協議。

SOAP/REST最適合在互聯網或B2B或其他您無法控制兩端並且需要鬆耦合的情況下使用。由於所有XML都會使性能下降得多,但您也可以在中間獲得行業標準協議,從而使兩端均可防止單一源問題。

+0

這可能是另一個問題,但可以輕鬆地調整EJB以將它作爲Web服務的接口公開,因此,您可以啓動您定義的第一個體系結構,如果將來需要擴展,則可以通過它展示Web服務,還是不? – 2012-04-18 14:38:38

+0

@ChristianVielma這是另一個問題,你不會從我這裏得到答案;-)問它是一個問題。 – EJP 2012-04-18 23:17:08

相關問題