Software Cinema

不知道為什麼, 關於 UPnP 比較有內容的文章好少, 而且可能因為剛寫完 Jini 的 review, 加上 UPnP 比較沒有我的愛 :p , 所以不知不覺變成用跟 Jini 比較的角度來寫了.

因為我打算一直累積這份 review, 因此 references 會連續, 部分 references 請參考 Jini 那篇.

What is UPnP

UPnP 由 Microsoft 所主要領導的 Universal Plug and Play Forum [11] 進行開發.

UPnP 本身其實是由許多 protocols 所組成, 意圖讓這些 protocols 成為溝通標準 (standard). 採用 UPnP 的 devices 等同於是同意使用一組標準的protocols 進行溝通. 從此點馬上可以看出 Jini 跟 UPnP 在標準化 (standardization)上的差異. Jini 試圖讓 Services 之間溝通的行為標準化, 也就是需要標準的 interface, 但是 data 格式是自由的. 而 UPnP 則是建立在近乎標準的許多 protocols 之上, 在 Services (或該說是 devices) 之間讓 data (或說是 message) 的格式標準化 (IP, DCP, UDP, HTTP, HTML, XML), 因此 Services 溝通時, 需要假設對方知道溝通用的 protocol. 也因此 UPnP 需要採用 XML 作為 service description (SOAP) 以及 service control (Device Control Protocols) 的主要工具, 因為他不像 Jini 具有 mobile code 的能力.


Comparing the Success of Jini and UPnP

就 Jini 與 UPnP 的市場比較來說, 我認為其實很難看出來勝敗. 雖然說現在到處可以看到支援 UPnP 的 devices, 但是 Jim Waldo 說的也是有道理 [7], 他認為 Jini 事實上在業界有許多十分成功的應用, 只是基於商業考量, 這些成功的公司不會把此點曝露出來, 避免對手也採用同樣的技術. 因此雖然說有文章對於 Jini 與 UPnP 在各項具備的能力上作直接的比較 [12], 但是我認為其實這樣比較的意義性不大. 因為兩者所瞄準的是不一樣的目標. 然而如果都放置到 Service-Oriented Computing 的 context 下作比較, 我認為 Jini 要比 UPnP 來的有優勢, 給予 programmer 的 flexibility 較大, 且就所處的 layer 以及彼此的著眼點來看, Jini 是可以把 UPnP 合併進來的 (除去 License 的問題, Sun 可用 Java 來 implement UPnP [13] ), 相對來說 UPnP 就很難反過來把 Jini 合併, 即便是 [4] 的 inter-operation 做法也等同於是把 UPnP 變成 Jini 的底層 Service 溝通的支援方式之一而已.

References

[11] Universal Plug and Play Forum, URL : http://www.upnp.org/
[12] Jini and Universal Plug and Play (UPnP) Notes, URL : http://www.psinaptic.com/link_files/jini_and_plugandplay.pdf
[13] Larry Press, "The Post-PC Era," Communications of the ACM, vol.42, no.10, pp.21-24, October 1999