愛德華日誌

OSGi 起源於1999 年三月，是由一些家用閘道器相關產業廠商所組合而成的組織，目前約有八十餘家廠商加入。包括了 IBM、Sun、BMW、Motorola、Nortel、Nokia、 Philips、Panasonic、Sony、Toshiba、Echelon 等。目前最新的標準是OSGi Specification 3.0。

當初制定OSGi 標準的最主要的目的，是要為遠端的服務提供者 (Service Provider) 與本地端的設備 (Device) 之間提供完整的點對點服務傳送解決方案。因此，OSGi 定義了一個開放性的平台，使得遠端軟體服務供應商所提供的應用程式 及加值服務，能視使用者需求，隨時下載至靠近用戶的閘道器 (Gateway) 上，並且自動安裝執行，而這裡所指的閘道器通常是連接家庭網路(Home Network)、辦公室網路 (Office Network) 與廣域網路間的一個裝置，如機上盒 (Set-top Box;STB)、ADSL數據機、纜線數據機 (Cable Modem)、住宅區閘道器 (Residential Gateway)等。透過這個開放性的平台，不同廠商所開發出的服務軟體及設備都能互相溝通及搭配使用。

在 OSGi 網站上的 FAQ 中，指出 OSGi 應用方向包括：

• Services in the Home:
• • Communication
  • Information/entertainment
  • Safety and security monitoring
  • Energy management and metering
  • Appliance diagnostics and servicing
  • Telemedicine and healthcare monitoring
• Services in the Car:
• • Navigation
  • Emergency assistance
  • Mobile commerce
  • Information/entertainment
  • Vehicle diagnostics
  • Location-based services

Again, we see java succeeded in J2ME. We can see many big-name companies in the OSGi member name list which include many companies come from many industries.

最近 OSGi 在軟體業最為人雀躍的發展，莫過於 Eclpise Java IDE 支援 OSGi 標準。這是一個有趣的現象，本來是設計給其他產業的運用，卻在軟體業也有不凡的表現。這也讓我想起 Java 的發展歷史，本來也是為了 embedded 系統而設計，卻意外的在 internet 竄起的年代獲得各方的矚目，更在 enterprise application 中立於不敗之地...

JMX 與 OSGi 在功能上的許多重疊之處，在國外已經有人討論過 (例如 Eclipse Embeds OSGi Based MicroKernel 及 JMX vs. OSGi - The New Flavor of the Eclipse Runtime)。不過我認為重點是：

1. JMX 本來設計的用途就只為了管理，我們不該把他拿來 (over use) 作為開發應用程式的元件 (那是 EJB 或 JavaBeans 該做的事)。但 OSGi 卻可以!
2. JMX 多數用於 server 系統中，而 OSGi 卻不限於所開發的應用程式。你可以用它開發 embedded 系統、desktop 程式，甚至是 server 程式。

OSGi 不但提供了與 JMX 相似的容器管理能力，甚至它本身就是一套精密的 Framework。OSGi 採用Micro-Kernel 的架構，可以提供無限延伸的功能。OSGi 的 Bundles 線上更新功能、以及應用程式之微量記憶體執行能力，都是開發應用程式的利基。

OSGi 與 J2EE 在設計上，我覺得完全是兩種思維模式：J2EE 的思維是 build on large scale，OSGi 的思維是 build on dynamic scale。OSGi 以小搏大...

OSGi Resources:

• Welcome to the OSGi Alliance - OSGi official web site
• alphaWorks : OptimalGrid
• ServiceBinder - Automatic service dependency management in OSGi
• IBM Service Management Framework - IBM Software
• Oxygen project homepage
• Oscar - An OSGi framework implementation
• Knopflerfish OSGi

註:

目前我看到與 OSGi 有關的 JSR 為：

• JSR 8: Open Services Gateway Specification (OSGi)
• JSR 232: Mobile Operational Management

連續寫了兩篇需要用腦的日誌，來一點不同口味的!

我帶著兒子唸英文，發現他在某些發音上很難辨別，例如 fi 唸成 pi、ter 唸成 ker。

我一氣之下就說：兒子，你很難教耶! 你說，你有沒有難教？

兒子說：沒有，我沒有難教。

我靈機一動，就指著他的小弟弟說：你明明就有難教(台語)，割掉就不難教，割掉割掉…

兒子(驚慌失措)：不要，不要…

----對話完----

後記：女人與男人的生產力

嗯，好久沒有在這寫日誌了！今天有空寫，是因為老婆回娘家，才變得特別有生產力。

所以有人說：女人會讓男人的生產力減半。

但是馬上有人反駁說：沒有女人的男人，毫無「生產」力可言 ^___^ !!!

過去已經有不少思想家把組織視為是有意識的生命體(註)，而我今天要談的，不是組織的人格化，而是現有資訊系統的架構，如何引領企業，向訊息的智能反應邁出步伐。

簡而言之，現代企業體的訊息反應模式，是越來越具有智慧生命的傾向了。而這種智慧生命的傾向，從整體與個體的角度來看，居然可以看到它的組成分子(有趣的是，這些組成份子同時也是創造它的生物)--人類--的影子。這是怎麼回事？請聽我道來。

就個體的功能性來看，每個人都具有一些慣性的行為反應、對某些事情熟練的操作方法，同時在腦中也有對事物的認知體系。而企業的資訊系統組成，也同樣的具有事件反應模式，商業流程、規則之作業程序，以及存放操作及分析資料用的異動資料庫及資料倉儲等。

Portal、 CMS、操作型CRM等，用來輸入與呈現資料；BPM、工作流程(Workflow)、電子郵件及群組軟體就像是企業的神經，在組織的各種不同單位間傳達訊息；而智慧的決策來自分析型CRM、資料探勘與知識管理等系統--我們通常將最高的智慧決策層稱之為BI。企業資訊系統近來較之以往，則更加強調預測、 模擬與控制。我們可以說，如果有一物件，能夠預測其未來，又能自行繁衍，那麼一物件就具備了智慧生命的特徵。

個體間會傳遞訊息，甚至組成社群， 企業生命體亦然。在不同的企業體之間透過 Web Serveice 互通訊息，同質性或上下游企業會組成聯盟，制定出此一聯盟才了解的協定(protocal)、行話(jargon)來通訊，或是提供服務。這些都在早期的 EDI、中期的分散物件呼叫協定以及近期的 SOA 等得到實現。

BI 若只是能分析現況還不夠，它必須能針對現況的了解，制定出決策，進而控制自己的未來，以適應環境。其最終目的，當然是在競爭的同類中脫穎而出，得以永續生存。當然企業可以透過交配(crossover, 合併)或分裂來改變體質，但在大部分情況下，多數企業會希望在維持同一生命體的情況下，去適應環境。這就突顯出企業之智能與神經，必須能有效的監測與控制個體之機能。

為了達成這樣的目標，企業之資訊系統，必須能轉化成資訊的智能神經系統。這與數年前比爾．蓋茲所提的「數位神經系統－與思想等 快的明日世界」略有不同，畢竟蓋茲所強調的，僅在數位資訊系統的快速反應能力，而不在強調資訊系統所能提供的智慧決策與企業控制機能(這可由微軟這幾年來許多重大錯誤決策等到印證)。

所以，當代在檯面上的各種資訊系統乍看之下似乎沒有共同的目標，實則當它能透過 BPM 與 SOA 整合在一起之後，其目的性就明確無礙 -- 一切資訊系統的存在，就是為了讓企業適應現況與未來，得以生存及繁衍。生命，總會自己找到它的出路。

這一組成之系統，我將它稱之為企業生機系統：它含蓋了企業的智慧分析與決策，訊息的傳導與輸出入，以及使生命體得以適應環境的監測與控制。

這樣是好的，科技始終來自人性。我說，科技勢必造就出人性。

註：

這方面的資料，可參考《電腦生命天演論：人工智慧的演化》一書的描述。我節錄其第一章的部分內容：

畢竟，我們是社會動物，出於天性，我們組成社會單位，就像我們是由細胞組成的社會構成一樣。威爾斯（H. G. Wells，著有《隱形人》與《時間機器》等科幻小說）儘管晚年對未來愈來愈悲觀，但對人類知識成為全球共享資源之後的世界，有無限的憧憬，在他 1938 年（出版的《世界大腦》（World Brain）裡寫道：「人類的知識與觀念，經過統一組織與分疏後……也就是我所謂的世界大腦……那個世界大腦將會取代我們許多沒有統一協調的神經節……我 認為，只有世界大腦出現了之後，才會有一個真正有能力的接收器，觀照世界事務……我們不需要獨裁者，我們不需要寡頭政黨或階級統治，我們要的是一個能夠意 識到自身的世界智慧。」我們為所有東西，不分大小，都發展了數位模型，而那些模型，面臨了模仿、複製自身的難題。就我們所知，這就是意識演化的起點。

不一樣的系統分析

「研究方法」裡面所說的系統分析，跟軟體工程裡面所說的系統分析很不一樣。

軟體工程裡面所說的系統分析，雖然也包含需求擷取、系統分析與設計，但在於確認系統設計規格上，做的總是略嫌不足。也就是，你如何確定你的設計是有效的。你的設計足以解決使用者所面對的問題，或是有效達成將來的需求？

可以說，軟體工程裡面的系統分析與設計方法，是比較適合用在 "確定性" 系統或 "創造性" 系統。也就是說，你已經確定某一問題該如何有效解決，或是你想要把成型之概念創造成系統，你才適合採用軟體工程裡面的系統分析與設計方式。

而研究方法裡面的系統分析，則是用來解決尚未有明確答案或解法之問題。什麼樣的問題是沒有明確解答的呢？例如：針對一發卡銀行而言，它如何找出合適的核準率與訂定出每個人的信用額度，這樣的問題可能會隨著大環境的改變，而有不同的解法。

為了與軟體工程裡面的系統分析區別，我傾向把這樣的程序稱之為「系統研究」。透過系統研究，你可以對一個系統的本質進行深入的了解，找出系統運作的脈絡，進而對現行系統的徵結設計適當的解法。

在系統研究中，有許多的方法可以讓你深入了解某一系統，我們可以概略的將這些方法區分成質性研究或量化研究。而當我們掌握系統之脈絡後，極可能需要針對系統的目前的問題提出解決方案。這樣的方案，不是我們設計出來就算了，而是需要透過許多方式去驗證這樣的設計的確有效，甚至可能需要透過各種模擬、實驗設計的方式，來驗證設計方案的確可行。

了解問題的終極目標，是要獲得一可控制的系統。透過模擬與預測，我們可以在系統尚未正式上線之前(或是解決措施尚未實施之前)，就了解方案實施的結果。這有點勝兵先勝，而後求戰的味道。

現代商業環境下軟體設計之挑戰

現代的商業環境變化極為迅速，在過往開發專案的經驗中，常發生一些不可避免的現象：

• 好不容易開發出一個系統，或是甚至系統還沒開發完成，商業環境已經改變，系統從未上線，即已過時。
• 專案開發曠日費時，不管專案是否完成，客戶發生人事異動，有可能是公司間的整併或裁撤，使專案變成無主孤魂。
• 對於面對的問題尚未能提出有效的解決辦法，就急著進行產品開發。不成熟的問題(搞不清楚要解決什麼樣的問題)，導致不成熟的設計，再導致不成熟的產品。

區分研究與開發、系統設計與軟體設計

針對以上的現象，我想最好的避免方式，還是將研究案與開發案分開來進行，先進行研究案。

在研究案進行過程中，前半期著重了解問題的本質，後半期著重解決方案的測試與設計。這裡我要強調，研究案也牽扯到設計的部分。這是因為畢竟我們面對的，是商業環境，任何專案成立的要素，必須能讓使用者從中得到利益。所以決不是為研究而研究，而是要設法找出解決問題的方法。

在對問題領域的了解上，我想可以採用質性方法裡面的紮根理論，傳統軟體工程裡面的需求訪談方式，建構出完整的領域架構知識。

而研究案中的設計方式，與開發案中的設計方式實有不同，它會更強調可行性分析與概念的驗證。必須有辦法對設計的有效性提出證明。在設計過程中，需要對解題方案建構出(許多)模型，而這些模型必須具有可模擬、可測試或可驗證的特性。

在程式設計裡面的單元測試中，你會丟入一些資料給測試程式，看看被測單元的執行是否正常。而在研究案的方案設計中，你也會丟入一些資料到你的系統模型中，看看產出是如何。然而這裡所求的通常不是你的模型是否正常，而是從眾多方案中找出一個最佳解。

為了支持研究案的資料分析，你必須有一套有效的統計分析工具，像是統計分析軟體 SPSS 或是 SAS 等等。為了瞭解方案的設計是否有效，你可能還需要一套模擬軟體，這樣軟體隨著應用領域的不同有著很多的多樣化風貌。用 Google 查詢「系統模擬軟體」就能得到一堆。

如果既有的分析模擬軟體都不能滿足你的研究需求，而需要自建軟體，那麼切記一個原則。你必須想辦法萃取出問題領域的通用模型，針對這個模型去設計軟體，而不是把你的解決方案寫死在程式中。如果你把解決方案寫死在程式中，當你變更解題模型時，就得再重寫一次分析或模擬程式，這就退回傳統的開發模式了。

如果你的研究案近期可能得不到一個具體的成果，卻又必須進入開發案(是的，這是一個時不待人的世界)，更必須確實把握上面所述「萃取出問題領域的通用模型」的原則。如此一來，你才能得到一個具有彈性，可以不斷成長與擴充功能的系統。

延伸閱讀

• 企業研究方法:引述 :『無論是社會科學領域剛入門的新生，或是企業組織中常面臨各種決策的經理人，抑或此兩種角色兼具的EMBA現職學生，如何在一大堆的工具與量表中，快速 且正確地找出適合的方法並使用無誤，毋庸置疑地，會是能否優游於企業管理或相關管理科學領域的重要關鍵...』
• 系統分析在經營決策上的應用:引述 :『本書目的在引導讀者了解處理投資等計畫問題的正確觀念及步驟，內容包括系統分析的意義、其在經營決策上的應用、系統分析的方法與限制、最佳決策方法、計劃 分析、貝氏決策理論、成本效益分析、馬可夫分析法、價值分析法、AHP法、資訊系統分析及高速鐵路等三個個案探討。...』

昨夜，又是難眠的夜…
為什麼而難眠呢？

對我而言，通常是無法克制的心緒起伏…
也許是因為思念一個朋友
也許是反覆思索一個想法
更常的是，思考一個問題如何解決…

總是嘲笑自己：
當我的腦子不動的時候，我沒法讓它動
當我的腦子要動的時候，我沒法讓它停

晚上下班回家時，看著 BeeTV 正在播報雙子座的一週運勢，其中有一項特別引我好奇 "要注意交通問題"。我想現在我是每天搭車上下班，該不太可能發生什麼 "交通事故" 吧! 不久準備下車時，竟發現我把悠遊卡遺忘在公司，而身上所有的現金，是皮包裡的千元大鈔。在確認找不到所有可用的零錢後，只好硬著頭皮拿起千元鈔跟試著跟鄰 座的女子換。巧的事，她是外籍勞工，比手劃腳直說 sorry。再向後座的女子換，她搖搖頭說找不開。我嘟嚷著 "該怎麼辦呢…"，好心的後座女子說她可以給我十五元。嗯! 我遇到人間菩薩了。我跟她直道謝，帶著感激的心投錢下車。

後來我回想今天一整天的遭遇，還真的發生了許多通勤上的小事故。像是一早就因星期一的高車流量及雨天的大塞車讓我進公司晚了十分鐘；而下午至客戶那 邊，在 打開車門之際，不慎把手中文件掉落滿地；回到辦公室之後，發現因為匆忙外出，所繫上的領帶根本是歪的! 而回家的過程中，又將證件卡片等遺落在公司…

即使是這樣，我還是對那一週運勢有些懷疑。首先，該不會所有雙子座的人都跟我一樣，在今天這般失魂落魄的吧？其二，觀之這些小事故，其實都是因為我 這一整 天來心神不寧所致，若是行事小心點，當不致如此。最後，其實我是感謝這些小事故的，因為它們是以溫和而無傷的方式出現，帶給我精神上的惕勵 — 讓我想到「君子居易以俟命，小人行險以僥倖」。也讓我隱約帶出一個機運的模式：天將降災殃於斯人也，必先喪其心志，惑其神情…。

終於讀完 電腦生命天演論：人工 智慧的演化 一書了。如果說這是一本小說，那肯定是我費時最久閱讀的小說，因為它的資訊含量實在太高，每讀完一章乃至一段，都要讓我再 多花一點額外的時間思考。

讀完此書後，第一個想法就是這個世界的確有很多的天才(除了達文西之外)，像是發現二元邏輯的萊布尼茲，奠定現代計算機架構的馮鈕曼，以及解決「決斷程序」問題的涂靈等人，這個世界也的確因為天才而更加美好。

另一個想法是，我們過去所學習的歷史，都是偏重在政治與戰爭的，似乎忽略了其他很多方面的發展史。

最後，看到機器生命一路演化的過程，見識到這些偉大的科學家們的學術領域並沒有針對特定學科。以馮鈕曼來說，他的知識層次就涵蓋計算機科學、人工智 慧學、流體力學、經濟學、拓樸學、以及武器學等。從這些人的觀點上，可以看到他們 “思考世界運作的方式”，像是以拓樸學來解釋經濟學，隱約可看出萬法同出一宗的味道。

今天凌晨遭可惡的蚊子吵擾，在我兩度起床收拾搗蛋蟲之後，竟導致我無法再入眠。不得己，起床上網看看，搜索看看是否具有設計良好的部落格。

幾經比較之下，發現 WordPress.com 的設計還不錯：

• 單一文章多重分類
• 支持樹狀階層分類
• 在分類上顯示每一分類的文章數
• 不管是分類顯示還是(首頁)全部顯示，都支援分頁，載入頁面速度極快
• 支持除了 blog post 之外的靜態頁面
• 支持 publish, draft 及 private 模式

WordPress 中唯一我不喜歡的特性：URL 中包含的 blog post 日期，這樣一來，當我變更 blog post 日期時，就會更改到頁面的 URL，很容易造成書籤中的 broken link.

昨天問某個同仁：是否有意願在部門會議中提出舉辦讀書會的事。結果他表示近來工作繁忙，可能不太適合舉辦。嗯! 回家想想後，讀書會跟工作繁忙有什麼關係呢? 因為讀書會所要研讀的書，其實是要員工回家唸的，不是讓員工在上班時候唸的。因為我們部門從來不加班，讀書會自然也不會影響到回家唸書的時間。

我還記得以前部門辦讀書會，專案部門的經理跑來跟我抗議：同仁用專案的時間在準備讀書會的投影片。嗯! 如果一個人在下班的時間都不願花時間來充實自己，而把讀書會的研讀項目當成上班的正事來做，那這樣的就失去自發性學習的、然後再與別人分享的本意了。

我以前待過的公司中，也的確有相當重視員工教育訓練的。不過公司方面還是希望，盡量不要佔用上班時間。所以都會把教育訓練安排在下午 5 點之後。當然也有大公司安排正式的教育訓練，從幾天到幾個月不等。但是這樣的教育訓練極可能都伴隨著考核與評分，如果是新進員工的教育訓練，考核不過的極 有可能被 layoff。

Anyway，其實在那次事件後，我就不太有興趣再提起舉辦讀書會的事。與其花時間強迫別人學習，不如找時間多多充實自己。還有閒暇，就上網寫寫日誌抒發己見，也可藉此吸引一些志同道合的朋友。

沒想到這樣的風氣吹到我這來了，看了 Willian 的點名單，讓我直想到 "Birds of a feather flock togther." 畢竟他所提出的作家及部落格作者，也是我所欣賞的對象。

如 Willian 所說，他對作家的忠誠度不高，我也是如此。既然最近看的較多的是有關商業管理類的書籍，那我就從這方面下手吧：

詹姆斯‧路易斯博士

他出版了許多專案管理類的書籍，包括《我懂了！專案管理》、《專案管理聖經》、《專案管理三部曲：成功專案規劃、排程與控...》、《專案領導：開啟成功專案管理之鑰》等。專案管理這門學科雖沒有高深的理論，但實務細節卻是相當繁瑣。詹姆斯‧路易斯博士以豐厚的實務經驗，伴以簡明及精要的說明，常能直指問題核心，使讀者在思考的層次上得到提升。例如在《我懂了！專案管理》一書最後面的某一章中，就提到專案團隊在逐漸成熟的各個階段中，專案領導人的角色應該要如何轉換。而《專案管理聖經》中所介紹的系統思考的應用，都是相當實用又有趣的課題。

蓋伊．川崎 Guy Kawasaki

只要透過網路查查，就可知道這個人的來頭。會把他列在這裡，主要是佩服他那超乎常人的想像力及問題解決的技巧。書如其人，每本書讀來都能感受到他的狂氣，像是《讓敵人瘋狂》、《推銷夢想》、《策略革命家》、《麥金塔風範》，及近期的《創業的藝術》等書，書中的每個段落讀起來都是那麼鏗鏘有力，如醍醐灌頂。

蕭天石

你相信修道可以成仙嗎？這位道學家、宗師級的人物告訴了我們許多法門。著有《世界偉人成功祕訣之分析》、《道海玄微》等書。你可以在這裡找到這位大師的著作。由於道流的沒落，蕭老的聲名，也就沒有心法上偏重於儒、釋的南懷謹老師來的響亮。

傑拉爾德‧溫伯格(Gerald M. Weinberg)

傑出的軟體專業作者和思想家。1997年，溫伯格因其在軟體領域的傑出貢獻，入選為美國計算機博物館的計算機名人堂（Computer Hall of Fame）的成員。去年我才剛看完他的《顧問成功的祕密》，他總是能以充滿智慧又幽默的口吻來闡述思考觀點。其他的著作還包括《你想通了嗎？》、《程式設計心理學》等。如果我沒猜錯，在湯姆‧狄馬克《最後期限：專案管理101個成功法則》後面的某個章節，好像是第 17 章〈解決衝突的專家〉，曾寫道男主角湯普金斯請來一個著作等身的顧問，為他處理專案人員衝突的問題… 那位顧問，影射的應該就是傑拉爾德‧溫伯格了。

Martin Fowler

這位 IT 大師同時也是位部落格名家。會把他列在這裡，純粹是他的議論與觀點，每每引起我的共鳴。

至於我所推薦的 5 個部落格作者...

沒說過不能重複吧! 我的點名如下：

• Willian
• 王克明
• Jserv
• Xexex
• 江南白衣

說老實話，這些人我都不熟識。知道 Willian 這個人，是因為我以前買了他的兩本書--《C++程式語言經典本》及《物件導向設計模式》。王克明嘛~ 他應該是在台灣部落格中講 UML、物件導向設計觀念最多的人，我想我在 Misoo 物件教室 高煥堂先生那兒見過他一次，但他不可能記得我… 因為那次我只是去旁聽。那次的聚會，有點像是物件導向界的華山論劍，談的是軟體架構，王 sir 講話的神態，好像是那兒的大師兄一樣。

至於推薦 Jserv、Xexex、江南白衣，是因為他們類型，都像是 Java 技擊派的高手，而部落格又寫的很勤。