レベル: 中級 Peter Xu (peteryxu@us.ibm.com), Senior Managing Consultant, IBM
2007年 10月 03日 ドメイン・モデルは大部分の OOP (Object Oriented Programming: オブジェクト指向プログラミング) 開発者やアーキテクトにとっておなじみの概念であり、さまざまなシステムやプロジェクトに使われて成功しています。しかしこの原則を SOA ベースのソリューションに適用するためにはどうすればよいのでしょう。IBM WebSphere 開発者向け技術ジャーナルより
はじめに
ドメイン・モデルは、構築しているシステムの概念モデルと考えることができます。ドメイン・モデルは、システムのエンティティーと、エンティティー同士の関係を記述し、システムの境界と概念を確立するために使われます。また、こうしたエンティティーの属性と重要なメソッドを特定する上でも役に立ちます。
ドメイン・モデルに OOP (Object Oriented Programming: オブジェクト指向プログラミング) の原則を適用すると、ドメイン・モデルはオブジェクトのようになります。Martin Fowler はドメイン・モデルを、『動作とデータの両方を考慮した、ドメインのオブジェクト・モデル』と定義しています。これはドメイン・モデルを認識するための 1 つの方法ですが、必ずしもこれが唯一の方法ではありません。
従来の OO システムやプログラムの大部分は、ドメインのデータ・オブジェクトの階層構造を操作するビジネス・オブジェクトで構成されています。そのデータ・オブジェクトは、通常はテーブル内のビジネス・データの薄いラッパーであり、一般的なデータ・アクセスをするためのメソッドと、関係をナビゲートするためのメソッドを持っています。データ・オブジェクトはデータベースのコアとなるデータ・モデルを取得し、またそうしたデータに適用されるビジネス・ルールも取得します。このパターンの典型的な例が Java™ EE のセッション Bean とエンティティー Bean であり、セッション Bean はビジネス・オブジェクトとして動作し、エンティティー Bean はデータ・オブジェクトです。良し悪しは別にして、この習慣はドメイン・モデル貧血症 (Anemic Domain Model) と呼ばれることがあります (「参考文献」を参照)。
オブジェクト指向のドメイン・モデルには独自のユース・ケースがあり、ゲーム・システムなどのクローズド・システムには有効です。ここでは OO システムの利点を繰り返すつもりはありませんが、その一方でオブジェクト・ドメイン・モデルには制限もあります。特にSOA 環境では、複数のレイヤーとシステムにまたがる柔軟性とソリューションが何よりも重要なため、オブジェクト・ドメイン・モデルには制限が出てきます。これらの制限を検証し、他に考えられるドメイン・モデルがないかどうかを調べてみましょう。
オブジェクト・ドメイン・モデルの問題
オブジェクト・ドメイン・モデルを経験したことのある人ならば誰でも、オブジェクト・ドメイン・モデルをベースとするシステムを構築する際には、コーディング作業の主な部分がアプリケーションのビジネス・データの周りにオブジェクト・ラッパーを作成することに費やされる、と証言するでしょう。例えば、銀行アプリケーション用に次のような単純なドメイン・モデルがあるとします。
図 1. 銀行アプリケーション用の単純なドメイン・モデル
オブジェクト・ドメイン・モデルの方法では、最初にしなければならないことは、Customer (顧客) と Account (口座)、そして Transaction (取引) 用にそれぞれ別の薄いラッパー・クラスを作ることです。これらのラッパー・オブジェクトは、ビジネスに関係するデータを保持するための属性を定義しなければなりません。さらにこれらのラッパー・オブジェクトを、次の動作メソッドによって増強し、実装する必要があります。
-
パーシスタンス・メソッド: パーシスタンス・ストアからのロードとパーシスタンス・ストアへの保存を行います。
-
検証メソッド: ビジネス・ルールに従うデータを検証します。
-
関係メソッド: オブジェクト間の包含関係をナビゲートします。
このためには大量のコードを作成し、維持管理しなければなりません。最近の言語には何らかのフレームワークとコード生成ツール (例えば Toplink や Hibernate など) が提供されていることもあるため、コード作成の一部は自動化できますが、それにしても大量のコードを作成する必要があります。
オブジェクトとリレーショナル間のマッピング
ドメイン・モデルとしては、リレーショナル・データベースのスキーマ・モデルに非常に似た単純なオブジェクト・ドメイン・モデルも、データベース設計の観点からは異なったものに見える複雑なリッチ・ドメイン・モデルのいずれも可能です。どちらの場合も、オブジェクトとリレーショナルのマッピングを行うためのコードを作成するか、あるいはそのコードを生成する必要があります。
オブジェクトとリレーショナル間のマッピングを自動的に行う方法は、最初は簡単に思えるかもしれませんが、時間の経過と共に複雑になります。これは根本的に異なる 2 つのドメインの間を橋渡ししようとする方法なので、非常に解決が難しい問題です。つまりリレーショナル・データ・ストアの設計方法は、オブジェクト・システムの設計方法とは微妙に、しかし深いところで異なるのです。オブジェクトとリレーショナル間のマッピングの問題に関する情報は、「参考文献」を参照してください。
その解決方法は何でしょう。それは、オブジェクトをあきらめることです。シナリオによっては、オブジェクト指向の方法はオーバーヘッドを減らすよりもむしろ増やしてしまい、この方法による ROI は、リッチなドメイン・モデルを作成するコストにはとても見合いません。ましてや、リレーショナル・データベースとの間でのマッピングに関するやりとりに、大量の費用や作業を費やすコストにも見合いません。
関係のナビゲーション
オブジェクト階層構造の間での単純なナビゲーション機能はデータ・オブジェクト・モデルの中に元々含まれていますが、オブジェクト階層構造の中での高度な検索やナビゲーションの機能は、検索のための基準 (例えば上記のシナリオでの findTransactionsByCustomer など) それぞれに対して実装しなければなりません。こうした種類のクエリーを実装するためには、データベースのスキーマに関する深い知識が必要となり、しかも非常に複雑なロジックを実装することになります。
検証ロジック
オブジェクトは固有の制約を持ちません。そのため、データの検証を実装するためには明示的にコーディングする必要があります。
上記からわかるように、データ・オブジェクトのラッパーはアプリケーション・コードの主要な部分を占めています。どのようなプロジェクトの実装でも、ビジネス・ロジックを実装することよりも、データ・オブジェクトの管理に大量の作業を行う羽目になってしまうものです。開発し、維持管理しなければならないコードは増え、そのためアプリケーションの開発サイクルは長くなり、そしてバグもコストも増大します。さらに、データ・スキーマが少しでも変更されると、オブジェクトの階層構造全体を変更しなければなりません。もしマッピングにサードパーティーのマッピング・ツールを使っている場合には、アプリケーションはそのツールに結びつけられ、ドメイン・レイヤーとデータベース・レイヤーの間が密に結合されてしまいます。
SOA の世界での動き
SOA (service-oriented architecture: サービス指向アーキテクチャー) は、対話動作を行うソフトウェア・エージェントの間に疎結合を実現しようとするアーキテクチャー・スタイルです。SOA は分散コンピューティングとモジュラー・プログラミングが進化したものです。SOA はソフトウェアのアトミック・サービスからアプリケーションを組み立てます。そうしたサービスは再利用可能なコンポーネントですが、非常に粒度が粗いものです。SOAP サービスと REST サービスはサービスのスタイルが異なり、サービスの記述方法は異なりますが、どちらもサービスのメッセージを XML で規定します (この XML は W3C の XML スキーマなどの言語で作成されたスキーマによって制限されます)。XML は、SOA の「通貨」と言うことができます。最近では、XML を SOA ソリューションのファーストクラスのドメイン・モデルとして採用する動きをさらに加速する開発が行われています。
ビジネス駆動型開発
俊敏で応答の速い企業になるためには、ビジネスのゴールと要件によって IT 開発プロジェクトを駆動することが必須です。SOA が業界で大きな支持を受けている理由は、SOA では、(サービス・インターフェースとデータ・フォーマットを定義する) 適切に規定された契約で結合されるサービスの連合としてエンタープライズ・ソリューションを考えるためです。SOA の世界では、プログラマーが特定の言語を使ってプログラムでドメイン・オブジェクトを作成するのではなく、ビジネス・アナリスト (あるいは業界標準) が XSD を宣言的に使い、また言語を独立に使うことでドメイン・オブジェクトを作成することが多くなっています。これが、「スキーマ・ファースト」という Web サービス、つまりSOA での「まずインターフェースorインターフェース・ファースト」というプログラミングの哲学です。
XQuery と XPath
XQuery 1.0 と XPath 2.0 が公開されたことによって、より強力で効率的なツールを利用できるようになっています。XML のユーザーは、これらを組み合わせて使うことで XML 文書全般を発見したり調べたりすることができ、またエンド・ツー・エンドの体系的な処理を行うために、ツリー構造で表現された、そうした文書の内部をナビゲートすることができます。XQuery で XML 文書を調査し、XPath でナビゲーションすることで、XML データを操作するための時間とコードの両方を削減することができます。
データベースでの XML サポート
新しくリリースされたデータベース (IBM DB2® v9 など) は、XML データをファースト・クラスのデータ型としてサポートしています。DB2 は拡張され、下記の機能を含んでいます。
- XML 文書特有の階層構造を効率的に管理するための新しい保管方法。
- XML 文書にまたがる検索や XML 文書内での検索を高速化する新しい索引付け技術。
- (XQuery のための) 新しいクエリー言語のサポートと、(XQuery のための) 新しいグラフィカル・クエリー・ビルダー、そして新しいクエリー最適化手法。
- ユーザーが提供するスキーマに基づいて行う XML データの妥当性検証を新たにサポート。
- 重要なデータベース・ユーティリティーのための拡張機能を含む新しい管理機能。
- 一般的な API (application programming interface) を統合することでネイティブ・サポートを実現。
DB2 では、クライアント・アプリケーションは、SQL あるいは XQuery を使うことで、テーブル構造と XML データ構造の両方を処理することができます (SQL の中には、XML 拡張機能を持つ SQL (よく SQL/XML と呼ばれます) が含まれます)。従って、たとえデータがリレーショナル・テーブルに保管されている場合であっても、そのデータをアプリケーション・レイヤーのための XML ストリームとして照会したり公開したりすることができます。
図 2. XML 機能とリレーショナル機能の統合
XML とオブジェクトのマッピング
SOA の世界では XML による Web サービスが答えであることを私達は知っています。それにもかかわらず私達は、好みのオブジェクト指向言語 (Java や C# など) を使って、オブジェクト・プロキシーを作成し、それを使用して Web サービスを送受信してしまう傾向があり、また基礎となる Web サービス・エンジンのツールキットによって XML メッセージが自動的にオブジェクトにバインドされることを期待しがちです。XML の方がテーブルよりもオブジェクトに適切にマッピングできることは明らかです。非常に単純なケースならば必ず適切にマッピングを行えますが、OAGIS や HL7、ACORD、IFX、OTA など、業界標準の XML 言語を使おうとすると、ツールキットのコード生成プログラムでは XSD の複雑さを処理できないかもしれません。たとえツールキットで処理できるとしても、無数のオブジェクトを作成し、また生成された無数のオブジェクト維持管理することは、実に負荷が重く、しかも柔軟性がありません。少しでもスキーマを変更しようとすると、完全にコードを再生成しなければなりません。しかもこのように生成された XML ベースのオブジェクトをナビゲートすることは、とても直感的と言えるものではありません。
XML をファーストクラスのプログラミング・モデルとして採用する
もし、
- ビジネス・アプリケーションが主にビジネス・データの作成と操作、保管、そして表示を行うものであり、
- ビジネス・データが次第に XML としてモデル化されつつあり、
- データベースが既にネイティブで XML をサポートしており、なおかつ、
- XPath と XQuery の新しいバージョンによって XML をはるかに効率的にナビゲートでき、操作できるのであれば、
そうした条件下では、オブジェクトとリレーショナル間のマッピング、つまり OX マッピングでの苦労から学んだすべての問題を考慮し、XML をファーストクラスのデータおよびプログラミング・モデルとして利用してはどうでしょう。
このモデルでは、アプリケーション・コードは DOM や JDOM、SDO (など) の API を使ってビジネス・ロジックを実行することができます。ナビゲーションに XPath を使うことで操作対象のビジネス・データの間の関係を説明できるため、アプリケーション・コードは理解しやすくなります。理想的には、データがデータベースの中に純粋な XML として保持されている必要がありますが、たとえデータがリレーショナル・テーブルに保管されている場合であっても、多くの場合にはアプリケーションの中で操作するために最初にデータを XML に変換することは、やはり適切なことです。
コーディングの削減
XML は本質的にデータ構造同士の関係を維持するため、個々のデータ構造の間の関係を取得するためにオブジェクトの階層構造を別途作成する必要がありません。しかも XML は既に DOM (Document Object Model) という標準のオブジェクト・モデルを持っています。このモデルを実装することで、XML データの作成と変更、そしてシリアライズを行うことができます。ビジネス・アプリケーションでは、XML データをロードし、変更し、保管することは些細な作業です。また、制約のチェックとスキーマの検証は XML モデルの中に組みこまれているため、もはやハンドコードによる検証ロジックは必要ありません。これらはどれも、コードを削減し (これは常に良いことです) 、バグの発生確率を下げ、維持管理の手間を減少させることにつながります。
容易なナビゲーションと柔軟性
データの正確な性質と、ビジネス構造とデータとの関係が XPath で記述されるため、ビジネス・ロジックのコードが読みやすくなります。また XPath 2.0 では、検索とナビゲーションのための機能が追加されています。さらに、XPath 式は非常に容易に外部化できるため、たとえ XML の構造が変化した場合でも、コードを変更せずに新しいパスを表すことができます。これは、特に SOA 環境で求められる柔軟性そのものです。
優れたパフォーマンス
この、XML を中心とした手法を使うことで、ガーベッジ・コレクションが必要となる余分なオブジェクトを作成する必要する必要がなくなるため、優れたランタイム・パフォーマンスを期待することができます。このパフォーマンスの違いは、非常に大規模な XML ファイルを処理する場合に一層顕著になります。
まとめ
典型的な SOA ソリューションでは、アプリケーションのさまざまなレイヤー (クライアントやプロセス、サービス・バス、そしてサービスなどのレイヤー) にまたがってデータをシリアライズする必要があります。こうしたフローのために最も適したデータ・フォーマットは XML です。データは各レイヤーで照会され、変換され、そして更新されます。そのため、XML としてのデータの性質が維持される限り、さまざまな言語 (Java や JavaScript™、PHP、または XQuery など) を使ってデータを操作することができます。XML 文書を取り巻く言語は異なったとしても、XML 文書をトラバースするために使われる言語は、どのレイヤーでも (外部化可能な、そしてすべてのレイヤーにまたがって共有可能な式を持つ) XPath で同じです。分散 SOA システムを構築するためには、この方がずっとスマートで一貫した方法に思えます。
参考文献
著者について  | 
| |
Peter Xu は IBM Software Services for WebSphere の Senior Managing Consultant であり、IBM の最大の顧客の何件かと直接業務を行いながら、IBM による広範な種類のソフトウェア製品やサービスをベースとする SOA ソリューションの設計とデプロイメントに対する支援を行っています。 |
記事の評価
| 
