Ajax と REST、第 2 回

Ajax ソフトウェア開発という難題に立ち向かう

Ajax の人気は急上昇しています。古い Web フレームワークでは Ajax をサポートするための改良が進行中で、新たな Ajax のみでのフレームワークの開発が進んでいます。また、Ajax の採用を検討中であったり、Ajax アプリケーションの構築をすでに開始したという組織も多数あります。そんなブームとは裏腹に、Ajax アプリケーションのデプロイメントに成功した組織は数えるほどです。2 回からなる連載のこの最後の記事は、実際の IT アプリケーションで Ajax を使用するべきかどうかを判断する際の手掛かりとなるとともに、Ajax 開発の成功率を高めることを目的としています。

Bill Higgins (bhiggins@us.ibm.com), Rational, IBM

Bill HigginsBill Higgins は、IBM Rational Software 部門で、開発チームをサポートするツールに取り組んでいます。2000 年、ペンシルバニア州立大学を卒業した彼は、コンピューター・サイエンスの理学士号を取得しています。仕事以外での趣味は、夫人と 2 人の子供と一緒に過ごすこと、自分の developerWorks ブログに投稿すること、そして読書とバスケットボールです。



2006年 11月 14日

この 2 回からなる連載の第 1 回では、Web アプリケーションに、動的でパーソナライズ化されたユーザー・インターフェースが要求される一方で、拡張性も必要な場合に、Web アプリケーションに対して Ajax/REST アーキテクチャー・スタイルが持つ潜在的なメリットについて説明しました。またこの要件に基づき、ランタイム特性という点で Ajax/REST アーキテクチャー・スタイルが従来のサーバー・サイド Web アプリケーションのアーキテクチャー・スタイルより優れている理由を説明しました。ただし、このようなランタイム特性の良い面ををユーザーが活用できるようになのは、Ajax アプリケーションの設計、計画、開発、テスト、そしてデプロイメントがうまくいった場合のみです。そこで、今回の記事では Ajax/REST アプリケーション開発時の特性について取り上げます。目的は、実際のアプリケーションへの Ajax の採用に興味を持つ読者が、次の重要な 2 つの質問に対する答えを出す手助けをすることです。

  • 自分の IT アプリケーションに Ajax 技術を使用するべきか。
  • Ajax 技術を使用する場合、その開発とデプロイメントの成功率を高くするにはどうしたらいいのか。

Ajax/REST アーキテクチャー・スタイルの新しさは、今までサーバー・サイド Web アプリケーション・スタイルを使用していた組織に難題を投げかけます。Ajax には従来のモデルよりアーキテクチャーの点で有力な利点がありますが、純然たる Ajax/REST のアーキテクチャーに短時間で完全に移行するのは、すべての組織にとって現実的ではありません。Ajax 開発のスキルがない組織では、既存のサーバー・サイド Web アーキテクチャーに Ajax 機能を徐々に追加しながら Ajax の調査を進めるという方法を採ることができます。Ajax/REST での経験を積むにつれ、より面白い意欲的なプロジェクトに自信をもって取り組めるようになります。

Ajax Resource Center にアクセスしてください。ここには、記事、チュートリアル、ディスカッション・フォーラム、ブログ、ウィキ、イベント、そしてニュースなど、Ajax プログラミング・モデルに関する情報が豊富に用意されており、ワンストップ・ショップになっています。新しい情報もここに記載されます。

Ajax を使用すべきか否か

Ajax は、一連の技術で構成されたアーキテクチャー・スタイルです。これらの技術はそれ自体に良し悪しがあるわけではなく、当たり障りのないものです。技術は、組織が適用して特定の問題を解決したり、あるいは特定の必要を満たすことができる限り多少なりとも有益です。そのため、「Ajax を使うべきか」という質問に対する答えを出すには、組織が達成しようとしているものが何なのか、Ajax がその達成に役立つ (または役立たない) のか、そして組織に適切な人材がいるかどうかを見極めなければなりません。

多種多様な採用オプションを検討する

「Ajax を採用する」という意味がわからない方もいるかもしれません。Ajax を利用すると言っても、アプリケーションを Ajax/REST のみのアーキテクチャーで作成しなおす必要はありません。純然たる Ajax/REST アーキテクチャーに直接飛びつくのではなく、まずは小規模なものから始めて少しずつ経験と自信をつけていくことをお勧めします。

Ajax の採用は、単純でささやかな作業を意味する場合もあります。例えば、Web アプリケーションのそれほど重要ではない機能を実装しなおして、機能性や応答性を高めるなどといったことです。このような単純なスタイルの一例が、Netflix 映画のフィードバック機能です。カスタマーは 1 つ星から 5 つ星をクリックすることで、簡単に映画に点数を付けることができます。クリックするとすぐに Netflix の設定が更新され、それに応じてお勧めの映画が変更されます。

Ajax を採用したハイ・エンドのアプリケーションとしては、例えば Web アプリケーション開発における最先端技術の定義を変えた、Google の Gmail および Maps があります。これらのアプリケーションは、豊富な直観的対話機能、あかぬけた表示、そしてユーザーの操作とユーザー・データに応じて常にユーザー・インターフェースを調整する機能で注目に値します。

確かに、Google Maps のように洗練されたものを業界にリリースしたら、どんな好反応が返ってくるかを想像すると心がくすぐられます。でも、現実的になってください。Google にはおそらく世界屈指の Web 開発組織があるはずなので、これを Ajax で実現可能なことの基準にするのは危険です。また、Google は (賢くも) 公にする準備が整うまでは新しいアプリケーションについて発表しなかったので、我々はその成功の部分しか見ていないということも忘れないでください。Google のスバ抜けた頭脳陣でさえも、Ajax で失敗することがあったと推測しますが、そのような失敗については何一つ知らされていないのです。

純粋な Ajax/REST は歴史の浅いアーキテクチャー・スタイルです。JSP (JavaServer™ Pages) 技術や PHP などの確立された Web アプリケーション・スタイルに比べると、その実装はまだ困難です。次世代 Web のユーザー・エクスペリエンスを提供することが第一の要件であり、そして世界的な Web 開発チームが控えているのでない限り、初めは Google のような「大規模な Ajax」ではなく、Netflix のような「局所的 Ajax」を採用するほうが組織にとっては有利に事が運びます。

Ajax が目標達成にどのように貢献するかを査定する

自分のアプリケーションのニーズにとって、Ajax プログラミング・スタイルのどのような特性が魅力になっているか、考えてみてください。あなたの会社で求めているのは、応答性の優れた UI による生産性の向上ですか? 動的性能の点でもパーソナライズの点でも極めて優れていて、しかも拡張可能なアプリケーションをデプロイしたいのですか? 対象とするマーケットのカスタマーにとっては、「かっこよさ」が差別化の特徴となっているのですか? いずれも正当な理由ですが、それだけではありません。ポイントは、Ajax を採用せざるを得ない理由を明確に説明できるかということです。Ajax が得意とするのは、以下の 3 つです。

  • 応答性に優れた UI。従来のサーバー・サイド Web アプリケーションでは、サーバーとの対話にはページの更新が必要なため、2 秒から 5 秒の遅れでページが完全に再描画されるというわずらわしさがあります。Ajax では、ユーザーは「応答不要送信」対話方式でサーバーと対話できます。つまり、ユーザーが操作を行うとシステムがバックグラウンドで処理するため、その間にユーザーは別の作業を続けることができます。また、UI は常にページ全体を再描画するのではなく、新しい情報を表示する領域だけを更新します。うまくすると、Ajax スタイルの UI を使ってユーザーがフローを実現して管理することもできるので、ユーザーの満足度と生産性の両方が向上することになります。
  • 見映え。アプリケーションと製品を客観的に見ると、必要な機能を満たす優れた製品というだけではもはや十分ではありません。ユーザーには非常にたくさんの選択肢があります。必要なのは、ユーザーの注目を集めて心を虜にする製品です。俗に言うように、見掛けもひとつの特徴です。何も、開発者が想像できるあらゆる装飾を施せと言っているわけではありません。iPod を見てください。シンプルさを極めたデザインながらも、他の携帯音楽プレーヤーを 10 倍もの数で圧倒しています。重要なのは、洗練されたデザインで、ユーザーが必要なことを快適に楽しく実行できるようにする、きめ細やかな機能を搭載するということです。
    Gmail はその良い例です。表面的には 10 年来の既存の Web ベースの E メール・アプリケーションと変わりありません。ところが Gmail では、Ajax を使用して細かなところまで配慮しています。ブラウザーを誤って閉じてしまったために、まだ送信していない長い E メール・メッセージを失くしてしまった経験はありせんか。Gmail 開発者チームはこのようなケースに配慮し、Gmail では 1 分毎に未送信のメッセージを下書きフォルダーに自動保存します。また、常に使っている E メール・アドレスを検索するのが面倒だと思ったことはありませんか。Gmail 開発者チームはこの点についても考慮して、過去に送信した E メール・アドレスに基づくアドレス・コンプリーション・メカニズムを提供しています。
    外部アプリケーションや商用アプリケーションにとっては、多くの場合、見映えが重要になりますが、内部ビジネス・アプリケーションにとってはそれほど重要ではありません。すべては状況次第ということです。
  • スケーラビリティーを犠牲にしないパーソナライズ。過去 15 年間で、従来のサーバー・サイド Web アプリケーションが一層動的でパーソナライズ化したものになるに従い、開発者とミドルウェアはますます多くのセッション状態をサーバー側に保管するようになっています。この手法はパーソナライズ化を実現する一方、スケーラビリティーを犠牲にします。第 1 回の記事で説明したように、Ajax アプリケーションではセッション状態をクライアント側に保管し、サーバーとの対話にはステートレス・サービスを使用する傾向があるため、スケーラビリティーを犠牲にすることなく、極めて動的でパーソナライズされた Web アプリケーションを実現できます。

決断を下す

以上の 3 つの利点は、組織の成功に役立つと思いますか? そうでない場合、Ajax の別の特有の利点が組織の成功に貢献する見込みがありますか? Ajax をどうしても利用しなければならない具体的な理由がないのであれば、その理由が見つかるまで Ajax は棚上げにしておくことをお勧めします。やむを得ない理由があるとしたら、続きを読んでください。


Ajax で成功する方法

Ajax でなければ組織にもたらすことができない価値があり、それが新しい技術に伴うリスクの増大を正当化すると判断したら、このセクションを読んで、Ajax の技術と手法をアプリケーションおよびソフトウェア開発プロセスに上手く組み込む方法を理解してください。「大規模な Ajax」を開発する場合に特有の考慮事項については、次のセクションで説明します。

小規模なものから始めて経験を積み、自信をつける

新しいものに下手に手を出して派手に失敗するプロジェクトほど、有益な新興技術を急速に衰えさせるものはありません。通常、スキルが十分にないのに多くのことを時期尚早にやろうとすると、このような結果になります。けれども今の時点では、非凡な Ajax 開発の経験を持つ開発者を見つけるのは困難です。この技術はとにかく新しすぎるからです。

この問題に対処するには、開発組織が Ajax の経験を積むことに目を向け、Ajax を実際のプロジェクト、ただしあまり重要ではない機能に実装するという作業を実践する必要があります。何か小さなものを実際の世界に迅速にデプロイすることに専念してください。そして失敗から学んでください。あまりにも早いうちから大きなものに取り掛かると、プロジェクトに大きなリスクを招くことになります。そして、規模が大きくなればなるほど、設計/開発/テスト/デプロイメントのサイクル全体をこなす時間が長くなります。このサイクルこそが、実世界での実際的経験を積む鍵なのです。

このアドバイスは主に、「局所的 Ajax」に取り組む組織に当てはまりますが、「大規模な Ajax」の場合でも、小さな規模から始めて開発を繰り返し重ねるという方法を採ることができます。これについては、「大規模な Ajax」の場合の特別な考慮事項で説明します。

UI に適任の人材、そしてサービスに適任の人材を見つける

過去 10 年間に渡って PHP、Java、あるいは .NET のサーバー・サイド Web アプリケーションを提供してきた Web 開発者のチームなら、専門的な Ajax 開発者に転向するのもわけないと考えがちですが、そう簡単にはいきません。同じ Web 開発の世界であっても、Ajax アーキテクチャー・スタイルとそれをサポートする技術では、いずれも、開発者が古い概念を捨て、新しい様式とパターンを学ぶ必要があります。つまり、転向は可能ですが、時間がかかります。

従来のサーバー・サイド Web 開発では、リンクのクリックとフォームのサブミットを処理し、完全な HTML ページで応答します。ワークフローが多数のページにまたがることも珍しくありません。そのため、サーバー側のアプリケーション・ロジックが、ブラウザーとの会話を維持しなければなりません。サーバーはクリックごとにアプリケーション全体の状態を記憶して、ユーザーが Web アプリケーションと対話する間、一見したところシームレスなワークフローを提供できるようにします。Ajax の世界では、この「グリーン・スクリーン」モデルを排除し、本物のクライアント・サーバー・モデルに移行します。このモデルでは、クライアントはステートフルかつ動的であり、サーバーの仕事は最小単位のステートレスなサービスを提供することだけです。このような新しいプログラミング・スタイルでは、クライアント側とサーバー側の両方でまた違った種類のスキルが必要となります。

クライアント側で必要なのは、CSS、JavaScript、DOM (Document Object Model) プログラミングを得意とする人材です。ここで問題となるのは、ほとんどの開発組織では「JavaScript と CSS の経験がある」とは言いますが、一般的にこの言葉はテキストの修飾やクライアント側のフォーム検証といったありきたりな機能を指しているという点です。このような平凡な JavaScript/CSS の経験を持つサーバー側の Web 開発者に大規模な Ajax アプリケーションに取り組む資格があると考えるのは、自動車を運転できるという人にデイトナ 500 でのレース資格があると考えるのと同じことです。

これもまた、小規模なものから始めることが重要である理由です。Web 開発者のスキルと経験は、現時点では Gmail 格の Ajax アプリケーションを作成するまでのレベルに達していないかもしれませんが、既存のサーバー・サイド Web アプリケーションを基本にした小規模で現実的なものを実現する能力はあるはずです。時間と経験を積むことによって、徐々に Ajax を使用した一層高度なシナリオを実装できるようになります。

サーバー側では Ajax は転換を表します。Ajax により、サーバー上でセッションとワークフロー状態を管理するという気のそそられない作業を排除できるからです。「ステートフル・クライアント/ステートレス・サーバー」という Ajax スタイルは、一度経験すれば理解するのも管理するのも非常に簡単ですが、このようなアーキテクチャー・スタイルの変更には新しいスキルが必要となります。サービス開発者には、HTTP プロトコルについての十分な理解、REST アーキテクチャー・スタイルの知識、そしてリモート・メソッド呼び出し (RMI) やリモート・プロシージャー呼び出し (RPC) などの分散サービスの開発経験が必須です。REST アーキテクチャー・スタイルには RPC とは基本的に異なる点がいくつかありますが、機能以外で関連する原則 (ボーダーでのセキュリティー、ネットワーク遅延、非信頼性) は引き継がれます。

フレームワークを使用する

DOM、CSS、および XMLHttpRequest (XHR) の「標準」は、ブラウザーによって大幅に異なります。開発者が既存のフレームワークでこれらの違いを解決しようとしない場合、ブラウザー間の不一致を標準化するために独自のコードを作成するという予定外のサイクルに多くの時間を費やすことになります。このようなコードが、今日利用可能なフレームワークがすでに達成している品質レベルにまで達するには、長い時間がかかります。有望なフレームワークの 1 つとして、オープン・ソースの Dojo ツールキットが挙げられます (「参考文献」を参照)。

ツールを習得して使用する

Ajax アプリケーションの開発には、2 つの異なる作業が伴います。1 つは、HTML/JavaScript/CSS/DOM による UI とアプリケーション・ロジックの実装、そしてもう 1 つは PHP、J2EE、.NET などの確立したサーバー・サイド・プラットフォームによるサービス・ロジックの実装です。サーバー側では、今まで使っていたツールを使用できます。クライアント側では、新しいツールを見つけてその使用方法を習得しなければなりません。サポートするブラウザーによって、必要となる Ajax ツールセットもおそらく変わってきます。以下に、一般的なツールの機能をリストします (「参考文献」に、もっとも人気の高い 2 つの Web ブラウザー、Microsoft Internet Explorer および Mozilla Firefox をサポートする一部のツールのリンクを記載しています)。

1 つの難関

J2EE または .NET のバックグラウンドを持つ開発者にとって共通の難関は、JavaScript プログラミング言語のコード・コンプリーション機能が未完成の状態だということです。これは、JavaScript では動的に入力されるということ、そして JavaScript のユーザー数が少ないという歴史的な背景により、コード・コンプリーション技術の市場がなかったことが原因となっています。コード・コンプリーションは Aptana などのツールによって改良されているところですが、Eclipse Java 開発者や Visual Studio C# 開発者が使い慣れたものになるまでには長い道のりがあります。

  • コードの作成: エディターと IDE。クライアント側の Ajax 開発では、HTML、CSS、および JavaScript ファイルを組み合わせて作成します。コード・エディターは、構文の強調表示機能、構文エラー検出機能、そしてコード・コンプリーション技術を提供して生産性を向上させます。
  • 構造の検査: DOM インスペクター。Ajax Web ページの視覚的な構造の大部分は、ユーザーによるページ操作に応じて動的に作成されるため、ページのライブ構造を調べるには、ただ単にソースを見ているだけでは不十分です。ソースは表示中の UI とは似ても似つかない可能性があります。そのため、ページを操作しながら DOM 構造を検査しなければなりません。DOM インスペクターを補完する優れた機能は「ライブ・ソース」ビューアーで、これは DOM の現在の状態を解析して HTML ソース・コードの形にし、HTML ソースを見慣れた開発者がページ・コンテンツを直観的に理解できるようにします。
  • 動作の検査: JavaScript デバッガー。開発者がフォームを検証したり、簡単な双方向性の機能を提供したりするために JavaScript による小規模なスクリプトを作成する際には、単純なアラート・ステートメントで問題のトラブルシューティングを行うことができます。ただし、大規模な Ajax 開発に飛躍する場合は、サポートする Web ブラウザーごとに JavaScript デバッガーを見つけて習得する必要があります。
  • クライアントとサーバーとの対話の検査: XHR モニター。Ajax ツールボックスに重要な最後のツールは、XmlHttpRequest (XHR) モニターです。XHR は JavaScript オブジェクトで、サーバーとの Ajax スタイルのリモート通信を可能にします。XHR モニターでは、ヘッダーとコンテンツを含め、要求/応答のペアーをモニターできます。

現実的な環境でテストする

単体テストについて

ツールとアジャイル手法が開発技術の最先端になっている今日、Ajax 構図のどこに単体テストが適合するのか疑問に思っている方もいることでしょう。この記事を書いている時点では、Ajax に有力な単体テストのフレームワークはありません。むしろそれぞれのフレームワーク (Dojo や Scriptaculous など) が、固有の最適化した単体テストのフレームワークを持つ傾向があります。Michael Mahemoff 著「Ajax Design Patterns」(「参考文献」を参照) の第 19 章では、2006 年頃の単体テストの動向を要約し、さまざまな Ajax フレームワークの単体テスト機能について説明しています。

今までにもよく書かれていますが、開発者側の特別な努力なくしては、Ajax は Web サイトの基本的な期待を裏切ることになります。例えば、Back ボタン、ブックマーク、ブラウザーの「ロード中」コントロールが機能しないといったようなことです。ここでも、「小規模なものから始める」という私のアドバイスが役に立ちます。ページの状態は更新する一方、ナビゲーションやワークフローには影響しない新しい機能を段階的に実装するためだけに Ajax を使用する限り、Back ボタンやブックマークは問題になりません。ただし、ロードの時間は問題になる可能性があります。特に、ネットワーク遅延が大きな要素ではないローカル開発環境でだけテストすると、この問題が顕著になることがあります。

次のことを考えてみてください。従来の Web アプリケーションでは、ユーザーがリンクをクリックしたりフォームをサブミットすると、後続のページをロードするのに 10 秒かかるとしても、すぐにブラウザーの「ロード中」コントロールからのフィードバックが表示されます。一方 Ajax アプリケーションでは、XHR 要求をトリガーするコントロールをクリックしても、「ロード中」コントロールはアクティブになりません。ローカル開発環境でのみテストする場合の危険性は、HTTP 要求、応答、そしてそれに続く UI 更新は瞬間的に行われるように見えるため、ブラウザーによる「ロード中」のフィードバックがなくても問題ではないように思ってしまうことです。ところが、ユーザーがサーバーから数百マイルあるいは数千マイルも離れている可能性がある実動環境では、このようにフィードバックがないと、混乱と苛立ちを招く可能性があります。ユーザーはコントロールをクリックしたかどうか不安になり、もう一度クリックしてみたところ、やはり何も起こらないという状況になるからです。

残念なことに、どんなに優れたエンジニアリングをもってしても、ネットワーク遅延はなくなりません。ネットワーク遅延は受け入れざるを得ないのです。ユーザーがクリックしてからサーバーの応答が到着するまでには時間差があることを前提として、ユーザーがリモート呼び出しを開始するという意思表示をしたら、その意思表示を受け取ったというフィードバックを瞬時に提供してください。例えば、一時的にコントロールを無効にしたり、あるいは何らかの動作が行われているというメッセージを表示し、そのメッセージをサーバーの応答を受信して UI を更新するためのものを入手するまで表示したままにします。ネットワーク呼び出しはボトルネックです。つまり、実行に著しく時間がかかる JavaScript コードを作成するのは困難です。

重要なポイントは、現実的な環境でテストするということです。現実的な環境では、このような使い勝手の問題に簡単に気付くことができます。問題を捉えるのが早ければ早いほど、初期段階で適切に対処することができます。

現実的な環境でのテストのもう 1 つの側面は、サポートするブラウザーのタイプとバージョンごとに各機能テストを確実に実行するということです。例えば、Firefox 1.5 および 2.0 と Internet Explorer 6 および 7 をサポートしようとしている場合は、これらのすべてのブラウザーで常にテストする必要があります。当たり前のように思えるかもしれませんが、開発者は好みのブラウザーでだけ開発とテストを行い、別のブラウザーで後から問題が発覚した時点でコードを書き直す必要に迫られるという悪い傾向に陥りがちだからです。


「大規模な Ajax」の場合の特別な考慮事項

Gmail や Google Maps のような大掛かりな Ajax アプリケーションは作成しないように勧めましたが、ビジネスの要素またはエンジニアリングの虚勢によりやむを得ない場合もあります。私としてはまず、「それは止めておきなさい。小規模なものから始めて経験を積んでください」と言いますが、それでも大規模な Ajax のみによるアプリケーションを今すぐ構築するというのなら、次のセクションを引き続き読んでください。

すべては人材次第

「大規模な Ajax」では、開発チームがなおさら重要になってきます。実証されたアーキテクチャーを新しい技術で拡張するだけでなく、新しいアーキテクチャーに着手しようとしているからです。チームは、Ajax の経験がほとんどない状態で、主要な設計を決定しなければなりません。決定によっては、恐ろしく間違った方向に進む可能性もあります。

JavaScript/DOM および CSS の経験豊富な人材が必要になります。JavaScript に十分な経験を持つ人材が見つからない場合は、Perl、Python、Ruby などのスクリプト言語で経験豊富な開発者を探してください。Lisp または Scheme などの関数型言語の経験は大きなプラスになりますが、経験豊富な Lisp/Scheme プログラマーは経験豊富な JavaScript プログラマーに比べ数が限られています。

アプリケーションの品質においては、優れた CSS の重要性を過小評価してはなりません。CSS を十分に理解している人材がいないと、コードが必要以上に厄介で管理しにくくなり、最初と 2 回目の書き直しが一層難しくなります。

「書き直し」と言いましたか?

少なくとも 2 回の書き直しを計画する

白紙から開発に取り組む場合は常に、最初に行った主要な設計の決定が正しいことはまれです。脆弱で不備のある設計を積み重ねていくか、あるいはアジャイルな方法を採って、機能するものとそうでないものについての知識と経験を習得しながら絶えず設計のリファクタリングを行うかのいずれかです。

Ajax のユーザー・エクスペリエンス、そして基礎となるアーキテクチャー・パターンはどちらも、サーバー側のものとは一見異なるため、Ajax は独特の課題を突きつけます。おそらく、UI にはわずかながらもなかなか消えない欠点があることに気付くことでしょう。Back ボタンがユーザーの期待通りに動作しない、ユーザーがリモート操作を呼び出しても十分なフィードバックがないなどといった欠点です。残念ながら、このような問題に対するソリューションの設計は、問題を実際に経験し、修復するためにはどのように設計を変更しなければならないかを理解するまでは簡単には行きません。

アプリケーションを書き直すもう 1 つの理由は、JavaScript/DOM および CSS の経験を重ねるにつれ、コードを一層簡潔で読みやすく、管理しやすくする新しい様式とパターンが見えてくるからです。さらに、コードを作成するなかで、サード・パーティーのフレームワークに含めるほどには一般的ではないながらも、最上位レベルのコードに散りばめるより固有のライブラリーに含めるほうが適している共通の動作も分かってきます。新しいライブラリー・コードを使用するための古いコードのリファクタリングは、長い目で見ると効果をもたらしますが、時間も粘り強さも必要です。また、自分がだんだんフレームワークの分野に没頭していくことに気付くこともあります。これにも独自の一連の問題がありあす。

フレームワークの分野に没頭しないようにする

大規模なアプリケーションで作業を進めるなかで、多くの汎用アプリケーション・サービスは、必要最小限の JavaScript/DOM/CSS、あるいは Dojo や Prototype などの新しい Ajax フレームワークによって提供されていないことがわかります。そこで心をそそられるのは、独自のフレームワーク・レベルのコードを作成して、新しいアプリケーション・レベルの機能を簡単に作成できるようにすることです。これは必ずしも悪いことではありません。ほとんどの優れた開発フレームワーク (Ruby on Rails など) は、具体的なアプリケーションのニーズから生まれています。ただし、ここで気をつけなければならないのは、前にも言ったように局所的な Ajax は実現可能ですが、大規模な Ajax となると非常に難しく、その難しさは桁違いだということです。大規模な Ajax をサポートするフレームワーク・レベルの技術を設計するには、また別の桁違いの難しさがあり、Ajax 技術の新参者にとって、これはなおさらのことです。

フレームワークのコードは抽象化レベルと間接化レベルを増やすため、コード・パスを理解しにくくなります。十分な経験に基づく法則としては、できるだけ具体的なアプリケーション・レベルで取り組み、アプリケーションの 3 つ以上の部分で使用可能なサービスを提供するコードについては、そのコードをフレームワークまたは再利用可能なライブラリーに移すということだけを考えるのが得策です。

一に繰り返し、二にも三にも繰り返し

白紙からの開発で良くない構図の主たるものは、初期設計から現実の人間が使用してフィードバックを提供できる具体的な製品にするまでに時間をかけすぎることです。野心的な新しい Ajax アプリケーションでは、数週間のうちに基本的な部分を動作させ、実演できるようにして、早速フィードバックを得られるようにしなければなりません。UI は荒削りでコードは醜いかもしれませんが、開発に 6 ヶ月費やしてから、新規アプリケーションを人々に試してもらっても同じ結果になるはずです。その違いと言えば、断念するコードと UI が 10 倍になっているということだけです。

長い設計期間より短時間の繰り返しを優先させ、定期的に、実動条件をシミュレートした環境で実際のユーザーが製品を実験できるようにしてください。この手法のハイ・エンドの形態は、テスト・サーバーを用意し、ユーザーとプロジェクト・リーダーが実験できる新しいコードで数日ごとにサーバーを更新し、それについてのフィードバックを得ることです。


まとめ

Ajax 技術を採用する際の最大のリスクは、業界での実際的経験が乏しいということです。そのため私が推奨しているのは、小規模なものから始めて、プロジェクトに大きなリスクを与えることなく開発チームが経験と自信を培うようにできるようにするということです。現時点で Ajax のみでの開発に飛び込むならば、現実的に成功する見込みが低いという理解のもとで行ってください。世界有数の Web 開発チーム、そして繰り返しを重ねる開発と実験をサポートするような開発組織がなければ、失敗は目に見えています。

やがてより多くの実践者が経験を積み、フレームワーク、ツール、そしてベスト・プラクティスが現れるにつれ、難易度もリスクも低くなっていくはずです。Ajax はエキサイティングとは言えないまでも、一層安全でより日常的になることでしょう。

謝辞

この記事について意見を交換し、感想を寄せてくれた Rational の同僚、Erich Gamma 氏、Grady Booch 氏、Josh Staiger 氏、Pat Mueller 氏、そして Scott Rich 氏に感謝します。

参考文献

学ぶために

  • 「Ajax と REST、第 1 回」(Bill Higgins 著、 developerWorks、2006年10月): 没入型 Web アプリケーションでの Ajax/REST アーキテクチャー・スタイルの利点について説明しています。
  • 「Debug JavaScript in Internet Explorer」: Microsoft Office にアドオンとして付属する Microsoft Script Editor のハウツー情報が記載されています。
  • 『Ajax Design Patterns』 (Michael Mahemoff 著、O'Reilly、2006 年): Mahemoff' の Ajax のテストに関する章は、2006 年の Ajax 単体テストの動向についてわかりやすくまとめています。
  • 著者のブログを読んでください。
  • Ajax Resource Center: developerWorks の Ajax に関するすべての記事が記載されています。

製品や技術を入手するために

  • Dojo Toolkit: Dojo はオープン・ソース Ajax フレームワークで、モジュール管理、イベント処理、リモート通信に役立つライブラリーが備わっています。Dojo は、カスタム・バージョンの Ajax コードを簡単にビルドしてデプロイできるシステムと、必要な Dojo のパーツだけをパッケージしています。
  • Aptana: Aptana はオープン・ソースの JavaScript に重点を置いた IDE で、複数のプラットフォームに対応したバージョンが用意されています。
  • Eclipse Ajax Toolkit Framework (ATF): ATF は、DOM インスペクター、XHR モニター、そして「ライブ・ソース表示」機能を含め、統合 Ajax ツールキットを提供します。
  • FireBug: FireBug は Firefox を統合して、エラー・コンソール、DOM インスペクター、XHR モニターを提供します。「ライブ・ソース表示」機能も組み込まれています。
  • Venkman Debugger: Firefox 対応の JavaScript デバッガーです。
  • Internet Explorer Developer Toolbar: IE 対応の DOM インスペクターおよびその他のツールです。
  • LiveHTTPHeaders および TamperData: Firefox/Mozilla 対応の XHR モニターです。
  • Fiddler および HTTP Analyzer: Internet Explorer 対応の XHR モニターです。

議論するために

コメント

developerWorks: サイン・イン

必須フィールドは(*)で示されます。


IBM ID が必要ですか?
IBM IDをお忘れですか?


パスワードをお忘れですか?
パスワードの変更

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


お客様が developerWorks に初めてサインインすると、お客様のプロフィールが作成されます。会社名を非表示とする選択を行わない限り、プロフィール内の情報(名前、国/地域や会社名)は公開され、投稿するコンテンツと一緒に表示されますが、いつでもこれらの情報を更新できます。

送信されたすべての情報は安全です。

ディスプレイ・ネームを選択してください



developerWorks に初めてサインインするとプロフィールが作成されますので、その際にディスプレイ・ネームを選択する必要があります。ディスプレイ・ネームは、お客様が developerWorks に投稿するコンテンツと一緒に表示されます。

ディスプレイ・ネームは、3文字から31文字の範囲で指定し、かつ developerWorks コミュニティーでユニークである必要があります。また、プライバシー上の理由でお客様の電子メール・アドレスは使用しないでください。

必須フィールドは(*)で示されます。

3文字から31文字の範囲で指定し

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


送信されたすべての情報は安全です。


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=Web development, Java technology
ArticleID=237345
ArticleTitle=Ajax と REST、第 2 回
publish-date=11142006