爲什麼要創建一個EJB而不是Web服務？

Question

我原以爲這裏有很多信息，但我還沒有找到真正解決我的問題的東西。

製作EJB而不是Web服務的優點是什麼？我能想到的唯一明顯優勢是性能。即便如此，我無法找到關於EJB效率如何的任何硬性數據。

Web服務，我能想到很多的優點，包括Java/.NET，更容易網絡之間的互操作性在防火牆/代理服務器，因爲它使用HTTP的。隨着WS-ReliableMessaging，WS-AtomicTransactions，MTOM等新的標準（這些標準被假設完全通過Sun & MS之間的互操作性測試），EJB爲Web服務提供了什麼？

我從來沒有比基本的網絡服務以外的任何工作，所以也許有人用更先進的Web服務標準的經驗可以告訴我，這一切都沒有工作，以及供應商要求？

Answer 1

首先，EJB和Web服務是不是唯一的選擇，它實際上是相當reaonable創建EJB，並讓它暴露既IIOP和Web服務接口。

所以這裏有兩個問題：

1. 什麼是好implmentation技術，可重複使用的一塊業務邏輯的。
2. 哪種調用樣式用於某個業務邏輯？諸如RMI/IIOP何時是一個很好的選擇？什麼時候是SOAP/HTTP？當SOAP/JMS ...等

寫作EJB3的EJB是很容易的，並給出了好處，如事務性，安全性，實例池和和管理，可擴展的基礎設施 - 這往往還清嚴重的企業邏輯。 （你也可以看看Spring等其他框架作爲替代）。

現在作爲調用樣式。顯然，當需要（如說）.NET的inter-op時，Web服務是有用的。但是，在純Java世界中，特別是當邏輯和「客戶端」可以部署在同一個JVM中時，使用本地EJB接口確實會比Web服務更高效。當遠程調用RMI/IIOP和Web服務之間的性能比較並不那麼明確時，在某些情況下，Web服務確實做得很好。對我來說，使用Web服務的反面論點是歷史上存在很多互操作問題，不同廠商之間的標準版本偏差是一個問題 - 儘管如果你在互操作，那麼我想你總會遇到這樣的問題。

Answer 2

我不想諷刺，但在此之前我看到了最EJB實現到EJB 3似乎旨在確保工作安全。這是我的軼事，它是值得的。

Answer 3

服務訪問 如果要支持Java服務的非Java使用者，請使用web服務。對於Java消費者來說，IIOP可能是一種選擇。

服務實現 如果你想有一個容器提供的功能，如交易管理，然後使用EJB實現的服務。