今度は、Web サービスを利用する側、
つまり、クライアントの方を考えてみよう。

RPC 系の Web サービスは、高度な水準であるため、
主に SOAP 機能を持つプログラムで利用される。
基本的に通信内容の XML はフレームワークで処理され、
プログラマが直接 XML を扱うことは殆どない。

REST や、任意の XML を利用する Web サービスの場合、
(便宜上、データ系と呼ぶことにする)
XML はそのままデータとして扱われるので、
XML の内容を、自力で解析する必要があり、
HTTP で通信を行う機能を持ち、
DOM 等で XML の解析が可能なプログラムで利用される。

さて、Web サービスは、当然ながら、
それを利用するクライアントがないと意味がないが、
クライアントには上記のような制約があるため、
利用者が直接 Web サービスを使うのは困難だ。

というのも、利用者が使うクライアントといえば、
やはり Web ブラウザが一般的である。
Web ブラウザは HTML しか解析しないため、
直接 Web サービスを利用することはできない。

利用者を限定しない WWW においては、
利用者に専用プログラムをインストールさせるのは敷居が高く、
Web ブラウザ以外の使用を強制するのは嫌われるからだ。

だからといって、Web ブラウザを相手にしないのは厳しい。
専用のクライアントプログラムで狭く利用するよりは、
やはり WWW の世界で相互利用されることが重要であるのだ。

Web サービスが、WWW の世界での普及に難があるようでは、
Web サービスを用意するメリットも半減してしまう。

そのため、Web サービスは、他の Web サーバを介して、
Web ブラウザに情報を提供するような位置づけが多い。

 Web ブラウザ <=> Web サーバ <=> Web サービスサーバ

用語の関係でややこしいが、サーバやクライアントというのは、
あくまでも「役割」であるため、
Web サーバの「役割」をもつコンピュータが、
クライアントとして別のサーバに接続することは可能なのだ。

つまり、上の図の右にある Web サービスサーバから見ると、
中央の Web サーバは Web サービスクライアントになる。

Web ブラウザ(クライアント)が Web サーバに接続すると、
Web サーバは、他の Web サイトが提供している
Web サービスに接続してデータを取得し、
それを HTML などに加工して Web ブラウザに返すのだ。

つまり、クライアントサーバシステムの三層モデルとして、
Web サービスがデータ層、Web サーバがファンクション層、
Web ブラウザがプレゼンテーション層として機能する。

データの提供を行うサーバ(Web サービス)と、
加工を行うサーバ(Web サーバ)が自由に連携することで、
利用者(Web ブラウザ)に提供できる情報が増えるのだ。

例えば、ニュースや天気予報、株価情報などを、
外部の Web サービスを利用して取得することで、
Web サイトの表現力を増やすことができる。

一般的に、ポータルサイトと呼ばれる Web サイトは、
外部の Web サービスの力を借りて、
Web ページの中に色々な情報を表示しているのだ。

Web サーバ側で、Web サービスを利用するためには、
Web サービスのクライアントとして機能する、
プログラミングを行う必要がある。

RPC 系の Web サービスの場合は、Web サーバ側で、
ASP.NET や Java 等の高度な機能を利用して、
SOAP クライアントのプログラミングが必要となる。

これは、PHP や Perl には敷居が高く難しいため、
通常、専用の Web サーバを持つ環境となる。
そのため、個人サイトなどでは絶望的であり、
利用は、事業を行っている企業サイトなどに限られる。

データ系の Web サービスの場合は、
PHP や Perl でも利用することができる。
HTTP で他の Web サービスと通信して XML を取得し、
それを DOM の力を借りて解析、
もしくは言語機能を用いてタグを直接解析する。

この場合は、個人サイトでも多く利用することが可能である。
現在、REST ベースの Web サービスが多いのは、
それを利用できるクライアントの制約が緩いからだろう。

1 つの Web サイトだけではその情報量に限界はあるが、
他の Web サービスと連動することで、
表現力や情報量に大きな幅を持たせられるようになるのだ。