|
|
|
|
|
|
| | | |
無線加入者に対応した Web アプリケーションの記述
以下の節では、WebLogic Server を使用して Web アプリケーションの対象範囲を無線加入者に拡大する方法を、サンプルを通して説明します。
インターネット対応無線デバイスの普及率の上昇により、アプリケーション開発者には、既存のデスクトップ ブラウザだけではなく、それ以外のブラウザにも接続できる Web アプリケーションを設計することが求められています。また、無線デバイスのフォーム ファクタ、ユーザ入力インタフェース、および無線（OTA）プロトコルとマークアップ言語の使い方はデバイスごとに大幅に異なっているので、開発者は Web アプリケーションの設計時にさまざまな種類の無線デバイスを考慮に入れる必要があります。
WebLogic Server に組み込まれている既存のアプリケーションは、無線 Web に対応しています。実際のところ、優れたアプリケーションの場合、大幅なコードの修正をしなくても、アプリケーションのバックエンド全体がインターネット対応無線デバイスに対応しています。最も単純な例では、アプリケーション開発者はフロントエンド ソフトウェアを記述するだけで、アプリケーションとインターネット対応無線デバイスを接続できます。
以下の節では、Web アプリケーション サービスを無線デバイスに適用するためのさまざまな方法について説明します。これらの方法は、サービスを無線デバイスに適用するための方法にしか過ぎませんが、WebLogic Server J2EE 機能を使用して独自の方法を開発するのに役立ちます。また、これらの方法を明確に理解できるよう、5 つの単純なサンプル アプリケーションも示します。
WebLogic Server ソフトウェアのインストール中、次の図に示すとおり、インストール プログラムによって 5 つの無線サンプル アプリケーションのディレクトリとファイルが wireless ディレクトリに置かれます。
図4-1 WebLogic Server無線ファイル ツリー
上に示した製品ディレクトリ、wlserver6.1 は WebLogic Server 6.1 のデフォルト ディレクトリです。このデフォルト名は、インストール時に変更される場合があります。
次の表では、WebLogic Server 無線ディレクトリ構造の最上位のディレクトリとファイルについて簡単に説明します。5 つのサンプルには、無線デバイスまたはデスクトップ ブラウザから JavaServer Pages（JSP）と Java サーブレットにアクセスする方法が示されています。
アプリケーション開発者は、Web アプリケーションのデータとビジネス ロジックを有線デスクトップ デバイスと無線デバイスの両方で使用できます。しかし、画面のレイアウトと移動方法は、デバイスの種類に応じて調整する必要があります。多くの場合、デスクトップ ブラウザ用のアプリケーション フローは、無線デバイス マイクロブラウザ用のそれとは大幅に異なります。
例として、デスクトップ ブラウザに e-コマース サイトを提供するための次のアプリケーション フローを考えてみましょう。
e-コマース サイトのホーム ページには、電子店舗、検索フォーム、および現在の特別商品の広告という、異なるセクションへのリンクが存在します。店舗の一部、商品カテゴリ、および特定の商品を選択すると、その商品の詳しい説明と、その商品をショッピング カートに追加するためのオプションが表示されます。その追加オプションを選択すると、ショッピングを続けるか、または会計に進むためのオプションが表示されます。
このアプリケーション フローは、消費者が電子店舗内をさらに見て回り、当初の目的よりさらに多くの商品を購入するように設計されています。デスクトップ ブラウザとマウスを使用する場合、このフローは非常によく機能します。しかし、このフローを使用して e-コマース サイトをデータ対応無線デバイスに提供した場合、消費者はフラストレーションのために電子店舗から立ち去ってしまう可能性があります。無線デバイスは、閲覧にはまったく適していないからです。代わりの方法として、これと同じ e-コマース サイトを携帯電話に提供するための次のアプリケーション フローを考えてみましょう。
このサイトのホーム画面では、消費者は商品の UPC バーコードまたは何らかのユニークな ID を入力できます。次の画面には、商品をカートに追加する、会計に進む、または商品の詳細を表示するためのリンクが表示されます。各ページには「総合電子店舗」へのリンクが表示され、顧客がいつでも閲覧できるようになっています。
このアプリケーション フローは、デスクトップ ブラウザ用のアプリケーション フローとは反対になっていることに注意してください。無線デバイス用のアプリケーション フローを作成するための鍵は、無線デバイスの入力および選択メカニズムを使用したユーザ対話を減らすことにあります。
したがって、Web アプリケーションを開発するときには、無線デバイスの限界を考慮し、適切なコンテンツを提供するための最も効率的で柔軟な方法を見つけ出さなければなりません。以下の節では、こうした考慮事項についていくつか説明します。
ほとんどの無線デバイスは、その画面のサイズと形状の違いから、異なるフォーム ファクタを持っています。無線マークアップ言語（WML、HDML、cHTML、Web Clipping など）は、これらのフォーム ファクタに対応するよう特別に設計されています。一部の WAP ゲートウェイ（WAP や i-Mode など）は HTML を異なるマークアップ言語に自動的に変換できますが、実際上、最も優れたアプリケーションは、WML を直接使用して無線ユーザ固有のニーズに合わせてインタフェースを調整します。このようにすることで、無線デバイスのフォーム ファクタを最大限に活用して、ユーザに最良の体験を提供できます。
多くの無線デバイスは、10 〜 20 文字の行を 4 つまたは 5 つしか表示できません。このため、ユーザが満足する情報をいかにして小さい画面に提供するかが課題となっています。
ほとんどの無線デバイスは、キーボードとマウスが存在しないことから、非常に単純なインタフェースを搭載しています。データの入力や画面間の移動は、数字キーまたは数字ボタンを押すか、ペンで入力することによって行います。
アプリケーションを設計および記述するときには、入力するデータの量に加え、データ入力のメカニズムも考慮する必要があります。可能であれば、アプリケーションの必須データ入力ポイントをオプション データ入力ポイントから分離して、必須データ フィールドだけが無線デバイスに表示されるようにします。
マークアップ言語（WML、HDML、cHTML、Web Clipping など）を使用すると、無線デバイスのキーとボタンに処理を割り当てるアプリケーション フロントエンドを記述できます。携帯電話の場合、一例として、特定の処理（[前へ]、[戻る]、[OK]、[送信]、[選択]、[実行]、[次へ]、[終了]、[ホーム]など）をラベルのない電源キーに割り当て、新しい処理をラベル付きのソフト キーに再び割り当てるためのアプリケーション フロントエンドをプログラミングできます。PDA デバイスの場合、新しい処理をソフト ボタン（シルクに印刷されたボタン）とハード ボタンに再び割り当てるためのアプリケーション フロントエンドをプログラミングできます。アプリケーションのデスクトップブラウザ バージョンのボタンとリンクに代わり、アプリケーションの無線デバイス バージョンにキーまたはボタンを割り当てることができるのは、非常に便利なデータ入力および画面移動機能です。
ほとんどの無線デバイスは、メモリをほとんど搭載していません。WML カードをデックにグループ化する場合、1 つのデックが最小のダウンロード単位になるようにする必要があります。つまり、情報はカード単位ではなくデック単位で無線クライアントにダウンロードされます。こうしたメモリ制限のため、大量のカードで構成されるデックや、単一の大きいカードの使用を回避することをお勧めします。
注意: デック内のカードの数またはサイズを制限するのは、メモリだけではありません。一部の無線ゲートウェイでは、無線デバイスに提供される単一のペイロードのサイズに制限があります。
Web アプリケーションの最も重要な部分は、ユーザと対話するために記述された特定の種類のマークアップ言語（従来の HTML）ではなく、そのユニークなコンテンツとバックエンドのデータベース対話です。優れたバックエンド機能であれば、修正を行わなくても、無線クライアントに同じサービスを提供できます。アプリケーション開発者は、マークアップ言語固有のフロントエンド（WML、HDML、cHTML、 ...）を開発しさえすれば、同じバックエンド機能を無線デバイスに提供できます。また、異なる種類のデバイス（携帯電話、PDA、従来のデスクトップ ブラウザなど）に応じてカスタマイズされたプレゼンテーションを定義し、特定のデバイスに固有の機能（リクエスト側デバイスの地理的位置に基づく携帯電話のパーソナライゼーションなど）を追加する必要があります。
HTML ベースのブラウザと無線クライアント タイプへのユーザ アクセスを処理するための基本的な方法は 2 つあります。ブラウザベースの HTML およびマイクロブラウザベースの WML/HDML/cHTML/... 入力ポイント用に別個の URL（www.foo.com、www.wap.foo.com、www.imode.foo.com など）を使用するよう Web アプリケーションをプログラミングする方法か、または、単一の URL（www.foo.com など）を使用してリクエスト側のブラウザ タイプに応じてコンテンツを生成するよう Web アプリケーションをプログラミングする方法です。後者の方法では、その URL に存在する Web アプリケーションは、リクエストの HTTP User-Agent ヘッダを調べるか、または無線ゲートウェイからリクエスト側に関する情報を取得することによってブラウザの種類を特定します。HTTP User-Agent ヘッダ情報へのアクセス例については、WebLogic Server の samples\examples\servlets ディレクトリに格納されている SnoopServlet サンプルを参照してください。
同じ 2 つの方法は、開発者が市販の異なる無線デバイスのさまざまな機能とディスプレイ サイズを利用しようとする場合にも使用できます。無線デバイスのディスプレイ サイズは、現時点ではテキスト 4 行ないし 8 行分です（これについては近い将来大幅に改善される見通しです）。クライアントのタイプを調べることによって、アプリケーションは使用可能な場合にだけ追加のグラフィカル領域を使用できます。最も単純な手段は、最小公分母（4 行）に合わせたコンテンツを作成することです。ただし、この方法ではほとんどのデバイス上で最良のユーザ体験を提供できません。
一般に、すべてのデバイス（既存のデスクトップ ブラウザを含む）で同じ URL を使用して、アプリケーションへのアクセスをできるだけ簡単にすることをお勧めします。
デバイスの種類に基づいてアプリケーションが提供するコンテンツをカスタマイズできるよう、パーソナライゼーション メカニズムを使用することを検討する必要があります。たとえば、あるデバイス（デスクトップ ブラウザなど）でユーザが見たいサービスは、別のデバイス（携帯電話）でそのユーザが見たいサービスとは大幅に異なる場合があります。BEA WebLogic Personalization Server のようなツールは、この種の柔軟性をアプリケーションに提供するのに非常に役立ちます。
また、パーソナライゼーション メカニズムを使用すると、デバイスの種類と場所に基づいてポータルを作成することができます。たとえば、米国の東海岸を訪れたときにはデバイス（携帯電話など）で特定のポータルを表示し、西海岸を訪れたときには同じデバイスで別のポータルを表示できます。さらに、デバイスの場所に基づいてポータルをパーソナライズすることもできます。
たとえば、デバイスが自宅から 20 マイルを超える場所にある場合はホーム ページにその土地のレストランの名前が表示され、自宅から 20 マイル以内にある場合はレストラン名が表示されないようにできます。
また、パーソナライゼーション メカニズムを使用すると、時刻または曜日に基づいて異なるデバイスにアラームを送信することができます。たとえば、ユーザが週末にページャを携帯していない場合、音声アラームを生成して留守番電話に記録できます。
セッション トラッキングは、複数の Web ページにわたってユーザの動きを追跡するのに役立ちます。『WebLogic HTTP サーブレット プログラマーズ ガイド』で説明されているように、サーバは各クライアント セッションに対し、セッション ID および関連付けられた javax.servlet.http.HttpSession オブジェクト（セッションの有効期間だけ WebLogic Server 上に存在する）を割り当てます。クライアントは、セッション ID を各リクエストに付与し、サーバが HttpSession オブジェクト内のセッション データを見つけられるようにします。
WebLogic Server のクラスタにデプロイされていないアプリケーションの場合、セッション ID は次の形式となります。
WebLogic Server のクラスタにデプロイされたアプリケーションの場合、セッション ID はさらに 60 バイトが追加された次の形式となります。
Rand_Sess_ID!Primary_JVMID_DIFFERENTIATOR!HOST!PORT!SSLPORT!
SECONDARY_JVMID_DIFFERENTIATOR!HOST!PORT!SSLPORT
サーバは、クライアントにクッキーを設定することによって、セッション ID を保存しようとします（クッキーは、Web ブラウザを識別し、それによってカスタマイズおよび円滑化されたサービスを提供するためにインターネットで使用されます）。クッキーが設定されたクライアントは、サーバに送信される各ユーザ リクエストにそのクッキーを含めるようになります。サーバは、クッキーのセッション ID を自動的に解析し、適切な HttpSession オブジェクトからセッション データを取り出します。
ただし、ほとんどの無線デバイスはクッキーをサポートしておらず、また、一部の無線ゲートウェイはクライアントのクッキーを処理しないため、別のセッション トラッキング手法を使用しなければならない場合もあります。
URL 書き換えでは、サーブレットがクライアントに送り返すページ上のハイパーリンクにセッション ID がエンコードされます。ユーザが以後これらのリンクをクリックすると、WebLogic Server は URL からそのセッション ID を抽出し、適切な HttpSession オブジェクトを見つけ出します。
均等なランダム分散を使用してセッションのセキュリティを保証するために、セッション ID には特定数の文字が含まれなければなりません。しかしながら、多くのデバイスは URL を最大 128 文字（バイト）に制限しているので、セッション ID の長さが問題となる可能性があります。
セッション ID の長さを制限する方法は以下の 2 通りです。
weblogic.xml の <session-descriptor> 要素で、IDLength 属性を設定することにより、セッション ID のうちランダムに生成される部分の長さを制限できます。最小値は 8 バイトです。
config.xml ファイルの <WebServer> 要素で、WAPEnabled 属性を true に設定することにより、セッション ID のその他の部分（JVMID）の長さを制限できます。
サービス パックが適用されていない WebLogic Server 6.1 では、WAPEnabled を true に設定すると、セッション ID のうちのランダムに生成される部分にまでセッション ID が制限されます。つまり、セッション ID には、プライマリ サーバおよびセカンダリ サーバの情報が含まれなくなります。
サービス パック 1 以降を適用した WebLogic Server 6.1 では、WAPEnabled を true に設定すると、WebLogic Server のクラスタにデプロイされたアプリケーションのセッション ID は次の形式に変更されます。
サーバは、Primary_JVMID_HASH と SECONDARY_JVMID_HASH の各値を、サーバに格納されているプライマリ サーバおよびセカンダリ サーバ情報にマッピングし、適切な HttpSession オブジェクトからセッション データを取り出します。
長いセッション ID の形式（WAPEnabled を false に設定）と、制限されたセッション ID の形式（WAPEnabled を true に設定）のどちらの場合でも、ステートのインメモリ レプリケーションが使用されます。つまり、セッション永続性は、WebLogic Cluster の要件ではないということです。WebLogic Server でインメモリ レプリケーションを使用していない場合、JVMID は URL にエンコードされません。WAPEnabled 属性の詳細については、「config.xml 要素と属性」を参照してください。
さらに優れた方法は、セッション ID が指定される WML postfield 要素を、WML go 要素と一緒に組み込むことです。WML では、go 要素は URL への移動を示します。go 要素には、1 つまたは複数の postfield 要素を含めることができます。これらの要素は、要求の間に元のサーバに送られる情報を指定します。以下の WML コード（スクリプトレット）では、セッション ID はセッションから取得され、JSESSIONID postfield の値を設定するために使用されます。
<go href="index.jsp" method="post"> <postfield name="JSESSIONID" value="<%= session.getId() %>"/></go>
上記のコードを使用すると、JSESSIONID=sessionID というメッセージ エンティティを持つ URL index.jsp への HTTP POST が実行されます。ここで sessionID とは、session.getId() 呼び出しから取得される ID です。index.jsp 内部からは、request.getParameter("JSESSIONID") 呼び出しで HTTP リクエストからパラメータを取得することによってセッション ID を取得できます。
date および phoneBook アプリケーションは、WAP 専用 Web アプリケーションのサンプルです。これらのサンプル アプリケーションは、次の図に示すとおり、WML クライアントから WebLogic Server にアクセスする方法を表しています。
図4-2 WAP 専用サンプル アプリケーションのデータ フロー
WML クライアントからのリクエストは、WAP ゲートウェイを介して HTTP リクエストの形式で WebLogic Server に転送されます。WebLogic Server は、静的ファイルか、JSP または Java サーブレットとして記述された HTTP サーブレットを提供することによって HTTP リクエストに応答できます。WAP アプリケーションでは、静的ファイルは通常 WML ファイルになり、JSP とサーブレットは WML を動的に生成するために使用されます。
WAP アプリケーションを作成するには、単一の種類のアプリケーション クライアント、つまり WML 対応マイクロブラウザを搭載した無線デバイスをサポートする WML フロントエンドを記述します。WML は XML をベースとしているため、『WebLogic XML プログラミング ガイド』で、WebLogic Server から XML を生成する例を参照してください。
date および phoneBook サンプル アプリケーションは比較的シンプルなので、J2EE と WebLogic Server API を使用して WAP アプリケーションを開発する方法を最初に学ぶのに最適です。ただし、これらのサンプルは、WAP アプリケーション モデルを実施に移すための複数の方法の 1 つに過ぎず、あくまで実例としてとらえる必要があることに注意してください。
date サンプルには、JSP から WML ドキュメントを生成して WML クライアントに提供する仕組みが示されています。次の図に、そのデータ フローの概要を示します。
図4-3 date アプリケーションへのアクセス
WAP ゲートウェイは、クライアントから受信した WML リクエストを HTTP サーブレット リクエストに変換し、変換したリクエストを WebLogic Server 上で動作する Date.jsp に転送します。Date.jsp は、現在の日付と時刻を調べ、その結果を次の WML ドキュメントとして返すことによってこのリクエストに応答します。
コード リスト 4-1 date ディレクトリの Date.jsp
<?xml version="1.0"?>
<!DOCTYPE wml PUBLIC "-//WAPFORUM//DTD WML 1.1//EN"
"http://www.wapforum.org/DTD/wml_1.1.xml">
<!-- Copyright (c) 2001 by BEA Systems, Inc.
All Rights Reserved. -->
<!-- set document type to WML -->
<%@ page contentType="text/vnd.wap.wml" %>
<wml>
<template>
<do type="prev" label="back">
<prev/>
</do>
</template>
<card title="WML DATE EXAMPLE" id="frstcard">
<p>
<small>The current date is:
<br/>
<%= new Date() %>
<br/>
Copyright © 2001 by BEA Systems, Inc.
All Rights Reserved.</small>
</p>
</card>
</wml>
リクエスト側の WML クライアントはマークアップ言語ドキュメントにアクセスし、次のサンプル ディスプレイに示すとおり、現在の日付と時刻を出力します。
図4-4 date のサンプル ディスプレイ
Date.jsp の <%@ page contentType="text/vnd.wap.wml" %> 行は、生成されるドキュメントの MIME タイプを WML MIME タイプに設定します。これは、WML を直接 JSP またはサーブレットから生成するときには常に必要です。この行が存在しない場合、MIME タイプはデフォルトによって HTML MIME タイプとなり、WAP ゲートウェイはそのドキュメントを WML に変換しようとして不適切な結果が生じる場合があります。
注意: MIME（Multipurpose Internet Mail Extensions）は、標準のインターネット電子メールの機能を拡張するための仕様です。MIME は、インターネット メールを介した伝送のためにさまざまなメディア タイプを表現およびエンコードするための標準化された方法を提供します。
date サンプルに必要な MIME タイプ（次の表を参照）は、WebLogic Server に登録されています。
表4-1 WAP 専用サンプル アプリケーション用の MIME タイプの定義
これらの MIME タイプは、インストールされている WebLogic Server の config\examples\applications\examplesWebApp\WEB-INF\web.xml ファイルで参照できます。このファイルに記述されている MIME タイプは参照専用です。したがって、このファイル内の MIME タイプを追加または削除しても、WebLogic Server に登録されている MIME タイプは変更されません。
phoneBook サンプルは、WML クライアントから受信したフォームのデータを処理する方法を示しています。次の図に、そのデータ フローの概要を示します。
図4-5 phoneBook アプリケーションへのアクセス
次のリストに示す phone.wml ファイルは、select 要素を使用して、電話番号を調べるためのオプションをユーザに提供します。
コード リスト 4-2 phoneBook ディレクトリの phone.wml
<?xml version="1.0"?>
<!DOCTYPE wml PUBLIC "-//WAPFORUM//DTD WML 1.1//EN"
"http://www.wapforum.org/DTD/wml_1.1.xml">
<!-- Copyright (c) 2000-2001 by BEA Systems, Inc.
All Rights Reserved. -->
<wml>
<card id="card1" title="Phone Book" newcontext="true">
<p>
Name:
<select name="name" value="" title="Name">
<option value="">All</option>
<option value="John">John</option>
<option value="Paul">Paul</option>
<option value="George">George</option>
<option value="Ringo">Ringo</option>
</select>
</p>
<do type="accept" label="Get number">
<!-- Edit the URL below to point to the appropriate
hostname and listenport of your WebLogic Server -->
<go href="http://localhost:7001/examplesWebApp/
PhoneServlet?name=$(name:escape"/>
</do>
</card>
</wml>
リクエスト側の WML クライアントはマークアップ言語ドキュメントにアクセスし、次のサンプル ディスプレイに示すとおり、電話番号を検索するためのオプションを出力します。
図4-6 phoneBook のサンプル ディスプレイ
ユーザの入力（All または名前）に基づいて、クライアントは WAP ゲートウェイを介して次の HTTP リクエストを PhoneServlet（WebLogic Server の samples\examples\servletsディレクトリに格納されている既存のサーブレット）に送信します。
http://wls_machine:listen_port/examplesWebApp/phoneServlet?name= $(name:escape)
クエリ パラメータの name は、サーブレットの URL に追加されます。このサンプルでは、PhoneServlet は phonelist というテキスト ファイル（WebLogic Server の samples\examples\servlets ディレクトリに格納されている）から WML 応答を生成し、WAP ゲートウェイはその応答を WML クライアントに転送します。次の図に、phoneBook アプリケーション フローとユーザ入力を示します。
図4-7 phoneBook アプリケーションの使用例
注意: WAP ゲートウェイをコンフィグレーションして HTML から WML に自動的に変換することも可能ですが、WML はほとんどの WAP クライアント デバイスの表示上の限界に対処できるように設計されているので、WML を直接生成することをお勧めします。
WAP 専用サンプル アプリケーション用の追加ソフトウェアのインストール
date および phoneBook サンプル アプリケーションを実行するには、以下のソフトウェアをインストールする必要があります。
WML クライアント エミュレーション ソフトウェアを販売しているベンダのリストについては、WebLogic Server の samples\examples\wireless\tools\emulators.txt ファイルを参照してください。
サンプル Web アプリケーションのディレクトリ階層は、WebLogic Server の config\examples\applications ディレクトリに格納されています。date および phoneBook サンプルを構築すると、config\examples\applications\examplesWebApp ディレクトリにはサンプル アプリケーション用に作成されたアプリケーション アーカイブが格納されます。
date または phoneBook サンプル アプリケーションの構築、コンフィグレーション、および実行については、対象サンプルのソース ファイルが格納されているサンプル ディレクトリ（date、phoneBook）内の package-summary.html ファイルを参照してください。
helloWorld、stockDemo、および travelDemo アプリケーションは、複数ターゲット アプリケーションの記述例です。これらのサンプル アプリケーションは、次の図に示すとおり、WML、HDML、cHTML、および HTMLクライアントから WebLogic Server にアクセスする方法を表しています。
図4-8 複数ターゲット サンプル アプリケーションのデータ フロー
各サンプル アプリケーション（helloWorld、stockDemo、および travelDemo）は、以下の種類のアプリケーション クライアントをサポートする 4 つのフロント エンドを備えています。それらは、WML 対応マイクロブラウザ搭載デバイス、HDML 対応マイクロブラウザ搭載デバイス、cHTML 対応マイクロブラウザ搭載デバイス（注意を参照）、および HTML 対応マイクロブラウザまたはブラウザ搭載のデバイスです。複数ターゲット アプリケーションを記述すると、アプリケーション開発者は標準の Web 技術による既存の開発努力を保持しつつ、無線加入者へのアクセスを取得できます。
注意: これらのサンプルは非常にシンプルなので、サンプル用の HTML JSP ページは cHTML JSP ページとしても機能します。
helloWorld、stockDemo、および travelDemo アプリケーションは比較的シンプルなので、J2EE と WebLogic Server API を使用して複数ターゲット Web アプリケーションを開発する方法を最初に学ぶのに最適です。ただし、これらのサンプルは、複数ターゲット アプリケーション モデルを実施に移すための複数の方法の 1 つに過ぎず、あくまで実例としてとらえる必要があることに注意してください。
helloWorld、stockDemo、および travelDemo サンプルは、単純なプロトタイプ フレームワークを使用してデバイスに依存しないページを選択します。デバイス リクエストを処理するためにサンプル フレームワークが呼び出されると、このフレームワークは、リクエストの HTTP User-Agent ヘッダを調べることによってリクエスト側デバイスの種類を特定して、使用する JSP ページとそのページに渡す値を指定したオブジェクトを返します。サンプル フレームワークは、1 つの URL を使用して、リクエスト側デバイスの種類に応じてコンテンツ（WML、HDML、cHTML、HTML）を生成するよう設計されています。
helloWorld、stockDemo、および travelDemo サンプルに必要な MIME タイプ（次の表を参照）は、WebLogic Server に登録されています。
表4-2 複数ターゲット サンプル アプリケーション用の MIME タイプの定義
これらの MIME タイプは、インストールされている WebLogic Server の config\examples\applications\examplesWebApp\WEB-INF\web.xml ファイルで参照できます。このファイルに記述されている MIME タイプは参照専用です。したがって、このファイル内の MIME タイプを追加または削除しても、WebLogic Server に登録されている MIME タイプは変更されません。
helloWorld サンプルは、(1) リクエスト側デバイスに固有の単純なマークアップ言語の生成、(2) 生成されたドキュメントのリクエスト側デバイスへの提供、を示したものです。次の図に、そのデータ フローの概要を示します。
図4-9 helloWorld アプリケーションへのアクセス
無線クライアントからのリクエストの場合、クライアントの無線ゲートウェイはクライアントから受信したマークアップ言語リクエストを HTTP サーブレット リクエストに変換し、そのリクエストを WebLogic Server 上の helloWorld の HTTP サーブレットに転送します。デスクトップからのリクエストの場合、デスクトップ クライアントは WebLogic Server 上の helloWorld の HTTP サーブレットに直接 HTTP サーブレット リクエストを送信します。
HTTP サーブレットは、そのリクエストのデバイス タイプと JSP ページを解決するためにそのリクエストをサンプル フレームワークに渡します。サンプル フレームワークは、helloWorld サンプル ディレクトリの wml、hdml、または html サブディレクトリ内の適切な helloWorld.jsp ページの場所を返します。選択された helloWorld.jsp は、マークアップ言語固有のドキュメントを生成してリクエスト側デバイスに返すことによって応答を行います。このドキュメントは、ユーザに Hello World! という文字列を表示します。次に、このドキュメントの WML バージョンを示します。
コード リスト 4-3 helloWorld ディレクトリの wml サブディレクトリ内の helloWorld.jsp
<?xml version="1.0"?>
<!DOCTYPE wml PUBLIC "-//WAPFORUM//DTD WML 1.1//EN"
"http://www.wapforum.org/DTD/wml_1.1.xml">
<!-- Copyright (c) 2001 by BEA Systems, Inc.
All Rights Reserved. -->
<%@ page contentType="text/vnd.wap.wml"%>
<wml>
<template> <do type="prev" label="back"> <prev/></do> </template>
<card id="firstcard">
<p>Hello World!
<br/> <a title="next" href="#secondcard">Next</a>
</p>
</card>
<card id="secondcard">
<p> Goodbye from WML.</p>
</card>
</wml>
リクエスト側のデバイスはマークアップ言語ドキュメントにアクセスし、次のサンプル ディスプレイに示すとおり、Hello World! を出力します。
図4-10 helloWorld サンプル ディスプレイ
stockDemo サンプルには、クライアントから受信した単純なフォームのデータを処理する方法が示されています。次の図に、そのデータ フローの概要を示します。
図4-11 stockDemo アプリケーションへのアクセス
stockDemo の HTTP サーブレットは、HTTP サーブレット リクエストを受信すると、そのリクエストのデバイス タイプと JSP ページを解決するためにそのリクエストをサンプル フレームワークに渡します。サンプル フレームワークは、stockDemo サンプル ディレクトリの wml、hdml、または html サブディレクトリ内の適切な stockAlert.jsp ページの場所を返します。選択された stockAlert.jsp は、マークアップ言語固有のドキュメントを生成してリクエスト側デバイスに返すことによって応答を行います。このドキュメントは、株式クエリを入力するための Stock: プロンプトを含んだフォームをユーザに表示します。次に、このドキュメントの HDML バージョンを示します。
コード リスト 4-4 stockDemo ディレクトリの hdml サブディレクトリ内の stockAlert.jsp
<%@ page contentType="text/x-hdml"%>
<!-- Copyright (c) 2001 by BEA Systems, Inc.
All Rights Reserved. -->
<HDML VERSION="3.0" TTL="0" PUBLIC="TRUE">
<ENTRY name="first" KEY="stock">
<ACTION TYPE="ACCEPT" TASK="GO"
DEST="/stockDemo/StockAlert?stock=$(stock)">
Stock:
</ENTRY>
</HDML>
リクエスト側のデバイスはマークアップ言語ドキュメントにアクセスし、次のサンプル ディスプレイに示すとおり、Stock: プロンプトを出力します。
図4-12 stockDemo のサンプル ディスプレイ
ユーザの入力（株式名）に基づいて、HTTP リクエストが stockDemo の HTTP サーブレットに対して行われ、クエリ パラメータ（stock）がサーブレットの URL に追加されます。サンプル フレームワークは、適切な displayPrice.jsp ページ（stockDemo サンプル ディレクトリの wml、hdml、または html サブディレクトリに格納されている）の場所と、リクエストされた株式の値（YaHoo! から取得）を返します。選択された stockAlert.jsp は、マークアップ言語固有のドキュメントを生成してリクエスト側デバイスに返し、リクエスト側デバイスはそのマークアップ言語ドキュメントにアクセスしてそのドキュメントを画面に出力します。次の図に、stockDemo アプリケーション フローとユーザ入力を示します。
図4-13 携帯電話からの株式相場のチェック-サンプル
travelDemo サンプルには、クライアントから受信したより複雑なフォームのデータを処理する方法が示されています。次の図に、そのデータ フローの概要を示します。
図4-14 travelDemo アプリケーションへのアクセス
travelDemo サンプル アプリケーションは、ログイン フォームから始まる一連のフォーム ドキュメントをリクエスト側デバイスに送信します。ユーザ名 x とパスワード y を使用してログインに成功すると、travelDemo の home.jsp はデバイス固有の旅行フォーム ドキュメントを生成してリクエスト側デバイスに返します。次に、そのドキュメントの HTML バージョンを示します。
コード リスト 4-5 travelDemo ディレクトリの html サブディレクトリ内の home.jsp
<html>
<!-- Copyright (c) 2001 by BEA Systems, Inc.
All Rights Reserved. -->
<HEAD>
<TITLE>Home</TITLE>
<meta name="palmcomputingplatform" content="true">
</HEAD
<body>
<h1>TravelDemo Homepage</h1>
<ul>
<li><a href="<%=
response.encodeURL("/travelDemo/FindAFlight")%>">
Book a flight</a>
<li><a href="<%=
response.encodeURL("/travelDemo/NotImplemented")%>">
Book a hotel</a>
<li><a href="<%=
response.encodeURL("/travelDemo/NotImplemented")%>">
Book a car</a>
<li><a href="<%=
response.encodeURL("/travelDemo/NotImplemented")%>">
View reservations</a>
<li><a href="<%=
response.encodeURL("/travelDemo/NotImplemented")%>">
View account</a>
<li><a href="<%=
response.encodeURL("/travelDemo/Logout")%>">Logout</a>
</ul>
</body>
</html>
リクエスト側のデバイスは旅行フォーム ドキュメントにアクセスして、次のサンプル ディスプレイに示すとおり、そのドキュメントを出力します。
図4-15 travelDemo のサンプル ディスプレイ
このドキュメントには、フライト、ホテル、車の予約、予約またはアカウントの確認、またはログ アウトのオプションが表示されます。実際に表示されるオプションは、リクエスト側デバイスの種類によって異なります。
注意: Book a hotel、Book a car、View reservations、および View account は、travelDemo サンプル アプリケーションでは実装されていません。
ユーザが Book a flight を選択すると、新しい画面が表示され、Cheapest at any time および Cheapest on specific days というオプションが示されます。これらのオプションの 1 つを選択した場合、次の From: プロンプトでは sfo（サンフランシスコ国際空港）が、To: プロンプトでは ewr（ニューアーク国際空港）が唯一の有効なユーザ入力となります。次の図に、travelDemo アプリケーション フローとユーザ入力を示します。
図4-16 携帯電話からのフライトの予約-サンプル
ユーザの入力に基づいて、travelDemo は応答を生成してリクエスト側デバイスに転送します。この応答は「あらかじめ決められた」応答です。このため、ユーザーは travelDemo サンプル アプリケーションにアクセスしても、実際にフライト、ホテル、車の予約や、予約またはアカウントの確認を行うことはできません。
複数ターゲット サンプル アプリケーション用の追加ソフトウェアのインストール
helloWorld、stockDemo、および travelDemo サンプル アプリケーションを実行するには、以下のソフトウェアをインストールする必要があります。
無線クライアント エミュレーション ソフトウェアを販売しているベンダのリストについては、WebLogic Server の samples\examples\wireless\tools\emulators.txt ファイルを参照してください。
サンプル Web アプリケーションのディレクトリ階層は、WebLogic Server の config\examples\applications ディレクトリに格納されています。helloWorld、stockDemo、および travelDemo サンプルを構築する場合、config\examples ディレクトリにはサンプル アプリケーション用に作成される展開形式の war ファイルが格納され、config\examples\applications ディレクトリにはサンプル フレームワーク用に作成される jar ファイルが格納されます。
helloWorld、stockDemo、または travelDemo サンプル アプリケーションの構築、コンフィグレーション、および実行手順については、対象サンプルのソース ファイルが格納されているサンプル ディレクトリ（helloWorld、stockDemo、travelDemo）内の package-summary.html ファイルを参照してください。これらのサンプルを構築すると、サンプル フレームワークも構築されます。
|
|
