クライアントサーバという究極の設計思想：Symbian OS開発の勘所（8）（4/4 ページ）
Symbian OSの第3の特徴はクライアントサーバ・フレームワークだ。「セマフォ＆共有メモリ」ではなぜダメなのか？
機能を提供する主体に求められるもの
ファイルシステムの管理やウィンドウの操作など、機能を提供する主体はどのような構成を取るべきなのでしょう。
Symbian OSはマルチプロセス、マルチスレッドのOSなので、それぞれがサーバに対して同時に要求を投げることがあり得ます。そうでなくてもアクティブオブジェクト−アクティブスケジューラにより複数のコンテクストが同時に存在するので、1つのスレッドの中から複数の要求が同時に仕掛かることがあり得ます（さもないとファイルを2つ開いて、内容をコピーするようなコードは書けませんよね？）。ですから機能の提供主体は要求が複数到着したとしても、それらすべてをきちんとさばけなければなりません。
セマフォと共有メモリで通信路を作ってもよいのですが、複数個の要求を管理する機能も作り込む必要があります。しかも非同期対応を省くわけにはいきません。クライアントのスレッドをブロックさせて構わないならいろいろ手段を考えられますが、そんなことをやった瞬間にほかの処理が破たんします。玉突き衝突ならぬ玉突きブロックが発生するからです。
このような制約を充足しようとした場合、一般的にはキューを導入し、呼ぶ側と呼ばれる側のアイソレーションを図ります。機能を提供する主体がクリアしなければならないハードルは、よく考えるとずいぶん高そうです。
時間軸方向のバッファ−キューを介した通信
ではSymbian OSにおける機能の提供主体であるサーバはどうしているのでしょう。図6で示した「メッセージを用いた論理的な通信路」をもう一段分解してみましょう。
図7 クライアントサーバの通信（実装含む）／（※）ファイルサーバの中核クラスをCFsServerとし、CServer2から直接派生している図としましたが、実際はこれとは異なっています。あくまでも概念としてとらえてください
解像度を上げると見えてくるものが、上図の「論理的な通信路の実現方法」とラベルが付いている部分です。図にあるとおり、ユーザープロセスとファイルサーバの間にはキューが存在します。クライアントサイドAPIに渡された引数はTIpcArgsという型のオブジェクトにパッキングされた後、メッセージキューに格納されます。サーバは要求の発生を通知されると、メッセージキューから1つ取り出して処理を行います。このようにメッセージキューを挟んで連携することにより、複数個の要求が同時に発生したとしても、クライアントをブロックさせることなくすべての要求を順次さばくことが可能になっています。
クライアントサーバ・フレームワーク
Symbian OSでは、このクライアントサーバを実現するための仕掛けを「クライアントサーバ・フレームワーク」と呼んでいます。要求のやりとりに関するほとんどの部分はフレームワークが処理してくれるので、新しくサーバを作ることになって書き起こすコードは、要求や結果をメッセージオブジェクトに変換する部分などに限られます。
付け加えておくと、サーバは必ずクライアントと別のプロセスに存在しなければならないわけではありません（アウトプロセスモデル）。上記の通信チャネルが確立できるのであれば、同一プロセス内の別スレッドがサーバであっても構いません（インプロセスモデル）。プロセスをまたがったデータコピーのコストが本質的な問題になるのであれば、同一プロセス内にサーバを構えることもできるというデザイン上の自由が保証されています。そしてこのようなことが選べるのも、結局のところフレームワークの恩恵の1つなのです。
ここまでの検討を振り返ると、「セマフォ＆共有メモリ」アプローチだから性能が向上するわけでも、実装が楽になるわけでもなさそうだということがお分かりいただけたと思います。というわけで、すでに必要な仕掛けはクライアントサーバ・フレームワークとして提供されており、車輪の再発明は避けるべきでしょう、というのが今回の結論となります。
ちなみにSymbian OSのクライアントサーバ同様、クライアントが要求する機能をアウトプロセス、インプロセスどちらのモデルでも提供し、マーシャリングによってプロセス境界も超えたデータ転送を行い、それらを使ってソフトウェアをコンポーネント化するデザインを徹底して行っている環境があります。マイクロソフトのCOM（Component Object Model）です。
もちろんネットワーク分散への対応や、CLRのような仮想マシンによる単一ランタイムへの集約など、計算機資源は使い放題であると考えるマイクロソフトのアプローチと異なる部分は多いのですが、こと単一のマシンでバイナリレベルの再利用に重点を置いたCOMに限っていえば、クライアントサーバが意識している問題と重なる領域を狙っています（ただし非同期に関してはアレですが）。
COMをご存じという方は、COMとパラレルな何か、という視点でクライアントサーバに関する知識の整理を行ってみることをお勧めします。
クライアントサーバという用語自体は確かにハードコアなのですが、実際に使う側からすると通常のAPIコールとさして違いがないこと（注5）、非機能要求を満たそうとすると妥当な選択だったことなどがお分かりいただけたと思います。ワンショット型（要求と応答が1対1）の要求に限ればクライアントサーバスタイルは妥当なデザインなのです。
と、微妙な物言いをしているのは、もちろん世の中の要求−応答のスタイルがワンショット型で網羅できるわけではないからです。このあたりはSymbianも十分理解しており、V8.1b以降いくつかのIPCの仕掛けが導入されています。Symbian OSの3本柱（というかトリニティというか）に関する説明は今回をもってめでたく終了しましたので、次回はこれら新しいIPCの話など、最近の動向を解説したいと思います。（次回に続く）
Copyright © ITmedia, Inc. All Rights Reserved.