Webサービス標準化の全体像と課題
Webサービス標準化の全体像と課題
XMLは1998年の誕生から6年を経て、いまやコンピュータデータの共通言語として確固たるポジションを確立し、数々の新しい技術の基盤技術ともなっている。その新技術の中でも、注目を浴びているWebサービスの標準化に着目してみよう。Webサービスは当初、SOAP、WSDL、UDDIの３つの技術で構築されるサービスがであると定義されていたが、Webサービスを繋いで実際に動かすためにはさらに多くの取り決めが必要であることから、数多くのWebサービス関連仕様の提案と標準化が進んでいる。これらの仕様は「WS-」で始まる名称をつけられることが多いため、ここではこれらをまとめて「WS-標準化」と呼ぶこととする。個別仕様の詳しい内容は専門の記事に譲るとして、ここではWebサービスを取り巻く数多くの標準化の動向を見てみよう。
なぜ「WS-標準化」が花盛りなのか？
表1は、現在標準化や提案が行われているWebサービス技術、つまりここでいうところの「WS-標準化」の一覧である。数の多さに驚いた人も多いのではないだろうか。それでは、何故これほど多くの「WS-標準化」が行われているのだろうか？
Webサービスを一つの側面から簡単に説明すれば、人間を対象としてサービスしていたWebサイトの対象をコンピュータに代えたものということができる。例えば、物品販売のWebサイトは、ブラウザを使った人に対するサービスであるが、物品販売のWebサービスは、他のコンピュータが自動的に発注を行ってその結果をデータとして返すサービスである。WebサイトとWebサービスの違いを整理すると図1のようになるが、ここで重要なことはWebサービスではプログラムによって自動的に処理されるという点である。Webサイトの場合に人が行なっていた様々な行為、例えば「相手を信用するのかどうかの判断」、「同じ請求書が2回来ていないかかどうかの確認」、「別の処理（例えば購入処理と資産管理）との連携」などを、Webサービスではコンピュータ自動で処理することになる。つまり、これまで人が行っていた様々な処理をコンピュータが行うのであり、それらの処理を自動で行なうための約束事が必要で、それこそが現在数多く提案されている「WS-標準化」である。
「WS-標準化」を整理する
図2は、表1に示した「WS-標準化」の中で主要なものを整理しWebサービス関連仕様の標準化の全体像として示したものである。
図2では、各仕様を示すボックスの色はその仕様を標準化している団体を示す。灰色については現時点でまだ標準化団体に提出されていない標準案である。この色分けからまず、Webサービスに関連する標準化に団体は4つあり、それぞれが大まかな役割分担ができていることがわかる。つまり、IETFはインターネットプロトコルなど通信基盤の分野、W3CはXMLやSOAPを初めとする基本的なデータ記述の分野、OASISはそれら基本技術をベースとした応用技術の分野、そしてWS-Iはそれらの技術の実装における相互接続性の分野という役割分担である。
上下方向は技術のレイヤーを示しており、上下に重なっている仕様はそれぞれ基本的に組み合わせて使うことができる。同じレイヤーで左右に間隔を空けて配置してあるものは、類似の仕様が対立していることを示している。
競合仕様の状況
図を見ると仕様が対立した部分が3箇所ある。これらは、全体を理解する上でも重要なので、以下で具体的に見ていこう。
(1) 信頼性メッセージング：WS-Reliability 対 WS-ReliableMessaging
この2つの仕様は、どちらもWebサービスのメッセージの信頼性を確保するためのものである。信頼性を確保するというのは、(1)メッセージの到達を確実にする、(2)重複到達を排除する、(3)到達順番を保証するという3つの大きな役割を意味する。インターネットのメッセージングは不特定のサーバーを介して行われるものであり、途中でどこかのサーバーのダウンによってメッセージが失われることもあり、また到達の順番も保証されていない。しかしながら、実際のビジネスにおいては個々のドキュメントは、確実に、重複なく、正しい順序で相手に到達しなければならない。例えば、注文書が2回届いたり、キャンセル通知が元となる注文書の前に届いたりしてはいけない。
WS-Reliabilityは、富士通、日立、NECなどが提案し、現在OASISで標準化が進められている仕様である。これは、ebXMLのmessaging Serviceをルーツとした実績のある実装である。特徴としては、他のセキュリティ技術に対して非依存であることロイヤリティフリーを宣言していることなどが挙げられる。MS-Reliabilityは、WS-ReliableMessagingは、IBM, Microsft, Tibcoなどが提案したもので、現時点では標準化団体にはまだ提出されていないが、提案各社の製品に実装されている。
WS-ReliabilityとWS-ReliableMessagingはどちらとも同様の目的のために開発されたものであり、あきらかに対立している。そのためOASISでは、両仕様の統合をに呼びかけており、年内には何らかの調整が行われるであろう。
(2) サービスの連携：BPEL4WS 対 WS-CL (Choreography Language)注
この2つの仕様は、どちらも複数のWebサービスを連鎖させビジネスフローとして使うための仕様であり、例えば、Webサービスの起動、データの操作、障害の通知、またはフローの終了などのアクティビティを作成し、それらを組み合わせることで複雑なプロセスを組み立てることができます。またアクティビティを、順番に実行するのか、並列して実行するのか、特定の条件に基づいて実行するのかなどを定義することも可能だ。
BPEL4WSはOASISで標準化が進み、WS-CLはW3Cで標準化が進んでいるため、標準化団体同士の争いと見られている側面がある。しかしながら、Webサービスの応用領域は、W3Cが従来カバーしてきた基礎技術領域とは違うためW3Cで標準化することが適切かどうかという疑問の声も多い。実際、図2を見てもWS-CLが他のW3Cの標準化レイヤーと異なり飛び地のようなポジションなっていることがわかる。
また、MicrosoftがWS-CLを離脱するなどの行動や、WS-CLでのディスカッションが進展していないなどのことから、私はこの2つの仕様はBPEL4WSを中心に収斂していくものと考えている。
(3) トランザクション：WS-Transaction 対 WS-CAF
この2つの仕様は、どちらもWebサービスを使ってトランザクション処理を行う基盤となる仕様である。Webサービスでトランザクション処理を実現するためには、複数の異なるコンピュータ環境をまたがって、処理のコミットやロールバック処理を行なうため、様々な取り決めと厳密な実装が必要となる。WS-Transactionと関連仕様のWS-CoordinationはIBM、Microsoftなどにより提案されているWebサービスによる分散トランザクションを可能にするための標準仕様案である。従来のクローズドな環境やベンダーで行なわれていたトランザクション処理を、不特定多数でWebサービスで結合した環境で可能にする。
そしてWS-Transactionの発表から約1年後の昨年8月にIONA, Oracle, Sun MicrosystemsなどがWS-CAFを発表した。WS-CAFは、3つの仕様から構成され（表1参照）、WS-Transaction + WS-Coordinationのカバー領域と重複している。これらは主として各社が提供する製品における実装の都合に起因している。
WS-CAFはOASISでの標準化が始まっており、IBM, Microsoftといった実力派対標準化団体という構図になっている。Webサービス連携に関する仕様が複数存在すると、Webサービスを連携させるために複数の仕様を実装しないといけないことになるため、Webサービス構築側もWebサービス利用側も余計にコストがかかってしまうこととなる。
その他の注目「WS-標準化」
次に、対立しているわけではないが、Webサービスの実用化にあたり注目すべき仕様をピックアップする。
(1) セキュリティ：WS-Security
セキュリティに関しては、多くの仕様が提案されており競合があるように見えるかもしれないが、基本的にはそれぞれが補完的になるものである。ベースになるデータセキュリティの仕様であるXML Signature（XML署名）、XML Encryption（XML暗号化）は特にWebサービスにかかわらずXMLデータ全般に適用できるデジタル署名と暗号化の仕様であり、WS-Securityはこれらを使用し、その上で、WS-Securityでは、デジタル署名、暗号化、セキュリティトークンの付加を提供する。
さらに、サービスによって必要なセキュリティを付加するしくみとして、WS-Policy(※)、WS-Privacy(※)、WS-Trust(※)、WS-SecureConversion(※)、WS-Federation(※)、WS-Authorization(※)などが開発中である。（※の概要については表1参照）
(2) サービスの管理：WS-Manageability
OASISのWS-Distributed Management TCで標準化が進められているWS-Manageabilityは、Webサービスを管理するWebサービスを規定する仕様である。従来はシステム管理ツールが独自の技術によってそれぞれのシステムを監視、管理していた。WS-Managabilityは、複数のWebサービスによって組まれたシステムについての可用性、状態、パフォーマンス、使用状況、構成などをWebサービスによって管理するための仕組みである。
「WS-標準化」の今後
Webサービス周辺の標準化仕様提案は未だに衰えを見せない。例えば、2004年1月8日には、Microsoft, BEA, Tibco社がWS-EventingというWebサービスにおけるイベント処理のための新仕様を提案した。Webサービスをあらゆる場面で適用していくためには、今年いっぱいはまだ新しい仕様の提案や標準化が続くであろう。しかし、先に紹介した3つの対立する仕様に関しては、仕様が対立したままでは各ベンダーの実装の障害にもなるため、各社何らかの決着を付けたいという思惑が働いており、近いうちに何らかの形で統合され実用的な仕様となるに違いない。
混乱しているように感じられる「WS-標準化」も、このように整理すれば、たいして混乱しているわけではないことがわかる。Webサービスをビジネスに使う場合には数々の約束事が必要で、その仕様が揃ってきているということだ。対立している3つの領域の統合もそう遠いことではない。今年から来年にかけて、一般的な企業でもWebサービスを一つの技術基盤として検討する年となるだろう。
注（追記）：W3CのChoreography仕様は、2004年4月27日にWS-CDLとしてワーキングドラフトが発表された。（図２は更新済み）
日時: 2004年04月27日 13:00 | | TrackBack
