IBM、Microsoft、AribaによるWeb Services Description Language (WDSL) スキーマ 開発がこの9月に完了しました。これは、Web Servicesのインフラストラクチャーを整備する努力の ほんの始まりに過ぎません。WSDL開発チームを含む130の企業が 参加したUniversal Description, Discovery and Integration (UDDI) もまた、より基礎的な面を扱うインフラストラクチャーです。こうして着々と準備が進むのと同時に、これらの仕様をベースに現実の実装を創り出す方法も すでに整い始めています。IBMのAlphaWorksの広範な一連のツールや、Microsoft.NET路線などがあります。Web Servicesの先導役となっている企業が 相次いでツールを発表したことにり、より大きな枠組みが生み出され、これらのツールはこの枠組みの中にしっかり組み込まれるでしょう。

しかし、既存のアプリケーションの中にWSDL形式を取り入れるために、統合WSDLツールの登場を待っている必要はありません。WSDLに関しては、World Wide Web Consortiumの万能型 ツールキットExtensible Stylesheet Language for Transforms (XSLT) を 使ってできることがたくさんあります。誰もが認めるとおり、XSLTはW3Cの誇る成果の1つです。単独製品と組み込み製品を合わせて、すでに20をはるかに超える実装が提供されています。なお、この記事を読み進めるためには、XSLTとResource Description Framework (RDF) についての知識が必要です。

年季の入ったプログラマーから、(新しいキャッチフレーズXML使って何か凄いことができないかと 試行錯誤している) Webマスターたちに至るまで、たくさんのXSLTユーザーが現れました。しかしXSLTは主に、XMLという無数の卵を1つ1つ検査するための 最新鋭ツールとして使われています。XSLT仕様が誕生するやいなや、Eric van der Vlist氏は、今はもう忘れ去られたパーサーにXMLを 取り入れるためにXSLTの手を借りました。Rick Jeliffe氏のSchematronはXSLTによって強化され、名前空間を使ったさまざまなXMLボキャブラリーを妥当性検査する 手法を提供しましたが、その間、XMLスキーマの方は開発が遅れがちでした。そこで、なんと大胆なことに、XMLスキーマ自体を妥当性検査するSchematronバリデーターまで 登場しました。この精神に見習って、この記事では、WSDLの実用面を初期探査するプローブとして使います。

WSDLに秘められたデータを発掘する

Web Serviceに関するホワイト・ペーパーや イエロー・ペーパーの作成者たち、それにサービス提供者たち自身も、さまざまなレポート形式やカタログ形式でWSDL記述から データを取り出すことに興味をお持ちでしょう。データ抽出およびレポートを行うためのツールとして、XSLTは優れています。

WSDLに関する最初の記事 (「参考文献」を参照) では、特定製品を推奨しているプロ・スノー・ボーダーはだれかを 問い合わせるサービスの記述を例として示しました。このサービスの要求と応答は、Simple Object Access Protocol (SOAP) を使って送信されます。リスト1 は、記述に従って、一連のサービスを簡単なテーブル (表) として示すXSLT変換です。これらのサービスのトランスポートや場所に関する情報もまた、抽出されます。

このように簡単な目的の場合でさえ、ずいぶん複雑な変換になってしまいます。この複雑さの原因の1つは、WSDL 1.0が少し手の込んだ内容になっているためです。たとえば、関係は、XML名前空間から派生する修飾名形式の属性を使って指定されます。しかしXSLT 1.0は、XML名前空間の範囲を超える 名前空間拡張の手法を提供していません。この点は、XSLT 1.1にぜひ追加すべき機能としてXSLT関係者の間で 既に話し合われました。WSDL、XMLスキーマ、それにXSLT自体などのさまざまな仕様が、修飾名を含むようになったからです。この機能が盛り込まれれば、リスト1はもっとすっきりするでしょう。

リスト1 のtemplate 1.1は、単にHTML定形文面をセットアップするだけです。次に、キーを使った一連のルックアップ (Lookup) テーブルが並んでいます。すべてのキーが実際に使われているわけではありませんが、リスト1の中では、基本的なパターンを示すために、Lookup table 1.1から1.4までを含めました。キーは最上位WSDLコンポーネントを表す要素ノードを収集し、name要素を使って索引が付けられます。

Lookup table 1.5はもっと面白いです。変換の後半では、各ポートのバインディング中に指定される トランスポートをリストします。WSDLは、"binding" というローカル名を使った要素の中で これを指定しています。Lookup table 1.5は、WSDLのそれぞれのbinding要素の中から、この要素を取り出します。

Template 1.2は、それぞれのWSDL service要素ごとにテーブルを生成します。その大部分は平凡なXSLTです。必要なデータを単純な方法で切り出すために、「プッシュ」モデル (テンプレート・マッチ) ではなく、「プル」モデル (明示ループおよびXPathを使った値検査) を 使用しています。中心的なループが、service要素の各ポートに対応する行を取り出します。ラベルの後、location 属性が、"address" というローカル名の要素から表示されます。WSDLは2つの "address" 要素タイプ (1つはSOAP用、もう1つはHTTP用) を指定しているため、ローカル名のみが検査されることに注意してください。さらに、変換でサポートされる拡張子を使用できることにも 注意してください。

次に来るのは、binding-uri 変数を使用し、最終的にbinding-local-name を使用するトランスポートです。この2つの変数はどちらも、xsl:for-each そのものの中で定義されています。binding-local-name の定義をご覧になれば、属性における修飾名の問題について 私が述べたことの意味をわかっていただけるでしょう。ポートのバインディング属性の内容と、それに対応するWSDLバインディング要素をマッチングするするために、名前空間の接頭部を取り去る必要が あります (substring-after() 関数がこれを実行します)。

binding-uri 変数は、binding-local-name をLookup table 1.5への 索引として使用します。このテーブルは、すでに述べたように、それぞれのバインディング名をトランスポート固有binding要素の 名前空間URIにマップします。今回の例では、binding-uri がSOAPのURI (http://schemas.xmlsoap.org/wsdl/soap/) となっています。最後に、3つ目のテーブル・セルでは、binding-uri がLookup table 1.6への 索引として使われています。このテーブルは、名前空間URIを "SOAP" のような記述文字列に変換します。

Lookup table 1.6は高度なXSLTテクニックを使っていますから、よく観察してください。別個の名前空間を使って、ルックアップ・テーブルをスタイル・シートそのものの中に作成しています。キーのすぐ下に、x:ns-to-binding 要素があります。キーについて詳しい知識のある読者は、キーによって定義される索引が、match 属性のパターンにマッチする、元のソース・ドキュメント内のノード上に作成される ことにお気付きでしょう。少しわかりにくいかもしれませんが、XSLTdocument() 機能を使って 追加のソース・ドキュメントがロードされるたびに、すべてのキーもまた、そのソース・ドキュメントに適用されます。変換の終了タグ直前のxsl:variable は、特別な形のdocument() 呼び出しを使って、スタイル・シートそのものを追加のソース・ドキュメントとしてロードします。こうして、ns-to-binding にマッチするスタイル・シート内のノードに、索引が付けられます。この手法は、ソース・ドキュメントを開いたり 余分なファイルに依存したりすることなく、ルックアップ・テーブルを設定するための優れた方法です。この記事の後の部分で、この手法をもう1度使用します。

この変換を実行するにあたり、私は自分の4XSLTアプリケーション (「参考文献」を参照) をUnixコマンド行から次のように実行しました。

お気付きのように、元のサンプルWSDLソースとリスト1スタイル・シートを オンラインで利用できるようにしました。詳細については、「参考文献」を参照してください。図1は、この変換の結果出力です。

この変換を拡張して、WSDLソースからたとえばメッセージ部分などの追加情報を 抽出する方法については、説明する必要がないでしょう。次のセクションでは、より複雑かつ別の角度から焦点を 当てたXSLT変換について見ていきましょう。

上に戻る

WSDLからRDFを生成する

WSDLに関する前回の記事では、WSDL用RDF形式の可能性について触れました。WSDLはRDFと同じように単なる説明ですから、RDFはWSDL用として理想的な形式であろうと私は述べました。幸いにもRDFは非常にフレキシブルですから、元のWSDLとほとんど変わらないRDF準拠形式を 考え出すことができたわけです。今回は、変換を自動化する様子を見ていきましょう。

リスト2 の変換を使って、最初の記事のWSDLサンプルを、2番目の記事で取り上げたサンプルのようなRDFバージョンに 変換することができます。

まず注意していただきたいのは、リスト1 の変換 では (xsl:for-each 指示に基づく) 「プル」モデルを 使ってサービス内のさまざまなポートを変換したのに対して、このスタイル・シートは、ほぼ全般的に「プッシュ」技法に基づいています。注意深くマッチングされた適切なモードのテンプレートが、実行パスを設定します。XSLTのビギナー・ユーザーのほとんどは、プル・テクニックの方がわかりやすいと感じるでしょう。この方が、たとえばECMAScriptのようなプロシージャー・モデルに なじみのある人にとって自然だからです。このため、上の変換を理解するには少し骨が折れるかもしれませんが、これは、1つのXML形式から別の形式へ非構造的調整を行うための 優れた汎用変換モデルです。

Template 2.1が最初の機能を実行します。xsl:copy を使って、wsdl:description 要素をコピーします。最初のxsl:apply-templates は、属性をコピーします。

2番目のxsl:apply-templates は子要素のコピーを 試行しますが、モードを特定しないことに注意してください。リストの残りを見ると、WSDLwsdl:types の場合、その要素をルートとするサブツリーのコピーを 再帰的に続行するtemplate 2.7にマッチングされます。wsdl:description の次の子に達するとただちに、違った展開になります。wsdl:message 要素は、空のプロシージャーであるtemplate 2.4にマッチングされます。ここまでの効果として、WSDL要素のwsdl:types を除くすべての子が抑制されます。

3番目のxsl:apply-templates も同様の操作を 実行しますが、convert-to-rdf モードを指定します。続いてプロセッサーは再びwsdl:types に遭遇しますが、今回は、別の空のプロシージャーであるtemplate 2.6にマッチングします。しかし、その他のすべての最上位WSDL要素はtemplate 2.2によって 処理されます。このテンプレートが、RDF形式への変換プロセスを開始します。もちろん、出力のこの部分は、必要に応じてrdf:RDF 要素の中にラッピングされます。

変換の残りの部分のほとんどは、このような処理の繰り返しです。前回の記事から、最上位の子をRDFに変換するには、元のname 属性から取ったrdf:ID 属性を 追加することを思い出してください。これを実行するには、template 2.2でxsl:attribute を明示的に使用します。また、最上位WSDL要素の各属性ごとに、明示的な名前空間を追加する必要があったことにも注意してください。これは、convert-to-rdf モードで属性を マッチングするtemplate 2.5によって処理されます。セットアップしたルックアップ・テーブルを使用していることに 注意してください。また、このテーブルはスタイル・シートをソース・ドキュメントとして ロードする手法を採用していることにも注意してください。このルックアップ・テーブルは、名前空間URIを、出力で使われる接頭部にマップします。

最上位WSDL要素の子は、template 2.3および2.4のように、少し違った方法で扱われます。このような異なる方法は、RDF表記の単純化と関係があります。つまり、wsdl:message/wsdl:part 要素を 無名 (anonymous) リソースのままにしたこと、@message 属性をrdf:resource 属性に 変換したことです。

再び4XSLTを使えば、元のWSDLソースを入力とするこの変換の出力は、前回の記事のRDFバージョンと同じようなものになります。読者がRDF形式のWSDLに関心がないとしても、上のようなスタイル・シートは、さまざまなWSDL調整の入門的な枠組みとなることでしょう。

上に戻る

ラッピング

WSDLのコア (中心部) はきわめて単純です。オンライン・サービスの単なる記述です。しかし、後援者による公認、およびUDDIによって据えられた重要な基礎のために、さまざまなアプリケーションで利用されるようになるでしょう。単純な形式が広く利用されている例の1つとして、Rich Site Summary (RSS) システムがあります。この記事でご紹介した手法は、XSLT変換を使ってWSDLを処理するいくつかの方法を示しています。

リスト1 の プル・アプローチは、単純なオンライン・レポートやカタログに適しています (とくに、簡単な変換方法が必要な場合)。このようなケースでは、出力の構造は入力の構造とほとんど似ていません。出力用の情報だけを選択して抜き出す方法は道理にかなっています。リスト2のプル・アプローチは、WSDLと同じ構造に基づく変換の場合に適しています。たとえば、あるWSDLファイルから拡張子を取り去って表示したいような場合、または、API要約用にすべてのレベルのWSDL documentation要素を 抜き出したい場合などがあるでしょう。また、WSDLの関係をXLinkとして作り直すような場合にも適しているでしょう。そのようなリンクは内部的なものかもしれませんし、または、WSDLインポートを使って記述を分割するような場合には、外部リンクかもしれません。もう1歩進んで、拡張機能として、WSDLのインポート機能以外の外部リソースとして リンクを処理することもできます。そのような変換は、リスト2とあまり変わらないでしょう。

この連載記事が、WSDLについての紹介として、また、現在利用できるXMLテクノロジーを使って形式を処理する方法の 紹介として役に立ったことを期待しています。WSDL、UDDI、その他のテクノロジーが成熟し互いの関連を深めるにつれて、アプリケーションはますます改善し、そのようなアプリケーションを利用する サービス提供者たちも進歩してゆくでしょう。こうして、Web Servicesのスムーズな統合という夢が 少しは現実味を帯びてくる日がやって来るかもしれません。

参考文献

• XSLTを使ってXMLテクノロジー実装をブートストラップする例が 他にもあります。Eric van der Vlist氏の記事には、パーサー処理前にXSLTを使ってXMLを処理する方法が紹介されています。Rick Jeliffe氏のSchematron のXSLT版は、DTDに適さない多数のXMLボキャブラリーを妥当性検査するツールです。
  
  
• 幸いにも、XSLTについて学習できる優れたリソースが新しく登場しています。XSLTに少しでも興味のある人は、Michael Kay著の優れた本XSLT Programmer's Reference、Wrox Press Inc.、2000年1月 (ISBN: 1861003129) をぜひ読んでください。
  
  
• Crane Softwrights Ltd. の出版しているXSLTに関する優れた ハンドブックPractical Transformation Using XSLT and XPath (第8版、ISBN: 1-894049-05-5) をお読みください。
  
  
• Miloslav Nic教授による 包括的なオンライン・チュートリアルもご覧ください。
  
  
• この記事のリストのスタイル・シートをテストするために、4XSLT を使用しました。
  
  

著者について

Uche Ogbuji は、次世代の Web 技術を専門とするサービスの会社である、Uli, LLC の代表者です。Ogbuji 氏は XML、RDF、およびナレッジ管理アプリケーション用のオープン・ソース・プラットフォームである 4Suite の開発リーダーであり、Versa RDF 照会言語の開発リーダーでもあります。ナイジェリア出身のコンピューター・エンジニア兼ライターで、米国コロラド州ボールダー在住です。彼に関して詳しくは、彼のブログである Copia を見てください。

この記事を評価する

コメント

上に戻る

目次

• WSDLに秘められたデータを発掘する
• WSDLからRDFを生成する
• ラッピング
• 参考文献
• 著者について
• コメント