Software Cinema

我對於 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

Embedded System

在過去對於 embedded system 的認定或是說明 (在此我避免用 定義, definition 這 個辭, 因為嚴格來說我認為沒有被 well-accept 的定義), 大多是利用一些特徵來描述 embedded system, 例如功能專一性 (not general purpose), 資源有限 (limited resource), 可用記憶體有限 (memory constraints) 等等各種 hardware constraints, 另外就是具有 hardware / software co-design 的特徵(不過這屬於逐漸被拋棄的一個領域), 可以進行操作的介面通常都很小等等. 總之就是把 embedded system 跟許多 hand-held device 或是家電 IA 畫上等號. 最常見的就市直接跟桌上型 PC 作比較, 像是 PC 這種運算快, 記憶體多, 體積大, 多功能用途的電腦系統就不是 embedded system, 反之大概就是. 這種概述大概是過去十幾年來對於 embedded system 的共通印象. 而對於資訊相關的學生來說, 因為講到 embedded system 開發好像就是一定要在一塊裸板上燒 ROM, 或是利用封裝好的小型主機, 外接螢幕什麼的, 好像不是這樣開發的就跟 embedded system 無關似的. 而所謂的 embedded application 當然就是在這樣的環境下可以執行的 applications 摟.

但我並不認為時至今日, 對於 embedded system 的認知應該維持過去的想法. 重點在於 embedded 這個字. 引用 webster's dictionary, rosetta edition 對於 embedded 這字的說明為 :

1. Enclosed firmly in a surrounding mass

2. Inserted as an integral part of a surrounding whole

embedded system 也只是一種 computer system, 而因為他所具有的特徵使得我們特意冠上 embedded 這個字. 但是如果是因為各種 hardware constraints 而冠上 embedded, 對照 embedded 這字本身的意思, 不是很怪嗎 ? 因此我認為, 對於 embedded system, 應該從別的角度來詮釋.

既然我們說 computer system 的目的, 其實終究還是希望可以幫助人類的生活過的更好更輕鬆, 是整體社會文明的一種進步. 因此在此我把上述對於 embedded 釋意文字中的 surrounding mass 以及 surrounding whole 對比到 human life. 換句話說, 所謂 embedded system 事實上是指能夠 embed 到 human life 的 computer system.

在此認知下, 一般熟悉的 PC 自然就不被涵括在裡面. 的確, PC 在很多人的生活中都會出現, 很多人每天也一定會使用到 PC, 但是 PC 有很顯然地融入一般人的生活中嗎 ? 恐怕是沒有吧, 大多數常接觸的人要不就是 PC Gamer, 否則還是以工作接觸居多, 這種情況就變成是刻意去接觸利用, 而不是嵌入或是融入我 們的生活之中. 當然, 我必須承認, 這樣的認知與區隔並不是很嚴謹, 或許仔細想還是可以找到介於是與不是之間的例子. 比如說手機就是一個. 對於現代人來說, 手機或是其他通訊設備幾乎就是融入生活的一部分, 然而當我們說到多功能的智慧型手機, 或是所謂的 Smart Phone, UMPC 等等, 其所提供的服務, 似乎又不是那麼地融入我們的生活了. 這種情況我就認為他既是也不是摟, 換句話說就要看你所持的觀點而定.

我的認知可以下面的概念圖表示. 圖中的 application software 以及 embedded application software 指的僅是 software 部分, 而整體的運作還需要加上更底層的 hardware. embedded application software 在添加 hardware 部分後構成一個 embedded system. 而此 embedded system 所達成的服務應用則是 embedded application. 兩者的差異即在於 Unawareness of Users 的考量範圍. 在 embedded application 的情況中, 需要設法達成讓 users 感覺不到 embedded application software 的存在.


而我上述的認知跟過去對於 embedded system 的認知之間的關係如何呢 ? 我認為過去從 hardware constraints 的角度去區別 embedded system 與否其實也沒有錯, 因為要符合上述我的說法, 將會使得 embedded system 所處的環境面對較多的限制, 例如機體大小等等, 自然而然就會形成各種 hardware constraints. 但是這點在硬體開發技術以及製程逐漸進步, CPU 處理速度越來越快, 同體積的記憶體效能 (Performance) 越來越好的情況下, 過去與桌上型 PC 相比的 hardware constraints 只會隨著時間逐漸的消失, 因此再也不適合用來區別 embedded system 與否.

最後一點, 則是關於上文中不斷提到的 融入 . 這也是之所以沒辦法有嚴謹定義的原因. 所謂融入跟人本身, 以及人所處的環境 (context) 會有關係. 人本身包含了生活習慣, 而環境則包含了文化 (culture) 因素. 這些都是會逐漸演進的 (evolve). 換句話說, 對於 embedded system 與否的認定, 會隨著整個社會環境的逐漸電子化而有所改變. 而如果對於 pervasive computing 或是 ubiquitous computing 略為知曉的人, 可能又會覺得好像沒什麼不同. 這樣說吧, 我認為 embedded system 就是 pervasive computing 或說 ubiquitous computing 的基礎構件之一, 而後兩者所描繪的是 global vision.

Embedded Middleware

而在 embedded middleware applications 的部分呢, 我認為 embedded middleware 跟一般的 middleware 不同處在於 middleware 所要代替 applications 面對的對象, 擴展到了使用者. 已下面的概念圖表示我的想法.

在我的想法中, embedded middleware 除了與一般的 middleware 一樣會需要替 embedded application software 處理面對不同的 operating systems, network, 以及 resource management 等相關問題之外, 還存在於 user 與 embedded application software 之間, 而所負擔的責任即在於降低 developer 設計與實現 embedded application software 時, 需要考量到不同的 users 在不同 context 下的使用問題. 因而有別於一般的 middleware software, user interface (UI) 在 embedded middleware 領域中佔有較重要的份量及地位.

這個想法是從 Code Snippet 來的, Code Snippet 簡單來說就是一個片段的可重複利用 (re-use) 程式碼, 通常會是利用 copy-n-paste, 加上適度修改的方式利用. ( 在這裡我刻意用可重複利用: re-use 而非可重用: reuse , 因為這兩者有本質上的差異, Code Snippet 應該算前者而非後者 )

Paper 開始寫多了, 被老師改的次數或是送外國人改的次數多了, 就會感覺被改過的句子其實是自己本來想寫出來的感覺, 但是限於腦子裡的英文程度, 總是沒辦法較為準確有效率的自己的意思, 總是只能用比較簡單的辭彙跟片語堆積出好幾句, 還沒有別人用一句說的清楚. 這種情況對於撰寫 Introduction, Related Work, 以及說明清楚自己要解決的問題時非常不利.

之前在 ptt 看到 CCY 學長說他會把看到的 paper 內寫的好的句子 copy 留下來, 之後有需要就可以套用, 再稍作修改. 其實這就跟以前背英文句子或句型一樣, 只是那要用人腦去記憶, 沒有背到很熟不容易使用...就算背很熟可能也反而會妨礙使用.

現在覺得自己好像也有必要這樣做了, 姑且把這種剪下來的 Sentences 叫做 Sentence Snippets 吧, 畢竟他也不算是大家或專家公認的佳句, 只是同領域的 papers 裡看到覺得寫的不錯, 可能以後會派上用場的句子.

雖 然不知道 CCY 學長如何管理他的 Setence Snippets, 但是直接 copy 下來保存一定不會是個有效率的使用方法, 適當的分類管理方法還是必要的. 可能用 faceted classification 或是 tag system 去作分類還可以吧, 只是要花點人工就是了, 同時使用的 tag 可能需要是中英文並用的, 比較能配合寫 paper 時的思考模式, 然後直接用 blog 紀錄, 應該也會蠻方便的. 恩...再想想好了.

That's what I think about Wii Fit : A Possibly Successful Application of Wearable Devices.

Wearable devices, 或是更廣義的說, wearable computers, 的概念已經存在很久, 不過對這種起源的歷史討論我向來沒什興趣, 參考 Wikipedia [1] 就罷.

Anyway, wearable devices 過去在學界, 主要是分散在 pervasive/ubiquitous computing, smart home, medical devices, military 等應用中, 事實上也取得了相當的進展. 因為我的 thesis 跟 context-awareness 以及 smart home 有關, 當時(一年多以前)也 survey 了很多發表的成果, 在各種可以對人們作 profiling 的 devices 上其實都已經可以有 product 出來. 但是實際市場上就是沒有大公司率先推出. 那時我就在猜原因, 想來想去除了市場推廣因素也想不出其他的原因來.

沒想到在 "正當" 的用途之外, wearable devices 居然在 game 領域可望率先取得成功了 :p

當然我說的成功指的是能夠在市場快速地達成一定的佔有率, 而非只是能夠開發出產品而已. 在 Wii Fit 準備推出後, 這樣看來其實就很清楚了, Wii 其實只是探路的棋子, 任天堂 (Nintendo) 可能打算藉由 game 領域為出發點, 快速擴大市場佔有率, 然後由 game 反攻上述各種應用, 包含 smart home, medical 領域. 像是 Wii Fit 廣告中已經有的各種應用軟體, 事實上就是觀照你身體健康的目的. 當然目前許多批評者認為, 實際運動效果其實不大, 但承認吧, 多少該有的效果還是有的. 況且 Wii Fit 也沒叫你一整天玩他就好, 出外運動跟玩 Wii Fit 並非互斥的選項. (以下影片引用自 YouTube)




等 Wii Fit 的其他配件再推出來, 例如感應手腳動作, 甚至頭部動作的配件, 看起來就更像早期研究者對於 wearable devices 的想像了.

這樣一來, 嘿嘿, 其實空間更大的是 software. 基於 Wii Fit 可以蒐集的資訊, 建構於 Wii 平台上的 software 可能發生的應用太多了. 希望任天堂公司別像 Apple 一樣, 把 Wii 平台開放出來吧, 這對於 Wii 的未來以及市場銷售絕對是有利的阿. 但在這之前, security 的問題絕對是十分十分地重要.

相對於任天堂的策略, Sony 跟 Microsoft 就採相反的做法, 他們都太執著於那台主機本身, 希望 customer 先坐著接受主機, 再來接受延伸的應用. 如果 wearable devices 的市場就此開發出來, 人們的電腦使用習慣因而改變, 任天堂應該會在歷史上再添榮光 :)

不過, 就像我標題寫的, 這只是可能而已, 變因太多了 :p

References
[1] Wearable Computers at Wikipedia, http://en.wikipedia.org/wiki/Wearable_computer