今日のエンタープライズ・アプリケーション開発者は、ユーザー・インターフェースに関してユーザーと運用側の両方の陣営から圧力を感じています。ユーザーというビジネス単位は、ユーザー生産性を最大にする機能豊富なユーザー・インターフェースをアプリケーションに求めています。このグループは、すべてのアプリケーションが Microsoft の Excel のようなクライアント常駐アプリケーションのように動作することを望んでいます。すなわち、アプリケーションが即時に応答することを希望しています。例えば、同じデータを表す複数のビュー (テーブルとグラフ・ビューなど) があり、その 1 つが変更されたとします。この場合、このグループは、表示されているもう一方のビューでも即時に変更内容が反映されることを望みます。

一方、IT 運用グループは、純粋なサーバー・ベースの配信モデルを好みます。このグループは、HTML ユーザー・エクスペリエンスがネイティブのオペレーティング・システム (OS) ベースのユーザー・インターフェースほど堅牢ではないことを認めつつも、改良したユーザー・エクスペリエンスを提供するとなると、クライアント常駐コードのインストール、構成、および管理のコストが高くなりすぎると考えています。

IT 組織にいる人の多くは、1990 年代のクライアント/サーバー・デプロイメント・モデルを経験していて、再びその経験を繰り返したくないと考えています。実際、コストがアプリケーションの投資対効果に見合わなかったため、多くの Java 2 Enterprise Edition (Java EE) アプリケーションは、クライアント常駐コンポーネントがある場合はビルドされませんでした。IT 組織は、サーバー配信デプロイメント・モデルを使用することで、希望する内容のものをコスト効率の良い方法で入手することになります。これは、1990 年代に夢に見ていたことです。サーバー・デプロイ Java EE アプリケーションの経済的側面を経験してきた多くの組織は、強制的にインストールされない限り、自分たちで個々のクライアント・マシンにインストールしなければならないコードをデプロイすることは考えもしないでしょう。

それでは、経験の少ない企業向け開発者はどうすればいいのでしょう? ユーザーは、サーバーの応答を何秒も待ったりして生産性を下げるようなことはしたくないと考えています。一方、IT グループは、クライアント・マシンにコードをデプロイして管理するような以前の方法に戻りたくないと考えています。このように一見すると対立する要求に対して、双方の組織を満足させる方法で対処するにはどうすればいいのでしょうか?

幸いなことに、クライアント・マシンに手動でコードをインストールすることなく、ブラウザー以上のユーザー・エクスペリエンスを提供できるテクノロジーが存在します。このテクノロジーを使用してビルドされたアプリケーションは Web 2.0 アプリケーションと呼ばれることがあります。Tim O'Reilly の記事「Web 2.0：次世代ソフトウェアのデザインパターンとビジネスモデル」(「参考文献」を参照) では、次のように述べられています。

我々は、前例のないユーザー・インターフェース革新の時代に突入しようとしている。いずれ、Web 開発者は、ローカル PC ベースのアプリケーションと同等の Web アプリケーションをビルドできるようになる。

Web 2.0 アプリケーションからは、ユーザーと IT グループの双方に最適なデプロイメント・モデルが提供されます。これは、コスト効率の良いサーバー・ベースのデプロイメント・モデルで、豊かなユーザー・エクスペリエンスが組み合わされます。このユーザー・エクスペリエンスは、クライアント常駐アプリケーションを使用するときの多くのユーザー・エクスペリエンスと比較してもひけをとりません。

今日の Java EE アプリケーションの強力なユーザー・エクスペリエンスを作成するためのさまざまなテクノロジー・オプションを以下に示します。

• Flex および OpenLaszlo
• IBM® Workplace™ Managed Client および IBM Lotus® Expeditor
• Faces Client Components
• Ajax
• HTML

Flex および OpenLaszlo

Flex および OpenLaszlo はどちらも、良く似た宣言型アプローチで、Java EE アプリケーションのインターフェースをブラウザー以上のインターフェースとして作成するために使用されます。Flex は、Adobe/Macromedia から提供される製品オファリングです。OpenLaszlo は、元は Laszlo Systems Inc. で作成されたオープン・ソース・オファリングです。いずれの環境でも、テクノロジー固有であり XML ベースでもある独自の文法を使用して、ユーザー・インターフェースをレイアウトし、作成します。

例えば、Flex でボタンを使用するには、MXML (Multimedia XML) で <a name="code-text"><mx:Button label="Submit"</mx:Button></a> のようにコーディングできます。

OpenLaszlo を使用する場合は、LZX (LasZlo XML) で <a name="code-text"><button<Submit</ button></a> のようにコーディングできます。

さまざまな UI エレメントを使ってサーバーと対話したり、通信したりできるようにするには、ActionScript (Flex) や JavaScript (OpenLaszlo) を使用してスクリプトを作成します。

これら 2 つのテクノロジーには、多くの共通点がありますが、相違点もあります。主要な相違点の 1 つは、これらのテクノロジーが要求するランタイム・インフラストラクチャーです。クライアントがサーバーとデータを交換する場合、Flex では Flex Data Services サーバーが必要となります。このサーバーは、Flash Player のプラグインで実行されているクライアントと通信します。基本的に、このサーバーは、クライアントからアプリケーションのサーバー・コンポーネントへのすべての通信とデータ交換の際に、メディエーション・サーバーとして機能します。

OpenLaszlo の最新版では、ランタイムが多少変更されています。この変更は、開発者にとって魅力的なものになるかもしれません。変更の 1 つは、バージョン 3 で導入された SOLO デプロイメント・モードです。これにより、一部のデプロイメント構成では Laszlo Presentation Server が必要でなくなります。新たに開発されたもう 1 つの主要な機能は、クライアント・ランタイム環境です。最新のリリース OpenLazlo 4 (現在はベータ版) では、Laszlo ベースのアプリケーションを Adobe/Macromedia Flash Player プラグインなしで実行できます。Flash Player のような独自仕様のプラグインの使用を余儀なくされることに懸念を抱いている多くの企業は、この変更を歓迎することでしょう。

あなたの組織ではどちらが良いかをどのようにして決めますか? Flex の主な利点は、Adobe/Macromedia の完全なサポートが付いた製品であることです。ただし、Flex Data Services サーバーのライセンス・コストを負担することになります。企業によっては、そのライセンス・コストは、完全にサポートされた製品を所有する場合に十分見合うものです。Adobe Flex 2 アプリケーションの場合も、Flash Player プラグイン V9 が必要です。Flex では強力なユーザー・エクスペリエンスを作成できますが、企業によってはコストやこのプラグインの要件が問題となることがあります。

OpenLaszlo テクノロジーは、元々、商品としてリリースされましたが、2004年に Laszlo Systems はこのテクノロジーをオープン・ソースにして、Common Public License (V1.0) の下にライセンス供与することを決定しました。Laszlo Systems はサポート・サブスクリプションを提供しますが、これはオープン・ソース・プロジェクトであるため、ユーザーは、自由に使用できるソースからこのテクノロジーをサポートできます。OpenLaszlo の場合、コストは明らかに問題ではありませんが、一部の企業では、オープン・ソース・ソフトウェアの使用に対して必要以上に確固としたポリシーを持っているため、OpenLaszlo が選択対象にならない場合があります。

上に戻る

IBM Workplace Managed Client および Lotus Expeditor

IBM Workplace Managed Client および Lotus Expeditor はどちらも、オープン・ソース EclipseRPC コード・ベースに基づいてビルドされています。EclipseRPC は Eclipse 開発ツール・ワークベンチから派生したテクノロジー・ベースです。このワークベンチは、eclipse.org で管理している開発ツールの共通プラットフォームです。サーバーに接続しない運用に対するビジネス要件があり、クライアント・マシンにコンポーネントをインストールできる場合は、Workplace Managed Client および/または Lotus Expeditor が、アプリケーションをビルドおよびデプロイするときの最高のテクノロジーとなります。

IBM Workplace Managed Client は IBM の Workplace 製品ファミリーのコンポーネントです。IBM Workplace Managed Client は、さまざまなコラボレーション・サービスを 1 つの統合フレームワークまたは 1 つのデスクトップ環境の下に組み合わせます。機能としては、文書管理、メッセージング (インスタント・メッセージを含む)、Web ブラウジング、Notes® 7 に直結するインターフェース、e-Learning、チーム・スペース、Web 会議、そして作業タスクに関連するスレッドをトラッキングするためのアクティビティー・エクスプローラーなどがあります。Lotus Expeditor にはリッチ・クライアント・プラットフォームが備わっていて、エンタープライズ・アプリケーション、トランザクション、装置管理、および Web サービスがサポートされます。Workplace Managed Client や Lotus Expeditor を選択する理由はさまざまですが、使用しているアプリケーションが実際にコラボレーション・アプリケーションである場合は、一般に Workplace Managed Client は最良の選択です。一方で、トランザクション・アプリケーションにより近い場合は、通常は Lotus Expeditor をお勧めします。

開発者は、Workplace Managed Client と Lotus Expeditor のいずれを使用しても、クライアント・マシンに常駐するリッチ・クライアント・アプリケーションを作成したり、サーバーに接続しない運用をサポートするようにそのリッチ・クライアント・アプリケーションを開発したりできます。このようなアプリケーションはクライアント常駐型ですので、実行先のワークステーションの能力を完全に利用できます。これにより、強力で高度に対話型のユーザー・エクスペリエンスを作成できます。Workplace Managed Client と Lotus Expeditor の両方のオファリングが共用する Eclipse ベースには、OS に依存しないプラットフォームが用意されていて、OS 固有の微妙な違いが解消されます。それにもかかわらず、可能な限り、ネイティブの OS サービスを利用するようにもなっています。これにより、Linux™ と Windows™ の両方で (将来的には Macintosh でも) 実行される単一の Java コード・ベースを開発できます。

このテクノロジーを活用するには、Eclipse プラグイン・アーキテクチャーを利用するようにアプリケーションを設計する必要があります。ユーザー・インターフェース・コンポーネントのビルドには、SWT (Standard Widget Toolkit) ウィジェットまたは jFace コンポーネントを使用します。SWT は、ネイティブのウィンドウ・システム (ただし、OS に依存しない API) に統合されたウィジェット・セットおよびグラフィックス・ライブラリーです。jFace は、SWT を使用して実装された UI ツールキットです。このツールキットを使用することで、多くの共通 UI プログラミング・タスクが単純化されます。また jFace は、API においても実装においてもウィンドウ・システムに依存せず、SWT を隠さずに SWT と連動するように設計されています。最終的な結果として、より高度な対話式のユーザー・エクスペリエンスが作成されます。そのルック・アンド・フィールは、ユーザーになじみのある他のネイティブの OS アプリケーションに似たものとなります。

結論を述べると、Workplace Managed Client ベースのアプリケーションや Lotus Expeditor ベースのアプリケーションは、サーバーで管理できるという点でネイティブの Windows アプリケーションと異なります。この主要な特徴により、クライアント常駐アプリケーション・コードに関連するシステム管理コストの大部分 (すべてではない) が削減されます。その結果、アプリケーションをデプロイする企業は、サーバー・デプロイ Java EE アプリケーションのすべての所有権益を得ることになります。一方、ユーザーは、OS 固有のクライアント常駐アプリケーションのユーザー・エクスペリエンスを享受することになります。つまり多くの企業や組織にとって互いにメリットのある結果となるのです。

上に戻る

Faces Client コンポーネント

JavaServer Faces (JSF) は、元は JSR 127 として開発された Java EE 1.4 コンポーネントです。このテクノロジーの主な目標は、Java EE アプリケーションのユーザー・インターフェースを開発するときに Java 開発者に求められるスキル・レベルを下げることでした。JSF はフレームワークであるため、すぐに使用できる多くの機能が備わっています。それまでは、開発者は、ユーザー・インターフェースをビルドするときに、JavaServer Page (JSP) を使用して手動でコーティングする必要がありました。

例えば、ユーザーに表示しなければならない大きな JDBC™ 結果セットがあるとします。JSF フレームワークには DataTable ウィジェットが備わっていて、これを使用することによりデータを表示できます。単純な JSP を使用してユーザー・インターフェースをビルドすると、ユーザーによるテーブルの操作を管理したり、ユーザーに表示すべきデータの行を決定したりしなければならなくなります。

JSF DataTable を使用すれば、ユーザーが「次へ (Next)」を押してテーブルにあるデータの次の x 行を表示するとき、JSF フレームワークで「次へ (Next)」の要求が処理され、独自にコーディングしなければならないものはありません。JSF により、より機能豊富な HTML ベースのユーザー・インターフェースをより簡単に作成できるようになりますが、JSF は、その設計上、サーバー・ベースのテクノロジーです。データの次の x 行を要求した場合、その要求はブラウザーからサーバーに送られ、サーバーで JSF フレームワークのコードにより、要求が処理されます。JSF の場合、サーバーとの間で 1 往復分のやりとりが必要となります。

ベースとなる JSF ウィジェットを改良するために、IBM's Rational® Application Developer V6 には、Faces Client コンポーネントが導入されました。Faces Client コンポーネントは、JavaServer Faces テクノロジーに対する拡張機能です。この拡張機能により、クライアント・サイドでいくつかの JSF フレームワーク・サービスを実行できます。例えば、上の例で Faces Client コンポーネントの DataGridを使用した場合、データの次の x 行を表示するときに、サーバーとの間の 1 往復分のやりとりは不要となります。

Faces Client コンポーネントは、Rational Application Developer JSF 開発者にも必然的に使用されるようになると考えられます。Faces Client コンポーネントを使用するには、Faces JSP ページを作成し、モデルとして「基本 (クライアント・サイド・データ・キャッシング使用) (Basic with client-side data caching)」を選択します。その際、Rational Application Developer でユーザー・インターフェースを作成する場合は、単に Rational Application Developer のツール・パレットにある Faces Client コンポーネントのドロワーから適切な UI コントロールを選択するだけです。

Faces Client コンポーネントの下では、さまざまな処理が行われます。ユーザーは、JSF コントロールの JavaScript 実装をブラウザーにダウンロードして、新たに業界標準となりつつある Service Data Objects を使用してブラウザーとサーバーとの間で通信します。ただし、元々、これらの処理はすべてユーザーからは隠されていて、ユーザーが気づくことといえば、アプリケーションの反応が通常のブラウザー・ベースのアプリケーションよりはるかに速いということくらいです。

上に戻る

Ajax

Ajax (Asynchronous JavaScript and XML) とは、Jesse James Garrett が作った言葉で、サーバーにデプロイされるアプリケーションに対してブラウザー以上のユーザー・エクスペリエンスを開発するための標準ベースの技法/設計パターンのことです。Ajax は、サーバー・テクノロジーにとらわれず、Java EE アプリケーションや .Net アプリケーションなどと連動できます。Ajax を使用すれば、標準の HTML を補強する JavaScript コードを作成し、機能豊富で対話型のユーザー・エクスペリエンスを作成することができます。例えば、このような JavaScript を使用することにより、ローカル・ユーザー入力を検証したり、同じデータをさまざまなビュー (折れ線グラフ、テーブル、円グラフなど) で表示したり、ブラウザーの XMLHTTPRequest オブジェクトを通してアプリケーションのサーバー・コンポーネントと非同期で対話したりできます。

Gartner Group の Hype Cycle for Emerging Technologies 2000 レポート (2006年7月18日) によれば、Ajax はすでに「過剰な期待のピーク (Peak of Inflated Expectations)」に達していて、「幻滅の谷 (Trough of Disillusionment)」に落ちつつあります。書店で売られている多くの Ajax の書籍を見ても、このハイプ・サイクルを判断できます。私見としては、3 つのことが、Geoffrey Moore が述べるテクノロジーのギャップに Ajax を押し込んだと考えています。

1. 最新のブラウザー。これまで、JavaScript を作成する開発者は、Netscape や Internet Explorer などのブラウザーにさまざまな点で互換性がないことに対処しなければなりませんでした。同じブラウザーでもバージョンが異なれば、互換性がないこともありました。まだ、一部に互換性がないものが残っていますが、多くのイントラネット・アプリケーションで通常要求される、Internet Explorer 5.5 以降、および/または Firefox 1.0 以降のブラウザーでは、これまでの非互換性の問題の多くが修正されています。最近になって、オープンな業界のコンソーシアム OpenAjax も設立され、Ajax との非互換性など、Ajax 関連の問題が扱われています。
2. Ajax ツールキット。これまで、Ajax を使用したいと思っていた開発者の多くは、実際には一から始めて、今なら Ajax ツールキットで行うことができるような多くの重労働を行う必要がありました。Ajax ツールキットには、事前にビルドされたさまざまな JavaScript ベースのユーザー・インターフェース・コントロール (ウィジェット) が用意されています。開発者は、このコントロールを使用することで、Ajax ベースのユーザー・エクスペリエンスをより簡単に作成できます。通常、Ajax ツールキットでは、より高レベルの抽象化が使用されていて、開発者は上述のブラウザーの非互換性を考慮する必要がありません。
3. ツール。最近まで、多くの JavaScript 開発者には、デバッグを支援したり、作業を軽減したりするような開発ツールが実質的に存在していませんでした。Firefox ブラウザーがリリースされてからは、Ajax 開発者向けの有用なプラグインが Firefox ブラウザー向けに作成されたり、最近になって IBM が上記の問題を解消するために一連の有用なテクノロジーを Ajax Toolkit Framework (Ajax) に統合したりしました。ATF は、Apache のサイトから自由にダウンロードでき、そこには Eclipse ベースの Ajax 開発環境が備わっています。また ATF には、JavaScript 構文依存型エディター、JavaScript コンソール、XMLHTTPRequest オブジェクト・ビューアーなどのツールが用意されていて、さらに、事前にビルドされた 3 つのパーソナリティー (Dojo、Zimbra、および Rico) も付属しています。

最後に、私見ですが、Ajax に関するヒントを本当に享受できるようになったのは、Google が Ajax ベースの Google Maps アプリケーションのベータ版をリリースしてからです。それまで Web 上の地図サイトを使用していたユーザーの誰もが、Google の地図ソフトウェアがインターネット上の他の地図サイトより優れている点にすぐに気づきました。技術的なことに詳しくない人は驚き、Google がどうやっているのかを不思議に思いましたが、裏で調べていたプログラマーは、Ajax の存在に気づき、自分のアプリケーションのユーザビリティーや反応性を改善するために Ajax ベースの技法をどのように活用できるかについてじっくり考え始めました。

上に戻る

純粋な HTML

開発者は、すべてのユーザーが自分と同様に最新の Firefox ブラウザーを使用していて、最も人気のある 10 個のプラグインをインストールしていると考えていますが、実際は、多くのマシンでインターネットへのアクセスに依然として Netscape 3.x や Internet Explorer 4.x が使用されています。このレベルのブラウザーは、特定のアプリケーション (ソースがなくなってしまい修正できないようなアプリケーション) を使用するために必要となることがあります。また、単に変更を好まないユーザーが自宅でこのレベルのブラウザーを使用している場合があります。このようなユーザーは「壊れていないものを直す必要はない」という考え方をブラウザーのアップグレードにも当てはめるため、Internet Explorer 4.0 を使用し続けたりします。

HTML では、ここで述べている HTML 以外のテクノロジーで実現できるユーザー・エクスペリエンスほど豊かなユーザー・エクスペリエンスを実現できませんが、HTML ベースのユーザー・インターフェースは、これからも長期にわたって存続し続けることでしょう。純粋な HTML ユーザー・インターフェースは、他のテクノロジーで作成されたアプリケーションよりも多くのユーザーに使用されています。結果的に、純粋な HTML ユーザー・インターフェースは、今後何年にもわたって多くのアプリケーションで使用され続けることでしょう。

上に戻る

まとめ

一般に、今日の業界では、サーバー配信アプリケーションのユーザー・エクスペリエンスを改良しようとする強い機運があります。Ajax はまだ多少未成熟でありながら、大きく勢いを増してきました。多くの企業は、その規模に関係なく、実稼働環境で Ajax を利用し始めています。ここで紹介した Ajax 以外のテクノロジーに関しては、個別の小さなグループがサポートを提供していますが、大本命と目されるグループが現れていないのが現状です。

ここで紹介したユーザー・インターフェース・テクノロジー以外にも、商用のユーザー・インターフェース・テクノロジーやオープン・ソースのユーザー・インターフェース・テクノロジー (Nexaweb、Backbase、JackBE など) が存在しますが、記事を適度に簡潔な内容にするためにここでは言及しませんでした。重要なのは、これらのテクノロジーが、それだけですべてに対応するものではないということです。したがって、これらのテクノロジーはいずれも、すべての状況に完全に適合することはありません。ここで紹介したいずれのテクノロジーにも独自のメリットがあり、それぞれが状況に応じてうまく適合します。

では、どうやって選択すればよいでしょう? 初心者の場合、テクノロジー選択の背景にある動機が、できる限り多くのユーザーに使用してもらうことであれば、古き良きテクノロジーである HTML が最適です。それとは正反対に、サーバーに接続しない運用が必要であり、アプリケーション・ソフトウェアをユーザーのマシンにインストールできる場合、EclipseRPC ベースの代替テクノロジーである Workplace Managed Client または Lotus Expeditor が最適です。

Flash Player を通してのみ配信できるような豊かなユーザー・エクスペリエンスが必要な場合は、Flex または OpenLaszlo の使用をお勧めします。JavaServer Faces を使用してアプリケーションをビルドする場合は、Faces Client Components を使用することが最も良い選択です。

結論として、目標が単に、既存の HTML ベースのユーザー・インターフェースにあるいくつかのユーザビリティー上の問題箇所に対処することだったり、標準ベースで、プラグインも使わず、ブラウザー以上のユーザー・エクスペリエンスを提供することだったりする場合は、Ajax が最適です。ハイプ・サイクルのこの段階で、Ajax は最も人気のある Web 2.0 テクノロジーの選択対象になると思います。ただし、Ajax 以外のテクノロジーが時間とともに成熟するにつれて果たす役割を軽視するわけではありません。

正しいテクノロジーを選択するときの鍵となるのは、アプリケーション要件に応じてユーザー・エクスペリエンスのテクノロジーを選択することです。これは、わかりきった基本的なアドバイスのように感じられますが、多くの場合、開発者はこれとは逆のプロセスに従います。その結果、多くの困難な実装の問題やデプロイメントの問題が発生する場合があります (それが原因で、プロジェクトの開発に重大な遅延や問題が発生することがあります)。このようなことが起こらないようにしてください。

参考文献

学ぶために

• 「Web 2.0：次世代ソフトウェアのデザインパターンとビジネスモデル」 (Tim O'Reilly, O'Reilly, 2005年9月) では、Web 2.0 の意味が解説されています。
  
  
• Workplace Managed Client では、豊かなユーザー・エクスペリエンスのために完全に統合されたサーバー管理のコラボレーションを行います。
  
  
• Lotus Expeditor では、装置やネットワークに対応するリッチ・クライアントおよびモバイル・アプリケーションをビルドしたり、デプロイしたり、保守したりします。また、プラットフォーム (OSGi および Eclipse ベースのサーバー管理クライアント・プラットフォーム、ツール、およびそれに対応するサーバー・サイド・コンポーネントが備わったプラットフォーム) と、リッチ・クライアント/モバイル・アプリケーションを統合します。
  
  
• Adobe Flex 2 では、Adobe Flash に基づく機能豊富なインターネット・アプリケーション・フレームワークで、ほとんどすべてのプラットフォームに対して拡張可能で優れたアプリケーションを作成します。
  
  
• OpenLaszlo では、オープン・ソース・プラットフォームのデスクトップ・クライアント・ソフトウェアのユーザー・インターフェース機能を使用してゼロ・インストール Web アプリケーションを作成します。
  
  
• 「Ajax: A New Approach to Web Applications」 (Jesse James Garrett, AdaptivePath, 2005年2月18日) では、Ajax moniker という言葉が作り出された記事 (これは、すべての Ajax 開発者が読むべきものと考えられている) を参照してください。
  
  
• OpenAjax では、OpenAjax Alliance、ベンダーの組織、オープン・ソース・プロジェクト、および Ajax を使用する企業 (オープンで相互運用可能な Ajax ベースの Web テクノロジーを積極的にうまく採用する企業) にアクセスします。
  
  
• JSR 127: JavaServer Faces: では、JSF アーキテクチャーおよび API を使用して Java サーバー・アプリケーションを作成および保守する作業を単純化します。
  
  
• 「Faces Client Components Developer's Guide」 (Laurent Hasson, developerWorks, 2005年5月) では、対話型 Web ページの開発を単純化して、そのユーザビリティーやパフォーマンスを向上させ、サーバーとの往復対話数を減らします。
  
  
• Ajax Toolkit Framework では、Eclipse Web Tools Incubator Project で Ajax Toolkit Framework (ATF) を試用します。ATF は、さまざまな Ajax ランタイム・オファリング (Dojo、Zimbra、Rico など) の IDE を構築するための拡張可能なフレームワークと典型的なツールのセットです。
  
  
• 「Enable C++ Applications for Web Services using XML-RPC」 (Karthik Subbian and Ramakrishnan Kannan, developerWorks, 2006年6月) では、C++ メソッドをサービスとして公開するためのステップバイステップのガイドを使用して、C++ プログラムのために独自の XML-RPC ベースのサービスを作成します。
  
  
• developerWorks の Architecture セクションでは、この分野でスキルを向上させる場合に必要な参考文献が解説されています。
  
  
• Web development zone では、Web 2.0、Ajax、wiki、PHP、マッシュアップなどの Web プロジェクトすべてのリソース・センターにアクセスします。
  
  
• technology bookstore では、ここで述べられているトピックやその他の技術トピックに関する書籍を参照します。
  
  
• developerWorks の Web development zone では、Web テクノロジーに特化した記事やチュートリアルを使用してサイト開発スキルを向上させます。
  
  
• developerWorks technical events and Webcasts で最新情報を入手してください
  
  

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

• IBM 製品評価版で、DB2®、Lotus®、Rational®、Tivoli®、および WebSphere® のアプリケーション開発ツールやミドルウェア製品を実際に使用してみてください。
  
  
• developerWorks RSS および Atom フィードで、詳細を調べて自分でビルドを行ってください。
  
  

議論するために

• developerWorks blogs から developerWorks コミュニティーに加わってください。
  
  
• developerWorks forums から、いくつかある Web 中心のフォーラムのいずれかに加わってください。
  
  

著者について

Sam Thompson は 1980 年に IBM に入社し、VM 製品開発でさまざまな技術職および管理職に就きました。1992 年、Sam は North Caroline 州 Raleigh にあるシステム管理開発研究所に移り、数々の SystemView 製品の商品化に貢献しました。SystemView が Tivoli Systems に合併されると、技術を伝えるために世界中を移動し、その合併、新しい Tivoli の戦略や製品、IBM と Tivoli のワークグループ製品の統合による戦略について説明して回りました。1997 年 3 月には、IBM の Emerging Technologies jStart (jump start) グループの立ち上げに貢献しました。このグループは、IBM のXML、Java、Web サービス、リッチ・クライアント、Web 2.0、およびオートノミック・コンピューティング・テクノロジーを利用するソリューションを IBM のお客様が設計し、構築するときに役立ちました。

この記事を評価する

コメント

上に戻る

目次

• Flex および OpenLaszlo
• IBM Workplace Managed Client および Lotus Expeditor
• Faces Client コンポーネント
• Ajax
• 純粋な HTML
• まとめ
• 参考文献
• 著者について
• コメント