レベル: 初級 Kevin Haverlock (kbh@us.ibm.com), Software Development, IBM
2008年 3月 18日 この記事では、IBM® WebSphere® Application Server Feature Pack for Web 2.0 を利用することによって、J2EE (Java™ 2 Platform, Enterprise Edition) アプリケーションを Ajax スタイルのアーキテクチャーでどのように強化できるのかを説明します。そして Web アプリケーション全体を再作成することなく、既存のアプリケーションに Ajax スタイルのアーキテクチャーを組み合わせる方法を学びましょう。またこの記事では IBM WebSphere Application Server 用の皆さん自身の J2EE アプリケーションに Web 2.0 Feature Pack を適用する方法についての考え方の一端も学びます。
「Plants by WebSphere」は、IBM WebSphere Application Server Feature Pack for Web 2.0 に提供されている、いくつかのサンプル・アプリケーションの中の 1 つです。このアプリケーションは典型的な J2EE アプリケーションの例であり、またアプリケーション全体を再作成しなくても Ajax スタイルのアーキテクチャーによりアプリケーションを強化できることを示す例でもあります。このサンプル・アプリケーションは、花、木、野菜、およびアクセサリーを注文でき、購入できる、架空のオンライン園芸店を表現したアプリケーションです。図 1 を見てください。この図はこの Web アプリケーションのフロント・ページを示しています。
図 1: 「Plants by WebSphere」Web アプリケーション
図 2 は、このアプリケーションに Ajax スタイルの機能を追加する前の、元の形式でのアーキテクチャーを示しています。このアーキテクチャーは、WebSphere Application Server 上で実行される非常に典型的な J2EE アプリケーション用のアーキテクチャーです。このアプリケーションは上位レベルで MVC (Model-View-Controller) デザイン・パターンに従っていますが、大部分の Web アプリケーションはいずれかのレベルでこのパターンに従っています。ブラウザーがこのアプリケーションの URL にアクセスすると、アプリケーションは JSP によって描画された HTML ページを返します。ブラウザーは Web アプリケーションに対してさらにリクエストを発行し、ユーザーが購入するためのリクエストを行うところまで進むと、フローを制御するためにサーブレットが使われます。データベース上にあるモデル・データを提供するためには EJB (Enterprise JavaBeans) が使われます。
図 2: 典型的な Web アーキテクチャー
下記の図 3 は、このアプリケーションのアーキテクチャーが、Ajax を使うことでいかに強化されたかを示しています。この強化の目的はアプリケーションを再作成することではなく、IBM Feature Pack で使われている技術を利用することでユーザー・エクスペリエンスを改善し、対話性が強化された一層リッチなエクスペリエンスを提供することにあります。
ブラウザー側では、このアプリケーションは JavaScript による Dojo Toolkit に提供されているウィジェットを使っています。また、Plants by WebSphere の持つ対話性を Plants by WebSphere を再作成することなく改善するために、カスタマイズされたユーザー・インターフェース・ウィジェットが作成されています。カスタムのユーザー・インターフェース・ウィジェットは非同期であるため、(Dojo Toolkit がサポートする) ブラウザーの XHR 機構を使って通信を行います。これらのウィジェットは XML 交換フォーマットを使ってサーバーとデータを交換します。サーバーでは、Feature Pack に提供されている RPCAdapter を使って EJB データを XML 交換フォーマットに変換し、ブラウザーで新たに作成されたウィジェットが容易にこのデータを利用できるようにします。
Ajax アプリケーションの 1 つの特徴は、ユーザー・インターフェースのレスポンスが改善されることです。Plants by WebSphere はアプリケーションのユーザー・インターフェース (UI) を改善するために、Web ブラウザーの中で Dojo Toolkit を使っています。Dojo Toolkit は純粋な JavaScript で作成されており、この JavaScript ファイルは WAR (Web Archive File) の Web-Content ディレクトリーの中に直接配置することもでき、あるいはパフォーマンスが最適化されたコンテンツ・デリバリー・ネットワーク上の静的な Web コンテンツとして存在することもできます。一例として、Dojo Toolkit の JavaScript ファイルは WAR の一部としてホストされています。
Dojo Toolkit は宣言型あるいは手続き型での使い方に対応しています。宣言型で使う場合は、使用する予定の JavaScript を HTML コンテンツの中に直接埋め込みます。Dojo Toolkit には HTML の中で宣言型で使用できる豊富なウィジェットが含まれており、関数をハンドコーディングする必要が少なくなっています。Plants by WebSphere の場合、Dojo Toolkit のウィジェットは JSP ページの中に直接埋め込まれています。
図 3: Ajax により強化されたアーキテクチャー
Ajax による強化の例: Web フォームの処理
Web アプリケーションでの一般的なシナリオにフォームの処理があります。フォームの処理ではユーザーが Web ページにデータ (ユーザーの名前、住所、好みなど) を入力します。入力が終わると、この情報はサーバーに送信されて処理され、その結果がユーザーに返されます。フォームに対する一般的なアクションとして、ユーザーが入力中の内容が受け付け可能なフォーマットかどうかを確認するための検証があります。文字ではなく数字が入力されたでしょうか。ユーザーは有効な郵便番号 (ZIP Code) を入力したでしょうか。Dojo Toolkit にはフォーム処理のための検証機能が豊富に用意されており、そうした機能を Web ページに追加することができます。下記のリスト 1 は Plants by WebSphere アプリケーションの中で使われている例です。これは Web アプリケーションの中で Dojo Toolkit を宣言型で使うための典型的な例を示しています。
まず、HTML ページの中で Dojo を使うことを宣言することから始めます。リスト 1 を見ると、最初の <script> タグは dojo.js を使うことを宣言しています。dojo.js は Dojo Toolkit のコア・カーネルであり、Dojo Toolkit を使う際に必要です。2 番目の <script> タグは、このページで使用する Dojo ウィジェットを宣言しています。dojo.declare は Java の import 文、あるいは C++ の #include に相当します。このメソッドは dojo.parser に対して、このページで使用する該当の Dojo Toolkit JavaScript ファイルをどこで探せばよいかを指示しています。例えばリスト 1 の場合、このページでは dijit.form.ValidationTextBox ウィジェットを使っています。また、JavaScript の dojo.parser も含める必要があります。このパーサーは宣言が必要なウィジェットがこのページにないか調べるために使われます。この後にあるリスト 2 が、その理由を説明しています。
リスト 1: 最大の幅を持つサンプル・コード・リスト
<script type="text/javascript"
src="/PlantsByWebSphereAjax//dojo/dojo.js"
djConfig="isDebug: false, parseOnLoad: true,
extraLocale: ['de-de', 'en-us']">
</script>
<script type="text/javascript">
dojo.require("dijit.form.ValidationTextBox");
dojo.require("dojo.parser");// scan page for widgets and
// instantiate them
</script>
|
リスト 1 は JavaScript の中で Dojo Toolkit を宣言する方法と、このページで使用することになるウィジェットの種類を示しています。リスト 2 は、このページの中でのウィジェットの宣言方法を示しています。リスト 1 で宣言された dojo.parser は HTML ページを解析するために使われます。この解析によってウィジェットが発見されると、そのウィジェットのコンストラクター・コードが呼び出されます。その結果、このページの DOM (Document Object Model) の中に検証を行うウィジェットのコードが作成されます。
リスト 2: Dojo の ValidationTextBox ウィジェットを使用する宣言
<TD width="100%">
<P>
<input type="text" id="sname" name="_sname" class="medium"
dojoType="dijit.form.ValidationTextBox"
propercase="true"
required="true"
promptMessage="Enter Name" />
</P>
</TD>
|
 |
クライアント・サイドの認証
ユーザー・データの認証形式として、クライアント・サイドの認証のみに頼るべきではありません。信頼しつつ、しかし検証は行う必要があります。クライアントが何かを返すものと信頼し、ただし返されるものが想定通りのものであることを検証します。一般的な方式としては、サーバー・サイドのホワイト・リストや、想定される入力に対するパターン・マッチングなどがあります。 |
|
図 4 はその結果を示しています。必要なフィールドにユーザーが値を入力しないと、ブラウザーはそれを動的にユーザーに知らせます。
図 4: Dojo の検証ウィジェットを使った請求用住所の入力フォーム
フォームの検証は、既存の J2EE アプリケーションの中で Ajax をどう使い始めればよいかを示す単純な例です。同時に、膨大な量の既存コードを再作成することなく、いかにシームレスにユーザー・インターフェースを改善できるかを示す強力な例でもあります。
他にも、Dojo Toolkit を使った宣言型のプログラミングを J2EE アプリケーションの中で使う方法を示す例は無数にあります。Dojo には、Dojo Toolkit の test ディレクトリーの中に多彩なサンプル・アプリケーションが同梱されています。これらのアプリケーションは HTML ページを開くとブラウザーの中で実行されます。
独自のカスタム・ウィジェットを作成する
もう 1 つ興味深い例として、独自にカスタマイズした JavaScript ウィジェットを作る方法が挙げられます。Dojo には強力なフレームワークが提供されており、HTML ページの中に直接埋め込むことのできる革新的なウィジェットを作成することができます。
図 5 は Plants by WebSphere アプリケーションのカタログ閲覧ページ示しています。ユーザーが画像の 1 つをクリックすると、カタログ・ページの上部にはさまざまな品目の画像が並べて表示され、また下部には各品目の詳細情報が表示されます。
図 5: Plants by WebSphere のカタログ・ページ
このページはいくつかの異なるウィジェットで構成されていますが、ここではページの下の方に表示される itemDetails ウィジェットを調べます (図 6)。itemDetails ウィジェットはサーバーから情報を取得し、その情報を詳細ウィンドウに表示します。ユーザーは Add to cart ボタンをクリックしてカートに品物を追加したり、左マウス・ボタンを使って品目をカートにドラッグしたりすることができます。このウィジェットは、ページの上部にあるカタログ品目の 1 つをユーザーがクリックすると、サーバーから情報を取得します。では itemDetails ウィジェットがどのように作成されたのかを調べてみましょう。
図 6: itemDetails ウィジェット
Dojo Toolkit を使ってウィジェットを作成する場合、いくつかのファイルについて考慮する必要があります。最初の 2 つは HTML と CSS のテンプレート・ファイルです。この 2 つは、ブラウザーの中でそのウィジェットが表示される際、そのページがどう見えるかの骨格を定義するために使われます。HTML ページには
ウィジェットによって DOM 要素が挿入されることになる接続ポイントが宣言されています。この接続ポイントは DojoAttachPoint と呼ばれます。
リスト 3 には、itemDetails ウィジェットの HTML テンプレートの一部と、テンプレートの table 要素の行内に配置された DojoAttachPoint が示してあります。カスタマイズされたウィジェットの中の JavaScript はコンテンツを処理しながら動的に要素を作成し、それらの要素を DOM の接続ポイントに挿入します。
リスト 3: Dojo のテンプレート itemDetail.html の中の DojoAttachPoint
<div>
<table cellpadding="2" cellspacing="2" border="0" width="100%"
height="100%">
<tr width="100%" height="100%">
<td valign="top" align="left" width="75%">
<span class="itemNameText"
dojoAttachPoint="nameElement"></span>
<span dojoAttachPoint="descElement"
class="itemDescText"></span><br><br>
<table cellspacing="0" cellpadding="0" width="100%"
height="100%">
<tr style="width: 80%">
<td valign="top" align="left">
<span style="font-family:verdana,arial,
sans-serif;
font-size:11px;">Price:</span>
</td>
<td valign="top">
<span class="itemNameText" >$
<span dojoAttachPoint="priceElement">
</span></span>
</td>
<td valign="top" align="right">
<button dojoType="dijit.form.Button"
dojoAttachEvent="onclick: addToCart">
Add to cart</button>
</td>
</tr>
</table>
. . . . .
. . . . .
// Additional content
. . . . .
. . . . .
</table>
</div>
|
このウィジェットのテンプレートと CSS はウィジェットの外観を定義し、また DOM のどこが更新されるのかを特定します。次のステップは実際の作業を行うウィジェットに JavaScript コードを追加することです。
リスト 4 は、カスタマイズされた itemDetails ウィジェットの最初の部分を示しています。このコードは最初に作成対象のウィジェットを宣言しています (dojo.provide("ibm.widget.ItemDetails");)。新たに作成されるウィジェットを参照する際には、この名前が使われます。
dojo.provide の下には dojo.declare があります。dojo.declare は itemDetails ウィジェットと、このウィジェットが持っている可能性のあるすべての継承を定義します。この場合、このコードは base dijit._Widget と dijit._Templated からの継承を宣言しています。これはテンプレート化されたウィジェットなので、コードは templatePath を宣言しています。テンプレート・パスは上記で定義されたテンプレートの場所を定義します。dojo.moduleUrl はテンプレートの場所を解決するために使われるユーティリティー関数です。
コードをさらに下に進むと、リスト 3 で定義された DojoAttachPoint が宣言されています。これらの宣言は更新される DOM を参照する際のルート・ノードになります。この場合、いくつかある変数のうち、nameElement と descElement が宣言されています。次のセクションでは、これらの要素がどのように変更されるかを調べます。
リスト 4: itemDetails ウィジェットを宣言する
dojo.provide("ibm.widget.ItemDetails");
dojo.declare(
"ibm.widget.ItemDetails",
[dijit._Widget, dijit._Templated],
{
initializer: function(){ },
templatePath:
dojo.moduleUrl("ibm","widget/templates/ItemDetails.html"),
isContainer: false,
// your DOM nodes declared as DojoAttachPoint in the
// Template:
nameElement: null,
descElement: null,
imageElement: null,
priceElement: null,
// Additional Code
. . . .
. . . .
|
このウィジェットを本当に興味深いものにするためには、このウィジェットに入力するためのデータが必要です。itemDetails ウィジェット用のデータはサーバー上にあります。この時点では、ページの中で表示するための記述データをどう取得するのか不思議に思う人もいるかもしれません。
Dojo Toolkit は強力な I/O トランスポート機構を提供しており、この機構を利用してサーバーに XHR (XMLHttpRequests) リクエストを発行し、その結果を処理することができます。XHR API はブラウザーの中で独自の通信チャネルを開きます。XHR は Ajax の対話動作を実現するための核心部分です。
リスト 5 は dojo.xhrGet 関数を使ってサーバーからデータを取得する方法を示しています。Dojo Toolkit は XHR API を独自の API でラップするため、XHR API が使いやすくなります。url: パラメーターはサーバーのアドレスを定義しています。?p0="+item.id はサーバーに渡される URL パラメーターです。timeout はサーバーへの接続の試行を中止するまでの待ち時間の長さを定義します。headers は、サーバーに送信されるリクエストに適用する必要のある、追加の HTTP ヘッダーを定義します。handleAs パラメーターはレスポンスの処理方法を Dojo Toolkit に指示します。この場合、想定されるレスポンスは XML コードです。
deferred.addCallback(function(response) はサーバーからレスポンスが返ってくると Dojo Toolkit から呼び出されるコールバック関数です。この前のセクションでは DojoAttachPoint を DOM の中で変更される DOM ノードの位置であると定義しました。descElement はここで変更される DOM ノードの 1 つです。self.descElement.innerHTML の値は XML の中で返された記述テキストに設定されます。descElement は、先ほどこのウィジェットの Template ファイルの中で宣言された DOM ノードです (リスト 3 を参照)。
リスト 5: サーバーに対する XHR GET リクエスト
var deferred = dojo.xhrGet( {
url: self.url+"?p0="+item.id,
timeout: 5000,
headers: { "Content-Type":"text/html" },
handleAs: "xml"
} );
deferred.addCallback(function(response){
var itemElement =
response.getElementsByTagName( "entry" )[0];
self.descElement.innerHTML =
itemElement.getElementsByTagName( "description" )[0].firstChild.nodeValue;
self.hiddenData.setAttribute("itemname", item.name);
self.hiddenData.setAttribute("itemprice", item.price);
self.hiddenData.setAttribute("itemid", item.id);
. . . . .
return response;
});
|
カスタマイズされた Dojo ウィジェットが作成されたら、そのウィジェットを使えるように HTML ページに挿入する必要があります。図 6 は、このページがどのように表示されるかを示しています。ここに表示されている文章は flowers.html ファイルのものです。リスト 6 は、このページの HTML フラグメントを示しています。DIV タグはウィジェットを埋め込むために使われており、また DIV タグは itemDetails ウィジェットを宣言するキーワード dojoType を含んでいます。いくつか追加のパラメーターが url (サーバー上の RPCAdapter (Remote Procedure Call Adapter) への URL リクエスト) の形式でウィジェットに渡されています。思い出して欲しいのですが、itemDetails ウィジェットは表示するデータを取得するためにサーバーに対して XHR リクエストを送信します。サーバー・サイドのコードについては、RPC アダプターの使い方を調べる次のセクションで説明します。
リスト 6: HTML ページでの itemDetails の宣言
<body style="background: #FFF;">
. . . .
. . . . //additional HTML
. . . .
<div dojoType="ibm.widget.ItemDetails"
url="/PlantsByWebSphereAjax/servlet/RPCAdapter/httprpc/Sample/detailRequest"
style="width: 100%;"
itemTopic="itemdetails_flowers"></div>
</body>
|
サーバー・サイドを調べる
ここまでの時点で、カスタマイズされたウィジェットを Dojo で作成する方法と、そのウィジェットがどのようにして XHR リクエストをサーバーに対して発行するかを見てきました。今度はこうしたリクエストをサーバーがどう処理するかを調べます。
Plants by WebSphere アプリケーションの場合、このウィジェットは何らかのデータを要求するためにサーバーに対して XHR リクエストを発行します。サーブレットはこのリクエストを読み取り、適切な EJB (Enterprise JavaBean) を探します。EJB が呼び出されると、EJB コンテナーがデータベースに要求を行い、データベースが結果を返します。この結果は XML にエンコードしてブラウザーの JavaScript ウィジェットに返送する必要があります。
このシナリオでは、IBM Feature Pack for WebSphere Application Server に提供されている RPC アダプター (RPCAdapter) を使って Plants by WebSphere という EJB に接続します。
RPCAdapter ランタイム JAR は Plants by WebSphere アプリケーションに含まれており、WAR ファイルの WEB-INF ディレクトリーの中にある XML ファイルを使って構成されます。リスト 7 は構成の例を示しています。
リスト 7: RpcAdapterConfig.xml
<?xml version="1.0" encoding="UTF-8"?>
<rpcAdapter>
<default-format>xml</default-format>
<services>
<pojo>
<name>Sample</name>
<implementation>
com.ibm.websphere.samples.plantsbywebspherewar.RpcConnecter
</implementation>
<methods filter="whitelisting">
<method>
<name>detailRequest</name>
<description>
returns back detail information for an item
</description>
<http-method>GET</http-method>
<parameters>
<parameter>
<name source="request">message</name>
<description>
Contains the message to be returned
</description>
</parameter>
</parameters>
</method>
</methods>
</pojo>
</services>
</rpcAdapter>
|
RpcAdapterConfig.xml ファイルをよく見てください。RPCAdapter が返す <default-format> が XML として宣言されています。また RPCAdapter はデータを JSON (JavaScript Object Notation) で返すこともできます。<implementation> 要素には、RPCAdapter がメソッドを呼び出すためにインスタンス化するユーザー定義のクラスの定義が含まれています。このクラスの中で呼び出されるメソッドの名前は <name> 要素の中で定義されており、メソッド名は detailRequest です。RPCAdapter が想定する <http-method> は GET です。URL リクエストに対して想定されているパラメーターは message です。
これをすべてまとめると、リスト 8 の itemDetails ウィジェットは次のフォーマットを使って RPCAdapter を呼び出します (F0001 はこの品物の ID です)。
/PlantsByWebSphereAjax/servlet/RPCAdapter/httprpc/Sample/detailRequest?message=F0001
|
RPCAdapter が返す結果は XML データです。リスト 8 はこの XML 出力を示しています。
リスト 8: RPCAdapter から itemDetails ウィジェットに返される XML 出力
<results>
<entry>
<description>
African orchids are some of the most endangered and rare kinds of orchids grown today.
This variety is medium yellow with variegated salmon and pink insides. Height: 18 to 28
inches.
</description>
<image>
/PlantsByWebSphereAjax/servlet/ImageServlet?getimagebyid=F0001
</image>
<id>F0001</id>
<name>African Orchid</name>
<price>$250.00</price>
<thumb>
/PlantsByWebSphereAjax/servlet/ImageServlet?getimagebyid=F0001
</thumb>
<dept>0</dept>
<heading>Rare Delicate Beauty</heading>
</entry>
</results>
|
今度は実装クラスを詳しく調べます。この実装クラスは RpcAdapterConfig.xml ファイルの中で定義され、また detailRequest メソッドを含んでいます。リスト 9 は、先ほどのリストの構成ファイル RpcAdapterConfig.xml の中で定義される実装クラス com.ibm.websphere.samples.plantsbywebspherewar.RpcConnecter を示しています。
リスト 9: 実装クラス com.ibm.websphere.samples.plantsbywebspherewar.RpcConnecter
public Collection detailRequest( String itemId ) {
ItemDetailPojo itemDetailPojo = new ItemDetailPojo();
Vector itemCollection = new Vector();
if (itemId != null) {
try
{
Catalog catalog = catalogHome.create();
StoreItem item = (StoreItem)
catalog.getItem(itemId);
if ( item != null ) {
itemDetailPojo.name = item.getName();
itemDetailPojo.id = item.getID();
itemDetailPojo.price =
java.text.NumberFormat.getCurrencyInstance(java.util.Locale.US)
.format(new Float(item.getPrice()));
itemDetailPojo.heading = item.getHeading();
itemDetailPojo.description = item.getDescription();
itemDetailPojo.dept = new
Integer(item.getCategory()).toString();
itemDetailPojo.thumb =
"/PlantsByWebSphereAjax/servlet/ImageServlet?getimagebyid="+item.getID();
itemDetailPojo.image =
"/PlantsByWebSphereAjax/servlet/ImageServlet?getimagebyid="+item.getID();
itemCollection.add(itemDetailPojo);
}
}
catch (javax.ejb.CreateException e)
{
Util.debug("RpcConnecter: EJB Create Exception in
detailRequest(...)");
}
catch (Exception e)
{
Util.debug("RpcConnecter: general Exception in
detailRequest(...)");
}
}
return itemCollection;
}
|
detailrequest( ) メソッドは POJO (Plain Old Java Objects) 要素のコレクションを返します。collection クラスは java.util パッケージに含まれています。POJO 要素は StoreItem EJB を呼び出すことで返されるデータから得られます。StoreItem は Catalog EJB から取得されます。Catalog EJB は Derby データベースの中にある Plants by WebSphere の在庫に含まれる品物の集合です。Java の Collection が返されると、RPCAdapter はその Collection をそのまま XML データにマッピングします。Collection のキーは XML 要素に対応し、またキーの値は XML の値に対応します。XML ストリームは itemDetails ウィジェットに返されます。
RPCAdapter を使用し、また RPCAdapter に XML コードを返させることで、他からも接続できるサービスを作成したことになります。このサービスはデータしか返さず、このデータをどのように表示するかは呼び出し側に依存します。使い方のシナリオとしては、Plants by WebSphere を利用する会社が、その会社が独自に販売している温室と Plants by WebSphere が維持管理するカタログ情報を集約するようなシナリオが考えられます。このシナリオはマッシュアップと呼ばれることがあります。
考慮する価値のある他のシナリオ
Plants by WebSphere アプリケーションは下記に挙げるような個別のシナリオを実装していませんが、これらのシナリオは J2EE アプリケーションで IBM WebSphere Application Server Feature Pack for Web 2.0 の利点を活用するための他の方法を考える上で役に立ちます。
プロキシー・サービス
先ほど、複数サイトのコンテンツを組み合わせて 1 つのサイトの外観を作り上げる、マッシュアップ・アプリケーションの作成について学びました。マッシュアップのよく知られた例としては、Google マップを利用し、地理情報に基づくユーザー独自のコンテンツでカスタマイズするアプリケーションがあります。マッシュアップを作成する際の課題の 1 つは、ブラウザー内でのクロスサイト・スクリプティングの問題をどう処理するかです。例えば、Plants by WebSphere アプリケーションを利用するために mydomain.com にアクセスするとします。ところが、作成されたウィジェットは XHR を使って mypartner.com に XML リクエストを発行するため、ブラウザーはそのリクエストを禁止します。通常であれば、この動作によって、Web 上のさまざまなページにアクセスする際にクロスサイト・スクリプティングによるセキュリティーの脆弱性が発生する問題を防止できるため、この動作は非常に適切です。
しかし Plants by WebSphere アプリケーションの場合、作成したウィジェットから他のサイトのコンテンツにアクセスできるようにしたいものです。ブラウザー内で、クロスサイト・スクリプティングを許可してもセキュリティーの問題が発生しないようにするにはどうすればよいのでしょう。
一般的な 1 つの方法は、フォワード・プロキシーを使う方法です。フォワード・プロキシーはブラウザーからリクエストを取得し、その URL を調べ、そのリクエストを適切なドメインに転送します。ブラウザーの観点からすると、情報は同じドメインから来るように見えますが、実際にはコンテンツのリクエストはクライアントに代わってプロキシーが行っています。IBM WebSphere Application Server Feature Pack for Web 2.0 に同梱されている Ajax プロキシーには、カスタマイズ可能なサーブレット・プロキシーが含まれています。
このプロキシーはサーブレットをベースにしており、EAR ファイルの中に直接組み込むことができ、あるいはサーバー上で WAR ファイルとして実行することもできます。このプロキシーにはホワイト・リスト機能も含まれており、追加としてこの機能も追利用すると、プロキシーが受け付けることのできるリクエストの種類を制限することができます。またこのプロキシーにはヘッダーや MIME タイプ、クッキーに基づいてフィルタリングする機能も含まれており、その機能を XML ファイルを使ってカスタマイズすることもできます。
Web フィードの配信 (世界に伝える)
Web 配信 (または Web フィード) は、コンテンツを他のサイトで参照できるようにするための方法です。通常は、サイトがそのサイトのコンテンツのタイトルと簡単な説明を含む Web フィードを利用できるようにします。ユーザーがそのコンテンツに関心を持ち、リンクをクリックすると、そのサイトに導かれ、さらに詳細な情報を読むことができます。Plants by WebSphere アプリケーションの場合のシナリオとしては、園芸の専門家によるヒントや特価品、ブログなど追加の情報を含むような Web フィードを考えることができます。
IBM Feature Pack for Web 2.0 は Apache の Abdera ライブラリーを提供しています。Abdera ライブラリーには Atom 配信フォーマットと Atom 出版プロトコルの実装が含まれており、独自のフィードを作成する際に役立ちます。
配信によるソリューションは、クライアント・サイドの実装を考慮しない限り完全なものにはなりません。IBM Feature Pack は Dojo Toolkit 拡張機能の一部として Atom Feed ビューアーを提供しています。このビューアーはフィード表示機能を提供するためのウィジェットとして HTML の中に埋め込むことができます。
まとめ
Plants by WebSphere アプリケーションは、IBM Feature Pack for Web 2.0 を適用することで既存の J2EE アプリケーションに Ajax スタイルのアーキテクチャーを作成するための、単なる 1 つの例にすぎません。Feature Pack にはクライアント・サイドとサーバー・サイドのさまざまな技術が含まれており、それらをまとめて、あるいは独立に、Web アプリケーションにデプロイすることができます。さらに詳しい情報は Feature Pack のダウンロード・サイトから入手することができます (「参考文献」のセクションを参照)。
参考文献 学ぶために
製品や技術を入手するために
議論するために
著者について | 
| | Kevin Haverlock は IBM の WebSphere Application Server 製品のアーキテクトであり開発者です。そして現在は Feature Pack for Web 2.0 チームの一員です。彼の連絡先は kbh@us.ibm.com です。 |
記事の評価
| 
