ウエブサービス:SOAP vs. AJAX

今現在ウエブ・サービスを実現する上で二つの技術がある。一つはSOAP、もう一つはAJAX。SOAPはHTTPとXMLを使用したRPCと言ったイメージ。主にアプリケーションから使用、又はバックエンドとバックエンドを結ぶイメージがある。もう一方のAJAXには、ウエブ・ブラウザーの機能で、今まではブラウザー上で、何かアクション(ボタン・クリックなど)があるとウエブ・ページ丸ごと更新されていたのが、AJAXを用いる事によってウエブ・ページの一部分をサーバーからのレスポンスによって更新できるようになる。

しかし、よくよく考察してみると、二つの機能の出来る事は凄く似ているように思う。基本的に、クライアントからサーバーにHTTP経由でリクエストを送り、サーバーがそのリクエストに対するレスポンスをHTTP経由で返す。二つの機能の違いは大きく二つあるように思う。SOAPはHeavy-Weight、AJAXはLight-Weight。SOAPはやり取りするデータ・リクエストにフォーマットが決まっているが、AJAXには決まっていない。基本的に出来る事が同じなのであるから、エンジニアはLight-WeightなAJAXを好み、その内SOAPは使われなくなっていくのではないだろうか?過去の例からも堅苦しい仕様の機能は、流行らなかったり、段々使われなくなっていったり。

SOAPもそんなにHeavyな仕様じゃないので、僕の予想は外れるかもしれないですが。。。。

Advertisements

4 thoughts on “ウエブサービス:SOAP vs. AJAX

  1. 僕はちょっと違った意見をもってま~す。(書いてもいいですか・・?ってもう書いてるよ!)

    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はなくならない、に一票!

  2. コメントありがとう。

    今現在XMLHttpRequestの実装ってJavaScriptに限られるんだけど、その内、”POPULARな”様々な言語の実装が出てきて、「AJAXはブラウザを使うユーザの経験を向上させる」の枠から飛び出してくるのでは?そして、SOAPと競合しだして、どっちがEASY?って話になって、AJAXの方がEASYじゃんって事でプログラマーはAJAXを利用してウエブ・サービスを実装しはじめるというのが私のシナリオです。プログラマーはなんてったって「ゆるい」のが好きなのではないでしょうか?

    SOAP使うのには、環境とそれなりの手順が必要でちょっとめんどうに感じます。

    SOAPなくならないとは思いますが、AJAXベースのウエブ・サービスがその内幅を利かせてくるに一票。

  3. なるほど、たしかに僕もパラメータを二個ぐらいとってXMLをリターンしてくる程度のサービスならHTTP GETでサクっとやったほうが手っ取り早いって思うこと、あります。

    ただHeavyDutyなインテグレーションでWS-*に基づいたやり取りなんかはやっぱりSOAPじゃないと生産性が追いつかないと思います。

    そこら辺で「住み分け」が進行するかもしれませんねぇ。「サクっとやりたい組はAJAX」みたいな?

    ちなみに「ゆるい」の意味が “Not strongly typed” だとしたら僕は断然”
    Strongly Typed”の方が好きです。そもそも型が分からない状態で

    var x = document.getElementById()

    みたいなのってどーも気持ち悪いです。

    でもこれは個人的な感想で、それが悪いとはひとつも思いません。

    何度も失礼しました!

  4. 「ゆるい」は単語の使い方を間違っていたかもしれません。形式ばっていないとか、手順が少ないなどのニュアンスで使いました。

    自分もJavaScriptのVar型は苦手です。データが何を指しているのかCodeから簡単に分りません。

    コンシューマー向けウエブサイトが、ただ単にHTTPリクエストに対してXML、JSON、又はPlain Textでデータを返して。ブラウザーからのアクセスだったら、WebベースのUIの向上。PC上で動くアプリケーションからのリクエストだったらRPCとして。サーバーアプリケーションからの接続だったら、バックエンド同士のRPCとして使われるのを想像してます。

    ちょっと繰り返しになってしまいますが、WSDLからソースコード吐き出して、コンパイルして、アプリケーション及びサーバーから呼び出す。JAVAだとSOAPクライアント又はサーバーを動かすのに、多くのJarファイルにクラスパスを設定しなければなりません。やっぱりHEAVY-WEIGHTだと思います。

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s