アーキテクチャーパターンとは何か

2009年5月20日(水)
羽生田 栄一

アーキテクチャパターンとは何か

連載2回目の今回は、アーキテクチャパターンについて紹介したいと思います。POSAおよびPoEAAという2つの有名なアーキテクチャパターンカタログについて簡単に触れた後、eビジネス分野のアプリケーション設計全般を対象とするパターンランゲージ、IBM Patterns for e-businessの内容をご紹介します。

 デザインパターンがクラスや関連でつながったクラス間の局所的な構造や相互作用をサポートするためのパターンだったとすると、アーキテクチャパターンというのは、クラスよりも大きな単位でのパッケージやサブシステム、レイヤーといったマクロな構造や、それらの接続と相互作用をサポートするためのパターンだと言えるでしょう。

 マクロなレベルにおけるオブジェクト設計の基本は、そのパッケージ内のクラス群はできるだけ関連性の高いものでまとめる(高凝集度)けれども、パッケージ間の依存関係はできるだけ単方向にして、かつできるだけインターフェースを限定して設計する(低結合度=疎結合)ということになります。

 こうした設計方針をきちんと定式化したものが、前回も触れたJames Martinのパッケージのためのオブジェクト指向設計原則だと言えるでしょう。パッケージ内部の凝集度を管理するための3原則(再利用・リリース等価の原則《REP:Reuse Release Equivalence Principle》、全再利用の原則《CRP:Common Reuse Principle》、閉鎖性共通の原則《CCP:Common Closure Principle》)とパッケージ同士の結合度を管理するための3原則(非循環依存関係の原則《ADP:Acyclic Dependencies Principle》、安定依存の原則《SDP:Stable Dependencies Principle》、安定度・抽象度等価の原則《SAP:Stable Abstractions Principle》)です。

■アーキテクチャパターンの代表格POSA
 最初に世の中に登場したアーキテクチャパターンはPatterns Oriented Software Architecture(通称POSA)です。4つのテーマ(大きな構造化、分散、対話型、適応型)で一般的なソフトウエアアーキテクチャを大くくりに分類してくれています(図1-1)。特に「混沌(こんとん)から構造へ」と題して大きな構造化の仕方を取り扱う目的で整理されているLayersパターン、Pipes&Filtersパターン、Blackboardパターンは、システムの最初の方向性、基本的な設計方針を固める上で非常に重要となります。

 またPOSAでは、GoFのデザインパターンも独自の分類で目的別に整理してくれています。GoFでは、生成・構造・振る舞いという素っ気ない3分類でしたが、POSAでは、Master-SlaveやWhole-Partといったいくつかの基本的なデザインパターンが追加された上で、分類に関しても、「仕事の組織化、サービスの多種化・拡張、管理、コミュニケーション、……」といった設計目的・意味によるカテゴリが導入されています。さらにクラスより小粒度のコーディングパターンをイディオムとして併せて整理しています。GoFと違いTemplate Methodがイディオム・レベルに格下げになっているのも興味深いです。

エンタープライズアプリケーションアーキテクチャパターンとは

 世の中にはもう1つよく知られたアーキテクチャパターンカタログとして、マーチン・ファウラーのエンタープライズアプリケーションアーキテクチャパターン(PoEAA)があります。「頑健なシステムを実現するためのレイヤー化アプローチ」という副題からもわかるように、これはPOSAで言うレイヤー化(Layers)パターンを、Webシステムを中心としたビジネス系アプリケーションに適用する際のノウハウ(ドメインロジックの分離、データの管理とDBマッピング、並行性やセッションの制御)を関連するデザインパターンとともに整理したものです。

 いままでJ2EEデザインパターンやEJBデザインパターン、.NETデザインパターンなどとして個別実装技術とセットで語られてきた、Webアプリケーション構築にかかわる設計上のノウハウを「レイヤー化」に着目して整理し直したものと言えるでしょう。

 レイヤーごとに考慮すべき設計課題が多岐に亘るため、40以上のパターンが紹介されています。とはいえ、これらのパターンを自分たちのシステムの目的に合わせて適切に取捨選択して組み合わせるには相当なスキルと経験が必要になります。

アーキテクチャのためのパターン・ランゲージ

 いままでご紹介してきたのは、いずれもシステム開発プロジェクトの後半で設計に利用できるアーキテクチャパターンカタログが中心でした。それに対し、これから紹介するのは、eビジネスに関するシステムを構築する際の一連の流れを有機的に支援することを意図して、そのノウハウの再利用をパターンランゲージとして定義した、IBM Patterns for e-businessです。

 単なるパターンカタログではなくランゲージになっているのは、上流から下流へとシステム分析・設計のプロセスに即して有機的にアーキテクチャにかかわるノウハウが構造化されているからです。ビジネス目的の分析から適切なビジネスパターンの組み合わせを選択し、それらに適したアプリケーションパターンを用いて論理アーキテクチャを設計し、それを実現するためのミドルウエアやインフラの物理アーキテクチャのしくみを、ランタイムパターンを用いて検討し、最後にそれらの実装製品の候補を検討する、という具合です(図2-1)。

 各パターンは共通のテンプレートにしたがって記述され、「ビジネス要件およびIT要件」「コンテキスト」「ソリューション」「メリットと制限事項」「パターンの使用例」「次のステップ」から構成されます。

 特に「ビジネス要件およびIT要件」をしっかり分析し、適切なビジネスパターンとそれを実現するアプリケーションパターンの候補を選択するためのナビゲーションがうまく考えられているところに、このパターンランゲージの経験知が凝縮されています(図2-2)。

■eビジネスパターンの使い方
 基本的には次のような手順でこのパターンランゲージを利用します。

(1)開発中のアプリケーションのニーズに合ったビジネスパターンを選択します。
(2)アプリケーション固有の機能をインプリメントできるアプリケーションパターンを選択します。
(3)ランタイムパターンを検討して、ソリューションのシステム要件を満たすパターンを選択します。
(4)上記のパターンから選択できるミドルウエアやインフラ構成を検討して、ステップ(3)で選択したランタイムパターンに正常に使用可能な製品へマッピングします。

ビジネスパターンの組み合わせ構造

 基本的なビジネスパターンには次の4種類があります。
・B1:セルフサービス(ユーザー/ビジネス間またはU2B)パターン
  内部および外部ユーザーが企業のトランザクションおよびデータと対話するようなしくみです。
・B2:コラボレーション(ユーザー間またはU2U)パターン
  ユーザー間の対話とコラボレーションを扱い、共通の目標を達成するために共同作業する必要があるチームをサポートするしくみです。
・B3:情報集約(ユーザー/データ間またはU2D)パターン
  複数のソースから統合されたデータをユーザーがアクセスおよび操作できるようなしくみで、大量のデータ、テキスト、画像・動画などの中から役立つ情報を抽出する機能を含みます。
・B4:拡張エンタープライズ(企業間取引またはB2B)パターン
  異なる企業におけるビジネスプロセス間の対話およびコラボレーションを扱い、プログラムのインターフェースを実装して企業内アプリケーションに接続するシステムが典型です。

 これらの4つの基本ビジネスパターンは組み合わされて使われることもありますが、その際、ユーザーから見てアクセスを共通化したいとか、システム提供側から見てデータやロジックを共通化したいなどという要求が当然発生します。そこで、次の2つの統合ビジネスパターンが用意されています。

・I1:アクセス統合パターン
  複数のチャネルやデバイスからのアクセスを可能にし、また一貫性のあるユーザー・インターフェースをサポートします。
・I2:アプリケーション統合パターン
  複数のアプリケーションやデータの統一的な利用をサポートします。

 そして通常のシステムは、複数の基本ビジネスパターンおよび統合ビジネスパターンの組み合わせをカスタマイズして利用することになります。世の中の多様なWeb利用の仕方から標準的な組み合わせを取り出します。さらに、世の中の多様なWeb利用の仕方から標準的な組み合わせを取り出したものも用意されており、コンポジット・ビジネスパターンと呼ばれています。代表的なコンポジット・ビジネスパターンには、「電子商取引」「eマーケットプレイス」「ポータル」「アカウント・アクセス」などがあります。実際にはこれらのコンポジット・ビジネスパターンをさらに組み合わせたりカスタマイズしたりして、複雑な実際のシステムが構成されることになるでしょう。

ビジネスパターンからアプリケーションパターンへ

 ビジネス上の戦略や業務目的に対して適合するビジネスパターンが選択できたら、次に行うことはそれらの戦略や目的を実現するためのビジネス要件・IT要件を最もよく充足するアプリケーションパターンを選択することです。その際、先の図2-1、2-2の表を利用します。

 図2にあるように、B1:セルフサービス(ユーザー/ビジネス間またはU2B)パターンに対するアプリケーションパターンは、「スタンドアローン・シングルチャネル」「直接統合シングルチャネル」「現状維持ホスト」「ホストへのカスタマイズ・プレゼンテーション」「ルーター」「デコンポジション」「エージェント」の7パターンです。

 例えば、そのシステムを使った「ビジネスの迅速な開始」に最も関心を寄せており、それ以外はできるだけシンプルに「アプリケーションの複雑さの最小化」に気を使うとすると、アプリケーションパターンとしては必然的に「スタンドアローンかつシングルチャネル」が選ばれることになります(図3-1)。これは、セルフサービス・ビジネスパターンを自動化するアプリケーションパターンの中で最も簡単なパターンです。

 このアプリケーションパターンでは、アプリケーションを2つの論理層に分割して、プレゼンテーション・ロジックはビジネスロジックから分離します。プレゼンテーション層とアプリケーション層の間のリクエスター対話は同期で、ユーザー・インターフェースから送られるすべての要求がビジネス・ロジックをこのアプリケーション層の上で呼び出します。ビジネス・ロジックが実行されると、制御権はプレゼンテーション層に渡され、戻された結果を使用して、ユーザー・インターフェースを更新します。バックエンド・アプリケーションの統合をすぐにまたは将来的に必要としないアプリケーションの場合は、このアプリケーション・パターンは目的に合う最適なアーキテクチャです。

 一方、ビジネス目的として「組織効率の改善」や「ビジネスプロセスの迅速化」に興味があって、かつIT要件として「保守容易性」「拡張容易性」はそれほど問題視していないという場合には、「直接統合・シングルチャネル」アプリケーションパターンが1つの候補になります(図3-2)。バックエンドのアプリケーションとデータベースにPoint-to-Point接続を使用して、スタンドアローン単一チャネル・アプリケーション・パターンを拡張します。アプリケーションをプレゼンテーション、Webアプリケーション、およびバックエンド・アプリケーションという論理的な3層アーキテクチャを作ります。

ランタイムパターン

 次の作業は、アプリケーションの要件と最も一致するランタイムパターンを選択することです。ランタイムパターンは、機能コンポーネントおよび操作コンポーネントをグループに分けるためにノードを用います。それらは設計目的に応じて相互接続され、ランタイムパターンを構成します。

 ここでは、「スタンドアローンかつシングルチャネル」アプリケーションパターンに対する基本と派生の2種類のランタイムパターンを示します(図3-3、3-4)。まず最初の基本ランタイムパターンでは、すべての機密永続データすべてをファイアウォールの背後に置くことにより、セキュリティーの手段が提供されます。 拡張容易性やフェイルオーバー機能はありませんが、そうした機能を追加するベースとしてのシンプルさを備えています。

 もう1つの派生パターンは、Webサーバーを含むWebサーバー・リダイレクター1台とアプリケーション・サーバー1台を使用して、2台のマシンにWebアプリケーション・サーバーの機能を効果的に分割しています。アプリケーション・サーバーを内部ネットワークに置いて、より高いセキュリティーを提供します。アプリケーション・サーバー・ノードがプレゼンテーション・ロジックとビジネス・ロジックの両方を実行します。WebサーバーはDMZ(DeMilitarized Zone:非武装地帯)内に残り、Webページを処理します。

 そしてこれらランタイムパターンの次に、そこに登場するミドルウエア/インフラ製品の具体的な候補を提示している製品マッピングが記述されています。それぞれのメーカーの製品スペックや特徴が示され、ユーザーはインフラアーキテクチャの具体的な実装を検討するのに便利です。

■これから求められるアーキテクチャパターン
 以上簡単にIBM Patterns for e-businessパターンランゲージに関して紹介しました。現在、これらのパターンはe-ビジネスを超えて、SOAアーキテクチャやクラウドコンピューティング時代を見据えて新たなアーキテクチャを必要としています。分散や並列処理、トランザクションといった概念への見直しやRDBに代わる新たなkey-valueを基本にしたデータベースの利用やMap/Reduceといった、副作用がない関数型の並列処理の方式などいろいろな面で大きな変更が必要となります。いずれこのような新しい時代のアーキテクチャ・パターンランゲージが登場することでしょう。


【参考文献】

『ソフトウェアアーキテクチャ ソフトウェア開発のためのパターン体系』Frank Bushmann他、2000(近代科学社)
『エンタープライズ アプリケーションアーキテクチャパターン』M.ファウラー他、2005(翔泳社)
『Webシステムのデザインパターン すぐに使えるe-businessアプリケーション構築の定石集』J.アダムズ他、2003(翔泳社)
Patterns for e-business英語サイトhttp://www.ibm.com/developerworks/patterns/library/ (日本語版は上記ページ右欄にあるTranslated web sitesのコーナーからJapanese translationを選択しダウンロードしてください)

株式会社豆蔵
株式会社豆蔵取締役CTO、プロフェッショナル・フェロー。技術士(情報工学部門)。オブジェクト指向やソフトウエア工学の実践適用に関するコンサルティング,セミナー講師に従事し,後進の育成にあたる。 アジャイルプロセス協議会会長,IPA/SEC設計技術部会委員,情報処理学会ソフトウエア工学研究会パターンワーキンググループ主査,IPA ITアーキテクト・コミュニティ委員,等を務める。神社と富士塚・古書店等を巡る街歩きが趣味。

Think ITメルマガ会員登録受付中

Think ITでは、技術情報が詰まったメールマガジン「Think IT Weekly」の配信サービスを提供しています。メルマガ会員登録を済ませれば、メルマガだけでなく、さまざまな限定特典を入手できるようになります。

Think ITメルマガ会員のサービス内容を見る

他にもこの記事が読まれています