はじめに

Webサービスの高信頼性メッセージングの目的とは、（アプリケーション、プラットフォーム、またはネットワークの障害にも負けずに）アプリケーションがメッセージを簡単に、確実に、そして効率よく送信そして受信できるようにすることです。IBM®、BEA®、Microsoft®、そしてTibco®（参考文献を参照）により最近再発行されたWS-RM（WS-ReliableMessaging）仕様は、配信の確証と確固としたサービスにより裏付けられる幅広い領域をサポートし、エンドポイント間でメッセージが確実に配信されることを保証するメカニズムのセットそしてプロトコルを定義します。

上に戻る

2004年03月バージョン以来の変更

2004年03月の発行以来、WS-RM仕様に加えられた最初の見逃せない変更は、著作権です。仕様の作成者はWS-RM仕様を著作権使用料が無料であるという条件のもと発行しました。（すべてのWS-*の仕様が著作権使用料無料の条件のもとで作成されるという作成者の公言された確証にもかかわらず）仕様を実装することに対する罪悪感をいだいていた方々には、これはよい知らせだと言えます。

仕様の技術的なコンテントの変更に関しては、実はプロトコルにはそれほどの変更はありません。大半の変更は、Interoperability Workshop（参考文献を参照）での参加と討論からのフィードバック、そしてそのあとに実施されたエンドポイントのテストにより後押しされました。これらの変更のおかげで、仕様は長足の進歩をとげました。変更の大半は、RM Sequenceがどのようにして作成されるかの方法に関連します。

新しい名前空間URI

すべてのWS-RMのプロトコル・エレメントは下記の新しい名前空間URIを割り当てられます。

http://schemas.xmlsoap.org/ws/2005/02/rm

リライアブル・メッセージング・モデル

1つの例外をのぞき、リライアブル・メッセージング・モデル(Reliable Messaging Model)は基本的には変更されていません。CreateSequenceハンドシェイクの交換そしてTerminateSequenceメッセージは（すでにオプショナルではなく）必須です。

終了されたRM SequenceのRM Destinationの一端として効率的なリソース・レクラメーション(resource reclamation)をプロトコルが使用可能にすることを保証するために、作成者はその変更を実行しました。RM DestinationはSequence IDを割り当てますので、一度Sequenceが終了すれば、RM Destinationは終了されたSequenceと関連する状態をすべてパージできます。さらに、（終了されたSequenceに属するのか無効なSequenceに属するのかに関する）情報を持たないSequence IDを含む受信されたメッセージをどれでもRM Destination は安全に廃棄することができます。

サポートされた配信の保証（At-Most-Once、At-Least-Once、Exactly-Once、In-Order）同様に、Application SourceとApplication DestinationそしてRM SourceとRM Destinationの役割は、以前の改訂から何も変更がありません。

前回の改訂同様に、RMプロトコルの本質はメッセージのSequence（シーケンス）の概念です。CreateSequenceメッセージを送信することにより、RM SourceはSequenceの作成を要求します。RM Destinationは（固有のSequenceIdentifierを割り当てる）CreateSequenceResponse メッセージで応答します。

高信頼性の配信の確認を必要とするそれぞれのメッセージは、Sequenceヘッダー・ブロックを含みます。Sequenceヘッダー・ブロックはSequenceの固有なIdentifierを含み、（1から始まり、Sequenceにて続くそれぞれのメッセージごとに単調に1つずつ増える）固有のMessageNumberをSequence にあるそれぞれのメッセージは割り当てられます。RM DestinationはSequenceAcknowledgementヘッダー・ブロックを包括することによりメッセージ受信の成功を応答し、Sequenceにある（受信されたメッセージの完全な範囲での）返信されたメッセージをRM Sourceに報告します。それぞれのSequenceAcknowledgement メッセージにて特定のメッセージの情報が運搬され、確認が不確実に送信されるようになります。

RM Sourceは、Sequence ヘッダー・ブロックにあるLastMessage子エレメントを包括することにより、Sequenceにある最後のメッセージを識別します。Sequenceの存続期間のどの時点でも、RM DestinationがSequenceAcknowledgementを送信するように要求するAckRequestedヘッダー・ブロックを含むメッセージを、RM Sourceは送信できます。

Sequenceの中にあるすべてのメッセージの送信が成功したという確認をRM Sourceが一度受信すれば、それはTerminateSequenceメッセージを送信してSequenceを終了します。RM Destination がTerminateSequenceメッセージを受信すれば、それはそのSequenceに関連するすべての状態を無事に廃棄できます。

プロトコル・エレメント

仕様の第3章（Section 3）にて定義されているプロトコル・エレメントの中で、（Sequence、SequenceAcknowledgement、そしてAckRequestedの）ヘッダー・ブロックのエレメントは（SequenceからオプショナルのExpiresエレメントが除去され、３種類のヘッダー・ブロックのエレメントのIdentifier エレメントの名前空間が変更されるという例外を除き）基本的には不変です。Sequenceの有効期限はCreateSequenceオペレーション（下記の「Sequenceの作成」を参照してください）により確立されます。さらには、スキーマと仕様のproseの間にあるいくつかの些細な矛盾が割り当てられます（例えば、以前からある仕様の改訂はスキーマにより許可される特定の拡張性の点の仕様を省略しました）。

下記のリスト1にある断片は、（Sequence、SequenceAcknowledgement、そしてAckRequested）のエレメントの新規フォーマットを表記します。

<wsrm:Sequence>
  <wsrm:Identifier>http://example.com/sequence/564</wsrm:Identifier>
  <wsrm:MessageNumber>1</wsrm:MessageNumber>
</wsrm:Sequence>
<wsrm:SequenceAcknowledgement>
  <wsrm:Identifier>http://example.com/sequence/564</wsrm:Identifier>
  <wsrm:AcknowledgementRange Upper="3" Lower="1"/>
</wsrm:SequenceAcknowledgement>
<wsrm:AckRequested>
  <wsrm:Identifier>http://example.com/sequence/564</wsrm:Identifier>
</wsrm:AckRequested>

Sequenceの作成

応答エレメント（CreateSequenceそしてCreateSequenceResponse）は、2004年05月に開催されたWS-RM Interoperability Workshopからのフィードバックをもとに修正されています。最初の変更は、CreateSequenceへのAcksTo子エレメントの追加です。

このエレメントが追加されることにより、RM DestinationがSequenceAcknowledgement メッセージを送信する宛先であるエンドポイントの参照が、Sequence作成の時点にて確立されることも可能となります。以前改訂された仕様はSequenceAcknowledgement メッセージを送信するのにRM Destinationが使うべき宛先エンドポイントを指定していませんので、実装者はSequenceAcknowledgement メッセージをwsa:Fromにより識別されるエンドポイントに送信する慣例に従いました。一部の場合にはこのアプローチは機能したかも知れませんが、SequenceAcknowledgementメッセージを受信するエンドポイントが元来のメッセージ送信者のとは異なるアドレスを所有する一部のユース・ケース（例えば、管理されたエンドポイントやRMプロキシー）を除外するという結論に著者は達しています。さらには、Sequenceの過程でwsa:Fromの値が変更された場合をどう取りあつかうかの論考もありました。Sequence内でのメッセージ間のwsa:Fromエレメントの可能性としてあり得る突然変異の起こりやすさに関連する論題を回避できますので、AcksTo をCreateSequenceに追加する方針に定まりました。

xsd:durationのタイプのExpiresエレメント（オプショナル）はCreateSequenceメッセージの子として追加されます。存在すれば、Expires エレメントは作成されたSequenceの望まれる所要時間を示します。それが存在しないか0に設定され（PT0Sの値として表記され）れば、Sequence が有効期限を絶対に切らせないことを暗示します。Sequence/Expiresエレメントの使用に対する懸念のため、著者はその変更を追加することにしました。例えば、Sequenceの存続期間の過程でその値が変更すれば、RM Destinationがその変更を尊重すべきなのでしょうか？さらに、Sequence/Expires エレメントはxsd:datetimeでしたので、RM SourceとRM Destinationのエンドポイントのためのクロックの同期化が必要なのかどうかの懸念を取り上げました。型をxsd:durationに変更してCreateSequenceにて値を一度指定すれば、これらの論題は簡単に解決します。

最後に、仕様のWS-Security系統との効果的な構成を支持するには、CreateSequenceエレメントはWS-SecurityのSTR（SecurityTokenReference）を含み、作成されたSequence用に受信されたメッセージを認証するためにRM Destinationが使用すべきセキュリティー・トークンを識別します。Sequence内で送信された全てのメッセージが、STRが参照する鍵を所持していることを証明せねばならず、無理ならばRM Destinationはそれを破棄します。

<S:Envelope xmlns:S="http://www.w3.org/2003/05/soap-envelope"
    xmlns:wsrm="http://schemas.xmlsoap.org/ws/2005/01/rm">
 <S:Header>
  ...
 </S:Header>
 <S:Body>
  <wsrm:CreateSequence>
    <wsrm:AcksTo>
      <wsa:Address>http://example.com/rm/endpoint</wsa:Address>
    </wsrm:AcksTo>
    <wsrm:Expires>PT0S</wsrm:Expires>
  </wsrm:CreateSequence>
 </S:Body>
</S:Envelope>

バイラテラル・シーケンス・ネゴシエーション

CreateSequence--CreateSequenceResponseの交換にあるまた別の変更は、バイラテラル・シーケンス・ネゴシエーション(bilateral Sequence negotiation)の最適化へのサポートの追加です。前回のWS-RM仕様の改訂では、それぞれの方向に2つのエンドポイントがRM Sequencesを確立する必要があるのであれば、それぞれのエンドポイントはCreateSequenceオペレーションを呼び出す必要があり、このため合計4つのメッセージが必要となります。CreateSequence内の子エレメント（Offer）そしてそれに対応するCreateSequenceResponse内の子エレメント（Accept）を活用することにより、対応するSequence（ここでは2つのエンドポイントに対するRM SourceとRM Destinationの役割は逆となります）をオプションとして提供する能力をエンドポイントに追加しました。単一のメッセージ交換のペアをともなう対応するRM Sequenceをエンドポイントが確立することを、この最適化は可能にします。

下記のリスト3とリスト4に示されるSOAPメッセージの例は、実行中のバイラテラル・シーケンス・ネゴシエーションの実例を表わします。最初のメッセージ（リスト3）であるCreateSequenceは新規のSequenceの作成を要求し、Identifier（http://example.com/sequence/67）とともに対応するSequence を提供します。次のメッセージ（リスト4）であるCreateSequenceResponseは新規のSequenceを作成する要求が受け入れられたことを示します。新規のSequenceはhttp://example.org/sequence/42のIdentifierを持ちました。さらには、（SequenceAcknowledgementメッセージが送信されるべきエンドポイントを指示する）CreateSequenceResponseメッセージにあるAcceptエレメントを含むことにより、提供されたSequenceの受け入れを、応答するエンドポイントは示します。

<S:Envelope xmlns:S="http://www.w3.org/2003/05/soap-envelope"
xmlns:wsrm="http://schemas.xmlsoap.org/ws/2005/01/rm">
 <S:Header>
  ...
 </S:Header>
 <S:Body>
  <wsrm:CreateSequence>
    <wsrm:AcksTo>
      <wsa:Address>http://example.com/rm/endpoint</wsa:Address>
    </wsrm:AcksTo>
    <wsrm:Expires>PT0S</wsrm:Expires>
    <wsrm:Offer>
      <wsrm:Identifier>http://example.com/sequence/67</wsrm:Identifier>
      <wsrm:Expires>PT0S</wsrm:Expires>
    </wsrm:Offer>
  </wsrm:CreateSequence>
 </S:Body>
</S:Envelope>

<S:Envelope
xmlns:S="http://www.w3.org/2003/05/soap-envelope" 
  xmlns:wsrm="http://schemas.xmlsoap.org/ws/2004/12/rm">
  <S:Header>
    ...
  </S:Header>
  <S:Body>
    <wsrm:CreateSequenceResponse>
      <wsrm:Identifier>http://example.org/sequence/42</wsrm:Identifier>
      <wsrm:Expires>PT0S</wsrm:Expires>
      <wsrm:Accept>
        <wsrm:AcksTo>
         
<wsa:Address>http://example.com/rm/endpoint</wsa:Address>
        </wsrm:AcksTo>
      </wsrm:Accept>
    </wsrm:CreateSequenceResponse>
  </S:Body>
</S:Envelope>

Sequence終了

Identifierエレメントの名前空間の些細な例外と割り当てられたスキーマと仕様のproseの間でのいくつかの取るに足らない矛盾を除き、TerminateSequenceエレメントは根本的には変更されていません。

<S:Envelope xmlns:S="http://www.w3.org/2003/05/soap-envelope"
    xmlns:wsrm="http://schemas.xmlsoap.org/ws/2005/01/rm">
 <S:Header>
  ...
 </S:Header>
 <S:Body>
  <wsrm:TerminateSequence>
    <wsrm:Identifier>http://example.com/sequence/67</wsrm:Identifier>
  </wsrm:TerminateSequence>
 </S:Body>
</S:Envelope>

RM Policy Assertions

2004年03月に改訂された仕様のRM Policy Assertionsの章は、仕様のWS-Policy系統に施された最近の変更に順応させるためにアップデートされ、別の仕様（WS-RM Policy Assertion）に再配置されます（参考文献を参照）。

改訂されたWS-RM Policy Assertion仕様は単一のポリシー・アサーション（RMAssertion）を定義し、以前に定義されたRM Policyのアサーション（InactivityTimeout、BaseRetransmissionInterval、ExponentialBackoff、そしてAcknowledgementInterval）を取り込み、RMAssertionの子エレメントまたはプロパティーとしてそれらを配置します（下記のリスト6の用例を参照）。前回に改訂されたWS-RM仕様からの変更は、これらのプロパティー（元々はアサーション）のセマンティックにありません。

<wsp:Policy wsu:Id="MyRMPolicy" >
  <wsrm:RMAssertion>
    <wsrm:InactivityTimeout Milliseconds="600000" />
    <wsrm:BaseRetransmissionInterval Milliseconds="3000" />
    <wsrm:ExponentialBackoff />
    <wsrm:AcknowledgementInterval Milliseconds="200" />
  </wsrm:RMAssertion>
</wsp:Policy>

さらには、WS-RM Policy Assertion仕様はRMAssertion をEndpoint Policy Subjectと一致させます。WS-PolicyAttachmentsはEndpoint Policy SubjectのWSDL1.1の接続点を、portType、binding、portとして定義します。しかしながら、WS-RMはSOAPプロトコルなので、RMAssertionをwsdl:portTypeに接続することに意味はありません（それは非SOAPバインディングにバインドできます。）かくして、Endpoint Policy Subjectを持つWS-Policy AttachmentsはRMAssertionをWSDL1.1のために定義された接続点（bindingそしてport）のうちのどちらかに接続できるようになります。

RM Faults

RM Faultsの章はだいたいにおいて変更されていませんが、SOAP1.1そしてSOAP1.2にフォールト・プロパティーがどのようにバインドされているかを定義するために、最近再発行されたWS-Addressing仕様にて使われたものと矛盾しない文書スタイルを使用するようにそれはアップデートされています。

付録

スキーマとサンプルのメッセージ交換の仕様の変更を反映するために、WS-RM仕様の付録はアップデートされています。さらには、WS-RM portTypeオペレーションの抽象WSDL1.1の記述が含まれています。

上に戻る

まとめ

近年にアップデートされたWS-RM仕様は、それ以前に発行された前バージョンから長足の進歩をとげました。その進化は、実装の経験そしてInteroperability Workshop（参考文献を参照）にて得られた手応えのあるフィードバックの賜物と言えます。とはいえ、プロトコルの本質的な部分に関して言えば、仕様の前回の改訂とだいたいにおいて同じままです。

参考文献

• 「Reliable Message Delivery in a web services world」（developerWorks、2003年03月）を購読しましょう。これを機会にメッセージ・デリバリーの役割を理解しない手はありません。
  
  
• どのようにしてメッセージがサービス間で確実に送信されるかを明確に詳細にわたり説明するWS-ReliableMessaging仕様（developerWorks、2005年02月）を入手しましょう。
  
  
• alphaWorksからのETTK（Emerging Technologies ToolKit）を使用することにより、数多くの先進的かつ実験的なWebサービス・プロトコルを実装しましょう。
  
  
• 「Asynchronous operations and web services, Part 1」（developerWorks、2002年04月）、「Asynchronous operations and web services, Part 2」（developerWorks、2002年06月）、そして「Asynchronous operations and web services, Part 3」（developerWorks、2002年10月）から、非同期Webサービスがどのようにして機能するかを説明する様々な概念を学びましょう。
  
  
• developerWorks ブログに参加すれば、あなたもdeveloperWorks のコミュニティーの仲間に入れます。
  
  
• Webサービスに関連する多数のタイトルをはじめ、広範な論題を網羅する技術書物が用意されておりますので、Developer Bookstoreをご覧になってください。
  
  
• 知識欲の袋に底はないのでしょうか？SOA and web services のページは、数百にもわたる情報豊かな記事と、Webサービス・アプリケーションの開発方法についての（初級、中級、そして上級の）チュートリアルを提供します。
  
  

著者について

ChrisはIBMのEmerging e-business Industry Architectureグループのアーキテクトとして、Webサービスやeビジネス標準の開発に積極的に関与しています。彼は現在、WS-I Basic Profile WG のIBM代表として、Basic Profile 1.1仕様のエディターをしています。また、W3C Web Services Architecture WGとOASIS Technical Architecture BoardのIBM代表でもあります。IBMに入社する前は、Web Services Architecture WGの議長を務め、XML Protocols WGのSun代表であり、また、XML Protocols WGのメンバーでもありました。

この記事を評価する

コメント

上に戻る

目次

• はじめに
• 2004年03月バージョン以来の変更
• まとめ
• 参考文献
• 著者について
• コメント