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