PR
図6●パイプライン・アーキテクチャ
互いに依存関係がない形に操作を分割できれば,個々に独立したモジュールを一直線に並べるイメージでシステムを構築できる。こうすればシステムの複雑さが減少し,柔軟なシステムを短期間で開発できるようになる。
図7●アスペクト
複数のクラスやオブジェクトに対し,横断的に適用可能な構造や振る舞いを抽出したものがアスペクトである。アスペクトはクラスを定義する際の視点とは独立しているので,アスペクトの内容を変更してもクラスやオブジェクトに影響を与えない。具体的には,ログ記録やセキュリティ,トランザクション管理などがアスペクトとして抽出される(本誌)。

分割したシステムから“製品ライン”を作る

 大規模システムを開発する上で重要なのは,それを複数の単純なシステムに分割して考えることである。ただ何を単位として単純なシステムに分割するかが難しい。分割の観点(スコープ)が互いに独立していれば,全体システムは単純なサブシステムの和となる。しかしサブシステム間に依存関係があると,単純なサブシステム分割だけでは問題は解決しない。この問題をスコープの独立性,あるいは,直交性(orthogonal)と呼ぶ。

 例えば,アプリケーション・サーバーにはトランザクション処理,セキュリティ管理,状態永続化,負荷分散など,問題領域ごとに分割した機能がある。それぞれの機能はスコープが独立しているので,単純な属性設定だけで機能の追加や組み合わせが可能である。しかし,オブジェクトの同時実行制御(いわゆる同期化)とトランザクションには依存関係がある。だからCOM+ではトランザクション処理の前提として,必ず同期化も実施しなければならない。

 別の例として,キュー(待ち行列)マネージャの実装がある。これには三つのスコープがある。(1)同時アクセス制御(同時アクセス制御のないシーケンシャル,ガードを使った明示的同期制御,実装内部で隠蔽した自動同期制御),(2)メモリー割り当て方法(配列,リスト,動的リスト),(3)データ項目の順序制御(キー順,順序なし)である。これらのスコープの組み合わせで3×3×2=18個の実装があり得る。うまく分割しておけばこれらの組み合わせで“製品ライン”を作り,さまざまな分野に応用できる。この考え方が「プロダクトライン・アーキテクチャ」である。

パイプライン・アーキテクチャ

 これに似た考え方として,パイプライン・アーキテクチャがある。WebサービスではSOAPヘッダーの拡張により,セキュリティ,信頼性のあるメッセージング,ルーティング,トランザクションなどの追加仕様が実現可能である。これらの仕様も互いに独立している。それぞれ特定の名前空間を使うので,識別が可能だ。拡張されたSOAPヘッダーを処理する実行エンジンは,拡張機能のスコープが独立しているので,パイプライン・アーキテクチャを採ることが多い(図6[拡大表示])。パイプラインは独立したスコープの処理を「流れ作業」で実行可能で,仕様の追加に対する拡張性を持っている。ASP .NETのHTTPハンドラがこのアーキテクチャの代表例である。

クラス横断な視点で別の分割を実施

 独立したスコープを提供する考え方として,アスペクト指向が最近注目を集めている。簡単に言えば,オブジェクト指向がソフトウェアをクラスという部品で構築する考え方なのに対し,アスペクト指向は部品に横断的な視点(アスペクト)に着目する(図7[拡大表示])。よく例として取り上げられる機能にロギングがある。ロギングは部品ごとに必要な機能であるため,その実装コードが各クラスに分散している。それらを一括して管理できるならば,クラス数が増大する大規模システムでも効率的管理が可能となる。

 同様に,複数オブジェクトにかかわるトランザクション(実行時にトランザクション木をオブジェクト間で形成する)やセキュリティ(呼び出し元から実行権限が呼び出し先に伝播する)などのサービスを定義するアスペクトが存在する。このようにアスペクトのスコープはクラスやオブジェクトの単位とは直交し,ソフトウェア部品化とは相補的な関係にある。この意味でアスペクト指向は必ずしもオブジェクト指向との組み合わせに限定されるわけではない。

 アスペクト指向はまだ発展途上だが,オブジェクト指向が継承ベースの拡張を考えるのに対して,クラス定義とは独立した観点からシステム拡張を考えるため,サブクラス数の増大を抑え保守性を改善すると考えられる。また,アスペクト定義の変更はクラス定義に影響を与えないので,システム変更を柔軟にできる。多くのデザイン・パターンが,オブジェクト同士を疎結合することで変更に対する柔軟性を与えている。アスペクト指向は同じ課題に対して別のアプローチをとったと考えてもよい。だからアスペクト指向により大半のデザイン・パターンを不要にできるという研究成果もある。だからといってデザイン・パターンがよい設計指針を与える有効な手段であることに変わりはないので注意されたい。

 最近になりWebサービスの拡張性やアスペクト指向のスコープの前提である分離した視点の直交性が成立しない問題が指摘されている。すなわち,パイプライン・アーキテクチャが有効なのは単純な場合だけという。このため,実行時に登録可能なイベント駆動型アーキテクチャ,あるいは,2相コミット・プロトコルに基づくトランザクション・コーディネータのような,複雑な依存関係にも有効なアーキテクチャが検討されている。

 いずれにしても,オブジェクト指向は分散技術など他の技術との組み合わせで初めて有効となる。それ単独で有効と言えたのはすでに過去のことと言えるほど複雑化している。