Webサービスの基礎知識
Webサービスは、コンピュータどうしを直接結んでリモートリソースにアクセスする方法の1つである。本稿では、SOAPのような基本的なWebサービス標準規格と、WS-*規格群として知られる高度な拡張機能を紹介する。
Webサービスがほかの手法と違うのは、シンプルなXMLメッセージを使って情報を送る、転送手段としてHTTPが使える、双方向（同期）通信が不要といった点だ。一般的に使える簡単なテクノロジと標準規格を利用していることから、Webサービスはコンピュータ間で情報をやりとりする手段としてすぐに定着した。
W3C（World Wide Web Consortium）の「Webサービスアーキテクチャ」（Web Services Architecture）には、Webサービスの厳密な定義が次のように記されている。
…コンピュータどうしによるネットワーク経由の相互運用可能なインタラクションをサポートするためのソフトウェアシステム。機械的に処理できるフォーマット（具体的にはWSDL）で記述されたインタフェースを備える。他のシステムはWebサービスとのインタラクションを、そのサービス記述に従った方法で、SOAPメッセージを使用して行う。こうしたメッセージは通常、XMLシリアル化やその他のWeb関連規格と共にHTTPを使用することで伝えられる。
この定義には、Webサービスのコアテクノロジが明確に記されている。SOAPはコンピュータ間でメッセージの受け渡しを行う標準化された方法、WSDL（Web Services Interface Language）はWebサービスのインタフェースを記述する言語、そしてXML（Extensible Markup Language）はこれら両テクノロジの基礎になるものだ。すべてのWebサービス標準規格は、これらの基本要素を何らかの形で利用して構築されている。SOAPとWSDLのほかに、UDDI（Universal Description Discovery and Integration）もコアとなるWebサービス標準規格の1つと見なされることが多い。これは、Webサービスに関する情報を保持するレジストリである。
XML
XMLはあらゆるWebサービス標準規格の基礎であり、どんな種類のデータでも記述できる柔軟な言語だ。データの各要素の記述には簡単なテキストタグを用いる。バイナリエンコーディングではなくテキストタグを使用するため、人が読んで理解できる。XMLの拡張機能を使うことで、開発者は既存のデータ定義に悪影響を与えることなく、新たなデータ要素を必要に応じて追加できる。
その本質的な柔軟性と処理ツールの多様さにより、XMLは新たなデータ形式を定義する手段として広く使われている。XMLの有用性を物語っているのが、地理的特徴（Geographic Markup Language）、数式（Math Markup Language）、グラフィック（Scalable Vector Graphics）をはじめとする膨大な種類のデータを記述するXMLスキーマの存在だ。また、Microsoft Office 2007とOpenOffice.orgの両オフィススイートもデータの保存にXML形式を利用している。
利点は多いが、XMLにも欠点はある。バイナリ形式と違って記述がかなり冗長になることだ。このことは概して、同じ情報をバイナリ形式でエンコードする場合よりも、必要な演算能力、ストレージ空間、帯域幅が増えることを意味する。こうした問題の多くを解決するために、効率的なXML表記の開発が進められている。
SOAP
SOAPはWebサービスのメッセージのフォーマットを定義するXMLベースの言語だ。従来はSimple Object Access Protocolと呼ばれていたが、今やその名称とは異なるものになっている。SOAPでは同期と非同期、双方のメッセージングパターンを扱うことができる。つまり、一方向のメッセージングパターンと要求/応答パターンのどちらでも使える。そのため、SOAPによる実装の柔軟性はきわめて高い。
SOAPメッセージには、ヘッダー（header）、ボディ（body）、エラー情報（fault）という3つの基本要素が含まれる。これらの要素は任意の種類のXMLデータを持つことができ、非常に柔軟性に富んでいる。通常、SOAPヘッダーにはSOAPメッセージの処理に関する情報が収められる。WS-*仕様の多く（WS-Security、WS-Addressing、WS-ReliableMessagingなど）は、追加の機能をSOAPヘッダーとして実装している。SOAPボディには、アプリケーションのデータ、各種関数のパラメータ、実行を完了した関数からの返り値が含まれる。また、フォールト要素はSOAPメッセージの処理中に発生したエラーの状況を伝える。
SOAPの主な欠点はパフォーマンスと帯域幅にある。XMLを使っているため、バイナリプロトコルに比べてデータの表記に伴うオーバヘッドが大きいのだ。SOAPとCORBAを比較した記事によると、SOAPはバイナリプロトコルと比較して30～60倍の処理時間がかかり、50～100倍の帯域幅を消費するという。こうした理由から、組み込みシステムにおけるコンポーネントの接続には、バイナリベースのリモートプロシージャコール・プロトコルであるCORBA（Common Object Request Broker Architecture）がよく使われる。
SOAPのパフォーマンスや帯域幅の問題を補っているのが、標準のポートやSMTP、HTTPS、HTTPといった標準プロトコルが使える点だ。一般的なインターネットテクノロジが使えることから、SOAPではファイアウォールの横断がほかのリモートプロシージャコール・プロトコルよりも容易である。ネットワークを再構成しなくても既存のネットワークトポロジとの相互運用が行えることは、SOAPが普及している要因の1つだ。
WSDL
WSDL（Web Services Description Language）は、外部のプログラムとWebサービスとのインタフェースを記述するXMLベースの言語である。標準化されたインタフェースを定義してプログラムの関数にするという点で、C/C++のヘッダーファイルやCORBAのIDLに似ている。WSDLはどんなプログラミング言語にも依存していないため、プログラミング言語に関係なくWebサービスに対するインタフェースを定義できる。
通常、開発者は開発ツールを使ってWSDLからWebサービス実装のスケルトンコードを生成する。反対に、既存のコードからWSDLを生成するツールも利用できる。すでにコードが存在する場合は後者の方法が簡単だが、そのコードの開発環境の影響を強く受けたWSDLになるので問題が起こりやすい。
WSDLは2つの部分で構成される。1つは、Webサービスでサポートされる動作と関連パラメータを記述する抽象的な部分だ。この抽象WSDLは、Webサービスの技術的な実装に依存しない。WS-*規格の多くは、抽象WSDLを使ってインタフェースを定義している。もう1つは、動作の詳細な実装とサービスのホスティング情報を記述する具体的なバインディングの部分だ。通常のWSDLでは、具体的なバインディングによって抽象的な動作がどのようにSOAPメッセージに結び付けられるかを記述するが、REST（REpresentational State Transfer）によるバインディングや、場合によってはCORBAへのバインディングも記述できる。また、1つのWSDLにおいて、サービスに複数のバインディングを実装することが可能だ。
UDDI
UDDI（Universal Description Discovery and Integration）は、サービスに関する情報を格納するXMLベースのレジストリである。UDDIには、ホワイトページ、イエローページ、グリーンページという3種類の情報が含まれている。ホワイトページに記されるのは、所在地や電話番号など、サービスを提供している企業に関する情報だ。イエローページには各サービスが分類表に従って記述されている。グリーンページはWebサービスのバインディングに必要な技術的な情報を記したものだ。このページには、WSDL定義を含めることができるが、WSDLの使用はWebサービスのインタフェースおよびバインディングに限定されていない。開発者や各種サービスは、標準化されたWebインタフェースを利用してUDDIにアクセスできる。
UDDIの呼び出しは可能だが、開発者は通常、UDDIにアクセスして新たなWebサービスを発見し、そうしたサービスを呼び出すコードを開発する。限られた数のWebサービスしか持たない組織の場合は、どうしてもUDDIレジストリが必要になるわけではない。1つの組織が持つWebサービスの数が増えると、新たなWebサービスの登録および発見のための構成要素としてUDDIが必要になってくる。
WS-*規格
開発者は、SOAPとWSDLだけでも基本的かつ機能的なWebサービスを作成できるが、複雑なインタラクションを扱うには相当な量のソフトウェアを実装しなければならない。大半のWebサービスでは、サービス品質の保証やセキュリティなど、高度な機能が必要になる。幸い、よく使われる機能の多くは、プロプライエタリおよびオープンソースの幅広いプロダクトで標準化と実装が行われている。
基本的Webサービスの拡張仕様群は、その名称のほとんどが“WS”で始まることから、WS-*ファミリーと呼ばれている。これらは、W3C（World Wide Web Consortium）やOASIS（Organization for the Advancement of Structured Information Standards）のような組織によって認定されたベンダ非依存の規格だ。よく知られたWS-*仕様として、WS-Security、WS-ReliableMessaging、WS-BPEL、WS-Addressingがある。
セキュリティ
Webサービスの使用例では、組織のネットワーク境界の外側やオープンネットワークにメッセージが送信されることが多い。ほとんどの場合、外部の組織はWebサービスの利用者である。Webサービスの所有者は、認証および認可が正しく行われたエンドユーザだけがサービスにアクセスできるようにする必要がある。Webサービスメッセージの保護、認証情報の引き渡し、セキュリティポリシーの記述など、セキュリティ関連の問題に対処するWS-*のセキュリティ規格には、さまざまなものがある。
WS-Securityは、SOAPメッセージへのセキュリティの適用に必要な基本事項を定めたものだ。一般用語としてのWS-Securityは、返ってきたメッセージが所定の受信者からのものであることの確認、認証を受けていない者によって送信中のメッセージが変更されないことの保証、対象としていない受信者によるメッセージ参照の防止、身元の証明に必要な情報の引き渡し、といった手段を提供するものを指す。一方、技術用語としてのWS-Securityは、SOAPメッセージに暗号化およびデジタル署名を標準化された形で適用する方法やセキュリティトークンの引き渡し方法を定めたものである。WS-Securityは、XML暗号化、XMLデジタル署名、SAML（Security Assertion Markup Language）といった従来の規格の上に成り立っている。また、Kerberos、PKI（Public-Key Infrastructure）、SSL（Secure Sockets Layer）など、XML以外のセキュリティモデルも組み込まれている。
WS-Securityが提供する標準規格はメッセージにセキュリティを適用する方法に関するものだが、適用すべきセキュリティ基準は定められていない。一方、WS-Policy言語を使用するWS-SecurityPolicyでは、サービス所有者によるセキュリティポリシーの記述が可能だ。サービス所有者は、許容できる暗号化アルゴリズム、セキュリティトークンのフォーマットなど、セキュリティ適用の方法とタイミングに関する情報を指定できる。
WS-Securityは個々のSOAPメッセージは保護できるが、相互に関連する一連のSOAPメッセージの保護には対応していない。通常のWebサービスでは、インタラクションの途中で一連のメッセージを利用者と交換することがよくある。WS-SecureConversationは、WS-Trust、WS-SecurityPolicy、WS-Securityに基づいて構築されており、同じセキュリティコンテキストに含まれる一連のメッセージを保護することができる。
WS-Federationは、種類の異なるセキュリティドメイン間で信頼関係の仲介を行うための言語と手続き群を提供する。企業はこの仕様を使うことで、社外パートナー組織の社員に対する認証および認可情報の管理を必要とすることなく、そうした組織と情報をやりとりできる。極端にいえば、Webサービス向けのシングルサインオン・ソリューションのようなものだ。WS-Federationを使えば、新たなWebサービスの利用者がそのサービスプロバイダのアカウントを作成しなくても、適切な認証情報の自動的な引き渡しが可能になる。
メッセージング
Webサービスメッセージをある地点から別の地点に届けるのは必ずしも簡単ではない。Webサービスは、適切な数のメッセージを適切なエンドポイントで受け取るようにする必要がある。だがSOAPは、企業向けサービスで求められる高度なメッセージング機能をもともとサポートしていない。
WS-Addressingは、こうしたSOAPに関する制限に対処したものだ。SOAPヘッダーには宛先情報が一切与えられない。よって、普通はWebサービスのURLが宛先情報になる。しかし、このやり方だとWebサービスの高度なルーティングや設定に制限が生じる。たとえば、Webサービスは呼び出し元以外のアドレスに応答を返せなくなる。WS-Addressingは、対象とする受信者、reply-toアドレス、メッセージIDを識別する手段を備えている。また、アドレッシングエラーを特定できる仕組みもある。WS-Addressingはその他のWS-*規格の多くで利用されている。
WS-ReliableMessagingは、一連のメッセージを信頼できる形で配信することを保証する。この仕様には、非常に柔軟性の高い配信保証が規定されている。サービス所有者は、利用者によるメッセージ受信に対して、順序どおり（in order）、高々一度（at most once）、厳密に一度だけ（exactly-once）、少なくとも一度（at least once）という要件を指定できる。また、確認応答の送信について調整を加えることも可能だ。サービス側は、個々のメッセージまたは一連のメッセージに対して確認応答を要求できる。配信完了の確認応答が必要なのか、配信エラーの通知だけを求めるのかといった指定もできる。
さらに別の規格では、出版/購読（publish/subscribe）パターンのような高度なメッセージパターンが定義されている。出版/購読メッセージパターンは、会報、新聞、雑誌を購読したことがある人にはおなじみのものだ。通常は、情報の発信者が新たなメッセージを公開する。購読者は興味のあるメッセージに申し込むことで、受け取るどのメッセージを選択する。多くの場合、通知ブローカー（notification broker）と呼ばれる仲介者が存在し、購読申し込みの管理を行っている。そのおかげで、情報発信者は購読の管理、全購読者への情報配信といった面倒な処理に追われずに済む。
出版/購読メッセージングの実装において競合する2つの規格として、WS-NotificationとWS-Eventingがある。技術的な違いはいくつかあるが、意図するところは同じである。結局、利用する側は実装面での差に基づいてどちらかを選んで使うことになるだろう。
ポリシー
WSDLはWebサービスの動作やバインディングを記述するものであり、セキュリティやサービス品質など、機能面以外の制約は十分に記述できない。WS-Policyは、Webサービスのポリシーを記述するための全般的な枠組みである。また、WS-SecurityやWS-ReliableMessagingなど、ほかのWS-*規格には、それぞれの要求に関連したポリシー文書が用意されている。同じように、それぞれの組織でもWS-Policyの枠組みを使って標準でない独自のポリシー文書を作成することができる。WS-Policyの利用により、各組織のWebサービスに対するバインディングの必須およびオプション要求の公表が可能になるわけだ。
オーケストレーション
Webサービスは完全なアプリケーションであるとは限らず、より大規模なアプリケーションの一部になっていることもある。Webサービスをより大きなプログラムのサブルーチンの1つと見なすと、いろいろな点で都合がいい。何か役に立つ機能を提供するには、複数のWebサービスを組み合わせて複雑なタスクを実行できるものが必要だ。開発者は一般的なプログラミング言語を使ってWebサービスどうしを結合できる。あるいは、Webサービスのオーケストレーション言語を使うことも可能だ。
WS-BPEL（Web Services Business Process Execution Language）は、複数のWebサービスから複雑なタスクを組み上げるXMLベースのオーケストレーション言語である。BPELは一種のスクリプティング言語と見なせるが、Webサービスを念頭において作られている。開発者はBPELスクリプトを作成して、その結果をオーケストレーション・エンジンで実行する。なお、BPELスクリプトはベンダの実装に依存しないものにする必要がある。そうすれば、オーケストレーション・エンジン間での移植が可能になる。
BPELスクリプトを容易に作成できるグラフィカル・モデリングツールがいくつか存在することも、WS-BPELの強みだ。最低限の知識がある業務アナリストは、それらのツールを使って業務プロセスのモデリングを行ったり、モデルから実行コードを生成したりできる。今後、こうしたツールは、技術的な知識がない業務アナリストでも新たなアプリケーションを作成できるほどに進化していくだろう。
エンタープライズ・サービスバス
エンタープライズ・サービスバス（ESB：Enterprise Service Bus）は、Webサービスの領域を超えた概念である。標準規格の集まりというよりも、広い範囲にわたるテクノロジの実装を指す用語といえる。ESBを支える基本的概念には、メディエーションとルーティングによる種類の異なる分散アプリケーションの統合が含まれる。ESBによって加えられるのは、共通に必要な機能であることが多い。一般的なサービスでサポートされる機能としては、WS-*規格群、ロードバランシング、高度なメッセージルーティング、トランスポート層プロトコル間の変換、メッセージフィルタリング、業務プロセス管理、ログ記録、監査、高度なエラー処理がある。
オープンソースのWebサービス
オープンソースソフトウェアは、Webサービスを実装する人々の間でもかなり普及している。「企業におけるオープンソースソフトウェアの役割の拡大」（Open Source Software’s Expanding Role in the Enterprise）という米Forrester Researchのレポートでは、調査に参加したITマネージャの57％がサービス指向アーキテクチャ（SOA：Service Oriented Architecture）への移行を進めるうえでオープンソースは“重要”または“とても重要”だと答えている。また、オープンソースソフトウェアを使う理由の上位を占めたのは、オープン規格に対応している、使用上の制限がない、ベンダ・ロックインを回避できるといった項目だった。
オープンソースのWebサービス用ソフトウェアのなかで、Apache Axis2は非常によく知られた柔軟性の高いWebサービスエンジンの1つだ。SOAPメッセージの複雑な処理に対処できるプログラミング・インタフェースを備え、JavaおよびC++実装の双方で利用できる。
Axis2のすばらしさの1つは、Webサービス開発者がモジュール内に新しい機能を追加できる点にある。Axis2は、アドオンモジュールとしてWS-Addressingを実装している。また、デフォルトでSOAPメッセージを監視するモジュールが含まれている。開発者は独自のモジュールを開発できるほか、Sandesha、Rampart、Kandulaなど、公開されているAxis2モジュールを利用することもできる。SandeshaはWS-ReliableMessagingをサポートし、RampartではWS-Securityの追加が行え、KandulaはWS-Coordination、WS-AtomicTransaction、WS-BusinessActivityを実装している。
Axis2以外にも、オープンソースのWebサービス用ソフトウェアはたくさんある。Apache MuseはWS-Notification、WS-ResourceFramework、WS-DistributedManagementを実装している。WS-BPEL向けエンジンとしてはApache ODEがある。また、Muleは使いやすくて強力なエンタープライズサービスバスだ。これらのプロジェクトは、Webサービステクノロジを中心にして構築されたオープンソースの健全なエコシステムの例である。
次なるステップ
Webサービスを手っとり早く開始する方法の1つは、実際に使ってみることだ。ここで紹介したオープンソースソフトウェアを使えば、大きな事前投資なしにWebサービステクノロジを試すことができる。開発者は、サンプルのWebサービスをスクラッチから構築してもよいし、リモート対応の既存ソフトウェアをWebサービスでラッピングして用意することも可能だ。こうしたアプローチは、大きなリスクを生むことなく、Webサービスの価値を短期間で実証してくれる。
結果的に、Webサービスは多くのメリットを組織にもたらす可能性がある。Webサービスを利用すれば、レガシー・アプリケーションのロジックをネットワーク上に公開でき、Webサービスがなければ分断されていたアプリケーション間でのデータ共有が可能になる。また、組織全体で共通して必要な機能やデータを共有することで、リソースも再利用できる。それぞれの組織がこうしたメリットを享受するには、どうすれば持てるインフラストラクチャの範囲内でWebサービスを最適な形で利用できるかを明確にする必要があるだろう。
Shawn Hermansはグローバルな技術コンサルティング会社、米Booz Allen HamiltonでITのエキスパートとして活躍。Webサービス、サービス指向アーキテクチャ、ネットワーク移行、情報セキュリティ、データ戦略に関する専門知識を提供。
ITManagersJournal.com 原文
