Loading article…
ソフトウェアエンジニアリングにおいて、Canonical Schemaはサービス指向設計パラダイム内で適用される設計パターンであり、サービス[ 2 ]が同じデータモデルを参照するメッセージを交換する場合にデータモデル[ 1 ]変換を実行する必要性を減らすことを目的としています。 [ 3 ]
サービス間のやり取りでは、ビジネス文書の交換が必要になることがよくあります。サービス利用者がデータ（特定のビジネスエンティティに関連するデータ、例えば発注書など）を送信するには、データの構造、つまりデータモデルを知る必要があります。そのため、サービスプロバイダは、サービス利用者からの受信メッセージに含まれるデータの構造を公開します。Webサービスとして実装されているサービスの場合、[ 4 ]これはXMLスキーマ文書になります。サービス利用者は必要なデータモデルを知ることで、それに応じてデータを構造化できます。しかし、状況によっては、サービス利用者が特定のビジネス文書に関連する必要なデータを既に持っているものの、そのデータがサービスプロバイダによって指定されたデータモデルに準拠していない場合があります。このようなデータモデルの不一致により、サービスプロバイダが指定する必要な構造にメッセージを変換するためのデータモデル変換が必要になります。前述の例を基にすると、サービスプロバイダは受信したビジネス文書を処理した後、処理済みの文書をサービスコンシューマに送り返し、サービスコンシューマはデータモデル変換を再度実行して、処理済みのビジネス文書を、ロジック内でビジネス文書を表すために使用するデータモデルに変換するということが十分に考えられます。 この実行時データモデル変換は、処理オーバーヘッドを増やし、サービス構成の設計を複雑にします。[ 5 ]データモデル変換の必要性を回避するために、Canonical Schema パターンでは、サービスインベントリ内のサービスによって共通して処理されるビジネス文書に対して標準化されたデータモデルを使用することを規定しています。[ 6 ] [ 7 ]
この設計パターンは、標準化されたサービス契約設計原則の適用によって完全にサポートされています。標準化されたサービス契約設計原則は、サービス契約が標準化されたデータモデルに基づいていることを推奨しています。これは、サービス間で交換される共通のビジネス文書を見つけるために、サービスインベントリブループリント[ 8 ]の分析を実行することによって実現されます。これらのビジネス文書は、標準化された方法でモデル化されます。たとえば、Webサービスの場合、ビジネス文書はXMLスキーマとしてモデル化されます。サービスインベントリに標準化されたデータ表現レイヤーが存在すると、異なるサービス契約が同じビジネス文書を交換する必要がある場合に、同じデータモデルを使用できます。これにより、データモデル変換の必要性がなくなり、データモデル変換に関連する処理オーバーヘッドが削減されます。また、カスタムデータモデル変換ロジックを必要とせずにサービスを利用できるため、サービスの再利用性も向上します。ある意味で、正規スキーマパターンの適用は、データモデル変換[ 9 ]設計パターンの適用の必要性を低減します。
この設計パターンを適用するには、標準化されたデータ モデルの使用を必須とする設計標準[ 10 ]が必要です。データ モデルを作成しただけでは、その使用が保証されるわけではありません。 [ 11 ]原則的には単純ですが、さまざまなプロジェクト チームからのコミットメントが必要であり、標準化されたデータ モデルに対応するソリューションを設計するという点で各チームに追加の労力がかかる可能性があるため、強制するのは困難です。 組織の規模が大きすぎる場合や、企業のさまざまな部門からの抵抗がある場合など、場合によっては、ドメイン インベントリ設計パターンを適用して作成された特定のドメイン インベントリ内で、カノニカル スキーマ設計パターンを適用する必要があるかもしれません。 [ 7 ]スキーマ は、サービス契約設計とは別に設計する必要があり、それらの間に依存関係がないようにする必要があります。[ 11 ]