| Oracle Application Development Framework Forms/4GL開発者のための開発者ガイド 10g（10.1.3.0） B40013-02 |
|
 戻る |
 次へ |
この章では、ビジネス・サービスの構築のための主要機能に関する説明など、Oracle ADFのADF Business Componentsレイヤーの概要について説明します。
この章の内容は次のとおりです。
J2EEプラットフォームでは、サービスの開発およびデプロイのために、サーバー側のモデルが定義されます。ただし、実際のビジネス・アプリケーションで必要とされる強力な機能の記述、再使用、カスタマイズの検討は、各開発チームのメンバーに任されています。特に、J2EEの仕様では次のアプローチについては言及していません。
ビジネス・アプリケーション・ロジックの一元的な記述および実行
ビジネス・ロジックの複数のアプリケーションでの再使用
現在のタスクのために特別に設定されたビジネス・データの、更新可能なビューへのアクセス
アプリケーション配布後の、ビジネス機能のメンテナンスおよびカスタマイズ
オラクル社では、長年にわたるJ2EEプラットフォーム上でのE-Business Suiteアプリケーションの構築経験に基づき、開発者が独自にJ2EEソリューションを構築する際、これらのアクティビティに最も多くの時間と労力が費やされることを理解しています。ADF Business Componentsは、これらの困難なタスクに対して規範となるアプローチを提供するように設計されています。また、再使用可能なソフトウェア・コンポーネントのライブラリや、設計時のプラグインをJDeveloperに提供することによって、規範となる実証済アプローチの理解を容易にします。
Oracle ADFのADF Business Componentsテクノロジは、Oracle Applications、Oracle Tools、Oracle Server Technologiesの各部門の長年にわたる共同の設計および開発の積み重ねであり、高度に設計されたデータベース中心のエンタープライズJ2EEアプリケーションの現在および今後の構築について、オラクル社の構想を実際的に示したものです。
Oracle ADF全体のその他のレイヤーと同様、ADF Business Componentsは、4,000名以上のオラクル社内のアプリケーション開発者と、オラクル社のパートナー企業を含む何千もの外部の顧客が日常的に使用しているテクノロジです。これは、ADF Business Componentsが信頼性の高いソリューションである証です。
ADF Business Componentsは、ビジネス・サービスを最も生産性の高い方法で作成、デプロイおよび維持するための基礎的な要素です。ADF Business Componentsは、一般的な開発タスクの大部分を宣言的にすることによって開発時間を短縮する、高度なソフトウェアの一連の基礎的要素を提供し、エンタープライズJ2EEビジネス・アプリケーションを驚くほど簡単に開発、デプロイおよびカスタマイズできます。これは、導入後すぐに、次の処理に必要な一般的な機能を管理するために使用できます。
自動的にデータベースと統合するコンポーネント内のビジネス・ロジックの、生産性の高い方法での記述およびテスト
複数のアプリケーションタスクをサポートする、データの複数のSQLベースのビューを介したビジネス・ロジックの柔軟な再使用
ブラウザ、デスクトップ、モバイル、Webサービス・クライアントからの、ビューへの効率的なアクセスおよび更新
デプロイ済のアプリケーションの変更を必要としない、アプリケーション機能のレイヤーでのカスタマイズ
ADF Business Componentsでは、一般的なアプリケーション配置機能に関連する大量のコーディングとテストが不要になるため、アプリケーション開発者はビジネス・ソリューションの実装に集中することができます。ADF Business Componentsは、Javaクラスの基盤を提供します。これはビジネス階層アプリケーション・コンポーネントによって拡張され、次の領域で必要とされる様々な設計パターンの強固な実装が活用されます。
必要なデータのみをクライアントに表示するデータ・モデルの設計
データ・モデルの一部としての複雑なマスター/ディテール階層の組込み
コード記述を必要としない、エンド・ユーザーのQuery-By-Example（QBE）データ・フィルタの実装
データ・モデル変更のビジネス・ドメイン・オブジェクト・レイヤーとの自動調整
データベースに対する変更の自動検証および保存
必須フィールド、主キーの一意性、データの精度と規模および外部キー参照の宣言的な実行
マルチレベルでの検証サポートを含めた、プログラムまたは宣言による、簡単なビジネス・ルールと高度なビジネス・ルール両方の簡単な取得および実行
ビジネス・ドメイン・オブジェクト間の関係のナビゲートおよび複合コンポーネント関連の制約の実行
ビジネス・サービス・アプリケーション・ロジックによるユーザー・インタフェースにおける変更の自動反映
関連する表からの参照情報の取得と、ユーザーによる外部キー値の変更時の自動保持
Web階層の自動的な状態管理による、複数ステップのWebベース・ビジネス・トランザクションの簡略化
コードを必要としない、イメージ、ビデオ、音声およびドキュメントの処理
データの複数ビューにおける、保留中のデータ変更の同期化
複数アプリケーションにおける、プロンプト、ツールチップ、フォーマット・マスク、エラー・メッセージの一環した適用
メタデータ駆動型ユーザー・インタフェースまたはアプリケーション機能をサポートする、ビジネス・コンポーネントに対するカスタム・メタデータの定義
行単位の状態管理を簡略化する動的属性の、実行時の追加
ベスト・プラクティスであるインタフェース・ベースのプログラミング・スタイルの適用
自動JAAS統合および監査メンテナンスによるアプリケーション・セキュリティの簡略化
「一度記述すれば、どこでもデプロイ可能」: プレーンなJavaクラス、EJBセッションBean、Webサービスと同様のビジネス・サービスの使用
クライアント・コードの変更を必要としない、2層から3層へのデプロイの切替え
効率的なバッチ操作による、リモート・クライアントに対するネットワーク通信量の削減
ソース・コードの変更を必要としない、提供後のコンポーネント機能の拡張
アプリケーションの修正を必要としない、提供済コンポーネントの拡張版へのグローバルな代替
カスタマイズが失われない、または下方カスタマイズの手動での再適用を必要としない、アプリケーション・アップグレードの提供
これらの機能をまとめて要約すると、J2EEビジネス・サービス・レイヤーに対してADF Business Componentsを使用することにより、業務を簡略化できるということになります。ビジネス・サービスを実装するためのADF Business Componentsの主要なコンポーネントは、次のとおりです。
エンティティ・オブジェクト
エンティティ・オブジェクトは、データベース表内の1行を表し、すべてのDML操作を処理することでデータ変更を簡略化します。また、該当する行のビジネス・ロジックをカプセル化し、ビジネス・ルールが一貫して適用されることを保証します。エンティティ・オブジェクトを他のエンティティ・オブジェクトと関連付け、基盤となるデータベース・スキーマの関係を反映することで、複数のアプリケーションで再使用できるビジネス・ドメイン・オブジェクトのレイヤーを作成します。
アプリケーション・モジュール
アプリケーション・モジュールは、UIクライアントがアプリケーション・データの操作に使用するトランザクション・コンポーネントです。アプリケーション・モジュールによって、エンド・ユーザー・タスク関連の作業論理ユニットに関する、更新可能なデータ・モデルやトップレベルのプロシージャおよびファンクション（サービス・メソッド）を定義します。
ビュー・オブジェクト
ビュー・オブジェクトはSQL問合せを表し、その結果の作業を簡略化します。使い慣れたSQL言語を十分に活用し、エンド・ユーザーのタスクが必要とする手近な形に、データを正確に結合、計画、フィルタ、ソートおよび集約します。これには、ビュー・オブジェクトを他のビュー・オブジェクトにリンクし、複雑度にかかわらずマスター/ディテール階層を作成する機能も含まれます。エンド・ユーザーがユーザー・インタフェースを使用してデータを変更すると、ビュー・オブジェクトはエンティティ・オブジェクトと連携し、変更内容が一貫して検証され、保存されます。
ベース・コンポーネントでは、高度な組込み動作によってすべての一般的なケースを処理しますが、その機能を活用した場合でも、必要なときにいつでも使用できるという利点が損われることはありません。ベース・コンポーネントで提供されるすべての自動的な動作は、戦略的なコードの数行の記述で簡単に上書きできます。そのため、すべての場面で動作方法は制限されません。
ADF Business Componentsでは、J2EEでの開発以前に開発者が使用していたエンタープライズ4GLツールに類似した機能を実装するコンポーネントを提供しています。この項では、ADF Business Componentsの主要コンポーネントが、他の4GLツールで使用していた機能に、どのように概念的に位置付けられるかを説明します。
ADF Business Componentsは、どのようなユーザー・インタフェースでも使用可能な方法で、使い慣れたOracle Formsのデータ中心のラインタイム機能をすべて実装します。Oracle Formsの各フォームには、キャンバス、ウィンドウ、警告、LOVなどのビジュアルなオブジェクトと、データ・ブロック、リレーション、レコード・グループなどのビジュアルでないオブジェクトの両方が含まれます。各データ・ブロック項目には、Foreground Color、Bevelなどのビジュアルなプロパティと、Data Type、Maximum Lengthなどのビジュアルでないプロパティの両方が含まれます。Formsで定義される、異なるイベント処理のトリガーも、ビジュアルなものとビジュアルでないものに分けられます。たとえば、WHEN-BUTTON-PRESSEDやWHEN-MOUSE-CLICKEDなどはフロントエンドのUIに関連した本質的にビジュアルなトリガーであり、WHEN-VALIDATE-ITEMやON-INSERTなどはバックエンドのデータ処理に関連が深いトリガーです。ビジュアルなものとビジュアルでないものを組み合せることにより、理解しやすくできる反面、再使用が困難になる場合があります。UI関連の要素とデータ関連の要素を明確に分離することにより、バックエンドのビジネス・ロジックに影響を与えることなく、ユーザー・インタフェースを簡単に再設計できます。また、複数の異なるフォームおいて、バックエンドのビジネス・ロジックの再目的化が容易になります。
UIとデータを分離して考えるために、現在のフォームを半分にして、ビジュアルでないデータ関連の部分のみにすることを検討してください。残るものはデータ・ブロックのコンテナ、リレーションおよびレコード・グループです。このコンテナは継続してデータ・ブロックに対してデータベース接続を提供し、トランザクションのコミットまたはロールバックを共有し、調整する役割を果します。また、ビジュアルでない検証およびトランザクション・トリガーによる、デフォルトのデータ処理の動作の拡張または変更も引き続き可能です。ビジュアルでないオブジェクトとは、データおよびビジネス・ロジックはあるがユーザー・インタフェースの要素のない、スマート・データ・モデルまたは汎用アプリケーション・モジュールの一種です。このアプリケーション・モジュールは、すべてのビジュアル要素と分離することで、今後必要となるすべてのユーザー・インタフェースでこれらのモジュールをデータ・サービスとして使用可能にすることを目的としています。
このアプリケーション・モジュールにおけるデータ・ブロックの役割について考えます。データ・ブロックでは、SQLを使用してデータベースからデータ行の問合せを行います。また、マスター/ディテール関連と他のデータ・ブロックの調整、WHEN-VALIDATE-RECORDトリガーとWHEN-VALIDATE-ITEMトリガーを使用したユーザーによるデータ入力の検証、有効なユーザーによる変更について、データ・サービスのトランザクションのコミット時のINSERT、UPDATE、DELETE文でのデータベースとの通信などを行います。
経験上、エンド・ユーザーに対しては、現在のタスクに応じた様々な方法でデータのフィルタ処理、結合、ソートやグループ化を行う必要があると考えられます。一方、ビジネス・ドメイン・データに適用する検証規則は、基本的に変更されません。このような観点から、ビジネス・エンティティの検証は一度のみ記述し、これを常にアプリケーション内でのユーザーによるデータの操作に活用することをお薦めします。
こうした柔軟性を持たせるには、データ・ブロック機能をさらに分割する必要があります。アプリケーションで必要とされる、数多くのデータのビューを表すために必要なSQL問合せオブジェクトは1つのみです。また、ビジネス・ルールを順守し、一貫性のある方法で基礎となる表への変更のやり取りを行うには、他のビジネス・エンティティ・オブジェクトが必要となります。このように機能を再分割すると、SQL問合せが同じビジネス・データを表している場合に、同一の基礎となるエンティティ・オブジェクトと連携するビュー・オブジェクトを複数持つことができます。
Oracle ADFでは、すぐに使用できる、Java世界で使い慣れたFormsに基づく機能を実装するJavaコンポーネントを、仮定した明確な機能分離に従って分類された職責とともに提供することによって、前述の部分で想定したUI/データ分割を実現します。
ApplicationModuleコンポーネントは、前述の、フォームの半分を占めるデータです。このコンポーネントは、クライアント・インタフェースで処理が必要なマスター/ディテール関連の問合せに関するデータ・モデルを含む、スマート・データ・サービスです。また、これに含まれるコンポーネントで使用されるトランザクションとデータベース接続を提供します。このコンポーネントには、サービス実装においてカプセル化される、サービス・メソッドと呼ばれるフォーム・レベルのプロシージャおよびファンクションが含まれています。このプロシージャやファンクションのうち、どれをプライベートに設定し、どれをパブリックに設定するかを決定できます。
EntityObjectは、前述のデータ・ブロック機能のうち、フォームの半分を占めるデータの検証およびデータベース変更に関する部分を実装します。フォームの実行時には、この作業はレコード・マネージャで実行されます。レコード・マネージャは、データ・ブロックやその中のデータ・アイテム内の検証トリガーの実行や、データベースへの変更の格納に関する調整を行うため、データ・ブロック内のどの行が変更されたかを追跡します。この処理は、まさにエンティティ・オブジェクトが実行するものです。エンティティ・オブジェクトは基礎となるベース表に関連しており、ビジネス・ドメインのエンティティを表します。また、ビジネス・オブジェクトの検証、デフォルト設定、データベース変更処理に関連するビジネス・ロジックをカプセル化するための場所を提供するコンポーネントです。
ViewObjectによって、前述のデータ・ブロック機能のうち、フォームの半分を占めるデータの取得が実行されます。各ビュー・オブジェクトではSQL問合せをカプセル化し、実行時にはそれぞれの問合せ結果セットを管理します。マスター/ディテール関連で2つ以上のビュー・オブジェクトを接続する場合、その調整は自動的に処理されます。ビュー・オブジェクトを定義する際、すべての問合せ列を、基礎となるエンティティ・オブジェクトにリンクさせることができます。この情報を取得することにより、ビュー・オブジェクトとエンティティ・オブジェクトは実行時に自動的に連携し、現在のタスクに対してユーザーが必要とするビジネス・データの形態にかかわらず、ドメインのビジネス・ロジックを実行します。
PeopleToolsを使用したソリューションの開発経験者は、PeopleToolsコンポーネントの構造をよく理解しています。ADF Business Componentsには、PeopleToolsで使い慣れているデータ・アクセス機能が実装されています。
ヘッドレスなコンポーネントであるアプリケーション・モジュール
ADFはMVCパターンに従い、ビューからモデルを分離します。PeopleToolsコンポーネントで使い慣れているページは、WebベースのアプリケーションのためのJSFコンポーネントやADF Facesコンポーネント、またはデスクトップ・フィデリティ・クライアント表示のためのSwingなどの標準テクノロジを使用し、ビュー・レイヤーで定義されます。
ADFアプリケーション・モジュールは、PeopleToolsコンポーネント・バッファと同様にデータ構造を定義します。データの行セットを生成するADF問合せコンポーネントとの間にマスター/ディテール関係を定義することにより、データと連携するすべてのアプリケーション・モジュールは、必要に応じて、コンポーネント・バッファのスクロール・レベルに類似した自然な階層を再使用できます。
アプリケーション・モジュールは、標準メソッドおよび追加的な開発者定義ビジネス・ロジックへのアクセスを提供するサービス・オブジェクトであり、使い慣れたコンポーネント・インタフェースに類似しています。コンポーネント・インタフェースでは、特定のユーザー・インタフェースに対してヘッドレスなデータ・サービスを提供するために、UIの対話に関連するPeopleToolsのファンクションの数が制限されます。アプリケーション・モジュールは、ヘッドレスなデータ・サービスを提供するという意味ではコンポーネント・インタフェースと類似していますが、既存のユーザー・インタフェースの制限されたビューをラップするという手法ではデータを提供していません。かわりに、アプリケーション・モジュールはビジネス・ロジックとデータ・アクセスのみを処理するよう設計されています。ADFではコンポーネント上にコンポーネント・インタフェースを構築するのではなく、最初にユーザー・インタフェースとは別のアプリケーション・モジュール・サービスを構築します。次に、このサービス上に1つ以上のページを構築し、アプリケーションのエンド・ユーザー・タスクを処理します。
アプリケーション・モジュールは、PeopleToolsコンポーネント・バッファと同じ方法でトランザクション・オブジェクトに関連付けられています。アプリケーション・モジュールは、自身に含まれているコンポーネントに対し、データベース接続を提供します。現在、コンポーネントPeopleCodeとしてトランザクションと関連付けているすべてのロジックは、ADFではアプリケーション・モジュールのロジックとして定義します。
トランザクション内のレコードと関連付けられており、現在、コンポーネント・レコードPeopleCodeまたはコンポーネント・レコード・フィールドPeopleCodeとして記述しているロジックは、アプリケーション・モジュール内では定義されない可能性があります。ADFには、複数のコンポーネントに同じレコードが使用されている場合に再使用しやすくするためのビュー・オブジェクト（後述参照）があります。
レコード定義としてのエンティティ・オブジェクト
エンティティ・オブジェクトは、PeopleToolsレコード定義が基礎となる表やビューへのマッピングであるのと同様に、基礎となるデータ構造に対するマッピングです。一般的には、アプリケーション操作が必要な表ごとにエンティティ・オブジェクトを1つ作成します。
PeopleToolsの変換値を使用して「Customer Status」などのフィールドに有効な一連の値を宣言するのと同様に、ADFではエンティティ・オブジェクトのそれぞれの属性に対し、宣言的な検証を追加できます。現在レコードPeopleCodeやレコード・フィールドPeopleCodeとして記述している、アプリケーション全体に適用されるレコードと関連付けられるすべてのロジックは、ADFではエンティティ・オブジェクトとして定義できます。
行セットと同様のデータ問合せを行うビュー・オブジェクト
PeopleToolsの行セットのように、ビュー・オブジェクトはSQL問合せにより移入できます。行セットと異なるのは、ビュー・オブジェクトの定義にはビジネス・ロジックを含めることができる点です。
コンポーネント・レコードPeopleCodeのロジックは、いずれもビュー・オブジェクトで定義される可能性があります。コンポーネント・レコードPeopleCodeはコンポーネントに直接関連付けられていますが、ビュー・オブジェクトは異なるアプリケーション・モジュールに関連付けることができます。多くのPeopleToolsコンポーネントでは同じレコード定義を使用できますが、Oracle ADFでは複数のアプリケーションにわたってビジネス・ロジックを再使用できます。
ビュー・オブジェクトは、現在のアプリケーションで使用しやすい形でデータの問合せを正確に行います。多くのビュー・オブジェクトは、同じエンティティ・オブジェクト上に構築できます。
PeopleToolsコンポーネントにおけるスクロール・レベルと同様に、マスター/ディテール構造を作成するため、ビュー・オブジェクト間の関係を定義できます。
SiebelToolsバージョン7.0以前のバージョンを使用したソリューションの開発経験者には、使い慣れたすべてのデータ・アクセス機能が、多数の拡張機能とともに、ADF Business Componentsに実装されていることがわかります。
カプセル化されたビジネス・ロジックを含む表オブジェクトであるエンティティ・オブジェクト
Siebel表オブジェクトと同様に、ADFエンティティ・オブジェクトは、列名や物理的なデータ型など、1つの表の物理特性を表します。両方のオブジェクトには、DB内の物理表を作成するDDLを生成するために十分な情報が含まれています。ADFでは、基礎となる表内の外部キーを反映した、エンティティ・オブジェクト間のアソシエーションを定義します。これらのアソシエーションは、ユーザー・インタフェース・ページや画面のビュー・オブジェクト問合せにおけるビジネス情報を自動的に結合するために使用されます。現在のデータ列から参照するLOVオブジェクトは、宣言的なエンティティ検証規則とビュー・オブジェクト問合せの組合せによってADFで処理されます。また、他の宣言またはプログラムによるビジネス・ロジックを、作成するすべてのデータ・ビューで自動的に再使用される表のハンドラ・エンティティ・オブジェクトとともにカプセル化することもできます。
ビジネス・コンポーネントであるビュー・オブジェクト
Siebelビジネス・コンポーネントのように、ADFビュー・オブジェクトは基礎となる物理表表現上に、論理マッピングを設定します。これはどちらもユーザー・インタフェースの要件を満たす、論理フィールド名、データ、計算済フィールドの提供を可能にします。ビジネス・コンポーネントでは、基礎となる様々な表の情報を結合するビュー・オブジェクトを定義できます。関連するADFビュー・リンクは、Siebelリンク・オブジェクトに類似しており、マスター/ディテール関係を定義できます。ADFでは、データをユーザー・インタフェースで必要とされる形にするために、SQL言語の特性を十分に生かすようビュー・オブジェクトを定義できます。
接続とトランザクションを含めたビジネス・オブジェクトであるアプリケーション・モジュール
Siebelビジネス・オブジェクトでは、ビジネス・コンポーネントのコレクションを定義できます。ADFアプリケーション・モジュールでも同様のタスクが実行され、関連するユーザー・インタフェースの一連のページのデータ・モデルの役割を果すマスター/ディテール・ビュー・オブジェクトのコレクションを作成できます。さらに、アプリケーション・モジュールはこのデータ・ビュー・グループに対し、トランザクションおよびデータベース接続のコンテキストを提供します。アプリケーション・モジュールからのオブジェクトに対し複数のリクエストを行うことが可能です。また、これらのオブジェクトは同じトランザクション内に含まれます。
Visual Studio 2003または2005を使用したソリューションの開発経験者は、ADO.NETフレームワークを使用したデータ・アクセスをよく理解しています。ADF Business Componentsには、ADO.NETで使い慣れているすべてのデータ・アクセス機能が、様々な拡張機能とともに実装されています。
ApplicationModuleコンポーネントは、ADO.NET DataSetと同じ役割を果します。これは、ビュー・オブジェクトと呼ばれる行セットのコレクションを表す、強く型付けされたサービス・コンポーネントです。下で説明するように、ADO.NET DataTableに類似しています。アプリケーション・モジュールは、関連するTransactionオブジェクトと連携し、ビュー・オブジェクトが実行するSQL問合せや、エンティティ・オブジェクトによってデータベースに保存された変更に対して、コンテキストを提供します。これは、ADO.NET DataAdapterの役割を果します。
EntityObjectは、強く型付けされたADO.NET DataAdapterと同様のものです。これは特定の表における行を表し、その行の主キーによる検索、挿入、更新、削除およびロックの操作を処理します。ADFでは、これらの文を自分で記述する必要はありませんが、必要に応じてオーバーライドできます。エンティティ・オブジェクトは、属性や基礎となる表の行全体に関連する、検証や他のビジネス・ロジックをカプセル化します。検証は、エンド・ユーザーが基礎となるエンティティ・オブジェクトを参照するすべてのビュー・オブジェクト問合せを使用してデータを更新および保存したときに実行されます。
ViewObjectコンポーネントは、SQL問合せをカプセル化し、結果となる行セットを管理します。基礎となるエンティティ・オブジェクトと関連付けることにより、ユーザーによるそれらの行の検証や変更の保存を自動的に調整します。ビュー・オブジェクトの問合せデータと、エンティティ・オブジェクトのカプセル化されたビジネス・ロジックの連携により、DataTableのすべての利点に加え、ビジネス・ドメイン・オブジェクトのレイヤーに対するビジネス・ロジックの明確なカプセル化が可能になります。ADO.NETデータテーブルのように、ビュー・オブジェクトのデータをXMLとして簡単に扱うこと、およびビュー・オブジェクトでXMLデータを読み取り、その情報に基づいた行の挿入、更新または削除などを自動的に行うことができます。
後続の章で主要コンポーネントについて詳細に説明する前に、Oracle ADFのこのレイヤーの設計および実装に関するいくつかの原則について理解してください。
Oracle ADFの他の機能と同様、ADF Business ComponentsテクノロジはJavaで実装されています。基本となるコンポーネントには、汎用的で、メタデータ駆動型の数多くの機能が実装されており、テスト済で実用的なコードの豊富なレイヤーによって開発時間を短縮できます。ADF Business Componentsのメタデータは、J2EEコミュニティのベスト・プラクティスに準拠しており、明確に分離されたXMLファイル内に各コンポーネントの実行時の動作を構成したメタデータが保持されています。
ADF Business Componentsはビジネス上非常に重要なアプリケーションにおいて使用されることが多いため、サポート契約を締結しているお客様は、ADF Business Componentsレイヤーを含むOracle ADFの完全なソースをOracle Worldwide Supportから入手できます。フレームワークの完全なソース・コードは、問題の診断、およびベース・フレームワーク機能のニーズに応じた正しい拡張を支援するための重要なツールです。
ビジネス・コンポーネントは、プレーンなJavaクラスとXMLファイルを使用して実装されているため、Java仮装マシンが存在するすべての実行環境で使用可能です。つまり、ADF Business Componentsを使用して構築されたサービスは、実行時にアプリケーションのコンテナと呼ばれるJ2EEサーバーの内部と、サーバーの外部の両方で簡単に使用できます。顧客は、コマンドラインのバッチ・プログラム、Webサービス、カスタム・サーブレット、JSPページ、Swingによって構築したデスクトップ・フィデリティ・クライアントなど、様々な構成でアプリケーション・モジュールを日常的に使用します。
ADF Business Componentsを使用して構築されたアプリケーションは、J2EE準拠のアプリケーション・サーバーを含む、Java対応のすべてのアプリケーション・サーバーで実行可能です。4.6.1項「接続、SQLスタイルおよび型マップの選択」で説明したように、様々な最適化を加えたOracleデータベースを対象とするアプリケーションの構築の他、Oracle以外のデータベースと連携するアプリケーションを構築することもできます。
ADF Business Componentsレイヤーは、実際のエンタープライズJ2EEアプリケーション作成のために理解、実装およびデバッグする必要のある、一般的なすべてのJ2EEデザイン・パターンを実装しています。J2EE関連の書籍でこれらのデザイン・パターンの一部の名称をすでに目にしており、ADF Business Componentsでどのように実装されているかを知るためのクロス・リファレンスが必要な場合は、付録E「ADF Business Components J2EE設計パターン・カタログ」を参照してください。
ADF Business ComponentsはJavaで実装されているため、パッケージ化されたJavaクラスおよびインタフェースで実装された形になっています。Javaパッケージは、ピリオドで区切った名前で識別され、開発者は階層型のネーミング構造でコードを整理できます。作成したコードが他の組織の再使用可能なコードと競合しないように、ベスト・プラクティスではパッケージ名の先頭に組織名またはWebドメイン名を付けることが定められています。たとえば、Apacheでは、Tomcat Webサーバーと関連付けるためにパッケージ名としてorg.apache.tomcatを指定しており、Oracleでは、XML Parserのパッケージ名としてoracle.xml.parserを指定しています。自社アプリケーション用に作成したコンポーネントは、com.yourcompany.yourappなどの名前でパッケージおよびそのサブパッケージに配置されます。
具体的な例として、SRDemoアプリケーションの主要なビジネス・サービスを構成するADF Business Componentsは、oracle.srdemo.modelパッケージおよびサブパッケージに配置されています。図4-1に示すように、これらのコンポーネントはワークスペースのDataModelプロジェクトにあり、次のように幅広く配置されています。
oracle.srdemo.modelには、SRServiceアプリケーション・モジュールが含まれています。
oracle.srdemo.model.queriesには、ビュー・オブジェクトが含まれています。
oracle.srdemo.model.entitiesには、エンティティ・オブジェクトが含まれています。
oracle.srdemo.model.designには、サービスをドキュメント化するUMLダイアグラムが含まれています。
自社アプリケーションでは、パッケージを最適に配置できるパッケージ構成を選択できます。具体的には、SRDemoアプリケーションの作成者のように、同じタイプのコンポーネントを1つのパッケージにまとめる必要はありません。
JDeveloperはリファクタをサポートしているため、名前の変更や、コンポーネントの別のパッケージへの移動などはいつでも簡単に行うことができます。つまり、最初から正しい構造にする必要はありません。ビジネス・サービスのパッケージ構造は、ADF環境での経験が増えるにつれて進化します。
また、パッケージに最適なコンポーネント数を表すような特別な数字はありません。ただし、経験を重ねるにつれ、チームに最適な構造が次の二極端の間のどこかに収まることがわかります。
すべてのコンポーネントをまとめた1つのパッケージ
個々のパッケージに分けられた各コンポーネント
25.7項「再利用可能なビジネス・コンポーネントのライブラリでの作業」で詳細に説明しているように、ADF Business Componentsのパッケージは、他のプロジェクトでの再使用のためにJDeveloperがインポートをサポートするレベルの単位になるため、コンポーネントをどのように配置するかも考慮に入れる場合もあります。
ADF Business Componentsレイヤーにより提供される、事前構築済のコードを構成するクラスやインタフェースは、oracle.jboパッケージおよび多数のサブパッケージに含まれます。ただし、ADF Business Componentsを使用した日常作業においては、主にoracle.jboとoracle.jbo.serverという2つの主要パッケージに含まれるクラスやインタフェースを使用することが多くなります。oracle.jboパッケージには、ビジネス・サービス・クライアントの連携のために設計されたすべてのインタフェースが含まれます。また、oracle.jbo.serverパッケージには、これらのインタフェースを実装するクラスが含まれます。
図4-2は、アプリケーション・モジュール・コンポーネントの具体的な例を示しています。アプリケーション・モジュールのためのクライアント・インタフェースは、oracle.jboパッケージの中のApplicationModuleインタフェースです。このインタフェースは、クライアントがアプリケーション・モジュールとの連携に利用可能なメソッドの名前やシグネチャを定義します。ただし、その機能の実装の仕様は含まれていません。アプリケーション・モジュール・コンポーネントのベースとなる機能を実装するクラスは、oracle.jbo.serverパッケージに含まれているApplicationModuleImplというクラスです。
ADF Business Componentsの各コンポーネントには、宣言的な設定によって制御される、組込みランタイム機能が付属しています。これらの設定は、コンポーネントと同じ名前のXMLコンポーネント定義ファイルに格納されています。コンポーネントのカスタム・コードを記述する場合、該当するコンポーネントに対するオプションのJavaクラスを有効にできます。
図4-3は、com.yourcompany.yourappパッケージ内で作成した、アプリケーション・モジュールYourServiceなどのアプリケーション固有のコンポーネントに対するXMLコンポーネント定義ファイルを示しています。対応するXMLコンポーネント定義は、JDeveloperプロジェクトのソース・パスのルート・ディレクトリ内のサブディレクトリ./com/yourcompany/yourappに保存されます。そのXMLファイルには、実行時にアプリケーション・モジュール実装を提供するJavaクラスの名前が記録されます。この場合、XMLにはOracle ADFが提供するoracle.jbo.server.ApplicationModuleImplベース・クラスの名前が記録されます。
ADF Business Componentsのコンポーネントの組込み機能を拡張する必要がない場合、また、組込みイベントを処理するカスタム・コードを記述する必要がない場合、このXMLのみの方法でコンポーネントを使用できます。つまり、コンポーネントは、XMLコンポーネント定義のみで完全に定義されており、コンポーネントに関連するカスタムJavaコードやJavaクラス・ファイルをまったく必要とせず、十分な機能を備えています。
コンポーネントのベース機能を拡張するため、またはイベントを処理するためにカスタム・コードを追加する必要がある場合、作成するADF Business Componentsのすべての主要タイプに対し、カスタムJavaクラスを有効にできます。コンポーネントのカスタム・クラスは、JDeveloperの対応するコンポーネント・エディタの「Java」パネルで有効にします。これにより、構成可能な命名の標準に準拠したコンポーネントに関連するカスタム・クラスのJavaソース・ファイルが作成されます。このクラスの名前は、コンポーネントのXMLコンポーネント定義に記録され、コンポーネントで必要とされるカスタムJavaコードは、このクラス内に記述できます。コンポーネントに対してカスタムJavaクラスを有効にすると、コンポーネントのアプリケーション・ナビゲータのポップアップ・メニューから、対応する「...クラスに移動」オプションを使用していつでもそのクラスにナビゲートできます。
図4-4は、前述のYourServiceアプリケーション・モジュールに対してカスタムJavaクラスを有効にするとどうなるかを示しています。YourServiceImpl.javaソース・コード・ファイルが、コンポーネントのXMLコンポーネント定義ファイルと同じソース・パスの同じディレクトリに作成されます。YourService.xmlファイルでは、ApplicationModuleImplクラスではなく、com.yourcompany.yourapp.YourServiceImplベース・クラスを実行時に使用するよう、変更が反映されます。
|
注意: このガイドの例では、生成済のカスタム・コンポーネント・クラスやインタフェースの名前には、デフォルトの設定を使用しています。自社アプリケーションでこれらのデフォルトを変更するには、JDeveloperツールの「設定」ダイアログの「ビジネス・コンポーネント: クラス・ネーミング」ページを使用してください。ここでの変更は、新しく作成したコンポーネントにのみ反映されます。 |
JDeveloperでは、サポートする各コンポーネント・タイプについてデフォルトでカスタムJavaファイルが生成されるように構成することも、XMLファイル・パッケージを使用して各パッケージ内のOracle ADF Business Componentsのリストが保持されるように構成することも可能です。この項では、ADF Business Componentsでの開発を始めた開発者に対し、これらのオプションの構成方法の推奨事項について説明します。
アプリケーションには、XMLのみのコンポーネントと、カスタムJavaファイルが関連付けられているコンポーネントを自由に組み合せることができます。たとえば、XMLのみのコンポーネントを使用してビジネス・ルールを宣言的に実行する、更新可能で完全に動作するデータ・モデルを定義できます。一方、開発者によっては、チームのコーディング・スタイルの一環として、作成する各コンポーネントに対しJavaクラスを事前に定義する場合もあります。
ADF Business Componentsでの開発を始めたばかりの開発者には、まずJDeveloperでカスタムJavaクラスがデフォルトで生成されないように構成することをお薦めします。これにより、カスタムJavaが必要とされる理由がわかり、アプリケーション内でカスタムJavaを必要とするコンポーネントに対して意識的に有効化できるようになります。時間の経過とともに、自分に最適の開発方法が定まります。
この推奨設定はデフォルト設定ではありません。そのため、次の手順を実行して、推奨のJava生成設定を構成する必要があります。
JDeveloperメイン・メニューの「ツール」→「設定」を選択します。
左のツリーから、「Business Components」設定カテゴリを選択します。
図4-5に示すように、すべてのチェック・ボックスが選択されていないことを確認し、「OK」をクリックします。
デフォルトでは、Oracle ADFの以前のリリースとの上位互換性を保つため、JDeveloperではパッケージ内のOracle ADF Business Componentsの名前を格納したXMLファイルを各ディレクトリに保持します。このパッケージXMLファイルは、以前はADFランタイム・クラスで必須でしたが、現在のバージョンではオプションとなっています。このパッケージXMLファイルの保持により、チームでの開発が複雑になる可能性があるため、図4-6に示すように、IDE設定の「ビジネス・コンポーネント: 一般」パネルで「クラス・パスへのパッケージXMLファイルのコピー」オプションをオフにし、すべてのパッケージXMLファイルの使用を無効にすることをお薦めします。
Java言語は文字列、日付、数値などのデータを処理するため、数多くの組込みデータ型を備えています。ADF Business Componentsにおいても、これらの型を使用可能ですが、デフォルトではoracle.jbo.domainパッケージおよびoracle.ord.imパッケージで最適化した一連の型を使用するように設定されています。表4-1に示すように、これらの型では、不要な型変換をなくし、ネイティブな内部形式をデータに保持することにより、Oracleデータベースのデータの処理パフォーマンスが向上します。文字列データでの作業の場合、ADF Business Componentsではデフォルトで通常のjava.lang.String型を使用します。
表4-1 oracle.jbo.domainパッケージおよびoracle.ord.imパッケージでの基本データ型
| データ型 | 説明 |
|---|---|
|
|
すべての数値データ |
|
|
日付および（オプションの）時間 |
|
|
データベース・トリガーにより割り当てられた、連続した整数 |
|
|
OracleデータベースのROWID |
|
|
タイムスタンプ値 |
|
|
タイムスタンプ値およびタイムゾーン情報 |
|
|
バイナリ・ファイル（BFILE）オブジェクト |
|
|
バイナリ・ラージ・オブジェクト（BLOB） |
|
|
キャラクタ・ラージ・オブジェクト（CLOB） |
|
|
Oracle Intermediaイメージ（ORDIMAGE） |
|
|
Oracle Intermediaオーディオ（ORDAUDIO） |
|
|
Oracle Intermediaビデオ（ORDVIDEO） |
|
|
Oracle Intermediaドキュメント（ORDDOC） |
|
|
ユーザー定義オブジェクト・タイプ |
|
|
ユーザー定義コレクション・タイプ（例: |
|
注意: oracle.jbo.domain.Numberクラスは、組込みのjava.lang.Number型と同じクラス名です。Javaコンパイラにより暗黙的にすべてのクラスにjava.lang.*がインポートされるため、これが参照されるすべてのクラスにoracle.jbo.domain.Numberクラスを明示的にインポートする必要があります。通常、これはJDeveloperで自動的に処理されますが、独自にカスタム・コードを追加で記述すると「Numberは抽象クラスです」というコンパイラ・エラーやランタイム・エラーが発生します。これは、oracle.jbo.domain.Numberではなくjava.lang.Numberを意図せず使用していることを意味します。クラスの先頭のpackage行の後に、次の行を追加してください。
import oracle.jbo.domain.Number; これにより、この種のエラーを回避できます。 |
アプリケーション・モジュール、ビュー・オブジェクトやエンティティ・オブジェクトで作業を行う際、汎用APIを使用するか、そのコンポーネントに強く型付けされたAPIを有効にするために、JDeveloperでコードをカスタムJavaクラスに生成できます。たとえば、ビュー・オブジェクトでの作業中、次のような汎用APIを使用し、結果のすべての行の属性値にアクセスできます。
Row row = serviceRequestVO.getCurrentRow();
Date requestDate = (Date)row.getAttribute("RequestDate");
汎用APIを使用した場合、パラメータの文字列名を渡し、戻り値の型をこの例のDateのように予想される型にキャストする必要があります。
一方、強く型付けされた作業スタイルを有効にした場合、次のようにコードを記述できます。
ServiceRequestsRow row = (ServiceRequestRow)serviceRequestVO.getCurrentRow(); Date requestDate = row.getRequestDate();
この場合、文字列名を渡して結果をキャストするのではなく、戻り型がコンパイル時に判明する生成済メソッド名を使用します。後続の章では、強く型付けされた作業スタイルの必要に応じた有効化について説明します。
ビジネス・サービス実装におけるビジネス・ドメイン・レイヤーのエンティティ・オブジェクトは、クライアントから直接参照されるように設計されていません。かわりに、クライアントは、アプリケーション・モジュールのデータ・モデルの一部として、ビュー・オブジェクトによる問合せデータを処理します。7.7項「実行時にビュー・オブジェクトとエンティティ・オブジェクトが連携する仕組み」で説明するように、実際には、ビュー・オブジェクトはビジネス・ドメイン・レイヤー内のエンティティ・オブジェクトと自動的に連携し、ユーザーが変更したデータの検証と保存を調整します。
したがって、クライアントに表示されるビジネス・サービスのコンポーネントは次のとおりです。
アプリケーション・モジュール: サービス自体を表します。
ビュー・オブジェクト: 問合せコンポーネントを表します。
ビュー行: 指定された問合せコンポーネントの結果の各行を表します。
oracle.jboパッケージでは、クライアントからのアクセス可能なビジネス・サービスに対するAPIを一連のJavaインタフェースとして提供します。前述の設計に従い、このパッケージにはEntityインタフェースやクライアントがエンティティ・オブジェクトを直接操作できるメソッドは含まれません。かわりに、クライアント・コードが次のようにインタフェースと連携します。
ApplicationModule: アプリケーション・モジュールを処理します。
ViewObject: ビュー・オブジェクトを処理します。
Row: ビュー行を処理します。
クライアントからコール可能にするカスタム・コードをOracle ADFビジネス・コンポーネントに追加する場合は、クライアントに表示されるコンポーネントすべてについて、その機能をクライアントに公開できます。JDeveloperでは、クライアント・インタフェース上で1つ以上のカスタム・メソッドをクライアントに公開している各コンポーネントに対して、関連するJavaインタフェース・ファイルが自動的に保持されます。そのため、SRDemoアプリケーションで使用されるSRServiceモジュールなどのアプリケーション・モジュールで作業していると仮定すると、次のようなカスタム・インタフェースを利用できます。
カスタム・アプリケーション・モジュール・インタフェース
SRService extends ApplicationModule
カスタム・ビュー・オブジェクト・インタフェース
StaffListByEmailNameRole extends ViewObject
カスタム・ビュー行インタフェース
StaffListRowClient extends Row
これにより、クライアント・コードでは、汎用クライアント・インタフェースをより詳細なインタフェースにキャストできます。詳細なインタフェースには、特定のコンポーネントに対して選択した、クライアントからアクセス可能な一連のメソッドが含まれます。
ビジネス・サービスの実装における、ADF Business Componentsを使用した簡略化の主要な利点の1つは、アプリケーション・モジュールが行セットのアクティブ・データ・モデルをサポートしている点です。Forms/4GLでの開発経験がある開発者にとっては、慣れている従来のツールと同様に作業できます。
一般的なJ2EEビジネス・サービスの実装を使用する場合、クライアント・レイヤーの開発者は次の点に留意する必要があります。
データを再表示するため、サービス・メソッドを起動します。
クライアントがどのデータを作成、削除、変更したかを追跡します。
変更を検証および保存するため、変更を1つ以上の異なるサービス・メソッドに渡します。
ADFアプリケーション・モジュールを設計した設計者は、このような取得、作成、編集、削除、保存のサイクルがエンタープライズ・ビジネス・アプリケーションで非常に一般的であるため、より洗練された、汎用的なソリューションが必要であると認識しました。ビジネス・サービスでアプリケーション・モジュールを使用すると、フィールド、表、ツリーなどのクライアントUIコントロールを、アプリケーション・モジュールのデータ・モデルにおけるアクティブ・ビュー・オブジェクト・インスタンスにバインドするのみです。UIの表示は、データ・モデルのビュー・オブジェクト行セットの行に対する変更を反映するよう自動的に更新されます。この機能は、Webやモバイル・デバイス用にJSPやJSFのページを使用して作成したものや、Swingを使用した、ウィンドウやパネルから構成されるデスクトップ・フィデリティのUIでの表示も含みます。このアクティブなデータ通知には、カスタム・ビジネス・サービス・メソッドにより、直接的または間接的に処理された結果としてのデータ・モデルへの変更も含まれます。
アプリケーション・モジュール・コンポーネントは一連の汎用サービス・メソッドを実装するため、サービス指向アーキテクチャ（SOA）でのアクティブ・データ・モデル機能が背後で有効になります。クライアント・レイヤーは、oracle.jboパッケージでADF Business Componentsインタフェースを使用するのみです。これらのインタフェースは、データ・モデルの行における行セットの観点からの検討が可能な、高レベルなAPIを提供します。エンド・ユーザーは、この内容を検索、作成、削除、変更および保存する必要があります。このAPIにより、下位レベルの汎用SOAメソッド・コールの複雑さを意識せずにすみます。さらに、宣言的なデータ・バインドのためのADFモデル・レイヤーを活用するUIを構築する場合、一般的に、アクティブ・データ・モデルと連携するクライアント側のコードを記述する必要はありません。この表示は、データ・モデルのビュー・オブジェクトや、その他の論理ビジネス・サービス機能を実行する場合のカスタム・ビジネス・サービス・メソッドに宣言的にバインドされます。
実行中のアクティブ・データ・モデルの、次の3つの具体的な例について検討します。
顧客がSRDemoアプリケーションにログインすると、未解決のサービス・リクエストのリストが表示されます。次にウィザード・ページからサービス・リクエストを新たに作成し、ホームページに戻ると、データベースに再問合せしなくても、新規サービス・リクエストがリスト内に表示されます。
マネージャがサービス・リクエストを編集し、値ページのポップリストから技術者の名前を選択し、このケースに技術者を割り当てます。データ・モデルを支援するビジネス・ドメイン・レイヤーのServiceRequestエンティティ・オブジェクトにカプセル化されたビジネス・ロジックには、サービス・リクエストに割り当てられている属性が変更された場合、割当て日を更新して現在の日時にするという簡単なルールが含まれます。ユーザー・インタフェースは、ビジネス・ドメイン・レイヤーのロジックが変更された割当て日を自動的に反映するよう更新されます。
ツリー表示で、ユーザーがツリー内のあるノードをクリックします。この操作により、アプリケーション・モジュール内のビジネス・サービス・メソッドが宣言的に起動され、マスター/ディテール情報を再問合せし、現在行を行セットの適切な行に設定します。画面は新規マスター/ディテール・データと現在行の表示を反映するよう更新されます。
アクティブ・データ・モデルが存在しない場合、開発者はこのように高度ではないビジネス・サービス実装アプローチを使用しなければならず、このために日常的に使用する、直接的なCRUDスタイルの操作を処理するには、より多くのコードをクライアント側で記述する必要があります。さらに、ページを常に最新に保つため、リフレッシュ・フラグを管理する必要があります。このフラグはコントローラ・レイヤーに、変更された可能性のあるデータを反映するため、ビジネス・サービスからのデータ再取得のリクエストを通知するものです。ADFアプリケーション・モジュールを使用してビジネス・サービスを実装する場合、エンド・ユーザーの期待に応じて業務を処理するよう配置するかわりに、当面のビジネス・ロジックにのみ重点を置くことができます。
アプリケーション・モジュールのアクティブ・データ・モデル機能により、クライアント・ユーザー・インタフェースは常に最新に保たれるため、通常、データ・モデルの設定や操作に関連するクライアント側のコードを記述する必要はありません。これらのコードはアプリケーション・モジュール・コンポーネントのカスタム・メソッド内でカプセル化することをお薦めします。ビュー・オブジェクトを操作するプログラム的なコードが完全なビジネス・サービス機能を実装するための論理的な特徴を備えている場合、アプリケーション・モジュールのJavaクラスでカスタム・メソッドを記述して、詳細をカプセル化する必要があります。これには次のコードが考えられますが、これらのコードに限定されるものではありません。
表示するデータを正しく問い合せるためのビュー・オブジェクト・プロパティの構成
集計結果を取得するための、ビュー・オブジェクト行の反復処理
1つ以上のビュー・オブジェクトに対する、複数ステップのプロシージャによるロジックの実行
これらの実装の詳細をアプリケーション・モジュール内で一元管理することで、次の利点が得られます。
コードの目的が、クライアントにより明確に伝わります。
必要に応じて、複数のクライアント・ページから同じコードを簡単にコールできます。
ビジネス・サービス機能全体のリグレッション・テストを簡略化できます。
クライアントに影響を与えることなく、実装を改善するオプションを使用可能にできます。
ページ内での論理ビジネス機能の宣言的な実行が可能になります。
ADF Business Componentsの使用によって記述が不要になるクライアント側コードの一般的な型としては、他に、マスターの行が変更された場合の詳細データ・コレクションを調整するコードがあります。次の章で説明するように、ビュー・オブジェクトをリンクすることにより、この調整は自動的に実行されます。
JDeveloperは、ADF Business Componentsに対する幅広い設計時サポートを提供します。この項では、このガイドで扱う、ビジネス・コンポーネントで作業する機能について重点的に説明します。
最初にコンポーネントを作成する場合は、図4-7に示すように、「ビジネス・コンポーネント・プロジェクトの初期化」ダイアログが表示されます。このダイアログを使用して、このプロジェクトのビジネス・コンポーネントで作業する際に使用する、設計時のデータベース接続を選択します。「接続」ドロップダウン・リストには、作成したすべての名前付きの接続が表示されます。また、必要な接続が見つからない場合は、「新規」をクリックして作成できます。
「SQLスタイル」設定によって、ビュー・オブジェクトが使用するSQL文と、エンティティ・オブジェクトが使用するDML文の構文が制御されます。JDeveloperでOracleデータベース・ドライバの使用が検出されると、この設定はデフォルトでOracle SQLスタイルに設定されます。サポートされるSQLスタイルは、次のとおりです。
Oracle: Oracleを使用する場合のデフォルト
OLite: Oracle Liteデータベースを使用する場合
SQLServer: Microsoft SQLServerデータベースを使用する場合
DB2: IBM DB2データベースを使用する場合
SQL92: サポートされているその他のSQL92準拠データベースを使用する場合
「型マップ」設定によって、このプロジェクトが最適化されたOracleの一連のデータ型を使用するか、基本のJavaデータ型のみを使用するかが制御されます。JDeveloperでOracleデータベース・ドライバの使用が検出されると、この設定はデフォルトでOracle 型マップに設定されます。サポートされる型マップは次のとおりです。
Oracle: oracle.jbo.domainパッケージの最適化された型を使用する場合
Java: 基本のJava型のみを使用する場合
|
注意: アプリケーションをOracleデータベースとOracle以外のデータベースの両方に対して実行する場合、アプリケーションの構築を開始した後ではなく、開始する前に、SQL92のSQLスタイルを選択する必要があります。これにより、OracleデータベースとOracle以外のデータベースの両方に適用できるアプリケーションを構築できますが、同時に、Oracle SQLスタイルで使用する場合に特有の、Oracle固有の最適化機能の一部は使用できなくなります。 |
「新規ギャラリ」の「ADF Business Components」カテゴリでは、JDeveloperはそれぞれのビジネス・コンポーネントを作成するためのウィザードを提供しています。各ウィザードでは、新規コンポーネントのコンポーネント名を指定し、どのパッケージにコンポーネントを配置するかを選択できます。パッケージがまだ存在しない場合、新規コンポーネントがそのパッケージの最初のコンポーネントになります。ウィザードには、コンポーネント・タイプを作成するために必要な情報を収集する、一連のパネルが表示されます。「終了」をクリックすると、XMLコンポーネント定義ファイルが保存され、新規コンポーネントが作成されます。デフォルトで生成にJava生成オプションを優先するよう設定している場合、JDeveloperでは初期のカスタムJavaクラス・ファイルも同時に作成されます。
アプリケーション・ナビゲータ内にパッケージを含めた後は、アプリケーション・ナビゲータからパッケージを選択し、図4-8に示すように、右クリックして表示されるポップアップ・メニューからオプションを選択することで、追加の各種ビジネス・コンポーネントを迅速に作成できるようになります。
コンポーネントが作成された後は、アプリケーション・ナビゲータでコンポーネントをダブルクリックするか、コンポーネントを選択して、右クリックして表示されるポップアップ・メニューから「編集」オプションを選択して対応するコンポーネント・エディタを起動し、ここで各コンポーネントを編集できます。コンポーネント・エディタでは、ウィザードで利用可能なパネルのスーパーセットが提供され、コンポーネントのすべての特徴を変更できます。「OK」をクリックすると、コンポーネントのXMLコンポーネント定義ファイルが更新され、関連するすべてのカスタムJavaファイルが必要に応じて更新されます。
第2章「Oracle ADFおよびJSFを使用した開発プロセスの概要」で説明したとおり、JDeveloperではADF Business Componentsに対する充実したUMLダイアグラム・サポートが提供されます。作成済の既存のコンポーネントを、ビジネス・コンポーネント・ダイアグラムに追加して視覚化するか、コンポーネントの作成および変更にダイアグラムを使用するか、またはこの2つを組み合せて使用できます。ダイアグラムは、エディタでの変更と同期しています。
新しいビジネス・コンポーネント・ダイアグラムを作成するには、JDeveloperの「新規ギャラリ」の「ADF Business Components」カテゴリから、「ビジネス・コンポーネント・ダイアグラム」アイテムを使用します。このカテゴリは、Business Tierの選択肢の一部です。
アプリケーション・モジュール・コンポーネントの作成後は、組込みのBusiness Component Browserを使用し、繰り返しテストできます。Business Component Browserを実行するには、アプリケーション・ナビゲータまたは「ビジネス・コンポーネント・ダイアグラム」でアプリケーション・モジュールを選択し、右クリックして表示されるポップアップ・メニューから「テスト」を選択します。
このツールではアプリケーション・モジュールのデータ・モデルにビュー・オブジェクト・インスタンスを提供し、動的に生成されるユーザー・インタフェースを使用してユーザーとインスタンスとの対話を可能にします。このツールは、ページやSwingパネルのビュー・レイヤー作成の前後において、ビジネス・サービスのテストやデバッグに必要不可欠なものです。
アプリケーション・ナビゲータでコンポーネントを選択し、右クリックして表示されるポップアップ・メニューから「リファクタ」→「名前の変更」を選択すると、いつでもコンポーネントの名前を変更できます。また、ナビゲータ内で[Ctrl]キーを押しながらクリックしてコンポーネントを選択すると、1つ以上のコンポーネントを選択できます。また、「リファクタ」→「移動」を選択すると、選択したコンポーネントを新規パッケージに移動できます。現在のプロジェクト内の古いコンポーネント名やパッケージへの参照は、自動的に修正されます。
