 |
| 図1：OrderSystemアプリケーションのサンプル・プロジェクト |
Oracleテクニカル・ホワイトペーパー
2002年9月
Enterprise JavaBeansTM（EJB）テクノロジは、分散型Javaコンポーネントの開発と展開のためのサーバーサイド・モデルを規定しています。これを実現するために、EJBの仕様では、APIの標準セットと、EJBサーバーがサポートすべきランタイム・サービスが定義されています。このモデルにより、アプリケーション開発者はアプリケーション・ロジックに専念できるようになり、EJBサーバーは、トランザクション、セキュリティ、リソース管理といったサービスの提供に専念できるようになります。しかし、現実のビジネス・アプリケーションに求められる堅牢な機能を記述するというタスクは、依然としてEnterprise Bean開発者の責任です。とりわけ、EJBの仕様は、以下のタスクを実行する方法を指定していません
事実、アプリケーション開発者とソリューション・プロバイダはこれらのタスクに大量の時間と労力を割いています。Oracle Business Components for Javaは、これらの難題に対するアプリケーション開発者のニーズに対処するために設計されました。
標準のEJBおよびCORBAアーキテクチャをサポートするOracle Business Components for Javaは、J2EEベースのサーバーサイド・ビジネス・アプリケーションの開発、配布およびカスタマイズを劇的に簡素化します。Oracle Business Components for Javaは、単にJDBCアクセスを簡易化させるだけでなく、更に広範に次に示すようなさまざまなビジネス・アプリケーションで共通に必要とされる機能を提供し、「何もしなくてもそのまま」協調できるインテリジェントな一連のソフトウェアの構築部品群として開発者が利用可能なJ2EEデータアクセス・フレームワークです。
このフレームワークを使用すると、あらゆるアプリケーション開発に共通して行われる「アプリケーション機能の結合作業」に関連する多大なコーディングおよびテスト作業をなくすことが可能で、アプリケーション開発者はビジネス・ソリューションの実装にフルタイムで専念できます。このフレームワークを使う利点は膨大かつ明白です。すなわち、開発コストを低減し、プロジェクトのリスクを減らし、カットオーバーまでの時間を短縮します。
フレームワークが、その洗練された組込み動作によってあらゆる一般的なケースを処理する一方で、これらの利点を活用しても、必要なときに「自分の思うままにする」能力を犠牲にすることはないということにも着目してください。フレームワークが提供する自動的な動作は、数行の戦略的なコードによって、ユーザー固有のコンポーネントで簡単に上書きすることができるので、すべてのケースに同じ方法を実行するよう強制されることは決してありません。
Oracle Business Components for Javaは、スケーラブルな多階層エンタープライズJavaアプリケーションをどのように構築するかというオラクルのビジョンを現実的に実現するべく、Oracle E-Business Suite、Oracle Tools、Oracle Server Technology開発組織が長年にわたり行ってきた共同設計および開発の結晶です。
Oracle Business Components for Java（BC4J）は、XMLを有効活用した100% Javaのフレームワークで、再利用可能なビジネス・コンポーネントからデータベース連携する多階層アプリケーションの生産的開発、開発後に配布方法を選択できるという優れた可搬性、および柔軟なカスタマイズを可能にします。
アプリケーション開発者は、BC4Jフレームワークを、Oracle JDeveloperに統合されたウィザード、コンポーネント・エディタ、および生産的Javaコーディング環境を使って、再利用可能なビジネス・コンポーネントからアプリケーション・サービスの組立てとテストを行うことができます。これらのアプリケーション・サービスは、CORBAオブジェクトまたはEJB Session Beanとして、Javaテクノロジをサポートするエンタープライズ規模のサーバー・プラットフォームに配布することができます。
|
| 図1：OrderSystemアプリケーションのサンプル・プロジェクト |
図1 はBC4Jの基本的なプロジェクトの例です。ここには、アプリケーション・モジュール、エンティティ・オブジェクト、Association、ビュー・オブジェクト、およびビュー・リンクと呼ばれるBC4Jの基本要素が表示されています（これらの各コンポーネントについては、後ほど本書内で説明します）。コンポーネントはパッケージに編成され、各コンポーネントは（上記図で、Orders エンティティ・オブジェクトのツリーの下に表示されているように）、XMLファイルによる定義情報とJava実装クラスからなっています。これらは、基本メタデータ（XML）とユーザー固有の拡張コード（Java）を明確に分離して、アプリケーションのカスタマイズを促進し、動的なアプリケーションの機能をサポートします。
 |
| 図2：顧客支払管理のためのサンプル・アプリケーションの実行時の動作 |
図2は、簡単なBC4Jアプリケーションの実行時の動作を示しています。
BC4Jフレームワークには、アプリケーション・モジュールと連携するためのクライアント側ライブラリも用意されています。それを利用することによって、構成されたサーバーサイドのアプリケーション・モジュールに対して、HTMLおよびJavaユーザー・インタフェースを容易に結合することができます。また、既存のアプリケーション・モジュールを集めて新たに一つのアプリケーション・モジュールとして構成することも可能です。つまり、真のコンポーネント開発であるといえます。
図2に示すように、BC4Jは、それ自身はCORBAサーバーでもEJBサーバーでもありません。BC4Jは、データアクセスとそれに関連するビジネス・ロジックを容易に構築するための基本ロジックを内蔵したランタイム・ライブラリと、それだけでなく、それらを生産的に開発可能な開発支援機能までを兼ね備えたフレームワークです。これを使うことで、開発者はスマートで再利用可能な部品から生産的にアプリケーション・コンポーネントを構築することが可能になります。これらのアプリケーション・コンポーネントは、その実行環境を提供するCORBAまたはEJBサーバーに、CORBA オブジェクトまたはEJB Session Beansとして展開されます。
BC4Jフレームワークが提供する基本のエンティティ・オブジェクト、ビュー・オブジェクト、アプリケーション・モジュールをベースとして、ユーザー独自で拡張することができます。各コンポーネントのデフォルトの実行時の動作を自動的に継承しつつ、機能拡張を行うことができます。フレームワークであらかじめ提供される組込み動作によって、エンタープライズJavaアプリケーションのための基本機能が保証されるため、生産性が格段に高まります。
以降では、BC4Jがこれらの結果を達成するために開発者に提供する10の重要な利点を詳しく説明します。
Oracle Business Components for Javaは、エンタープライズCORBA/EJBアプリケーションを構築、配布およびカスタマイズする開発者に対し、以下の重要な利点を提供します。
以下のセクションでは、上記の主要な利点それぞれの技術ハイライトと簡単な説明を行います。
| 技術ハイライト | |||||||
|---|---|---|---|---|---|---|---|
|
エンティティ・オブジェクト
図3では、単純な電子取引発注システムのビジネス・エンティティに対するUMLモデルを示しています。この図のモデルを即座にアプリケーションとして実現するために、BC4Jでは、各ビジネス・エンティティに対応し、それに関連するビジネス・ロジックのカプセル化とデータベースとのやり取りの詳細をすべて処理する、エンティティ・オブジェクトと呼ばれる基本フレームワーク・コンポーネントを提供します。
 |
| 図3：電子取引発注システムのUMLエンティティ・モデル |
Oracle Business Components for Javaを利用すると、それぞれのクライアント・アプリケーションまたはサーブレットごとにビジネス・ロジックをコーディングするのではなく、フレームワークで提供される基本エンティティ・オブジェクトを拡張してユーザー固有のビジネス・コンポーネントとし、そこにビジネス・ロジックを一元的に記述するという方法を取れます。たとえば、図3 のOrdersエンティティの実装形であるOrders エンティティ・オブジェクトには、以下のものをカプセル化できます。
エンティティ・オブジェクトのJava実装クラスに妥当性ロジックを記述するだけで、その妥当性ロジックを施行するタイミングの調整はフレームワークが行います。エンティティ・オブジェクトが他のエンティティと強い関連性がある（図3 でのOrdersとLineItemなど）ような場合は、フレームワークは関連するエンティティの妥当性も調整します。
Association2つのエンティティ・オブジェクトの間にAssociationを定義することにより、それらの間に有効なリンクが作成されます。AssociationのgetXXXメソッド（getterメソッド）によって、コード内でリンクを「移動して」関連先のエンティティ・オブジェクトへ直接アクセスすることができ、AssociationのsetXXXメソッド（setterメソッド）によって、関連するオブジェクトを直接セットすることができます。getterおよびsetterメソッドは、BC4Jでは属性アクセスのためのコーディング・パターンでもあるため、Associationを使用すると、エンティティの仮想属性のように表現され、関連する情報に透過的にアクセスできるようになります。
 |
| 図4：LineItemにおける属性レベルの妥当性検査コード ここでは Associationアクセス機構を使用してこの発注を行った顧客を走査し、そのメソッドをコールしている |
図4では、現在のLineItemに対するOrdersを参照し、続いてOrdersを発生させた（発注を行った）Customerを参照し、さらに許容される最大の割引をチェックするためにCustomerに対するビジネス・メソッドを呼び出す、というJavaコードが、BC4Jではどれほど容易に記述できるかを示しています。BC4JのAssociationアクセス機構を活用することにより、ビジネス・ロジックの記述が格段に単純化されます。
Associationは、1つのエンティティが別のエンティティを参照することを示しています。さらに、UMLで表現されているように、Associationは、2つのコンポーネント間のより強い所有あるいは包含関係を示す「コンポジション」であるというフラグを立てることができます。たとえば図3では、OrdersとCustomerは、LineItemとInventoryItemと同様、Associationによって関連づけられています。これは単純に、Ordersが特定の顧客（Customer）によって行われたものであり、LineItemが在庫にある特定の品目（InventoryItem）に対するある量の注文を表している、ということを意味します。Ordersがシステムから削除されても、発注を行った既存のCustomerや、削除された発注で要求されたInventoryItemに対して影響はありません。
一方、上記のOrdersおよびLineItemは、コンポジション（Associationの線上の無地の菱形によってUMLに表記されています）によって関連付けられています。BC4Jを使った場合、これは実行時に以下のことを意味します。
このように、Associationとコンポジションによって、ビジネス・エンティティ間の関連性を正確に表現でき、それがシステムをよりインテリジェントにします。前述のように、BC4JでAssociationとコンポジションを使うことにより、多くの一般的な妥当性検査が自動化されます。
検証ルール検証ルールは、JavaBeansとして構成され、それにより、すべてのエンティティ・オブジェクトから再利用可能な妥当性検査コードとしてカプセル化されます。エンティティ・オブジェクトのJava実装クラス内にJavaコードを記述することで、自由に妥当性検査ロジックを実現できますが、基本的な検証ルールであれば、XMLコンポーネント定義内に宣言的に付加するだけで実現できます。
 |
| 図6：LineItemのQuantity属性に対する検証ルール（RangeValidationBean）の使用を示す、XMLメタデータ |
図6は、LineItem エンティティ・オブジェクトのQuantity属性に対する有効な値の範囲を設定するために、Oracle JDeveloperでエンティティ・オブジェクト・エディタの"検証"タブを使って、RangeValidationBeanによる検証ルールを設定した結果を示しています。検証ルールは、JavaBean内の小さなデータ駆動の妥当性検査エンジンのようなもので、実行させるためにパラメータ・セットを供給する必要があります。これらのパラメータは、検証ルールの使用を表すXML属性として、XMLによるコンポーネント定義内に表記されます。このような方式のため、基本的な検証ルールの値の設定やカスタマイズの際には、Javaコードを記述する必要がなく簡単です。
検証ルールは、エンティティ・オブジェクトの属性それぞれに対して、およびエンティティ・オブジェクト全体に対しての両方に付加することができ、フレームワークは各場所で複数個の検証ルールを実施できます。検証ルールはJavaコード・ベースの妥当性検査と連携して作用するので、ニーズに応じた妥当性検査のアプローチを調整することができます。
BC4Jには例に挙げた値の範囲検証のような基本的な検証ルールのセットが付属していますが、その真のパワーはユーザーが独自の検証ルールを簡単に実装できることにあります。結局のところ、検証ルールを実行しているのは、提供されたBC4Jインタフェースを実装するJavaBeansにすぎないです。つまり、ユーザー独自の検証ルールのライブラリを作成可能で、それを再利用することで、開発チームやエンド・ユーザーは、アプリケーションの動作をより簡単かつ宣言的にカスタマイズできるようになるでしょう。
ドメイン真のアプリケーションを構築する場合、以下をチェックするために、しばしば短いルーチンを記述しなければなりません。
ドメインとは、アプリケーションに頻繁に現れるスカラー・データ型を表す不変クラスです。上記の状況を表すドメインは、それぞれTelephoneNumber、CreditCard、WebURL、FedExTrackingNumberなどで表現できます。
ドメインには、コンストラクタ内に、適切な値であることを確認するために必要なチェックを実行する妥当性検査が含まれます。ドメインのインスタンスは、いったん構成されると、メソッド・パラメータとして型に関係なく自由に渡すことができます。実際、ドメインにより、Priceを予測しているメソッドにQuantityを渡すというミスを容易に回避できます。これは、コンパイラが即座にエラーのフラグを立てるためです。
BC4Jは、エンティティ・オブジェクトおよびビュー・オブジェクトの属性としてドメインを簡単に使用可能です。これによって、クライアントが提供した属性値に対し、ドメインに内蔵された妥当性検査が自動的に行われます。図7は、WebURLクラスを利用した"タイプセーフ"なgetter/setterメソッドの例、Customer.WebSite属性のデータ型としてのWebURLドメインを使用した場合のXMLメタデータ、およびWebURLドメインのコンストラクタ実行時における妥当性検査を示しています。
 |
| 図7：WebURLドメイン定義、顧客エンティティのWebSite属性としての使用例 |
| 技術ハイライト | |||||||
|---|---|---|---|---|---|---|---|
|
ビュー・オブジェクトEJB Entity Beanは「ファインダ・メソッド」と呼ばれる機能をサポートしています。これは、Beanのコード記述者によって用意される、そのBeanに対する「参照」方法です。たとえば、主キー属性OrderNumberによってOrdersBeanを見つけるという一般的な方法の代わりに、他のパラメータに基づく参照のためにファインダ・メソッドを用意することができます。 単純なEJB「ファインダ・メソッド」とは異なり、BC4Jのビュー・オブジェクトは次の機能を提供します。
データをデータベースから取り出して、その後、Java実装クラス内に記述されるカスタムJavaコードによって値を計算するという一般的な手法に加えて、ビュー・オブジェクトには、SELECTリスト内のSQL式に、SQLの強力な計算および集計機能による計算属性を含ませることができます。つまり、クライアントで計算するのではなく、データベースに計算させて、その結果を取得するという手法です。これは、 データアクセスのパフォーマンス改善のためのチューニングを可能にし、レスポンス時間を短縮化させる重要な機能です。
ビュー・オブジェクトはいったん定義されると、必要に応じてアプリケーション・モジュールに組み込んだり、名前によって参照されて実行時にオンデマンドでインスタンス生成される、再利用可能なコンポーネントになります。
各ビュー・オブジェクトは、そのXMLコンポーネント定義内に関連するメタデータを格納しています。そこにはSQL問合せのSELECTリスト内の列が、どのように各エンティティ・オブジェクト属性に関連付けられているかが記述されています。この情報から、ビュー・オブジェクトによって取り出された行の値を変更した場合に、どの（エンティティ・オブジェクトの）ビジネス・ロジックを実施すべきかをフレームワークが判断し、調整します。
 |
| 図8：ビジネス・ロジック実施のため、ビュー・オブジェクトは 関連するエンティティ・オブジェクトとの調整を行う |
たとえば、上記の図8は、2つの異なるビュー・オブジェクトであるEmployeeListとTopPerformersの両方が、その結果セット列内のEmployee エンティティ・オブジェクトから属性を参照していることを示しています。EmployeeのSal属性が両ビュー・オブジェクトに含まれると仮定すると、どちらかのビューがそれを変更しようとしたときに、Salに対するあらゆる妥当性検査ルールが自動的に施行されます。
実際には、Salはビューに含まれない場合もあります。たとえば、Employee エンティティ・オブジェクトに、従業員が昇進したら昇級するというビジネス・ロジックがあるとします。そして、クライアントは、EmpNo、EName、およびLevelのみを含むビュー・オブジェクトを使うとします。このような場合でも、クライアントから、従業員のレベルの値が現在の値より高く設定される（昇進を示す）と、昇進関連のビジネス・ロジックが施行され、それによって従業員の給与が無効なものになると、例外が常にクライアントに対して提示されます。
エンド・ユーザーの画面またはWebページに必要な情報だけを表示するために、ビュー・オブジェクトのSQL問合せで、たくさんの基礎となる表を結合しなければならない場合が多々あります。もう一度、図3を見て、Ordersに新しいLineItemを入力するというタスクを完了させるためにユーザーが必要とする情報について考えてみてください。 ユーザーは、最低でも、SupplierのNameの他に、InventoryItemの項目に関するPriceおよびDescription情報を見る必要があります。
ビュー・オブジェクトはこれを簡単に処理します。結合問合せをビュー・オブジェクト・エディタを使って構築させるだけでよいのです。つまり、ビュー・オブジェクト・エディタを使って、問合せに必要な列と基礎のエンティティ・オブジェクトの適切な属性との関連付けを指定します。通常、結合問合せは更新できませんが、BC4Jフレームワークを使えば、ビュー・オブジェクト・メタデータを使って任意の結合を完全に更新可能にできます。
時には完全に更新可能にすることが必要でない場合もあるので、ビュー・オブジェクト内の各属性を完全にコントロールして、それが読取専用であるのか、更新可能であるのか、新規作成の行の場合のみ更新可能であるのかを指定し、そのビュー・オブジェクトを使う可能性があるユーザー・インタフェースやWebページにコーディングを行う負担を軽減することができます。
| 技術ハイライト | |||||||
|---|---|---|---|---|---|---|---|
|
クライアント・アプリケーションを構築する開発者にとって最も難しいタスクの1つが、エンド・ユーザーに複数の同期したデータ・ビューを提供することです。表形式のグリッド・インターフェースにサマリー情報を表示し、フォームで詳細情報を提示し、グラフとして同じ情報をグラフィカルに表現するようなアプリケーションを、何度も目にしてきたことでしょう。ユーザーがデータを変更したりナビゲートしたりする際にたくさんのビューの同期を保つことは、簡単ではなく普遍化も難しいので、これらのアプリケーションはユーザーにとってはありがたくても、開発者にとっては悪夢です。BC4Jは、これを実行する上で難しい部分すべてを自動化するフレームワーク・コンポーネントを提供することにより、この問題を解決します。
BC4Jのビュー・オブジェクトを通してデータベースから取得されたデータは、その各行を分解して、対応するエンティティ・オブジェクトの構成部分（属性）に格納します。つまり、複数のビュー・オブジェクトが、同じエンティティ・オブジェクトのデータを参照している場合には、メモリ内でデータがキャッシングされる格納位置は一個所（対応するエンティティ・オブジェクトのインスタンス）になります。この基本的な処理動作によって、同じデータの複数のビューの同期を自動的に保つという利点があります。ビューが属性を変更すると、変更は、その下にあるエンティティ・オブジェクトの一意のキャッシングされたインスタンスの対応する属性にも、効果的かつ自動的に反映されます。これによって、同じセッションのすべてのビュー・オブジェクトには即座に変更を把握します。つまり、同期化に関する機能を実装するために手作業でコードを記述する必要がなくなります。
ビュー・リンク開発者にとって次に調整が難しいのが、マスター/ディテール問合せの同期を保つことです。BC4Jフレームワークでは、ビュー・リンクを定義して、2つのビュー・オブジェクト間のマスター/ディテール関係を確定することができます。このビュー・リンクが、実行時に、ディテール側のビュー・オブジェクトの結果セットをマスター側の結果セットの状態にあわせて自動的に同期させます。ビュー・オブジェクトは、適切なビュー・リンクの調整制御のもとでインスタンス化され、効率よく再利用されます。
JFC/Swingベースのユーザー・インタフェースまたはJSPページが、ビュー・リンクで結合された2つのビュー・オブジェクトの情報を使う場合、masterVO.next()などのコールを単純に行うと、ほかの特別なコーディングを行わずとも、ビュー・オブジェクトのマスター/ディテール情報が自動的に同期化されます。これによって、高度なユーザー・インタフェースに必要なコードが大幅に削減されます。
同じようなパターンでありながら、何度も繰り返しのルーチン的な非生産的コーディングになりがちなもう1つの一般的なタスクが、参照値の取出しの管理です。例えば、ユーザーが受注項目（LineItem）を入力する画面で項目のIDを入力した場合、通常は、入力された値でItemIdを対応づけてInventoryItemのデータを参照し、そのDescription、Price、およびSupplierのNameを取り出すようなコーディングを記述する必要があります。
BC4Jでは、各ビュー・オブジェクトは、どのエンティティ・オブジェクトをベースとしているかを把握しています。エンティティ・オブジェクト間がAssociationによって関連付けされているのであれば、BC4Jフレームワークがそれらの情報を自動的にまとめるため、参照情報を取り出すためのルーチン・コードを記述する必要がなくなります。
 |
| 図9：ItemId が新規入力されると、ビュー・オブジェクトのベースとなっているLineItemおよびSupplierの各エンティティ・オブジェクトからの適切な属性値が自動的に取得される |
図9は、LineItemsViewの現在行のItemId属性に値が設定されたときに発生する内容を表しています。値が設定されると、フレームワークは、ビュー・オブジェクトで使用されているInventoryItemおよびSupplierエンティティ・オブジェクトから該当する参照情報を自動的に取り出します。II およびSから出ている斜めの線は、エンティティの参照を表しています。このため、ユーザーが、新しいSKU#を指定したときに追加のコーディングなしに、正しい説明（Description）、価格（Price）、および仕入先（Supplier）が自動的に検索されます。
| 技術ハイライト | |||||||
|---|---|---|---|---|---|---|---|
|
アプリケーション・モジュールクライアント・ユーザー・インタフェースのコードを少なくするために、クライアント・アプリケーションが必要なデータ・モデル全体をアプリケーション・モジュールに事前構築することができます。これには、アプリケーションが使用する基本データ・モデル（ビュー・オブジェクト）だけでなく、マスター/ディテールの自動調整の動作を設定するビュー・リンクも含まれます。このすべてを事前に設定することによって、クライアント・アプリケーションでは、単に必要なアプリケーション・モジュールをインスタンス化するだけで、適切に調整されたすべてのビュー・オブジェクトを即座に利用可能になります。同時に、ネットワーク上の効率的なデータアクセスを実現し、起動時間を短縮できます。
図10は、図3のOrderSystem アプリケーション・モジュールを実装するために必要な、ビュー・オブジェクトとビュー・リンクを示しています。
 |
| 図10：OrderSystem アプリケーション・モジュールのデータ・モデル |
アプリケーション・モジュールを、"アプリケーションのためのデータ・モデルを一まとめにしたもの"としてのみ捉えると、アプリケーション・クライアントが必要とするサーバーサイドのサービスの提供という、効率的な論理三階層アプリケーションの構築においてアプリケーション・モジュールが果たす他の重要な役割を見逃すことになります。
アプリケーション・モジュールに対して定義されたカスタム・メソッドは、アプリケーション・モジュール・エディタの"カスタム・メソッド"パネルで選択するだけでリモート・アクセスできるようになります（クライアントから利用可能になります）。アプリケーション・モジュールのカスタム・メソッドが"公開"の状態に設定されると、BC4Jフレームワークでは、クライアントが利用可能なリモート・インタフェースを自動的に作成します。このリモート・インターフェースには、公開されたカスタム・メソッドのためのインターフェースも作成されており、メソッドの本体であるサーバーサイドのメソッド実装との間で、適切な引数のやり取り、戻り値の取得および例外ハンドリングを実行時に自動的に処理します。したがって、データを大量に使った計算などのコードをクライアントからアプリケーション層の該当するアプリケーション・モジュール側に移すことにより、大量のデータをクライアントに不要に持ち込むことなく、1回のネットワークのラウンドトリップによって答を得ることができるようになります。
アプリケーションのコンポーネントを分かりやすく組み立てられるように、必要に応じて、いくつかのアプリケーション・モジュールを含んだアプリケーション・モジュールという構成をすることができます。図11に示すように、ある画面ではアプリケーション・モジュールを単独で使用し、別の画面ではマスター/ディテールの一部として同じアプリケーション・モジュールを使うという場合、単独のアプリケーション・モジュール、それをディテールとして含むアプリケーション・モジュール、さらにはその両方を含む論理アプリケーション・モジュール、という構成をとることによって、高い再利用性の下でアプリケーションを構成することができるようになります。
 |
| 図11：アプリケーション・モジュールの組立て例 |
アプリケーション・モジュールのインスタンスを、最初は空である汎用コンテナとして使用することもできます。これは、例えば、複雑な、ロール・ベースのアプリケーションなどで、事前には具体的なアプリケーション・モジュールやその中のビュー・オブジェクトの構造が固定できずに、実行時に動的にロードするような場合が該当するでしょう。
JavaServer Pages（JSP）からビュー・オブジェクトとアプリケーション・モジュールへのアクセスを行いたい開発者のために、BC4Jフレームワークの一環として、カスタム・タグが用意されています。このカスタム・タグを利用することによって、JSPからのデータアクセスが劇的に簡単になります。
BC4Jのカスタム・タグには、利用するアプリケーション・モジュールおよびビュー・オブジェクトを宣言するだけでなく、データの取り出し、表示する範囲のスクロール、データ更新フォームのためのタグ、コミットやロールバックを指示可能なタグなどが含まれ、JSP内からビュー・オブジェクトとアプリケーション・モジュールをプログラム的に完全にコントロールすることができます。これらのカスタム・タグは、Oracle JDeveloperのコンポーネント・パレットから、JSPに挿入することができます。つまり、カスタム・タグを単に用意しているだけでなく、それを記述する際の支援機能までも提供しています。
 |
| 図12：コンポーネント・パレットからJSPへのカスタム・タグの挿入 |
JSP開発者にとってさらに興味深いBC4Jの機能が、アプリケーション・モジュール・プーリングとビュー・オブジェクトの順方向限定（フォワード・オンリー）モードです。JSP開発者は、多数のブラウザ・ベースのユーザーを効率的かつ高いパフォーマンスで処理するために、使用されるアプリケーション・モジュールのインスタンスをプール内に自動的に維持し、再利用できます。それぞれで個別に状態を保持するようなアプリケーション・モジュール・インスタンスを、ステートフル・モードでプーリングする場合はもちろん、ステートレス・モードでプーリングする場合であっても、頻繁にアクセスされるデータが各アプリケーション・モジュールのビュー・オブジェクトにキャッシングされたままになるため、レスポンス時間をはるかに迅速にするという利点があります。
アプリケーションによっては、問合せされたデータの表示範囲を任意にスクロールする必要もなく、値の更新も行わないケースがあります。このような場合に、ビュー・オブジェクトのインスタンスを順方向限定モードに設定することで、ビュー・オブジェクトの問合せ結果のキャッシングを意図的に回避することができます。代表的な例として、動的にHTMLまたはXML Webドキュメントを出力するために問合せ結果をフォーマットする場合です。アクセス数が多い場合、同じビュー・オブジェクトが何回もインスタンス化されるので、それを順方向限定モードで使用すればWebページのフォーマット作成が速くなり、一方で、通常モードのインスタンスを用意しておけば、ユーザーが値に変更を加えて最終的に確定した場合に、更新と自動的なビジネス・ロジックの実施を行うこともできます。
Oracle JDeveloperには、データベース問合せによるデータとJFC/Swingコントロールを宣言的に結びつけるために、JFC/Swingコントロールのモデルとして役割を果たすことが可能なJClientデータモデルが用意されています。Oracle JDeveloperでは、これを利用して、一般のJFC/Swingアプリケーションの開発と同じ手法を用いて、そこに宣言的にBC4Jのデータアクセス・オブジェクトを結びつけることが可能になります。
 |
| 図13："JClientデータモデル"を使ったビュー・オブジェクトとSwingコントロールとの宣言的な結びつけ |
図13 は、Swingコントロールとビュー・オブジェクトを結合（バインド）するダイアログを示します。この例では、テキスト・フィールド・コントロールの"document"プロパティに、JClientデータモデルによるビュー・オブジェクト結合を設定しています。これにより、開発者が手作業でコーディングを行わなくても、実行時に、コントロールが列のデータをビュー・オブジェクトを通して自動的に表示し、変更できることを意味します。
| 技術ハイライト | |||||||
|---|---|---|---|---|---|---|---|
|
すでに説明したように、ビュー・オブジェクトは問合せされたデータを自動的にエンティティ・オブジェクト部分にキャッシュします。ビュー・オブジェクトの列と、そのベースとなるエンティティ・オブジェクト属性との関連性を示す情報は、ビュー・オブジェクトのXMLメタデータに格納されており、その情報を利用して適切な位置にキャッシュされます。このテクニックにより、データベースがSQL問合せをフルスピードで処理する一方で、返されたデータを1度キャッシュに入れることでより効率的なデータアクセス処理を可能にします。
データがエンティティ・オブジェクトによってキャッシングされると、エンティティ・オブジェクトは、属性に対して有効な変更が行われた場合に、データベースとのやり取りを処理します。この自動的な動作の最初のステップが、行レベルのロックです。
BC4Jは、排他ロックと共有ロックのどちらを使用するかを宣言的に設定できます。エンティティ・オブジェクトが排他ロックとして設定された場合、属性に対する変更が（妥当性検査を無事通過して）成功すると、エンティティ・オブジェクトはデータベース内の対応する行をロックしようとします。ロックできない場合には、例外がアプリケーションにトラップされ、処理されます。
エンティティ・オブジェクトの新しいインスタンスが生成されるか、既存のインスタンスが修正または削除されると、影響を受けたエンティティ・オブジェクトのインスタンスは、トランザクションのコミット時に、基礎となるデータベース表に自動的に変更を通知します。コミットされる前の確定保留状態にある変更はすべて、現在のトランザクションの一環として発生したものとして識別されます。これらの変更は、現行のルート・アプリケーション・モジュールに関連付けられ、含まれるすべてのアプリケーション・モジュールで共有されます。
変更が確定保留状態としてキャッシュ内にある間でも、エンティティ・オブジェクトのビジネス・ロジックが機能して、Associationを探索し、関連するオブジェクトのすべての検証ルールに関するチェックを行うということは、アプリケーション開発者にとって決定的に重要な機能です。つまり、このビジネス・ロジックは、関連するオブジェクトに対するすべての確定保留状態の変更に対して、データベースに対するコミットが行われる前に、ビジネス・ロジックが正しく実施されることを保証します。
クライアント・アプリケーションまたはアプリケーション層のビジネス・ロジック内のコード上で、アプリケーション・モジュールに対して getTransaction().commit() をコールするだけで、その他のコードを記述することなしに、キャッシュ内の変更されたすべてのエンティティ・オブジェクトのデータは、その変更内容をデータベースに効率的に放出します。
もちろん、このようなアプリケーション・フレームワークでは、フレームワークが提供するデフォルトの動作を望まない場合に、戦略的にフレームワークの機能を無効にし、特定のケースに合わせて動作させることができることも重要です。エンティティ・オブジェクトのデータベースとの対話のデフォルトのメカニズムをオーバーライドするには、そのエンティティ・オブジェクト内のたった一つのメソッドdoDML() をオーバーライドするだけです。カスタムの格納の実装を必要とする場合、たとえば、受注（Orders）を削除する場合に、物理的に行を削除するのではなくDeleted列のフラグを立てるだけにする、というような場合には、この手法によってその要求に沿った処理をすばやく実現することができます。
図4 で紹介したように、Associationを使うことで、エンティティ・オブジェクト間を簡単に遷移できます。通常は外部キー値によって関連情報を参照するといったSQLコールが必要ですが、Associationを利用すると、そういった実際的なSQL記述作業が必要なくなります。
| 技術ハイライト | |||||||
|---|---|---|---|---|---|---|---|
|
アプリケーションによっては、システムの各ユーザーの多様な役割や職務によって処理が異なるため、実行時でないと必要とされる正確なアプリケーション・コンポーネント定義が明確にならない場合もあります。これに対処するために、BC4Jフレームワークでは、個々のビュー・オブジェクト、もしくは事前調整済みのビュー・オブジェクトで構成されるアプリケーション・モジュールを、クライアント・アプリケーションの実行時にオンデマンドでロードすることが可能です。
開発者は、ビジネス・コンポーネントの完全なパッケージ修飾名を参照するだけで、現在のセッションでアプリケーション・モジュールを簡単にインスタンス化でき、以下のコード例に示すように、名前によってそのビュー・オブジェクトの1つを見つけることができます。
ApplicationModule theAM = createApplicationModule("comm.order.OrderSystem");
ViewObject theVO = theAM.findViewObject("LineItems");
|
ViewObject myVO = createViewObject("comm.order.UnpopularItems");
|
theAM.remove(); myVO.remove(); |
アプリケーションの汎用性を高めるために、フレームワークを使って構築されたコンポーネントにカスタムのプロパティを関連付ける能力が提供されています。任意の名前/値の情報セットを、任意のコンポーネントのXMLコンポーネント定義で関連付けることができ、シンプルなAPI によって、このカスタム・メタデータを実行時に取得して、さまざまな動的な決定処理に利用できます。
カスタム・プロパティは、各エンティティ・オブジェクト、ビュー・オブジェクトおよびその属性レベルだけでなく、ドメインにも割り当てることができます。BC4Jフレームワークを利用する開発者は、カスタム・プロパティを用いて、次のような情報を、より賢く総合的に保持させることができます。
もう一つ、派手ではないものの重要な機能が、実行時に動的に属性を追加することができる能力です。これを利用すると、ビュー・オブジェクトの行ごとの状態を追跡することが可能になります。BC4Jフレームワークでは、ほとんどすべての処理をアプリケーション層で行うことによってクライアント・メモリとコードの絶対量を少なくすませることができるように設計されています。このため、キャッシュされたデータはすべてアプリケーション層に存在します。このような中間層での動的な情報を管理できるようになります。
動的に属性を追加するためには、単に対象としたいビュー・オブジェクトに対して AddDynamicAttribute() をコールします。例えば、このときに、コールした時点の情報を使って、その属性に値を設定できます。動的属性は、ビュー・オブジェクトの通常の属性と同じようにキャッシュされ、管理されます。また、ビュー・オブジェクトの様々な属性と同様、動的属性も直列化可能な（シリアライズ可能な）オブジェクトです。したがって、そのデータを利用する際に、クライアントへのデータ転送を必要としません。大規模なビュー・オブジェクトの結果セットの場合、これは大きな利点です。
| 技術ハイライト | |||||||
|---|---|---|---|---|---|---|---|
|
開発者は、好みのテキスト・エディタなどでコンポーネントのJava実装クラスやXMLコンポーネント定義に手を加えて、自身のBC4Jアプリケーションを開発・強化することもできますが、Oracle JDeveloperは、フレームワークをアプリケーションで使用するための多くの局面を自動化する、統合された設計時のサポートをBC4Jフレームワークに提供しています。
図14 は、Oracle JDeveloper 統合開発環境（IDE）を示します。JDeveloperのシステム・ナビゲータは、アプリケーション・モジュール、エンティティ・オブジェクトなどのビジネス・コンポーネントを表示します。各ビジネス・コンポーネントの重要な詳細情報は、構造ペインに表示されるので簡単に参照することができます。システム・ナビゲータでコンポーネントのツリーを開くと、コンポーネントのXMLコンポーネント定義とJava実装クラスが現れます。
 |
| 図14：Oracle JDeveloper IDEと統合された、BC4Jフレームワーク設計機能 |
BC4Jウィザードやコンポーネント・エディタなどの統合された設計ツールを使用して、アプリケーションを実現するために必要なユーザー固有のコンポーネント特性をすべて定義できます。ウィザードを使って新しいコンポーネントを作成したり、コンポーネント・エディタを使ってその局面を変更したりすると、BC4Jの設計支援ツールが、Java実装クラス内のコードを自動修正し、XMLコンポーネント定義ファイルをその変更に同期化させます。Java実装クラスで記述すべきコードは、ユーザー固有のビジネス・ロジックや、フレームワークで用意されたメソッドのオーバーライド・コードのみです。つまり、BC4Jの設計支援ツールがこれらのファイルに対して行うコード変更は、具体的には以下のものになります。
図15 は、アプリケーション・モジュール・エディタの1つのパネルです。ここでは、マウスを数回クリックするだけで、アプリケーションに組み込むべきビュー・オブジェクトおよびビュー・リンクを特定できます。
 |
| 図15：アプリケーション・モジュール・エディタを使って、データモデルを定義する |
実際には、多くのアプリケーション開発者は様々な開発手法を組み合わせて開発することがあります。たとえば、コンポーネントの基本機能や関連するXMLコンポーネント定義を設定するために、BC4JウィザードやOracle JDeveloperのコンポーネント・エディタを使用し、ユーザー固有のビジネス・ロジックの実装のためのコーディング作業には、好みのエディタを使用する、というような場合もあるでしょう。
エンティティ・オブジェクトからデータベース表を作成するための機能と、既存の表からのすべての基本的なフレームワーク・コンポーネントを生成する機能の両方をサポートしています。
 |
| 図16：ビジネス・コンポーネント・プロジェクト ウィザードを使って、デフォルトのエンティティ・オブジェクト、 ビュー・オブジェクト、およびアプリケーション・モジュールを迅速に作成 |
ビジネス・コンポーネント・プロジェクト ウィザードを利用すると、その過程で、ベースとするデータベース・スキーマを選択できます。その選択に応じて以下のものが自動的に作成されます。
同じ操作を、UMLダイアグラムを用いて、よりビジュアルに行うこともできます。UMLダイアグラムを用いると、JDeveloperのシステム・ナビゲータからデータベースのスキーマ情報を参照して、UMLダイアグラムにドラッグ&ドロップすることで、対応するエンティティ・オブジェクトを自動作成し、それをUML表記します。
 |
| 図17：システム・ナビゲータからUMLにドラッグ＆ドロップしてエンティティ・オブジェクト定義を作成 |
これにより、完全に機能する初期アプリケーション・モジュールを極めて迅速に作成することができ、このアプリケーション・モジュールを即座にテストして、アプリケーションに必要なユーザー固有の機能をサポートするように進化させることができます。
逆に、BC4Jのコンポーネントを定義することからスタートして、各エンティティ・オブジェクトに対応したデータベース表を作成することも可能です。これを行うには、UMLダイアグラム上でエンティティ・オブジェクトを選択し、データベース・オブジェクトの生成メニューを選択するだけです。
 |
| 図18：エンティティ・オブジェクト定義から、対応するデータベース表を作成 |
アプリケーション・ロジックをビュー（UI 画面）から明確に分けることの多くの利点の1つに、ビジネス・ロジックに携わるチームが、それを様々なアプリケーションとして再利用する開発チームとは独立して作業できることがあげられます。ビジネス・ロジックを記述する開発者で、ユーザー・インタフェース開発の必要性がまったくない場合、組込みのBusiness Component Browserが極めて便利です。Business Component Browserを利用すると、特別なユーザー・インターフェース開発をせずとも、ビジネス・ロジックを即座にテストすることができます。これは、IDEのシステム・ナビゲータでアプリケーション・モジュールを選択し、右マウス・メニューから「テスト...」を選ぶだけで起動できます。
 |
|
図19：Oracle Business Component Browserを使用したビジネス・ロジックのテスト。 |
図19 で紹介した Business Component Browserは、Thin Javaクライアント・アプリケーションの一例でもあります。これは、BC4Jフレームワークが持つ"動的機能"を使って、アプリケーション・モジュールの実行情報を取得し、現在のアプリケーション・モジュールに含まれるビュー・オブジェクトとビュー・リンクの構造を表示しています（画面左側）。このツールは、各ビュー・オブジェクトに対してSwingベースのフォーム画面を、各ビュー・リンクに対してマスター/ディテール・フォーム画面を、それぞれ動的に作成します。
Business Component Browserでは、以下のような、BC4Jフレームワークのランタイム機能のすべてを視覚的に確認できます。
Business Component Browserによって、一般的なクライアント・アプリケーションがアプリケーション・モジュールのビュー・オブジェクトと協調動作している様子を確認することができます。それはまた、BC4Jを使うことで多くのアプリケーション・ロジックと調整機能を論理アプリケーション層にカプセル化できること、その際にクライアント層を複雑化したりコーディングを迫られる必要がないことが明白になります。また、Business Component Browserは便利なテスト・ツールであるという以外に、便利な参考書でもあるということ付け加えておくべきでしょう。Business Component Browserのフル・ソース・コードは、サンプル・アプリケーションとしてOracle JDeveloperに付属されています。
| 技術ハイライト | |||||||
|---|---|---|---|---|---|---|---|
|
列とエンティティ・オブジェクト属性との関連付けを管理したXMLコンポーネント定義メタデータに基づいて、ビュー・オブジェクトによる問合せデータは、適切な行キャッシュに分割格納されます。このアーキテクチャによって、実行時の利点の多くが可能になります。
図20 に示すように、クライアントが、myEmployeeList.executeQuery() をコールすると、アプリケーション層に常駐するビュー・オブジェクト実装がその問合せを直接データベースに送って即座に実行させます。ビュー・オブジェクトはデータベース問合せの結果をフェッチし、以下のことを行います。
ほとんどすべてのオブジェクト/リレーショナル・マッピング・ツールによるアプローチと全く対照的なのは、たとえOrdersオブジェクトの構造が複雑で、200を超えるほどの属性があるような場合であっても、BC4Jでは、TotalAmount属性を参照するためだけであれば、その200の属性を問合せすることは決して ないということです。
 |
| 図20：部分的フェッチとアプリケーション層のキャッシング |
データの任意のSQLビュー（ビュー・オブジェクト）と、ビジネス・ロジックを実施し、矛盾なくカプセル化されたビジネス・コンポーネント（エンティティ・オブジェクト）との協調動作という、この驚くほど現実的で強力なアプローチの下で、システムのアプリケーション層は効率的に稼動し続けます。しかし、これは、非常に効率的な三階層アプリケーションを提供するためにBC4Jが実施するメカニズムのほんの一部に過ぎません。
もう一度、図20 をご覧ください。データのキャッシングは、クライアント層ではなくアプリケーション層にあります。これは、図が示すように、BC4Jの三階層アプリケーション内の大量のデータが論理アプリケーション層に保持され、BC4J アプリケーション・モジュールによって管理されることを意味します。IIOPまたはRMIを介してアプリケーション・モジュールやビュー・オブジェクトを遠隔使用するクライアントとは、本来必要な少量のデータ（例えば、クライアント層で現在画面に表示している分だけのデータ）以上のものをやり取りする必要はありません。
BC4Jフレームワーク・コンポーネントと実行時のリモート・クライアントAPIによって、このようなリモートでアクセス可能なSQLベースのビュー・オブジェクトの自動管理機能が提供されます。例えば、アプリケーション層にキャッシュされた大量の行のうち、表示するデータ範囲（これは開発者が構成可能）だけをローカルにキャッシュするといった機能があげられます。
CORBAおよびEJBの標準のリモート・アーキテクチャの採用に加えて、アプリケーション・モジュールには、さらなる最適化が行われており、それによってクライアント層とアプリケーション層間のネットワーク・ラウンドトリップの数を絶対的な最小値に保ちます。BC4Jフレームワークが提供するネットワーク・パフォーマンスの最適化は、スケーラブルな三階層エンタープライズ・アプリケーションの構築に特に重要です。きめ細かくアプリケーション・サービスのリモート・アクセスを提供して多大なネットワーク・トラフィックを発生させることを避けて、ビジネス・エンティティを内部的に管理し、全体をEJB Session Beanとするというアプローチは、高度にスケーラブルなアプリケーションに対するソリューションです。
※ このアプローチは "Session Facade" パターンとして「J2EEデザイン・パターン」にもあげられています。
アプリケーション・モジュールをCORBAサーバー・オブジェクトまたはEJB Session Beanとして配布する場合、設計上、アプリケーション・コンポーネントに対して複数のリモート・インタフェースが必要となることはありません。これにより、すべてのサービスにEJB Entity Beanを使用した場合にありがちな、クラスとインタフェースの過多な公開/アクセス によるオーバーヘッドを回避し、環境をよりシンプルに保つことができます。
アプリケーション・モジュールをCORBAサーバー・オブジェクトまたはEJB Session Beanとして配布する場合、最低限必要なのは、1つのリモート・インタフェースだけです。他にアプリケーション・モジュールに対してリモート・アクセス可能なビジネス・メソッドを公開する必要がない場合は、余分なリモート・インタフェースは一切不要で、BC4Jフレームワークが提供するデフォルトのインタフェースで十分です。このセクションで説明したBC4Jのすべての機能は、分散型エンタープライズ・アプリケーションにとって、よりシンプルで効率的、かつネットワーク性能の高いアーキテクチャだといえます。
| 技術ハイライト | |||||||
|---|---|---|---|---|---|---|---|
|
BC4Jを導入することで、層を意識せずに、業界標準に完全に基づく、分散型アプリケーション開発のための生産的なプログラミング・モデルが提示されます。（ユーザー・インターフェースの有無に関係なく）クライアント・アプリケーションは、シンプルな共通のインタフェースのセットを使って、ユーザー固有のアプリケーション・モジュールやビュー・オブジェクトといったBC4Jフレームワーク・コンポーネントにリモート・アクセスします。これによって、以下の厳密な論理的分離が促進されます。
BC4Jでは、クライアント・コードのために用意された共通インタフェースを通して、リモートのアプリケーション・モジュールやビュー・オブジェクトに作用するので、開発者が記述したアプリケーション・コードを修正することなく、これらの3つの論理層を自由に組み合わせて物理的に配布することが可能です。
以下の図21 に、クライアントがCORBA IIOPまたはEJB RMI-IIOPのいずれかを介して、アプリケーション・モジュール・コンポーネントにリモート・アクセスする場合を示します。
 |
| 図21：アプリケーション・モジュールへのリモート・アクセスの例 |
この図のような構成は、Javaアプリケーションまたはアプレットから、 EJBサーバー上のEJB Session BeanまたはCORBAオブジェクトとして配布されたアプリケーション・モジュールにリモート・アクセスするケースをあらわしています。
論理クライアント層が、論理アプリケーション層（アプリケーション・モジュールが配置されている層）と同じJava VMに物理的に共存している場合、クライアントが使用するアプリケーション・インタフェースには、 リモート・インターフェースは一切必要ありません。しかしながら、まったく同じアプリケーション・プログラミング・モデルを使用できます。
次の図22は、ローカル・クライアントの場合を示しており、以下のような構成のひとつの例です。
 |
| 図22：HTMLサーブレットまたはアプリケーション・モジュールのJSPクライアント |
図23は、アプリケーション・モジュールの代表的な配布構成を要約したものです。
 |
| 図23：アプリケーション・モジュールの代表的な配布オプション |
EJB Entity Beanに対するリモート・アプリケーション開発の場合のように、データベース内の表に対してそれぞれのリモート・インタフェースが存在し、そのそれぞれに対し手作業でプログラミングを行うのではなく、BC4Jを使ってEJB Session Beanとしてアプリケーション・モジュールを配布すれば、すべての作業が代行されます。BC4Jでは、生産性が高くしかもシンプルなクライアント用のインタフェース・ライブラリが提供され、リモートのアプリケーション・モジュールおよびその内部のビュー・オブジェクト、ビュー・リンクとともに動作するために使われます。これにより、クライアント層のユーザー・インターフェースを開発するプログラマは、JDBCの結果セットを扱う場合と同様の手法でビュー・オブジェクトによる結果セットを扱うことができます。
重要な違いは、JDBC結果セットを操作する際の複雑さが一切追加されないことです。ビュー・オブジェクトは、表示範囲のスクロールを完全に制御し、更新可能で、ビジネス・ロジックの施行が保障された行セットであり、自動的に層にまたがって作用し、自動的にマスター/ディテールが調整され、アプリケーション層内の問合せされた大量のデータを容易に管理します。
| 技術ハイライト | |||||||
|---|---|---|---|---|---|---|---|
|
エンタープライズ・アプリケーションをひとたび開発・配布したら、通常発生する次のステップは、新たなニーズに合わせて調整することです。
Oracle Business Components for Javaは、これらのニーズに対し、シンプルかつ革新的なソリューションを提供します。BC4Jは、すぐにでもアプリケーションの機能をカスタマイズできるよう構成されています。すべてのフレームワーク・コンポーネントでは、そのXMLコンポーネント定義とJava実装クラスが明確に分離されています。このため、ユーザー独自でコンポーネントのカスタマイズが必要な場合、フレームワークのベース・コンポーネントのJava実装クラスを（Java言語の継承機能を活用して）継承・拡張することで実現できます。これにより、カスタマイズを容易にします。
カスタマイズ・ソリューションとなるもう一つの点は、BC4Jフレームワークの、XMLコンポーネント定義の拡張に対する組込みサポートにあります。エンティティ・オブジェクト、ビュー・オブジェクト、アプリケーション・モジュールを、新しくユーザー固有のコンポーネントとして作成した場合、すでにあるコンポーネントのメタデータを宣言的かつ単純に拡張できます。たとえば、図3
のOrders エンティティ・オブジェクトを拡張するには、Oracle JDeveloper IDEを使用して、comm.order.Ordersを拡張した新しいエンティティ・オブジェクトを作成するだけです。XMLコンポーネント定義の拡張機能を使えば、ユーザーはCustomOrderに新しく追加する情報、ベースから変更する情報についての記述をするだけで済みます。この結果、新しい、拡張されたCustomOrderに対するXMLコンポーネント定義は、次のようになります。
<?xml version="1.0" encoding='Shift_JIS'?>
<!DOCTYPE Entity SYSTEM "jbo_03_01.dtd">
<!--
|
| CustomOrderエンティティ・オブジェクトに対する
| XMLメタデータ・ファイル。Ordersエンティティ
| オブジェクトを拡張して、新規属性を一つ追加している。
|
+-->
<Entity
Name="CustomOrder"
TimeStamp="1031118615824"
Extends="comm.order.Orders"
DBObjectType="table"
DBObjectName="CUSTOM_ORD"
AliasName="CustomOrder"
BindingStyle="Oracle"
UseGlueCode="false"
CodeGenFlag="4"
RowClass="comm.order.CustomOrderImpl" >
<Attribute
Name="MyCustomAttributeName"
Type="java.lang.String"
ColumnName="MY_CUSTOM_ATTR_NAME"
ColumnType="VARCHAR2"
SQLType="VARCHAR"
Precision="255"
TableName="CUSTOM_ORD" >
</Attribute>
</Entity>
|
 |
| 図24：BC4Jの階層的なカスタマイズ |
オプションで、開発者はカスタマイズされたコンポーネントで、拡張元のコンポーネントを完全かつ大域的に置き換えるかどうかを決定することができます。例えば、カスタマイズを行う開発者は、追加コーディングなしで、newpackage.CustomOrder で comm.order.Ordersを置き換えることが可能です（BC4Jコンポーネントのプロジェクト・ファイルで、この置き換えの設定が可能です）。この設定がなされると、実行時に、comm.order.Ordersのインスタンスを使用する要求がなされると、代わりにカスタマイズされたnewpackage.CustomOrder エンティティ・オブジェクトのインスタンスが与えられます。このインスタンス作成時の置き換えは、すべてのフレームワーク・コンポーネントに適用されます。
コンポーネントの拡張機能とインスタンス作成時の置き換え機能を組み合わせて利用できることにより、ベース・コンポーネントのソース・コードを変えることなく、その動作を自分用に調整することができます（もっというと、ベース・コンポーネントのソース・コード自体が不要です）。さらには、コンポーネントの元のバージョンをカスタマイズされたバージョンに置き換えることができます。インスタンス作成時の置き換え機能によって、元のコンポーネントを利用していたアプリケーションは、カスタマイズされたコンポーネントの存在について何も知らなくても、実行時に、カスタマイズされたバージョンを使用するようになります。
BC4J フレームワークにおける、XMLベースのコンポーネント定義管理およびその拡張機能によって、コンポーネントをカスタマイズした新バージョンをアプリケーション稼動の後でも任意に追加でき、次にアプリケーションが起動されたときにその新機能を取り出すように設計されています。
Oracle Business Components for Javaは、CORBA、EJB、Javaサーブレットといった、業界標準のサーバー環境に提供するためのJavaによるエンタープライズ規模のアプリケーション開発、配布およびカスタマイズに対する実践的なアプローチを提供します。
BC4Jアプリケーション・フレームワークは、Java開発者にとって馴染みのある技術を有効に結合させた姿であり、効率的な分散型ビジネス・アプリケーションを構築する際の困難な部分すべてを処理することで開発者の生産性を向上させ、開発の下流的作業である部品の組み合わせや調整、結合といった作業ではなく、まさに目の前の業務に真に集中させることができます。
また、このテクノロジは、全世界のオラクルのアプリケーション開発およびコンサルティング部門により共同設計され、現在使用されている基礎テクノロジです。Oracle JDeveloperとともにOracle Business Components for Javaを利用する開発者は、そういった非常に幅広い分野ですでにテスト済みの実績あるコンポーネントを使って、コンポーネント・ベースのJavaアーキテクチャのエンタープライズ・アプリケーションへと移行することができるでしょう。
| Oracle Corporation World Headquarters 500 Oracle Parkway Redwood Shores, CA 94065, USA http://www.oracle.com |
世界共通窓口： 1-800-ORACLE1 Fax: 650.506.7200 |
Oracle、JDeveloperはオラクル社の商標です。 言及されているその他すべての会社名および製品名は、特定のみを目的としており、それぞれの所有者の商標である場合があります。 版権(c) Oracle Corporation 1999 無断転載を禁ず |
