XML Web サービスの概要

インフォテリアネットワークス株式会社
吉松 史彰

1. XML Web サービスの概要

1.1. XML Web サービスとは何か？

XML Web サービスとは、XML、HTTP、SOAP などのインターネット標準技術を利用して、異なるプラットフォーム上のアプリケーションとも統合することが可能なソフトウェアの総称です。XML Web サービスはクライアント・プログラムに情報を返す、URL でアクセス可能なリソースであるとも言えます。

1.1.1. 従来の Web アプリケーションとの違い

現在の Web には、ニュース、株価情報、星占いなど、Web サイトにある情報を統合して提供する、いわゆる 「ポータル」 サイトがたくさんあります。ポータルサイトは、ユーザーが個別の Web サイトにアクセスしなくても、1 つのサイトで情報をまとめて受け取ることができるという、Web 上で提供されているサービスととらえることができます。

図 1. MSN のようなポータルサイトにおける処理の流れ

しかし、株価情報や星占いなどの機能を提供する Web サイトは、Web ブラウザを介して人間の目で見るためのデータを生成しています。つまり HTML データです。HTML は見やすいように配置することはできますが、その中の情報の一部だけをプログラム的に取り出すことは非常に困難です。もしポータルサイトのデザイナーが直接作業を行うなら、毎日各サイトを見て回って情報を自ら収集する、あるいは特定のサイトから定期的にデータをもらうなりして、新たな Web サイトとしてまとめる作業を行うことになります (図 1)。もう少しプログラム的に行うなら、ポータルサイトの開発者とコンテンツ提供者の間で独自のプロトコルを用意し、専用のソフトウェアで再構成するという方法が実際に採用されていますが、異なるコンテンツ提供者ごとに別々のプロトコルが必要になり、しかもそれらのコンテンツをシームレスに統合するためのツール開発コストやシステムの維持管理コストなどの負担が指数関数的に大きくなる恐れがあります。

ポータルサイトの後ろにある、株価や星占いの Web サイトが、人間の目ではなく、プログラムから「見える」ような汎用的なインターフェイスとデータフォーマットを用意してくれれば、保守担当者の作業はプログラムによって自動化できますし、複数プラットフォーム対応を始めとした開発コスト上の負担も減らすことができます。それが XML Web サービスの役割です。Web 上の各種サイトが XML Web サービスとして公開され、ポータルサイトからはそれらが提供する XML データを解釈して自分のサイトで再構成するプログラムが動いていれば処理が自動化されます。さらに、ポータルサイト自身が XML Web サービスとしてまとめた内容を配信すれば、それを受け取ってさらに加工するプログラムを作ることも可能です。つまり、Web を介したアプリケーションの統合が実現できます( 図 2)。

図 2. XML Web サービスにおける処理の流れ

ポータルサイトと XML Web サービスとの違いは、人間の目で解釈される情報を返す (HTML) か、プログラムが解釈できる情報を返す (XML) かの違いであるということができます。

1.1.2. XML との関係

XML Web サービスが送出するデータは、プログラムが解釈できさえすれば良いのですが、プログラムといっても、インターネット上にはさまざまなプラットフォームでさまざまなプログラミング言語で書かれたさまざまな形態のプログラムが動作しています。ある特定のプラットフォームや、特定のプログラミング言語でしか解釈できないデータを送出してしまうと、いくらプログラムで解釈できるデータとはいっても、利用できる範囲が限定されてしまいます。

そこで、インターネット標準のメタデータフォーマットである XML を利用するのが、XML Web サービスです。

XML は、単なるテキストデータである上に、多数のソフトウェア・ベンダーが様々なプラットフォームやプログラミング言語及び開発ツールで広くサポートしているので、異なるプラットフォームやアプリケーション間でデータ交換を可能とします。

1.2. XML Web サービスのアーキテクチャ

1.2.1. 従来型システムのアーキテクチャ

従来の Web アプリケーション開発では、Windows DNA に代表される、いわゆる「n階層アプリケーション」が開発の基盤となっていました (図 3)。

図 3. Windows DNA アーキテクチャ

Web ブラウザと HTML をプレゼンテーションに、ファイアウォールの内側には、ビジネスロジックを COM コンポーネントとして開発・配置し、それがバックエンドのさまざまなデータにアクセスするというスタイルです。

Windows DNA によって、個々の Web サイトを効率よく、保守性をあげて開発することが可能になりましたが、そこには限界も出てきました。

特に問題になるのは、層と層との連携に、特定の技術を強制するため、その技術に基づいた開発ができない環境ではうまく作ることが難しいことです。コンポーネント技術は、COM、CORBA、JAVA などさまざまありますが、どれもコンポーネントどうしの接続にバイナリプロトコルが必要などして相互運用性に乏しいため、プレゼンテーション層とビジネスロジック層、ビジネスロジック層とデータ層とを結ぶ技術が固定されてしまいます。そもそも、アーキテクチャの統一によって、性能の向上、開発生産性の向上などが実現されてきたので、これ自体は悪いことではありません。ですが、このようなシステムの実装が進むにつれて、以下のような問題がクローズアップされてきました。

1. 社内の新しいシステムと、既存のシステム (レガシーシステム) とが接続できない
   既存システムが吐き出したファイルを、新システムに対して人間が手で受け渡しを行わなければならないような場面が見受けられます。
2. 自社システムと他社システムとの媒介が、人間の手による電話、FAX、電子メールになっている
   せっかく社内システムを開発して作業効率を上げても、取引先との連携部分がボトルネックとなって、一向にリードタイムが改善されません。

このようなシステムは、層と層とが密接に結びつけられて動作して、性能は良い分、いったん運用を始めると互いに一部を取り替えたり、別のアーキテクチャでバージョンアップすることが難しいということです。このような仕組みを、一般に密結合システムと呼んでいます。

1.2.2. XML Web サービスのアーキテクチャ

XML Web サービスは、プラットフォームやプログラミング言語から独立した、XML フォーマットのメッセージデータを交換することで、相互運用性を高めています。システム内のビジネスロジック層と、データ層、あるいは自社システムと他社システムが、お互いにどのようなプラットフォームで動作していて、どのようなプログラミング言語で開発されているのかを意識する必要がまったくありません。データ交換のために必要な情報だけが提供されていれば良いのです。そのため、このようなシステムは、疎結合システムと呼ばれています。

XML Web サービスによって、これまでは密接につながっていたシステム同士が、より緩やかに連携できるようになると、「必要なときに最適な相手と」 連携することができるようになります。このため、XML Web サービスには、従来の n 階層とは違う、新たな役割が与えられます。

まず、当然のことながら、XML Web サービスそれ自身は、サービスの提供者 (サービスプロバイダ) という位置付けになります。そして、XML Web サービスを利用する、サービスの消費者 (サービスコンシューマ) が存在します。従来のシステムでは、消費者と提供者がお互いのことを良く知っている (密結合) ので、この 2 者だけでシステムが動作していることも多かったのですが、XML Web サービスは疎結合が前提のため、両者を仲介する、サービスの仲介者 (サービスブローカ) が必要になります。この 3 社の共同作業をまとめると図 4 のようになります。

図 4. XML Web サービスのアーキテクチャ

図 4 のように、XML Web サービスは、サービスが公開され、サービスが発見され、サービスが利用されるという 3 段階の流れで動作します。この仕組みによって、「必要なときに最適な相手と」 接続することを可能にするのです。

2. XML Web サービスの技術概要

2.1. SOAP (Simple Object Access Protocol)

SOAP は、XML Web サービスのやり取りを円滑に行うために取り決められた、業界標準プロトコルです。郵便局で、遠くの親戚に封書を送るときを想像してみてください。封筒には、郵便番号、あて先住所、あて先の氏名、送信元の住所・氏名を書いて、中に手紙の本文を入れて、封をしてポストに投函します。すると、郵便局のスタッフが、封筒を見てあて先へ向けてそれを配送し、最終的なあて先まで配達してくれます。このとき、郵便局のスタッフは、手紙の本文は読む必要がありませんので読みませんし、読んではいけません。郵便局のスタッフが配達する (または不達で送信元に戻す) ときに必要な情報は封筒にすべて書いてあるので、本文が読めなくても、配達に何ら支障はありません。

SOAP は封筒の役割を果たすプロトコルです。実際に相手の XML Web サービスに送信したい本文を SOAP の Body の中に入れて、全体を SOAP の Envelope で包むことで、SOAP対応のサーバーの間で送受信できるようにします。SOAPサーバーは、本文の中身を知る必要はありません。

SOAP は、もともとは DevelopMentor、Microsoft、IBM、Userland Software、Lotus の各社が最初のたたき台を整備し、World Wide Web Consortium (W3C) に提案した仕様です。現在は、W3C の XML Protocol WorkingGroup によって標準化作業が進められています。現時点での最新の仕様は、http://www.w3.org/2000/xp/ で読むことができます。（SOAP 1.1 仕様に関しては https://www.microsoft.com/japan/developer/workshop/xml/general/soapspec.asp に翻訳があります。）

2.2. WSDL (Web Service Description Language)

WSDL は、XML Web サービスの呼び出し規約を XMLフォーマットで記述するために定義された、XML ベースの言語です。従来の密結合システムでは、サービスの消費者とサービスの提供者が、お互いについて詳しく知っていたため、お互いの機能に関する説明は、プログラマの間で共有され、プログラムの中に埋め込まれていました。しかし、「必要なときに最適な相手と」 通信する XML Web サービスでは、通信したい相手が実際にどのような機能を持っていて、どのアクセスポイントにどんなメッセージを送るとどんなメッセージが返ってくるのか、そのために利用されるプロトコルは何なのかといった、相手に関する情報を、サービスの提供者からダイナミックに入手する必要があります。

人間同士の手紙のやり取りならば、中身が何を意図しているのかは文章を読めば大体わかりますが、プログラム同士のやり取りでは、どんなメッセージなら受け付けることができて、そのときはどんな返事を返すのかを、あらかじめ定義しておかないと、通信がしづらくなります。そのため、WSDL でその部分を書いておいて、サービスの消費者とサービスの提供者が WSDL で書かれた仕様に合意する必要があるのです。

WSDLは、もともとは Microsoft、IBM がたたき台を整備し、World Wide Web Consortium (W3C) に提案した仕様です。現在は、SOAP と同じく W3C の XML Protocol WorkingGroup によって標準化作業が進められています。現時点での最新の仕様は、http://www.w3.org/TR/wsdl.html で読むことができます。(WSDL 1.1 仕様に関しては https://www.microsoft.com/japan/developer/workshop/xml/general/wsdl.asp に翻訳があります）

2.3. UDDI (Universal Description, Discovery and Integration)

UDDI は、XML Web サービスを発見するためのレジストリと、レジストリへのアクセス方法を定義した仕様です。「XML Web サービスのアーキテクチャ」 で解説したとおり、XML Web サービスでは、サービスの検索ができるようにするための、サービスの仲介者が存在します。サービスの消費者は、「必要なときに」 サービスの仲介者にアクセスして「最適な」サービスの提供者を探し出します。また、将来探し出してもらえるように、サービスの提供者は、自分自身の情報をサービスの仲介者に登録します。このような、XML Web サービスのディレクトリの役割を果たすのが、UDDI レジストリの機能です。

また、XML Web サービスという観点では、UDDI レジストリも 1 種の XML Web サービスであると考えられます。UDDI レジストリは SOAP に対応したクライアントから、登録や削除、実行時の検索などを、SOAP メッセージを投げこんで結果を SOAP メッセージで返信してもらうことで対応ができるようになっています。UDDI レジストリは、電話帳などと同じような構成でサービスの登録情報を持っています。この機構に対して利用者は必要な検索を行い、利用したいサービスを探し当てることができるようになっています。

UDDI は、もともとは Microsoft、IBM、Ariba がはじめたイニシアチブです。2001 年 5 月時点において 260 以上の企業が UDDI コミュニティに名を連ねています。このイニシアチブで、UDDI のレジストリの仕様、レジストリ同士のレプリケーションの仕様、そしてレジストリへアクセスするための API 仕様などを整備しています。詳細な仕様や、イニシアチブのメンバー企業については、http://uddi.xml.org/ で確認することができます。現時点での最新仕様とその日本語版も、このホームページからダウンロードすることができるようになっています。

3. UDDI とレジストラ

図 4 のようなアーキテクチャと、前述した 3 つの XML ベースの技術によって、XML Web サービスの統合と実務での利用が可能になるようなイメージが湧きますが、実際には、現実のビジネスにおけるさまざまな問題が、XML Web サービスの運用にも立ちはだかります。

サービスの消費者の立場では、例えば以下のような問題があります。

1. これまで取引のなかったベンダーとの信用取引をおこなう手順
2. XML Web サービスのキャパシティなどの技術的問題

UDDI は、たとえば登録した企業番号 (D-U-N-S番号) が正しいかどうかの確認などは行えますが、UDDI に登録したベンダーの財務状況、他の取引先、資本金、株価などの信用取引にかかわる情報を、直接提供してくれるわけではありません。説明として書いてあったとしても、それをどこまで信用してよいものかどうか判断がつきません。

また、XML Web サービスとして公開されてはいるものの、頻繁にサービスの提供を休止したり、サービスの更新頻度が低いといったような運用状況に関する情報などは、やはり UDDI にアクセスしただけでは手に入りません。

3.1. レジストラの役割

そこで、UDDI レジストリへの登録や検索を代行してくれるレジストラサービスの役割が生まれます。レジストラが、XML Web サービスの登録や検索を一手に引き受けることで、以下のようなメリットが出てきます。

1. UDDI に登録された情報の正確性の維持
   レジストラが、ベンダーからの登録依頼を受けて UDDI に登録する過程で、何らかの審査を行ったり、入力情報の正確性を検証することで、そのレジストラを介して登録された情報の信憑性が高まります。
2. UDDI ではサポートされていない分類法(Taxonomy)を使った検索
   現在の UDDI 仕様では、企業コードとしてのD-U-N-S番号、商品/サービス分類としての NAICS コードや UNSPSC コードなどグローバルに運用されているコード体系に基づき、検索できるようになっていますが、日本ローカルで使われる、帝国データバンク企業コードや JICFS コード、JAN コードなどで検索することはできません。そこで、レジストラが UDDI で企業をあらわすキーと、それらのコードの結びつきを管理することで、独自の Taxonomy を使った検索が可能になります（注：UDDI 仕様 v2 では、独自 Taxonomy の有効性確認を、UDDI レジストリから外部のレジストラサイトなどへ委譲する仕組みを提供しますが、このコラムを書いている時点では UDDI レジストリ側でまだ実装されていません）。
3. UDDI への登録手順の簡略化
   多くの企業では、UDDI に登録した情報を常に最新の情報に保つのは、大変です。レジストラが簡単なユーザーインターフェイスを Web で提供したり、電子メールや FAX でも受け付けていれば、UDDI への登録が大幅に簡略化され、ビジネス機会が増えることにもつながります。

3.2. 誰がレジストラになるべきか？

レジストラは、サービスの提供者からもサービスの消費者からも信頼されるサイトでなければなりません。そこでまず考えられるのは、政府、官庁、あるいは公共団体です。また、実績ある業界団体も候補となりえます。また、営利サービスを提供している、ビジネスリポジトリを扱う企業もその役割を果たすことができるでしょう。

また銀行や金融関連企業がレジストラと連携する、あるいは自らがレジストラになって、会員同士の信用取引にあたって、売掛債権の買取や支払保証を行うサービスなどを提供すれば、XML Web サービスの問題点の 1 つである、信用取引の難しさを解決できます。あるいは、e マーケットプレースがレジストラになって、会員企業の情報を UDDI レジストリにも登録すれば、e マーケットプレース自身にも、会員企業の増加の可能性というビジネスメリットがあり、会員企業にとっても、e マーケットプレースで扱っているカタログ情報からの検索が可能になったり、e マーケットプレースの信用機能を利用するといったメリットが考えられます。

3.3. レジストラ構築の必要条件

上記のとおり、レジストラになって成功するためには、まず登録してくれるユーザーからの信頼が欠かせません。これは技術で解決できる問題ではありませんので、すでに実績がある団体や企業のほうがレジストラとして活動しやすいでしょう。

技術的には、レジストラとして UDDI レジストリに会員企業の情報を代理で登録するためには、UDDI オペレータからその承認を受ける必要があります。現時点で、UDDI オペレータとして実際に活動しているのは、Microsoft (http://uddi.microsoft.com/) と、IBM (http://www-3.ibm.com/services/uddi/) です。Microsoft のサイトを例に取ると、Microsoft では、Passport 認証を利用してデータの登録を管理しています。1 Passport アカウントにつき、1 企業しか登録できないように制限を設けています。そのため、レジストラとして多くの他社の情報を登録するには、自社がレジストラサービスを提供していることを宣言して、この制限を解除してもらう必要があります。これはオペレータに直接依頼するしかありません。

4. まとめ

XML Web サービスは、これまでのシステム開発の手法を維持しつつ、より「適材適所」 なシステム作りを支援する新しいアプリケーション統合アーキテクチャです。SOAP、WSDL、UDDI などの XML ベースの技術を利用して、プラットフォームやプログラミング言語を超えて、最適なシステム同士を連携させて新しいシステムを作ることを可能にします。

XML Web サービスのアーキテクチャの中で、UDDI レジストリの存在は特に重要です。これによって、XML Web サービスの消費者が、必要なときに最適な相手を探し出して、システム連携を実現することができます。

UDDI レジストリは、一般的な企業情報や分類コードを利用できるように作られていますが、たとえば日本特有の企業コード、製品コードなどから検索することはできません。また、UDDI レジストリに登録されているからといって、その企業がビジネスのパートナーとしてふさわしいかどうかはわかりません。

そこで、独自の Taxonomy による検索や、信用情報の提供を行うことで、UDDI レジストリに付加価値を提供するのがレジストラサービスです。レジストラは UDDI レジストリへの登録を代行し、代替コードでの検索を可能にしたり、信用情報を提供するようなサービスを付加することができます。その性質上、実績のある業界団体や、銀行、e マーケットプレースなどが、最初にレジストラとして活動できるだけの信頼を持っているということができます。