企業システムに浸透し始めたWeb 2.0

ここでは、今後企業システムでの利用が広がると予想されるWeb 2.0的な技術のうち、RESTとAjaxを取り上げたい。

RESTが変えたWebサービス

まずは、これまで行なわれてきたシステム連携技術であるWeb サービスのあり方を変えると言われるREST（Representational State Transfer）を取り上げる。RESTとは何か、RESTが何を変えるのかについて、従来のWeb サービスと比較しながら説明していこう。

普及しなかった狭義のWeb サービス

Web サービスと言ったとき、「広義のWebサービス」を指す場合と「狭義のWebサービス」を指す場合とがある。
広義のWeb サービスは、前述したSOAとほぼ同じ意味で、サービスとして公開されたプログラムにネットワーク経由でアクセスし、それらを部品として利用する形態全般を指す。XML 技術をベースとする必要はない。また、広義のWebサービスは、企業や社会全体のシステムのあるべき将来像を語るときにしばしば使われる。
それに対し、狭義のWeb サービスは、Webサービス利用のために交換されるメッセージフォーマットを定義した「SOAP（Simple Object Access Protocol）」、公開されたWeb サービスの使い方や内容を記述する「WSDL（Web Service Definition Language）」、Webサービスを探すためのディレクトリサービスを定める「UDDI（Universal Description, Discovery, and Integration）」という、XML ベースで定められた仕様群を用いて構成されるシステムの形態を言う（図6）。
狭義のWeb サービスは、主要なミドルウェア製品を使えば実装できる。ただし、企業システムの将来像としては納得できても、SOAP、WSDL、UDDIが使い物になるような場面は限られるので、宣伝されているほど広く使われていないのが現状だ。SOAPなどの仕様は機能がリッチである分、理解しなければならないこともまた多く、技術面での敷居が高かったことが、その普及を妨げている。

図6 狭義のWebサービス

RESTによるWeb サービスの新しい形

こうした、従来型のWebサービスの問題をクリアする新しいWebサービスの形態と目されているのがRESTである。RESTとは、Webアプリケーションに適用されるアーキテクチャの考え方（指針）の1つだ。RESTアーキテクチャを採用したWeb アプリケーションは、以下のような特徴を持つ（図7）。

●Webアプリケーションの機能は、HTTPのメソッド（GET、POSTなど）により呼び出される
●外部から呼び出される機能は、一意となるようなURL（もしくはURN）が割り振られている
●すべての機能呼び出しは独立しているため、クライアント側での状態維持の必要がない

現在、Web 上ではこのREST を用いたWeb サービスの利用が増加し、あっという間にSOAPを利用する狭義のWebサービスから主役の座を奪ってしまった。
RESTでは、SOAPやWSDLといったXML ベースのプロトコルを用いるわけではないが、現在の主要なREST 型Web サービスはXML 形式のデータを返すのが一般的になっている。レスポンスをXML 形式にしているのは、Webサービスのマッシュアップによるサイト構築に好都合だからだ。
マッシュアップを改めて説明すると、すでに流通しているWeb コンテンツの部品や機能をいくつか組み合わせて、新たな価値を付与した上で新たなコンテンツとして公開することである。いわば、広義のWebサービスそのものだろう。レスポンスがXML であれば、素材提供元のサイトとは異なるレイアウトで表示するのに文書構造を変換するXSLT（XSL Transformations）のような技術が使えるし、もともと無関係なサイトから入手した複数の素材を結合するのに、個々のXML データの持つ構造がとても役に立つのだ。

図7 RESTアーキテクチャ

Web サービスの3つの形

現在、主要なWebサービス提供サイトが採用しているWebサービスの形式には、REST、SOAP、XML-RPCの3種類がある（表2）。
XML-RPC方式とは、HTTPプロトコル上でリモート環境にある処理の呼び出しを実現するための方式である。REST方式と似ているが、REST 方式がHTTP プロトコル自体を使って処理を呼び出すのに対して、XML-RPC 方式はその名のとおり、HTTP プロトコル上にXML 形式のリクエストを流して処理を呼び出す。XML-RPC方式もREST方式と同じ理由により広義のWeb サービスと呼べる。
これら3 つの形式は、サービス利用者の目的に合わせて選択すれば良い（表3）。REST はほかの方式とは異なりURL による呼び出しが可能であり、レスポンスもJSON（次節にて説明）のようなXML 以外 の形式が可能であるため、JavaScriptからの呼び出しに適している。
SOAPは唯一標準化されているWebサービス方式であるため、仕様調整が困難な企業間のデータ交換に適している。XML-RPCはSOAPと同じXMLベースの仕様だが、通信プロトコルをHTTP を前提としていることや、標準化を目的としていないためにSOAPよりもシンプルかつ軽量である。RESTよりも厳密にリクエストのデータ構造を定義したいが、SOAPを使うことでサービス利用者への敷居が高くなることは避けたいサイトで利用されている。

表2 代表的なWebサービス

表3 Webサービス方式の比較

WebアプリをリッチにするAjax

もう1 つのWeb 2.0 的技術であるAjaxは、通常のWeb ブラウザ上でリッチクライアントを実現する手段として注目されている。

Google Mapsにより広まったAjax

AjaxはAsynchronous JavaScript and XMLの略で、「XML 形式のデータをクライアントの側のJavaScript とサーバーとの間で非同期のHTTP 通信により交換する」という意味である。非同期とはWebブラウザでのページ遷移を伴わずに表示情報の更新できることを言う。この仕組みを使えば、Visual Basicなどで開発したクライアントアプリケーションに似たユーザーインターフェイスをWeb ブラウザ上で実現できるのである。このことから、Ajax はリッチクライアントを既存のインフラ上で簡単に実現するために有効な技術やアーキテクチャの総称としても使われている。
Ajax は、地図情報を提供するGoogleMaps をマッシュアップした数多くのサイトとともにインターネットに広まった。さらに、GoogleはGoogle Mapsを利用するためのJavaScript コードを自動生成する ウィザード（画面）を提供しており、開発者は生成されたコードを埋め込むだけで、地図情報を利用する機能をWebアプリケーションに追加できる。
このJavaScript コードにはAjaxの仕組みが実装されていて、Google MapsのデータベースとXML 形式でデータをやり取りする。LIST に生成されたJavaScriptコードの例を示す。生成されたJavaScriptコードでは、ページ表示のためのHTTP 通信とは非同期で、Google Mapsサーバーから必要な地図情報を取得して表示するAPI（Google Maps API）を使用している。これにより、Google Mapsを一躍有名にした、Web ブラウザ画面のリロードを伴わない広大な地図のスクロールが可能となる。
XML も非同期通信も既存のインフラ上で動く、古くからある技術であるが、Ajaxはそれらを組み合わせて、新しく質の高いユーザーインターフェイスを実現できることを示した点が何より画期的であった。

画面 ■ Google Mapsを埋め込むためのJavaScriptを生成するウィザード

LIST ■ 生成されたJavaScript のコード（一部抜粋したもの）

<script type="text/javascript">
    function LoadMapSearchControl() {
         var options = {
              zoomControl : GSmapSearchControl.ZOOM_CONTROL_ENABLE_ALL,
                title : "ウルシステムズ株式会社",
               url : "http://www.ulsystems.co.jp/",
                idleMapZoom : GSmapSearchControl.ACTIVE_MAP_ZOOM,
                activeMapZoom : GSmapSearchControl.ACTIVE_MAP_ZOOM
            } 
        new GSmapSearchControl(
        document.getElementById("mapsearch"),
        "東京都中央区晴海1-8-10",
        options
        );
    }
    // arrange for this function to be called during body.onload
    // event processing
    GSearch.setOnLoadCallback(LoadMapSearchControl);
</script>

XMLを使わないAjaxもある

一方、Ajax によって実現できるようなリッチなクライアントは、JavaScriptとXML でなくとも実装可能である。つまり、文字どおりのAjaxである必要はない。
Web ブラウザ上で非同期通信を行なう機能を実装する手段は、JavaScript以外にもある。中でもFlashはJavaScript以上の表現力を持っており、しかも昨今ではモバイル機器上の動作環境も整備されつつあることから、リッチクライアントのプラットフォームとして注目されている。
また、Flash によるリッチクライアント開発を容易にするために、Flashの開発元である米アドビシステムズはアプリケーションフレームワーク「Flex」も提供している。Flex は、Flash を使うWeb アプリケーションをJSP（JavaServer Pages）のようにタグベースで記述可能にする。タグで記述されたページは、Flexフレームワークに含まれるコンパイラによりFlashコンテンツに変換される。これまで開発生産性などの面から業務アプリケーションには向かないとされてきたFlashだが、開発／実行環境の充実により、今後リッチクライアントにおけるデファクトスタンダードになる可能性も捨てきれないと言えるだろう。
Ajax のもう1 つの要素である、通信に使用するデータ形式もXMLでなくて良い。特に注目されているのは「JSON（JavaScript Object Notation）」である。JSON はJavaScriptと親和性の高いテキスト指向のデータ形式で、そのままJavaScriptのソースコードに埋め込んで扱える。先ほどのLISTでも、オブジェクトのデータ形式としてJSONを使っている（LISTの赤字部分）。
また、JSONはJavaScript以外にもJavaやC、Perl、Ruby など、多数のプログラミング言語がサポートしており、XML に代替できるデータ標準として認知も広がってきている。

WebサービスとAjaxの今後

ここでは、企業システムに影響を及ぼすと思われるWeb 2.0的な技術としてRESTとAjaxの技術的な側面を説明してきたが、最後に、RESTやAjaxが今後どう企業システムで展開されていくのかを考えてみよう。

現実的なWeb サービスが広がる

先ほど、Web サービスの3 つの形（REST/SOAP/XML-RPC）を紹介したが、その中でもRESTの広まりの速さは驚異的であるし、SOAPやXML-RPCはその勢いに引っ張られて利用を伸ばしてきたという印象がぬぐえない。RESTが広まった最大の要因は、だれでも簡単にWeb サービスを利用可能にする、その扱いやすさにあるだろう。Google Mapsのような魅力的なサービスがREST 形式で公開されたことにより、マッシュアップで開発した新しいサービスを提供するWeb サイトが爆発的に増加したのである。
ただし、Web サービスが本格的に利用されていくためには、より多くの有益なサービスが公開される必要がある。これまでのSOAP形式によるWeb サービス公開では、必要な技術水準が高かったために ユーザーの利用が低調で、サービス公開も活発にならないという悪循環に陥っていた。RESTの成功によって多種多様なサービスの公開が進むとともに、シンプルな連携はRESTで、もっと高度な連携が必要なときにはSOAP で、という具合に公開方法を使い分けたWeb サービスが実現されていくだろう。
そしてこの動きは、インターネットからイントラネットへと展開していくはずだ。インターネットでのRESTの成功によりWebサービスの敷居が低くなった今、企業内に埋もれているアプリケーションをWebサービスにより再生しようという提案は、以前よりも企業の経営者や情報システム担当者に受け入れられやすくなるに違いない。

企業システムにおけるAjax の利用

現在の企業システムではWebアプリケーションが主流になりつつあるため、最近言われているAjax のエンタープライズ領域への進出というのも自然な流れだ。多くの企業でAjax採用の動きが具体化するだろう。そのとき、JavaScriptとXMLの組み合わせは最適だと言えるのだろうか。
表現力という面では、現時点でJavaScriptはFlashに及ばないが、運用管理面を考えるとJavaScriptは有効だ。Flashアプリケーションを稼動させるためには、WebブラウザにFlash動作環境をプラグインする必要があるが、JavaScript はWeb ブラウザだけで良いので、情報システム管理者がクライアント端末の管理をするときに余計な手間がかからない（図8）。
また、Flashは特定の企業が仕様をコントロールしているのに対し、JavaScriptはオープンな技術なので、技術者の調達などで圧倒的に有利だ。クライアントをリッチにすることが業務効率にどの程度寄与するのかを客観的に評価するのは難しいので、情報システム部門としてはFlash採用を決断することは当面難しいだろう。
データ形式については、JSONはJavaScriptと相性が良く、仕様もXMLより単純で習得しやすい。その反面、どういった業務でどのような目的に使われるデータなのかを厳密に定義するには、XML のほうが 適している。特に企業間でのデータ交換において、あいまいさはシステム開発に大きな負担を強いる。さらに、すでに企業間データ交換の主流となっているXMLには、ほかのさまざまなデータ形式からの変換ツールが用意されている。そのため、企業内に存在するさまざまな業務データを連携するにはXML が有利である。
こうして考えてみると、AjaxがJavaScript ＋XML であることによるメリットは、今後、企業システムへAjaxの導入が進む過程で判明してくるように思われる。その一方で、Flashの持つ豊かな表現力やJSONの簡単さにメリットを感じ、積極的に利用している人々がいるのも事実である。システム構築にAjaxの適用を考えるのであれば、Ajax に何を期待するのか、もう一度考えてみる必要があるだろう。

図8 リッチクライアント実現に必要な動作環境の比較