ここで、現在のインターネットサービスの利用方法を考えてみよう。まずURLを入力して画面を開き、入力作業を行なう。ユーザー名とパスワードを入力してログオンし、その後にいろいろなサービスが使えるようになるというのが、典型的な例である。
オンラインショッピングの場合も、あらかじめユーザーがプロファイルを登録しておき、ワンクリックで買い物ができるスタイルである。株のトレーディングにしても、まずログオンし、ユーザーの残高などが表示され、そのなかで株の売買を行なうという方式を取っている。共通することは、基本的にサービスを利用するという点では、まずURLで画面を開くという操作が必要になるということだ。
ところが、アプリケーションとアプリケーションが連携する場合は、プログラム間連携なので、セキュリティチェックは必要となるが、画面が見えなくても、直接サービスを利用することが可能なわけである。今までのActive Server PagesやPerlなどは、基本的にクライアントに対して、そのつどHTMLで画面を作って返す作業をしているが、その作業が無駄になる。それに対して、いきなりオブジェクトを指定して、業務ロジックの部分で連携させるのは効率がいい。極論すれば、アプリケーション間連携においては、Webサーバの役割は無駄ということになってしまう。
現在では、Internet Information Services(IIS)にしても、ほかのアプリケーションサーバにしても、Webの上でオブジェクトを動かす仕組みを作っているので、Webが必要になるが、要するにオブジェクトが動けばいいわけだ。すると将来はHTMLなんて必要ない、XMLがあればいいという段階に進み、Webは必要なくなるということになる。つまり、Webページはユーザーがページとして見るから必要なのであって、機能を呼ぶ場合には必要ないということになる。
ここで、サービスについて考えてみよう。
- B2Cのような、ユーザーの入力が必要で、現在のようにユーザーに見せるためのサービス
- B2Cのような、アプリケーション間連携ができれば、表示を必要としないサービス
この場合、2のサービスでは、そのつどHTMLの受け渡しは必要なくなる。クライアント／サーバ(実際は3階層)のなかで画面のやり取りをなくした、より効率的な業務間連携ができるようになったのが、SOAPの重要なところなのである。
クライアントのユーザーが、サーバにアクセスする際にはSOAPを利用する(ルースリーカップル：「粗」)。つまり、UIからオブジェクトの呼び出しはルースリーカップルで行なう。そこからトランザクションが発生し、中間層からはDCOMプロトコルを使ったタイトリーカップル(「密」)で行なう。このような関係を「.NET」は基本にしているし、歴史的に見ても、このような流れは必然的である。
そしてMicrosoftは、Webサービスや業務ロジックを、アプリケーションのオブジェクトの集合として位置付けた。今まではアプリケーションで処理した結果の画面を、クライアントに流すための機能だったものを、今度はアプリケーションを部品としてインターネットに公開することにしたわけである。「Webオブジェクト」と呼ばれる部品を、インターネット上の業務ロジックの部品などと連携できるようにしたのである。
