IBM on SOA 的經驗分享

SOA Goes Vertical: But IBM Still Not There Yet.

Weblogic Server: Spring Console設定

自從去年(2005)BEA宣誓力挺Opensource應用程式框架以來，BEA和Spring Framework的Interface21就走的越來越近。除了和Interface21簽訂互相技術支援的合約外，Interface21和bea的工程師更是有許多技術底層的交流。Spring Console就是這樣的交流當中所衍生出來的一種產品。

首先，定位一下什麼是Spring Console。Spring Console並不是開發時期的工具，而是應用程式部署在Weblogic平台上的一個JMX監控工具。大家都知道，從Spring 1.2以來，我們就可以透過MBeanExporter將任何一個POJO註冊在MBeanServer上成為一個JMX Standard MBean，然後就可以透過MC4J這樣的JMX監控工具來管理這樣的MBean。Spring Console可以被當作是一個JMX的Web管理介面，只是這個管理介面可以直接內嵌在WebLogic Server 9.x的管理控制台裡頭。這樣的好處是，當管理人員登入到WebLogic Server管理控制台的時候，除了能夠管理一些WebLogic Server例行性的事務之外，還能夠管理跟Application邏輯相關的東西，比方說直接透過Web介面查詢目前的登入人數、工作排程、使用分析等等，如下圖：



講完這個東西的好處後，當然要講一下怎麼安裝。首先：

1. 到BEA網站下載Spring Kit。
2. 解開下載檔之後，可以看到裡頭有一個spring-wls-console-ext的目錄，開啟後可看到有兩個.jar檔：spring-ext-client.jar以及spring-ext-server.jar
3. 將spring-ext-server.jar放到你的DomainHome/console-ext下
4. 將spring-ext-client.jar放到你webapp的WEB-INF/lib下
5. 開發你的Web Application，然後參考這篇文章的applicationContext.xml設定
6. 將WebLogicHome/server/lib/consoleapp/APP-INF/lib中的commons-logging以及log4j的jar檔copy到你的DomainHome/lib下

這樣就搞定啦！


Technorati Tags: weblogic,spring

WebLogic Server: 交易的迷思

一般的程式設計師對於單一資料源的交易處理機制都有一定的了解。所謂的交易控管，用白話文來說，就是只要我需要一次更動多筆資料，而這個更動的行為在邏輯上是一個具有業務價值的單一行為，我就需要交易的處理機制。但是比較少人花心思去了解的是J2EE裡頭規範Application Server必須Follow的XA Transaction Protocol以及更具有價值的Transaction Recovery機制。

接下來我想要點出的是一般人的迷思：

1. 迷思：只有在多重資料庫的資料更新場合才需要2PC。事實上只要你有兩個以上的DataSource想要同時參與一個Transaction，你就需要2PC。除非你自行處理所有的交易補償邏輯，否則兩個以上的Local Transaction，是不會有相互關連，資料的正確性也就大大的有問題了。
2. 迷思：只要依賴資料庫的交易機制，我的資料正確性就無懈可擊！假設Application Server正在處理一個交易，一個Batch update好了。你從DataSource1把資料傾倒到DataSource2，一邊將DataSource1的資料清除掉。這時候，不知道什麼原因，網路斷了，或者電源線被踢到了....源源不絕的客服電話把你灌爆。你以為你把電源插上就沒事了，可是.....咦，資料好像不太對？這時候如果你用得是WebLogic Server Advantage以上的版本，你可以透過Transaction Log自我恢復的機制，來讓WebLogic Server幫你Rollback資料庫裡頭的資料，維護你資料的Consistency。當然，你可以自己花錢花時間寫這個機制....但是你的客戶是否可以接受哪怕是幾分鐘的資料不正確？

簡單的結論：除非你的AP只提供簡單的查詢介面，否則你幾乎一定會需要用到2PC以及Transaction Recovery的功能。Transaction的問題很難Debug，已經看到太多英才死在這邊了，拜託大家緬懷先列的犧牲，不要再為了這種問題而強制性失眠了，請愛用XA，謝謝！


Technorati Tags: j2ee, 2pc, weblogic, bea, xa

WebLogic所提供的Demo Keystore密碼

雖然不建議在Production環境使用Demo的JKS (因為Demo憑證的CA是WebLogic, 所以所有的WebLogic只要用Demo的JKS會互相信任, 會變成一個嚴重的安全漏洞), 但在開發過程還是很多朋友會用預設的環境。WebLogic 預設會找尋JDK的憑證, 然後就是這二個JKS: DemoTrust.jks與DemoIdentity.jks, 這二個檔都是在$BEA_HOME/weblogic81/server/lib裡, 開啟的密碼分別是DemoTrustKeyStorePassPhrase與DemoIdentityKeyStorePassPhrase。

如果不喜歡用keytool操作的, 可以試試看這個GUI工具, KeyStore Explorer .

監看WebLogic Server 9.1的記憶體使用狀況 - Sun HotSpot JVM

這是個大題目，也是個AP Server管理/開發人員一定要瞭解的題目。

記憶體的問題，在許多的狀況下都會發生，有時候是因為系統效能很差，這可能是因為記憶體不足，造成頻繁大量的GC而造成；有時候則是因為不時出現的OOM(Out Of Memory)錯誤。本文的目的不在教導大家如何調校記憶體，而是著重在如何使用工具來監控JVM的記憶體狀況。WebLogic Server 9.1 Admin Console可以自行加入extension，讓你用視覺化的方式監控記憶體的使用，不過目前既有的extension，只能讓你看到heap的總使用量，至於heap裡面的各個generation，或是在heap之外的記憶體，就無法獨立出來監看，例如Permanent Generation。這個時候，我們就必須藉助一些其他的工具。

一般來說大家最常用的可能是Sun的JVM，除此之外目前在Windows、Linux、以及Solaris的平台上，BEA有推出JRockit JVM，往後應該會陸續增加對其他作業系統的支援。當然，如果在HP或是IBM的box上，你可能用的是HP和IBM的JVM。而此次要介紹的是監控 Sun的JVM，我們用的是Sun提供的tool，所以拿去監測其他廠商的JVM，不見得能用，這點要特別注意。

本次的測試環境如下：
AP Server: WebLogic Server 9.1
JDK: Sun JDK150_04 (跟WebLogic Server 9.1 bundle在一起的版本)
作業系統: Windows XP SP2
監控工具: jvmstat 3.0

另外，本次的測試特別選用安裝WebLogic Server 9.1時，就可以選擇安裝的server example來測，這樣大家也能一起跟著做。

(一)下載、安裝WebLogic Server
首先，當然是把WebLogic Server 9.1裝起來，可到這邊下載
。安裝WebLogic Server是很簡單的事情，用膝蓋都裝得起來...如果連這關都過不了，我強烈建議你馬上離開，不要回來。安裝完之後就先晾在那邊別理他:D

(二)下載、安裝、測試jvmstat
接著我們到Sun Developer Network下載這次的主角，jvmstat。不過在下載之前，強烈建議你把這個頁面上的資訊讀一讀，下面我只節錄一點點不知不可的事情。你會發現，原來在J2SE 5開始，Sun已經偷偷把jvmstat的部分utitlity在你的JDK裡面(jps, jstat,jstatd)，這些utility都是我們等一下會用到的。要注意的是，這些東西只附在JDK裡面，如果你只安裝JRE，就沒有囉。不過不要害怕，因為安裝WebLogic Server 9.1的時候，也會順便把JDK150_04也裝進去，所以這些東西都有。

• jps(JVM Processes Status Tool) - 這個工具是用來列出在我們要監控的機器上，有哪些JVM在跑，每個在跑得JVM都會有一個ID，之後我們就會用這個ID來追蹤某個特定的JVM狀況。
  
• jstat(JVM Statistics Monitoring Tool) - 這是黏在JVM上蒐集並log效能資訊的程式。
  
• jstatd(JVM jstat Daemon) - 他本身是個RMI Server應用程式，有兩個功能。一個是監督自己所處的機器上有那些JVM被建立或是被停止，另一個功能就是提供一個介面，接受遠端監控工具送過來的指令。
  
• visualgc - 這個要另外下載，因為他沒有被包含在JDK裡面，要下載jvmstat。這個工具可以把你的JVM的記憶體狀況，包括每個不同的Generation，以圖形化的方式展現出來，很炫，也是這次要用的重點。
  

簡單瞭解之後，在使用之前，我們就可以先猜猜看該怎麼用。首先，既然我們要監控WebLogic Server，就必須啟動server(廢話)；接著啟動jstatd，讓遠端監控工具可以連上來；最後在遠端的機器，我們就啟動visualgc，連上來，看到JVM的記憶體使用狀況。....用說的都很快啦...

接下來有關jvmstat的安裝，都是參考installation guide for windows platforms，如果有任何不清楚，請仔細閱讀原始文件。

• 把下載回來的zip檔解壓縮到一個你高興的目錄，我很高興的把我的jvmstat解壓縮到C:\java\jvmstat3.0
  
• 開啟一個dos視窗，因為這個視窗接下來會呼叫jvmstat和java指令，所以你必須設定適當的path參數。C:\> SET PATH=JVMSTAT_HOME\bat;JAVA_HOME\bin;%PATH%，其中JVMSTAT_HOME就是jvmstat解壓目錄，以我的狀況，就是C:\javajvmstat3.0。而JAVA_HOME我們就很偷懶的連結到BEA附的JDK，以我的狀況，就是C:\bea9\jdk150_04
  
• 測測看裝好了沒。我們先執行一個最簡單的測試。在dos視窗中，我們打入C:>jstat -gcutil 0 1000 3，按Enter之後，應該會看到三行類似下ping指令看到的回應，有三行。這個意思是說，我執行jstat這個工具的gc監看功能，監看jvmid=0的jvm，每隔1000ms看一次，總共看3次。因為jstat要執行也會啟動jvm，所以這個指令的意思就是自己監看自己啦，跟我們測網路的時候ping自己的機器是類似的意思。(接著還有用jstat監視同一台機器上的AP的測試，請參考原始文件)
  
• 雖然我們測試全部都在同一台機器上，不過鑑於在實際的情況，我們應該會希望在自己的機器上監控遠端的伺服器，所以我們還是練一下用遠端的方式來監控。所以我們就要在遠端的機器上啟動RMI
  server，也就是jstatd。因為一些原因(參考jstatd文件)，我們必須先建立一個policy file。
  
• 找個地方(建議是jstatd的同一個目錄，以我的狀況就是C:\bea9\jdk150_04\bin)，建立一個空白文字檔，在裡面貼上如下的一段文字並且存檔，檔名隨便，例如叫做jstatd.all.policy。如其中的JAVA_HOME其中，以我的狀況，就是C:\bea9\jdk150_04，記得把\換成/
  

grant codebase
"JAVA_HOME/../lib/tools.jar"
{
permission java.security.AllPermission;
};

• 我們開一個新的dos視窗，切換到JAVA_HOME，用下面的指令執行jstatd
  

jstatd -J-Djava.security.policy=jstatd.all.policy

• 執行成功之後放著暫時就別動他
  

(三)修改並啟動WebLogic Server
前面說過，我們要用WebLogic Server安裝時一起裝入的example server來做測試，不過這邊要先做一點小修改，因為這個server使用的是JRockit，而不是Sun的HotSpot
JVM，所以我們要修改一下。修改方式如下：

• 找到WL_HOME\samples\domains\wl_server\bin，以我的狀況來說， WL_HOME就是C:\bea9\weblogic91
  
• 將目錄下的startWebLogic.cmd用文字編輯器打開，找到這行程式call "%DOMAIN_HOME%\bin\setDomainEnv.cmd" %*
  
• 在這行程式的前面，加上一行set JAVA_VENDOR=Sun，所以整個看起來會像下面這樣
  

...前略...
@REM Call setDomainEnv here.

set DOMAIN_HOME=C:\bea9\weblogic91\samples\domains\wl_server
for %%i in ("%DOMAIN_HOME%") do set DOMAIN_HOME=%%~fsi

set JAVA_VENDOR=Sun
call "%DOMAIN_HOME%\bin\setDomainEnv.cmd" %*

set SAVE_JAVA_OPTIONS=%JAVA_OPTIONS%

set SAVE_CLASSPATH=%CLASSPATH%
...後略...

• 完成之後存檔，接著就準備啟動example server
  
• 你可以直接雙擊剛存檔完成的startWebLogic.cmd，也可以從windows的「開始」-> 「程式集」->「BEA Products」->「Examples」->「WebLogic Server」->「Start Examples Server」開啟
  
• 當server已經正確的被帶起來，應該會自動開啟你的瀏覽器，然後連上http://你的ip:7001/index.jsp
  

(四)開始監控
現在我們在伺服器上(也就是我們到目前為止正在操作的機器)已經有一個dos視窗正在執行jstatd，並且有一個 WebLogic Server的instance正在執行，用的是Sun的JVM。如果是真實的狀況，接下來我們應該要去另外一台電腦上(姑且稱之為遠端)，一樣安裝 jvmstat，然後用jps這個工具，去找出我們想監控的JVM，不過反正這是測試玩玩，就別這麼麻煩了，但是樣子還是要做出來，也就是說指令還是要下得彷彿我們在遠端的機器遙控一樣。

• 開啟一個dos視窗
  
• 在視窗中做set path的動作，參考前面jvmstat安裝的段落
  
• 查詢遠端伺服器的JVM，假設遠端伺服器的電腦名稱叫做MyServer
  

C:\>jps MyServer

• 看到的結果應該類似下面這樣
  

1416 Jstatd
2484 Server
2268 netServer
2132 Jps

• 前面的數字就是JVM的id，因為我們測試的時候，其實是在同一台機器上，所以你也會看到你正在執行的Jps process。所以現在我們知道WebLogic Server用的JVM的id是2484。為什麼我會知道這個名為Server的JVM就是我要看的？很簡單，因為其他的不是(哈哈，廢話)接著我們用jstat去查詢這個遠端的JVM的GC狀況，注意2484@MyServer這一行的語法，就是說我要查詢MyServer機器上的2484號JVM
  

C:\>jstat -gcutil 2484@MyServer 1000 3

• 如果你有看到三行回應，那就對啦，恭喜你
  

(五)更華麗的視覺介面
看到這邊，大家一定會覺得...「這不是啃得積*&^#$%^」。沒錯，前面這個jstat功能雖然夠用，可以讓你回家慢慢分析到家破人亡，不過這不是我們本次介紹的重點，我們的重點是，如何讓你的桌面看起來很炫麗，營造時時刻刻認真監控伺服器狀態的假象，以掩蓋你上班都在上網的事實。或是我們可以這麼說，如果只有數字報表，沒有圖形介面，那大家都去看小說了，電影院也可以關門了...好啦，真正的重點大家自己去思索吧。我們來看要如何運作

• 剛剛那個在遠端機器上的dos視窗還沒關掉吧？關掉活該，誰要你多事。如果不幸關掉，請重開一個dos視窗，並且設定path，如果忘記，請參考前面jvmstat安裝一節。
  
• 利用Jps得知伺服器(MyServer)上的JVM id，如果忘記請參考前一節
  
• 叫出花俏絢爛visualgc
  

C:\>visualgc 2484@MyServer

• 如果順利的話，你應該就會看到類似的圖形了
  

(六)剩下的

• 自己試
  
• 碰到jvmstat的問題的話，建議先去Sun的文件找答案installation guide for windows platforms
  
• 這個工具好用歸好用，沒事不要用，特別是正在上線運作的系統，因為還是會影響server的效能

WebLogic SIP Server

在Flickr放了一些關於SIP, IMS與WebLogic SIP Server的介紹, 歡迎參觀!
網址在http://www.flickr.com/photos/kyhuang/sets/1726235/show/

AquaLogic Service Bus Deployment Resources

AquaLogic Service Bus Deployment Resources

根據上述的文件，AquaLogic Service Bus的Cluster在一個Domain當中只能夠有一個，和一個WebLogic Server能支援多個Cluster的概念是不太一樣的。

另外，想要正確的設定一個AquaLogic Service Bus Cluster，請利用Configuration Wizard在一開始的時候就正確的實作Cluster的設定，否則要從單機的設定移轉到Cluster的設定是一件很麻煩的事情：你必需按照上述的文件「手動」部署所有需要用到的.war, .jar, .ear等模組，並且更新相關參數。

Spring Framework 2.0的新功能

Dev2Dev有一篇文章介紹Spring 2.0的新功能。基本上，2.0新增的功能主要Focus在

• 簡化設定檔的xml語法
• AOP：與AspectJ有更好的整合
• Post -Injection：以前Spring只能針對自己所初始化的物件Instance進行Dependency Injection，但是Spring 2.0能夠針對已經被其他Container(例如Servlet Container)所初始化的物件進行Dependency Injection。這代表著任何Servlet、POJO，甚至EJB都有可能由Spring來提供Dependency Injection的服務。
• 排 程的新選項：CommonJ Timer/Workmanager。過去Spring主要支援兩種排程系統：JDK Timer以及Quartz。現在多加了CommonJ Timer/Workmanager的選項，讓大家放心的在Java EE的Container裡頭大膽的使用排程服務。

就以Application Server的角度來說，最令人振奮的就是最後一項新功能：CommonJ Timer/Workmanager的支援。在過去，其實沒有一個好用又可靠的方法可以在Application Server當中撰寫非同步、或者需要定時執行的程式。因為不管是JDK的Timer或者是Quartz，他們都是以直接操作 java.lang.Thread的方式來達成工作的排程；而任何直接操作Thread的行為，在Java EE的規格中說得非常清楚：Illegal。

為 什麼直接操作Thread並不被允許呢？主要是因為Application Server的設計邏輯所想要提供的是一個可靠的應用程式運作環境。然而，由程式設計師自己所操作的Thread，Application Server實在是束手無策，因為這些Thread已經跳脫了Application Server所能夠管理的環境；任何Thread的異常，都會導致底層JVM的異常，造成效能特別差、OutOfMemoryException、甚至 Deadlock。

CommonJ最大的好處就是這些API所操作的Thread是在Container的視線範圍內；這也是說，任何Thread所產生的異常，不會去影響到底層的JVM。Container會根據你所設定的QOS參數以及Timeout來決定怎麼處置這些Thread。

因此，為了做到類似排程/平行處理的效果，在過去比較好的做法是利用JMS以及Message Driven Bean；當然這樣的解決方案不會是程式設計師想要的。CommonJ Timer/Workmanager很顯然是一個更貼近程式設計師需求的解決方案。

(在這裡必須補充一點：Quartz有一種執行選項可以將工作執行的狀態寫到RDBMS裡頭；運用這種方法，基本上要做到排程的Fail-over是有可能做到的，不過等我研究出來再說吧:b)

WebLogic Server 9.0:利用commons-logging API將Log寫到Server Log

想要將Log寫到Server Log但是又不想使用NonCatalogLogger API嗎？不用改程式，做下面的幾件事情：

1. 在startWebLogic.cmd加入：set JAVA_OPTIONS=-Dorg.apache.commons.logging.LogFactory=weblogic.logging.commons.LogFactoryImpl
2. 在DOMAIN_HOME/lib下加入commons-logging API的jar
3. 到WEBLOGIC_HOME/server/lib下尋找wlcommons-logging.jar並且將jar放到DOMAIN_HOME/lib

重新啟動Server之後，所有commons-logging的log就會導到server log中。

WebLogic Server 9.0: Log API 的支援

最近在替WebLogic Server 9.0寫一個JOSSO的Plugin，就順便研究了一下WebLogic Server 9.0的Log機制有沒有什麼新功能。後來發現，9.0對於Log API的支援突然多了很多！

在8.1的時代，如果要把Log寫入WebLogic Server的Server/Domain Log，一定要透過Catalog/NonCatalogLogger的API以及機制來做。9.0新增加了一個commons-logging的 Adaptor，讓開發人員能夠透過commons-logging的API來把Log寫入Server Log。

另外也加入了Log4J的支援。WebLogic Server內建的Log機制在底層是用JDK本身的Logging package來做的；在這個部分，WebLogic Server 9.0允許管理人員在Runtime透過WLST或者Admin Console來動態切換底層Log的實作；簡單來說，如果嫌JDK Logging很差，可以改成底層用Log4J。這樣一來就可以利用Log4J可延伸的Appender API，將Log導向資料庫、Syslog Server、RMI Server或者其他客制化的Log儲存機制。

真是越來越有彈性了。

同時使用用戶數與TPS的關係

一般應用伺服器公佈的容量規劃(Capacity Planning)文件多是以TPS(每秒交易量; 交易的定義依測試標準而不同)計算, 但大部分的使用者需求是從多少個同時使用者(Concurrent Users)來衡量, 這有個簡單的算式來轉換TPS與同時連線使用者的關係:

同時連線使用者人數 = (ETT x TPS) + TPS

ETT(Estimated Think Time): 預估的思考時間, 二個連續動作的休息時間

依據這個算式, 如果二顆Sun Sparc 750Mhz的CPU在95%的利用率下, 可以榨出55.76 TPS, 假設思考的停留時間為4秒, 則同時連線人數可支撐到278.8 (4*55.76+55.76).

Weblogic Portal 8.1:整合LDAP

LDAP的整合總是有一點神秘，但是又常常會碰到的問題。
或許是因為相關書籍以及討論比較少，所以大部分的人對於這種技術並不如RDBMS那般的熟悉；但無形之中，LDAP在今天的IT系統當中仍然扮演相當重要的角色，比如說使用者帳號的存放以及管理。

今天的文章當中，我準備要介紹怎麼將OpenLDAP整合到Weblogic Server 8.1的認證(Authentication)機制；為了讓各位能夠更容易了解整合的原理，我也會稍微介紹JAAS以及Weblogic Security Framework(說實話，JAAS本身就可以寫一本書了，所以有空再另外詳述)。至於Portal的部分，我則會介紹怎麼更進一步的設定LDAP整合，以及怎麼樣設定LDAP來達到巢狀使用群組(Nested Group)權限的繼承效果。

有玩過Weblogic Server 8.1的朋友們應該很熟悉Weblogic Admin Console的操作介面；在Admin Console當中我們可以設定幾乎所有Weblogic可調整的參數。當然，由於今天講的是LDAP，所以我們現在感興趣的是如何在Admin Console當中設定安控相關的參數，以便將使用者認證的LDAP查詢機制整合到Weblogic裡面來。

首先，啟動Weblogic Server。當Server啟動完畢後，進入http://localhost:7001/console ，預設值可以用weblogic/weblogic帳號進行登入。

在這個系統啟動→登入的過程當中，其實Weblogic內部的安控引擎已經替我們做了很多事情；首先在啟動過程當中，Weblogic會詢問Administrator權限的帳號以及密碼；而透過這套帳號的認證，Weblogic內部的安控系統會決定這個帳號權限所能夠啟動的系統服務。

另 外，由於Admin Console本身就是一個採用Form-based Authentication的J2EE Web Application，而JAAS-based的認證會將認證資料傳遞給底層做苦工的Weblogic Security Framework；而Weblogic Security Framework則會根據你原來的設定，將你所提供的帳號密碼提交給Authentication Provider進 行比對，比對成功才允許進入Admin Console。至於什麼是Authentication Provider呢？簡單來說，Authentication Provider就是JAAS認證機制和實體認證儲存機制的一個媒介；透過這種媒介，理論上Weblogic可以和任何一個系統進行帳號密碼的比對以及共 享。。

大家可能會很好奇：Weblogic是怎麼去儲存預設的帳號以及密碼？Tomcat的預設做法是用xml儲存並且load到Memory Realm，那Weblogic的做法又是什麼呢？

其 實Weblogic本身Bundle了一套小型的LDAP引擎。每一個你所啟動的Weblogic Server instance都會有一個屬於自己的LDAP資料庫，但是通常你能夠去修改編輯的只有Admin Server的LDAP資料庫；其他的Managed Server會從Admin Server把最新的資料複製過來。

對應到剛剛 Authentication Provider的話題。各位應該已經猜到了：Weblogic有一個DefaultAuthentication Provider會和內嵌的LDAP進行帳號以及密碼的比對；所以如果我們想要利用OpenLDAP來取代原本Weblogic內建的LDAP，標準的做 法就是幹掉原來的Authentication Provider，而以Weblogic內建的OpenLDAP Authentication Provider來取而代之。但是有一點必須要注意！在幹掉Weblogic內建的LDAP之前，必須將裡頭的帳號密碼複製到OpenLDAP當中，否則 待會會連Weblogic都無法啟動。

如果覺得還要複製這些帳號很麻煩，其實有比較簡單的方法：讓這兩個Authentication Provider共存！只是還是必須做點小調整。

一 個Weblogic Domain可以同時存在多個Security Realm，但是只有一個是Active的；而一個Security Realm裡頭可以同時有好多個並行的Authentication Provider/LoginModule(是的，Authentication Provider實際上底層就是對應到一個LoginModule)；根據JAAS的規格，我們要透過REQUIRED、REQUISITE、 SUFFICIENT、OPTIONAL等控制旗標來告訴Weblogic，在一個以上的Authentication Provider環境中，到底哪些Authentication Provider說得話才算話(這些旗標的意義請看Java SDK的Javadoc)。簡單來說，如果我們希望在不同的Authentication Provider之間產生聯集的效果，那我們最好把這些Provider的控制旗標設定成OPTIONAL。

哇！是不是有點給他小複雜？休息一下，我們再繼續往下看。

剛剛我們介紹了整合OpenLDAP到Weblogic的原理和做法，接下來我們就來看看剛剛這些設定對Weblogic Portal來說有什麼意義。

Weblogic Portal 8.1的權限控管機制是把Weblogic Server的功能加以強化；這也就是說，其實Portal和Server之間的權限控管機制是共享的。所以，當你在Weblogic Server設定了一組OpenLDAP的Authentication Provider時，Portal也可以輕易存取這些資源，並且和強大的Entitlement功能整合，讓群組的權限設定能夠有繼承的效果。什麼是群組權限的繼承？我們用以下的一個場景來描述。

假設我們今天有一個場景，希望建立一個群組叫做信用卡使用戶，以及另外三個子群組，個別是銀卡用戶、金卡用戶、白金卡用戶。 只要我們在LDAP裡頭正確的設定信用卡使用戶的groupofnames類別，將member屬性設定成銀卡、金卡以及白金卡等群組的DN，那 Portal就會自動在進行Entitlement檢查的時候，讓銀卡、金卡以及白金卡的群組能夠繼承信用卡使用戶的權限。這是一個非常實用的功能！運用 這種功能，你可以設定一個信用卡用戶才能看得到的專屬頁面，然後在這個頁面裡頭提供針對銀卡、金卡、白金卡等不同等級的Portlet資訊。

呼呼呼，一下子寫得有點太多，文筆也太亂:b

暫且停筆囉！有空再作更深入的介紹。

tag: Weblogic, java, jaas, portal, bea, ldap

Weblogic Portal 8.1: User Profile屬性以及Java型態之對應

User Profile是Weblogic Portal 8.1個人化功能的核心。Entitlement、Campaign Management等功能都能夠以User Profile裡面的Property屬性作為底層規則引擎的判斷依據。

然而，要怎麼樣才能夠在Web程式裡頭存取User Profile呢？JSP的部分有提供Tag Library，而Netui Java Pageflow的部分有提供Profile Control來作為一個API的User Profile存取介面。Profile Control的API當中，有許多方法可取得User Profile；如果你想取得的User Profile是隸屬於目前正在操作的User，則可以使用

ProfileWrapper aProfileWrapper = getProfileFromRequest( HttpServletRequest aRequest );


User Profile的本質實際上就相當於我們常常用的Properties。

通常我們使用Properties寫檔讀檔的時候都可以假設這些東西都是字串。但是藉由ProfileWrapper所包起來的Map，當中的值都和你在User Profile當中所設定的型態有緊密的對應：

User Profile	Text	Date	Float	Numeric
Java Type	java.lang.String	java.sql.Date	java.lang.Double	java.lang.Integer

當然，ProfileWrapper也提供了將getPropertyAsString之類的方法來將User Profile屬性轉換成String，但我個人而言比較喜歡嚴謹一點的做法；另外，搭配Netui的Tag Library本身就可以做型別的Type Check，這又是嚴守型態對應的另外一種好處。

Technorati Tags: Java, Weblogic, J2EE, Programming,
Weblogic Portal

重新思考J2EE的意義

最近抽空又重新拜讀了一本過去J2EE的經典書籍：Mastering Enterprise JavaBean 2nd Edition。這本書是在J2EE1.3的規格塵埃落定的時候出的，到現在少說也有大約三、四年的時間了吧！

綜 觀過去三四年Enterprise Java的發展，我發現有兩種互相矛盾的現象同時在發生。第一種現象，當然就是J2EE成為許多企業的標準資訊基礎架構。Mission Critical的Deployment到處都見到了J2EE的影子，J2EE的運用不可不說是欣欣向榮；然而相對的，抱怨J2EE太複雜的聲音也越來越 多─這就是我要討論的第二種現象。



針對J2EE的檢討最有建設性的恐怕就是Spring Framework這個近年來最成功的Open Source Java Project。首先必須要澄清的是，其實Spring Framework的用途不僅只在J2EE的層次；在我過去的工作當中，我們利用Spring Framework加上MX4J打造了分散式的網路流量分析代理程式。Spring的概念對於近兩年來的Java開發造成相當大的衝擊：更少的Code、 更大的彈性、更好的Design。另外比較眾所皆知的，Spring和JTA的整合讓過去EJB獨有的Declarative Transaction能夠發生在Pure Java Class的層次；這大大的簡化了任何Server Side系統開發的Effort。

Spring 的成功無庸置疑。在2004年的JavaTwo大會上，我興奮的利用有限的時間分享Spring簡化開發的成果；2005年的JavaTwo大會，歐宣修 先生再度的分享了Spring開發的心得。Spring目前所獲得的注意力，恐怕只有當年的Struts能夠相比擬。

然而在這邊我必須澄 清的是，Spring的使用不代表放棄J2EE。很多支持EJB的專家認為使用Spring這樣light-weight Framework即代表放棄J2EE的核心價值；而許多使用Spring的開發人員也認為從此以後再也不需要考慮到EJB。我個人認為：Spring的 出現，增強了許多J2EE沒有考慮到的地方，讓J2EE的開發能夠更漂亮；然而J2EE當初許多的設計以及考量，也不是現在的Spring能夠完全 Cover的。

當我重溫Mastering Enterprise JavaBean這本書的時候，這種感覺更強烈。我幾乎忘了當初EJB設計的目的，是要提供一個強大可靠的分散式Middleware系統。我身為一個 Programmer的本能，往往造成視野上的盲點：彷彿這世界就只有漂亮的API以及乾淨的Design，不需要去操心Clustering、Load Balance、Fail Over等問題。舉例來說，在Spring當中的Singleton/Prototype Instance，萬一有了內部狀態，要怎樣來做Replication來因應Fail-over？純粹的Servlet Container加上Spring Framework，要怎麼樣去處理非同步訊息這樣的系統需求？

從純粹的功能角度來說，一些狀態的東西可以藉由ServletContext、HttpSession來作為一種cache的機制；而非同步的訊息架構，可以利用另外控制Thread的方式來達成非同步的效果。然而這樣真的好嗎？我們來看看。

首 先，ServletContext本身不是Replicatable。這也就是說，ServletContext裡面的東西在Cluster的環境當中沒 有一種簡單的機制能夠達成同步。HttpSession是可以跨越實體Server的限制來達到同步，我也的確認為某些使用者操作的狀態很適合用 HttpSession來儲存；但是一個我們認定為後端Service的POJO，要另外想辦法手動把他放入HttpSession來維持Cluster 之間的同步狀態嗎？這樣不但手續多了一層，似乎也不是很好的Design。至於利用直接操作Thread的方式來達到非同步的效果更是危險。Thread 的狀態是無法跨VM做Replication的，因此這種Solution也不夠Reliable。

我想，了解一種技術想達到的目的和了 解它的限制一樣重要。Light-Weight Framework並不是Middleware；而Middleware的設計其實主要的焦點在於可靠性。我們可以利用一個像是Spring這樣的 Framework來幫我們隱藏以及簡化許多Server-side開發的細節，但是Spring仍然需要一個Middleware來解決High Availability的相關的問題。因此我相信，Spring和J2EE是相輔相成，而不是互相衝突的；EJB的專家應該仔細研究Spring的開發 模型能夠為J2EE帶來的彈性；而Spring的使用者也必須意識到Spring是一個Framework，並無法取代一個Middleware的價值。

在Weblogic 8.1上跑Openlaszlo 3.0

試了一小段時間了....跟各位分享一下心得。

首先介紹一下什麼是Openlaszlo 3.0。

Openlaszlo 是一個類似Macromedia Flex的Flash based presentation server。所謂的Presentation Server就是跳脫傳統HTTP Server服務html網頁的方式，以自己的獨特技術來提供一種客戶端的 UI呈現技術。舉例來說，Cocoon勉強可以算是一種 Presentation Server；Cocoon所提倡的xslt轉換能力，的確是在Presentation Tier提供了一套自己的UI呈現技術。

不過如果我們把所謂的Presentation Server的定義縮小到「提供Rich Internet Application能力」的涵義，那所謂的Presentation Server大概就剩下Macromedia Flex、Laszlo Systems所Open source出來的Openlaszlo以及零零碎碎一些提供類似Server-side XUL+Java Applet的Rich Client技術。

扯遠了，我們今天的主題是Openlaszlo :b

首先，下載Openlaszlo。Openlaszlo應該有四種下載方式：

• SDK。這是一個已經幫你準備好的Tomcat bundle，如果是Windows平台的話已經有installer。


• SDK。這是一個.war的檔案，也就是Web Application Archieve。要在Weblogic上頭跑Laszlo，請下載這個檔案


• Source。自己Compile比較合你的胃口嗎？


• Core。這也是一個.war的檔案，可是沒有Tutorial以及Demo

下載了.war之後，請找一個目錄將.war解開來，然後啟動Weblogic Server開始進行Deployment的程序。

首 先用Weblogic Builder的Deployment Descriptor開啟Openlaszlo的Web Application目錄，然後開啟「Prefer WEB-INF classes」的選項。這個選項之所以必要是因為Laszlo< style="font-family:SimSun;">所需要的xerces版本和Weblogic所提供的不同，所以必須以這個選項告訴 Weblogic Server在Class loading的時候優先以WEB-INF目錄下的Class和library jar為優先載入Classpath。

調整完該選項後，請檢查WEB-INF/lib< style="font-family:SimSun;">下是否有一份xerces.jar？如果沒有，請去Apache的網站上下載一份。這些步驟完成後，我們進入 Weblogic Administration Console。

還記得剛剛把.war解開的目錄嗎？我們現在利用no-stage< style="font-family:SimSun;">的方式將該目錄Deploy到Weblogic Server上面，這個時候如果我們利用Web App的測試功能，就可以看到Openlaszlo< style="font-family:SimSun;">的Welcome頁面。

接下來我要簡短的敘述一下，之所以要使用no-stage Deployment的原因。

我們都知道，在Weblogic上頭的Deployment大致上可以分成三種(詳細敘述請見Weblogic Server Documentation)：

1. Stage


2. No-stage


3. External Stage

使 用第一種方式來Deploy Web App是很方便，但是因為檔案都會被Copy到Staging Directory，所以往往目錄結構會和Web App原來所設計的有所不同。像是Laszlo這種需要Runtime去Compile出Flash檔案的Web App，目錄結構一亂掉就無法正常運作了，因此我們必須採用No- stage的Deployment模式。

tag: java, weblogic, openlaszlo

通過BEA 8.1 Certified Administrator

BEA 8.1 Certified Administrator是一個針對Weblogic Server管理員所量身訂做的認證。考試的內容側重於Clustering/Fail over的管理、效能調整、J2EE基本概念(1.3)、安全性等Production環境常常碰到的議題。
考試分鐘120分鐘，69題，66% 就算及格。重點是在於Weblogic JMS/EJB/JTA部分的HA設定，題目在這方面著墨甚多，但是相對的只要能夠花點時間去了解Weblogic的特殊Behaviour，要通過這個考試並不會太困難：因為Weblogic Server的管理，本來就不會太困難:-)

Technorati Tags: Java, Weblogic, J2EE, Programming

在WebLogic Portal中，如何讓每個user看到不同的look and feel？

在使用Portal的時候，讓user可以自己選擇版面的風格，或是利用不同的風格，來做一些使用者感覺上的區隔，算是再普通不過的需求了。例如，當一個 user登入系統之後，我們用程式去判斷使用屬於哪個群組，如果是內部員工，就給他藍色的版面，字體清晰；如果是外部的客戶，我們可能就利用很多圖片，和 比較活潑的顏色，把畫面弄得花俏一些，以吸引客戶的注意。

在WebLogic Portal中，要做到這樣的功能，牽涉到幾件事情：
1. 要有多組的look and feel用來切換<--廢話 2.Portal必須在streamed mode下執行，file mode是做不到的 3.使用Backing file的機制，讓user在login之後，利用程式切換桌面look and feel的設定 其中，關於2的部分，如果您不清楚什麼是streamed mode，什麼又是file mode，請參考http: //edocs.bea.com/wlp/docs81/lookandfeel/lookandfeel.html#999682。 關於3的部分，如果您不清楚什麼是Backing file，請到http://edocs.bea.com搜尋backing file這個詞，把相關的文件多看看，就會比較瞭解。基本上，他就是一個java程式，在JSP之前執行。也就是說，如果我們寫了一支JSP，然後把這個 JSP變成portlet，接著又給這個portlet指定了backing file。那麼當這個頁面要呈現的時候，server會先去執行這個backing file，在這個backing file中，我們可以設定一些屬性，這樣當JSP要呈現畫面的時候，就可以根據這些屬性，去做一些調整。 以本例來說，我們利用signin.jsp程式來做login的動作，可是在這個jsp的背後，有一支SigninBacking.java，在 backing file中，我們去讀取user的屬性，然後把屬於該user的look and feel設定好，接著才是JSP，根據backing file設定好的條件，呈現在畫面上。 多說無益，這邊提供一個完整的範例，總共三個壓縮檔都要下載，裡面都是原始程式碼，大家回去自行研究一下吧。 [下載LAFViewlets.zip]
這 是該如何測試這整套look and feel切換的範例程式的說明，都是動畫。在看動畫之前，你必須先建立一個全新的portal domain，然後利用workshop建立一個全新的portal application，裡面在建立一個portal web project。因為這個套件會覆蓋掉一些原有的檔案，因此一定要用全新的環境來測試，否則原來的檔案被蓋掉遺失，我可不負責。

[下載 LAFTestKit_WebApp.zip] 這是測試套件的一部份，裡面有兩套look and feel，一個是改過的default look and feel，另一套是叫做sdp winter look and feel，相關需要的圖檔也都在裡面。此外，這裡面還包括一個signin.jsp以及SigninBacking.java的backing file

[下載LAFTestKit_UserProfile.zip]
這 裡面只包含一個檔案，其實就是當你產生一個portal application的時候，那個data資料夾中，系統自動幫你建立的CustomerProperties這個user profile。套件中包含的，只是把原來的profile，加上一個叫做LookAndFeel的property，如此而已。

===
接 下來的說明，你一定要先把範例執行過，才知道我在說什麼。接下來我們就看程式。其實signin.jsp是一支再簡單不過的程式了，所以根本不需要看。 唯一要看的，就是SigninBacking.java，而這個backing file真正需要看的，也就只有49~71行中間而已，其他的不是重點。關鍵的指令在68行，我們要update desktop的instance，其中有一個參數，就是傳入look and feel的id，就是從這邊，我們得以重新設定user所使用的look and feel。但是為了要執行這個method，還有其他的參數要輸入，因此，49~57行就是在取得url的path資訊，記住，是streamed mode的url，不是file mode的url喔！59~64行，就是去抓剛剛登入的這個user的CustomerProperties的LookAndFeel這個 property的value。

其實就是這樣而已，沒什麼。如果你想更進一步知道updateDesktopInstance這個方法裡 面做了什麼，如果你的WebLogic Portal版本是8.1 SP4，你可以在你的portal web project的WEB-INF\src下面找找，可以找到PortalVisitorManager的原始碼。SP3應該也有。

其實這 個就是從visitorTools裡面擷取出來的功能啦。visitorTools不知道是什麼嗎？注意看一下你的portal web project，裡面不是都有個叫做visitorTools的目錄嗎？這是個讓user可以自己客製自己的portal的工具。又該怎麼用？請參考 http://e-docs.bea.com/workshop/docs81/doc/en/portal/buildportals/visitorToolsAdd.html

弄 懂之後，相信你的腦中應該浮現出各式各樣的應用方式，例如我不用user profile來讀取屬性，而是去讀取日期，當聖誕節前後，我就換上聖誕節的look and feel。或是我可以再做一個頁面，讓使用者自己來選擇他要套用的look and feel...等等。就WebLogic Portal來說，動態套用不同的look and feel，是一個複雜但是並不難的工作，如果能把這些關係搞懂，那麼將來對portal的操控就會更加得心應手。

以上的程式，在WebLogic Portal 8.1 SP3, SP4測試過。作業系統，Windows XP SP2.

Virtual Directory範例

WebLogic Server的Virtual Directory功能，可以讓多個Web Application共用同一個目錄下的資源。通常就是用來放一些每個Web Application都會用到的圖片、靜態頁面等等。

這個功能很實用。不過在設定的步驟上，文件寫得有點簡略。如果你看過一次就設定正確，那必是天資聰穎、慧根獨具。如果設了半天還是怪怪的，那也還好，我也是去把WebLogic Server內附的example挖出來看才窺見其中的端倪。

為 了讓大家少走一點冤枉路，小弟做了一個簡單的範例，讓大家玩一玩WebLogic Server的Virtual Directory。範例中包含一個step-by-step的動畫、一個簡單的Web Application，以及我家狗狗的美圖一張。測試的環境是Windows XP SP2英文版+WebLogic Server 8.1 SP3繁體中文版。

「點我下載完整文件」

Http Control使用範例

Http Control是幹嘛用？簡單說，他扮演一個http client，像是一個瀏覽器，可以向遠端的web server發出request，並且取得response。因此，你就可以利用http control，寫程式幫你上網，而不用坐在電腦前面親手操作。

所以典型的運用是什麼呢？沒錯，就是寫一個上網機器人，幫你到一些沒有設防的網站，註冊一狗票email帳號，然後狂發垃圾郵件給討厭的人，灌爆他的臭信箱！

另外一個比較無聊的應用，就是企業內部的網站整合啦，你可以利用這個方式，幫user去其他的網站擷取資料直接show在當前的畫面上，而不需要讓user做一些笨事例如「自己重新開一個視窗，連到另外一個網站，看到資料，再自己抄下來」

本範例需要對WLI有基本的瞭解

這個範例基本上是從dev2dev的sample中擷取一小段修改而來的，。
完整的範例請點後面下載「HTTP Control/Event Generator for WebLogic Platform 8.1」

Http request常用的(意思就是不是全部)傳遞資料到後端的方式，有GET和POST兩種，這兩種http control都有支援。

Http GET的範例相對來說比較簡單，亂弄都會通，有興趣的人請「點我下載」

Http POST就必須先對「該如何傳送一個POST request」有所瞭解，瞭解之後就會跟GET一樣簡單。如果不先瞭解，就會怎麼弄都弄不出來。POST的範例，請「點我下載」。 這個範例是以一個testPostPageFlow當作測試對象，原始碼已經附在壓縮檔中，如果不知道這個page flow應該安裝到什麼地方，可以參考app_structure.jpg，簡單說就是放在一個名為simpleWeb的web project之下。至於viewlet的觀看順序，則是先看simple_page_flow_and_POST_request以瞭解POST reqeust的組成，再看http_control_and_process瞭解http control的相關使用方式。

由於小弟的範例有例用到dev2dev sample中的文件，因此建議最好還是下載一下上面的範例

Portal和Portlet的中文化/多國語言化

WebLogic Portal內建許多寫好的程式，包括login的程式、討論區、行事曆...等等。既然人家都寫好了，不拿來用豈不成了冤大頭、笨蛋加三級？不過老美很可惡，寫的都是英文，都不寫中文，所以我們只好自己來做中文化。

說 「中文化」聽起來比較俗，我們應該要說「國際化」。國際化讓你想到什麼了嗎？是的，就是i18n。意思就是說，不同語言的客戶端連上你的portal， 就可以看到不同的語言和文字，但是事實上，你的程式只有一套，這些不同的語言文字，是根據客戶端的locale，從不同的語言檔動態抓出來顯示在UI上。

在WebLogic Portal上面，如果要支援多國語言，有幾種不同的做法，在dev2dev.bea.com有「現成的範例供大家參考」。此外，小弟特地以WebLogic Portal安裝時會順便安裝的sample portal為例，將其中的行事曆(calendar)的portlet做一點小小的修改，讓大家感受一下用i18n做國際化的威力，以及實做上應該注意的小技巧。

完整的範例，請「點我下載」