目次


OASIS CAM (CAMV) を使った XML 妥当性検証フレームワーク

宣言型のプログラミング手法を使って XML データの妥当性検証ルールを作成する

Comments

ビジネス上の課題と技術的な課題

今日行われている、XML および XML に付随する大規模な XSD スキーマを使った複雑な情報交換では、これに一連の取引相手が加わるため、受信したすべてのトランザクションの正確な処理をサポートし、維持することが重要な課題となっています。現在、XML 文書の構造的な内容の妥当性検証をする (つまり確認する) 機能は、XML スキーマと DTD によって提供されています。特定の妥当性検証ルールを XML スキーマの一部として含めることもできますが、あらゆる種類のトランザクションの妥当性検証を XML スキーマや DTD を使って行えるわけではありません。

業界特有の標準、例えば STAR (Standards for Technology in Automotive Retail) などの登場により、標準的な XML メッセージ交換フォーマットがすべて XML Schema の形で提供されています。Web サービスの利用者 (コンシューマー) もプロバイダーも、これらのスキーマに準拠しない限り業界標準化団体による認定を受けることができません。しかし、そうした業界特有のスキーマによる制約は緩く、妥当性検証は最低限であるため、受信した XML の構造検証以外には使用できません。スキーマによるチェックを補うために必要な妥当性検証を実装するためには、追加のコードが必要です。アプリケーションやコンポーネントがデータに対して、特定の構造をしていること、そしてビジネス・コンテンツの妥当性検証ルールに準拠していること、を要求している場合には、こうした妥当性検証用のコードを追加することによってデータ受信の際のエラーを防ぐことができます。

Web サービスや Web サービス関連の XML アプリケーションに必要な妥当性検証ロジックを実装するための最も一般的な方法は、カスタム・コードを作成する方法です。その結果、妥当性検証ルールはアプリケーションの中に組み込まれてしまい、他への適用や、文書化、共有が困難になります。必要な妥当性検証の数や性質によっては、妥当性検証コードは複雑で長くなり、取引先が追加されるにつれて保守が大きな負担になってきます。それに加え、検証ロジックが変更されるたびに本番サーバーにコードを再コンパイルして再デプロイする時間と手間、そしてリスクを伴うことになります。

スタンドアロンのアプリケーションの場合だけではなく、ESB (Enterprise Service Bus) を介してサービスを公開する場合にも妥当性検証が必要です。図 1 はメッセージング・バスに注目した場合の ESB の典型的なアーキテクチャーを示しています。このバスは、SOAP、HTTP、JMS (Java Messaging Service) などの標準に基づくメッセージ配信サービスを提供します。ESB により、個々のトランザクションのサービス品質要件に基づき、サービス同士がやり取りすることができます。また ESB は、SOAP、XML、WSDL、JMS、J2EE、JAX-RPC など、多様な標準もサポートしています。

図 1. ESB アーキテクチャーで妥当性検証を実行する方法
ESB のメッセージング・レイヤーを示すブロック図。ESB メッセージング・レイヤーはメッセージ・コンシューマーとメッセージ・プロバイダーの中間に位置しています。
ESB のメッセージング・レイヤーを示すブロック図。ESB メッセージング・レイヤーはメッセージ・コンシューマーとメッセージ・プロバイダーの中間に位置しています。

開発者が直面する大きな課題の 1 つは、ESB を介してメッセージが交換される中で、メッセージ・プロバイダーのエンドポイントとメッセージ・コンシューマーのエンドポイントでどのようにして妥当性検証を行うか、という点です。例えば図 1 にあるように、Web サービスのコンポーネントは既存のアプリケーションからの情報を要求するかもしれません。その Web サービス (コンシューマー) は ESB を介してメッセージ要求情報を既存のアプリケーション (プロバイダー) に送信します。アプリケーションのコンポーネントはリクエストが特定のフォーマットに従って適切な情報を含むことを要求するため、妥当性検証を行ってからリクエスト・メッセージを処理します。Web サービスのコンポーネントも独自の要件があるため、レスポンス・メッセージの妥当性検証を行います。この 2 つのエンドポイントが異なるプロトコルや標準を使用している場合には、ESB は各メッセージを変換し、妥当性検証を行ってからメッセージの変換を行います。

各プロバイダーとコンシューマーには独自の要件があります。そのため、トランザクションのタイプや妥当性検証の数により、すべての妥当性検証を定義、作成、テストしようとすると開発サイクルが長くなります。この安定化フェーズは、各妥当性検証コンポーネントが呼び出し側コンポーネントに対してメッセージの妥当性検証に関する適切なフィードバックを提供できるようになるまで続きます。

ソリューションの説明

ここで説明するソリューションでは、OASIS の CAM (Content Assembly Mechanism) 仕様に基づいて XML 妥当性検証サービスを実装します。OASIS CAM テンプレートによる方法では、単純な方法で XML コンテンツの処理と妥当性検証を行うため、ビジネスは XML による交換を行うための共通の交換モデルを作成することができます。CAM テンプレートはコンテキスト・ベースのルール、コード・リスト、クロスフィールドでの妥当性検証をサポートしています。クロスフィールドでの妥当性検証の多くは XSD スキーマのみでは実装できません。また場合によると、公開された業界スキーマですべての妥当性検証のバリエーションに対応することはできない場合もあります。

この記事で紹介するソリューションには CAM Studio (Eclipse ベースの UI テンプレート・エディター) が含まれており、この CAM Studio を使って CAM テンプレートを定義します。また CAMV 妥当性検証エンジンにはオープンソースの Java API が用意されており、これらの API を使用することで、コンパイルされた特定の CAM テンプレートによって実行時に XML の妥当性検証を行うことができます。CAM Studio テンプレート・エディターでは、このエディターで生成されたテンプレートにカスタムの XPath 式を追加することができますが、大部分のルールは UI で定義することができ、カスタムの式を作成する必要はありません。

図 2 は、妥当性検証ルールを作成するためのライフサイクルの各ステージすなわち、Model (モデル化)、Author and Test (作成およびテスト)、Deploy (デプロイ)、Monitor (監視) を示しています。

図 2. 妥当性検証ルールのライフサイクル
妥当性検証ルールを作成するためのライフサイクル (Model (モデル化)、Author and Test (作成およびテスト)、Deploy (デプロイ)、Monitor (監視)) を示す図
妥当性検証ルールを作成するためのライフサイクル (Model (モデル化)、Author and Test (作成およびテスト)、Deploy (デプロイ)、Monitor (監視)) を示す図

Model (モデル化) ステージ

このステップでは、データ・エンティティーおよびそのデータ要素を特定するとともに、各エンティティーやデータ要素に対応する妥当性検証ルールも特定します。また、XML 交換に必要なスキーマを設計します。あるいは、必要な要素を、既存の業界標準スキーマ、例えば STAR (Standards for Technology in Automotive Retail) スキーマなどにマッピングします。

Author and Test (作成およびテスト) ステージ

CAM Studio エディターを使って CAM テンプレートを組み立てたり、作成したりします。エディターで CAM テンプレートを作成するための手段としては、下記の 3 つが考えられます。

  1. ゼロから、つまり手動で作成する
  2. 既存の XML Schema を使う
  3. 既存の XML インスタンスを使う

CAM テンプレートを作成したら、次のステップとしてすべての要素と属性を調べ、各要素と属性に対して妥当性検証ルールを指定します。エディターのパネルには各テンプレート・ノードに対するルールが表示されます。図 3 はテンプレートの構造を表示した CAM Template Editor のスクリーン・キャプチャーです。

図 3. CAM Template Editor に表示された CAM テンプレート
テンプレートの構造の概要を表示した CAM Template Editor のスクリーン・キャプチャー
テンプレートの構造の概要を表示した CAM Template Editor のスクリーン・キャプチャー

必ずしもすべての妥当性検証ルールに対する結果が成功もしくは失敗である必要はなく、CAM では妥当性検証の失敗を Warning (警告) に分類することもできます。この機能が重宝するのは、修正アクションをサービス・プロバイダー側で行い、メッセージ全体を拒否せずにペイロードを変更してメッセージを使用可能にするようなケースです。例えば、あるルールでは特定のコメント・フィールドの長さが 255 文字以内でなければならないとします。その場合、リクエスト・メッセージの長さが最大値を超えても、そのメッセージを拒否すべきではありません。代わりに、そのコメントの最初の 255 文字のみが使用されることを伝える警告をコンシューマーに送信する必要があります。

妥当性検証メッセージを警告に分類する方法についての詳細は、この記事の「ヒントと秘訣」セクションで説明します。

Deploy (デプロイ) ステージ

CAM テンプレートは CAM Studio エディターを使ってコンパイルされ、アプリケーションのランタイム CAMV エンジンで使用されます。コンパイルされたフォーマットは元の CAM テンプレート自体を凝縮した XML であり、CAMV 妥当性検証エンジンのパフォーマンスを最適化するように設計されています。CAM テンプレートをコンパイルするためには、メニュー・バーから「Tools (ツール)」 > 「Compile Template (テンプレートのコンパイル)」の順に選択します。すると .cxx ファイル・フォーマットのテンプレートが生成され、このテンプレートが実行時に使用されます。

CAMV 妥当性検証エンジンにはオープンソースの簡単な Java API が用意されており、この API を使用することで、任意の Java アプリケーションで適切な CAM テンプレートを使って入力 XML の妥当性検証をすることができます。リスト 1 のコード・スニペットは CAMV の使い方を示しています。

リスト 1. AMV API の使い方
TemplateValidator tv = new TemplateValidator(templateDocument);
tv.setErrHandler(new ElementErrorHandler(tv));

boolean tvResult = tv.validate(ioReader);

if (tvResult){
        System.out.println("No errors, might be warnings.....");
}

List errList = tv.getErrors();
List warnList = tv.getWarnings();

エラー・メッセージと警告メッセージのフォーマットは以下のとおりです。

<エラーの分類>: <XPath> => <エラーまたは警告メッセージ> => Node: <ノード名> => attribute: <属性名>

例えばエラー・メッセージは以下のようになります。

/p:ProcessRepairOrder[1]/p:ApplicationArea[1]/p:CreationDateTime[1]=>Content does not conform to the mask:YYYY-MM-DD'T'HH:MI:SSZ =>Node: CreationDateTime

(/p:ProcessRepairOrder[1]/p:ApplicationArea[1]/p:CreationDateTime[1]=>コンテンツが YYYY-MM-DD'T'HH:MI:SSZ というマスクに従っていません =>Node: CreationDateTime)

警告メッセージは以下のようになります。

Warning: /p:ProcessRepairOrder[1]/p:ProcessRepairOrderDataArea[1]/p:RepairOrder[1] /p:RepairOrderHeader[1]/p:OwnerParty[1]/p:SpecifiedPerson[1]/p:ResidenceAddress[1] /p:LineOne[1]=> length should be less than 80 =>Node: LineOne

(警告: /p:ProcessRepairOrder[1]/p:ProcessRepairOrderDataArea[1]/p:RepairOrder[1] /p:RepairOrderHeader[1]/p:OwnerParty[1]/p:SpecifiedPerson[1]/p:ResidenceAddress[1] /p:LineOne[1]=> 長さが 80 未満でなければなりません =>Node: LineOne)

Monitor (監視) ステージ

CAMV を使用すると、すべての妥当性検証チェックを外部化することができ、コードの中に埋め込んだり、カスタム・コードを使って実装したりする必要はありません。監視サイクルの間に妥当性検証を追加する必要がある場合には、妥当性検証テンプレートを更新するだけでのことです。妥当性検証を追加する場合や既存の妥当性検証を削除する場合には、コンパイルされた CAM テンプレート (.cxx ファイル) を再配布します。妥当性検証ロジックを変更しても、Java コードの再コンパイルや再デプロイは必要ありません。

最新の CAMV リリースの新機能

最新 (2009年 12月) の CAMV リリースに追加された重要な機能は以下のとおりです。

  1. デフォルトの Java 1.6 用のダウンロードの他に、後方互換性のある Java 1.5 用のリリースをダウンロードすることができます。
  2. CAMV がスレッドセーフになりました。そのため、WebSphere® Application Server など任意の J2EE コンテナーに CAMV をデプロイすることができます。
  3. CAMV は JDOM 文書として XML 入力を受け付けるだけではなく、StringReader として XML 入力を受け付けられるようになりました。そのため、メッセージ処理の際にシリアライズやデシリアライズの必要がなくなります。
  4. 1 つの XML 要素または属性に複数の条件を定義できるようになりました。

ヒントと秘訣

以下のヒントと秘訣は、私達が最近従事したプロジェクトから得られたものです。このプロジェクトでは CAMV を使用して B2B ゲートウェイ用の妥当性検証フレームワークを作成しました。この B2B ゲートウェイを介して STAR ベースの Web サービスが自動車業界大手の組織に提供されています。

妥当性検証の分類

CAMV では、エラー・メッセージの他に警告メッセージも提供できる妥当性検証ルールを作成することができます。警告メッセージを提供する妥当性検証を指定するためには、その XML 要素に対し、条件付きの XPath 式を指定する必要があります。

例えばビジネス・シナリオの例として、Web サービス・リクエストの特定のフィールドが 255 文字という指定制限を超えても、そのリクエストを拒否する必要がない場合を考えてみてください。ビジネスの判断としては、そのフィールドの長さが 255 文字を超えた場合にはバックエンド・システムの要件に従って 255 文字を超えた分は切り捨て、ただし呼び出し側のコンポーネントには警告を発行する必要があります。

そうしたシナリオを処理するためには、CAM テンプレート・ルールで printmessage() 式を指定します。

メッセージ・テキストは「Warning:」という接頭辞を持つ必要があり、その後に、例えば「length should be less than 255 (長さは 255 未満でなければなりません)」など、必要な警告メッセージを続けます。完全なメッセージ・テキストは「Warning: length should be less than 255 (警告: 長さは 255 未満でなければなりません)」のようになります。

警告が返されるのは、特定の要素が指定の長さを超過した場合のみであるため、このルールは「Conditional (条件付き)」と指定され、長さをチェックするための XPath 式が作成されます。これを示したものが図 4 です。このスクリーン・キャプチャーは CAM Studio エディターの式入力ウィザード・ツールをキャプチャーしたものです。

図 4. 警告ルールを構成する方法
警告メッセージ用のルールのスクリーン・キャプチャー。このルールでは文字の長さが 255 文字を超えていないかどうかをチェックします。
警告メッセージ用のルールのスクリーン・キャプチャー。このルールでは文字の長さが 255 文字を超えていないかどうかをチェックします。

CAMV テンプレートをキャッシュする

CAMV テンプレートをメモリーにキャッシュすると、妥当性検証を繰り返し実行することができ、妥当性検証を実行するたびにハードディスクからテンプレートを読み込む必要がなくなります。こうすることでディスク I/O が減少し、パフォーマンスとスループットを大幅に改善することができます。

妥当性検証エラーをチェックする

CAMV の Java メソッド TemplateValidator.validate(..) は、警告が返された場合にも true を返します。このメソッドが false に設定されるのはエラーが返された場合のみです。従って、警告のみが返される場合には getWarnings() メソッドを使用し、返された警告メッセージをすべて取得します。

妥当性検証メッセージ

返されたメッセージ (XPath パス、妥当性検証メッセージ、ノード名を含みます) ではビジネス・シナリオに十分ではなく、さらに情報が必要な場合には、クライアント・アプリケーションがカスタム・コードを作成することができます。CAMV は、入力交換メッセージの XML にCAMERROR 属性と CAMWARN 属性を追加した後、リスト 2 と同じ入力 XML を返します。

リスト 2. 妥当性検証の実行後に変更された XML
<p:ApplicationArea>
<p:Sender>
<p:CreatorNameCode>CNV</p:CreatorNameCode>
<p:SenderNameCode>SNC</p:SenderNameCode>
</p:Sender>
<p:CreationDateTime CAMERROR="CreationDateTime | Content does not conform to the
mask:YYYY-MM-DD'T'HH:MI:SSZ">2001-12-31T12:00:00</p:CreationDateTime>
<p:Destination/>
</p:ApplicationArea>

<p:ResidenceAddress>
<p:LineOne CAMWARN="WARNING:LineOne |  length should be less than 80">100 Moon Drive 
100 Moon Drive 100 Moon Drive 100 Moon Drive 100 Moon Drive 100 Moon Drive</p:LineOne>
<p:LineTwo>APT # 100</p:LineTwo>
<p:CityName>MALIBU</p:CityName>
<p:CountryID>US</p:CountryID>
<p:Postcode>99999</p:Postcode>
<p:StateOrProvinceCountrySub-DivisionID>CA</p:StateOrProvinceCountrySub-DivisionID>
</p:ResidenceAddress>

ワイルドカード式

テンプレートにルールを入力する際、XPath 妥当性検証式の指定には (デフォルトで) 二重スラッシュ (//) によるワイルドカード式を使います。この指定方式により、文書の中の現在のノードから、選択基準に一致するノードがすべて (ノードの場所によらず) 選択されます。

図 5. ワイルドカード式を指定してルールを定義する方法
(ワイルドカードの値として) 二重スラッシュを使った XPath 式でルールを定義する場合のスクリーン・キャプチャー
(ワイルドカードの値として) 二重スラッシュを使った XPath 式でルールを定義する場合のスクリーン・キャプチャー

こうすることで、ある特定要素の該当インスタンスすべてにルールが適用されます (注: ある特定要素の該当インスタンス以外のインスタンスでは、適用されたルールが即座に表示されるとは限りません。ただし CAM テンプレート・エディターのビューの中でテンプレートを更新すると、適用されたルールが表示されます)。

ただし、ある XML 要素の特定のインスタンスに対してチェックをする必要がある場合には、Rule XPath チェック・ボックスの「Full (フル・パス)」を選択することが適切です。

図 6. 明示的に式を指定してルールを定義する方法
ルールで明示的に XPath 式を指定する場合のスクリーン・キャプチャー
ルールで明示的に XPath 式を指定する場合のスクリーン・キャプチャー

まとめ

CAMV を使用すると、一貫性のある形で妥当性検証によるチェックを強制することができ、また素早くルールを変更してメッセージ処理を微調整し、特定の取引相手との交換方式やコンテンツに合わせることができます。従来はバックエンド・アプリケーションのコードの奥深くに埋め込まれていた妥当性検証ルールを外部化することで、メッセージ処理に関して予測性を高めるとともに極めて適切な制御と管理を実現します。

また、こうした標準に基づくルール・テンプレートを取引相手と共有すると、システム全体にわたって適切なコンテンツ処理を容易に行えるようになります。

より柔軟で耐障害性の高いプロセスを使用することで、アプリケーションが処理できるコンテンツのバリエーションが広がります。その結果、多種多様な取引相手と容易にやり取りできるようになり、サポートや保守のコストも削減することができます。通常の方法では、そうしたことは実現できません。

オープンソースを利用したことで、ソリューション開発を行う上での連携作業や、開発環境に CAMV エンジンを統合する作業は非常に容易に行えました。

このプロジェクト全体として、XML の革新的な使い方、そして動的に構成可能な XML ルール・テンプレートにより、静的にコンパイルされたコード・リソースのみに依存する場合よりも、アプリケーションに対するユーザー・エクスペリエンスが適切で安定、高速、高機能になることが実証されました。


ダウンロード可能なリソース


関連トピック


コメント

コメントを登録するにはサインインあるいは登録してください。

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=XML, Java technology
ArticleID=494526
ArticleTitle=OASIS CAM (CAMV) を使った XML 妥当性検証フレームワーク
publish-date=05112010