第4回　実装のアーキテクチャを決めよう

樫山友一
2002/4/23

---

　今回からJ2EEアプリケーション・サーバを利用した設計に入ります。第3回「UMLモデリングによる設計の流れを理解する」までのフェイズは、プラットフォームに依存しない段階の設計でした。今回は、前回行っ た設計をプラットフォームに依存したモデルへと落とし込んでいくプロセスを解説します。

　ところで、今後、プラットフォームはJ2EEのテクノロジーを含めて速い速度で進化していきます。よって、前回作成したプラットフォームに依存しないモデルを作成することはとても重要なことになりつつあります。将来は、 プラットフォームに依存しないモデルをプラットフォームに依存するモデルへと自動的に変換するCASEツールなどが登場するでしょう。

J2EEのどのテクノロジを使えばよいのか

　ここでは、J2EEアプリケーション・サーバを利用して開発を行うということを前提に設計を進めていきます。

　J2EEを用いて開発を行う場合、どの部分にどのテクノロジを使うべきか悩む方も多いのではないでしょうか。例えば、今回のプロジェクトでEJBを使うべきなのか、JSPとServletのどちらを使うかなどです。大体は第1回「Webサイトの構成とJ2EEサーバ」で解説したようにMVCモデルを採用するわけですが、モデル、ビュー、コントローラのそれぞれに、どのアーキテクチャを採用するか決める必要があります。次にいくつかの例を示します。

	メリット	デメリット
すべてをJSPで実装	ソースコードの管理などがしやすい。手軽に開発を行うことができる。ロジックやページ数が少ないシステム、データベースを参照しないシステムなど、小さいシステムに適している	モデル、ビュー、コントローラを明確にすることが難しい。コードがJSPに多く入ってしまい、読みにくい
すべてをServletで実装	ソースコードの管理などがしやすい。JSPに比べ、ソースコードが読みやすい	JSP同様、モデル、ビュー、コントローラを明確にすることが難しい
EJBとJSPで実装	モデル、ビュー、コントローラを明確にして実装することが可能。EJBコンテナがトランザクションの管理を行うので、トランザクションの多いシステム開発が効率的に行える	EJBを理解できるエンジニアが少ない。EJBコンテナを持ったアプリケーションサーバーが高価である
Servlet、JSP、EJBの組み合わせで実装	EJB、JSPのみの場合に比べ、コントローラ部分をより柔軟に設計することが可能	複数の仕様を用いるため、管理に手間がかかる
表1　Servlet、JSP、EJBをどう組み合わせて構築するかはそれぞれのメリット、デメリットを考えて決める

　それぞれメリット／デメリットがありますが、比較的小規模のシステムであれば、JSPやServletのみで開発すると効率がいいでしょう。大規模なシステムや再利用を考えると、やはりEJBをお勧めします。EJBではJ2EEアプリケーション・サーバの機能により、データベースから取得したデータをキャッシュすることもできますし、トランザクションの管理をJ2EEアプリケーション・サーバに任せることで、コーディングが楽になるなどのメリットもあります。また、パフォーマンスの面でもEJBを用いた方が有利になるケースもあります。

JSPとEJBによる実装を考える

　　では、前回から例に挙げている受注システムの場合はどうでしょうか。このシステムは、明らかにイントラネットのシステムであるため、それほど負荷はかからないと思われます。しかし今後ほかの部署のシステムに転用する場合の再利用性などを考えると、MVCでしっかり実装する必要があるでしょう。よって、ここではJSPとEJBによる実装を考えましょう

図1　前回作成したモデル

　図1は前回作成したモデルです。このモデルにはステレオタイプとしてMVCが明確になっています。よって、Controllerのステレオタイプを持つクラスはコントローラへ、entityのステレオタイプを持つクラスはモデルへ実装することになります。また、controlの付いているクラスは、Session BeanあるいはJSPとして実装されることになります。

　実際にJSPとEJBを用いたシステムでは、図2のような動作をします。JSPはSession Beanを呼び出し、Session Beanは複数のEntity Beanからデータを取得して、表示のためのデータを収集、整形してJSPに返します。JSPは、Session Beanから受け取ったデータを表示します。

図2　JSPとEJBを用いたシステム

　このような構成を利用すると、MVCモデルを実現したアーキテクチャで開発が行えますが、Webアプリケーションがコンテンツの激しく入れ替わるサイトなどで利用されることを考えると、より柔軟にシステムを構成する必要があります。それは、図2の構造の上にフレームワークを用いると、システムのアーキテクチャをより柔軟で再利用性を高くすることが可能です。これからもう少し踏み込んで、JSPとEJBを用いたフレームワークを用いることを検討しましょう。

フレームワークを用いる

　昨年より、サン・マイクロシステムズが提唱しているJ2EEのブループリント（J2EEでアプリケーションを開発する際の設計指標を記述しているドキュメント）をベースとしたフレームワーク製品が登場してきています。これらフレームワーク製品を用いることで、より柔軟で再利用性の高いシステムを構築することが可能です。　フレームワーク製品の一覧は、コンポーネントスクエアのホームページに詳細が掲載されていますので、そちらを参照してください。

コンポーネントスクエア（http://www.c-sq/com/）

　J2EEブループリントを利用したフレームワーク製品の概要は、以下のようになっています。

図3　フレームワーク製品の概要

1. 送られてきたリクエストの内容を判断して、まず入力された内容が正しいかをチェックするためのコンポーネントを呼び出します。多くはServletとして実装されています。
2. 入力チェックのコンポーネントでは、実際に入力された値の型があっているか、例えば電話番号の入力欄に漢字が入っていないかなどのチェックを行います。JavaBeansや通常のJavaクラスを使って実装します。
3. 入力が正しい場合は、ビジネスロジックを呼び出します。このビジネスロジックは、JSPやJavaBeans、EJBなどを呼び出すことが可能です。
4. 最後にビジネスロジックから受け取ったデータを、JSPやServletでHTML化します。

　フレームワーク製品では、これら各コンポーネントへの対応を設定するGUIなどを持っています。また、コンポーネント情報を保持するサーバなどが用意されていて、必要に応じて取り出し、画面上でコンポーネント間の関係を定義できるものもあります。

　フレームワーク製品を用いるメリットとして、以下のことが挙げられます。

• JSP間の関係を疎に構成できるため、ページ構成の変更が容易になります。例えば、あるページを別のページへ遷移させる場合や、間にページを入れたくなった場合、コードの変更をせずにフレームワーク製品の設定を変えるだけでページ構成を変更できます
  
• フレームワーク製品に標準で用意されたコンポーネントを部品として利用することが可能です。また、自分で作成したコンポーネントも部品として利用可能なため、再利用性が向上します
  
• ページ間の構成をGUIツールなどで見ることができるため、複雑なWebサイトの構築に適しています

　ここでは、フレームワーク製品とほぼ同等の機能を持った、ApacheのJakartaプロジェクトで開発されているStrutsを用いて開発を行うことにします。

　Strutsでは、図3の各コンポーネントは以下のようになっています。

図2で示したコンポーネント	Struts
コントローラ	アクション・サーブレット
入力フォームのチェック	アクション・フォームBean
ビジネスロジック	アクション・クラス
表2　Strutsのコンポーネント

　Strutsの動作概要を図4に示します。　アクション・サーブレットがWebブラウザからの処理を最初に受け取り、アクション・フォームBeanが登録されていれば、登録されているアクション・フォームBeanを呼び出します。アクション・フォームBeanは、受け取ったフォームの情報を確認して、エラーがないかをチェックします。続いて、登録されているアクション・クラスを呼び出します。アクション・サーブレットがどのアクション・フォームBeanやアクション・クラスを呼び出すかは、Strutsの設定ファイルに格納します。ほかのフレームワーク製品では、これをツールでグラフィカルに設定できるものもあります。

　アクション・クラスを呼び出し、EJBから処理結果をもらった後、そのデータをHTMLに整形するためJSPへフォワードします。ここでどのJSPにフォワードするかも、Strutsの設定ファイルに格納されています。よって、設定ファイルにある各アクション・コンポーネントの関係を変更するだけでページ構成を変更することができます。

図4　Strutsの動作概要

　図3と表2では、ビジネスロジックと表示されていますが、実際にはこの部分にモデルかモデルをまたがったコントローラのコンポーネントが実装されることになります。

　図1に示すクラスは、実際にはモデルとそのモデルを利用するコントローラであるため、画面の表示部分は含まれていません。よってStrutsでは、この図1のクラス群は、すべてアクション・クラスか、アクション・クラスから呼び出されるクラスとして実装することになります。　まとめると以下のような構成となります。

• モデル
  アクション・クラス、またはアクション・クラスから呼び出されるコントローラとなるSession Beanから呼び出させるEntity Beanとして実装します
• コントローラ
  複数のモデルをまたがる場合は、Session Beanとして実装します。１つのモデルを使う場合は、アクション・クラスとして実装します
• ビュー
  アクション・サーブレットからフォワードされるJSPで実装します

　今回でアーキテクチャが決定しました。次回からは、このアーキテクチャに合わせて設計の詳細を進めていきます。

■参考文献

• 『わかりやすいUML入門』オーム社
• 『Webサイトのわかる本』オーム社

プロフィール

樫山友一（かしやま ゆういち） 大手電機メーカー研究所でオブジェクト指向によるシステム開発に従事する。1996年よりJavaへの取り組みをはじめ、J2EEアプリケーションサーバを活用したWebシステム構築のコンサルタントとして多数のプロジェクトを手掛ける。 2001年3月にイーズ・コミュニケーションズ株式会社の設立に参加し、最高技術責任者に就任。 著書に「わかりやすいUML入門」、「Webサイトがわかる本」（いずれもオーム社）がある。

Java Solution全記事一覧

＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）