　技術的に見ると、Ultra LightはSQLiteのように、ライブラリで提供されるデータベースである。つまり、基本的にUltra Lightはアプリケーションの実行ファイルの中に組み込み、そのアプリケーションのプロセスの一部として動作するのである。データベースのプロセスが独立して立ち上がり、クライアント／サーバモデルを実現するものではない。

図1　Ultra LightとASAのアーキテクチャ

　ここで「基本的に」としたのは、バージョン9からUltra Lightもクライアント／サーバモデルが追加されたからである。「例えばカーナビで、音楽再生機能とナビゲーション機能が別プロセスで動いており、その両方がデータベースを利用したいという場合があります。Ultra Lightが別プロセスで動作すれば、複数の機能にデータベースを提供できます」（森脇氏）という。ちなみに、シングルプロセスの場合でもマルチスレッドに対応しているという。


	関連リンク：
⇒	SQLite（http://www.hwaci.com/sw/sqlite/）

　シングルスレッドで使う場合、バージョン8までは独自SDK（これをStatic APIと呼ぶ）を直接プログラムからたたく形になっていた。典型的なEmbedded SQLのように、SQL文をプログラム中に記述しておき、プリプロセッサに通すとソースと一緒にDBアクセスルーチンが生成され、これをコンパイル／リンクするという形だ。バージョン9からは.NETが全面的にサポートされ、ADO.NET経由でのDBアクセスが可能になったという。

　Static APIがよいのかADO.NET経由がよいのかについては、アプリケーションの性格にも依存しそうだ。例えば、日本語入力支援などでRead Onlyの小さなDBを作るのであれば、Static APIを使って不要な機能をビルドしないようにすれば、フットプリントを非常に小さくできるという。Static APIは現在のバージョン9のみならず、2006年秋ごろに登場するバージョン10にも残されるから、今後も要件によって使い分けることが可能だ。

サポートする機能とプラットフォーム

　Ultra Lightの機能については、「実は驚くほど豊富です。実装されている機能を数えるよりも、ASAにあってUltra Lightにない機能を数えた方が早いでしょう」（森脇氏）という。これについては、「Ultra LightとASAの比較」というページにまとめられている。トリガやストアドプロシージャが使えないといったところがASAとの大きな違いだろう。とはいえデータ型などはきちんとサポートされており、RDBとして使う分には問題ないとしている。現バージョンの最大の問題は、1テーブル当たりのRowが制限される（65534行以下）ことで、大量のデータを格納する場合はテーブル分割などを考慮する必要があることだ。これについては、次のバージョン10で大幅に緩和される予定だ。


	関連リンク：
⇒	Ultra LightとASAの比較（http://www.ianywhere.jp/sas/ulasa.html）

　サポートプラットフォームとしては、WindowsおよびWindows CE、Palmが掲げられている。面白いのは、J2SEで動作する「Native Ultra Light for Java」とPure Javaの「Ultra Light Static Java」の存在である。例えばWindows CEの場合、現在ラインアップされているのはARM（XScaleベース）がメインだが、この場合はNative Ultra Light for Javaで対応できる。それ以外のCPUでもJ2SEを動かせばUltra Light Static Javaで対応できるという。ただ、実際にはJ2SEを使うユーザーはほとんどいなかったようで、J2SEのサポートは残念ながらバージョン9止まりとなる。その代わりといっては何だが、バージョン10からはSymbian OSのサポートが決定しているほか、組み込みLinuxとJ2MEのサポートを検討しているという。ちなみにJ2MEのターゲットはBlackBerry（編注）とのこと。日本ではあまりなじみがないが、欧米ではビジネス層にかなり広く普及しており、ワールドワイドでは大きな強みになるかもしれない。

※編注

カナダのResearch In Motion（RIM）社の携帯端末。

Research In Motion（http://www.rim.net/）
BlackBerry（http://www.blackberry.com/）

連携を支えるMobile Link

　現在、Ultra LightはWindows CEベースの専用端末で利用されるケースが多いという。例えば、工場や倉庫、サプライチェーンなどで在庫管理をするためにバーコードリーダを付けた専用端末が多く利用されている。こうしたシーンで、入出庫の情報を一時的にストアするためにUltra Lightを利用し、各端末から集めた情報をまとめて管理するバックエンドデータベースにASAなどのRDBMSを使う。こうしたケースで、端末とバックエンドDB間をつなぐのがMobile Linkというわけだ。

　「1つの大きなデータベースと複数の小さなデータベース。つまりシステムの中でデータがたくさんコピーされているようなケースで、個々のデータをどうやってセンター側に伝えるかが課題になっている。そのためのソリューションがMobile Linkという技術です」（森脇氏）ということで、案件によってはMobile Linkが「主」で、これと連動するUltra LightやASAが「従」になるケースもあるようだ。

　Mobile Linkは、図2のような構造を取る。

図2　Mobile Linkによる同期

　Ultra Lightを搭載するMobile LinkクライアントとMobile Link同期サーバの間は、HTTP/HTTPS、ActiveSync/HotSyncといった汎用プロトコルやTCP/IP上に載せたMobile Link独自プロトコルで通信する。Mobile Link同期サーバはこれをODBCに変換してRDBMSにアクセスし、戻りは再びODBCから独自プロトコルに変換してMobile Linkクライアントに返されるという仕組みだ。要するに、Mobile Link同期サーバはODBCと独自プロトコルを変換するプロキシのような動きをすることになる。

Mobile LinkがサポートしているRDBMS

　RDBMSとのインターフェイスがODBCであることからも分かるとおり、Mobile LinkはASAだけでなく他社製の主な商用データベース製品をサポートしている。

　当然セキュリティ面も配慮されており、HTTPSによる通信経路の暗号化をサポートしている。さらに、データベースファイル自体を暗号化してファイルシステムに保持するオプションを備えている。暗号化のレベルは選択可能で、「重要な通信に関しては、AESなどをお勧めしています」（森脇氏）という。ただし、暗号強度はMobile Link同期サーバのみならずクライアントへの負荷も関係してくるので、データの機密性とパフォーマンスを勘案しながら選ぶことになるだろう。

競合はフラットファイル

前のページへ 1|2|3 次のページへ