OFBiz Go

App 很紅, 主要在行動設備上, 上下游都很火紅。要談的 App 是現在不太紅的 Ent App (Enterprise Applications), 或是說已經紅過了, 但仍然是每個公司, 組織都會用到的。

App 多是產品, 而 Ent App 是種社會(Social), 俗名是江湖, 充滿交流與妥協, 大多以專案形式進行。就算從產品開始, 後面也會帶專案, 常見區分出軟體, 硬體, 開發, 維護, … 各個階段。

由於 Ent App 牽涉層面通常既廣又深, 以技術角度來看, 擴散方式(銷售, 安裝)一直沒太大改變。現在雖然服務導向, 雲端喊得震天嘎響, 但除了網路基礎服務(信件,檔案), Web應用或特殊應用, 要把 Ent App 放上去, 應該還有些東西要準備好。用雲端的榜樣電與水比擬, 水除了自來水, 還有各式來源; 電除了公共設施, 也有可移動型的, 或私人備援。因此資料的移動能力要具備, 否則還是有些不足。

開放源碼讓技術普及, 加上硬體設備的大幅提升, 過去得詳加規劃, 才能執行的 Ent App, 現在只要在雲端或筆電開個 VM (虛擬機器) 就行開工。再者, 小公司不需要 24 小時運轉的系統, 功能有的話, 需要時再開啟。甚至中型單位, 只要合宜的環境及配套規劃, 也能朝這方面努力。

首先, 要面對的問題是 … 怎麼去開始?

在 OFBiz 下載頁面中, 寫明只要有 JDK(Java 1.6 SDK), 下載 zip 後解開壓縮檔, 執行指令就可以開始。

似乎還算容易?

但每個平台準備 JDK 其實都不太一樣, 更不用說如果發生衝突的話要怎麼辦, 例如在 Linux 上用 OpenJDK。這些說明字句雖少, 看起來簡單, 毫無疑問是寫給工程人員看的。再加上 Ent App 的社會屬性是有機成長, 如果要修改, 要調整, 按照慣例就得靠自學, 或找人助拳。

以整個過程來看, 愈到後面, 障礙愈高, 的確是不太容易推動。

之前在一種應用源碼管理的實作討論過 可短小, 可長久, 可分享 的客製化方式。路雖然通了一小段, 但想想, 比原來 OFBiz 官方的安裝方式還要複雜, 素人要開始, 會有不小的障礙。

因此做了 OFBiz Go 用一個步驟完成 所有 繁瑣的準備工作。

準備工作有:

1. 下載必須的 JDK, Python, Subversion, Mercurial 以及相關工具(patch, diff, cURL, 或 Wget), Windows 要再加 MinGW。
2. 安裝妥上面這些東西, 做好設定 … 例如系統變數, Mercurial 的設定, 與 virtualenv 的環境。

當然如果機器上已經有的軟體項目, 就略過不下載, 也不安裝。

寫上一篇的時候, 略過這些步驟。對熟悉這些工具的人, 早就備妥; 但不熟悉的人, 繁瑣且容易漏東漏西的過程, 反而造成困擾。即使自己做, 將這些裝到 Linux, 也碰上不少問題。

想做個 VM 來用, 但每次要把數 GB 的東西搬來搬去, 還得搬進雲裡頭, 舉重若輕恐怕也不太容易辦到。

在支援 Windows 前提下, 也考慮 Puppet, Chef, 或老牌 CFEngine 這類 組態管理 工具。但即便輕如 CFEngine 都必須做額外的安裝設定, 所以這工具還是留給 應用系統, 做為其中的組件。

剩下可用的大概就是系統腳本語言(Shell Script)。

OFBiz Go 是先在 OS X 上寫個 .sh 做完上述工作。然後找到 Windows 2008 用 Powershell 寫個 .ps1。最後用 VMWare 開啟 Ubuntu 11.10, 原本認為 OS X 小改就可以用, 但還是改了不少。

比較特別是 Powershell 挺有 Power 的 … 要正確合法下載 JDK, 需使用者同意。Powershell 可控制 IE 瀏覽器帶出正確下載網頁, 當使用者點選同意後, 繼續腳本的工作。

目前在 OS X 10.6, Windows 2008R2 / 7, 還有 Ubuntu 11.10 測試過。OS X 可能會不太行, 因為環境不乾淨。;-)

只要腳本的下載, 安裝, 驗證的工作做完, 就可和 應用程式源碼溝通。把繁瑣的過程, 劃分成兩個階段, 方便入門者, 也方便自己。

由於大部份工具和 Python 相關(Fabric, MQ), 下週三(2011/12/21) 晚上 19:30 在新竹的 PyHUG 會描述 配置方式 與 應用客製 兩階段的安排, 及運作細節。除了 Ent App, 很多類似的狀況, 也可用相同方式處理。歡迎參加, 和我們一起討論。

開放源碼資訊應用系統的開發觀點

資訊應用系統較開放的定義: 公司、組織所需要的應用系統, 下面縮減為企業應用(Ent App), 與當下常見移動 (Mobile) 和 Web 應用有所區別。開放源碼顧名思義即可。身處在公司組織中, 資訊系統所涵蓋的可能是有什麼用什麼, 或依需要採買。企業應用則依公司組織的需求, 所打造的應用 … 有些是獨立系統, 或某個系統的擴充。常要與不同單位, 甚至跨公司組織的各系統聯繫以協同作業。

去年 2010 接觸一個國外頗具規模組織的企業方案導入, 從基礎設施開始到應用系統的那種。儘管方案已落入 M 社手中, 仍有許多可深入思考借鏡之處。

這個需要方案的組織, 雖然考慮過開放源碼方案, 對技術有想像, 對未來有憧憬, 最後還是回到踏實的 … 支援問題。

按捺支援問題, 整理過程中一些溝通討論的部份。

從頭開始的組織, 討論的觀點有多高? 大概有太空那麼高。平常較常用的辭彙字眼, 鮮少在此時派上用場。與非開發者進行討論, 還是得用流行 … 呃, 太空的觀點來溝通, 也難怪不斷有人創造一些東西來滿足。在其中討論的議題有目錄服務, 檔案分享搜尋, 管理監控, 入口網站, 工作流程, 應用系統, … 等。前三個題目, 一般公司組織都給 M 社綁住, 接下來似乎 M 社都把東西都準備好, 都可一次夠足儘管用。

曾被詢問: 如果不用 M 社方案, 這些問題如何解? 兜幾家公司產品才解決又沒參考案例, 說服力自動下降。能否找到適當資源滿足這些要求, 就成了給自己的寒假作業。

選擇以 Java, Python 為基礎, 避免對作業系統的依賴太深。

把問題劃分幾個區塊, 否則以系統/應用分太簡略, 純以開發觀點來看又太複雜:

• 應用系統: 這是已經存在並使用的應用。ERP, B2B, 入口網站, 網購平台, 生產系統, … 甚是以套件存在的論壇, 而開發成果也在此區塊。
• 基礎系統: 不需要應用也存在的系統。例如電子郵件, 資料庫, 網站網路服務(Web/FTP), …。
• 工具: 基本上是支援開發相關工具。像源碼的版本管理, 記錄工作的事例追蹤, 負責測試建置, 文件產生, 資料處理, …
• 開發作業: 可以是獨立的應用, 但通常除了基礎系統, 也與其他應用系統打交道。現在複雜環境, 選適當語言外, 更需要適當框架加持。

這些區塊的涵蓋面是否恰當, 以流行的 Web 框架來檢視: 資料庫/網站在基礎系統; 編輯器/版本管理在工具區; 開發框架本身在開發作業區; 如果套在入口網站裡, 就看成在應用系統區。

再來把之前討論議題在放進來:

• 目錄服務: 有名的 OpenLDAP 使用過一陣子, 那時要編得安全一點不太容易。現在 ApacheDS, 有 Java 環境就能很快上手。雖沒 M 社搭配其作業系統的特異功能, 但具備 Kerberos, DNS, NTP, DHCP。另有 Directory Studio 處理綱目和資料都便利, 而單一簽入(SSO)可交給 CAS 處理或 PicketBox。這些放到基礎系統區。
• 檔案分享搜尋: 從歷史來看, M 社把之前拳王 N 社撂倒後就一直雄據著, 不過移動設備和 Web 普及應該稍有機會推動一下這板塊 … 內容管理交互服務(CMIS)。實作不少, 偏好的是 Nuxeo, 實際選擇視需求而定。也放到基礎系統區。
• 管理監控: 之前做都是一兩個系統加上數個服務, 要求是把自己做的管好就好, 沒從組織觀點來看。這方面有許多成熟產品, 例如 SpringSurce 有併入 Hyperic。會考慮的是 Zenoss, 畢竟現在有各式各樣服務, 彈性大一些會比較好。而 Java 在開發作業考量與 Zenoss 搭配, 執行記錄方面從 log4j 著手走 syslog 即可。還是放到基礎系統區。
• 入口網站: 已經流行過好一陣子的題目, 或許每個人都有自己的一套, 就略過。分類的話, 由於依使用方式不同而有差異, 所以放應用系統區。
• 工作流程: 推薦的是原 jBPM 開發人員從 jBoss 離開, 在 Alfresco 支持下做的 Activiti 專案。從 2010 年底釋出 5.0 以來, 2011 的前兩個月都按表操課, 穩定釋出新版本 5.1, 5.2。具備彈性流程工具外, 比較特別的是考慮開發人員甘苦, 不會一昧討好商務端人員。Activiti 可考慮嵌入與應用共存, 但從服務獨立、聯合管理的角度, 應該是單獨存在的系統, 因此放到基礎系統區。
• 應用系統: 從開發觀點來看, 只要一個語言就可做任何事, 然而任何人能完成的事情都是有限。現成開源應用系統也不少(ERP, CRM), 加上在雲端的就更多。但能否存活, 像後者在 2010 收了好幾家, 特別讓人有疑慮。因此期望把關鍵資料放在自己可以掌握的地方, 彈性/好用是必需的, 但也不會因為開發專案的公司策略調整或併購而影響。因此選擇 OFBiz 來擔任企業核心的應用系統。

回頭看各區塊, 應用系統依實際狀況而定, 基礎系統補上即時訊息(IM) Openfire 做即時通訊, 另外以通用伺服器 Felix, Karaf, Camel, ServiceMix 統籌日漸增長的服務。工具區塊比較被熟悉, 也常見許多討論個人、團體開發過程中面對的問題與解決方式。這裡對之前 近未來 IT 開發 一文做補充, 成為開發作業區塊:

• 穩定層: 包含應用系統與基礎系統, 有穩定的界面。例如 ERP 財務的界面, 或像檔案傳輸的方式也固定。
• 動態層: 原本以樣板打造動態層, 要含括一般且普遍的情況下, 得選用框架。以 Web 來說, 會用 Grails, 他和原本 Java 與企業大宗資源 DB 溝通方式非常的 … 一脈相承, 能快速且彈性建立 Web 應用或服務。在 Web 應用方面, 加上 ZK 協助能使用先進的 Web 技術, 卻毋需太煩惱衍生的問題。而面對複雜的服務與模組, 有更強力的 Scala/Akka 組合以函數編程與靜態語言協助建立穩定的服務。
• 領域層: 有了上面分門別類的區塊提供各式的服務, 接下來在 grails 與 akka 下, 開發領域相關的東西。

整理如下圖:

歡迎指教與補充。 :)

參考連結:

• Activiti: http://www.activiti.org/
• Akka: http://akka.io/
• ApacheDS & Directory Studio: http://directory.apache.org/
• Camel: http://camel.apache.org/
• CMIS: http://en.wikipedia.org/wiki/Content_Management_Interoperability_Services
• Felix: http://felix.apache.org/site/index.html
• Grails: http://www.grails.org/
• Groovy: http://groovy.codehaus.org/
• log4j 搭配 syslog
• Jasig CAS: http://www.jasig.org/cas
• JBoss PicketBox: http://www.jboss.org/picketbox
• Karaf: http://karaf.apache.org/
• Nuxeo: http://www.nuxeo.com/en
• OFBiz 完全中文安裝教學
• Openfire: http://www.igniterealtime.org/projects/openfire/index.jsp
• Scala: http://www.scala-lang.org/
• ServiceMix: http://servicemix.apache.org/home.html
• Zenoss: http://www.zenoss.com/
• ZK: http://www.zkoss.org/

近未來 IT 程式開發

今年初(2009)看到 InfoQ 上匯集 2008 年度文章, 其中一篇 JRuby 開發者之一 Ola Bini 先生的相關文章 "Programming languages in future systems" , 將應用系統用到的語言類型分為三層, 印象很深刻 ... 因為幾乎花整個 2008 年的時間打造這樣的系統 ... 在讀到文章之前, 做起來不盡相同。在案子完成之際, 借用相似標題記錄一下這個過程。

大多數 IT 相關系統, 都是處理資料 ... 絕大部分的人都會同意這是領域(domain)主導, 不是技術主導。在一些廠商強力運作下, 開發人員近乎被催眠在執行一些固定工作 ... 選用主流技術(沒人喜歡意外), 然後踏上規劃, 分析, 設計, 實作, 測試, ... 的履帶。

在專案執行之前, 有 IT 主要廠商已下海幾年宣告失敗 ... 就不得不審視一些基本問題:

1. 這是一個財務資訊系統 (AIS, Accouting Information System) 主要得完成 "成本系統" ... 屬資料市集 (Data Mart) 規模, 資料變異不大但資料量大。


2. 使用者都全天候使用, 需求經常性改變 ... 使用角色的人數約開發者的 5 倍。


3. 之前系統是 dbase 系, 因為原廠不支持, 決定換 Java。要接手的 IT 部門沒人有經驗 ...

審視第一點 ... 之前也習慣用 ORM, 但時薪較我日薪還高的廠商都搞不定的資料量 ... 立馬決定透過 SQL 把資料處理的問題都丟給資料庫, 捨棄物件導向方式。

關於第二點 ... 全天候使用, 帶給系統更大的壓力。而需求改變, 更是許多系統不穩定的致命一擊。但揉合這兩個問題, 使用腳本(Scripting)語言達成快速變更, 測試就交給使用者(與開發人員關係良好) ... 原則上是這樣, 還有一些方式, 下段再述。

而最末一點 ... 要從頭學習 Java, 並好好發揮不是每個人都辦得到。但主要是匯入/匯出、維護/查找資料、檢核、計算、報表、傳票 ... 這幾件事，大致就是 SQL 加上個別功能就收工。後來都是 SQL 測試完成後, 再用樣板(template)套入功能 ... 大約可完成八、九成工作。

以技術拆解來看是: SQL + 腳本語言 + 功能模組樣板 ... 有人認為 Java 可達成, 的確也是。但 Java 的問題在於, 直接放 SQL 勢必會分段(SQL 都是長得誇張), 再加上變數會更亂; 而做成獨立檔案(iBatis 做法), 或 Stored Procedure 或 View, 造成非功能性分割, 竊認為是修改應用程式不易的禍首。

使用腳本語言就一個功能一個檔, 很直覺, 清清處處 ... 開發過程曾有 SQL 部份算式要改, 還是使用者(只會 SQL 查資料)直接指出哪邊要改。

專案開始(2007年中), 就決定使用Groovy, 即便用過 jython, 當時也較成熟; 而 jruby 如日中天 ... 但偏好 Groovy 補 Java 不足的角度, 特別是支援類似 python 三引號(triple-quotes)的樣板字串(template string), 可直接寫 SQL 再加上需要的變數、函式都很容易 ... 除了 Groovy 本身支援的 SQL, 後來也嵌入EBNF 的語法描述, 再來做 DSL 處理也很方便。

回頭看打造的系統與 Ola Bini 先生宣告三層類型的對應:

1. 穩定層(Stable layer): 沒與應用太多相關, 以靜態語言打造 ... Groovy 程式的載入、執行都是用 Java 寫的。


2. 動態層(Dynamic layer): 與應用相關, 以動態語言打造 ... 功能模組樣板(匯入/匯出, 檢核, 計算, ...), 都是用 Groovy 寫的 ... 像報表小計方式百百種, 都一一解決。


3. 領域層(Domain layer): 與應用相關, 以領域語言打造 ... 使用 SQL + Groovy 方式, 大抵 SQL 能動就了結。

其文中提到的 Drools 也有用到, 因為決策表格(Decision Table)對使用者更容易使用 ... 也在此做證言 :-)