Java EEアプリケーションデザイン
これまでの説明で、Java EEアプリケーションデザインの詳細に踏み込むための基礎はできました。とはいえ、Java EEソフトウェアのデザインはそれ自体で大きな題材であり、多くの書物で取り上げられてきたことです。この記事でのねらいは、Spring Frameworkを使ってパターンとベストプラクティスを適用することにより、Java EEアプリケーションのデザインと開発を単純化することにあります。従って以下では、このテーマに沿いつつ簡潔さも考慮して、このコンテキストに関係するトピックだけを論じることにします。
開発者やデザイナの中には、Java EEアプリケーションデザインは本質的にオブジェクト指向デザインだと考えている人たちもいます。それは間違いではないのですが、Java EEアプリケーションデザインには従来のオブジェクトデザインよりもずっと多くのことが関係してきます。問題範囲のオブジェクトを見つけ、それらの関係と協働を把握する必要があります。個々のレイヤのオブジェクトには役割が割り当てられ、レイヤ間の対話のためにインターフェースが用意されます。しかし、それで終わりではありません。話はもっと複雑です。なぜなら、従来のオブジェクトデザインと違って、Java EEは分散オブジェクトテクノロジ（ビジネスコンポーネントを配備するためのEJBなど）をサポートしているからです。ビジネスコンポーネントはリモートアクセスが可能なセッションEnterprise JavaBeansとして開発されます。JMSとメッセージ駆動型Bean（MDB）はオブジェクトの分散非同期対話を可能にするので、話はいっそう複雑になります。
分散オブジェクトのデザインは、経験豊富なプロにとってさえ非常に複雑で厄介な仕事です。最終的なソリューションの草案を作る前に、スケーラビリティ、パフォーマンス、トランザクションといった重要な問題について検討する必要があります。使用するセッションEJBファサードの粒度を粗くするか細かくするかというデザイン上の決定は、Java EEアプリケーションの全体的なパフォーマンスに大きな影響を及ぼす可能性があります。またトランザクションに課する正しいメソッドの選択はデータ整合性に大きな影響を及ぼす可能性があります。
パターンによるアプリケーションデザインの単純化
Java EEのデザインパターンを適用すると、アプリケーションデザインを大幅に単純化できます。Java EEのデザインパターンについてはSunのJava BluePrintsでドキュメント化され、『Core J2EE Design Pattern』（Prentice Hall刊、2003年）でも詳細に論じられています。Java EEデザインパターンは『Design Patterns: Elements of Reusable Object-Oriented Software』（Addison Wesley刊、1994年）で説明されている基本オブジェクトデザインパターンを基礎にしています。これらのパターンは、同書が4人の著者（Eric Gamma、Richard Helm、Ralph Johnson、John Vlissides）によって書かれたところから、GOF（Gang of Four）パターンとも呼ばれています。Java EEパターンカタログではコアオブジェクトデザイン原則に加え、リモートアクセスが可能な分散オブジェクトの難題に対処するための方策も考慮しています。
デザインパターンは一般的なデザイン上の問題に再利用できるソリューションを記述したものです。デザインパターンは経験豊富な開発者とデザイナによって蓄積されドキュメント化されたテスト済みのガイドラインとベストプラクティスです。それぞれのパターンには次に示す3つの主要な特性があります。
- 「コンテキスト」―問題が存在する周囲条件です。
- 「問題」―その範囲における困難で不明確な対象領域です。検討すべきコンテキストによって限定されます。
- 「ソリューション」―検討している問題に対する改善策です。
ただし、問題に対するすべてのソリューションでその問題がパターンと見なされるわけではありません。問題がパターンと見なされて、再利用できるソリューションが生み出されるためには、その問題が頻繁に発生するものであることが必要です。さらに、パターンにおいてデザインソリューションを開発者とデザイナに知らせるための共通語彙を確立することも必要です。例えば、誰かがGOFのSingletonパターンに言及した場合、アプリケーション内でインスタンスを1つしか持たないオブジェクトをデザインする必要があるのだということを関係者全員が理解できることが必要です。多くの場合、このデザインパターンを実現するために、その記述に構造図と相互作用図ならびにコードが補足されます。各パターンの記述は一般に利点と問題点の分析で締めくくられます。
Java EEデザインパターンカタログ
既に述べたように、Java EEは10年近くにわたって最も優勢なエンタープライズ開発プラットフォームでした。その間、このテクノロジを使って構築され成功したアプリケーションと製品は何千もあります。しかし、失敗した試みもあります。失敗の原因はいくつかありますが、その中で真っ先に挙げられるのが不適切なデザインとアーキテクチャです。これが重大な領域であるのは、デザインとアーキテクチャは要件を構築フェーズに橋渡しするものだからです。けれども、Java EEのデザイナとアーキテクトは有用なデザインパターンのリストを作成することで失敗と成功の両方から教訓を学んできました。このJava EEパターンカタログは、Java EEアプリケーションの各レイヤのオブジェクト対話のために時の試練を経たソリューションのガイドラインとベストプラクティスを提供します。
プラットフォームそのものと同様、Java EEパターンカタログも進化してきました。既に述べたように、このカタログは初めSunのJava BluePrintsの一部としてまとめられ、後に『Core J2EE Design Pattern』（Prentice Hall刊、2003年）で詳細に論じられました。表1にこれらのパターンを示し、それぞれの簡単な説明と対応するレイヤを付記します。
| レイヤ | パターン名 | 説明 |
|---|---|---|
| プレゼンテーション | View Helper | プレゼンテーションをビジネスロジックから分離する |
| Composite View | レイアウトベースのビューを複数の小さなサブビューから作成する | |
| Front Controller | プレゼンテーション層のリソースに対する単一のアクセスポイントを提供する | |
| Application Controller | ページコントローラおよびビューコンポーネントとの調整を担うフロントコントローラヘルパとして機能する | |
| Service to Worker | 次のビューに制御が渡される前にビジネスロジックを実行する | |
| Dispatcher View | 次のビューへの応答を準備するために最小限のビジネスロジックを実行する（またはビジネスロジックをまったく実行しない） | |
| Page Controller | ページ上での各ユーザーアクションを管理し、ビジネスロジックを実行する | |
| Intercepting filters | ユーザー要求に対して前処理と後処理を行う | |
| Context Object | アプリケーションコントローラを特定のプロトコルへの結合から切り離す | |
| ビジネス | Business Delegate | 複雑なリモート分散オブジェクトになる可能性のあるビジネスロジックとページコントローラを切り離すためのブリッジとして機能する |
| Service Locator | ビジネスオブジェクトへのハンドルを提供する | |
| Session Facade | リモートクライアントのためにビジネスレイヤへの入口として粒度の粗いインターフェイスを公開する | |
| Application Service | ビジネスロジックの実装を単純なJavaオブジェクトとして提供する | |
| Business Interface | ビジネスメソッドを集約し、EJBメソッドのコンパイル時チェックを適用する | |
| 統合 | Data Access Object | データアクセスロジックをビジネスロジックから分離する |
| Procedure Access Object | データベースのストアドプロシージャと関数へのアクセスをカプセル化する | |
| Service Activator（Message Facade） | 要求を非同期に処理する | |
| Web Service Broker | Webサービス標準として公開された外部アプリケーションにアクセスするためのロジックをカプセル化する |
表1はJava EEの現在の状態に合わせて少し修正してあります。例えば、Data Transfer Objectパターンはもうカタログに含まれていないので、この表から抹消しました。このパターンはレイヤ間でデータを転送するのに使われていたもので、リモートエンティティBean持続性コンポーネントを使用する場合に特に便利でした。しかし、新しいJava Persistence API（Java EE 5プラットフォームの一部）が導入され、POJO（Plain Old Java Object）プログラミングモデルが大勢になったことで、このパターンはもはや意義を失っています。
この表は決して完全なものではありません。パターンの中には、いろいろな層に適用できるものがあります。例えば、セキュリティデザインパターンをプレゼンテーションレイヤに適用すれば、JSPなどのWebリソースへのアクセスを制限できます。またセキュリティパターンを使用して、ビジネスレイヤのEJBコンポーネントに関してメソッド呼び出しを制御することもできます。トランザクションパターンはビジネスレイヤと統合レイヤの両方に適用できます。これらのパターンは「横断的（cross-cutting）」パターンに分類されます。
