.NET Framework入門 １．Microsoft.NETプラットフォームとWeb Service デジタルアドバンテージ 遠藤孝信 2000/12/14

---

本記事は改訂されました。改訂版の「.NETとは何か？ ― 基礎解説：.NET初心者のための.NET入門【2011年版】」をご覧ください。

　Microsoft.NETビジョンの中心となるコンセプトは、インターネット上に存在するさまざまな情報サービスが互いに会話できるインターフェイスを用意し、このインターフェイスを通して各サービスが協調できるようにするということである。言い換えれば、Web情報サービスを1つのソフトウェア・コンポーネントとして機能できるようにするということだ。このように、インターネット上に存在し、互いに会話可能な標準インターフェイス（SOAP／XML）を備えるWeb情報サービスは、「Web Service」と呼ばれる。文献によっては、これを「Webサービス」と訳しているところもあるようだが、これだと広く一般の「サービス」を連想しやすく、誤解を招くので、本稿では「Web Service」と表記することにする（これに対し、一般的なサービスを指すときには「情報サービス」などと表記し分ける）。

　周知のとおり、現時点でも、Webのしくみを使った情報サービスは多数あるし、日々増加の一途をたどっている。しかしこれらの情報サービスは、ソフトウェアが機械的に利用可能な「Web Service」ではなく、人間がWebブラウザを通じて表示し、操作する「Webアプリケーション」である。例えば、ビジネスマンにとって便利なWeb情報サービスの1つとして、電車の経路探索サイトがある。このような経路探索サイトでは、Webブラウザから出発駅と目的駅を指定して検索を実行すれば、選択可能な経路と、経路ごとの平均所要時間、運賃などを調べることができる。

経路探索サイト

出発駅と目的駅をWebブラウザで入力し、検索を実行すれば、経路探索を行ってくれて、目的駅までの距離や平均所用時間、運賃などを表示してくれるサービス（画面はジョルダンが提供している「駅名入力検索」での検索例。ジョルダンのホームページ）。文句なく便利なツールではあるが……。

　文句なく便利なツールである。しかし何軒も客先を回らなければならないとき、どのような順序で訪問すると効率的なのか、などといった処理は、Webブラウザに表示されたさまざまな経路情報を元に、人間が順列組み合わせを検討しなければならない。仮にそうした処理を行うロジック（客先を効率よく訪れるための順序などを決定するためのロジック）が手元にあったとして、それと電車の経路探索サービスを組み合わせることができれば、最新の時刻表と運賃をも考慮した営業支援システムができるかもしれない。あるいは出張旅費申請システムと経路探索サービスを組み合わせれば、運賃の精算を自動化できるかもしれない。

　しかしこれを可能にするには、電車の経路探索サイトが、プログラムから直接アクセス可能なインターフェイスを備えている必要がある。このようなインターフェイスを備えたWeb上の情報サービスが「Web Service」である。

　見方を変えれば、Web Serviceは、インターネット上に存在するコンポーネントとしてとらえることができる。例えば先の出張旅費申請システムなら、最新情報に基づいた運賃計算などを行うために、ソフトウェア部品としてインターネット上の「電車の経路探索コンポーネント」を呼び出すわけだ。また複数のWeb Service同士は、それぞれが会話するためのインターフェイスを備えているので、必要に応じて、他のWeb Serviceを呼び出すことができる。このためWeb Serviceを利用したシステム開発が一般化すれば、1つのWeb Serviceを、さまざまなシステムの一部として活用できるようになる。

Web Serviceのインターフェイス

　このようなコンポーネントとしてのWeb Serviceを作成する際に重要となるのはインターフェイスである。前述したような発想は、従来から「分散オブジェクト」などとして議論されてきたし、一部では実装も行われている。しかしそれらがなかなか一般に普及しないのは、コンポーネントの通信インターフェイスとして、CORBA（Common Object Request Broker Architecture。「コルバ」と読む）やDCOM（Distributed COM）などいくつかの標準があり、仕様の異なるコンポーネント同士は直接には会話できないこと、これまでの分散オブジェクト環境は、どちらかというとLANなどのローカルなネットワークを前提としており、インターネットなどのグローバル・ネットワークで利用するのが容易でなかったことなどが原因している。

　Web情報サービスの利点は、Webサーバからクライアントに送られるデータがHTMLという標準仕様にのっとっており、この仕様に準拠さえしていれば、特定のOSやサーバ／ブラウザ・ソフトウェアに依存することなく、Webページを閲覧できることだ。したがって例えば、前出の経路検索の例でも、Webサーバが返してくるHTMLデータを解析するようなプログラムを作成すれば、情報の2次利用は不可能ではない。しかし求める情報（本文テキストなど）のほかに、表示制御のための構文（フォント指定や文字サイズ指定など）や文書構造のための構文など（見出しや表指定など）が渾然一体となったHTMLデータから、プログラムが必要なデータだけを切り出すのは容易でないし、仮に作ったとしても、そのプログラムはWebページ・デザインに依存することになるので、サイトごとに別々のプログラムが必要である。またWebページの構成が変更されるたびにプログラム変更を余儀なくされる。

　つまりWeb Serviceの会話を効率的に行えるようにするには、ソフトウェアが容易に解釈可能な論理的な状態で、互いが会話するための共通インターフェイスを定義する必要がある。このためのインターフェイスとして、次世代の共通ドキュメント・フォーマットとして広く普及したXML（eXtensible Markup Language）をベースに開発されたのがSOAP（Simple Object Access Protocol）である。具体的に言えば、SOAPは、データ型やコマンド呼び出しの表現を取り決めたプロトコルで、それらを業界標準となったデータ記述言語のXMLにより記述するものである。

　SOAPで通信するソフトウェア同士は、リクエストやレスポンスをXML形式のテキストで記述し、HTTPなどの通信プロトコル（Webページのデータ取得などで広く使われているプロトコル）によってデータ交換を行う。このように、広く普及した通信プロトコルを土台とすることで、ファイア・ウォールによって閉ざされたような環境からでもWeb Serviceの呼び出しが可能になる（下図参照）。

既存のWebサイト／Webブラウザと次世代のWeb Service

現在のWebページは、本来の情報に加え、表示制御のための構文などが渾然一体となったHTML形式で構成されている。これに対し次世代のWeb Serviceでは、ソフトウェアが必要な情報に的確かつ効率よくアクセスできるように、XMLとSOAPによるインターフェイスを備える。

　このXMLもSOAPも、HTMLなどと同じく、誰もが特別な手続きなしで利用可能な標準仕様である。したがってWeb Serviceを実現するために、必ずしもマイクロソフトのプラットフォームは必然ではない。SOAP／XMLという共通のインターフェイスにさえ準拠していれば、マイクロソフト以外のOS上にWeb Serviceを実装し、サービスを提供することができる。マイクロソフトのドキュメントなどを見ていると、こうした標準インターフェイスの話と、マイクロソフト独自のテクノロジの話が一緒くたに語られるため、Web Serviceはマイクロソフト製のプラットフォームに依存したサービスだと勘違いしている向きもあるようだが、この点を混同してはいけない。Microsoft.NETは、Web Serviceの開発と運用を支援するためのプラットフォームであるが、こうして作成されたWeb Serviceを外部から利用するためのインターフェイスは、あくまで標準仕様のSOAP／XMLである。

情報サービスを構成する部品として機能するビルディング・ブロック

　マイクロソフトは、このように情報サービス全体を支える個々のコンポーネントとなるWeb Serviceを指して、「ビルディング・ブロック（building block）」と呼んでいる。このビルディング・ブロックを開発するための開発環境や、ビルディング・ブロックを運用するためのOSプラットフォームを提供することはマイクロソフトの大きな仕事だが、同時にマイクロソフトは、自身でもビルディング・ブロックとなりうるサービスを提供していく予定である。例えば現在、マイクロソフトは、ポータル・サイトのMSNにおいて「Microsoft Passport」と呼ばれるサービスを提供している（MSNのホームページ）。

Microsoft Passportの登録画面

マイクロソフトは、同社が運営するポータル・サイトのMSNにおいて、Microsoft Passportと呼ばれる認証サービスを行っている。ユーザーは、このPassportで自身の電子メール・アドレスとパスワードを登録すると、認証が必要なMSN内のコンテンツにアクセスしたり、Passportに対応した外部サイトにアクセスしたりできるようになる。将来的には、このPassportによる認証サービスが、コア・ビルディング・ブロックとしてWeb Service化される計画だ。

　ECサービス（電子商取引）に代表されるように、Web Serviceでの処理によっては、サービスを提供する相手を特定し、相手に応じた処理を行う必要もあるだろう。現在マイクロソフトは、MSNのサービスの一環として、Microsoft Passportという認証サービスを行っている。このPassportにユーザー登録を行うと、認証が必要なMSNのコンテンツにアクセス可能になるほか、Passportに対応した他のWebサイトをアクセスする際の認証をPassportで行えるようになる。今後マイクロソフトは、このMicrosoft PassportをWeb Serviceに対応させ、ユーザー認証サービスを行うビルディング・ブロックとして機能させる計画である。これによりユーザー認証を必要とするWeb Serviceは、Microsoft Passportをビルディング・ブロックの1つとして利用し、ユーザー登録や認証の処理をこれに任せられるようになる。これはWeb Serviceの設計者にとって大きなメリットであると同時に、ユーザーにとっては、Passportにユーザー登録しておけば、Passportをビルディング・ブロックとして使うさまざまなWeb Serviceを利用する際の認証処理を1個所で集中的に行えるようになるというメリットがある。このMicrosoft Passportでの認証サービスなどを始め、マイクロソフトは、多くのアプリケーションで必要とされるプリミティブなビルディング・ブロックを「コア・ビルディング・ブロック（core building block）」と呼んでいる。認証以外のコア・ビルディング・ブロックとしては、通知・メッセージング、パーソナライゼーション、カレンダー、XMLストアなどが検討されている（詳細については別稿の「特集：Microsoft.NETが目指す次世代情報環境とは？」を参照）。

　Passportの例と同様にして、例えば配送管理機能や在庫管理機能など、多くのビジネス・アプリケーションで必要とされる機能モジュールがビルディング・ブロックとして提供されれば、それらを組み合わせて、必要なカスタマイズを施すだけで、ビジネス・アプリケーションを効率よく構築できるようになるだろう。また1つのWeb Serviceが汎用的に使われるので、コードの再利用性も高まる。つまりWeb Serviceにより、全世界的なネットワークであるインターネットをプラットフォームとしたコンポーネント・プログラミングが可能になるのである。

関連記事（Insider.NET内）
特集	Microsoft.NETが目指す次世代情報環境とは？
関連リンク
ジョルダン	ジョルダンのホームページ
マイクロソフト	MSNのホームページ

　

INDEX
	［特集］.NET Framework入門
	1．Microsoft.NETプラットフォームとWeb Service
	2．.NETプラットフォームと.NET Framework
	3．Common Language Runtime（1） 　　　CLRの内部構造とプログラム実行の流れ
	4．Common Language Runtime（2） 　　　CLRによる複数言語サポート： 　　　 VS.NETで標準サポートされる言語処理系
	5．Common Language Runtime（3） 　　　CLRによる複数言語サポート： 　　　サードパーティによってサポートが予定されている言語処理系
	6．ASP.NET（1） 　　　 ASP.NETで何が変わるのか？　まずは既存のASPと比較してみよう
	7．ASP.NET（2） 　　　 VBライクなWebアプリケーション開発を可能にするASP.NETのサーバ・コントロール群
	8．ASP.NET（3） 　　　 Web Service開発始めの一歩。サービス公開に必要なのはキーワード指定1つ

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