Workshop中幾個安控屬性的意義

在Workshop時, 屬性編輯視窗在特定的檔案開啟後, 會有一個security小節, 這些設定一樣是用Javadoc Annotation寫在原始碼, 例如:

• Web Services , Java Control 與 JPD : @common:security
• Java Page Flow : @jpf:controller 與 @jpf:action
• EJBGen : @ejbgen:role-mapping

簡單的說明一下這些屬性的意義, 詳細內容還是要參考手冊!

roles-allowed : 准許設定的角色可以使用物件, 這些角色必須已經定義在web.xml或ejb-jar.xml 。在@jpf:controller設定的是套用到整個class, 可存取所有methods, 若在@jpf:action設定, 算是擴充(再加上原來@jpf:controller的部份)；同樣原理也適用在@common:security。

roles-referenced : 不適用於JCX或JPF檔。代表在程式中會用到的角色, 列在此則會在DD中增加security-role-ref的設定, 例如在JWS中設定, 則在編譯後的EJB Jar檔裡, ejb-jar.xml中會多一筆security-role-ref, 且在weblogic-ejb-jar.xml中該角色被設定為externally-defined。

run-as : 代表設定的這個角色有權利存取其他資源, 當存取該資源時, 會用設定的角色名稱, 因此使用設定的檔案編譯完成DD檔會多一筆相關的角色設定, 且是externally-defined。如果run-as-principal沒有設定, 則此屬性同時代表principal與角色名稱。

single-principal : 如果設定為true, 則使用此服務時, 在對話中的所有動作都必須由同一個principal來做。

callback-roles-allowed : 定義當JWS呼叫控制項後, 誰可回呼JWS的Callback介面, 而此控制項必須實作ExternalCallbackTarget介面。

BPM如何處理交易中的錯誤

在WebLogic Integration 8.1中, 所有的流程都是至少有一個全域交易(Global Transaction), 萬一有錯誤(Exception)發生, 流程引擎會怎麼運作呢? 下面這張圖是基本的演算法:

很清楚地, 只有在沒被標示成Roll-Back Only, 而且Exception Hanlder沒有產生錯誤的情況下, 流程會繼續跑下去(Resume), 否則都Rollbacked, 流程進入Aborted狀態。

問題來了, 如果流程被設定成"freeze on failure"時, 會如何? 答案是: 交易會被Roll-backed, 而且不會執行Exception Handler, 流程進入凍結狀態! 如果又希望在Rollbacked前, Exception Handler可以被執行的話 (例如做補償交易), 可以將其"execute on rollback"屬性設成"true" 。

Exception的處理, 影響到整個流程的設計, 請千萬小心!

原始文件在 http://e-docs.bea.com/workshop/docs81/doc/en/integration/wfguide/wfguideException.html 可取得。

使用WebLogic Server叢集時, 程式寫作上要注意什麼?

在BEA快三年, 這也是常被問的問題之一! 除了需要根據WebLogic Server的規定, 在部署時做設定, 的確有些常犯的錯誤, 但當了解原理與J2EE規格後, 通常應該不會有此疑問。叢集可以容錯轉移的基本原理是, 透過網路讓不同的JVM互相溝通, 備份資料, 並且看看誰已經死了, 不要再去打擾它。

所以在Servlet/JSP寫作上, 要注意:

1. 放到Session的資料都要Serializable, 不然怎麼備份?
2. 只用setAttribute跟removeAttribute修改Session裡的資料, 因為WebLogic只監控這二個方法
3. 小心放到Session的資料, 因為它需要做網路複製的動作, 會影響整體效能, 更重要的, 目前還沒有好的方法知道Session裡有哪些資料, 哪些是不Serializable, 大小, 除非買工具來做
4. 小心使用Frames! 有可能每個開發人員都在自己的Frame裡產生Session, 而系統不會幫這些Frames做同步, 在叢集環境裡就會搞死人! 所以最簡單的方法是有一個Frameset的其中一個Frame產生Session, 之後用其他的Frameset的一個Frame來修改Session資料

對Stateless Session Bean來說, 最重要的是idempotent, 也就是同樣資料餵進去, 不管幾次, 再哪一台Server, 都有一樣的結果, 這樣就可以做容錯轉移, 像新增物品到購物籃的程式, 本質上就不行!

對Stateful Session Bean而言, 跟HTTP Session 一樣, 注意要被放的狀態需要可以序列化!

以上說明都是來自http://e-docs.bea.com/wls/docs81/cluster/failover.html#1032777 .

關於叢集所提供的負載平衡與容錯轉移功能

很多人會問二個問題 : 1) 為什麼使用叢集後, 負載沒有平衡? 2) Servlet收到Client要求, 呼叫同一部WLS instance裡的EJB, EJB物件死了, 怎麼沒有轉移到其他部執行?

回答這些問題前, 先解釋二個名詞, 在叢集部署時, 最簡單的有二種情況, 第一種是Web Container跟EJB Container在同一個WLS Instance裡, 這我們叫Basic Architecture或2-Tier Architecture; 第二種稱為Multi-Tier Architecture, 這種狀況是Web Container與EJB Container跑在不同的機器上。

首先, 先回答第一個問題, 這通常發生在2-Tier Architecture中, 而且應用程式均部署再每一台伺服器, 負載不平均有可能是因為EJB的呼叫不平均, 為什麼? 根據文件, 我可能已經指定一種演算法(Round-Robin, Weight-Based, Parameter-Based或Random)了, 理論上EJB呼叫應該均勻分配, 不是嗎? 答案不是的! WebLogic 會最佳化這個腳本, 因為Servlet跟EJB在同一個WebLogic Server Instance裡都有了, 何必遠求浪費時間呢? 這就跟我們要吃鼎泰豐一樣, 既然台灣都有了, 何必跑到日本吃, 有比較便宜嗎? 所以當這些物件被放在一起時, 就不會根據指定的負載平衡演算法來走, 而是找本地的, 詳細說明在這裡http://e-docs.bea.com/wls/docs81/cluster/load_balancing.html#1008605的Optimization for Collocated Objects小節。除了這個原因, 也可能是其他因素, 例如我們觀察的時間太短, 負載平衡應該是在較長的時間中的統計結果。

第一個問題其實已經說明第二個問題, 注意在叢集運作裡, 其實是以WLS Instance為單位, 更簡單的說是JVM, 負載透過平均分散在不同的JVM以達到平衡的效果。跟第一個問題同樣的設定腳本， Servlet呼叫的EJB物件無法使用, 請問有這樣的狀況嗎? 會有這樣的狀況通常Web Container也跟著掛了, 更可能連JVM都有問題了, 怎麼可能有問題的Servlet再去呼叫其他台可用的EJB? 所以區分的界限是在OS的Process是否正常。當然隨著技術演進, 這樣的設計可能過時, 但很清楚的是, 天下沒有白吃的午餐, 當要求越多, 付出也會越多。

因此, 要充分達到我們的理想, 就要使用Multi-Tier架構, Web App獨立一層, EJB獨立一層, 這樣富在就能夠根據演算法分配, 所有的EJB使用都是遠端的, 當有非應用程式的錯誤時, 就可以轉移到其他伺服器上執行, 雖然達到目標且更有彈性與伸縮性, 但是增加了管理上的難度。