移動微件
出自 MBA智库百科(https://wiki.mbalib.com/)
移動微件(Mobile Widget)
目錄 |
移動微件是在移動互聯網領域對微件技術的提升和應用，同時受到運營商、終端廠商、平臺廠商和應用軟體提供商、內容提供商的重視，是因為它可以滿足產業鏈上不同角色的需要。從運營商角度看，移動微件可以作為業務運營的一種良好方式；從終端廠商角度看，移動微件可以用於增加其終端的可定製性；從平臺廠商角度看，移動微件可以作為其控制終端桌面，從而實現控制用戶的一種方式；從應用軟體提供商來看，移動微件易於開發、易於部署的特性使其成為應用開發的較好平臺；從內容提供商角度看，移動微件是開展內容服務的較好通道。
移動微件的實現方案[1]
雖然移動微件的實現方案很多，但是從標準化的角度來說，真正具有標準化前景的方案有四種：W3C方案、OMTP BONDI方案、諾基亞的WRT方案、中國移動的JIL Widget方案。
自2006年起，W3C開始制定Widget草案，目前由Web Applications( WebApps)Working Group負責。
圖1是一個典型的Widget架構（源於W3C），最下一層稱為主機運行時環境，通常是一個軟體引擎，或提供功能的網頁瀏覽器。大部分的環境主機運行時，通常會支持HTTP、IRls、Unicode、HTTP．以及ECMAScript/JavaScript、CSS、DOM，其中還包括為了展現多媒體資源需要的支撐技術。
各規範的內容大致如下：
(1)《Widgets l.0: Requirements》：針對打包、配置文件、程式語言介面、用戶體驗、安全與數字簽名等內容提出Widget總體需求。
(2)《Widgets l.0: Packaging and Configuration》：涉及到資源文件的文件類型、內容、路徑，打包方式，描述文件元數據等；規定Widget需用ZIP演算法打包，並使用wgt作為文件擴展名；配置文件需用統一的文件名：config．xml，放在Widget包的根目錄下；併進一步規範了配置文件所應使用的源數據及其語義：Widget, name, description, author, license, icon,content, feature, param, preference。
(3)《Widgets l.0: Digital Signatures》：數字簽名用於驗證Widget包的完整性，需使用signaturel．xml作為文件名，放在Widget包根目錄下；並同時規範用戶代理對簽名文件的處理流程。
(4)《Widgets l.0: APls and Events》：定義Widqet對象提供給應用程式（如jacascript腳本）調用的介面，具體包括一個Widget介面，其中包含如下屬性：viewMode, locale, identifier, authorName,authorEmail, authorHref, name, description,version，width，height，preferences。如下方法：onmodechange, hasFeature, openURL,getAttention, showNotification。
(5)《Widgets l.0.: Access Requests Policy》：定義預設情況下的安全策略、安全聲明格式以及對安全事件的處理流程。目前尚無實質內容。
(6)《Widgets l.0: Updates》：定義了Widget更新需使用統一命名的update．xml文件名，並規範了此文件中需使用的元數據和更新處理流程。
(7)《Widgets 1．O：URI Scheme》：規範化Widget內部所使用的URI的語法和模式，目前尚無實質內容。
2009年7月3日，W3C DAP工作組(Device APlsand Policy Working Group)成立。DAP制定終端側API，通過這些API，互聯網應用和微件(Widget)能與終端提供的服務交互，如日程、地址本、攝像頭等。同時，該工作組還研究制定安全框架，該框架管理對API的安全訪問／調用。
應該說，由於W3C在互聯網領域以及Web標準制定上的權威性，W3C的標準是最具有指導價值的。但是，由於W3C標準需要廣泛征求各方建議，充分吸納各種輸入文稿，所以其制定速度較慢。因為草案較多，制定的內容也比較全面，因此至今仍未發佈關於Widget標準的正式國際規範。
此外，對運營商採用Widget開展業務來說，由於W3C並未規定相關的平臺側技術要求，可能會造成具體運營時的困難。在具體的API定義上，W3C也處於起步階段，這是影響Widget可移植性的主要因素，如果W3C標準要進入實際運營環節，還有很多工作要做。
OMTP是由國外8傢具有影響力的移動運營商組成的聯盟，致力於移動應用的編程介面的標準化工作，針對Widget成立了BONDI項目，包含如下兩項規範：
(1)《BONDI: Interfaces》：移動設備底層能力調用介面的標準化。
(2)《BONDI: Architecture_Security》：移動設備底層能力調用的安全架構。
OMTP將來打算將BONDI項目形成的規範推向W3CWidget，已於2008年8月與W3C簽訂了備忘錄。因此可以認為OMTP BONDI與W3C Widget是相互兼容的。
BONDI由幾個相關的規範組成。
API規範——一組生成HTML頁的BONDI APls的語法和語義定義。
安全策略規範——安全策略的一個互操作的×ML描述，定義訪問一個特定Web應用和Widget所需的BONDI APls。
開源的參考實現(Rl) -有關介面和安全規範應該實現的一個實際的、具體例子， Rl SDK包含API文檔和代碼。
BONDI工作組要確定的規範必須提交W3C和OpenAjax聯盟審閱和修訂。
OMTP BONDI已經正式提交給W3C作為Widget API的輸入文稿，這表示BONDI和W3C的工作會逐步走向統一。
雖然BONDI的參與者眾多，但是其產品化推進一直沒有得到太多的重視，導致其介面定義雖然完整，但是真正實現BONDI的廠家較少，不利於其推廣應用。
諾基亞於2007年8月24日發佈了在S60平臺上的Widget引擎並且宣佈在其未來所有發佈的S60手機都將支持自己的Widget產品。Widget的運行基於Web Run-time（以下簡稱WRT）。WRT是S60 SDK 3rd EditionFeature Pack 2中新增加的瀏覽器組件。它是一個Web應用開發環境。
Nokia Widget的使用方式與S60本地應用一樣。作為Widget的運行平臺，WRT設計目標之一就是使Widget與S60平臺進行無縫集成，給用戶一致的使用體驗。例如，每個Widget都可以在應用程式菜單中顯示圖標；可被設置為待機狀態下的快捷鍵和左右軟鍵；能出現在活動應用列表中；具有與現有的S60應用一樣的管理方式，如安裝、卸載等等。由於功能簡單，WRT占用資源較其他Widget引擎要小。同時，由於WRT是基於S60瀏覽器環境構建，技術相對較成熟，對資源的利用效率也較高。
從標準的角度來說，諾基亞提供了以下輸入文稿到W3C，作為W3C DAP組的起草文件：Nokia´s calendarAPI, Nokia´s camera API, Nokia´s contacts API,Nokia´s messaging API, Nokia´s System Info API,Nokia´s DeviceException Interface。
整體上說，OMTP和Nokia都是W3C成員．OMTP正在將其BONDI規範，Nokia也正在將其JavaScript API規範提交W3C供討論。
BAE是中國移動主導的，面向移動互聯網的、開放的、跨終端操作系統平臺應用運行環境。它基於開放的瀏覽器技術，為移動互聯網應用提供了跨平臺的運行環境，為開發者提供基於標準Web技術開發移動互聯網應用的基礎，降低了手機終端應用和業務的開發和部署難度；為終端用戶在手機終端上提供移動互聯網全新體驗。目前，BAE支持JIL Widget格式（中國移動與沃達豐、軟銀、Verizon共同定義、遵循的Widget標準），同時兼容部分互聯網上流行的Widget，如Apple Dashboard Widget等。
JIL Widget的特點是提供一套可產品化的參考實現。同時，JIL Widget項目也在與移動軟體開發商、設備製造商的戰略合作，推動豐富的產品開發工作。更進一步，JIL Widget也會提供相應兼容性測試工具。另一方面，JIL Widget標準化的工作重點是推動個人及第三方的Widget開發工作，構建一個開放的、全球化的開發者社區。JIL Widget希望通過以上這種方式來建設一個較為完整的、能夠商業化運營的移動Widget產業環境。
從技術層面上來講，JIL和BONDI的API定義各有特色，但是JIL更加重視產業化推進，配套開發工具和開發包等比較完備。
JIL Widget的主要特點是運營商主導，推進迅速，但是其並沒有納入W3C規範，即沒有正式向W3C輸入文稿，在具體的API定義方面也與W3C的路線有衝突，該方案能否在全球範圍內取得成功，還需要時間的檢驗。
移動微件業務發展策略[2]
從移動微件業務本身來說，支持何種形式的應用都有可行性，但是技術畢竟有其局限性，除去標準化的因素，結合運營商自身的需求，找準移動微件最適用的業務形式，是移動微件業務成功的關鍵因素之一。這裡重點考慮兩方面的問題：一是移動微件從技術角度來說適用的應用形式；二是移動微件如何與其它業務相結合。
從技術角度來說，移動微件對複雜邏輯的處理能力有限，因此難以用來開發較為複雜的本地應用，如大型游戲等，至少在現階段仍是如此。從微件簡單易移植的特性來說，更加適合信息類的應用，以及對現有應用進行UI優化或者集成的方面，除簡單的天氣預報、新聞類業務外，可以重點考慮話費查詢、影音播放等邏輯較為簡單的業務，以及開展廣告等後向收費型的推送業務。從移動微件與其它業務的關係來說，移動微件可以成為其它業務的良好承載形式，如將運營商常見的手機音樂、手機電視、手機郵箱等業務用移動微件的形式來提供，即可提高應用的可移植性，加快部署速度，也可以有更優化的UI和更靈活的界面佈局控制。從部署策略來說，移動微件常與應用商廈相結合，可以成為應用的一種形式。但是，移動微件在訪問控制上有更高的要求，特別是終端本地能力訪問控制上，比常見的應用有更好的控制力，因此移動微件也有自己的控制平臺，除通過移動微件引擎進行控制外，部分功能還需要與平臺聯繫來確定應用的訪問許可權。從發展的趨勢來說，移動微件的策略應該是與本地應用相混合，從形式上不再讓用戶區分是微件應用還是本地應用，也就是類似Palm在發展WebOS時的技術途徑，但是應用之間應該有相互調用的機制，以保證業務的一體化。
