連載 ビジネスWebサービス最新事情（1）
高度化するWebサービスの仕様群を整理する

Webサービスをビジネスで利用するために、高度なセキュリティやトランザクション処理、複数のWebサービスの連携などを実現するさまざまな仕様が策定されようとしている。本連載では、これらの仕様を理解するための解説を行っていく。（編集局）

日本アイオナテクノロジーズ（株）
小野沢 博文
2003/8/1


■拡張が続くWebサービス仕様

　Webサービスは基本的に、WSDL、SOAP、UDDIといった仕様で構成されていることがよく知られています。しかし現在では、実際のビジネスでWebサービスを利用するためのさまざまな要求にこたえるため、これらの基本仕様の上に、セキュリティ、トランザクション、コレオグラフィといった幅広い拡張仕様が存在し、または仕様策定のための議論が行われています。そのため、広い意味でのWebサービスは、さまざまな仕様から構成されるものとなりました。

　しかし、それらの個々の要素技術を詳細に理解するには、W3CやOASISの仕様書、あるいは製品マニュアルなどの膨大なドキュメントを読まなければならず、その一方でWebサービスの全体像を把握するための情報も欠けています｡しかも、Webサービスの仕様策定にはさまざまな企業や団体が関係しており、その動向は目まぐるしく変化しています。

　そこで本連載では、こうした「ビジネスにかかわるWebサービス仕様の全体像の把握」と「各仕様の概要を把握」するためのガイド役となり、読者の方々のWebサービスへの理解と実用化を促進することを目指していきます｡

　第1回は、現在におけるWebサービスが、どのような仕様の組み合わせで成り立っているのかを解説し、全体像を把握していただこうと思います｡そして第2回以降では、セキュリティ、コレオグラフィ、トランザクションといった各テーマごとに関連する仕様を取り上げ、その内容を掘り下げていきます｡

■Webサービスの全体像

　Webサービスの第1の目的は、インターネットやイントラネット上でアプリケーション・プログラム間の連携を可能にすることです。そのために、ベンダごとの独自技術ではなく、SOAPやWSDLといった、XMLをベースにした標準技術を使用します。そして、単にXMLベースの通信を可能にするだけではなく、ミッションクリティカルな分野や複雑な業務にも十分に適用できるように、SOAPやWSDLなどの基本的な仕様の上に、セキュリティ、トランザクション、コレオグラフィなどの拡張仕様が構築されています。

　Webサービスを構成するこれらの要素の関係を図解すると下のようになります。各構成要素は実際には非常に複雑に絡み合っており、2次元の図で表現するのは多少無理があります。この図はあくまでも大ざっぱな理解のためだと思ってください｡

図1　Webサービスを構成する仕様の全体像 SOAPなどを基盤として、トランザクション、コレオグラフィ、セキュリティ、セマンティックWebなど、より高度な仕様へと拡張されている

　今回は、これらの構成要素の主なものを簡単に説明することで、拡張し続けるWebサービスの全体像を把握していただき、次回以降で各要素をさらに詳しく理解するための足掛かりにしていきます｡

■基本プロトコル「SOAP」

　Webサービスで現在最も広く利用されているプロトコルがSOAPです。SOAPは、もともとSimple Object Access Protocolの略でしたが、最近W3Cの勧告になったSOAP 1.2からは、何の略でもない「SOAP」が正式な名称となりました｡

　一般的に「Webサービスのプロトコル＝SOAP」と思われがちですが、WebサービスのプロトコルはSOAPに限定されません。SOAP以外に、既存のメッセージング・プロトコルやIIOPをWebサービスの基盤プロトコルとして採用することで、性能や信頼性を向上させたり、セキュリティやトランザクションをサポートすることも可能です。しかし、マルチベンダ環境での相互運用性を実現するためには、現時点ではSOAPを使用する必要があります。

　SOAP仕様では、HTTPやSMTPなどのトランスポート・プロトコル上で運ばれるメッセージの形式を定めています。ただし、SOAPのトランスポート・プロトコルは、これらに限定されるわけではありません｡

　SOAPメッセージはエンベロープ（封筒）と呼ばれるXML文書で、これはヘッダ部とボディ部から構成されています。ボディ部はアプリケーションがやりとりするメッセージの本体で、封筒の中身に相当します。ボディ部にどのような情報を格納するかによって、SOAPをRPC（リモート手続き呼び出し）のメカニズムとして利用することも、単にXML文書を転送するために利用することもできます。

　郵便の場合、必要に応じて「親展」、「速達」、「重要」といった付加情報を封筒に追加することができますが、SOAPエンベロープでは、ヘッダ部にこうした付加情報が格納されます。後述するWS-SecurityやWS-Transactionでは、この仕組みを利用してセキュリティやトランザクションの情報を伝搬しています。

　現在広く実装されているSOAP 1.1は、IBMやマイクロソフトがW3Cに提出した仕様（W3C Note）です。この仕様をベースに、W3Cでは2003年6月にSOAP 1.2（Part 0、Part 1、Part 2）を勧告として発表しています。

─ SOAPの解説記事
連載 Webサービスのキホン（1） 「Webサービスの主役、SOAP誕生の背景」

■インターフェイスを記述する「WSDL」

　Webサービスに限らず何らかのサービスを利用するためには、利用者は、そのサービスが、どのようなインターフェイスで、どのようなプロトコルで、どこで提供されているのかを知っている必要があります。Webサービスの場合、これらの情報を記述するための言語がWSDL（Web Services Description Language）です。

　WSDLの大きな特徴は、サービスの論理的なインターフェイスと、物理的なプロトコルやメッセージ形式を明確に区別して記述できる点です。このためWSDLには、SOAPに限らずさまざまなプロトコルやメッセージ形式を記述するための拡張メカニズムが提供されています。

　現在広く実装されているWSDL 1.1は、IBMやマイクロソフトがW3Cに提出した仕様（W3C Note）です。この仕様をベースに、W3CではWSDL 1.2（Core Language、Message Patterns、Bindings）の仕様策定を進めています｡本稿執筆時点では、WSDL 1.2のステータスはW3Cドラフトです。

─ WSDLの解説記事
連載 Webサービスのキホン（4） 「WSDL：Webサービスのインターフェイス情報」

■Webサービスの検索エンジン「UDDI」

　特定のWebサービスを固定的に使用する場合には、サービス提供者からWSDLを入手することで事が足ります｡現時点では、こうした閉じた範囲でのWebサービス利用が中心ですが、インターネット上で最適なサービスを自由に選択して利用する次の段階に移行するためには、サービス検索が鍵を握ることになります。

　 Webサービスにおけるサービス検索の代表的な仕様がUDDI（Universal Description, Discovery and Integration）です。UDDIを利用することで、利用者はIBMやマイクロソフトなどが運営するUDDIレジストリから、企業名やサービス内容に基づいてサービスを検索し、アクセスに必要なWSDLを効率的に取得できます。その結果、例えば多くの部品メーカーの中から最も納期の早い業者を選択するといったことが可能になります。

　現在ほとんどのUDDIレジストリで実装されているのは、UDDI 1.0と2.0です。これらの仕様はUDDIプロジェクトによりリリースされたもので、その後OASISに移管されています。OASISでは、やはりUDDIプロジェクトにより開発されたUDDI 3.0を、2002年7月にOASIS委員会仕様として公開しています。

─ UDDIの解説記事
連載 Webサービスのキホン（最終回）　「Webサービスを発見する仕組み〜UDDI」

■Webサービスのセキュリティ関連仕様

　個人情報のような機密データをネットワーク上で交換したり、課金を伴うサービスを公開するような場合には、セキュリティの確保が不可欠になります。Webサービスのセキュリティ標準は、W3CやOASISの多くの仕様から構成されており、それらの関係は非常に複雑になっています。こうした仕様の関係を図解すると次のようになります。今回は、これらの主な役割と関係に焦点を当てて説明することにします。それぞれの詳細については、次回以降で解説していきます。

図2　Webサービスのセキュリティを構成する関連仕様 セキュリティの基盤となる部分にはPKIを用い、XML正規化やXML暗号化などによってXML文書を暗号化する。その上にさらに高度なアクセス制御やアサーション、鍵管理などのための仕様が構築される

通信経路の暗号化「SOAP over HTTPS」

　Webサービスのセキュリティは、「トランスポート・レベルのセキュリティ」と「メッセージ・レベルのセキュリティ」に大別されます。

　トランスポート・レベルのセキュリティは、SSL/TLSに代表されるセキュアなプロトコルをSOAPの下位プロトコルとして使用する方法で、HTTPSとSOAPの組み合わせですでに実用化されています。この方法で、メッセージ全体の暗号化と改ざん防止や、クライアント／サーバ認証などの基本的なセキュリティを確保することができます。

メッセージ・レベルのセキュリティ

　しかし、トランスポート・レベルのセキュリティでは不十分なケースもあります。例えば、機密文書を部分的に暗号化して、担当者によってアクセスできる範囲を制限したいケースです。あるいは、1つの稟議書に担当者が順番に署名をしていくようなケースも考えられます。こうしたケースに対応するためには、XML暗号、XML署名、WS-Security、SAMLなどのメッセージ・レベルでのセキュリティが必要になります。以下では、メッセージ・レベルのセキュリティを実現する仕様を紹介しましょう。

XML文書を暗号化「XML暗号とXML署名」

　XML暗号を利用することで、文書の部分的な暗号化に対応することができます。XML暗号では、XMLに限らずさまざまな情報を暗号化し、その結果をXML文書に組み込むことができます。また、XML署名を利用することで、文書の一部分に署名を施したり、ある担当者が署名した文書にさらに別の担当者が署名するといった複雑なケースにも対応することができます。XML暗号と同じように、XML署名では、XMLに限らずさまざまな情報に署名を行い、その結果をXML文書に組み込むことができます。

　XML暗号とXML署名は、いずれもW3C勧告として標準化されています。

暗号化情報をWebサービスに組み込む「WS-Security」

　SOAPメッセージとなるXML文書に暗号化や署名を施す場合、XML暗号とXML署名を使用することになりますが、それだけでは不十分です。暗号化または署名されたXML要素を、どのようにSOAPメッセージのヘッダあるいはボディに格納するのかをきちんと決めておく必要があるのです。OASISで標準化が進められているWS-Securityでは、こうした点が規定されています。

　WS-Securityはそれだけでなく、クライアントの認証と認可のために使用するセキュリティ・トークンをSOAPメッセージに組み込む方法も規定しています。セキュリティ・トークンとは、クライアントの身元をサーバに申告するための証明書です。ユーザー名とパスワード、X.509証明書、次に説明するSAMLアサーション、あるいはXrML（eXtensible rights Markup Language）などのさまざまな形式をセキュリティ・トークンとして使用することができます｡

クライアントの認証情報などを格納する「SAML」

　OASISで標準化が進められているSAML（Security Assertion Markup Language）は、クライアントの認証情報、属性情報、あるいは認可情報を格納する「アサーション」と呼ばれるXMLベースの証明書に関する仕様です。アサーションのメッセージ形式、アサーション発行元（SAMLオーソリティ）の役割、そしてクライアントとSAMLオーソリティ間のメッセージ規則であるSAMLプロトコルを定めています｡SAMLアサーションは、SOAPに限らずHTTPやIIOPなどのさまざまなプロトコルで運ぶことができます。

　SAMLは、アサーションやそれを交換するためのプロトコルを標準化することで、シングル・サインオン（SSO）のための基盤を提供しています。しかし、SAML仕様では具体的な認証方法までは規定していないため、SSOを実現するためには、さらに上位のフレームワークが必要になります。Liberty Allianceは、SAMLをベースにしたSSOのためのフレームワーク仕様の代表例です。

アクセス制御のポリシー「XACML」

　XACML（eXtensible Access Control Markup Language）は、アクセス制御（認可）ポリシーを記述するためのXMLベースの言語とメッセージ形式のための仕様です。アクセス制御ポリシーとは、だれがどのリソースに、どのような操作を行うことができるかを定めたものです。XACMLは、SAMLの認可オーソリティの部分をカバーしますが、XACML仕様はSAMLには依存しておらず、CORBAやEJBなどの幅広いアプリケーションから利用することができます。

　SAMLとXACMLはOASISで標準化が進められており、いずれもそのバージョン1.0がOASIS標準仕様になっています。

XMLでPKIの鍵管理「XKMS」

　これまで説明してきたXML暗号、XML署名、WS-Security、SAMLは多くの部分でPKI（公開鍵基盤）に依存しています｡従来、PKIを利用するためには複雑なデータ構造やAPIを駆使する必要がありましたが、こうした処理をWebサービスに隠ぺいして利用可能にしようというのが、XKMSの目的です。

　XKMS（XML Key Management Specification）は、鍵の登録、鍵情報の解決や有効性検証などのサービスのインターフェイスとプロトコルを定めています｡XKMS 2.0は、W3Cによって仕様化が進められており、執筆時点のステータスはW3Cドラフトです。

■複数のWebサービスを連携させるコレオグラフィ記述言語

　Webサービスのインターフェイスやエンドポイントを記述するための言語は、もちろんWSDLです。しかし、複数のオペレーションが決められた順番で呼び出されなければならない複雑なWebサービスや、複数のサブ・サービスから構成されるWebサービスを構築するためにはWSDLだけでは不十分です。WSDLでは、オペレーション呼び出しの順序やほかのWebサービスとの関連は記述できないからです。

　そこで必要になるのが、コレオグラフィ記述言語です。コレオグラフィ（choreography）とは、「舞踏法」あるいは「ダンス表記法」という意味で、Webサービスのメッセージ交換の約束をダンスに例えてこのように呼んでいます｡用途に応じて、「ビジネス・プロセス・フロー」あるいは「サービス・オーケストレーション」と呼ぶこともあります。

図3　実際のビジネスでは複数のWebサービスを連携させることになる 例に挙げた旅行予約Webサービスでは、顧客管理から決済、発券までを4つのWebサービスが連携して処理するが、顧客からはそれ全体が1つのWebサービスとして利用できる

2つのコレオグラフィ「WSCIとBPEL4WS」

　これまでIBMのWSFL（Web Services Flow Language）やマイクロソフトのXLANGのような、ベンダ固有のコレオグラフィ仕様が実装されてきましたが、2002年8月に、標準化を目指した2つの仕様がほぼ同時期に提案されました。1つ目が、インタリオ、サン・マイクロシステムズ、SAP、BEAシステムズの4社によってW3Cに提案されたWSCI（Web Service Choreography Interface）です。そしてもう1つが、IBM、マイクロソフト、BEAシステムズによって発表され、その後OASISに提案されたBPEL4WS（Business Process Execution Language for Web Services）です。

　WSCIとBPEL4WSは、シンタックスやアプローチは異なりますが、ほぼ同等の機能をサポートしています。いずれの仕様でも、WSDLとの統合、例外ハンドリング、イベント・ハンドリング、トランザクション記述、制御構造、構造化スコープ、オペレーション呼び出しのコリレーションなどの機能がサポートされています。

■Webサービス連携に不可欠なトランザクション処理

　複数のサーバにまたがる処理において、サーバ間のデータの整合性を保持するためには、トランザクション処理が必要になります｡例えば、航空券の発券とクレジットカードの決済において、一方の処理だけが失敗するという状態は許されません｡このため、2つの処理を「トランザクション」と呼ばれる1つの単位で実行し、いずれかの処理が失敗した場合、トランザクション全体をキャンセルすることで、データの整合性を保持するようにします。

図4　複数のWebサービスを1つのトランザクションとする Webサービスによる複数の処理を連携させるとき、「どちらか一方だけが失敗する」 ことが許されない処理が発生する。例えば、「決済処理は成功したが発券処理に失敗して航空券が発行されなかった」といったことは許されない。そうした複数の処理を「1つのトランザクション」として実行する

　このようなトランザクション処理には、2つのアプローチがあります。1つ目のアプローチは、密結合システムで通常採用されるACIDトランザクションです。2つ目のアプローチは、主に疎結合システムで採用されるロング・ラニング・トランザクションです。これらの違いについては、この後の連載で詳しく説明していきます。

　Webサービスでも、適用分野が密結合か疎結合かによって、この2つのトランザクションを使い分ける必要がありますが、特にWebサービスは疎結合システムに適用されるケースが多いので、ロング・ラニング・トランザクションが重要になります。

　Webサービスのトランザクション仕様は、セキュリティ仕様以上にあわただしい動きが見られる分野です。今回は、現時点で公開されている情報に基づいてBTPとWS-Transaction、そして先日公開されたばかりのWS-CAFの要点を説明します。

疎結合トランザクションの実現「BTP」

　BTP（Business Transaction Processing）は、OASISで標準化が進められているWebサービスのトランザクション仕様です。この仕様は、疎結合システムへの適用を前提に、ロング・ラニング・トランザクションのための調整プロトコルを定義しています。2002年5月にOASISの委員会仕様になっています。

密結合と疎結合トランザクションの実現「WS-Transaction」

　WS-Transactionは、2002年8月にマイクロソフト、IBM、およびBEAシステムズの3社によって公開されたWebサービスのためのトランザクション仕様です。現時点で公開されている仕様は最初に公開された初期仕様のみで、プロトコルの詳細までは規定されていません。また、標準化団体への提案もまだなされていません。

　WS-Transactionでは、密結合用のACIDトランザクションと疎結合のためのロング・ラニング・トランザクションの両者をサポートしています。これらは、それぞれ「アトミック・トランザクション」と「ビジネス・アクティビティ」と呼ばれています｡いずれのケースでも、分散トランザクションの調整のために、WS-Transactionと同時に公開されたWS-Coordination仕様を使用しています｡

トランザクション仕様の統合を目指す「WS-CAF」

　Arjuna Technologies、富士通ソフトウェア、IONAテクノロジーズ、オラクル、およびサン・マイクロシステムズによって先ごろ（2003年7月28日）発表されたWS-CAF（Web Services Composite Applications Framework）は、トランザクションを含む複合Webサービスのための仕様群です。

　WS-CAFは、WS-CTX（Web Services Context）、WS-CF(Web Services Coordination Framework）、WS-TXM（Web Services Transaction Management）の3つの仕様から構成されています。これらの仕様は近日中に標準化団体に提案されることになっています。

　BTPやWS-TransactionにないWS-CAFの大きな特徴は、複数のWebサービスから構成されるアプリケーション群が同一のコンテキスト情報を共有するためのメカニズムを提供している点と、BTPやWS-Transactionといった既存のトランザクション・プロトコルをプラグインとして取り込むことで相互運用性を実現しようとしている点です。特に、後者は、乱立したトランザクション仕様を統合する上で重要な役割を果たすことになります。

■メッセージ配信の信頼性を高める

　SOAPの下位トランスポートとしてHTTPを使用する場合、メッセージ配送の信頼性は必ずしも高いとはいえません。このため、SOAPの枠組み自体を変えずに、信頼性を向上させるための取り組みがいくつかなされています｡

　その1つは、SOAPの下でJMSやHTTPR（Reliable HTTP）などの信頼性のあるトランスポートを使用する方法です。これはすでに製品として実用化されている方法です。

SOAPによる送達確認「WS-Reliability」

　もう1つの方法は、SOAPのヘッダ部を利用して、送達確認や再送を制御する方法です。これにより、下位トランスポートに依存せずに、SOAPの上位レベルでメッセージの信頼性を確保することができます。このアプローチをとっているのが、2003年1月にSonic Software、富士通、日立製作所、NEC、オラクル、サンによって公開され、その後OASISに提案されたWS-Reliabilityです。

■セマンティックWebでソフトウェアによる自動処理

　Webサービスが目指すのは、ソフトウェアがインターネット上でサービスを動的に探し出して、処理を自動的に遂行する「ダイナミック・ディスカバリ」や「ダイナミック・インボケーション」です。これを実現するためには、HTMLやWSDL、UDDIに、ソフトウェアが人間の介在なしに理解できるセマンティックス（意味）を付加していく必要があります。このように、既存のWebやWebサービスにセマンティックスを追加して、ソフトウェアによる自動処理を実現しようという研究領域がセマンティックWebです。

セマンティックスを記述する「RDFとOWL」

　W3Cでは、こうしたセマンティックスを定義するためのメタデータ記述言語としてRDF（Resource Description Framework）の仕様化を行っています｡さらに、RDFをベースにして、意味付けのためのボキャブラリを定義するための言語としてOWL（Web Ontology Language）の仕様化も行っています｡これらのフレームワーク上に業界や分野ごとのボキャブラリを定義しようという動きも、さまざまな団体によって開始されています。

◆

　今回は、Webサービスによって高度なサービスを提供するために必要とされるさまざまなテクノロジについて概要を解説してきました。次回からは、ここで紹介したテクノロジの中でも、セキュリティ、コレオグラフィ、トランザクションなどの、よりビジネスにとって重要で高度な仕様を中心に、さらに深い解説を行っていきます。（次回へ続く）

■バックナンバー

　1 .複雑化するWebサービスの仕様群を整理する
　2. Webサービスのキュリティ技術を詳解する
　3. OASIS WS-SecurityとXKMSの構造を知る
　4. OASIS SAMLとXACMLの構造を知る
　5. Webサービスを連携させるコレオグラフィ
　6. 混迷するWebサービス・トランザクション制御
　7. BtoB基盤となるWebサービス・トランザクション（最終回）

ビジネスWebサービス最新事情

＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）