お使いのブラウザは最新版ではありません。最新のブラウザでご覧ください。

CNET Japan ブログ

Reliable Messaging(高信頼性メッセージング)は第8のレイヤーになるか

2003/09/19 23:09
  • このエントリーをはてなブックマークに追加

IT-Director.comにWeb Services Reliable Messaging Updateという記事が掲載された。

記事は

In March I wrote two articles about Web Services Reliable Messaging, describing two competing specifications: WS Reliability from Sun, Oracle and friends and WS Reliable Messaging from BEA, IBM, Microsoft and Tibco (BIMT). Since I wrote some progress has been made.

と始まる。この記事では、OASISで順調に検討が進んでいるWS-RM TC(日本のNEC、富士通、日立が発起人だったとは岡部さんのXMLステータスリポートで初めて知った)とその対抗馬となるBIMT仕様についての進捗状況が簡単に述べられている。(今回は、このつまらない対立自体については述べない)

このReliable Messagingというものは、平たく言えばインターネットを介して信頼性の高いデータ送受信を行えるプロトコルを作ろうという考え方だ。受信に成功すればACKを返信し、ACKが返ってこなければ再送が行われるという、従来のネットワーク屋にもすんなり理解できる、ごくごくこなれた考え方に基づくものだ。

ここで、人によっては「確実にデータ転送するって、FTPと何が違うの?」という非常にベーシックな疑問を持たれるかも知れない。これに簡単に解説をしておこう。FTPなどでは比較的安定したファイル転送はできるが、単体では「確実な送受信」は期待できない。例えば、転送の途中でセッションが切れた場合などには再送を考えなければいけないのだが、そもそも再送する際にファイル名は同じで上書きしてよいのかどうか、また相手のFTPサーバの上位に位置するアプリケーション(または人)が転送が完了しているかどうかを判断するためにインデックス用のロックファイルを置くのかファイル名のポリシーとリネームで制御するのか、など、汎用性を考慮し始めるとFTPの上位層で考慮しなければいけない決め事は無数にある。これに応えるのがReliable Messaging仕様である。実際、これらの仕様はHTTPやFTPなどの下位プロトコルと独立してモデル化されることが多い。

最新仕様はOASISのWS-RM TCの仕様書ページを確認していただきたいのだが、ここではメッセージ識別子(ファイル名のようなものだ)の付番方式や再送の考え方、メッセージの永続化ルール、再送に伴う重複除去、順序性の保証などの約束事が追加される。これらのパラメータやタイムスタンプも含めたあらゆるメタ情報をパッケージングするためのエンベロープ(これがまさにSOAPだ)を定義しているのがこの仕様書というわけだ。

ところで、同じOASISにebXML Message Service V2.0(以下ebMS)というものがあるのをご存知の人もいるかと思う。これは実は、2001年に全く同じ目的を果たすために誕生した "Yet Another SOAP-Based Reliable Messaging" なのである。そして、こいつのVersionは今や2.0だ。

これらの仕様書を読まれた方ならお気づきと思うが、笑ってしまうぐらいにそっくりな文面なのだ。(機能的な有意差はと言えば、HTTPバインディングが強化されたことの影響だと思うけど返信モードでResponse/Callbackに加えてPollモードが加わったぐらい?)あまつさえ、Editorも重複している。(富士通の岩佐さんとか)

では、なぜこのような作業の重複が延々と行われているのか?

これはひとえに、仕様というものは世代や文化のたまものである、ということの証左に他ならない。ebXMLはUN/CEFACTとOASISのジョイントプロジェクトとして始まった経緯からも判るように、古くレガシーシステム時代から連なるEDIの歴史の延長線上にあるものだ。一方、Webサービスはインターネット世代のカタギな技術屋連中が、SOAPというカプセル化アイデアにWSDLというインターフェース記述言語をかぶせたらCORBAなんかより全然カジュアルだし面白いゼ、という技術スタンスから生まれたものだ。

これらの全く異なるバックグラウンドを持つ2つの世代・文化が、機能的に見ればそっくりな2つの仕様を生み出した。お互いにSOAPを用いるというところまで一致したにも関わらず最後に交差できなかったポイントは、WSDLというAPIジェネレーション的指向か、CPPAというビジネスコンテキスト指向か、という差異であると思う。

敢えて個人的な意見を言わせてもらえば、WSDLは発想がCORBAのIDLのレイヤーに近く保守的で、現時点ではCPPAを育てていく方が未来が明るいように思えてならない。そういう意味では、Webサービス世界のGeekの方がプログラミング原理主義的とさえ形容できそうなほど保守的だったとも言えるわけで、一昨日のBlogに書いた硬派から軟派へのシフトが始まりつつあることを象徴していて面白い。

そう、今やOSIの7層参照モデルなんていう時代はとっくに終わっていて、今や7層目(HTTPやFTPといったアプリケーション層)のさらに上のレイヤーでプロトコルスタックが積まれているのだ。Webサービスについての情報が整理され、こなれてくるであろう数年後にこんなことに気付いているようではネットワークエンジニア失格だ。Reliable Messagingは、情報が錯綜して混沌としたWebサービス関連技術の中で、明らかに突出した重要性を持つものだ。セキュリティなど後回しでいい。SSLを知らなくてもSocketを知っていればHTTPは語れるが、HTTP(使い道)を知らなくてはSSLはうまく説明できないのだから。

この燦然と光り輝く「第8のレイヤー」は間違いなくネットワーキング技術の折り返し地点となるだろう。これを消化できるかどうかが、世のネットワークエンジニアにとって硬派から軟派へ進んでいくか、またはほんの一握りのエリート硬派でいつづけるかを選択する試金石となるに違いない。

※このエントリは CNET Japan ブロガーにより投稿されたものです。朝日インタラクティブ および CNET Japan 編集部の見解・意向を示すものではありません。
運営事務局に問題を報告

最新ブログエントリー

個人情報保護方針
利用規約
訂正
広告について
運営会社