RDFによるWSDLのスーパー・チャージ

構造化されたWeb Servicesメタデータの管理

Resource Description Frameworkは、XMLオブジェクトのメタデータの定義に使用するWorld Wide Web Consortiumの公式形式です。概念的には、XMLベースのサービスに関するメタデータのコレクションであるWeb Services Description Languageに似ています。この記事では、これら2つの仕様の間にかかる橋に焦点を合わせます。まず、Web Servicesの記述がどのようなRDFファイルになるかの例を示します。次に、RDFビジュアル化ツールを活用してWSDLデータのグラフを生成する方法について説明します。最後に、WSDL用に使用できるRDF図式の一部を示します。

Uche Ogbuji (uche@ogbuji.net), Consultant, Fourthought, Inc.

Uche photoUche Ogbuji氏は、Fourthought, Inc. のコンサルタント兼共同設立者です。この会社は、企業のナレッジ・マネジメントのためのXMLソリューションを専門とするソフトウェア・ベンダー兼コンサルタント会社です。Fourthoughtでは、XML、RDF、およびナレッジ・マネジメント・アプリケーション用のオープン・ソース・プラットフォームである4Suiteを開発しています。Ogbuji氏は、ナイジェリア出身のコンピューター・エンジニア兼ライターで、現在は、米国コロラド州ボールダーに住み、そこで働いています。Ogbuji氏の連絡先はuche.ogbuji@fourthought.com です。



2000年 11月

Web Services Description Language (WSDL) (参考文献を参照) 仕様は、ネットワーク上で使用可能なXMLベースのWeb Servicesを記述するのに使用できる、単純なXMLベースのボキャブラリーを提供しています。サービスそのものは、Simple Object Access Protocol (SOAP)、HTTP、SMTP、または他の手段によって通信を行いますが、WSDLは、通信をセットアップするのに必要なメタデータをユーザーに提供します。WSDLそのものは、サービス記述の公開や共通化を行う方法については述べておらず、そのことは他の仕様にまかせています。Web Servicesのディレクトリーを作成するイニシアティブであるUniversal Description, Discovery and Integration (UDDI) は、WSDL記述のカタログとディスパッチを行うためのフレームワークを定義していますが、これはまだ新しく、非常に複雑です。

UDDIはオンライン契約の分野に力を入れており、まもなく分散サービスの業界で頭角を現すことでしょう。しかしながら、WSDLの最初の展開は、オープンなWebではなく非常に閉じたシステムで行われる可能性があるので、おそらくUDDIよりも優れた代替案があります。より自然なかたちとして、Resource Description Framework (RDF) が、より早くWSDLのカタログとディスカバリーの分野に参入するでしょう。RDFは、World Wide Web Consortium (W3C) によって開発された、Webメタデータのエンコードと管理を行う機構です (参考文献を参照)。大量のメタデータを複数のドメインに組み込む単純な手段を提供します。

この記事のフレームワークを理解するために、以前の記事『SOAPアプリケーションでWSDLを活用する方法』(参考文献を参照) を読むことをお奨めします。この記事では、スノーボードのエキスパートが業界のベンダーに広告を提供するためのサービスを記述する特定の例により、WSDL仕様の機能について説明しています。今回の記事では、RDFの単純性と能力を結び合わせてWSDLの記述能力を高める方法について説明します。RDF、RDF図式、およびRDFの基本的なXML表現について精通する (残りの作業を理解するために重要) には、参考文献のセクションにあるRDF情報リンクを参照してください。

RDFとWSDLはこうなるはずだった

WSDLが提供しているすべてのものは、RDFシリアライズ形式で作成することができたはずです。IBM、Microsoft、およびAribaがこれについて考慮しないことにしたのは、奇妙なことです。他の類似の標準 (RDF Summary (RSS) など) は、XMLリソース記述形式をRDFのXMLシリアライゼーションとして表す方法を示しています。これは、すべての標準で意味を持つわけではありません。たとえば、ほとんどの人は、Scalable Vector Graphics (SVG) 作業グループがRDFまわりのSVGを設計するとは予想していませんでした。しかしながら、ほとんどの情報がリソース間の関係や短いラベルを表している場合、増え続けているユーザーおよびツールにより、RDFは大きな意味を持ちます。

たとえば、私は、上述のWSDL仕様を使ってスノー・ボードに関する例をリスト1 のように変更し、RDFシリアライズ形式を使うようにしてみました。

リスト1: スノーボード広告内容検索のWSDL記述は、有効なRDF構文ではこのようになる。
 <?xml version="1.0"?>
 <definitions name="EndorsementSearch"
   targetNamespace="http://namespaces.snowboard-info.com"
   xmlns:es="http://www.snowboard-info.com/EndorsementSearch.wsdl"
   xmlns:esxsd="http://schemas.snowboard-info.com/EndorsementSearch.xsd"
   xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
   xmlns:w="http://schemas.xmlsoap.org/wsdl/"
   xmlns="http://schemas.xmlsoap.org/wsdl/">
   <types>
     <schema targetNamespace="http://namespaces.snowboard-info.com"
             xmlns="http://www.w3.org/1999/XMLSchema">
       <element name="GetEndorsingBoarder">
         <complexType>
           <sequence>
             <element name="manufacturer" type="string"/>
             <element name="model" type="string"/>
           </sequence>
         </complexType>
       </element>
       <element name="GetEndorsingBoarderResponse">
         <complexType>
           <all>
             <element name="endorsingBoarder" type="string"/>
           </all>
         </complexType>
       </element>
       <element name="GetEndorsingBoarderFault">
         <complexType>
           <all>
             <element name="errorMessage" type="string"/>
           </all>
         </complexType>
       </element>
     </schema>
   </types>
   <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#">
     <message w:name="GetEndorsingBoarderRequest"
              rdf:ID="GetEndorsingBoarderRequest">
       <part w:name="body" w:element="esxsd:GetEndorsingBoarder"/>
     </message>
     <message name="GetEndorsingBoarderResponse"
              rdf:ID="GetEndorsingBoarderResponse">
       <part w:name="body" w:element="esxsd:GetEndorsingBoarderResponse"/>
     </message>
     <portType w:name="GetEndorsingBoarderPortType"
               rdf:ID="GetEndorsingBoarderPortType">
       <operation w:name="GetEndorsingBoarder">
         <input rdf:resource="GetEndorsingBoarderRequest"/>
         <output rdf:resource="GetEndorsingBoarderResponse"/>
         <fault rdf:resource="GetEndorsingBoarderFault"/>
       </operation>
     </portType>
     <binding w:name="EndorsementSearchSoapBinding"
              w:type="es:GetEndorsingBoarderPortType"
              rdf:ID="EndorsementSearchSoapBinding">
       <soap:binding soap:style="document"
                     soap:transport="http://schemas.xmlsoap.org/soap/http"/>
       <operation rdf:about="GetEndorsingBoarder">
         <soap:operation
           soap:soapAction="http://www.snowboard-info.com/EndorsementSearch"/>
         <input>
           <soap:body soap:use="literal"
             soap:namespace="http://schemas.snowboard-info.com/EndorsementSearch.xsd"/>
         </input>
         <output>
           <soap:body soap:use="literal"
             soap:namespace="http://schemas.snowboard-info.com/EndorsementSearch.xsd"/>
         </output>
         <fault>
           <soap:body soap:use="literal"
             soap:namespace="http://schemas.snowboard-info.com/EndorsementSearch.xsd"/>
         </fault>
       </operation>
     </binding>
     <service w:name="EndorsementSearchService"
              rdf:ID="EndorsementSearchService">
       <documentation>snowboarding-info.com Endorsement Service</documentation>
       <port rdf:about="GetEndorsingBoarderPort">
         <binding rdf:resource="EndorsementSearchSoapBinding"/>
         <soap:address soap:location="http://www.snowboard-info.com/EndorsementSearch"/>
       </port>
     </service>
   </rdf:RDF>
 </definitions>

基本的に、変更点は、1つの記述セクションを取り出し、それをRDFシリアライゼーションにエンコードしたことです。RDF Model and Syntax 1.0 Recommendation (RDF M&S) (参考文献を参照) で要求されているように、このセクションはrdf:RDF エレメントで囲まれています。これをRDFプロセッサーに送ると、WSDL記述を構成する修飾情報や関係をきちんと示す情報の宝庫が生成されます。私は使用可能なすべてのRDFシリアライゼーション・トリックを使用して、元のXML構造からの変更が最小になるようにしました。これは、既存のXML形式を有効なRDFフォームに押し込めるようにするために、RDF作業グループがどれほど懸命にRDF M&Sを作成したかをよく示しています。使用可能な多くのトリックにより、さまざまな構文からの変換や、結果のRDF抽象モデルがもろくなるので、これは大きな論争の原因となっています。

私は、types エレメントをRDFセクションに入れませんでした。主な問題は、このセクションの内容が、完全にWSDLの扱う領域外にあることです。XMLスキーマからRDFへの標準マッピングは、W3Cや他のWeb標準化団体によって考え出されるかもしれませんし、他のデータ・タイプ方法論によって実現するかもしれませんが、これは、実際には完全に有効範囲が異なる活動です。types の指定は、parseType="Literal" 属性を完全に挿入することにより、RDFモデルに挿入することもできました。ただし、このようにした場合、parseType="Literal" に関係するすべての問題に直面していたでしょう。特に、RDF M&Sでは、マークアップを含むリテラルの間の等価性の定義 (たとえば、マークアップを含む2つのリテラルは、Canonical XMLに縮小したものが同一であれば等価であると言える) が明示的に否定されています。したがって、RDFモデルに保管したものを他のデータと正しく比較することができなくなったでしょう。実際、これによってparseType="Literal" は全く役に立たないものとなっているので、私はこれについて考えませんでした。

RDFに変換されたセクションの中で最も際だった変更点は、rdf:ID 属性がコアWSDLエレメントに追加されたことです。RDFはこのようにして、WSDL作成者が属性内の修飾名によって行おうとした処理を行い、抽象エンティティーの間の関係を確立します。rdf:resource 属性が使用されている個所では、これらの識別済みリソースへの参照が行われていることが分かります。

別の際だった変更点は、以前に接頭部のなかったすべての属性に接頭部が追加されたことです。ネーム・スペースで解決された 属性名を適切な名前として扱えるようにするRDF省略形があります。このような属性値は、ステートメントのリテラル値を形成します。私はこの省略形をリスト1 で頻繁に使用しました。適切な名前に関するネーム・スペースは、必ずしもRDFに必要ありませんが、その種の名前を明確にする手段として強くお勧めします。このWSDLメタデータを他の情報を含むモデルに入れると、共通に使用されるラベル (たとえば "name") が他の特性 (たとえば、個人や組織の名前を表すもの) と衝突する可能性が高くなります。XML Namespaces 1.0ではデフォルトのネーム・スペースを属性に適用することができないので、名前を明確にするために接頭部を明示的に指定する必要があります。

message部分などでは、匿名リソースを使用しました。message/part エレメントに特性属性はありますが、rdf:ID またはrdf:about 属性はありません。このようにしたのは、message部分をメッセージ・コンテキストの外部から参照することはほとんど必要でないと思えたからです。そのような操作を行わないのであれば、リソースを匿名にしない理由はありません。そうでなければ、固有のID (最上位リソースの場合と比較すると不自然) を作成するか、XPointerをrdf:about 属性で使うか、その他のしかけを使わなければならなかったでしょう。私は、最も自然に思えることを行いました。

最後に一言。見て分かるように、私はrdf:aboutservice エレメントで使用し、以前はサブジェクトとして記述した、ポートに関するステートメントを追加しました。これは、RDF構文の柔軟性を活用して元のWSDLからの変更を最小にしているもう一つの例です。さらに、RDFにおける記述の自由なネストがどれほど役に立つかも分かるでしょう。これにより、binding エレメントで元の構造を維持することができます。


RDFTOCによるWSDLの詳細なグラフ化

結局、これまで調べてきたWSDL 1.0仕様によれば、上記の例は有効なWSDLではありません。幸運なことに、RDFを公式の構文から生成することは十分に簡単です。これは、WSDL文書のデータを提供したのと同じソースで行われる自動処理や、XSLTを使用することにより行えます (これを行う方法の例は、WSDLに関する次の記事で説明されます)。私がこの記事で示したRDF表現は、WSDLでエンコードされたメタデータの具体的なRDFモデルを提供するので、依然有効です。これは、関係のあるステートメントや実際的なステートメントをほぼすべて取り込んでいると思います。したがって、WSDLから抽出した特定のRDF構文を使用して同じモデルを構築することは、単純な問題です。

XMLの持つ多くの側面

ここで、宣教師の説教壇にほんの少しの間登ることにします。この多面性は、まさにXMLと関連テクノロジーをエキサイティングにしている要素です。白髪頭のデータ処理専門家は、WSDL、RDF、および他の同様テクノロジーに関して、わくわくするような洞察や独創性をほとんど認めないでしょうし、実際にそうしていません。革命的なのは、データ形式や抽象モデルでも、それらの間に存在するいかなるものでもなく、さまざまな適合システム間のコラボレーション能力です。このために、多くの人々がXMLデータ処理の旗の下に結集してきました。

つまり、自称ものぐさプログラマーの私でも、新しいサービス記述言語WSDLについていくらかの理解を得、即座にそれをRDFの形式に適用することができます。RSSなどでは、このことがすでに行われています。すぐに入手できるツールを使用すれば、もともと記述されていた抽象概念の包括的なビジュアル表現を作成することができます。

RDFと、RDFに関するW3Cの要求については、いくらかの論争がありますが、このWSDLの解説は、RDFについての読者の考えや、良く知られている不完全さに関係なく、メタデータについての会話を適切に始めるために使用できる大きな円卓と言えるでしょう。XMLコミュニティーが意味のある仕方で最初に行っているように見える 1つのことは、この会議を広げるための努力です。これにより、コラボレーションがさらに現実的なものとなっています。それでは、説教壇から降りて仕事に戻ることにします。

WSDLのRDFモデルの1つの優れた利点は、WSDLモデルが指定する情報の手軽なビジュアル表現が直接得られるということです。メタデータをRDFにマップすることにより、私はRDF M&Sが有向グラフとして表すことを提案している形式に準拠しました。これが機能するのを見るには、Dan BrickleyのすばらしいRDFビジュアル化ツール (参考文献を参照) にアクセスし、URLテキスト・ボックスに以下のURLを入力してください。
http://www-4.ibm.com/software/developer/library/ws-rdf/endorse.rdf
リスト1 は、参照用の文書のコピーです。

結果のグラフを少し見てください。ビジュアル化ツールからGIF出力を使用する場合はちょっとした工夫が必要なので、Adobe SVGプラグイン (参考文献を参照) などのビューアーがある場合は、SVG出力をお勧めします。さらに、ビジュアライザーのサイトからは、2-D Virtual Reality Markup Language (VRML) を生成することもできます。匿名リソースには、RDFツールの通常処理として、生成されたUniform Resource Identifier (URI) が割り当てられます。ただし、これは、RDF M&Sのサンプル・グラフ (匿名リソースが空の楕円で示される) とは異なります。たとえば、最初のmessage エレメントで囲まれている無名ポート・リソースには、以下のURIが割り当てられます。
http://www-4.ibm.com/software/developer/library/ws-rdf/endorse.rdf#genid3
さらに、rdf:type 特性が明示的にドローされていることにも注意できます。リスト1では、rdf:description エレメントの代わりにタイプ付きノードを使用することにより、これは暗黙的に行われていました。


WSDL用のRDFスキーマ?

ダイアグラムで表示されるtype特性は、RDFモデルへの変換に使用する形式的なフレームワークとして使用できる、WSDL用のRDFスキーマを提案します。この場合も、WSDL仕様ではRDFスキーマが提供されていませんが、リスト2 で私は控えめな提案をしています。これは、WSDLの完全なRDFスキーマではなく、リスト1 (WSDLのサブセットを使用する) で示した例のサブセットを扱うにすぎません。私の願いは、これをさらなる作業の基礎とすることです。

まず注意できる点として、大文字で示されていることは、RDF Schemas Candidate Recommendation (RDF Schemas) で使われている規則と一致していません。これは、WSDLが使うエレメント・タイプ名の変異を避けるためです。このことを除けば、これは平凡なスキーマです。記述エレメント間の内部関係について、対応する制約がWSDLにある個所では、domain- およびrange- 制約を使用しています。たとえば、WSDLのinputエレメントのmessage属性の値はメッセージの名前でなければならないので、RDFスキーマはリスト3 の断片で等価の範囲制約を使用しています。

リスト3. RDFスキーマの範囲制約
 <rdf:Property ID="input">
 <rdfs:range rdf:resource="message"/>
 <rdfs:domain rdf:resource="operation"/>
 </rdf:Property>

上記のドメイン制約は、input特性がoperationエレメント内からしか使用できないことを保証します。これは、WSDLの条件でもあります。

しかしながら、これらの制約の多くは、可能な限り強力にはなっていないことに注意してください。たとえば、element特性は、typesセクションにある、message部分で使用される特定のエレメントを示します。この特性の値は、有効なqnameでなければなりません。たとえば、ストリング "!!42xyz??" は、有効なXMLエレメント・タイプの名前でさえないので、この特性の値として設定することはできないはずです。しかし、rdfs:Literal を特性の範囲として使用しているので、RDFプロセッサーではこのようなエラーも許容されます。不運なことに、RDF Schemasはデータ・タイプのサポートをほとんど提供せず、XML Schemasグループの成果を活用できる後のバージョンのために残していることで悪名を得ています。

物事を単純にしておくため、私は戦略的にサブセットからSOAP操作を除外しました。SOAP固有のステートメントを独自のネーム・スペースに保持しておくには、これらのクラスや特性のための別のRDFスキーマ・ファイルと、スキーマの公開についてWSDL作成者からのいくらかの援助が必要となる可能性があります。しかし、この場合も、この記事でセットアップしたフレームワークとともにRDFスキーマを使用するには、基本URL "http://schemas.xmlsoap.org/wsdl" (参考文献を参照) を所有しているWSDL作成者からのいくらかの援助が必要です。この記事で使用した4RDFを含むほとんどのRDFプロセッサーは、デベロッパーに基本URIのマップとオーバーライドを許可することによってこの問題を回避することができます。おそらく、他のRDFプロセッサーも同様のことを行えます。


XSLTへつづく

この記事で説明しているようにWSDLをRDFにマップすれば、サービス記述をRDF対応の検索エンジンや種別システムに自動的に組み込むことができます。W3Cはすでに、かなりの力を用いて、RDFによってコンテンツをカテゴリー化するようベンダーやWebマスターに促しています。こうすれば、組み込まれたサービス記述の価値が高まるはずです。そうなれば、(XMLコメンテーターLen Bullardの言葉を借りると) "サービスWeb (services Web)" のホワイト・ページやイエロー・ページは、WSDLスキーマに限定されたRDF検索と同じほど単純になります。UDDIの人たちが組み立てている巨大フレームワークよりもずっと単純になりますが、これは別の話です。

私の願いは、この記事が読者に、RDFで使用可能な既存のツールを使ってWSDLの実験を行う方法に関する洞察を与えることです。ここでは、WSDLでエンコードされたメタデータ関係の内部構造について調べました。これは、RDF変換によって明確にされました。また、RDFスキーマおよびインスタンスを非RDFのXMLボキャブラリーから導出する一般的な処理についても調べました。次の記事では、別のコアW3Cテクノロジー (つまり、XSLT) がWSDLデベロッパーおよびユーザーに何をもたらすかを考えます。

参考文献

  • 私の前の記事、 SOAPアプリケーションでWSDLを活用する方法では、WSDLの仕組みと、SOAPベースのアプリケーション・プログラミングに適用する方法について説明しています。
  • W3CはRDF情報ページを開設しています。詳細についてはこれを参照してください。
  • RDFの学習を進めるには、この チュートリアルを試してみてください。
  • 私は、Dan Brickleyの驚くべきRDFビジュアライザーを使って、説明したWSDL記述のイメージを生成しました。これは、GIF (141 KB) またはSVG (27 KB) 形式で入手可能です (このファイルを表示するには、Adobe SVGプラグインをダウンロードしてください。プラグインをインストールしたら、任意のRDFファイルをプラグインまたはWebブラウザーで開き、グラフで表示してください)。RDFソースはこの記事のリスト1 です。リスト1のコピーも入手できるようにしてあります。
  • RDFスキーマ・ビジュアル化ツールリスト2 に対して使用することもできます。
  • W3CのSVGページには、多くのSVGリソースがあります。
  • ダイアグラムの生成時を除き、私はこの記事のRDFファイルおよびスキーマの処理やテストに 4RDF を使用しました。

コメント

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=SOA and web services
ArticleID=242299
ArticleTitle=RDFによるWSDLのスーパー・チャージ
publish-date=112000