SOAPは、XMLによる通信内容を低レベルのインターネット・プロトコル上で送信する、トランスポート・プロトコルです。1.2以前のトランスポートの仕様は、XMLの推奨されているエンコード方式で作成されていましたが、プログラム言語の直列化構成に適応しています。そのようなエンコード方式は、リモート・プロシージャー呼び出し (RPC) システムとして知られるものの中心を成し、ローカル・プロシージャー呼び出しと同じようにして、リモート・コンピューター呼び出しを行なうという共通の目的を持ちます。RPCエンコード方式の他の例として、従来のRPCのExternal Data Representation (XDR) (RFC 1014で定義) や、CORBAのCommon Data Representation (CDR) があります。それらのエンコード方式と組み合わされた結果、SOAPは明らかにアプリケーション・プログラミングの様相を帯びるようになり、一般的なデータ交換の利便性という点は疑わしくなりました。

このような初期のタイプのSOAPは多くの議論を生み出しました。ます第1に、トランスポートとデータ・エンコードの仕様を混ぜ合わせる事は、通信を行う点で大きな混乱を招く事が予想されますし、数十年間ネットワークの世界の慣習となってきた階層化プロトコルに、真っ向から対抗するように思えます。結局のところ、HTMLマークアップの仕様もHTTP仕様には組み込まれませんでした。第2に、上位のものにRPCに似たエンコード方式を選ぶことは、SOAPを奇妙な場所に置くことになります。SOAPにはXML以前のRPCメカニズムよりも高い表現力がありますが、XMLの冗長さに対して、HTTP、SMTPなどが汎用アーキテクチャーである事を考えるなら、実質的には効果性が低くなることになります。SOAPが次世代のRPCとしてもたらす唯一の利点は、Microsoft陣営とCORBA陣営を統合することです。この点は重要ですが、これはSOAPが有望視されている理由では決してありません。

RPCとしてのSOAPの決定的な弱点は、そのようなシステムは一般的なWebサービスとして期待されている次世代のEDIに全く適合しないという事です。Webサービスがネットワーク上でビジネスに関係する通信を行う新しい手段になる場合、プログラミング言語APIのレベルではなく、ビジネスおよび法的な要件を満たすレベルでデータをやり取りするトランスポート・メカニズムが必要になることでしょう。それを裏付けるように、XMLを使用して国際的な電子ビジネス通信のためのシステムを作り上げることを目指すebXML initiativeは、他の影響力のあるいくつかの組織と同様、SOAPを使用する事に関して当初は否定的でした。

現在の状況はそのときよりも落ち着いてきています。SOAP 1.2によって特殊なエンコード方式への依存度はいくらか弱まり (別個の「付加属性」セクションに移されています)、ebXMLを含め現在ほとんどの組織はSOAPという船に乗りこんでいます。現在でもほとんどのSOAPインプリメンテーションは、特別なSOAPエンコード方式を排他的に使用していますが、エンコード方式の幅広い選択肢のためのプラグイン・アーキテクチャーが用意され、通信上の多くの問題への取り組みも始まり、これらの問題も解決に向かう兆しを見せています。そのような問題の1つはメタデータの交換です。これには、SOAPを使用して伝送される他のXML文書で使用されるセマンティクスを判別するのに役立つメタデータが含まれます。

Resource Description Framework (RDF) は、そのようなメタデータの交換に取り組むためのいくつかの機能を備えたモデリング・システムです。この記事では、そのようなメタデータのエンコード方式のためにRDFをSOAPで使用する方法、またRDFにエンコードされているデータ・インスタンスを、変換せずにSOAPエンコード方式に直接伝送する方法についても取り上げます。そのため、この記事を理解するにはSOAPとRDFについて熟知していることが必要です。これらについては、参考文献を参照してください。さらに、IBM developerWorks XMLゾーンで連載中のXML的思索 コラムで紹介されている、RDFやナレッジ管理に関係する他のXML技術に関する記事も参照してください。

良い船であるRDF

まず初めに、RDFをあるシステムから別のシステムへSOAPによって発送させるときに何ができるかについて考えましょう。ここで、XMLゾーンで私が執筆しているXML的思索 コラムで現在扱っているプロジェクトから例をあげましょう (参考文献を参照)。たとえば、リモート・マシンのシステムに追加されているissueの詳細を交換したいとします。これは、非集中の、分散issueトラッカーの基礎となることでしょう。RDF直列化におけるissueの例をリスト1 に紹介します。

                
<?xml version="1.0"?>
<rdf:RDF xmlns:it="http://rdfinference.org/schemata/issue-tracker/"
         xmlns:dc="http://purl.org/dc/elements/1.1#"
         xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
         xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#"
         xml:base="http://rdfinference.org/versa/issues">
  <it:issue rdf:ID="0101">
    <dc:relation rdf:resource="http://rdfinference.org/versa/0/2"/>
    <dc:identifier>0101</dc:identifier>
    <dc:creator rdf:resource="mailto:uche.ogbuji@fourthought.com"/>
    <dc:date>2002-01-27</dc:date>
    <dc:title>Data type conversions</dc:title>
    <dc:description>Not all the data type conversions listed make sense.  
	In particular the question of how to convert numeric types to resources 
	and vice versa require much thought.</dc:description>
  </it:issue>
</rdf:RDF>

これはWebリソースに対して生じるissueの例です。issue自体は、URIhttp://rdfinference.org/versa/issues#0101 として識別されます。これは、文書の基本URIに、そのissueを表す入力されたノードの rdf:ID 属性によって指定されたフラグメントを追加することによって決定されます。文書の基本URI (正確に言えば文書要素の基本URIであり、入力されたノード要素自身のものとなる) は、xml:base 属性を使用してhttp://rdfinference.org/versa/issues と指定されます。その後、issueそのもののステートメントをいくつか作成し、最も重要な事として、Dublin Coreからのdc:relation メタデータ・タグを使用してissueが参照するリソースを指定します。さらに、ID (これはissueの完全なURIを表示しやすくするために単に省略したもの)、issueの作成者、実行依頼された日付、簡潔なタイトル、および長い説明を提供します。

これはRDFであり、そのためXMLの直列化は最も重要な要件ではなく、むしろ要約型のRDFモデルに変換する方法の方が重要であることに注意してください。たとえば、図1 は、Triclopsから生成される、4Suite 0.12.0 alpha 1以上に付属しているRDFビジュアル化ツールを示しています (警告: この例は非常に幅の広いイメージが生成されます)。Dan Brickley氏のオンラインRDFビジュアル化プログラムを使用することによっても、同様のグラフを生成できます。

では、ここでこのモデルをSOAPメッセージで送信する2つの方法について見てみましょう。まず最初は、SOAPエンコードに変換する方法です。そして次に、直接RDFにエンコードする方法を考えます。

SOAPエンコード方式の使用

まず最初に、送信の方法を作り出す必要があります。定義したRDFはデータの固まりであり、このデータの固まりをメッセージに渡すという方法です。そして、受信側がそのデータを扱う方法を予期できるように名前を付けます。この例では、トラックすべき新しいissueがあることをリモート・サーバーに通知します。そこで、このメソッドをnewIssue と呼びます。これからSOAPエンコード方式を使用しますが、メソッド名は、SOAPをRPCに結合するプログラミング言語に適したものとするように注意してください。

次に、新しいissueオブジェクトを送信する方法を見つける必要があります。これは、新しいオブジェクトのIDと、そのプロパティーを伝送することによって行います。基本的には、新しいissueオブジェクトから各プロパティーを切り離して、メッセージ・パラメーターに変換します。SOAPエンコード方式はtype情報に厳格であるため、各パラメーターをtypeで修飾する必要があります (リスト2 を参照)。

                
<?xml version='1.0' ?>
<env:Envelope xmlns:env="http://www.w3.org/2001/12/soap-envelope">
 <env:Body>
   <itsoap:newIssue env:encodingStyle="http://www.w3.org/2001/12/soap-encoding"
     xmlns:itsoap="http://rdfinference.org/schemata/issue-tracker/soap"
     xmlns:it="http://rdfinference.org/schemata/issue-tracker/"
     xmlns:dc="http://purl.org/dc/elements/1.1#"
    
     xmlns:xs="http://www.w3.org/2001/XMLSchema">
     <dc:identifier xsi:type="xs:nonNegativeInteger">0101</dc:identifier>
     <dc:relation xsi:type="xs:anyURI">http://rdfinference.org/versa/0/2</dc:relation>
     <dc:creator xsi:type="xs:anyURI">mailto:uche.ogbuji@fourthought.com</dc:creator>
     <dc:date xsi:type="xs:date">2002-01-27</dc:date>
     <dc:title xsi:type="xs:string">Data type conversions</dc:title>
     <dc:description xsi:type="xs:string">Not all the data type conversions listed 
	make sense.  	In particular the question of how to convert numeric types to 
	resources and vice versa require much thought.</dc:description>
   </itsoap:newIssue >
 </env:Body>
</env:Envelope>

すべての値は、SOAPのエンコード規則で要求されているように、要素の中に置かれます。これには、RDFでリソースとしてマークアップされていて、anyURI データ型が与えられている値も含まれます。これによって、完全なURIだけでなくURI参照である値も (つまり、相対的なURIやフラグメントも) 使用できるという点を覚えておいてください。このようなメッセージすべてをこの形式にしなければならないことを面倒に感じる場合、メッセージ要素にXMLスキーマを定義することによって、データ型をその都度指定する手間を省くことができます。それから、Web Services Description Language (WSDL) 要素に入れるか、他のアウト・オブ・バンド方式で通信できます。リスト3 およびリスト4 は、そのようなスキーマ (異なるターゲット名前空間を指定するため別個に指定) からのフラグメント (ルート要素と名前空間宣言が省略されたもの) です。

                
<!-- with target namespace = http://rdfinference.org/schemata/issue-tracker/soap -->
<xsd:element name="newIssue">
  <xsd:complexType>
    <xsd:all>
      <xsd:element ref="dc:identifier"/>
      <xsd:element ref="dc:relation"/>
      <xsd:element ref="dc:creator"/>
      <xsd:element ref="dc:date"/>
      <xsd:element ref="dc:title"/>
      <xsd:element ref="dc:description"/>
    </xsd:all>
  </xsd:complexType>
</xsd:element>

                
<!-- with target namespace = http://purl.org/dc/elements/1.1# -->
<xsd:element name="identifier" type="xsd:nonNegativeInteger"/>
<xsd:element name="relation" type="xsd:anyURI"/>
<xsd:element name="creator" type="xsd:anyURI"/>
<xsd:element name="date" type="xsd:string"/>
<xsd:element name="title" type="xsd:string"/>
<xsd:element name="description" type="xsd:string"/>

これらによって、リスト5 にあるようにSOAPメッセージをシンプルにできます。

                
<?xml version='1.0' ?>
<env:Envelope xmlns:env="http://www.w3.org/2001/12/soap-envelope">
 <env:Body>
   <itsoap:newIssue env:encodingStyle="http://www.w3.org/2001/12/soap-encoding"
     xmlns:itsoap="http://rdfinference.org/schemata/issue-tracker/soap"
     xmlns:it="http://rdfinference.org/schemata/issue-tracker/"
     xmlns:dc="http://purl.org/dc/elements/1.1#"
   >
     <dc:identifier>0101</dc:identifier>
     <dc:relation>http://rdfinference.org/versa/0/2</dc:relation>
     <dc:creator>mailto:uche.ogbuji@fourthought.com</dc:creator>
     <dc:date>2002-01-27</dc:date>
     <dc:title>Data type conversions</dc:title>
     <dc:description>Not all the data type conversions listed make sense.  
	In particular the question of how to convert numeric types to resources 
	and vice versa require much thought.</dc:description>
   </itsoap:newIssue >
 </env:Body>
</env:Envelope>

RDFをそのまま送る

この記事の冒頭でも触れたように、SOAPを使用するためにSOAPメッセージをRPC形式に変えなければならない理由はありません。他のシステムへRPCを統合する必要に束縛されていない場合、データを送信した場合にリモート・システムがそれを形式変換処理しなくていいようにする、もっと自然で明快な方法を取ることができます。SOAPに対する公式なRDFのエンコード方式というものはありませんが、この記事はRDFとSOAPの規則および規定を基にしています。

最もシンプルな方法は、リスト6 に示されているように、rdf:RDF 要素を単一のSOAPボディの最上位要素にする方法です。

                
<env:Envelope xmlns:env="http://www.w3.org/2001/12/soap-envelope">
 <env:Body>
<rdf:RDF env:encodingStyle="http://rdfinference.org/rdfws/soap-encoding"
         xmlns:it="http://rdfinference.org/schemata/issue-tracker/"
         xmlns:dc="http://purl.org/dc/elements/1.1#"
         xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
         xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#"
>
  <it:issue rdf:about="http://rdfinference.org/versa/issues#0101">
    <dc:relation rdf:resource="http://rdfinference.org/versa/0/2"/>
    <dc:identifier>0101</dc:identifier>
    <dc:creator rdf:resource="mailto:uche.ogbuji@fourthought.com"/>
    <dc:date>2002-01-27</dc:date>
    <dc:title>Data type conversions</dc:title>
    <dc:description>Not all the data type conversions listed make sense.  
	In particular the question of how to convert numeric types to resources 
	and vice versa require much thought.</dc:description>
  </it:issue>
</rdf:RDF>
 </env:Body>
</env:Envelope>

ここで使用されているエンコードID、http://rdfinference.org/rdfws/soap-encoding は、規則的なものではなく、要するにRDF/XMLをSOAPメッセージのボディに組み込むことを表しています。メッセージ形式とプレーン形式の1つの重要な違いは、issueリソースを識別するためにrdf:about が使用されていますが、そのIDを使用してインライン宣言されていないという点です。これは、SOAP送信における直列化RDFモデルの重要な原則です。つまり、インライン宣言を避けるということです。xml:base を使用してそのIDの基本位置を修正できる場合、そのような原則は無用であるように思えるかもしれません。しかし、インラインで送信されるリソースのライフ・サイクルおよび所有権に関して、クリアなセマンティクスを想像することは難しいと言えます。インライン宣言はどんな場合でも避けることが可能であるというわけではないことに注意してください。たとえば、無名のリソース (AKAブランク・ノード) は記述の一部として送信される必要があり、定義で適切なIDが指定されていない場合があります。

上に戻る

結論

SOAPおよびRDFの相互作用に話が及ぶと、他の方法や考え方があることでしょう。実際、これはRDFユーザーがWebサービスを発見する場合に抱く不変のテーマです。またその逆もしかりです。この問題のいくつかに関する参照情報が、参考文献セクションで紹介されています。XMLベースのデータを直列化するより包括的なシステムが、Webサービスの世界を富ませることは間違いありません。

参考文献

• Dublin Core Metadata Initiative では、Web上でライブラリー・ライクなメタデータを記述するためのボキャブラリーが紹介されています。
  
  
• 「Web servicesの進化と革命 第3回: SOAPの仕組み」 Graham Glass著では、SOAP (以前のバージョン) について詳しく取り上げています。
  
  
• SOAP Version 1.2 Part 0: Primer は、SOAPに関するW3Cワーキング・ドラフトの1つです。これは、SOAP 1.2に関する優れた入門情報です。
  
  
• Uche Ogbuji氏による「XML的思索」 コラムもご覧ください。
  
  

• Henrik Frystyk Nielsen氏によるRDFモデルをSOAPで直列化する例を参照してください。
  
  

• 4Suite - Uche Ogbuji氏も開発を手がけているXMLおよびRDFツール・セット
  
  
• Dan Brickley氏によるRDF visualizer - すでにWeb上で利用できるようにXML直列化している場合、RDFグラフを手軽に生成できます。
  
  

著者について

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

この記事を評価する

コメント

上に戻る

目次

• 良い船であるRDF
• 結論
• 参考文献
• 著者について
• コメント