Software Cinema

RWW Report : Get Quick Impressions of Your Latest Product Iteration with Concept Feedback

又是一個從一個極端到另外一個極端的權衡.

現在的 Web 環境, 讓我們可以很容易地, 無花費地把任何想法, 計畫, 設計, 產品, 介紹給任何人, 然後收取任何的多元意見. 缺點就是過程可能會極度沒有效率, 也沒有保證性的正面結果, ex. Yahoo Knowledge+

當然, 花錢找顧問公司則是完全相對的作法, 是最有效率, 也可以得到保證性結果的作法. 缺點是顧問費用是一定要給的, 即便結果你不是那麼滿意.

ConceptFeedback 取了個中間的位置, 透過 "仲介" 具備一定水準的 Consultant Community, 來給予付費的顧問服務. 這之間自然就會有許多付費模型可以選擇. ConceptFeedback 是允許使用者選取三個 Best Advices 來給予實質的 Money Reward. 不過想來應該會允許使用者提高或增加 Reward 的數量, 畢竟如果是有價值的產品, 利用 ConceptFeedback 作為一個蒐集意見的平台也是值得的. 另外 ConceptFeedback 應該也有一些防止 Cheating 的機制才是.

其實除了 Consultant 的實質功能之外, ConceptFeedback 整合了相當多過去的概念, 例如網路商業廣告 ( 還記得上一個網路泡沫之前, 滿天飛的 "邊上網看廣告邊賺錢" 嗎 ), 知識分享社群, 網路問卷調查服務, 網路拍賣平台 ( 管理與貨物提供者的責任分離 ) 等等.

但相對來說, 就跟網路拍賣平台一樣, 可能會面臨容易出現強力競爭者的情形. 不知道 ConceptFeedback 或是其他的競爭者, 要用甚麼樣的策略來勝出 ? 跟有實力的 Consultants 具體簽約 ? 或是在 Profiling 上有過人之處 ?

今天看到 Nintendo 跟 Google 合作的遊戲安藤ケンサク, 雖然看不太懂遊戲的進行方式, 但是從少量 blogs 跟 forums 的簡短說明, 大致上可以知道跟 Search Engine 的 Search Keywords 有關, 利用 Google 在 Search Engine 上所累積的統計資料來產生新型態的 Q/A 遊戲, 最大的特點是問題的答案可能會隨著時間改變 -- 因為 Google Search Engine 所累積的資料也在變動中.


緊接著又在 JustineTV 看到人家在玩暴雨殺機 ( Heavy Rain ), OMG, 我真的脫離新遊戲太久 這遊戲的畫面真棒, 運鏡跟電影拍攝手法好像. 剛好看到玩家操縱的角色在房間裡探索, 看起來應該是遊戲初期, 中間有一度打開電視, 看到跟案件劇情相關的新聞報導, 然後把電視關掉.


這在一般追線索的解謎遊戲中常常看到類似的橋段, 但是今天我卻忍不住再想, 如果再打開電視一次會怎樣 ?

遊戲的 NPC 或裝置 ( 包含電視 ), 通常都是有固定集合的對話或是資料, 為了避免太死板, 又會循環或亂數出現這些對話. 但從安藤ケンサク的例子, 是否我們可以開始考慮跳脫這樣的限制, 讓遊戲更加跟已經有的 Online Data 作結合 ?

例如上面的開電視, 如果遊戲本身把該電視跟 Youtube 或其他 Onlive Vedio Service 作結合, 就可能在重開時看到其他的新聞, 這樣似乎也會很有趣 :)

利用不同的 Services 來存放不同的 Data, 然後在一個統一的 Blog 展示是目前 BSP 系統的標準設計模式. 然而 BSP 對於整體 Data 的管理策略可能還有值得討論的地方.

以無名的例子來說, 進行 Blogging 的使用者可能同時利用他的網路相簿跟網路影音服務, 但基本上該兩項服務的 Data 跟 Blog 本身是分開的, 只是在 Blog 上提供可以存取該 Data 的介面. 有時候使用者如果因為特殊原因要暫時關閉該 Blog, 原則上相關的 Data 應該也無法取得才對.

例如無名的 tiger302 這個 Blog, 因為某些理由被使用者關閉, 因此相關的相簿影音等資料也無法取得. 但是如果你從 無名影音 進行搜尋的話, 事實上還是找的到相關的 Index, 只是連結進去後一樣是無法讀取.


然而, 雖然無法透過尋常的 Blog 或是搜尋介面看到影片資料, 如果有心人在 Blog 開放時留下影片連結的話, 居然是可以直接看到理應被禁止存取的影片 Data, 例如同樣是 tiger302 上傳的這隻影片 :


顯然地, 無名是利用禁止某些 Service 被執行, 來達到禁止 Data 被取得, 但是這樣作就會產生上面的這種漏網之魚 -- 也就是某些公開的 Service 還是可以取得該資料.

同樣的情況在其他的 BSP 上也可能出現, 如果 BSP 沒辦法讓使用者把相關的資料都綁在一起作管理的話, 就可能出現文章被禁止存取了, 圖片跟相關影片卻還是可以被取得的情況. 然而, 以使用者的角度來說, 文章就包含了圖片跟影片, 而非只有文字而已. 因此相關 Data 都應該被禁止存取.

在無名的例子中對於此問題還算好解決, 只要 BSP 願意多花點心思調整一下 Data Model 或是 Access Model, 提供給使用者在發表文章時作選擇即可. 然而當這個問題是跨服務 (Across Services) 時就會複雜許多.

在幾年前的台灣 BBS 也存在類似的問題. 當時全台灣大大小小的 BBS 可能有上千個, 透過 Mailing List 原本的機制, 彼此轉信變成一種風潮. 但是轉信的看板之間卻出現一種問題, 當有使用者錯發文章, 或是不恰當的文章要被刪除時, 只有原本的發信站做了刪除, 其他收信站還需要該站或看板的管理者再做一次判斷. 造成垃圾文章需要花費大量的人力管理刪除. 後來的 BBS 發展出 control.cancel 協定, 只要支援該協定, 可以透過轉信機制自動刪除在發信站已被刪除的垃圾文章.

但這要在不同的 Services 之間, 支援共同的 Protocol 似乎難度大的許多, 況且允許的動作也不是簡單的刪除而已.

最近要到蘭嶼去玩幾天 (8/1-8/4), 發現行程規劃實在是件有點複雜的事情.

從台灣本島到蘭嶼有搭飛機以及搭船兩種方式. 飛機的話目前只有台東機場有德安航空到蘭嶼的航班, 其他地方沒有.搭船的選擇就比較多了, 台東富岡有, 也可以從屏東後壁.

如果說旅程規劃沒有任何彈性, 事情就簡單許多, 但是選擇也相對變少. 比如說就是要從台北到蘭嶼, 然後日期就是 8/1 到 8/4, 那麼大約只剩下台北搭火車夜車到台東, 一早坐飛機到蘭嶼, 不過這樣的旅程很累 ; 或是 8/1 早上搭火車, 但是這樣到蘭嶼的時間就變成下午了.

而如果旅程規劃有很多彈性, 像是我們的規劃, 可以接受先到台東住一兩天, 然後從容地搭飛機到蘭嶼 ; 甚至可以接受先到台南待一天, 然後從台南搭火車到台東 (大約只要三個半小時), 這樣比台北到台東快上不少, 旅程也比較不會累. 其他像是先到花蓮, 再到台東等等, 都在可以接受的範圍. 這時候再考量旅館, 交通, 食物等等相關事項, 整個規劃作業瞬間就變的很複雜.

在 Web Service 與 SOA 的研究中常見以 Traveling 作為 Service & Workflow 的 Example. 常見以 Time 為根據作行程的銜接, 以及基本的條件設定, 然後加上一些進階條件的選擇, 像是不搭船, 以及 Quality 的要求等等. 這樣 SOA 的 Solution 事實上存在很多複雜度, 除了上面說的以外, 像是 Service 的狀態要能由 Service Provider 更新, 確保 Service Abailability 以及 Quality 等等.

但是若單純以 Bottom-Up 的方式去產生可能的 Workflow, 固然可以得到最多的可能性, 但是畢竟使用者要的通常只有一兩個, 因此中間就需要透過使用者的參與來降低可能的選擇數目, 這又變成了 User Interaction 的問題.

也許因為這樣的複雜度, 許多國內的旅遊服務都只停留在 Information Portal 或是 Service Portal 的階段而已, 而不是真正的 Service Provision Forge.

我認為類似的應用應該考慮利用 Top-Down 以及 User Community 來夾出可能的選擇, 進而大幅降低一般使用者的負擔, 同時確保規劃結果的品質與可行性.


方法就是利用現成的 Travel Plan 作為 Incomplete Workflow 去套可得的 Services. 可以想像一個類似 Digg 的 Travel Plan 推薦子系統, 由一個 Community 維護. Community 成員可以貢獻自己的 Travel Plan, 作為基本的 Template, 而其他成員是以一個 Travel Plan 為單位進行推薦以及參考. 而反過來, Community 也能夠提供 Single Service 的資訊, 有利於一般 Service 資訊的更新與正確性.

當然, 免不了地 User Interface 依舊會是關鍵, 必須要能夠盡量降低使用者輸入以及推薦 Travel Plan 的 Effort, 才能夠在使用者可以得到的幫助與付出之間取得平衡. 另外必須有 Formal Travel Model, 而不是向許多旅遊網站只是讓使用者以 Natural Language + Free Style 分享旅遊心得. 既然要從使用者端取得資訊來再利用, 就應該有系統地蒐集以及使用.

不用把資訊的取得想的太複雜, 也不要期望旅途中相關的商家旅館會時時更新訊息, 單純依靠 Community 的力量來建構這樣的環境, 有效地在資訊進來之前就先篩選, 同時也讓回給使用者的規劃有最高的有效性.

Google Maps 現在也加上 Walking Direction 的資訊了( RWW 也有相關文章 ), 這基本上是一個必然的動作, 能夠讓地圖提供更有效率的幫助. 即便是在有了各種電子地圖後, 查閱地理資訊變得更加容易, 自動規劃路程也變得可能, 然而缺乏更加詳細的資訊卻讓許多理想的服務無法完成.

像是 UrMap 也遲遲未能提供台北縣市以外的大眾交通工具資訊, 以及路線規劃只能提供汽車, 沒辦法照顧到機車族群. 我認為問題不在於 Algorithm 的設計以及 Computation Power 的限制, 而在於 Valid Data 的取得.

透過 Sensor 或是 GPS Devices 固然是一種方式, 也常用於自然災害偵測與防治以及疾病控管等大範圍監控系統上, 但是幾乎都是透過衛星傳輸資料, 要在城市中使用, 為了降低成本需要仰賴於城市無線網路基礎設施, 同時即便如此, 大量的 Sensor 裝設費用仍然很嚇人.

在這些困難下, 其實過去的警廣交通網作法, 反而是可以讓人考慮的一條路. 台灣主要道路的路況是由熱心的駕駛回報到警廣, 然後由警廣彙整略加查核後由廣播通知鄰近其他駕駛人

同樣地, 我們可以期待類似 Twitter 與 Google Maps 的結合. 透過 Twitter, 使用者可以時不時地簡短報告自己周圍的地理狀況, 然後以 Google Maps 作為具體呈現的平台, 廣播給大家知道. 已經有類似的服務在 TwitterVision 被實現. 相關的主題也可以在 Google 上利用 "Twitter Google Maps Mashup" 作為關鍵字找尋, 有相當多的討論.

然而 TwitterVision 也只是讓 Twitter + Google Maps 發揮 1 + 1 = 2 的效果而已, 我們需要讓 1 + 1 > 2 .

透過 Twitter 而來的 Message 或是 Media (Photo, Vedio Clip, etc) 應該可以在使用者輸入時先作簡單的分類或是 Tagging, 然後在後端利用 Semantic Analysis & Semantic Web 以及 Image Recognition, Image Classification 對於這些資料根據 Google Maps 的基本地理條件 (Constraints) 作彙整, 針對不同使用者的使用需求, 提供即時的相關資料整理.

交通以及路況就是一個很容易處理的應用. 只要在輸入者提供一些簡單的 Template, 很容易就能得到使用者身邊有用的 Data, 然後就能夠整理成該地區有用的交通及路況資訊. 當然, 這依舊仰賴於無線網路基礎設施的鋪設, 以及手持式電子裝置的普及 -- 不過話說回來, 這時代有哪項網路服務不是建立在這樣的預想 (Assumption) 之下 ?

期待很快能看到這樣的 Product 出現 :)

RWW 上的一篇文章 : Reaching for the Sky Through The Compute Clouds, 我覺得寫的不錯, 算是從一個容易理解的角度說明 Cloud Computing. 同時他提出 Google Data Cloud 的例子來輔助他畫出的 Clouds 概念圖增加不少說服力. ( 不過 You vs Them 段落之後感覺有點混亂, 不是很能同意 )

其中請注意到底下回應中, Avner Algom 的回應 ( No.15 ). 為了紀錄方便, 完整轉錄 (稍加編排) 如下 :

It is to remember that without the convergence of grid, virtualization and SOA concepts, the cloud implementation cannot be done. In fact, the Cloud Computing concept is a Grid based business model that provides utility Computing services and/or SaaS services

Terminology Synch:

• Grid provides the Service-Oriented Infrastructure Virtualization (SOIV) that enables IT scalability and flexibility
• Service Orientation - Service-orientation is a design paradigm that specifies the creation of automation logic in the form of services. It is applied as a strategic goal in developing a service-oriented architecture (SOA).
• Virtualization - a technique for hiding the physical characteristics of computing resources from the way in which other systems, applications, or end users interact with those resources.
• Utility Computing – Pay-per-Use for network based Compute and Storage services
• Software as a Service (SaaS) - Pay-per-Use for network based software applications’ services
  

目前來說, 我傾向認同這樣的歷史觀點, Cloud Computing 並非技術面上的突破, 而是技術面上的成熟代表. 然而, 僅僅是相關技術的成熟, 有必要 Google 大張旗鼓的推廣此概念嗎 ? 僅僅是為了對於顧客的商業包裝, 推廣相關技術到一般人面前嗎 ?

我覺得除了把 Cloud 跟過往 Network 上的雲狀圖示作聯結之外, 是否應該想想取用 "Cloud" 這個字所隱含的意義呢 ?

在 Webster's Dictionary 上可以查到下面的解釋 ( 只取較為相關的部份 )

1. Any collection of particles (e.g., smoke or dust) or gases that is visible.
2. A visible mass of water or ice particles suspended at a considerable altitude.
3. Out of touch with reality; "his head was in the clouds".

然後我們又知道, Cloud 的形狀, 大小, 高度, 都會因為各種氣候條件而有所不同, 如果再結合 RWW 文章中的這張圖, ( 引用自 RWW, 由 Alex Iskold 繪製 )


霎時卻讓我想到了, Cloud Computing 從軟體工業的角度來說, 或許代表的是軟體產業的二次分工.

第一次分工是著重於軟體製造業的分工, 從 System Design, Software Analysis & Design, 到 Implementation, Testing 的分工. 這在目前世界軟體產業已經是普遍的模式, Global Software Engineering 也早已被討論多時.

而我所指的軟體產業的二次分工, 則是軟體服務業的分工.

上圖中的各種 Cloud 都可以被視為是一群提供相關服務的業者 ( 服務提供者, 未必是真實人類 ) 所組成, 但是與單純的 Service Group 不同的是, 在此 Cloud 內的 Particles ( 服務提供者 ), 必須遵守同樣的 Protocol 規範, 包含 Interface, Quality 等等, 因此對於採用該 Cloud 服務的顧客而言, 面對的是整個 Cloud, 而非單一個服務提供者.

這個觀點相信也與 RWW 的該篇文章(特別是 You vs Them 段落), 以及網路上的許多文章應該是相容, 只是從產業改變的觀點來說.

不過必須再加說明的是, 我不認為此分工模式會導致軟體服務創意被壓縮. 事實上, 這種分工模式是一個把餅做大的分工模式, 而不是為了要做出很多不同口味的餅. 在此情況下, 最大的得利者會是開發出新口味大餅的業者, 其次則是某種口味大餅做的最好賣得最好的業者, 最後則是勉強作一種口味的大餅可以餬口的業者. 而 Google 跟其他在推 Cloud Computing 的業者這當然是前兩者 :)

在癮科技看到的這篇新聞 : 費城將在街上設置垃圾壓縮機 很有趣, 等同於是把小型的垃圾車放置在城市中固定的地點, 透過科技的進步來增加垃圾收納量, 以及降低環境污染度, 克服過去公設垃圾桶會有的許多缺點.(以下圖片引用自 KYW Newsradio)

不過之所以會特別想在這記上一筆, 並非僅是因為這事有趣.

過去在談論 Service-Oriented Computing 時, 我們似乎都會很自然的想到各種商業應用, Shopping Services, Business Services, Travel / Hotel / Transportation Services 等等, 然而回歸到現實面, 其實還有很多非常小, 但是很實用的 Services 經常就被忽略.

像是很常遇到的, 走在街上, 可能是因為剛剛買了小吃, 飲料, 或是打噴嚏的衛生紙, 很容易的手上就會有想丟掉的垃圾. 如果是在不熟, 非生活圈的地方, 一時之間要找垃圾桶就不是如此容易的事情. 如果費城的垃圾壓縮機可以在 Service-Oriented Computing 基礎設施上搭配提供這種 垃圾 Service, 應該會讓計畫的效果更好吧.

這種 垃圾 Service 看起來很小很無聊, 可是需要的時候功用卻是很大的.

上學期修課跟學弟合作的一個期末計畫是建立一個巴士系統的 Embedded Middleware. 目前這東西也慢慢延伸變成學弟的 Master Research. 在整個 Vision 中, 有一部分就是關連到即時地蒐集巴士系統中 Customer 相關的資訊, 以及整理分析這些資訊, 產生出足以作為決策支援的資訊 ( Structured Information ).

類似的東西已經開始有人用 GPS 得到的資料做出 Prototype 來摟.

6/22 的 NY Times 報導了此一 Prototype : Predicting Where You’ll Go and What You’ll Like , 由 Sense Networks 這家公司開發 ( 我覺得他們名字取得不錯 ) . 基本概念是利用 GPS 得到 Location Data 以及 Movement Data, 然後透過適當的 Mining Algorithm 分析, 就可能得到關於行為模式的猜測結論. 在文章中期時也提到, 可以用來被追蹤 (Track) 的東西很多, 不見得只有 Location 可以用來追蹤猜測人們的行為. ( 以下圖片引用自 Sense Network Media Center 公開資料, 上面還有 Vedio 可以下載 )


Realtime Data Mining 技術本身其實不是困難點, 困難的是怎樣讓整個 Process 可以真正應用到商業行為中使用. 期間需要考量的, 整合各種軟硬體設施, 同時城市無線網路的基礎也不可或缺. 另外就是使用者願意曝露自身資料的意願.

不過從過去的成功經驗來看, 其實這個世界的人們對於自身的資料隱私其實不是真的那麼在意 -- 只要有利可圖的話.

Sense Network 做出了很合理且聰明的決定, 他們不是一廂情願的向使用者買 Data 或是期望使用者會自動主動提供資料. 而是利用提供給使用者相關服務來換取資料 ( 原文為 : Sense decided to trade services for data. ) 而 Sense Network 自然可以從操作廣告以及服務之間得到適當的利益. 從 Google 以來, 這似乎已經是 Web 2.0 唯一具有足夠商業成功案例的模式了.

但是 Sense Network 是否能夠獲得足夠久的成功卻還很難說, 相當仰賴於他們的商業操作手段. 使用者的 Location 資料並非是會有長久價值的資料, 其 Lifecycle 可能只有短短的數個小時, 因此 Sense Network 不可能像是某些 Blog Supplier 一樣透過累積大量的懶惰使用者讓自己不倒, 而就算是在 使用者 <-> 手持裝置 <-> 位置及其他資料 <-> 可得服務 的 Cycle 中, Sense Network 也不是居在任何不可取代的位置. 因此一切都還很難說.

唯一能肯定的是 Realtime Mining 相關應用的這個趨勢應該確實會發生.

只在 ZDnet.com 的新聞稿上看到 IBM 的 Lotus Symphony 介紹文章中有一個有趣的觀點 (不過沒找到原文) :

IBM的主管表示，這項策略不直接與微軟Office競爭，而是把文件當作「容器」(containers)，儲存工作流程與協作應用程式內的資訊。

在物件導向概念裡, 一個 Object 可以看成是 Data 以及允許改變這些 Data 的 Method 之集合. 在一份文件上, 很顯然地文件裡面用文字或是圖片, 甚至是影音檔案所想要表達的知識是我們需要的 Data. 過去我們可能習慣於直接把文件當作 Data, 但是上述的文字似乎是想把文件當成 Object ? 如果一份文件除了本身所紀錄的 Data 之外, 還紀錄了可以調用哪些 Web Services 來對於文件作存取, 那麼其實可以把整個文件視為一個 Document Object. 此 Document Object 具有 State : 就是 Data, 以及目前執行中的 Web Services, 也具有 Dynamic Behavior, 視乎調用了哪些 Web Services.

這樣一來過往 Document Editor 的角色就更有趣了, 將會變成一個 Web Service Management Tool, 負責結合不同的 Web Services 到 Document Object 上, 每一次的編輯事實上是在不斷的調整Workflow.

Users can enjoy the easy-to-use interface and online community for templates, tips and support.

Businesses can control software acquisition and upgrade costs, provide ability to compatibility with Microsoft Office file formats, protect future access to documents with support for ODF and support a global workforce with Lotus Symphony's native language support for over 23 languages.

Developers can extend their applications with the power of Lotus Symphony through support for plug-ins and, when the Lotus Symphony editors inside Lotus Notes are used, rich composite applications.

在 Lotus Symphony 的網站中也提到了採用 Eclipse Rich Client ( ERC ) 想法, 對於 Lotus Symphony 特別加強 Plug-ins 的支援. 從這點看來 Lotus Symphony 可能是 IBM 在過往 Lotus Smart Suits 的失敗後, 歷經 Eclipse 轉投 Open Source Community 的成功, 以及自身在 Web Service Development & Solution 的領導地位後, 轉而想在 Microsoft Office 以及 Google Docs 兩個極端之間殺出一條不同定位跟發展模式的產品.

剛剛在 癮科技 看到這篇新聞介紹 : Vodafone將推出Otello圖片搜尋服務 , 簡短介紹 Otello 的服務以及使用方式. 覺得相當有趣的是, 在 Otello 的使用情境 ( usage scenario ) 下, 我們只需要利用既有的各種可進行數位攝影的 device 就能夠進行相關資訊的搜尋, 間接的把搜尋引擎 ( search engine ) 嵌入 ( embed ) 在 device 上變為一種 "service" 的概念, 而不是一個 "software" 或是 "website".


這樣的使用方式無疑地是更符合以及簡化我們的使用習慣. 原本我們就希望看到的東西到進行搜尋之間可以是無縫地進行, 而不是還要把圖片存下, 然後上傳到某個圖片搜尋引擎再進行搜尋, 這樣分開使用不同的 services 實在是太麻煩了.

而很容易聯想到的, Otello 現在支援圖片的搜尋, 未來如果結合光學辨識技術 ( OCR ), 要能夠直接把看到的文字用來搜尋應該也不會是甚麼難事. Seeing is Searching, it's cool !!

剛剛看到 YouTube 上似乎增加了新的 sorting 方式, 本來是在利用 keywords 進行搜尋過後, 可以有 Relevance, Date Added, View Count, 以及 Rating 的 sorting 方法,


現在多了 Today, This Week, This Month, 以及 All Time 的選項. 但是我實際試了結果好像沒有作用, 還沒有作用的功能會先放上來嗎 ? Anyway, 從選項看起來, 我猜應該是可以進一步對於 sorting 的結果作切割吧, 例如 Date Added 加上 This Week 的話, 就只會看到利用 keywords 找到的 Videos 中, 只列出於本週內加上的 Videos, 依照 Data Added 的新舊順序列出. 雖然不是什麼突破性的 sorting 功能, 但是增加這個利用 Time 來切區塊的參數, 就可以讓 sorting 的效率增加不少.


玩著玩著就想到, 以後不知道會不會出現 Domain-Driven Video Sorting. 顧名思義, Domain-Driven Vedio Sorting 就是會針對你要找的 Videos 所屬的 domain, 有專用的 (specific domain) 最佳化過 ( optimized ) 的 sorting 方法.

講到最佳化好像就會變的很複雜, 要用一堆數學, 其實根本不用啦, 舉例子來說, 我上面的兩張圖片是在找韓國星海職業比賽的影片, 想看 Bisu 對上 Stork 的最近三場比賽 Videos, 而 YouTube 目前只有上面說的兩種 sorting 方法, 這兩種 sorting 方法事實上是普用性的 ( general purpose ), 對於哪個領域都可以適用. 但是在星海職業比賽內事實上有一些領域邏輯 ( Domain Knowledge & Logic ) 在, 例如這是 OSL 或是 MSL 的聯賽, 是單場 (1 set) 或是三連戰 ( 3 set ) 等等. 這些領域邏輯應該可以被用來進一步增加 sorting 的效率.

再舉個例子, 如果今天我是找 NBA 短片 Videos, 我可能可以利用聯盟分組 ( Division ) 與否的方式來為找到的 Videos 切段, 在 NBA 官方網頁上已經有類似的區分方法, 不過是用來看戰績表的.(噗, 不小心把姚明跟 Garnett 剪進去, 沒辦法今天沒馬刺戲份)


換句話說, 當我們在 YouTube 上根據某些關鍵字找到某些影片之後, YouTube 會自動根據你找到的影片之領域特性, 提供你除了普用性的 sorting 方法之外的, 此領域專用性搜尋方法, 因此究竟你每一次的搜尋可以用到哪些 sorting 方法是動態 ( Dynamic ) 決定的. 而至於 sorting 方法的產生就不一定, 要容易作點或許可以利用 Domain Ontology 推演出來, 這樣八成就會是靜態的 ( Static ), 複雜點的話或許 sorting 方法會是 self-evolved, 這方面就超越我所知道的領域了.

不管是哪樣, 可預期的, 服務都是越來越往我們的真實生活在靠攏, 我們需要遷就電腦軟體的地方只會越來越少.

昨天收到 SourceForge.net 的通知信了, SourceForget.net Marketplace 正式開張.

在 Marketplace 上, 可以購買 services, 也可以提供 services.

提供 services 的人不一定要是某 project 的維護者, 舉 XAMPP 為例, 目前提供的一個相關 service 是 XAMPP Instalation, 提供者 (seller) 並非原本在 S.F.net 上, XAMPP project 的維護者之一. 不知道這會不會引發在 S.F.net 上的 SEO 問題 : 我的 services 要怎樣比較容易讓需要的人找到呢 ?


同時從右側的進階資訊 widget, 可以看到此提供者同時提供的其他 services, 以及 profile. 在 profile 內的資訊除了基本資料, 聯絡方式, 以及該 seller 在 S.F.net 上參與維護的 projects 之外,


同時可以察看該 seller 的 reputation 評分, 算是某種 customer feedback 的 service quality 紀錄. 但是此 quality 統計紀錄是針對 seller, 而非針對該 seller 的不同 services. 由於同一個 seller 對於不同的 services 能夠提供的服務品質可能有所不同, 因此我覺得如果可以同時提供該 seller 在不同 services 的表現會更好. 左下角有一個 detail 選項, 或許可以看到各次評分的詳細紀錄, 但是因為沒有找到已經有紀錄的 seller, 不知道下面的資訊會如何出現.


另外在 reputation 評分上, 也只有提供 excellent, good, satisfactory, fair, bad 等等模糊的評分, 而沒有辦法根據不同的 software services 有更細節的描述, 或許可以結合 ontology-based [1] 的方式給予更有意義的評分.

身為 OSS portal 的龍頭, SourceForge.net 的 Marketplace 能夠獲得怎麼樣的成功, 相信全世界都在看吧. 如果 Marketplace 能夠在獲得一定的成功, 很可能給投入 OSS 的力量帶來相當大的影響, 同時在 software company 營運模式也會有所改變也說不定. ( 派遣的品格 !? )


References

[1] M. Sensoy and P. Yolum, "Ontology-Based Service Representation and Selection," IEEE Transactions on Knowledge and Data Engineering, vol.19, no.8, pp.1102-1115, August 2007

前幾天寫了關於 BUG Labs 的一些觀察, 剛好這兩天因為 Lab meeting 的緣故看了一篇文章, 是 Dirk Riehle 的 "The Economic Motivation of Open Source Software : Stakeholder Perspectives" [1]. 在文章的前半段, 作者用了兩張圖來解釋 open source 對於 software company 獲利的影響.

第一張圖 ( referred and re-drawed from [1] ) 如下, 橫軸是潛在的願意購買 customer 數目, 縱軸是 customer 需要付出的價錢. 一個完整的 product 是由 hardware, software, 以及 services 所構成, 而非單只有其中一者. Customer 的需求被 modeling 成為一條曲線 ( 雖然圖上是一條直線, 不過這只是示意圖 ). 當 open source 被引入 software 那個區塊時, 由於對於整體 product 來說, 軟體的研發製作成本降低了, 因此在維持原售價的情況下, software company 可以從每個 customer 身上獲得的利潤就會增加.

而假使 software company 的利潤完全來自於 service, 而不包含販賣 hardware 以及 software 時可能獲得的利潤, 這時整個 hardware 以及 software 的兩個部份對於 product 就是完全的成本而已. 那麼扣掉 service cost, 剩下的就是 software company 可以獲得的 service profit.

當然 service profit 會根據最後的 service 定價而定, 假設 service 最低價要高於所有的成本, 那們我們就可以在成本與 customer 需求曲線之間括出一塊可以獲利的區域, 在下圖左中以灰色區域標示. 當 open source 取代原本的 software 區塊後, 可以想見的, 因為成本降低, 因此可獲利區域也就隨之增大. 同時藉由價格的調降, 負擔得起該 service 售價的 customer 將會變多, 亦即相對市場就可以變大. 這是下圖右的說明.

在 [1] 中並未討論到 hardware 的問題. 而如果我們考量 BUG Labs 的願景, 以及所謂 open source hardware 的想法, 很有可能我們可以基於 open source software 之上, 把成本再一次地降低, 使得更多的人可以負擔起一樣的 service.

下圖左是只有 open source software 的樣子, 下圖右把 hardware 部份用 BUG Labs 取代, 由於硬體部份不再需要一個整體性的產品, 而是可以讓 customer 根據自己的需要選購適用的硬體, 電子製造商將沒有辦法將電子產品的硬體規格掌握在手中, 因此我認為這部份的成本可以降低. ( 事實上也可能帶動 open source software 部份的成本再度降低, 因為 open source software/hardware 的整合會在 project 中完成, 不需要採用者額外進行, 但這裡先不考量這一點 )

很顯然的, 所帶出的結果就是 service profit 的可調整空間再度變大, 同時有意願購買, 也有能力購買的潛在 customer 市場也變得越大. 對於 customer 來說, 將可以用更加便宜 (或者該說是更加有彈性) 的購買方案, 來獲得需要的 service.
同時在這樣的市場中, Long Tail 的效應可能會更加明顯, 因為新的 service 未必一定要搭配新的 hardware, 在目前的市場中受限於電子製造商, 使得我們要換 service 好像就一定要買新的 device, 手機就是一個很明顯的例子 (如果我可以把現在手機的 300 萬畫素攝影模組移到新手機, 我就不用買新手機的 600 萬畫素模組, 我只需要 300 萬畫素的就夠用了 ).

References

[1] Dirk Riehle, "The Economic Motivation of Open Source Software : Stakeholder Perspectives," IEEE Software, pp.25-32, April 2007

在說到 BUG Labs 之前, 先看看這張圖 (取用自 BUG Labs 公開可用圖庫) :


這張圖是什麼 ? 看起來有點像一些小積木疊在一起, 然後用線連著, 然後每堆好像長的不太一樣. 每堆中好像都有一個比較特殊的, 邊邊帶有灰色矩形的積木存在. 其他就不一定. 這是什麼 ?

身為 software scientist (it this term exist) 以及 hacker, 我們看到一個喜歡 software 時往往會首先想到兩件事, 第一是 : 這東西怎樣運作的, 第二個是 : 我要怎樣把他改成可以跟我手邊的其他 software 合作. 一般的使用者不會這樣想是因為, 一般使用者難以認識到內部的運作, 從而即便想了第二個問題, 也沒辦法用自己的能力讓想法實現.

而 BUG Labs, 就是想要讓這樣的事情變成可能.

BUG Labs 採用 Lego 積木的想法, 把 computer 拆解成數個方塊, 每一個方塊上具有一個或是數個 services, 例如 GPS 應用, 數位攝影機, Webcam, LCD 小螢幕, 或是鍵盤. 同時 BUG Labs 提供一塊小小的 motherboard, 讓你可以自由地把這些方塊插上去.

BUG Labs 的 product 網頁上給了一個例子 :

For example, with BUG, you can easily assemble and program a GPS + digital camera device that automatically publishes geo-tagged photos as a web service. Integrating with an online photo-sharing service like Flickr is only a few more lines of code away, and now you have your own real-time, connected traffic-enabled mobile Webcam!

這樣的想法並非全新, 至少在 software 領域, component-based software development (CBSD) 的發展已久, 即便是後來的 service computing 也預計會朝同樣的路走下去. 而在實際的產品上, 我記得已經有教育性的產品是透過 USB port 標準, 可以把不同的 software 事先安裝在 USB 上, 然後孩子用的主機不需要進行軟體安裝, 而是透過主機上數十個 USB port, 匯入不同的 softwares 共同運作. 但是相對來說 performance 就不適合一般使用.

而 BUG Labs 應該是在非教育領域, 第一個把這樣的概念具體化成為一般消費用商品, 並公開展示的公司. 歐, 我沒有提到更棒的是, 他們希望是採用 open source software / hardware 的概念來推廣.

在每一個方塊內當然會有相對的 software 可以提供 service, 同時也可能有必要的 operating system 在裡面. 不同的方塊之間基本上透過 OSGi 進行 communication. ( 但由於 OSGi 的 license 問題, 使得 BUG Labs 無法直接使用 OSGi 的 source, 否則對於他們的 open source 計畫會造成阻礙, 於是他們重寫了 OSGi 的 implementation [1]) 然而使用者並不需要了解這些, 使用者只需要把他們想要的某項 application, 所需要的方塊都插到 motherboard 上就好了.

需要知道這些的是 service developer, 可能是 open source community 的人, 也可能是 commercial company 的人. 透過 BUG Labs 提供的 motherboard 作為 platform, 開發者同樣是專注在本來他想提供的 service 就好, 其他的部分是從 BUG Labs community 內可以找到的其他方塊來提供. 這也是上面第一張圖所代表的意義之一.

然而看著上面第二第三張圖, 還是會有個疑問, 看起來只有四個槽, 如果需要安裝比較多的方塊, 怎麼辦呢 ? 我想這應該可以回到第一張圖, 誰說 motherboard 上不能再接 motherboard ? 或者我可以在不同的 motherboard 之間透過 wireless 連接溝通, 一樣可以應付需要更多方塊的情況.

然而 BUG Labs 是否能夠成功仍然有很大的疑慮, 我想他們選擇 open source community 作為主要合作對象應該也是希望可以解決一些關鍵問題. 提供以及制定 motherboard 倒不是問題, 而是這樣的使用方式基本上相對於目前主流電子產品來說有別. 目前主流電子產品製造權是掌控在電子製造商手裡的, 而且軟硬體都是. 看看如果你想改造 iPod, 會遇到哪些完全是非技術性的限制. 而 BUG Labs 的產品完全是顛覆 (disturb) 目前的產品線. 在 BUG Labs 的 vision 下, 消費者才是最終決定手上的 product 長什麼樣子的人 (軟硬體都是), 而非目前的電子製造商.

但顯然地, 這需要大量的軟硬體開發支援, 特別是 software 部分. 如果可以替換的 software service 太少, 則 BUG Labs 的 motherboards 是完全沒有意義的. 透過 open source community 的生產力以及創造力, 能夠幫助 BUG Labs 把他們的 motherboard 之可能性發揮到最大. 同時究竟消費者會希望 BUG Labs 的產品以什麼樣貌展現, 也正在進行調查中 [1].

在通往成功的路上, BUG Labs 還有很長一段要走. 但是以我們小小工程師的角度來說, 身為 BUG Labs 的一份子, 手上握著足以顛覆世界的想法以及產品, 真的是作夢也會笑阿 :)

References

[1] David Cohn@DigiDave, "Evolving from Larvae To Bug Lab: The Rise of Open Source Hardware," URL : http://www.digidave.org/adventures_in_freelancing/2007/11/evolving-from-l.html

雖然我是個平常用不到 bytecode inspection tool 的人, 不過今天因緣際會看到 reJ 這個 tool, 起了一點想法.

我們對於什麼東西都可以用 5W1H, who, when, why, what, where, how 來嘗試弄清該東西的本質, 而我就想問了, what kind of bytecode inspection tool do you actually need ? 以及 who else also need this tool ?

reJ 這樣說了,

There are various robust libraries/APIs available for bytecode manipulation, such as:

• BCEL - http://jakarta.apache.org/bcel/
• ASM - http://asm.objectweb.org/
• Serp - http://serp.sourceforge.net/
  

Each library has a slightly different focus. reJ uses it's own API which is focused to serve the needs of the user interface. The user interface with syntax coloring, search, compare and editing capabilities is something that is less readily available elsewhere.

關鍵句子出現了, "serve the needs of the user interface".

現在已經有很多強大的 bytecode manipulation library 出現, 尤其是 BCEL 跟 ASM, 基本上最近幾年在比較好的 software engineering conference / journal 上看到關於需要處理 bytecode 的 paper 都脫不了使用這兩個 tools. 在品質上顯然是受到信賴的.

然而 bytecode manipulation 終究只是技術的問題. 怎樣從 bytecode data 中挖出 information 並不該是身為 programmer 的我們需要花費最多關注的問題, 畢竟這是個一定可以被解決的問題. 我們更應該關注的是怎樣更有效率地挖出有意義的 information, 或者換句話說, bytecode inspection tool 要該要呈現什麼樣的 user interface 給 programmer, 才能夠讓 bytecode inspection 的動作有意義且有效率. 我相信 reJ 的那段話就是在嘗試說明此點.

User interface 在這裡並不單純指 software GUI 而已, 而是包含了 programmer 跟 bytecode inspection tool 之間的各種 operating languages. 透過 user interface 的設計, bytecode inspection tool 可以知道 programmer 真正想要的 information, 並且將之呈現給 programmer.

從 reJ 的 screeshots 可以看到這種努力, 雖然目前支援的 views 還很少, 但是這是以 service 的觀點來製作 bytecode inspection tool, 嘗試把 programmer 真正想要用的 views 帶進 software. (這不就是 service-oriented computing ?) 底下 screeshots 取自 reJ @ SourceForge.net.


也有其他的 tool 有類似的想法, 例如 jclasslib, 可以看到的 information 更多, 但是過多的 information 卻沒有整理成適當的 views, 一樣對於 programmer 來說是種困擾. 底下是 jclasslib 的一張 screeshot, 其他的 screeshots 可以在他的網站找到.

NetJaxer [1] 是一個方便使用者搜尋以及使用既有的 web 2.0 application 的 tool, 可以想成是一個 software RSS reader (?) , 或是網路書籤的 client 版, 會自動匯集新的 web 2.0 applications, 並根據 application 的應用以及受歡迎程度作分類.


看看 NetJaxer 怎樣說明他自己 :

NetJaxer is a free and easy way to integrate your favorite Web 2.0 applications right into Windows. Now, they are always just a mouse click away. NetJaxer combines a categorized and searchable web directory of 100's of Web 2.0 sites that works hand and hand with a free small piece of software you download to your computer's desktop.

這裡面看到了幾個關鍵字, categorized, searchable, 以及 works hand and hand.

在今年稍早 Richard MacManus 寫的 NetJaxer - a Web/Desktop integration product… but is it useful? [2] 文中提到了他向 NetJaxer 的 development team 詢問一些未來發展的規劃, 從回答看來的確似乎還舉棋不定, 但是從目前 NetJaxer 的敘述看起來, 似乎也不全然是沒有方向, 至少那個 works hand and hand 就很引我注意了 :p

在 Ajaxian 上的一篇文章 [3] 也說到 :

Imagine dragging a document into a GMail icon or having desktop notification that your buddy just logged in to Campfire...

在前幾天我剛好也寫到 Software Bundles 的 knowledge 觀點, 如果 NetJaxer 不只是提供目前依據應用以及受歡迎程度作分類的推薦方式, 同時可以提供 有效率地串聯這些 applications 以滿足某特定目的 的使用方式呢 ? 那麼 NetJaxer 就不只是一個可以提供 categorized applications 以及 search applications 的 tool 了, 而是一個 application composition utilization knowledge sharing platform 了. (應用軟體整合知識分享平臺--什麼跟什麼阿)

更甚而, 如果不要把 application 當作最小單位, 而是再把 application 拆解成為數個 services, 那麼實際上進行的其實是對於 web services 的串聯以及分享, 也就是 web services composition utilization knowledge sharing -- 越來越長了.


總之, 我只是想說 NetJaxer 是個蠻有趣具有潛力的 tool. 不過 service-oriented computing 相關研究最近幾年才開始快速展開, 對於 service selection 以及 composition 的議題都還在研究中, 加上目前的 web applications 所形成的 services 概念跟形式都與早期的 web services 有些不同, 不知道 NetJaxer 能夠利用多少具體的成果就是了.


References

[1] NetJaxer, URL : http://www.netjaxer.com/
[2] Richard MacManus, "NetJaxer - a Web/Desktop integration product… but is it useful?" URL : http://blogs.zdnet.com/web2explorer/?p=147
[3] Michael Mahemoff, "NetJaxer: Web-Desktop Integration," URL : http://ajaxian.com/archives/netjaxer-web-desktop-integration

lazybuntu [1] 是國內著名 bbs/web browser 軟體 PCMan 的作者(也叫 PCMan :p)發起的計畫, 就如同其他 lazyxxx 計畫一樣, 是希望透過把常用的, 好用的 softwares 綑綁在一起(software bundle), 並設定好在特定 platform 上的安裝設定以及 package deployment, 使得在該 platform 上的使用者可以快速地安裝好必要的 softwares. 當然會這樣作的原因也包含了在原來的 distributions 中並未能夠考慮特定區域的使用習慣來決定內建的 packages 支援, 或是因為 packages 太多反而讓一般使用者不知道怎樣選取.

相似的東西, 最近國內比較 hot 的應該是 lazyeeepc [2] 吧, 而我之前為了求方便分別在 Linux 以及 Windows 上也使用過的 XAMPP [3] 也算是類似的東西. 但是我認為從 information & knowledge engineering 的角度來看, 這些 software bundles 之間還是有所不同.

如果只是從 把常用受歡迎的 softwares 一起包裝起來 的角度來看 software bundle, 那麼 software bundle 其實可以被看為是一個 packaged information aggregation. 在此 aggregation 內, softwares 是以特定的關係被 connect 在一起, 但是這樣的關係只會是 在同樣 platform 上的關係, 或是跟某個 programming language 相關等等的關係, 並沒有包含這些 information 怎樣以有方向性的關係作連結的資訊.

以 XAMPP 的例子來說, 有意識地選用了特定的 software 組合, 意味著完成 XAMPP 的 developer 認為這樣的組合在他的使用經驗中具有某種優勢, 這樣的組合是對於他來說是有意義的. 而有意義意味著對於 Information 的認知能夠提供他使用上的某種經驗, 於是 Information with Meaning 就變成了 Knowledge.

更甚而可以形成某種解決問題的 pattern, 擁有合適的 context description, 以及使用此 software bundle 時需要考慮的 forces, 使用後的 consequences 等等, 這就已經不再只是 information aggregation 的 level, 而是把 software bundle 作為一種 knowledge sharing 的手段了.

以 lazybuntu 來說, 其實蠻有淺力往這邊走的, Ubuntu 的使用者多, 在 Ubuntu 上的 applications 也多是兩個主要的原因. 但是要以怎樣的 format 讓 contributers 可以在 lazybuntu 上分享自己的 "knowledge" 倒是一個難題. 特別是所謂的 knowledge 是可以包含各種使用方式的, 像是 Apache 雖然是 web server, 但是我也曾經把他跟 Trac 綁在一起用, 原因只是為了利用 Apache 的密碼加密模組.

當我們可以把 software bundle 完完全全視為一個被 share 的 knowledge 時, 或許到時看到的就不再是 software 的 composition (或說是 component composition), 而是現在正開始熱的 service-orientation 的角度了. 到時我們看的不是一個一個的 softwares, 而是看到 softwares 經過適當的組合, 經過使用的測試, 匯集使用的經驗, 所提供出的 services.


References

[1] lazybuntu, URL : http://lazybuntu.openfoundry.org/
[2] lazyeeepc, URL : http://yurinfore.blogspot.com/2007/10/lazyeeepc-001.html
[3] XAMPP, URL : http://www.apachefriends.org/zh_tw/xampp.html
[4] Michael Negnevitsky, Artificial Intelligence : A Guide to Intelligent Systems, Addison-Wesley, 2001

我對於 Jini 的 capabilities 以及 architecture 之認識主要依靠閱讀 Jini Architecture Specification [1] 以及Jim Waldo (Sun 資深工程師, Jini 的主要發明者之一) 在 1999 年發表於 Communications of the ACM 上的一篇文章 [2].

The Goal of Jini

引用 Jim Waldo 在 [2] 文章一開始的一段話 :

The Jini™ architecture exemplifies a new approach to computing systems—making the network the central connecting tissue. By replacing the notion of peripherals and applications with that of network-available services and clients that use those services, the Jini system breaks down the conventional view of what a computer is, while including new classes of devices in a unified architecture.

可以看出Jini 的理想是跳脫目前的電腦架構, 而在目前的基礎之上, 建構一個以 Service 為單位, 基於 Network, 只存在 Services 與 Clients (Users) 的世界.

The Reality of Jini

然而 Jini 以開放的 Specification 來看並未真正完全具備實現理想世界的完整能力. Jini 的主要能力仍是以 Service Lookup 為主, 也提供 Service Registration 以及 Leasing 的特性. 其中 Leasing 機制可以視為一種極為簡單的 Service Negotiation. 另外一個令 Jini 與目前既有的 Service Middleware 極為不同的特點是, Jini 有 Mobile Code (Code Mobility) 的概念. 此概念為跳脫傳統在 Service 與 Client 是只有單純的 Data 傳送的方式, 而把 Code 也視為 Data 進行傳送. 這樣一來 Services 之間的 coupling 將更低, 同時更能更應付一個快速變化的網路環境 (Changing Network). 此特殊的能力事實上是建構在 Java 本身統一利用 JVM 執行程式, 以及 Java 的 Security 特性上. Jini 的真正意函在於 Jini Specification, 而利用 Java 作為實現只是一種選擇, 然而其他語言是否能夠實現 Jini Specification 就不一定了.

在所查到的相關資料中, 大多將 Jini 的 limitations 歸因於下列幾點

1. Network-Centric [3]
1. need a central server [3][5]
2. TCP/IP based [5]
2. Architecture Base
1. based on conventional distributed system [3]
3. Java-based [4]
1. JVM limitation [3][5]
2. Java RMI limitation [3][5]
   

如果單以 Jini architecture specification 的角度來討論, 唯一可能留下的應該只有 need a central server 以及 based on conventional distributed system 兩點. 其中需要 central server 此點會使得 Jini 在某些環境下比較難以實現, 例如 pure Ad Hoc 環境, 或是缺乏 central server 的 P2P 環境. 而 based on conventional distributed system 這點在 [3] 中則是認為會導致 Jini 需要 statically configured infrastructure 來完成 service discovery, 這跟 need a central server 是一樣的意思, 另外就是 Jini 將會需要一個足夠穩定的網路環境 (well-behaved computing environment) 以便進行 RMI 的運作, 滿足 transparency 以及 synchronization 的需求.

而餘下的 limitations 我認為其實跟 implementation 的選擇相關比較大. 比如說 TCP/IP 的依賴性問題, 在 Jini 原先的 implementation 中僅支援 TCP/IP, 但是根據 specification 可以進行適當的擴充, 以支援其他不同的 protocols, 在 [5] 有參與討論者說明自身的相關計畫經驗. 同樣的, 與 Java 相關的 limitations 可以藉由選擇不同的語言實現 Jini architecture specification 解決.

再者, 如果回到 Jini 原先的理想下, 那麼其實 Jini 還有著更多的 limitation, 包含在目前 service oriented 環境中要求的各種 service management 能力, 諸如 service broking, service negotiation, service mediation, service billing, service composition, service security... [6] 等等, Jini 都有許多尚未能滿足的部分.

The Rise and Fall of Jini

下圖說明了我認為 Jini 的 rise and fall. 但因為其中的許多部份沒有查到確切的年份資料, 因此我僅是簡單地照我的猜測及推想擺放相關方塊的位置.


首先是 Jini 的開始開發以及第一個版本的 release. 根據相關的文章可以看出 Jini 在當時引發的熱潮. 而這時有個意外的插曲, Sun 的 marketing 把 Jini 說小了, 沒有完整地呈現出 Jini 的理想, 或許這是為了單純的 marketing 考量, 此點在後來採訪 Jim Waldo 的文章中也有提及[7]. 我認為這點在某個程度上使得 Service-Oriented Computing 沒有更早獲得重視與劇烈發展.

而在 Jini 於市場上取得短暫的成功後, 怎樣維持接續的發展以及強化 Jini 的能力是最重要的事, 單純只有 service lookup 顯然是不夠的. 在這裡我想同時受到幾項因素影響 Jini 的發展. 首先是同一時間 Java 本身也在 J2SE 以及 J2EE 領域取得巨大的成功, 相關的應用及計畫大幅展開, 此段時間內想必 Sun 本身也是忙的不可開交. 對照同時間的 J2ME 發展, 幾乎呈現停擺狀態. 另外如上述說的 Service-Oriented Computing 的想法還不成熟, 許多 Jini 可以沿深加強的方向都還沒有較為成功的研究成果出現. 另外有一個我認為很重要的因素, 在於 Sun 在 Jini 最初 release 不久後開始緊縮 license, 以 Sun Community Source License (SCSL) 授權, 直到 2005 年才開始分別釋放部分程式碼改為 Open Technology License 以及 Apache License [9]. 我認為這無形中對於 Jini 在 Open Source Community 以及 Commercial Company 的發展進行了侷限, 許多基於 Jini 的可能性無從發展 [8], 進而影響後續對於 Jini 是否能夠制定一個 standard 以及 Jini 應用的 promotion.

而對於 Sun 以及Jini 來說, 最大的玩笑或許是 Web Services 的崛起. Web Services 使用 XML-based Remote Procedure Call (XML-based RPC), 相對於 Jini 的理想來說其實有點開倒車.然而在之後的兩年之間, Web Services 的熱潮完全掩蓋了 Jini 的光芒. [10] 的作者認為原因可能是 Web Service 相對的 simplicity. 我覺得應該反過來說, 是 Jini 還沒有達到應該有的 simplicity.

縱使如此, 不管怎麼說, Web Service 的熱潮也逐漸退了, 取而代之 Service-Oriented Computing以及 Middleware-based Software Engineering 看起來正要開始快速發展, 因此我想我同意 Jim Waldo 說的, 許多真正有用而強大的概念是需要時間成熟及驗證 [7], 過早斷定 Jini 已經不行了是不必要的, Jini 仍有大好的機會捲土重來.

References
[1] Jini Architecture Specification, URL : http://www.jini.org/wiki/Jini_Architecture_Specification
[2] Jim Waldo, “The Jini Architecture for Network-Centric Computing,” Communications of the ACM, vol.42, no.7, pp.76-82, July 1999
[3] Robert Grimm, Janet Davis, Eric Lemar, Adam Macbeth, Steven Swanson, Thomas,erson, Brian Bershad, Gaetano Borriello, Steven Gribble, and David Wetherall, "System Support for Pervasive Applications," ACM Transactions on Computer Systems, vol.22, no.4, pp.421-486, November 2004
[4] J. Allard, V. Chinta, S. Gundala, and G. G. Richard III, "Jini Meets UPnP: An Architecture for Jini/UPnP Interoperability," Proceedings of Symposium on Applications and the Internet, pp.268–275, 2003
[5] Limitations of Jini Technology, discussion thread at Jini mailing list, URL : http://osdir.com/ml/java.sun.jini/2004-10/msg00199.html
[6] Dan Jong Kim, Manish Agrawal, Bharat Jayaraman, and H. Raghav Rao, "A Comparison of B2B E-Service Solutions," Communications of the ACM, vol.46, no.12, pp.317-324, December 2003
[7] Janice J. Heiss, "Jini Network Technology Fulfilling its Promise: A Conversation with Jim Waldo," March 2004, URL : http://java.sun.com/developer/technicalArticles/Interviews/waldo_qa.html
[8] Eric S. Raymond, "Open letter to Sun: Let Java Go," 2004, URL : http://www.catb.org/~esr/writings/let-java-go.html
[9] Licensing of Sun's Jini Technology, at Sun official website, URL : http://www.sun.com/software/jini/licensing/
[10] Berco Beute, "Universal Plug 'n Play: Jini's ex-rival back from the dead?" 2004, URL : http://www.artima.com/weblogs/viewpost.jsp?thread=48801