直上Google App Engine雲端運算平台(1)
Google App Engine for Java環境建置
文／圖 盧建州．責任編輯／洪羿漣

分散式架構與雲端運算，是本年度最熱門的話題之一，而Google於2008年4月推出的雲端運算平台「應用服務引擎(Google App Engine, GAE)」，讓開發人員無須了解分散式基礎環境的建置，即可參與雲端程式的開發。

---

原先只支援Python的GAE在今年滿周歲的4月開始支援了Java平台，正式宣告了為數眾多的開放原始碼社群加入GAE開發的時代來臨。使得原先心態抱持著觀望的筆者也決定加入了推廣GAE的行列之中，為了與Python作區別，對於Java環境的應用服務引擎，我們將統稱為GAE/J或GAE for Java。

在RUN!PC第183~186期的[技術專欄]中，筆者以GWT為例，分別以架構師的觀點講解了專案建置、測試觀念與日誌記錄的重要性。而新雲端平台的出現，當然不能免俗我們也將導入軟體開發專案於分散式架構中的應用，正因為如此，接下來幾期的文章中所有給與讀者的概念將包裹上GAE/J的糖衣。


備妥開發環境
對於GAE/J如何申請帳戶、基礎相關知識與官網所建議的開發方式，筆者並不重覆論述，請自行連結官網[http://code.google.com/intl/zh-TW/appengine/]查看相關文件。本期所建置的開發環境將依實際專案範圍進行區隔。


中小型專案開發環境
在此所指的是由個人或一個小團隊來完成專案的開發環境，需求的開發工具與套件如下：

1.必要開發套件
●Java SE Development Kit 1.6.0_14。
●Eclipse IDE 3.5.1。
●Google Plugin for Eclipse。

2.選用開發套件：GWT Designer(付費開發套件)。

3.分散式版本控制系統(擇一安裝)
●Mercurial Plugin for Eclipse。
●TortoiseHg 0.8.1。

Java與Eclipse的安裝，對開發人員來說並不陌生，比較不同的是加入了選用套件與版本控制系統的安裝。GWT Designer是輔助製作GWT使用者介面的工具，可用拖曳UI的方式進行畫面的編排，對於GWT的初學者來說著實方便，可惜的是該套件需商業授權，未付費者有14天的試用期。但GWT是基於物件式的開發，早已封裝了HTML、JavaScript與AJAX與其他不便技術的複雜性，只要有物件導向觀念與Swing UI的經驗，對於GWT的應用基本上不會有問題。

另外版本控制系統來說，過去筆者已介紹過SubVersion版本控制系統，但過往堪用的工具每當新時代的到來多少就會發現到不敷使用的困境。分散式架構已經是不可避免的潮流，過往的Client/Server架構的版本控制雖可繼續延用，但卻不若新式的分散式版本控制系統Mercurial來的優異。

無論是個人或中小型專案可因應需求擇一安裝，差異在於使用Mercurial Plugin for Eclipse將可使開發完全於Eclipse IDE中進行，而TortoiseHg則內嵌於系統中為Mercurial分散式版本控制系統之本機端與伺服端，筆者將於之後的文章進行全面性的說明。


大型以上專案開發環境
從開發人員的角度來看，備妥上述開發環境即可達到運行與部署GAE/J應用程式的中等要求，但若是以架構師的觀點來看則遠遠的不足。作為大型專案的指導者來說還必須考量持續性整合(CI)與配置管理(CM)。所以通常在大型專案中系統整合人員或架構師會用自己熟悉的工具建立自動化持續性整合與配置管理腳本。在Java EE的領域中針對大型專案我們一直應用的則是Maven。

於筆者的過往文章中，Maven無處不在，而GAE/J專案的開發，Maven也將應付自如，建議讀者先自行安裝下列套件，我們將在下期中講解使用Maven開發GAE：
●m2eclipse：Maven2 Plugin for Eclipse。
●Maven2。


設定Plugin
首次安裝Google Plugin for Eclipse過程中，GAE/J與GWT的SDK會隨著Plugin的安裝跟著下載並置於外掛路徑下。原則上來說安裝完成後即可進行相對應的開發程序。但有一點需要留意，目前GWT與GAE/J皆為較新穎的開發套件，SDK版本更新較為頻繁，若是喜好嘗鮮的開發人員，時常進行外掛套件的版本更新的話，有時會不經意引來版本錯亂的狀況發生。

以筆者情形為例，首次安裝Google Plugin for Eclipse時內嵌的GWT版本為1.7.0，GAE/J版本為1.2.5，當用該版本開發一段時間後進行外掛套件更新。此次更新後GWT版本為1.7.1，GAE/J為1.2.6。

剛更新完畢時新、舊SDK暫時皆會同時存在，為何說是暫時呢？原因在於目前Google外掛套件的更新原則，當對應SDK隨同一起Update後，於下一次啟動Eclipse後將移除舊版SDK。

當版本更新幅度不大時，如只作Bug fix的話還不會有問題，若新版本增加了較不相容的功能時，對於開發的影響則不容小覷。以前者來說，GWT1.7.0到1.7.1只進行小幅修正，但GAE/J1.2.5更新為1.2.6時於新版中加入了特別的appengine-agent.jar檔，這個改變將造成現行的程式在新的SDK的本機端測試環境無法順利啟動。

因此針對版本問題的處理原則，應遵守當專案開始進行實際開發階段，相關第3方套件的*.jar檔、SDK，或其他相依於版本的資料，若沒特殊必要，切勿進行更動。

無論商業開發套件或其他開放原始碼如何掛保證，如一般版本號編排為[主版本號.子版本號.修正版本號]，並且有以下規則：
●主版本號的不同，代表新舊版本將不相容。
●主版本號相同，子版本號不同，表示新舊版本相容，子版本號為功能增強。
●只有修正版本號不同，代表版本間是完全可互換，差異可能只在於極小的Bugfix。
縱然原則是如此，但每當第3方套件版本間的替換，經常依舊是開發人員的夢靨。

一般而言開發套件版本更動，必須由架構師，或資深的系統整合人員先行處理相容性問題後，再統一修正並公佈更新。從現行的Google Plugin for Eclipse來說，建議作法有二。其一如同前述，當專案已進入開發階段，開發人員對Google外掛套件即暫時不進行更新，若需更新則先行由專責人員解決可能引發的版本問題後，統一公告所有開發人員同時更新，此時更新後所有人員的開發環境亦必須一致。

其二，開發環境中自行指定GAE/J與GWT的SDK路徑，不使用預設內嵌的SDK，如圖1所示。分別點選[Window]→[Preferences]→[Google]選項中的[App Engine]與[Web Toolkit]，可以看到皆有第二個SDK設定。

此處的設定指向自行下載的SDK路徑，並勾選為預設，這麼一來無論Google Plugin更新多少次，將不會引發現行開發專案的版本問題，並且保持Plugin支援功能為最新版。


圖1：Google Plugin for Eclipse設定。

另外若決定試用並安裝了GWT Designer外掛套件的話，亦必須指定GWT的SDK路徑，如圖2所示，設定路徑與Google外掛套件的Web Toolkit指向同一個SDK。


圖2：GWT Designer Plugin設定。


開發環境畫面配置
經過上述的配置與設定，於Eclipse IDE中我們將擁有非常友善的GAE/J的開發環境。若為個人式開發的專案，面對如此簡易又繁複的設定，必須不假他人之手自行安裝，並嘗試兜出一個符合自己所需的開發介面。而在稍具規模或分配了架構師的專案中，各開發人員的環境則將會被統一配置。

最好的做法是由專職的負責人員建置好開發平台後打包並壓縮，再轉送至各參與人員的手上。最少也必須如本期開頭所述，定義出各開發套件與其詳細的版本資訊，由開發人員自行備妥，以達到所有人員皆一致的開發平台，如此將可最小化專案初期一些不必要的問題。如筆者於前幾期的範例中，要求讀者下載的Eclipse就是屬前者的做法(參考http://code.google.com/p/arch-tutorials/wiki/DevEnvGeneralIde)。

當然本期所進行的環境配置說明就屬於後者所述，一切就緒後開發過程的操作介面將如圖3所示，標示編號說明如下：
1：為Google Plugin功能表，由左至右分別是：建立GAE/J專案、編譯GWT、部署GAE/J至遠端伺服器。
2：GWT Designer建立專案的功能表，在GAE/J專案中不使用。
3：GWT Designer功能，用於產GWT中各模組與元件，與Google Plugin中GWT同性質的功能比較起來較為優異，但不代表必要使用，因Google Plugin已可達到一般使用要求。
4：GWT Designer所見即所得使用者開發介面，往後的說明中，我們將會個別介紹手工打造GWT與使用該開發介面的方式。


圖3：備妥的GAE開發環境操作介面。


HelloWorld GAE/J的初體驗
這似乎已經是個不成文的規矩了，每當有了新技術，需要進行快速入門的講解時，就得做個HelloWorld展示來跟這個世界拜個碼頭，以免失了禮數。在GAE/J的官網與許多先進的文章中，或多或少都有做了建立新專案的導引，對於在網路上可搜尋到的部分與概念，本節將不進行說明，筆著將專注於未提及的觀點進行導入。

首先參考圖4，點選標示1，使用圖示工具或下拉功能表[File]→[New]→[Web Application Project]皆可，再於彈出對話框內填入專案資訊，注意[Use Google Web Toolkit]與[Use Google App Engine]皆必須勾選。當按下[Finish]後將依填入的資訊建立專案，本次範例專案名稱為archetype-gae。於Eclipse中資料夾結構將如圖5所示。


圖4：新建GAE專案。


圖5：HelloWorld專案資料夾結構。

src資料夾放置了GWT的原始碼，war資料夾則包含了靜態的網頁與相關資源檔，如*.css，有趣的一點是範例中包含了二個log設定檔：一是src下的log4j.properties；一是war/WEB-INF/logging.properties。但在*.java的範例中，並沒有任何一處執行Log的函式，事實上是宣告的意味重於範例的展示。

在GAE/J官網的文件中提到，GAE/J支援日誌功能，但部署至遠端的應用程式只能使用JDK內置的java.util.logging。但在本地端的開發中，還是允許使用其他的Log機制的，如可以用Commons Logging，本地端測試使用Log4J，部署至遠端伺服引擎上時切換為java.util.logging。

src/META-INF/jdoconfig.xml這個範例中並未使用到，在此也是宣告的意味，表示進行JDO資料持久化時可對該檔進行設定，若為JPA的話則使用設定檔為src/META-INF/persistence.xml。

最後的重點在於war/WEB-INF/lib 路徑下的所有*.jar檔，此處所存在的函式庫檔，是於建立專案過程中，由Google Plugin複製產生，因此新建專案後即不會再更新。還記得前述所說的版本問題嗎？每當Eclipse外掛更新後引發的版本錯亂，通常就是由此處觸發的。另外，若開發人員手動將此處系統複制的jar刪除，本地端測試也將無法順利運行。

雖然首次建立的專案範例還有許多地方需要留意的，我們暫且留到下期再繼續討論。在不修改任何程式碼的狀態下，這個專案是可用的，於專案資料夾按下滑鼠右鍵執行[Run As]→[Web Application]後，將出現GWT host模式的GUI畫面。

確認程式執行無誤且關閉本機端程式後，我們將發現於war路徑下產生了archetype_gae資料夾，與war/WEB-INF/lib不同的是，本範例中的archetype_gae是GWT的模組名稱，也就是在運行GWT編譯的過程中產生的Client端模組程式碼。可以試著將其刪除，於下一次[Run As]→[Web Application]運作過程中將會再次產生。

確認本機端執行並測試無誤後，才可將GAE/J應用程式進行上傳(GAE帳戶必須先行申請)。參考圖6所示，按下標示1執行[Deploy App Engine Project]後，將彈出如標示2中的對話框，要求輸入GAE帳戶資訊。首次上傳的應用程式還必須指定[Application ID]與[Version]資訊，為此我們按下標示3並於標示4中填入資訊(Application ID必須先行於GAE後台先行建立)。按下[OK]與[Deploy]後Eclipse即接手進行應用程式上傳並回應部署結果。


圖6：上傳GAE/J應用程式。

上傳完成後隨即可開啟瀏覽器驗收成果，不過在此之前先了解一下GAE後台介面，將有助於日後應用程式的管理。參考圖7，連結[https://appengine.google.com/]進行GAE後台登入。

於標示1中輸入先前申請的帳戶資訊，確認登入完成時，畫面將移轉至標示2的My Applications，此處所列清單為帳戶所建立的各個應用程式。Application欄位所指的就是先前上傳應用程式的[Application ID]，Google限制每一個GAE帳戶最多只能建立10個Application，並且建立後將無法變更名稱與移除Application。

圖7中的標示3為Current Version，代表的就是目前直接連結GAE應用程式時，預設執行的版本。讀者對此處可能較難理解，我來加強說明一下。


圖7：GAE/J後台管理與範例執行。

前面提過Google限制每個帳戶最多只能有10個Application，而每個Application可部署最多10個Version。對於Version的應用則由GAE帳戶人員決定，你可以循規蹈矩的以版本1、2、3…作為編號，部署同一個應用程式的各個版本，亦或是以英、數加上「-」符號，自定各個Version來部署不同的版本，甚至是不同的應用程式皆可。在圖7中標示4中的各個Version，可看出筆者於實驗過程中，隨意取了多個版本名稱，事實上也部署了不相干的數個應用程式。

對此，若為實際專案開發的過程中，則可為每位開發人員建立部署特定Version的權限，因此在協同開發的過程中，不會造成同時間部署到同一版本而造成相衝突，或互相牽制的狀況發生。

每個Version皆有個Live URI，該欄位中的網址即為部署完成後執行GAE/J應用程式的可用連結，如本次範例的版本號為1，點選圖7中標示5的連結，即執行了最終結果的GAE應用程式，完成本期目標的GAE初體驗。