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

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

この記事では、XML の妥当性検証に OASIS の CAM (Content Assembly Mechanism) テンプレートを使用する方法について説明します。CAM テンプレートを使用することで、B2B や B2C のビジネス・パターンを使用するビジネス・パートナーと多種多様で複雑なメッセージ交換をすることができます。CAM テンプレートによって妥当性検証ルールを単純化、外部化できる一方、直接関係のない情報に対してはゲートウェイをパススルーさせることができます。またこの記事では私達が経験した内容として、妥当性検証サービスを提供するために、Eclipse と Java™ 技術で作成されたオープンソースのコンポーネントを使用する方法についても説明します。ここではアプリケーションの開発プロセスについて順を追って説明し、またコード・スニペットと XML の例として、STAR (Standards for Technology in Automotive Retail) の Automotive BOD (Business Object Document) スキーマとその関連の CAM XML テンプレートを使った例についても説明します。

Puneet Kathuria, Advisory IT Architect, IBM

Photo of Puneet KathuriaPuneet Kathuria は IBM India に勤務する統合アーキテクトです。彼は主にアプリケーション・アーキテクチャーや統合アーキテクチャーで 13 年以上の経験があり、4 年前から IBM に勤務しています。



David Webber, Senior Architect, INTEGRITYOne Partners

Photo of David WebberDavid は現在、米国政府の NIEM IEPD 開発のコンサルティングを行っており、米国ワシントン特別区を拠点としています。彼は OASIS CAM 技術委員会の議長であり、XSLT 処理スクリプトの大部分を処理する CAM Studio Eclipse エディターの共同開発者でもあります。彼はこの業界に 30 年以上の経験があり、2007年には、XML に関する業界での業績から ACM のシニア・メンバーに認定されました。彼は XML や情報交換最適化、OASIS 標準化仕様などに関して多くの記事を執筆しており、また北米、欧州、アジアで XML に関して幅広く講演を行っています。



Martin Roberts, CAM Open Source Project Developer/Designer, Ontology Systems

Photo of Martin RobertsMartin はイギリスの Suffolk を拠点に活動するコンサルタントであり、XML、オントロジー、Java、Eclipse、Web ソリューションなどの専門分野で 20 年以上の経験を持っています。彼は最初の OASIS CAM 仕様と CAM Studio Eclipse エディター、そして CAMV 検証エンジンの実装、という両方を作成しました。また彼は以前、ヨーロッパの通信業界で XML ベースのメッセージ交換や標準化に関する業務を行っていました。彼は主にヨーロッパでの OASIS 後援の技術展示会を含め、いくつかの業界イベントで講演を行っています。



2010年 5月 11日

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

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

よく使われる頭字語

  • API: Application Programming Interface
  • B2B: Business-to-Business
  • B2C: Business-to-Consumer
  • DTD: Document Type Definition
  • HTTP: HyperText Transfer Protocol
  • JAX-RPC: Java API for XML-Based Remote Procedure Call
  • JDOM: Java-based Document Object Model
  • J2EE: Java 2 Platform, Enterprise Edition
  • OASIS: Organization for the Advancement of Structured Information Standards
  • UI: User Interface
  • WSDL: Web Services Description Language
  • XML: Extensible Markup Language
  • XPath: XML Path Language
  • XSD: XML Schema Definition
  • XSLT: Extensible Stylesheet Transformations

業界特有の標準、例えば 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 メッセージング・レイヤーはメッセージ・コンシューマーとメッセージ・プロバイダーの中間に位置しています。

開発者が直面する大きな課題の 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 (モデル化) ステージ

このステップでは、データ・エンティティーおよびそのデータ要素を特定するとともに、各エンティティーやデータ要素に対応する妥当性検証ルールも特定します。また、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 では妥当性検証の失敗を 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 文字を超えていないかどうかをチェックします。

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 式でルールを定義する場合のスクリーン・キャプチャー

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

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

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

まとめ

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

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

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

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

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


ダウンロード

内容ファイル名サイズ
Sample Java project that uses CAMV Java APIsValidationFrameworkSample.zip2032KB

参考文献

学ぶために

製品や技術を入手するために

  • OASIS CAM の仕様をダウンロードし、その内容を学んでください。
  • IBM 製品の評価版をダウンロードするか、あるいは IBM SOA Sandbox のオンライン試用版で、DB2®、Lotus®、Rational®、Tivoli®、WebSphere® などが提供するアプリケーション開発ツールやミドルウェア製品を試してみてください。

議論するために

  • XML zone discussion forums に参加してください。これらのフォーラムでは XML を中心に議論が行われています。
  • developerWorks blogs から developerWorks のコミュニティーに加わってください。

コメント

developerWorks: サイン・イン

必須フィールドは(*)で示されます。


IBM ID が必要ですか?
IBM IDをお忘れですか?


パスワードをお忘れですか?
パスワードの変更

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


お客様が developerWorks に初めてサインインすると、お客様のプロフィールが作成されます。会社名を非表示とする選択を行わない限り、プロフィール内の情報(名前、国/地域や会社名)は公開され、投稿するコンテンツと一緒に表示されますが、いつでもこれらの情報を更新できます。

送信されたすべての情報は安全です。

ディスプレイ・ネームを選択してください



developerWorks に初めてサインインするとプロフィールが作成されますので、その際にディスプレイ・ネームを選択する必要があります。ディスプレイ・ネームは、お客様が developerWorks に投稿するコンテンツと一緒に表示されます。

ディスプレイ・ネームは、3文字から31文字の範囲で指定し、かつ developerWorks コミュニティーでユニークである必要があります。また、プライバシー上の理由でお客様の電子メール・アドレスは使用しないでください。

必須フィールドは(*)で示されます。

3文字から31文字の範囲で指定し

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


送信されたすべての情報は安全です。


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