技術分享如何實現基于J2EE的服務(圖)

2019-11-18 12:23:29

字體：大中小

來源：轉載

供稿：網友

　　Bobby Woolf寫了一篇文章：How to Implement a Service in J2EE。他建議，假如服務使用同步傳輸（如：HTTP或RMI），就使用SSB（無狀態會話bean）；假如使用異步傳輸（如：JMS或JCA），就使用MDB（消息驅動bean）。
　　
　　“將服務實現為SSB的一個好處是，客戶可以靈活地同步或異步地調用它。我已經討論過對HTTP或JMS傳輸使用service activator進行異步訪問的情況了。服務的java客戶機可能希望同步調用該服務——這使用SSB很輕易做到，只需使用其本地或遠程home和接口。所以SSB使服務調用非常靈活。”
　　
　　很難不同意他的觀點。將服務公開為由J2EE應用服務器托管的SSB和MDB確實是一個好方法，因為它會自動為客戶機和服務提供者提供遠程、事務性、入池、負載均衡、故障恢復等功能，尤其是假如您承擔得起使用應用服務器的費用，就完全不必重新構建并花時間重新實現這些服務。
　　
　　“有些人不喜歡EJB。也許他們使用的不是Java，而是.NET，他們使用.NET中與SSB等效的東西。又或者雖然他們使用的是Java，但不是J2EE，至少不是EJB。原則仍然適用，他們會使用JavaBean/POJO。若非J2SE對象需要處理安全性、事務、遠程、入池，您就已經重新創造了EJB，所以使用EJB作為起點就可以了。”
　　
　　所以在Java中SSB不是實現服務的唯一方法，但是假如您要利用J2EE，那么使用SSB是一個好方法。”
　　
　　前些時候，當IoC（反向控制）容器開始流行時，引發了很多討論。“基于POJO的設計缺少安全性、事務、遠程支持等等”這種說法可能有些不實。這些都的確是橫切關注點，而且與實際的業務邏輯沒有太大關系。此外，這些獨立的關注點不一定需要單元測試，而只需要集成測試。
　　
　　依我來看，更靈活的取兩者之長的方法是，只將EJB作為可能具有遠程、事務性等功能的邊界的Service Facade，而將實際的業務邏輯實現封裝在由某種IoC容器驅動的POJO中。這樣EJB代碼就應該與下面的代碼類似（使用了Xdoclet注釋）：
　　
　　PRivate RequestProcessor requestProcessor;
　　/**
　　* @ejb.interface-method view-type = "both"
　　* @ejb.transaction type = "RequiresNew"
　　*/
　　public String request( String msg) {return requestProcessor.submitSync( msg);}
　　
　　其中，requestProcessor是由Spring托管的POJO。注重，該代碼非常簡單，其實不需要進行組件級的測試。
　　
　　服務組件的連接方式如下所示：
　　　技術分享如何實現基于J2EE的服務(圖)（圖一）

　　注重，在容器外（例如，在獨立的客戶機中）還可以使用POJO組件，這尤其方便測試和調試。
　　
　　上述方法在開發時具有幾個優點。下表對EJB和基于POJO的組件開發進行了比較。如您所見，POJO使測試更為輕松，本例中EJB的整個更改/構建/部署/測試/驗證周期大約是POJO的5~10倍，而且POJO的開發流程更具動態性。
　　技術分享如何實現基于J2EE的服務(圖)（圖二）