　もともとDBusは、デスクトップ環境とGUIアプリケーションとの間における通知ややりとりを円滑に行うためのプロトコルだった。最近では、デバイスのリソースをユーザーランドへ提供するインタフェースとして利用する事例が増えている。恐らく、この試みを最初にはじめたのは、Bluetooth機器を管理するデーモンであるBluezだと考えられる。Bluetooth機器をアプリケーションから利用するには、ペアリングや、他のアプリケーションがBluetooth機器とペアリングしているかの確認など、やるべきことが多くなる。デバイス開発者とアプリケーション開発者の間での確認事項が増えてしまい、コミュニケーションに掛かる負担が非常に大きくなる。

　そこで、bluezがBluetooth機器のリソースを管理して、DBusのAPIを提供することにより、デバイス開発者とBluetooth機器を利用するアプリケーション開発者に掛かる負担を減らせるようになった。Bluezに影響を受けたデーモンの例としては、NFC（近接無線通信）デバイス向けの「Neard」などがある。

プラグイン方式

　Linuxと付き合っていく上で最大の懸念はライセンスだ。プラグイン方式の採用により、この懸念が払拭（ふっしょく）され、ベンダーが参入しやすい環境が整えられてきている。

　オープンソース――というより、GPLを採用しているソフトウェアの開発はソースコードの公開義務があるため、ベンダーは及び腰にならざるを得なかった。こういったライセンス問題を回避する手法として、コアとフレームワークはオープンソースにし、プラグイン方式で機能を追加する手法を採用するプロジェクトが増えている。

　プラグイン方式は構造が複雑になるのでデバッグの負担が増えるというデメリットがある。その一方で、クローズドなプラグインを開発できるのでベンダーは参入しやすい。また、プラグインのインタフェースが不足する場合は、コアやフレームワークへ機能を追加する必要が出てくるので、クローズドの開発でありながら、オープンソースプロジェクトに貢献する可能性もある。

　ここまで列挙したTizen IVIのコンポーネントは、UIと機能の切り離しとプラグイン方式を採用している。

　Tizen IVIとは直接関係はないが、Linuxと付き合って行く上で、この2つの手法は念頭に置いておくとよいだろう（もちろん今後変わる可能性はあるけれども……）。

「Tizen IVI」のコンポーネントについて

　Tizen IVIのコンポーネントの詳細に興味のある方は、「Intel Open Source Technology Center」のWebサイトにアクセスしてみてほしい。

対応プロセッサと製品開発状況

　Tizen IVIが対応するアーキテクチャとしては、バージョン1.0であれば、Intelが推進するx86プロセッサの他に、「Pandaboard」などに搭載されているARMプロセッサでも利用できた。しかし、バージョン2.0以降は、x86向けに開発を集中することになっている。バージョン3.0でも、x86に注力する方針は変わらない。

　Tizen IVIは、バージョン2.0でHTML5プラットフォームを志向し、バージョン3.0ではディスプレイマネージャーとしてWaylandを選択した。アーキテクチャが大きく変更されているので、製品開発を検討しているのであれば、バージョン3.0から始めるのが賢明だろう。

最後に

　矢継ぎ早ではあったが、Tizen IVIのバージョンアップによるアーキテクチャ変更の流れや、特有のコンポーネントについて解説させていただいた。Tizen IVIが、Tizen mobileをベースにして独自色を出そうと試行錯誤するさまと、Tizen mobileよりもHTML5に注力していることが伝われば幸いだ。

　今回、Tizen mobileがベースとなっているアーキテクチャの解説は省略している。Tizen mobileやTizenそのもののアーキテクチャの詳細について興味のある方は、筆者がWeb上で公開している資料（http://www.slideshare.net/TNaruto/tizen-24482878）で補完していただければと思う。