上周硅谷非常熱鬧，重大消息頻繁出現，其中包括了喬布斯因病休假，蘋果的恐怖財報等等。對于我們所關心的移動業界跟互聯網來說，Google 換帥是另外一個重量級消息。

Quora 上有一個討論串，題目是“Larry Page 上任之后，Google 的重點應該是什么？”，討論相當活躍。我也在這里湊個熱鬧，談一談在我看來，Larry Page 應該如何去改變 Google。

1：關注核心業務，也就是搜索

Google 前段時間在搜索結果上算是飽受攻擊，由于與日俱增的垃圾內容，搜索結果的污染狀況越發嚴重。Stack Overflow 的創始人之一 Jeff Atwood 在一篇文章里這樣評價 Google 現在的搜索結果：

Google ，這個曾經的必備工具，某種程度上已經失去了它的優勢地位。垃圾內容制造者、以點擊率為終極目標的內容聚合站點正在走向勝利。

在 這一點上來說，ifanr 感同身受。作為內容提供者，我們是創造價值的人，是在給互聯網不斷添磚加瓦的一方。而之前在 Google 里搜索我們的原創文章，出現在結果最頂端的卻往往是是通過拷貝+粘貼、有時候還不注明出處進行轉載的內容聚合站點。它們用毫無成本的方式奪取著應該屬于原 作者的訪問量。

好在 Google 似乎已經認識到了這一點。之前搜索質量組的 Matt Cutts 表示他 們已經意識到了垃圾內容的增多，以及劣質內容聚合站點引發的不滿，并且會很快進行處理。從我今早的實驗來看，似乎 Google 已經采取了措施，最近 ifanr 的原創文章都出現在首頁頭條。從根子上（點擊量帶來的經濟利益）驅逐劣質內容聚合站點，對現代互聯網來說，確實是件好事

搜索，是 Google 的立身之本，從上周發布的財報來看，Google 收入的主要增長點仍然是在網站本身的業務。不斷改進搜索，添加新的搜索方式，才能保持和增強 Google 在這個領域的領導地位。后院不起火，才有在其他領域發展的資本。

這一條，是 Larry Page 上任以后最需要關注的。未來十年的搜索是什么樣子？如何提高內容關聯性，改進使用體驗？怎么樣通過創新，把 Bing 等競爭對手遠遠甩開，對 Google 來說，至關重要。

2：在社交網絡方面另辟蹊徑

Google 在社交網絡方面的試探，到目前為止都是悲劇，坦率地說，我個人認為Google 已經錯過了第一班社交網絡的列車。

作為新生事物的社交網絡，從一開始負載的是用戶虛擬交流的需求。

目 前的勝利者里面，Facebook 滿足了人們交流的愿望，利用網絡，表現了某種程度上真實的人與人關系，而大量互動元素的引入，則是模擬了現實生活的部分人際往來，從根底上來說，沒有理念 上的創新，然而它仍然足夠偉大，Facebook 把現實生活成功投影到了虛擬世界，是真正意義上的創造者。

另一個贏家是 Twitter，它滿足的，是人們表達自己的愿望。通過簡短的 140 個字，人與人之間形成了一種奇妙的交流關系，普通人也可以第一時間見證重大事件。可以說，Twitter 與智能手機的結合，創造了一種新媒體。表達自己，記錄周邊，關注別人，是 Twitter 類社交網絡的根本。無論是變種的 foursquare，還是 Quora，從理念上看，都是這樣的東西。

Google 之前的嘗試呢？ Wave 那個體驗一塌糊涂的東西不去說它，出生太早了；Buzz 則是無限制版本的 Twitter：Google 試圖利用現成的龐大用戶群，但沒有實質性創新，再加上拙劣的整合方式，這個產品的前景樂觀不到哪兒去。

社交網絡走到現在，實際上已經到了一個重要的關口，即：虛擬的內容如何與現實社會結合起來，怎樣把線上關系與實體經濟整合，創造出一個嶄新的商業模式。在我看來，這才是第二代社交網絡，也即成熟版本的社交網絡。這個方向是未來兩年的熱點，也是 Google 下一步可以突圍的角度。

Google 的最大優勢是什么？大家應該都非常清楚，其一是龐大的用戶群，其二就是信息了。Google 相對于 Twittter、fousquare 等來說，先天就有信息方面的優勢。而 Google 在建設社交網絡的時候，卻完全忽略了這個優勢，捆著手腳去從頭開始跟已經成熟的對手競爭，怎么可能勝利？

舉個最簡單的例子，Google Maps 信息豐富，我經常用它來尋找晚餐地點，最大的好處之一就是可以看到多個網站的用戶評價，看看截圖：

看 到了吧，有 Buzz 選項，然而搞笑的事來了。我可以看到其他網站的評價，可以在 Buzz 上分享這個地點，然后呢？沒了。我完全看不到 Buzz 關于這個餐館的討論，看不到我分享以后朋友的看法——一點也沒有。實體經濟方面的內容本身就是 Google 的長項，然而在它的任何產品里面，都沒有把這個長處跟自己的社交網絡更緊密得結合起來。

放著龐大的現實數據不用，幾個產品之間幾乎沒有交流，捧著金飯碗要飯，這就是 Google 的社交網絡。跟現實社會結合的社交網絡，將是 Google 在這一領域的最后一個機會。

3：細節，細節，還是細節

有一句老話，細節決定成敗，然而 Google 現在的很多做法，卻表現了一種對細節的漠視，極大影響了產品的使用體驗。還是要以 Android 為例（這玩意簡直就是反面教材）：

就從簡單的設置界面說起。Android 平鋪直敘的設置界面，完全沒有突出重點（我甚至懷疑這幫人安排順序的時候是不是拍腦門做出的決定。），跟右邊的 iOS 比，孰優孰劣，一目了然。

還有應用市場，每次談到 Android 的應用市場，我都有爆粗口的沖動。緩慢的速度、時常丟失的已下載應用列表、遲遲沒有解決的應用無法下載問題……這是整個產業的核心之一，Google 就準備這么糊弄下去？

Android 不講究的地方何止這些，工程師文化并不代表著可以不拘小節，Google 的目光，應該多放些在細節上。移動設備，用戶體驗至關重要。

4: 繼續擁抱云，下注新能源產業

在這個賣雜貨的、搞 B2C 的、做軟件的都在搞云應用平臺的當口，互聯網界巨頭，擁抱云的先驅之一，可能擁有著世界上最好硬件以及網絡設施的 Google，當然也擁有自家的 App Engine。

云 計算平臺對于中小企業、個人的意義，無論如何贊揚也不會過分，它直接引領了當前的互聯網創業潮。低廉的平臺成本，按需付費的方式，Amazon EC2 吸引了大量的個人開發者，Google 的 App Engine 當然不錯，但我要說，還是不夠靈活，如果能提供更多語言支持，就再好不過了。

新能源很好理解，隨著碳交易市場的興起，碳排放量眼看就要變成金融市場上的一個新產品。在這個趨勢影響下，每個企業都應該考慮下自己的能源來源，為將來更加嚴格的排放調控措施做好準備，規避可能的經濟風險。

降低所消耗能源的碳排放，對于 Google 這種能源消耗大戶來說，是經濟跟政治上都很正確的方向，而且同樣有大量的利益存在。新能源產業，應該成為 Google 下一步的重點投入方向。

5：提高決策速度與質量，減少內部溝通環節

大 家都知道 Google 著名的 20% 規則：員工可以把 20% 的上班時間放在其他項目上。Google 的員工無疑是優秀的，這些業余時間做出的項目也應該有很多不錯的點子，然而，從中孵化的成果卻并不多。其中的部分原因，恐怕與 Google 的內部引導以及溝通機制存在很大的關系。由于缺乏引導，員工的項目往往與 Google 本身沒什么聯系，而因為溝通問題，好的項目不一定能夠獲得公司的幫助。

Google 的前員工遍布整個互聯網業界，大量創新卻往往出現在他們離開 Google 以后。應該如何去引發員工的創造力、提高內部效率跟執行力度，Larry Page 需要仔細考慮，以便調整內部架構來適應這個變化迅速的世界。三星這個反應快到根本不像大公司的大公司在全世界攻城掠地，諾基亞反應稍微遲緩一點就束手束 腳，Google，你要快一點，再快一點，才能跟 Facebook 以及數以千計的創業企業進行競爭。

轉自：http://www.oschina.net/news/14996/larry-page-google-five-things-todo

沒有人能說清哪種緩存算法優于其他的緩存算法。（以下的幾種緩存算法，有的我也理解不好，如果感興趣，你可以Google一下）

Least Frequently Used（LFU）：

大家好，我是 LFU，我會計算為每個緩存對象計算他們被使用的頻率。我會把最不常用的緩存對象踢走。

Least Recently User（LRU）：

我是LRU緩存算法，我把最近最少使用的緩存對象給踢走。

我總是需要去了解在什么時候，用了哪個緩存對象。如果有人想要了解我為什么總能把最近最少使用的對象踢掉，是非常困難的。

瀏覽器就是使用了我（LRU）作為緩存算法。新的對象會被放在緩存的頂部，當緩存達到了容量極限，我會把底部的對象踢走，而技巧就是：我會把最新被訪問的緩存對象，放到緩存池的頂部。

所以，經常被讀取的緩存對象就會一直呆在緩存池中。有兩種方法可以實現我，array 或者是 linked list。

我的速度很快，我也可以被數據訪問模式適配。我有一個大家庭，他們都可以完善我，甚至做的比我更好（我確實有時會嫉妒，但是沒關系）。我家庭的一些成員包括LRU2 和 2Q，他們就是為了完善 LRU 而存在的。

Least Recently Used 2（LRU2）：

我是 Least Recently Used 2，有人叫我最近最少使用twice，我更喜歡這個叫法。我會把被兩次訪問過的對象放入緩存池，當緩存池滿了之后，我會把有兩次最少使用的緩存對象踢走。 因為需要跟蹤對象2次，訪問負載就會隨著緩存池的增加而增加。如果把我用在大容量的緩存池中，就會有問題。另外，我還需要跟蹤那么不在緩存的對象，因為他 們還沒有被第二次讀取。我比LRU好，而且是 adoptive to access 模式 。

Two Queues（2Q）：

我是 Two Queues；我把被訪問的數據放到LRU的緩存中，如果這個對象再一次被訪問，我就把他轉移到第二個、更大的LRU緩存。

我踢走緩存對象是為了保持第一個緩存池是第二個緩存池的1/3。當緩存的訪問負載是固定的時候，把 LRU 換成 LRU2，就比增加緩存的容量更好。這種機制使得我比 LRU2 更好，我也是 LRU 家族中的一員，而且是 adoptive to access 模式 。

Adaptive Replacement Cache（ARC）：

我是 ARC，有人說我是介于 LRU 和 LFU 之間，為了提高效果，我是由2個 LRU 組成，第一個，也就是 L1，包含的條目是最近只被使用過一次的，而第二個 LRU，也就是 L2，包含的是最近被使用過兩次的條目。因此， L1 放的是新的對象，而 L2 放的是常用的對象。所以，別人才會認為我是介于 LRU 和 LFU 之間的，不過沒關系，我不介意。

我被認為是性能最好的緩存算法之一，能夠自調，并且是低負載的。我也保存著歷史對象，這樣，我就可以記住那些被移除的對象，同時，也讓我可以看到被移除的對象是否可以留下，取而代之的是踢走別的對象。我的記憶力很差，但是我很快，適用性也強。

Most Recently Used（MRU）：

我是 MRU，和 LRU 是對應的。我會移除最近最多被使用的對象，你一定會問我為什么。好吧，讓我告訴你，當一次訪問過來的時候，有些事情是無法預測的，并且在緩存系統中找出最少最近使用的對象是一項時間復雜度非常高的運算，這就是為什么我是最好的選擇。

我是數據庫內存緩存中是多么的常見！每當一次緩存記錄的使用，我會把它放到棧的頂端。當棧滿了的時候，你猜怎么著？我會把棧頂的對象給換成新進來的對象！

First in First out（FIFO）：

我是先進先出，我是一個低負載的算法，并且對緩存對象的管理要求不高。我通過一個隊列去跟蹤所有的緩存對象，最近最常用的緩存對象放在后面，而更早的緩存對象放在前面，當緩存容量滿時，排在前面的緩存對象會被踢走，然后把新的緩存對象加進去。我很快，但是我并不適用。

Second Chance：

大家好，我是 second chance，我是通過FIFO修改而來的，被大家叫做 second chance 緩存算法，我比 FIFO 好的地方是我改善了 FIFO 的成本。我是 FIFO 一樣也是在觀察隊列的前端，但是很FIFO的立刻踢出不同，我會檢查即將要被踢出的對象有沒有之前被使用過的標志（1一個bit表示），沒有沒有被使用 過，我就把他踢出；否則，我會把這個標志位清除，然后把這個緩存對象當做新增緩存對象加入隊列。你可以想象就這就像一個環隊列。當我再一次在隊頭碰到這個 對象時，由于他已經沒有這個標志位了，所以我立刻就把他踢開了。我在速度上比FIFO快。

CLock

我是Clock，一個更好的FIFO，也比 second chance更好。因為我不會像second chance那樣把有標志的緩存對象放到隊列的尾部，但是也可以達到second chance的效果。

我持有一個裝有緩存對象的環形列表，頭指針指向列表中最老的緩存對象。當緩存miss發生并且沒有新的緩存空間時，我會問問指針指向的緩存對象的標 志位去決定我應該怎么做。如果標志是0，我會直接用新的緩存對象替代這個緩存對象；如果標志位是1，我會把頭指針遞增，然后重復這個過程，知道新的緩存對 象能夠被放入。我比second chance更快。

Simple time-based：

我是 simple time-based 緩存算法，我通過絕對的時間周期去失效那些緩存對象。對于新增的對象，我會保存特定的時間。我很快，但是我并不適用。

Extended time-based expiration：

我是 extended time-based expiration 緩存算法，我是通過相對時間去失效緩存對象的；對于新增的緩存對象，我會保存特定的時間，比如是每5分鐘，每天的12點。

Sliding time-based expiration：

我是 sliding time-based expiration，與前面不同的是，被我管理的緩存對象的生命起點是在這個緩存的最后被訪問時間算起的。我很快，但是我也不太適用。

好了！聽了那么多緩存算法的自我介紹，其他的緩存算法還考慮到了下面幾點：

• 成本。如果緩存對象有不同的成本，應該把那些難以獲得的對象保存下來。
• 容量。如果緩存對象有不同的大小，應該把那些大的緩存對象清除，這樣就可以讓更多的小緩存對象進來了。
• 時間。一些緩存還保存著緩存的過期時間。電腦會失效他們，因為他們已經過期了。

根據緩存對象的大小而不管其他的緩存算法可能是有必要的。

原文：http://www.zavakid.com/27

提交 B3log Solo（運行在 GAE/J 上的博客程序） 代碼后發現 Google Code 版本控制系統會將提交日志同步發布到 Google Buzz 中：

但在 Buzz connected sites 里并沒有看到與 Google Code 關聯：

現在一提交代碼就 Buzz，還是比較無奈的....

有時我們需要隨機地獲取數據記錄（實體），比如博客程序中的“隨機文章”的實現。

目前 GAE 并沒有 API 可以直接獲取隨機實體，要實現這樣的需求我們只能自己想辦法了 :-)

在 stackoverflow 上也有人提過該問題，總結如下：

• Generate and store a random number on your entities as you create them, then pick a random number and look (via a query) for the closet record(s) to it.
• Implement some mechanism to ensure your entity ids are "densely" populated, then fetch within the known range using keys.
• Periodically generate random lists of the entities and return entities from those lists. This may take the form of a stack that entities are popped off of, or as actual lists that are returned.

目前 B3log Solo 在處理“隨機閱讀”上采用的是方法一，即在每個文章實體上添加一個屬性保存 0-1 的隨機浮點數。

在獲取隨機文章時生成一個 0-1 的隨機數（mid）作為查詢條件，以此查詢條件作為邊界（0 <= mid <=1）來過濾實體保存的隨機值屬性。

這個方法基本可以達到隨機的效果了，為了讓隨機的效果更動態一點，我們可以考慮經常更新文章實體中的隨機浮點值：

• 訪問文章時（即在更新文章瀏覽次數時一并更新該文章的隨機浮點值）
• 后臺定時任務（獲取一定數量的隨機文章然后更新它們的隨機浮點值）
• 用戶做文章更新時

加上以上處理后，隨機的效果比較好了 :-)

作者 榮浩 發布于 2010年12月28日 上午12時0分

對jBPM來說，今年最大的事件莫過于jBPM的創建者Tom Baeyens離開JBoss了。Tom Baeyens離開的具體原因尚不清楚，但他的離開產生了兩個結果：一是jBPM的下一個版本jBPM5完全放棄了jBPM4的基礎代碼，基于Drools Flow重頭來過；二是Tom Baeyens加入Alfresco后很快推出了新的基于jBPM4的開源工作流系統Activiti。 由此不難推測Tom Baeyens離開的部分原因：JBoss內部對jBPM未來版本的架構實現產生了嚴重的意見分歧。更加巧合的是12月1日Activiti5剛發布，緊 接著12月2日jBPM5就發布了第一個候選發布版本，jBPM與Activiti之間的微妙關系可見一般。

在這篇文章里，我們將一起回顧jBPM從jBPM3到jBPM5以及Activiti5的發展歷程，我們可以清晰的看見jBPM（包括 Activiti）設計所遵循的一致原則：強調流程服務的可嵌入性和可擴展性。同時，從各個版本之間的變化我們也能看見產品設計思路的變化：更加強調面向 業務人員，增加BPMS（業務流程管理系統）特性。

在回顧之前，我們首先討論一下BPMS應該嵌入還是獨立部署的問題，因為不管是jBPM還是Activiti，都強調了流程服務的可嵌入性。此外，我們還需要討論一下什么是BPMS的特性，它們所解決的問題是什么。

一、嵌入式還是獨立部署？

不管是jBPM還是Activiti，都強調了流程服務的可嵌入性。Tom Baeyens在其個人博客里稱作為獨立部署的BPMS已死，原因有兩個：一是獨立部署的BPMS需要很高的安裝使用成本，需要獨立部署、需要用戶支出大 量的培訓成本和維護成本；二是獨立部署的BPMS與外部系統的交互方式是分布式，這使得很多問題變得復雜，例如分布式事務。Tom Baeyens代表了相當一部分人特別是開發人員的觀點。

Tom Baeyens沒有完全理解BPMS。什么是BPMS？BPMS最重要的目標就是需要打破各個應用系統（CRM、ECM、ERP、SCM）之間的界線，將 分散在這些系統中的流程集中管理，這是BPMS的實質。一如流程再造，打破各個部門之間的壁壘，減少浪費，建立流程驅動性的組織。如下圖1所示：

圖 1：BPMS打破應用系統之間的界線

BPMS所要解決的問題要求其必然是獨立部署的。Tom Baeyens錯誤的根本原因在于其將BPMS與工作流系統的定義混為了一談，他如此定義BPMS：BPMS旨在簡化對組織核心流程進行支撐的軟件創建。 也就是BPMS面向的是軟件開發人員，旨在簡化他們的開發，降低他們使用流程的門檻。而這正是工作流系統需要解決的問題。

BPMS面向企業用戶，工作流面向開發社區和系統集成商。

二、BPMS特性

jBPM4、jBPM5和Activiti5都增加了其BPMS特性，那些特性能夠稱為BPMS特性呢？我們先看一看BPMS需要解決的問題，為解決這些問題所增加的特性就是BPMS特性。

1. 如何設計流程，在組織中高效地對設計出的流程進行溝通，取得共識？

   • 提供跨越組織的流程標準標記符號與術語（BPMN已經成為標準）
   • 流程及相關文檔的可視化（流程/內容存儲倉庫）
   • 提供在組織結構內進行不同層次之間的流程導航（流程存儲倉庫支持組織模型）
   • 流程定義在各個層次/部門間的一致性，避免業務人員的流程建模轉換到IT系統時受到損耗（流程引擎支持基于圖的建模，支持擴展）

2. 如何更好地執行流程？

   • 業務活動的實時監控，預警與控制（BAM）
   • 流程執行的仿真
   • 流程執行的統計分析與反饋（報表）
3. 如何更好地管理流程？
   • 打破各個應用系統之間的界線，統一管理所有流程（EAI，與ESB的集成）
   • 對業務人員友好的建模工具
4. 如何在執行流程過程中遵循業內最佳實踐和規則？
   • 面向流程的知識管理
   • 規則引擎

三、完整的工作流實現jBPM3

jBPM3的最新版本是3.2.7，其包括了以下組件：基于Eclipse的流程設計器、用于監控案例（流程實例）和處理任務的Web控制臺以及jPDL核心庫。如下圖2所示：

圖 2：jBPM3組件

1. 基于Eclipse的流程設計器

   提供給開發人員繪制jPDL流程圖，因為該設計器基于Eclipse，所以生成的流程文件可以與開發代碼一起組織管理，非常容易進行單元測試。實現了工作流管理系統參考模型里的接口1。

2. Web管理控制臺

   主要有兩個功能：一是作為工作流客戶端應用接口，給用戶提供一種手段，以處理案例運行過程中需要人工處理的任務；二是對案例的狀態進行監控與管理。實現了工作流管理系統參考模型里的接口2和5。

3. jPDL核心庫

   jPDL核心庫是一個單獨的JAR包，可以嵌入到目標應用中執行，它包括了：

   • 流程倉庫：解析jPDL流程定義文件并存儲讀取；
   • 流程引擎：對流程定義進行初始化和調度執行，節點的運行期行為與jPDL里定義的節點類型一一綁定；
   • 任務管理：生成任務節點所對應的工作項，管理工作項的生命周期（初始化、分配執行者、執行、掛起、結束、終止）；
   • 事件管理：發布案例和任務的開始、結束事件，通過監聽者模式調用相應的事件處理器；
   • 異步執行機制：通過線程實現了Job Executor，進行異步工作的處理，這些工作包括了時間處理、異步動作。
   • 身份組件模型：實現了一套簡單的身份組件模型，包括了組、用戶和權限。

   通過調用自定義Java代碼實現了對外部應用的調用，從而實現工作流管理系統參考模型里的接口3。

jBPM3是一個輕量級的嵌入式工作流系統。它在Java社區的成功得益于兩個方面：一是嵌入式，這降低了使用工作流的門檻；二是對開發人 員友好，這表現在易讀的jPDL、流程的可測試性(Eclipse插件)以及節點行為的可擴展性，我們可以非常容易的在流程運行中加入自己定制的行為（通 過事件處理器和Action）。jBPM3面向開發人員，它解決的問題是流程的自動化，它的影響力集中在Java開發社區，是一個完整的工作流系統實現。

四、向BPMS努力的jBPM4

與jBPM3相比，jBPM4最大的變化是引入了流程虛擬機（PVM），同時增加了BPMS的特性。jBPM4不再滿足于工作流系統的定位，開始向BPMS努力。

1. 為什么引入流程虛擬機

   盡管jBPM3在Java社區取得了很大的成功，但是有一件事始終被人們詬病，那就是它不支持流程語言規范，從最開始的XPDL、BPEL 到后來的BPMN，它采用了自定義的jPDL。在jBPM3中，節點的運行期行為與jPDL里定義的節點類型是一一綁定的，這造成了流程引擎與特定流程語 言的綁定，要支持其他的流程語言變得困難。于是在jBPM4中，jBPM提出了流程虛擬機的概念，即流程引擎與流程語言解耦，通過一套通用的流程模型并配 以可定制的節點運行期行為實現了對多流程語言的支持。

   流程虛擬機帶來的好處是多方面的：第一也是最重要的是jBPM4支持了BPMN。

   第二是實現了基于流程組件的流程引擎，流程圖(語言)與實現解耦，我們使用通用編程語言實現節點運行期行為，稱之為流程組件，通過將流程圖 與流程組件掛接，避免了圖的損耗。在這一點上，Tom Baeyens對BPMN到BPEL的轉換提出了一針見血的批評：BPMN和jPDL以及XPDL都是基于圖的，而BPEL是基于塊的，這造成了當將業務 人員使用BPMN所建立的流程模型向BPEL執行模型進行轉換時，出現許多的不匹配，最初的流程模型會扭曲變形。而扭曲的后果就是業務人員與開發人員之間 的協作困難，這影響了流程從業務到技術的實現。

   第三個好處是我們可以定義領域特定語言（DSL），在特定的應用里，采用DSL約定并隱藏了大部分的技術細節可能做到業務人員對執行流程的直接修改，例如企業文檔管理里的審批流程。

2. BPMS特性的加入

   這表現在以下三個方面：第一是支持了BPMN，BPMN已經成為業務人員的流程建模標準；第二是引入了Signavio作為面向業務人員的Web建模器；第三是在已有的Web管理控制臺加入了對案例和任務的統計功能。jBPM4的組件如下圖3所示：

   

   圖3：jBPM4組件

   和jBPM3一樣，jBPM4依然是輕量級的、可嵌入的工作流系統。相比jBPM3，它將業務人員作為最終用戶之一，增加了部分BPMS特性，同時PVM的引入使得它的可擴展性得到了極大的增強，我們甚至可以定義自己的DSL。

   在BPMS特性里我們提到了應該避免業務人員的流程建模轉換到IT系統時受到損耗，最理想的情況是業務人員與開發人員共用一個流程模型，業 務人員能夠直接對流程進行調整（在特定應用中，通過DSL是可以做到的）；其次是通過BPMS將業務人員的模型與實際執行的技術模型關聯起來（很多商業產 品已經做到了這一點，在Activiti5中我們也會看到這一點），業務人員、開發人員以及運營團隊之間能夠做到很好的協調；最差是業務人員與開發人員各 自為政，獨立維護各自的流程模型，并且模型之間存在極大的不匹配，此時流程的迅速變化基本上是奢望。

五、鳩占鵲巢的Drools Flow與jBPM5

目前jBPM5剛剛發布了第一個候選發布版本，jBPM5基本上完全拋棄了jBPM4的代碼，所有代碼全部來自原先的Drools Flow。Drools Flow最初被用來解決規則執行順序的問題。其實從Drools Flow開始支持BPMN時起，我們已經預感到它與jBPM的競爭關系。

jBPM5依舊定位為輕量級的可嵌入的工作流系統。在jBPM5的特性里，有這么兩條引人關注：一是引入了Guvnor作為流程倉庫，這解決了流程 的可視化問題，流程定義作為資源被管理，我們可以對流程定義進行可視化管理以及全文檢索（Guvnor使用了Jackrabbit作為了其存儲實現，但我 們的經驗表明Jackrabbit在大數據量情況下性能存在嚴重問題）；第二是規則引擎(Drools Expert)、事件處理引擎(Drools Fusion)與流程引擎的合三為一，這是jBPM5最讓人期待的地方。jBPM5的組件如下圖4所示：

圖 4：jBPM5組件

規則引擎在流程中的應用已經非常廣泛了，我們這里說說事件處理引擎。

事件處理引擎是業務活動監控（BAM）的基礎，BAM的功能及執行過程，如下：

• 捕獲：BAM捕獲各種事件（通過消息監聽器、適配器、代理等）。這些事件來自應用、系統軟件、外部交易伙伴。消息是BAM的核心——它們反應底層業務流程的狀況。
• 過濾：BAM過濾掉沒有直接后果的事件，在很多情況下由支持事件流處理（Event Stream Processing，簡稱ESP）或復雜事件處理（Complex Event Processing，簡稱CEP）引擎來進行過濾。
• 分析：BAM根據分析模型和規則將相關事件聯系起來。
• 警告：BAM向用戶提出警告，以便用戶在必要時進行控制。

如上所示，BAM的執行過程包含四個步驟，而前三個步驟都是對事件進行相關的處理（捕獲事件、過濾事件、分析事件、關聯事件），因此在大多數BAM的技術實現方案中，都基于CEP和ESP的引擎來實現BAM的功能。

與jBPM4相比，jBPM5對PVM的放棄也帶來了幾個不小的問題：第一是對開發人員來說只支持BPMN，不再支持jPDL（當然提供了遷移工 具）；第二是流程執行的可擴展性回到了jBPM3的年代，僅僅支持自定義動作（相當于jBPM3里的Action）。此外，Web建模器由 Signavio替換為了Oryx Designer。

總而言之，jBPM5通過引入流程倉庫和BAM繼續向BPMS邁進（目前的進展是與流程倉庫的集成還未完成，BAM基于日志進行分析），同時，由于不再支持PVM和jPDL，帶來了流程擴展性的降低和社區開發人員的未來流失。

六、Activiti5的反擊

Activiti5是Tom Baeyens加入Alfresco后推出的新的基于jBPM4的開源工作流系統，1號剛剛發布第一個版本。Activiti的開發團隊相比與jBPM強 大了許多，有23位核心開發者。當然這也是由于activiti規劃的功能所致：包括核心引擎、Web的流程建模器、協作工具Activiti Cycle、Activiti Probe、Activiti Explorer、與Spring的集成、與Mule的集成等。

圖 5：Activiti5的組件

如上圖所示，Activiti5由三種類型的組件組成，分別是：專用工具（Dedicated Tools）、內容存儲工具（Stored Content）和協作工具（Collaboration Tool）。

專用工具包括以下：

• Alfresco—Alfresco公司的企業級內容管理產品

Alfresco 是一個開源的、企業級的內容管理系統，功能包括：文檔管理、協作、記錄管理、知識庫管理、Web內容管理等功能。Alfresco與Activiti的深 入集成實現了流程及相關文檔的可視化。更重要的是Alfresco支持組織模型，能夠提供在組織結構內進行不同層次之間的流程導航。

• Activiti Modeler—建模器

基于開源Signavio Web流程編輯器的一個定制版本，提供了對BPMN2.0圖形化規范的支持，建模后的流程以文件格式進行存儲。

• Activiti Designer—Eclipse插件形式的建模器
• Activiti probe—管理及監控組件

對流程引擎運行期實例提供管理及監控的Web控制臺。包含部署的管理、流程定義的管理、數據庫表的檢視、日志查看、事務的平均執行時間、失敗多次的工作等功能。

• Activiti Explorer—任務管理組件

提供任務管理功能和對案例、任務基于歷史數據的統計分析（報表）功能。Web應用程序。

內容存儲工具：包括了文檔倉庫、模型倉庫、SVN倉庫、MVN倉庫和Activiti引擎。其中文檔倉庫、SVN倉庫和MVN倉庫三個組件為協作工具（Activiti Cycle）提供底層的支撐。Activiti引擎則是以前的PVM。

協作工具：與jBPM4相比，Activiti5最令人矚目的特性就在于它的協作工具組件。

Activiti Cycle完全是一種新類型的BPM組件。它是一個用來促進業務人員、開發人員和IT運營人員協作的Web應用程序。 在現實的場景中，業務文檔有業務人員所持有，而軟件程序由開發團隊所管理，被部署的軟件應用則被IT管理人員所管理。三者之間不能很好的協作。我們可以想 象這樣一個場景，業務經理用文檔來維護需求和visio格式的流程圖，開發人員管理可執行的流程和大量的Java源文件而IT維護人員則管理部署在 Tomcat中的.war文件和存儲在Activiti數據庫中的流程。

圖 6：Activiti cycle協作組件邏輯示意圖

Activiti Cycle通過BusinessLink將與流程相關的業務人員、開發團隊與IT維護人員關聯起來，實現他們之間的協作。

總而言之，與jBPM4相比，Activiti5目前最重要的增強就是實現了流程的可視化以及創新的Activiti Cycle協作組件，此外，通過與Mule的集成加強了其集成能力。其對PVM的保留使其繼承了jBPM4強大的可擴展能力，對jBPM的老用戶來說，這是向其遷移的重要理由。

七、總結

jBPM3是一個完整的工作流系統實現，面向開發人員，目的在于簡化對組織核心流程進行支撐的軟件創建，不支持標準。

jBPM4引入PVM，使其擁有更強大的擴展性，同時增加BPMS特性，這些特性包括了對BPMN的支持、面向業務人員的Web建模器和簡單統計分析功能的加入。

jBPM5基于原先的Drools Flow，支持BPMN，通過與Drools的合并支持BAM，通過內容倉庫增加對流程可視化的支持。由于放棄了jBPM4的PVM，引擎的可擴展性受到損害，并且不再支持jPDL。

Activiti5基于jBPM4，與Alfresco的集成增加了其流程可視化與管理能力，同時通過創新的Activiti Cycle協作組件支持流程相關人員之間的協調，最后，它加強了集成能力。

對于工作流應用或者jBPM3、jBPM4的老用戶，建議轉向Activiti5。

關于作者

榮浩，ThoughtWorks咨詢師，關注敏捷和企業流程改進過程，目前正與辛鵬合著《Head First Process-深入淺出IT流程》一書。博客地址http://ronghao.javaeye.com。

轉自：http://www.infoq.com/cn/articles/rh-jbpm5-activiti5

有很多理由都能說明為什么我們應該寫出清晰、可讀性好的程序。最重要的一點，程序你只寫一次，但以后會無數次的閱讀。當你第二天回頭來看你的代碼 時，你就要開始閱讀它了。當你把代碼拿給其他人看時，他必須閱讀你的代碼。因此，在編寫時多花一點時間，你會在閱讀它時節省大量的時間。

讓我們看一些基本的編程技巧：

1. 盡量保持方法簡短
2. 永遠永遠不要把同一個變量用于多個不同的目的
3. 使用自描述的變量名和方法名
4. 盡可能的把變量定義在靠近使用它的地方
5. 拒絕神秘數字
6. 友好的對待你的語言
7. 不要逆常規而行
8. 警惕過早優化
9. 積極重構測試過的程序
10. 不要過度沉迷于技巧
11. 通過習例學習新知

現在，讓我們把每個小點展開來詳細講一下。

1. 盡量保持方法簡短

盡管很多人都遵循這個規則，但它仍然非常的重要。你寫的方法要始終能在一個屏幕里放得下。如果你需要去滾動屏幕，這會分散你的注意力，而且你看不到 整個的上下文。最佳長度是5-20行，這根據你的情況而定。當然，getters/setters 通常是一行代碼的方法，但與其說它們是真正的方法，不如說它們只是存取工具。

2. 永遠永遠不要把同一個變量用于多個不同的目的

一個變量應該始終只為一個目的服務。通過使變量常量化(C++里的const， Java里的final)，使得編譯器能夠優化編譯，而且使你的代碼醒目表達這個變量是不能改變的，你的程序的可讀性會變得更好。

3. 使用自描述的變量名和方法名

你的代碼應該，對于任何人來說，只要看一眼就能知道是干嘛的。盡量不要用簡寫方式，除非有特殊的習慣，就像下面的：

 src - source
 pos - position
 prev - previous

如果你認為描述性的名稱并不是那么有價值，請對比一下n, ns, nsisd 和 numTeamMembers, seatCount, numSeatsInStadium。

4. 盡可能的把變量定義在靠近使用它的地方

蓋房子時，你可不希望把錘子放到別人的院子里。你希望把它們放的離手頭越近越好。定義變量也是同樣的道理。

int foo = 3;
int bar = 5;
// 一大段使用“bar”的代碼，
// 但沒用到“foo”
// ...

baz(foo);

這段代碼可以簡單的重構成

int bar = 5;
// 一大段使用“bar”的代碼，
// 但沒用到“foo”
// ...

int foo = 3;
baz(foo);

當你把變量的聲明和第一次用到它的地方間隔太遠時(距離超過一個屏幕)，這確實會成為一個問題。記住上下文關系會變得困難，你需要滾動屏幕去找哪來的這個變量。

5. 拒絕神秘數字

當你要把什么東西跟一個常量值做比較時，記得把這個值定義成常量。沒有什么會比去猜測你的同事寫的這樣的代碼更讓人頭疼的事了：

il < 4384

換個形式感覺如何？

inputLength < MAX_INPUT_LENGTH

6. 友好的對待你的語言

學習新語言是一種很有樂趣的事情，你能學到一種新的完成任務的途徑。當一個對一種語言已經很專業的人去學習另一種語言時，會出現一種很大的負面效應。比如說你是一個Java開發者，試圖去學習Ruby。你應該學會用Ruby的方式解決問題，而不是沿用Java的解決問題的思想。

當你需要重復5遍”Hello world！“時，在Java里，你可能會這樣做：

for (int i = 0; i < 5; i++) {
    System.out.println("Hello world!");
}

在Ruby里，你也許會禁不住這樣寫：

for i in (0..5)
  puts "Hello world!"
end

這樣看起來沒問題，但有一個更好的方式：

5.times { puts "Hello world!" }

7. 不要逆常規而行

每種語言都有自己不同的習俗約定。一般來說，人們聽的最多的是Java的編碼規范。讓我們看看其中的一些習俗規范：

• 方法名應該小寫字母開頭，其后用字母大寫的單詞連接(veryLongVariableName)
• 類名應該都使用首字母大寫的單詞連接而成
• 常量名應該全部大寫，用下劃線連接(MY_CONSTANT)
• 左大括號應該跟 if 語句在同一行

只有在有必要的理由時才去打破這些常規，不要輕易的因為你不高興就違反它。如果你只是在團隊里改變一些這樣的習慣，那也沒問題，但當把你代碼拿出來和其他的沒有這些思想準備的程序員共享時，問題就會來了。

8. 警惕過早優化

過早優化是所有問題的根源，至少電視上是這么說的 … 你第一應該關心的事情是寫出易于理解的代碼。起初寫的程序不要求快。除非你的程序很慢，否則談優化都是為時太早。如果你想優化什么東西，你首先需要知道問題出在哪。這就是我們需要profilers這個工具的原因。

在沒有知道問題在哪的情況下試圖對程序進行優化，其結果必然是把程序能壞，至少你的代碼會喪失可讀性。如果你覺得有些地方很慢，不要盲目的重寫代碼，你應先找到慢的證據。

不要傻乎乎的去解決根本不存在的問題。

9. 積極重構測試過的程序

沒有任何東西會是完美的。即使你感覺你真正寫出了一段完美的代碼，幾個月后回頭再看看，你可能會驚訝道”怎么會這樣傻？“

改進程序的一個好方法就是重構，但要等程序測試通過之后。你首先要確保程序是好的可運行的，你可以通過自動化測試或手工測試完成這個工作。

之初，你需要的是程序可用。不要期望在第一次就寫出完美的程序，你只需要把它寫出來，可用。然后重構它，使之完美。對于你們當中知道測試驅動開發 (TDD)的人來說，對這個會很熟悉。這里的關鍵就在于你要習慣于重構這種事情。如果你使用的是像IntelliJ IDEA這樣強大的集成開發工具的話，重構的工作會變得簡單的多。

重構之后，你也許會弄出一些Bug，導致某些功能出問題。這就是為什么說寫自動化測試的原因。不論何時重構后，只要運行一下所有的測試用例，你就能準確的知道什么地方出了問題。

10. 不要過度沉迷于技巧

當我第一次讀到有關設計模式的知識時，我覺得我找到了圣杯。這些精心設計的思想作用顯著，它能使你的設計易于理解，因為你可以簡單的說”我使用的是 ‘觀察器模式’“，而不用從頭到尾的解釋一遍。那么，有問題嗎？一切看起來都這么自然、簡單，你開始不論在哪都使用設計模式。為什么不把這個類做成 singleton呢？干嘛不去再創建一些工廠類呢？

于是一個80行就能寫完的腳本，你最終使用了10個類，15個接口，外加一大堆范式和標記符。97%的代碼不做任何事情。設計模式是一種十分有用的用來簡化你的設計的工具，但這不意味著你該在所有能用到的地方都用它。你應該用它們，但不能濫用。

11. 通過習例學習新知

編程是一種學習新知的過程。當你學到了新的程序庫或新語言，你可能會迫不及待的丟掉舊的代碼，用你新學到的東西重新寫一遍。有很多的理由都能說明你不該這么做。

往現有的應用里增加新的類庫或框架同屬于這種情況。就說你寫了一個Javascript的web應用，期間，你發現了jQuery。現在你突然急切的想丟到你的Javascript程序，重新用jQuery寫，盡管你還從來沒用過它。

最好的方式是你先用jQuery寫一些簡單的例子，通過這種方式把你在應用里將要用到的知識都學會。需要AJAX？在你的項目之外做一些小例子，當完全弄懂了后，丟掉例子，應用到你的產品里。

如果你非常關注編程技術，我強烈的推薦你閱讀Steve McConnell寫的 《代碼大全》 一書。它會永遠的改變你對編程的認識。:)

[英文出處]：11 tips for better code

[譯文來源]：外刊IT評論