Webサービスの基軸を構成するのは、SOAP、WSDL、UDDIの3つのテクノロジだ。この連載では、Webサービスの基本的な知識を身に付けるために、この3つのテクノロジの背景と仕様、機能などを分かりやすく解説していく。(編集局)
Webサービスとは、インターネットの標準技術を使ってネットワーク上に分散したアプリケーションを連携させる技術のことだ。あるいは、その技術によって連携させられるアプリケーションそのものをWebサービスと呼ぶこともある。
Webサービスのことを「アプリケーション連携技術」とひと言で述べたが、実際のところWebサービスは単一の技術ではない。Webサービスは、メッセージ技術やセキュリティ技術やトランザクション管理技術など、実に広い範囲に及ぶ技術で構成されている複合的な技術だ。ただし、Webサービスを構成する技術の中にはまだ策定中のものが多い。さらに、重複する複数の技術が競合中で最終的にどれが生き残るのか分からないものさえある。
Webサービスはまだ発展の途上にある技術なのだ。
そこで、この連載では、Webサービスの中核をなす技術で、しかも仕様が比較的定まっている以下の3つの技術に話題を絞って解説する。
Webサービスに対応した便利な開発ツールが数多く出回っているので、開発者はSOAP/WSDL/UDDI仕様の詳細を覚える必要はないだろう。そこでこの連載では、仕様が策定された背景や、そのように定められた理由を説明することによって、仕様を覚えることではなく、理解することを目標にして執筆を進めたいと思う。
連載の皮切りとしてSOAP(Simple Object Access Protocol)を取り上げる。今回はSOAP規格が登場した背景を説明しよう。
Webサービスを利用するためには、クライアントからサーバにサービスの要求やパラメータを渡したり、クライアントからサーバに処理結果を返したりすることが必要だ。Webサービスでは、HTTPやSMTPなどの通信プロトコル(下位プロトコルとも呼ぶ)に乗せたXML形式のメッセージによって、それらのやり取りを実現する。
つまりSOAPとは、Webサービスで使用されるメッセージのデータフォーマットや、メッセージの処理ルールを定めた通信規約のことだ(図1)。またSOAP規格に準拠したXML形式のメッセージのことをSOAPメッセージと呼ぶ。
SOAPという名前は「Simple Object Access Protocol」の略だ(注)。その名前が示すとおりSOAPは、元をただせばネットワーク上に存在しているオブジェクトにアクセスするためのプロトコルとして開発されたものだ。しかし、そのような分散したオブジェクトを統合する技術ならば、以前から分散オブジェクトがある。では、SOAPが必要とされたのはなぜだろうか?
編注:SOAP 1.2からは、SOAPは何かの略ではなく「SOAP」という固有名詞とする、とのこと。
分散オブジェクト技術は、異なるコンピュータ上に分散したアプリケーションをオブジェクトとしてとらえ、オブジェクト間でメッセージを交換することによって分散処理を実現する。こうして、アプリケーションを利用するにあたって、動作しているプラットフォームやコンピュータの場所を隠蔽できるようになる。また、分散オブジェクト技術では、各オブジェクトのインターフェイスをIDL(Interface Description Language)という言語で記述する。IDL対応の開発ツールを使うことによって、オブジェクトのインターフェイスに対応するコードを容易に実装できるようになっている。
分散オブジェクト技術としては、オブジェクト指向技術のための標準化団体OMG(Object Management Group)が策定したCORBA(Common Object Request Broker Architecture)や、マイクロソフトが策定したDCOM(Distributed COM)などがある。
しかし、これまでの分散オブジェクト技術には問題点があった。1つ目の問題点は、異なるアーキテクチャによる分散オブジェクトシステムの相互接続が容易でないことだ。もちろん、CORBAで構築したシステム間や、DCOMで構築したシステム間なら、問題なく相互接続できる。しかし、CORBAの世界とDCOMの世界の通信を実現するには、両者のプロトコルを変換して2つの世界を橋渡しするための仕組みが必要になってしまうのだ(図2)。
別の問題点は、分散オブジェクト技術で採用されているプロトコルが独自のプロトコルであることだ。例えば、CORBAではIIOP(Internet Inter-ORB Protocol)というインターネットの世界では一般的ではないプロトコルが採用されている。そのため、同じ分散オブジェクト技術で構築したシステム同士でも、インターネット経由でメッセージを交換するためには、ファイアウォール設定の変更が求められることが多い(図3)。
このように、CORBAやDCOMはイントラネットやLANなどの「閉じた」世界で使用するには向いているが、ファイアウォールを通過し、Web上のいろいろな通信プロトコルやプログラムに対応することは難しい。
そこで、分散オブジェクト技術が普及するにつれて、特定の技術にロックされることなく、さまざまなプラットフォーム上で稼働するオブジェクトを利用したいという要望が出てきた。また、Web上に分散するオブジェクトを利用するためには、インターネットの標準技術を採用することが望ましいことも分かってきた。SOAPは、HTTPやXMLなどのインターネット標準技術を使うことによって、Web上の分散オブジェクトをプラットフォームの壁を越えて利用することを可能にするために開発されたプロトコルだ。
SOAPはその名の示すとおり、“シンプル(Simple)な”プロトコルだ。CORBAやDCOMのようなトランザクション管理はできず、その分軽量だが、それゆえにWeb上の分散オブジェクトを「ゆるやかに」結合するのに適している。「ゆるやか」とは、システム上の大きな変更を必要とせず、例えばCOMアプリケーションとCORBAアプリケーションを接続することもできるということだ。つまり、CORBAやDCOMなどのような閉じた世界の密な結合から、SOAPによるプラットフォームに依存しないグローバルでゆるやかな結合へと変化することが求められ、登場したのがSOAPと言うことができる。
SOAPが注目され始めたのは1999年のことだ。この年の9月、DevelopMentor、Microsoft、Userland Softwareの3社が策定したSOAPバージョン0.9が公開された。同年11月、この3社は、SOAPバージョン1.0をインターネット関連技術の標準化団体IETF(Internet Engineering Task Force)へ提出した。この時点のSOAPは、メッセージを運ぶ下位プロトコルとしてHTTPだけをサポートしていた。
2000年5月、SOAPバージョン1.1(以下、SOAP1.1)は、XML関連技術の標準化団体W3C(World Wide Web Consortium)に技術ノートとして提出された。SOAP1.1は、HTTP以外のプロトコルもSOAPメッセージを運ぶ下位プロトコルとして使用できるようになった。さらに注目できる点はSOAP1.1の策定にIBMとLotusが加わったことだ。こうして、SOAPは特定のベンダに依存しない規格へと変化していった。
前項で述べたとおり、SOAPは分散オブジェクト技術の発展の過程で登場した規格だ。だが、SOAPの登場は、単に既存の分散オブジェクト技術の改良にとどまらなかった。2000年9月には、Web上のSOAP対応のアプリケーションであるWebサービスを、公開したり検索したりするための規格UDDIバージョン1が発表された。また同じ月にWebサービスのインターフェイスの記述言語WSDLバージョン1.0が発表された。このようにSOAPの登場を皮切りにして、Webサービスという新しい世界の中核が次々と確立されていった。
さまざまなベンダやオープンソース団体がSOAP1.1を実装したツールを提供するようになると、異なるツールで開発したシステム間でSOAPによる相互接続に不具合が生じることが分かってきた。SOAP1.1の仕様にあいまいな点があったため、仕様の解釈にゆらぎが生じたのだ。
SOAPの仕様からあいまいさを排除するため、W3CはSOAPバージョン1.2(以下、SOAP1.2)を策定中だ。この記事を執筆している時点(2002年11月)でSOAP1.2は最終草案の段階に来ている。SOAP1.2が最終的な勧告になるのも間近だ。
この記事を執筆している時点で稼働しているWebサービスや開発ツールのほとんどはSOAP1.1対応だろう。そこで、この記事ではSOAP1.1規格に沿って説明し、SOAP1.2で仕様が大きく変更されている見込みのところではその点を言及するにとどめる。SOAP1.2は最終草案の段階であり、最終勧告の仕様ではさらに変更される可能性が残っているからだ。
今回はWebサービスのためのメッセージ規格であるSOAPが登場した背景と規格の概要を説明した。次回は、SOAPメッセージの内部構造を詳しく見てゆくことにする。
Copyright © ITmedia, Inc. All Rights Reserved.