今現在ウエブ・サービスを実現する上で二つの技術がある。一つはSOAP、もう一つはAJAX。SOAPはHTTPとXMLを使用したRPCと言ったイメージ。主にアプリケーションから使用、又はバックエンドとバックエンドを結ぶイメージがある。もう一方のAJAXには、ウエブ・ブラウザーの機能で、今まではブラウザー上で、何かアクション（ボタン・クリックなど）があるとウエブ・ページ丸ごと更新されていたのが、AJAXを用いる事によってウエブ・ページの一部分をサーバーからのレスポンスによって更新できるようになる。
しかし、よくよく考察してみると、二つの機能の出来る事は凄く似ているように思う。基本的に、クライアントからサーバーにHTTP経由でリクエストを送り、サーバーがそのリクエストに対するレスポンスをHTTP経由で返す。二つの機能の違いは大きく二つあるように思う。SOAPはHeavy－Weight、AJAXはLight-Weight。SOAPはやり取りするデータ・リクエストにフォーマットが決まっているが、AJAXには決まっていない。基本的に出来る事が同じなのであるから、エンジニアはLight－WeightなAJAXを好み、その内SOAPは使われなくなっていくのではないだろうか？過去の例からも堅苦しい仕様の機能は、流行らなかったり、段々使われなくなっていったり。
SOAPもそんなにHeavyな仕様じゃないので、僕の予想は外れるかもしれないですが。。。。
Life after reading Startup 
僕はちょっと違った意見をもってま～す。（書いてもいいですか・・？ってもう書いてるよ！）
AJAXはJavaScript言語をそのモデルに内包してますからJavaScriptを実行できる環境を要求します。その環境として最も一般的なのがウェブ・ブラウザです。ワークステーション上のスクリプト環境（例：WindowsScriptHost）としてのJavaScriptっでも多分使えるんでしょうけど（やったことはないです・・・）
B2Bのインテグレーションを行う上でJavaScriptを使っていればAJAXも使えるということになりますか・・・。
一方SOAPはInteroperabilityを目的としているのでなんの言語でも実装できます。二つのエンドポイントがJavaでもC++でもC＃でもPHPでも何でもアリです。さらに”HeavyWeight”である理由はあるサービスをAPIとして「固定する」目的があるのでその分いろいろ付いてきてしまいます（たとえばWSDL言語によるAPIの定義）。
この点、AJAXはフォーマットは自由です（JASONというシリアル化のフォーマットのことではなく、APIとしてのフォーマット）
「フォーマットが自由」ということは「自分て定義していい」ということでということはプロプリエタリなフォーマットがあちこちにできる可能性がある。結果としてInteroperabilityという点においては問題が生じることになる。
ということは「AJAXはブラウザを使うユーザの経験を向上させる」で、「SAOPはサービス・プロバイダ間のinteroperabilityを向上させる」ということになるでしょうか。
つまり重要な違いの一つに「目的が違う」ということがあげられると思います。
「目的が違う」ということは「競合しない」ということ、つまり片方がもう一方を駆逐してしまうことは無いといえます。
ということでSoapはなくならない、に一票！
コメントありがとう。
今現在XMLHｔｔｐRequestの実装ってJavaScriptに限られるんだけど、その内、”POPULARな”様々な言語の実装が出てきて、「AJAXはブラウザを使うユーザの経験を向上させる」の枠から飛び出してくるのでは？そして、SOAPと競合しだして、どっちがEASY？って話になって、AJAXの方がEASYじゃんって事でプログラマーはAJAXを利用してウエブ・サービスを実装しはじめるというのが私のシナリオです。プログラマーはなんてったって「ゆるい」のが好きなのではないでしょうか？
SOAP使うのには、環境とそれなりの手順が必要でちょっとめんどうに感じます。
SOAPなくならないとは思いますが、AJAXベースのウエブ・サービスがその内幅を利かせてくるに一票。
なるほど、たしかに僕もパラメータを二個ぐらいとってXMLをリターンしてくる程度のサービスならHTTP GETでサクっとやったほうが手っ取り早いって思うこと、あります。
ただHeavyDutyなインテグレーションでWS-*に基づいたやり取りなんかはやっぱりSOAPじゃないと生産性が追いつかないと思います。
そこら辺で「住み分け」が進行するかもしれませんねぇ。「サクっとやりたい組はAJAX」みたいな？
ちなみに「ゆるい」の意味が “Not strongly typed” だとしたら僕は断然”
Strongly Typed”の方が好きです。そもそも型が分からない状態で
var x = document.getElementById()
みたいなのってどーも気持ち悪いです。
でもこれは個人的な感想で、それが悪いとはひとつも思いません。
何度も失礼しました！
「ゆるい」は単語の使い方を間違っていたかもしれません。形式ばっていないとか、手順が少ないなどのニュアンスで使いました。
自分もJavaScriptのVar型は苦手です。データが何を指しているのかCodeから簡単に分りません。
コンシューマー向けウエブサイトが、ただ単にHTTPリクエストに対してXML、JSON、又はPlain Textでデータを返して。ブラウザーからのアクセスだったら、WebベースのUIの向上。PC上で動くアプリケーションからのリクエストだったらRPCとして。サーバーアプリケーションからの接続だったら、バックエンド同士のRPCとして使われるのを想像してます。
ちょっと繰り返しになってしまいますが、WSDLからソースコード吐き出して、コンパイルして、アプリケーション及びサーバーから呼び出す。JAVAだとSOAPクライアント又はサーバーを動かすのに、多くのJarファイルにクラスパスを設定しなければなりません。やっぱりHEAVY-WEIGHTだと思います。