需要關於面向服務架構的建議

Question

我們是一個完整的SOA研討會（僅限Java），我們使用SOAP進行數據傳輸。目前，我們正在集中處理特定組件的數據庫工作，以便其他組件可以使用SOAP從一個應用程序獲取數據。

我的觀點是集中很好，但是在數據庫調用之間添加soap時會增加很多延遲。我想要一個RMI/EJB類型的實現，以便我們獲得序列化對象，並減少了編組開銷。我喜歡Ejbs的實施方式，並希望使用它。但是我們返回的數據根本不在一張表中，因此，我無法返回數據庫表實體，數據可能來自其他20個或更多表。

因此，在我們當前的系統中，我們創建了自定義實體以映射到繁重的sql查詢。 （不涉及一個表）

ejbs可以用於這種類型的環境嗎？如果是這樣，是否有可以隨時將查詢結果映射到實體的庫？

不幸的是我們的內部系統很舊，我們使用java 1.4。

Answer 1

這可以完成，但這將是痛苦的。有一個原因是由EJB 3.0實體bean創建的。這是因爲處理這些複雜的需求非常難以通過舊的2.x實體bean xml文件進行映射。

如果您真的在構建一個新的SOA層來表示您的數據庫內容，那麼爲什麼要使用已經過時近10年的技術來​​做到這一點？

更糟的是，使用EJB 2.x構建此應用程序，然後使用RMI/EJB將您的所有其他應用程序綁定到相同的過時技術。很少有人會選擇啓動新的 EJB 2.1項目。

我真的相信你最好使用SOAP來代替EJB，而不是使用SOAP，至少它不會將你與一個過時的平臺耦合在一起。當前的最佳實踐更喜歡REST進行實體傳輸，並將SOAP保存爲RPC風格的交互，但是有許多優秀的庫用於將數據庫表用於SOAP映射，其中很多都是RDMS的開箱即用的。

最後，如果你決定這樣做，我建議你先做一個測試。構建一個測試框架以真正瞭解SOAP反序列化是否是一個重要的成本組件。將其與網絡傳輸的成本進行比較。除非這些實體在兆字節範圍內，否則反序列化只是整個應用程序時間的一小部分。