|
|
この章では、BEA AquaLogic Data Services Platform のインストールに含まれている Avitek 小売サンプル アプリケーション (RTLApp) について概説します。 また、RTLApp の開発に使用されたデータ ソースや、その他のアプリケーション コンポーネントについても説明します。
Avitek は、何度かの買収によって成長を遂げた架空の小売業者です。 衣料品の販売業者として創業しましたが、最近になって電子機器の小売業者を合併してビジネスを拡大し、経理や Web 開発などのコスト センターを統合しました。 この買収のため、同社はまったく異なる 2 種類の注文管理システム (OMS) を利用して電子機器と衣料品の注文を管理しています。 Avitek では、顧客プロファイル情報の管理に顧客関係管理 (CRM) システムを使用しています。 また、電子機器のサポート事例を管理するため、顧客サービス システムも使用しています。
新たに統合された IT 部門は、短期および中期の全般的な目標として以下を設定しています。
最も簡単と思われる解決策は、顧客がセルフサービスで利用する Web サイトを構築し、これをサポート担当者からも利用できるようにすることです。 この Web サイトでは、異なるバックエンド リソースを簡単に統合するための手段を提供し、システム間の双方向の通信 (読み取り/更新) を実現する必要があります。 また、異なるシステムを利用する複雑さをユーザに感じさせない仕組みも提供する必要があります。
Web サイトのフロントエンド アーキテクチャは、顧客が自分でプロファイル情報を更新したり、注文内容を確認/変更したりするための顧客セルフサービス ポータルを提供します。 バックエンド アーキテクチャは、以下の 5 種類のデータ ソースにアクセスします (図 6-1 を参照)。
このプロジェクトのコード ネームは 「RTLApp」に決まりました。
まず、RTLApp の開発環境と Web アプリケーションが利用可能であることを確認します。 IDE で RTLApp を起動するには、「インストールの検証」で説明されている手順を実行します。この手順には、BEA WebLogic Server の起動も含まれています。
WebLogic Workshop から RTLApp を実行する際の手順は、IDE を起動する手順に似ています (すでに Workshop で RTLApp をビルドおよびデプロイしてある場合は手順 4 に進んでください)。
[スタート｜すべてのプログラム｜BEA WebLogic Platform 8.1｜BEA AquaLogic Data Services Platform 2.5｜Examples｜RTL Demo｜Launch RTL Demo Sample Server]
| 注意 : | すべてのサンプル、サンプル チュートリアル、および RTLApp サンプル アプリケーションは、次の場所に格納されている ldplatform ドメインで実行するように設計されています。 |
<bea_home>/weblogic81/samples/domains| 注意 : | 各種のサンプルや例で必要となるデータも、このドメインに格納されています。 |
| 注意 : | サンプル ドメイン サーバを起動している間に、手順 2 を進めることができます。 |
RTLApp.work を実行して、WebLogic Workshop と RTLApp を起動します。<bea_home>/weblogic81/samples/liquiddata/RTLApp/RTLApp.work
RTLApp ([アプリケーション] ペインの最上位ノード) を右クリックし、コンテキスト メニューから [アプリケーションのビルド] を選択します。 WebLogic Workshop に、ビルドのステータスが表示されます。 ステータス メッセージで、ビルドが正常に完了したことを確認します。
demoPageFlowController.jpf をダブルクリックします。 このファイルは、次のフォルダに格納されています。RTLSelfService\Pages
[デバッグ｜開始]
ダイアログ ボックスに示されている名前の 1 つを使用してログインします。 選択するログイン名をマウスでポイントするだけで、ユーザ名とパスワードが自動的に入力されます (図 6-2 を参照)。
小売サンプル アプリケーションには、多くの IT 部門が直面する異種データ統合の問題が、単純化された形で含まれています。 課題としては以下が考えられます。
これら以外にも、 この大容量データ ソリューションはスケーラブルか、 全社規模で再利用可能か、 元のデータ ソースはアプリケーションに対して透過的か (それとも、アプリケーションを微調整するたびにデータ ソースを調整する必要があるか)、 基底のデータをどうしても変更しなければならない場合にそれをアプリケーション層に簡単に反映できるか、といった点が問題になる場合もあります。
異種データの統合においては、非常に多くの課題を解決する必要があります。
Avitek のマーケティング部門からの委託を受けて実施された調査の結果、同社の顧客は、注文の追跡と顧客情報の更新に要する通話待ち時間に不満を抱いていることが判明しました。 フォーカス グループでは、セルフサービス Web サイトのアイデアが多くの支持を集めました。 顧客サービス部門もこのアイデアに同意しました。同部門では何年も前からセルフサービス サイトの実現を要望していましたが、常にそのコストが予算を上回っていたのです。 しかし、今回はマーケティング部門の支持も得ています。
サイトの要件は単純なように見えます。 顧客が以下の操作を実行できるようにすればよいわけです。
顧客がこのレベルの操作をセルフサービスで実行できるようになれば、結果的に Avitek にとってもかなりの経費削減になります。
マーケティング部門と顧客サービス部門の合同チームは、Web アプリケーションの保守要件を以下のようにまとめました。
アプリケーション/UI 設計者は、必要となる JSP の仕様の検討を開始しました。 ページの設計はそれほど難しくありません。 ただし、データが必要になるため、合併によって統合された IT 部門に電子メールを出すことにしました。
IT 部門のデータ設計者は、データ要件を分析していて問題に直面しました。 アプリケーションで必要になる情報は、顧客データ (1 番目のデータ ソース)、まったく異なる 2 つの部門の注文データ (さらに 2 種類のデータ ソース)、および顧客サポート データ (4 番目のデータ ソース) です。これら 4 つの異種データ ソースを調査した結果、これらのデータ ソースのデータを統合する作業は複雑で時間がかかり、将来的にデータのメンテナンスが大きな問題になることに気づきました。 課題が浮かび上がったのは以下の点です。
最もやっかいな問題は、アプリケーションで必要な特殊コードがほとんど再利用できないことです。
IT 部門が直面している最も困難な課題の 1 つは、分散データの統合ビューを開発することです。 利用可能なすべてのデータ ソースを標準化しても、新しいデータ ソースを追加することになれば、それまでのデータ統合ソリューションは使い物になりません。
この問題は、多くの企業が抱えている非常に一般的な問題です。最先端の企業でさえもデータ統合の課題に直面しており、それが原因で毎年何千もの重要なアプリケーションが、開発されなかったり、完成が遅れたり、大幅に妥協して出荷されたりしています。
一方、RTLApp チームは以下の条件でソリューションを探しました。
Avitek は、一見単純に思われた RTLApp にも多くの課題があることに気づきましたが、それらを解決できる製品 AquaLogic Data Services Platform を見つけました。AquaLogic Data Services Platform は以下のような特長を備えていました。
データ アクセス。 AquaLogic Data Services Platform では、簡単に作成できる「仮想データ アクセス レイヤ」を使用して、社内、社外を問わずどこからでも情報にアクセスできます。 アクセスしたデータは、AquaLogic Data Services Platform サーバに格納されている再利用可能なクエリとビューを組み合わせることで容易に集約できます。
クエリの開発。 単一アクセス ポイントからデータを収集したら、これらの異種ソースからのデータを結合して、より特殊なクエリ向けの再利用可能な共通ビューを表すクエリ関数を簡単に作成できます。
AquaLogic Data Services Platform アーティファクト (データ サービス内のクエリ関数) は、非常に理解しやすい宣言形式です。
クエリのデプロイメント。 開発したクエリは、さまざまなアクセス方式 (AquaLogic Data Services Platform Mediator API、データ サービス コントロール、JDBC、または Web サービス) でクライアント アプリケーションに簡単に統合できます。
統合。 RTLApp のビジネス ロジックは、NetUI と Workshop のページ フロー機能によって提供されます。 しかし、AquaLogic Data Services Platform クエリは、任意の J2EE アプリケーションのビジネス ロジックの中で容易に統合および管理できます。
RTLApp は、AquaLogic Data Services Platform によって生成されるクエリが、まったく種類の異なるデータ ソースからのデータをどのように集約するかを示すサンプル アプリケーションです。このようなクエリを使用することで、データに単一のポイントからアクセスでき、この単一アクセス ポイント自体もアプリケーションに簡単に統合できます。
| 注意 : | RTLApp の動作を単純化するため、このドキュメントで説明する複数のデータ ソースのシミュレーションは、AquaLogic Data Services Platform に付属の PointBase RDBMS を使用して行います。 元の実装では、これらのデータベースが各大手ベンダの RDBMS システムになっています。 |
<WL_HOME>/weblogic81/samples/domains/liquiddata/RTLApp
RTLApp を作成するための RTLApp コントロール、ページ、プロセス、およびリソースは次のディレクトリに格納されています。
<WL_HOME>/weblogic81/samples/domains/liquiddata/RTLSelfService
RTLApp で使用するスキーマの一部は次のディレクトリに格納されています。
<WL_HOME>/weblogic81/samples/domains/liquiddata/schemas
その他のコンポーネントは、それぞれのデータ サービス内に格納されています。
RTLApp の Workshop .work ファイルは次のディレクトリに格納されています。
<WL_HOME>/weblogic81/samples/domains/liquiddata/RTLApp/RTLApp.work
AquaLogic Data Services Platform を WebLogic Platform と一緒にインストールした場合は、RTLApp のソース コードに Workshop からアクセスできます。 詳細については、「RTLApp のソースの表示」を参照してください。
RTLApp では、さまざまな BEA テクノロジが使用されています。
RTLApp は非常に単純ですが、データが 4 つの異種データ ソースに分かれているため、基底データをどのように取得するかが課題になります。 データ ソースとしては以下があります。
この節では、一部の RTLApp データ サービスによって実行される処理について説明します。
以下の物理データ サービスは、アプリケーションで必要になる物理データ ソースに対応します。
RTLApp の物理データ サービスは、ほとんどが読み取り関数を備えています。また、一部の物理データ サービスは、リレーショナル ソース間の主キー/外部キー関係に関連付けられた 1 つまたは複数のナビゲーション関数も備えています。
論理データ サービス (物理データ サービスまたは別の論理データ サービスに基づくサービス) は、RTLServices というフォルダに格納されています。 複数のデータ ソースに対する読み取り関数やナビゲーション関数は、これらの論理データ サービス内で開発および管理されています。
表 6-1 に、データ ソース、主要なデータ要素 (RDBMS システムの場合であればテーブルとカラム)、サンプル アプリケーション JSP、および RTLApp Web ページの間の関係を示します。
小売サンプル アプリケーションをまだ起動していない場合は、「Avitek サンプル アプリケーション (RTLApp) のクイック スタート」の説明に従って起動します。 ユーザ名は、Steve、Jack、Tim、Homer、Jerry のいずれかを選択できます。 どのユーザでも、パスワードは weblogic です。
顧客がログインすると、[MyProfile] 画面が表示されます。 この画面から、未処理の注文、注文の履歴、サポート、検索などの画面に移動したり、ログアウトしたりできます。 顧客は、未処理の注文を編集したり (図 6-4 を参照)、完了した注文の詳細を確認したりできます。 検索は、商品の説明情報、開始日、終了日、注文金額の範囲を指定して実行できます。
このサンプル アプリケーションでは、以下を始めとする AquaLogic Data Services Platform 機能の一部も使用されています。
[My Profile] ページには、分散されたデータを自動的に読み取り/書き込みするための AquaLogic Data Services Platform 機能が使用されています。
![[My Profile] ページ](wwimages/myprofilepage.gif)
[My Profile] ページには、顧客情報とクレジット カード情報が統合されています。 ユーザは、個人プロファイル、住所、およびクレジット カードの情報を変更できます。 変更は、まず [MyProfile] ページに反映されます。 内容に誤りがないことを確認して [Submit All Changes] をクリックすると、その変更がそれぞれのデータ ソースに永続化されます。
このページは、ProfileView.jsp および ProfileView データ サービス (ProfileView.ds) に基づいて作成されています。
RTLApp の [Open Order] ページには、顧客の電子機器と衣料品の未処理注文が統合されています。
![RTLApp の [Open Order] ページ](wwimages/wk_app_home_pg.gif)
データの変更は、ユーザから見ると単に選択と入力を行う操作です。 しかし、電子機器の注文を更新するための基底のメカニズム (Web サービスとして実行する処理) と、衣料品の注文を更新する基底のメカニズムはまったく異なります。
電子機器の注文は、Web サービスから派生します。 このサンプル アプリケーションでは、電子機器の注文の更新に、Web サービスのカスタム更新機能を利用しています。
衣料品の注文はリレーショナル データベースから派生しており、更新は自動的に行われます。
[Open Orders] ページの [Enable Cache] オプションをオンにすると、このページの基底の機能でキャッシュが使用されます。 [Refresh Data] ボタンを使用すると、キャッシュが有効になっている場合と無効になっている場合では処理速度がかなり違うことを確認できます。
[Make Electronics Source Unavailable] ボタンをクリックすると、Web サービスが無効になります。 この操作によって、[Open Orders] ページがリフレッシュされます。 データ ソースが使用不可になっても、一部の結果 (衣料品の注文) は以前どおり取得できる点に注目してください。
[Show SQL Report] オプションは、JDBC によるデータへのアクセスを実演します。 この機能では、AquaLogic Data Services Platform のクエリ関数に、Crystal Reports などのレポートおよびビジネス インテリジェンス ツールを統合しています。
[Open Order] ページは、defaultView.jsp という名前の JSP で制御されています。 図 6-4 のキャプションは、基底のデータ ソースを示しています。 このページのルック アンド フィール (フォントなど) は、カスケーディング スタイルシートで設定されています。
RTLApp の [Order History] ページには、電子機器と衣料品の注文の履歴情報が表示されます。
![RTLApp の [Order History] ページ](wwimages/orderHistoryPg.gif)
[Apply] ボタンをクリックすると、指定した条件に基づいてページがリフレッシュされます。
AquaLogic Data Services Platform のセキュリティは、注文の数を [All Orders] に設定してみるとよく分かります。 その状態で [Restrict Access] オプションをクリックすると、データが自動的に編集され、注文金額が $500.00 未満の注文のみが表示されます。
[Order History] ページは、orderHistory.jsp という名前の JSP で制御されています。
[Support] ページには、ログインしている顧客の未解決のサポート事例に関する情報が表示されます。
![RTLApp の [Support] ページ](wwimages/supportPage.gif)
[Search] ページでは、注文日、商品、または金額に基づいて特定の注文を検索できます。 基底のコードは、AquaLogic Data Services Platform のアド ホックなクエリ関数を実行します。
![RTLApp の [Search] ページ](wwimages/searchForm.gif)
ユーザは、検索フィールド条件 (商品の説明、開始日、終了日、注文金額の範囲) を自由に組み合わせて検索できます。
このページの JSP は、小さな Java プログラムを起動します。このプログラムは、顧客の入力を取り込んで、選択されたパラメータに基づいて XQuery を生成します。
RTLApp のデータ サービス、関数、JSP ページ、および接続ロジックは、Workshop で作成されています。 RTLApp のソースも Workshop で表示できます。
RTLApp アプリケーションを起動するには、Workshop で RTLApp.work ファイルを開きます。 フル パスは次のとおりです。
<WL_HOME>/weblogic81/samples/domains/liquiddata/RTLApp/RTLApp.work
| 注意 : | すでに WebLogic Workshop を実行しているか、これまでに異なるサーバ設定で実行したことがある場合は、アプリケーション サーバのプロパティ設定を変更しなければならない可能性があります。 必要な場合は、WebLogic Workshop メニューで次のように選択します。 |
Tools 
Application Properties WebLogic Server
WebLogic Workshop で RTLApp を開くと、最初にアプリケーション コンポーネントと作業領域が表示されます。
![小売サンプル アプリケーションの初期画面 ([アプリケーション] ビュー)](wwimages/wk_initialview.gif)
WebLogic Workshop では、開発中のアプリケーションをコンポーネントまたはファイルとして処理できます。 Web ページの表示と実行、およびアプリケーション ロジックの開発とテストを行うことができます。
| 注意 : | IDE の詳細、および IDE を使用してエンタープライズ アプリケーションをビルドする方法については、「WebLogic Workshop 入門」を参照してください。 オンライン ドキュメントには、豊富な例とチュートリアルが掲載されています。 |
WebLogic Workshop Samples アプリケーションには、データ アクセスと XML に関するいくつかのサンプルが収められています。 次のディレクトリを参照してください。
| 注意 : | <WL_HOME>/samples/workshop/SamplesApp/SamplesApp.work |
すべての WebLogic Workshop アプリケーションと同様に、RTLApp のコンポーネントもフォルダに整理されています。 この節では、これらのフォルダとその中身について簡単に説明します。
DataServices フォルダには、物理データ サービスと論理データ サービスの両方が格納されています。
物理データ サービス (物理データ ソースに基づくデータ サービス) には、衣料品の注文 (ApparelDB)、電子機器の注文 (ElectronicsWS)、クレジット カード情報 (BillingDB)、および顧客サービス情報 (ServiceDB) があります。 すべての論理データ サービスは、RTLServices フォルダに格納されています。
物理および論理データ サービス両方に基づくモデル ダイアグラムは、MODELS フォルダに格納されています。 特に注目すべきは、アプリケーション内のすべての物理データ サービスをモデル化した EnterpriseDataModel です。 論理モデル ダイアグラムとしては、RTLApp を構成するデータ サービス関係をまとめた RTLApp モデルなどがあります。
| 注意 : | DataServices フォルダ内の Demo フォルダには、データ サービスのベースとして使用されている文字区切り形式ファイル データ、XML ファイル データ、および Java 関数の単純な例が格納されています。 |
ElecWS フォルダには、RTLApp で使用する電子機器の注文データ サービスのベースとして機能する Web サービスが格納されています。
小売サンプル アプリケーションの構成要素の多くは、RTLSelfService フォルダから利用できます。
RTLControl.jcx ファイルが格納されています。 このファイルは、AquaLogic Data Services Platform アプリケーションで使用される各クエリ関数のメソッドを含むデータ サービス コントロールによって生成されます。 デザイン ビューでは、これらの関数が一覧で表示されます。 関数名をクリックするとソース ビューに切り替わり、その関数に関する以下のような詳細が表示されます。
RTLControl の詳細については、「コントロール」を参照してください。
demoPageFlowController.jpf が格納されています。
このページの詳細については、「アプリケーション ページ」を参照してください。
RTLApp の Schemas フォルダには、論理データ サービスおよび XML Bean クラス用に開発されたスキーマが格納されています。
RTLControl.jcx には、データ サービス コントロールの開発者によって選択されたストアド クエリ セットに基づく自動生成メソッドが格納されています。 WebLogic Workshop 内の AquaLogic Data Services Platform クエリへのアクセスについては、『クライアント アプリケーション開発者ガイド』の「Accessing Data Services from Workshop Applications」にある「Select Data Service Functions to Add to a Control」を参照してください。
図 6-12 には、RTLControl JCX ファイルの RTLOrderSummary メソッドのソース ビューの一部を示します。 なお、クエリのターゲット スキーマの名前は、コメントとして記述されます。
データ サービス コントロールの各メソッドは、クエリ関数に対応しています。 各メソッドは、XMLBean 型を返します。 XMLBean はコントロールの作成時に生成され、WebLogic Workshop アプリケーションの Libraries フォルダに格納されます。
RTLSelfService フォルダ内の Pages フォルダには、RTLApp を構成する JSP (Java Server Page) が格納されています。 これらの JSP は、クエリ RTLControl と NetUI グラフィカル要素を使用して WebLogic Workshop で作成されたものです。
RTLApp は、WebLogic Workshop の PageFlowController によって管理される JSP で構成されています。 PageFlowController のファイル名は demoPageFlowController.jpf です。
アプリケーション ロジックから見た場合、ユーザが [次へ]、[前へ]、[OK]、[取消し] などのオプションを選択してページのコントロールを解放すると、アプリケーション ロジックが PageFlowController に戻ります。 このロジックが処理されると、ユーザに対して適切な Web ページが表示されます。
WebLogic Workshop を使用すると、ページ フローをプログラムから、またはグラフィカルに検査、変更、および拡張できます。 ページ フローのビューは、ページ フロー ビュー、アクション ビュー、ソース ビューの 3 つです。
WebLogic Workshop ページ フロー図 (図 6-14) は、JSP 間の関係をグラフィカルに示したもので、ユーザ アクションによって決定されるモードレス ページ フローも含まれています。
特定のページ名をクリックすると、WebLogic Workshop 開発ブラウザでそのページが開きます。
[アクション ビュー] タブは、RTLApp に関連付けられているページ フロー アクションの場所を探すために使用します。
アクション項目をクリックすると、demoPageFlowController が開き、コードの該当部分が表示されます。
PageFlowController ファイルは、以下の要素で構成されています。
AquaLogic Data Services Platform についてより詳しく知るためのドキュメントには、次に示す BEA edocs サイトから簡単にアクセスできます。
  
|
