ビジネス・ロジック層には、他の層(クライアントおよびデータベース)が対話する1つ以上のアプリケーション・モジュールがある。アプリケーション・モジュールは、オンライン注文の処理や昇給の処理などの特定のアプリケーション・タスクを実行する。アプリケーション・モジュールには、次の主要な特性がある。
クライアントが使用するデータ・モデルを表す。データ・モデルを作成するために、アプリケーション・モジュールには、ビュー・オブジェクトおよびビュー・リンクのインスタンスなどのビジネス・コンポーネントが含まれる。(これは、Javaフレームにリスト・ボックスやグリッド・コントロールなどのコンポーネントのインスタンスを含めることと同じである。)
ネストしたアプリケーション・モジュールと呼ばれる他のアプリケーション・モジュールを含むことができる。1つのアプリケーション・モジュールに、様々な基本的アプリケーション・モジュールを含め、これを組み合せて複雑な機能を提供できる。たとえば、OnlineOrdersアプリケーション・モジュールには、AddNewCustomerアプリケーション・モジュールを含めることができる。
データベース内のデータに影響するすべての変更を管理する。最上位レベルのアプリケーション・モジュールは、その中に含まれるビュー・オブジェクト・インスタンスのトランザクション・コンテキストを提供する。これには、ネストされたすべてのアプリケーション・モジュール内のインスタンスも含まれる。これは、アプリケーションに必要なアプリケーション・モジュールを決定する際に考慮すべき重要な事項である。たとえば、注文の作成と顧客の追加を同じトランザクションに含めることができる。
リモートでアクセス可能なメソッドを提供する。このメソッドは、アプリケーション・モジュールの動作を実装する。カスタム・メソッドを追加し、クライアントで使用するこれらのpublicメソッドを選択的にエクスポートできる。たとえば、従業員の昇給を処理するアプリケーション・モジュールは、従業員の給与情報を検索して昇給額を加算するメソッドをエクスポートできる。
最上位レベルのアプリケーション・モジュールには、データベースへの接続が1つある。
コードを変更せずに、同じアプリケーション・モジュールをCORBA、EJB、ローカルなどの複数の構成でデプロイできる。また、コードを変更せずに、同じアプリケーション・モジュールを(層が1台、2台または3台のコンピュータにある)物理的に1層、2層または3層のアプリケーションで使用できる。開発の完了後に、特定のデプロイメント・プラットフォームに依存することはない。
アプリケーション・モジュールは個別の単位であるため、他のアプリケーションのビジネス・ロジック層で簡単に再利用できる。
ビジネス・ロジック層をプログラミングする際に、ビジネス・ロジックは、ビジネス・コンポーネントの再利用を簡単にするために様々なレベルに配置される。
エンティティ・オブジェクトには、単一のビジネス・エンティティに関連するビジネス・ロジックが含まれる。エンティティ・オブジェクトに基づくすべてのビュー・オブジェクトは、ロジックを共有する。エンティティ・レベルでは、計算はJavaコードで実行される。
ビュー・オブジェクトには、SQLのSELECT文で定義される、ビューに関連するロジックが含まれる。これには、SQLの計算式、結合、UNION、ネストした副問合せなどが含まれる。Javaソースにコードを追加することもできる。たとえば、UIにイベントを伝播したり、このビューで公開するエンティティ・メソッドをコールするメソッドを作成できる。
アプリケーション・モジュールのソース・ファイルには、実行するタスクに固有のロジックを含めることができる。これは、エンティティ・オブジェクトまたはビュー・オブジェクトに含めるのには適していないロジックで、異なるタスクを実行する複数のアプリケーション・モジュールで使用できる。2つのアプリケーションで同じビューを使用する場合、一方のアプリケーションに固有のロジックは、エンティティまたはビュー・オブジェクトのソース・ファイルではなく、そのアプリケーション・モジュールのソース・ファイルに含める。一般的なガイドラインとしては、タスクごとに1つのフォームがある場合、フォームごとに1つのアプリケーション・モジュールが存在するようアプリケーションを作成できる。アプリケーション・モジュールは、1つのトランザクション内で完了するタスクのデータ・モデルを表す。
アプリケーション・モジュールでは、クライアント・インタフェース(フォームなど)に合せてデータを収集するため、複数回ではなく1回のネットワーク・ラウンドトリップでデータを取得できる。リモート・アクセス可能なメソッドを介してビジネス・ロジック層で計算を実行し、クライアントのオーバーヘッドを削減することもできる。アプリケーション・データのバルク操作の場合、すべてのデータをクライアントにダウンロードするのではなく、ビジネス・ロジック層で操作を行う。クライアントが現在表示しているデータへの変更は、自動的に同期化される。
アプリケーション・モジュールを設計時に作成および編集するには、アプリケーション・モジュール・ウィザードおよびアプリケーション・モジュール・エディタを使用する。また、ビジネス・コンポーネント・プロジェクト・ウィザードおよびビジネス・コンポーネント・パッケージ・ウィザードを使用することにより、デフォルトのアプリケーション・モジュールも作成できる。
実行時、クライアントは使用するアプリケーション・モジュールのインスタンスを作成する。作成できるのは、設計時に作成したアプリケーション・モジュールのインスタンス、または汎用アプリケーション・モジュールと呼ばれるベース・アプリケーション・モジュール・クラスのインスタンスである。汎用アプリケーション・モジュールは、動的に作成されたビュー・オブジェクト、ビュー・リンクおよびアプリケーション・モジュールのコンテナが必要な場合に使用できる。たとえば、クライアント・メニューに多数のタスクが含まれた、複雑なアプリケーションがある場合、メニューでの選択に基づいて、同じトランザクション内で、アプリケーション・モジュールを必要に応じてインスタンス化する汎用アプリケーション・モジュールを作成できる。
クライアントは、プール内のアプリケーション・モジュール・インスタンスを使用できる。たとえば、あるWebアプリケーションを最大1000人のユーザーが使用できる場合に、特定のアプリケーション・モジュールは同時に100人のユーザーしか使用しないとする。この場合、プール内に100個のアプリケーション・モジュール・インスタンスを保持する。あるクライアントでアプリケーション・モジュール・インスタンスが必要になると、そのクライアントは、プール内の空きインスタンスを取得し、トランザクションをコミットまたはロールバックした後で、プールに解放する。インスタンスはあらかじめ作成されているため、エンド・ユーザーは、タスクを実行する際にアプリケーション・モジュールをインスタンス化する時間が短縮される。通常は、WebベースのJSPクライアントでプールを使用する。