クライアントサーバという究極の設計思想：Symbian OS開発の勘所（8）（2/4 ページ）
Symbian OSの第3の特徴はクライアントサーバ・フレームワークだ。「セマフォ＆共有メモリ」ではなぜダメなのか？
利用者から見たクライアントサーバ
では、サーバは利用者側からどのように見えるのでしょうか。ファイルサーバを例に説明を進めます。
ファイルサーバは、ファイルおよびその格納先であるフォルダを操作する機能一式を提供するものです。多くのOSにおけるファイルシステムと同様、Symbian OSでも以下の2つの観点でAPIを整理しています。
- フォルダ、またそこに含まれるファイルを操作する
- ファイルを開いて内容を操作する
1に関する操作はRFsというクラスに集約されています。Rから名前が始まる場合、第3回のクラスの命名規則で説明したとおり、ほかのエンティティ（カーネルや他プロセス）が所有するリソースを参照するためのクラスとなります。確かにファイルサーバは他プロセスであるので、そこに処理を委託するためのクラスにふさわしい名前です。ではこのRFsクラスはどのようにファイルサーバと通信をしているのでしょうか。クラス定義を眺めてみましょう。
MkDir()やRmdir()、Rename()やDelete()など、名前から機能が即座に想像できるAPIが並んでいるのに交ざって、Connect()という見慣れないメンバ関数がいます。これこそがファイルサーバに接続するための、クライアントサーバに特徴的なAPIです。ただし名前はConnect()に決まっているわけではありません。後出のRFileクラスではOpen()という名称を用いています。
RFsを使ってファイルを移動するコードのサンプルを見てみましょう。
前処理のセクションではConnect()関数を発行しています。この関数の延長でファイルサーバに対して接続が行われ、以後要求を発行することが可能になります。サーバに対して通信をうんぬんというと非常に厄介なもののような気がしますが、実際には特定のAPIを決まり事として呼び出しておく以外にコストが発生することはありません。なお、CleanupClosePushL()と、それに対応する後処理のCleanupStack::PopAndDestroy()は、第4回で解説しているクリーンナップスタック（CleanupStack）というメモリ（リソース）管理フレームワークの機能です。これにより例外フリーな後始末（Connect()で開始された接続の切断）が保証されます。
処理実体である部分にもクドクドとコードが書かれていますが、よく見れば最初の2行は文字列の定数宣言をするためのコードです（注2）。またUser::LeaveIfError()は、負の値を受け取ったときに、それを値としてリーブを発生させるものです。というわけで、処理実体はRFsのAPI呼び出しと、そのサポートコードから構成される形になっています。
まとめると、ファイルサーバに処理を要求するというと大事のように聞こえますが、実のところ、
- 最初に接続APIを決まり事として呼んでおく
- 最後に切断を必ず行う
さえ守っておけば、後はクラスラッピングされたAPI呼び出しにすぎません。OO（オブジェクト指向）環境においてはクライアントサーバといえども適切にラッピングされ、ただのAPI呼び出しと見分けがつかない形で提供されるのです。Symbian OSでは、このラッピング用クラスとそれが提供するAPIのことを併せて、クライアントサイドAPIと呼称します。そしてこのクライアントサイドAPIを用意する義務があるのは、当然ですがサーバの提供者です。クライアントのプログラムは、あくまでクライアントサイドAPIを使うだけなのです。
なお上記のサンプルコードが仰々しく見えてしまうのは、第2回から第7回までで解説したSymbian OSのイディオムをすべて使用しているからですが、これはつまるところ慣れの問題です。ロバストかつモバイル向けのコードが必要なのであれば、いずれ必ず見慣れると思ってください（注3）。
ただし今回は特別に、まだSymbian OSのイディオムに移行できていないという人のために、例外処理を無視した、不完全なバージョンのサンプルを付記しておきます。
図3のコードと見比べてみてください。
Copyright © ITmedia, Inc. All Rights Reserved.