1990年代後半，WWW(以下Webと記す)をけん引役に，インターネットが世界中に爆発的に広がり，現在国内ではブロードバンドが家庭にまで到達し，ビジネス上の業務，家庭生活において必要不可欠なインフラとなりました。Webが普及した背景には，利用者が，世界中から必要な情報を必要な時に取得または登録（申請）したいという要求があります。
ビジネス上，取引企業間でのWebの利用が進むと，業務担当者がWebで取得した情報を取捨選別し，別のシステムに入力する場面が多く見られるようになりました。このため人が行っているこの作業を自動化したいという要求が必然的に発生しました（図１）。
従来のWebは，人が利用することを前提にしています。Webはｈｔｔｐプロトコルによるクライアント-サーバ形式によるデータ交換で，サーバが提供するデータはhtml書式で表現されます。クライアント・アプリケーションであるWebブラウザは，html書式を解析し，埋め込まれたスタイル情報に基づき，データを画面に配置します。htmlでは含まれるデータに表示情報（スタイル情報）を関連付けることはできますが，データそのものに意味情報を関連付けることができません。htmlの<table>，<tr>，<td>タグで表示される表は，人がWebブラウザで表示された表をみて意味を解釈し，見出し行とデータ行の位置関係からセルに含まれるデータが何であるか判断します。この作業をアプリケーション・プログラムで行うことが難しく，従来のWebの仕組みを用い，人を介さずシステム間でデータ交換することができませんでした。
Webサービスは，現行のWebの課題を解決し，既存の膨大なWebのインフラ資産を最大限有効活用することを要求に，インターネット上で公開される情報をシステム間で利用できる仕組みとして登場しました。
Webサービスの目的は，インターネット上に分散するアプリケーションの提供する機能を，クライアントのアプリケーションにプログラミング可能なインタフェースとして提供することです。
アプリケーション・プログラムの提供する機能（データ提供，データ編集，データ登録など）をサービスと呼び，このアプリケーション・プログラムをWebサービスと呼びます。
Webサービスによる基本的なアプリケーションの概念モデルは図２のようになります。
この概念モデルには，サービス提供者，サービス利用者のほか，サービス・ディレクトリが登場します。 Webサービスは，従来のWebにおけるWebアプリケーションに相当し，サービス利用者とXML形式のデータの交換を行います。サービス・ディレクトリは，Webディレクトリ，検索サイトまたは各Webサイトにあるサイト・マップに相当し，Webサービスのカタログ，検索機能を提供します。
Webサービスの利用手順は次のようになります。
Webサービスは，プログラミング・モデルの視点から，次のように言い換えることができます。
“ネットワーク上に分散，自律し，不特定の利用者が必要に応じて（オン・デマンド）利用するコンポーネント”
太字のキーワードごとに特徴を説明します。
Webサービス提供者，Webサービス利用者，他Webサービス提供者は，組織または企業が異なることを想定しています。Webサービス提供者は，Webサービス利用者と独立して運用を行います。このため，関連するWebサービス，サービス利用者を全て把握する実体はありません
Webサービスは，アプリケーションの稼動する環境，アプリケーションの実装言語に依存せず，また，データ転送にインターネット・プロトコルを利用することから，不特定の利用者に提供することが可能です。
Webサービスの利用者は，アプリケーション・プログラムの開発時，あらかじめWebサービスのアドレス，インタフェースの型を固定する必要がありません。要求時に目的のWebサービスのアドレスを知り，利用可能なインタフェースを選択して接続することが可能です。
Webサービスの概念は，オブジェクト（コンポーネント）指向の考えに基づき考案されました。このため，Webサービスを仮想的なソフトウェア部品として利用者のアプリケーション・プログラムに組み入れることができます。Webサービス利用者システムを使用する人は，インターネットを介して遠隔地にあるWebサービスを利用していることを全く意識しません。
Webサービスは，その言葉の曖昧さから，人により異なる対象，範囲を指すことが多く混乱しがちですが，W3C Webサービス アーキテクチャWGでは，次のように定義されています。
[Definition:A Web service is a software application identified by a URI, whose interfaces and binding are capable of being defined, described and discovered by XML artifacts and supports direct interactions with other software applications using XML based messages via internet-based protocols] (Web Services Architecture Requirements, W3C Working Draft 29 April 2002より)
Webサービスは，次のような性質を持つソフトウェアです。
UDDI.orgは2000年9月に開始した，IBM，Microsoftなど，企業の連合体によるコンソーシアムで，ビジネス利用を想定したインターネット上で公開するWebサービスのサービス・ディレクトリの実現を目的としています。サービス・ディレクトリのデータ構造，ディレクトリのアクセス方法，サービス・ディレクトリの運用方法に関する仕様作成が主たる活動です。
このサービス・ディレクトリは，UDDIビジネス・レジストリと呼びます。既にIBM，Microsoftにより運営が開始されており，最終的にIBM，Microsoft ，HP，SAP，NTTコミュニケーションの5社により運営されることが決まっています。
UDDI.ビジネス・レジストリを用いたWebサービスのアプリケーション・モデルは，図4のようになります。
このアプリケーション・モデルで，Webサービスは，SOAP，WSDL，UDDIビジネス・レジストリの三つの標準化された要素技術により実現されます。
SOAP：Webサービス提供者とWebサービス利用者間のメッセージ・プロトコル
WSDL： Webサービスのインタフェースとバインディング情報を定義するXML書式の言語
UDDIビジネス・レジストリ：Webサービスの登録，検索を提供するディレクトリ
SOAPは，既存のインターネット・プロトコルの上で，アプリケーション同士がデータ交換をするための通信プロトコルです。
SOAPは，アプリケーションの実装言語，稼働環境や，インターネット・プロトコルの種別に依存しないデータ交換の実現を目的としています。このため，TCP/IPのネットワーク階層と，業務アプリケーションのビジネス・ロジック層の間にメッセージ層を導入しています。
| 層 | プロトコル，言語 |
|---|---|
| ビジネス・ロジック層 | Ｊａｖａ，C#，Perl，COBOLなど |
| メッセージ層 | SOAP |
| アプリケーション層 | http,https smtp ftp message queuing |
| トランスポート層 | TCP，UDP |
| インターネット層 | IP，ICMP |
| ネットワークインタフェース層 | イーサネット，FDDI |
SOAPには転送に使うデータ形式とデータの交換方法について規定があります。データ形式にはXMLを用いで図5のようにSOAPエンベロープと呼ぶルート要素とSOAPヘッダー，SOAPボディの子要素を持ち，SOAPヘッダーは転送制御に関わる情報を含み，SOAPボディはアプリケーション・データを包含します。
SOAPメッセージの例を例１に示す。
| <env:Envelope xmlns:env="http://www.w3.org/2001/09/soap-envelope"> <env:Header> <n:alertcontrol xmlns:n="http://example.org/alertcontrol"> <n:priority>1</n:priority> "n:expires>2001-06-22T14:00:00-05:00</n:expires> </n:alertcontrol> </env:Header> <env:Body> <m:alert xmlns:m="http://example.org/alert"> <m:msg>Pick up Mary at school at 2pm</m:msg> </m:alert> </env:Body> </env:Envelope> <env:Envelope>：SOAPエンベロープ <env:Header>:SOAPヘダー <env:Body>:SOAPボディ SOAPヘダー，SOAPボディが含む要素は全て利用者が規定した要素 |
SOAPによるメッセージ転送は手紙（封書）の配達に喩えると理解がしやすくなります。
SOAPエンベロープは手紙の封筒に相当し，SOAPヘッダーの内容は封筒に記述する住所，宛名などに相当します。そしてSOAPボディの内容が手紙の本文に相当します。手紙は船便，航空便など配送する手段に関わらず同じものが相手に届けられるように， http，smtp，ftpに関わらず同じSOAPエンベロープのメッセージが通信相手（アプリケーション）に届けられます。
WSDL（Web Services Description Language）はWebサービスのインタフェースとバインディング情報の定義を記述するXML形式の言語です。
WSDLは5つの階層化された要素で構成され，次のような情報を持ちます。
| 要素 | 情報 |
|---|---|
| types | 交換するメッセージに含まれるデータ（XML）のスキーマ情報。 スキーマは通常XML Schema DataTypeにより表現される。 |
| message | 交換するメッセージのデータ書式。複数のtypesを組み合わせ，メッセージ中のデータの並びを記述する。 |
| portType | 入力メッセージ，出力メッセージの組み合わせを持つ論理的な操作を記述する。それぞれのメッセージでmessageを指定する。 操作には四つの種類がある。 (1) One-way サービス利用者からサービスへ，一方的なメッセージを送信する。 (2) Request-Response サービス利用者からの要求に対して，サービスが応答する。 (3) Solicit-response サービスからの送信請求に対して，サービス利用者がメッセージを送信する。 (4) Notification サービスからサービス利用者への通知。 (3)と(4)は非同期型のWebサービス実現に備え，用意されている。 操作名はportType要素に含まれるoperation要素のname属性により設定される。 |
| binding | portTypeで定義された論理的な操作の，SOAPメッセージへのバインディング・スタイル（RPC/EncodedまたはDocment/Literal），使用するインターネット・プロトコル，MIMEの指定を行う。 |
| servce | 複数の操作を組み合わせ，サービス利用者に対するオブジェクトを記述する。具体的にはservice要素に複数のport要素を含み，一つのport要素で一つのbinding，そのアクセスポイント（URI）を指定する。 |
UDDIビジネス・レジストリは,電話帳に類似した概念を持っています。UDDIビジネス・レジストリは企業単位にエントリを持ち，企業名，企業を特定するID（識別子）などの企業情報，その企業に対して産業コードや，提供する製品，サービスの分類コードを割り当て，様々な視点による索引を設けています。サービス利用者はサービス内容，企業名，分類コード等からWebサービスを検索します。
UDDIビジネス・レジストリのデータ構造は，企業情報を最上位にもつ階層構造を持つ。
| 情報種類 | 要素名 | 内容 |
|---|---|---|
| White Page | businessEntity | 企業名，業種業態分類情報などを含む。 |
| Yellow Page | businessService | 顧客に提供するサービス（業務）内容情報を含む。 また，あらかじめ用意されたタクソノミ-（分類とコード）として次の三つがある。 _ 産業コード（NAICS） _ 製品/サービス（UN/SPSC） _ 国コード（ISO3166） 企業は異なる複数のサービスを持つため，複数のbusinessServiceが一つのbusinessEntitiyに含まれる。 |
| Green Page | bindingTemplate | サービス（業務）にプログラム的にアクセスするための情報を含む。その情報にはWEBサービスが公開されているアクセスポイント（URL）などがある。 一つのサービスに対して複数のプログラム的なアクセス方法が存在することもあるのでbindingTemplateは一つのbusinessServiceに複数含まれる。 |
| Service Type (電話帳に該当なし) |
tModel | サービスに関する仕様，接続に関する仕様を表わす。接続仕様にはWSDLが公開されているURL情報を含む。 複数の企業が同じサービスや接続を持つ場合，同一つのtModelを参照する。 |
| Business Relation | publisherAssersions | 企業間の関係を表現する。 一つのpublisherAssersionsにおいてfrom,toで二つのbusinessEntityを関連付け，互いに逆方向の関連をもつ二つのpublisherAssertionsがそろって関係が成立する。 |
図6にUDDIビジネス・レジストリの構造を示します。
Webサービスは，現在直ぐに利用できる段階に来ています。しかし，適用する業務によっては，解決が期待されるいくつかの課題があります。
Webサービスをインターネットで公開する際の課題。
運用時のWebサービスの品質における課題。
UDDIビジネス・レジストリは，サービス提供者，利用者にとって新規ビジネスを開拓するために非常に有効です。しかし，実ビジネスへの適用には幾つかの課題があります。一つは，誰もがサービスをUDDIビジネス・レジストリに登録できるため，登録された企業とサービスの品質を，利用者が信頼するための手段が必要なことです。UDDIビジネス・レジストリのバージョン2（2002年夏から運用開始予定）から，検証済みタクソノミーの機能（企業が企業情報，サービスを登録するさい，検証済みタクソノミ-を利用し値を登録しようとすると，その検証済みタクソノミ-を管理する機関の検証が必要となります。）が追加されます。この検証済みタクソノミ-によりお墨付きの企業，サービスを，ある程度信頼することはできますが，新規の取引では，これ以外に与信情報が必要となります。また，UDDIレジストリは，業種業態を問わず利用されることを前提としているので，普遍的で共通な情報のみを保持します。特定の業界業種で利用することを考えると，業界固有の情報や，詳細なサービス情報を拡充する必要があります。例えば，取り扱う製品の分類情報はUDDIビジネス・レジストリに登録できますが，取扱商品の商品コードを登録することはできません。
このため業種業態に応じてUDDIビジネス・レジストリを補完することが望まれます。この補完機能として，UDDIビジネス・レジストリを核として付加機能，付加情報を提供するレジストラ・サービス（以降レジストラと記述します。）と呼ぶ概念があります。
図8に示すようにレジストラはUDDIビジネス・レジストリと，サービス提供者，サービス利用者の中間に位置します。レジストラは，内部に付加価値情報を保持し，サービス提供者の与信情報，サービスの信用情報や，取引に必要な業種業態固有な情報を蓄えます。これらの情報を豊富な索引と合わせてサービス利用者に提供します。
サービス提供者の利益としては，レジストラにより認定されることで，サービス利用者から信用を得やすくなります。また，レジストラ自身が，サービス提供者に代わりUDDIビジネス・レジストリに登録する機能を提供することで，サービス提供者は，UDDIビジネス・レジストリのAPIを使った煩雑な処理を行うことなく，公開することができます。
2002年1月，W3Cでは，現行のWebサービスの持つ課題を解決し，また，今後の機能拡張にも柔軟に対応するように，Webサービスのフレームワークを整備するWebサービス・アーキテクチャ・ワーキング・グループが開始しました。
このフレームワークの最大の特徴は，機能のモジュール化です。Webサービス開発者，Webサービス稼働環境提供者は全ての機能を，初めから実装する必要がなく，必要に応じて段階的に実装することが可能になります。
Webサービスのフレームワーク概念を図9で示します。
フレームワークはWebサービスの実行に関連するWireスタック，Webサービスの定義，登録・公開に関連するDescriptionスタック,Webサービスの検索に関連するDiscoveryスタックに分かれます。モジュール化した各機能が関連するスタックに分類化されます。
現在，有力ベンダー，標準化団体で行われている技術開発，標準化作業を表にしめします。
| 機能 | 規格 | 団体/企業 | 説明 |
|---|---|---|---|
| Reliability | httpr | IBM | httpプロトコルの上に，信頼性のあるメッセージ転送プロトコルを実現 |
| Reliability | Reliable Message（GXA） | Microsoft | マイクロソフトが提案する次世代Webサービス体系GXA（Global XML Architecture）中の信頼性メッセージ機能 |
| Security | XML Signature | W3C | XML文書に対する電子署名の付与 |
| Security | XML Encryption | W3C | XML文書の暗号化 |
| Security | SOAP Signature | W3C :Note |
SOAPメッセージに含めた電子署名つきXMLデータに関連する情報の記述 |
| Security | SAML | OASIS | Webサービスの内部処理で別のWebサービスを呼び出すようなWebサービスの連鎖を想定した権限委譲の方法 |
| Security | XACML | OASIS | XML文書中のノードに対するアクセス制御。 (例)見積もり書XMLの金額に関連するノードは営業部門のみ閲覧可能 |
| Security | XKMS | W3C :Note |
PKIにおける証明書の発行，検査などの処理インタフェースのWebサービス化 |
| Security | WS-Security | IBM Microsoft VeriSign（WS-I） |
SOAPメッセージの暗号化，完全性保証の機能。SOAPの拡張を前提に，PKI，Kerberosに対応。 |
| Security | WS-Policy | IBM Microsoft VeriSign（WS-I） |
セキュリティ・ポリシー（制限事項，可能事項）の記述方法の定義 |
| Security | WS-Trust | IBM Microsoft VeriSign（WS-I） |
サービス利用者，サービス提供者（中間サービス提供者を含む）間の信頼関係を確立のモデル |
| Security | WS-Privacy | IBM Microsoft VeriSign（WS-I） |
Webサービスのプライバシー保護の実装方法と，実行時の利用者に対するプライバシーに関連する情報の提示方法 |
| Security | WS-Secure Conversation | IBM Microsoft VeriSign（WS-I） |
Webサービス提供者（中間提供者も含む），利用者間のメッセージ交換の管理，認証の方法。 セキュリティ関連情報の交換方法や，セッション・キーの確立，配布方法も含まれる。 |
| Security | WS-Federation | IBM Microsoft VeriSign（WS-I） |
異なるセキュリティ体系（SSOシングル・サイン・オン）間での信頼関係の維持管理や，取りまとめ |
| Security | WS-Authorization | IBM Microsoft VeriSign（WS-I） |
Webサービスの権限データ，ポリシーの取扱い方法 |
| Routing | WS-Routing WS-Referral（GXA） |
Microsoft | マイクロソフトが提案する次世代Webサービス体系GXA（Global XML Architecture）中のSOAPメッセージの経路選択機能 |
| Attachment | SOAP Attachment | W3C :Note |
SOAPメッセージ交換における添付データ（バイナリ）の交換方法 |
| Transaction | BTP | OASIS | <Business Transaction Protocol> トランザクション処理を持つ複数Webサービスを利用する場合のトランザクション連携。 2フェーズ・コミットに基づく厳格なトランザクション・グループ（Atom）の組みあせ（Cohesion）による緩やかなトランザクション。 一つのAtomのトランザクションが失敗しても残りのAtomの処理を完結することができる。 |
| Workflow | WSFL | IBM | Web Services Flow Language 複数Webサービスの統合を柱にしたフロー言語 |
| Workflow | XLANG | Microsoft | XML-EDIミドルウェアBizTalk Serverにおける受信メッセージの内部処理制御フローの記述が発端 |
| Workflow | WSCL | W3C :Note |
Web Services Conversation Language 軽量なフロー記述言語 |
| Inspection | WS-INSPECTION | IBM Microsoft |
Webサービス提供サイトで公開するWebサービスのディレクトリ。それぞれの一元管理するUDDIビジネス・レジストリに対して，各Webサービス提供サイトに配置される分散型。 |
| Provisioning | WSHT | IBM | -Web Services Hosting Technology 有料課金Webサービスの運用も範囲に含めた，Webサービスのプロビジョニング体系 |
| Provisioning | SPML | -Service Provisioning Markup Language Webサービスの提供環境（プロビジョニング）に対する処理要求（Webサービスのサービス提供要求）と問合せ機能の標準化 |
|
| Application | WSIA | OASIS | - Web Services for Interactive Application 対話型のWebアプリケーションの構築に，Webサービスをコンポーネントとして組み合わせるためのフレームワーク |
| Application | WSRP | OASIS | - Web Services for Remote Portals> ポータルWebサイトにおいて，Webサービス技術を用い分散する動的コンテンツを簡易に集約（プラグアンドプレイ）できるようにする仕組。WSIAのフレームワークに対応。 |
今後のビジネスにおいて企業間の柔軟な連携が重要視される中，Webサービスはそれらを支えるＩＴとして，非常に期待されています。Webサービスが期待どおりの機能を持ち合わせるＩＴとなるには，まだ，充分に機能がそろっていないことは事実です。
では，機能が充実するまで待つべきでしょうか？WebサービスはGUIを持ちません。そのため机上の考察だけでは，Webサービスの本質は完全に理解できないと言われています。
各有力ソフトウェア・ベンダーから安価で，質が高く，開発生産性の高い，ツールや開発環境を提供しています。また，Webサービスを動かすのに，既存のネットワーク環境以外にインフラを整備する必要がありません。まずはプロトタイピング・システムを構築することが，今後の展開を考える上で，最良の策であると考えられます。先進的なユーザの多くは，プロトタイピング・システムの構築に着手し，Webサービスの概念，利点を把握し，ビジネス展開シナリオを検討する段階に入っています。