サン認定Java Web Component Developer試験には、どうやらJ2EEが前提としているさまざまなデザインパターンについても出題されるらしい。自習がてら「Core J2EE Pattern Catalog」（J2EEの中核パターンカタログ）に掲載されているデザインパターンを一つずつ見ていく。

J2EEの中核パターンは利用者に近いフロントエンドから、データベース側に近いバックエンドまで、さまざまなパターン部品から構成されているようだ。フロントエンド側から中身を見ていきたい。

最初は「Intercepting Filter」で、利用者がWebクライアント（ふつうはWebブラウザ）から入力するさまざまな要求事項を、適切な処理へ割り当てるための前処理だ。その利用者に特定の処理を実行する権限があるか、その利用者のIPアドレスは信頼できるネットワークか、アプリケーション側がそのWebブラウザをサポートしているかなどなどのチェックを行う。このようなチェックをうまく実現するために、個々のチェックを行うプログラムを「フィルター」として部品化して、自由に追加したり外したりできるようにしようというのが「Intercepting Filter」の考え方だ。

次の「Front Controller」は利用者から見たときに、アプリケーションが一貫性のある見た目になるようにするためのもので、見た目を制御するプログラムを一箇所に集中化し、入り口を一つにしようという考え方だ。利用者はその入り口から入りさえすれば、ユーザ認証など後に続く処理が自動的につぎつぎ呼び出されるようにしておく。

次の「View Helper」は、時々刻々と変化するデータに合わせて、利用者に対して表示する内容を変化させるための考え方で、データの処理を行うプログラムと、見た目を組み立てるプログラムを分離することで、プログラムの保守性を良くする。

次の「Composite View」は、上述の「View Helper」で見た目を組み立てるプログラムとデータ処理のプログラムを分離するにしても、見た目を組み立てるプログラムの中身をさらに小さな部品に分解しておけば、見た目部分のプログラムの保守性がさらに良くなるでしょうという考え方にもとづいている。Webブラウザの画面上をいくつかの小さな部品にわけて、それぞれを組み立てる小さなプログラムを必要に応じて呼び出す。そういう考え方だ。

次の「Dispatcher View」は、利用者からの見たときの画面の表示順序をちゃんと制御しましょうという考え方だ。利用者の権限チェックが必要なアプリケーションの場合は、まずログイン画面があって、次に処理選択のメニュー画面があって、次に個々の処理のための入力画面がある、という具合に、利用者を順番に適切な画面へ案内していくということである。

次の「Service to Worker」は「Dispatcher View」と同じ考え方で質の違いはないが、程度の違いがある。「Service to Worker」は「Dispatcher View」に比べるとより複雑な処理をさせる。例えば「Dispatcher View」が、単にWebブラウザからわたされた文字列を、既存の対応表と照合して別のWebページのアドレスに変換し、自動的に飛ばすだけだとすると、「Service to Worker」はWebブラウザからわたされたさまざまな入力データを、いったん別のプログラムに渡して、そのプログラムで入力データどうしの関係などから次に飛ばすべきWebページを判定するといった複雑な処理まで行う。「Service to Worker」は「Dispatcher View」が複雑になったもので、本質的な役割は同じである。

次の「Business Delegate」は、利用者の目には直接触れないデータ処理プログラムなどが変更になるたびに、利用者の見た目を制御するプログラムも変更しなければいけないということを避けるための考え方だ。具体的には、利用者の見た目を制御するプログラムがデータ処理プログラムを呼び出したい場合、必ず仲介役になるプログラムを通して呼び出すようにする。利用者からの見た目を制御するプログラムが、データ処理プログラムを直接呼び出すのではなく、それを呼び出す仕事を仲介役となるプログラムに権限委譲する（delegateする）というわけだ。

次の「Service Locator」は、そのようにして仲介役となるプログラムが、適切なデータ処理プログラムを呼び出すときに、利用者からの要求に合致したデータ処理プログラムを素早く見つけ出せるようにしようという考え方だ。データ処理プログラムが部品化されていて、物理的に別のコンピュータ上で動いていたりする場合だってある。ネットワーク上に分散して動いているそれらのプログラムを呼び出すには、さまざまな規則にしたがった呼び出し方をする必要がある。そのあたりの面倒な呼び出し規則を扱う処理そのものを、一つの部品にして、この部品に任せましょうということだ。そのように呼び出したいサービス（service）を迅速に位置づける（locate）という考え方なので「Service Locator」という名前で呼ばれている。

次の「Session Facade」は、無事「Service Locator」を使って呼び出したいデータ処理の場所を特定できたとしても、そのデータ処理プログラムがとても複雑で膨大なものだとすると、その処理の中身の流れをあらかじめ知っておかなければ、適切なデータをわたせなくなるおそれがある。そこで、複雑で膨大な処理に、一つだけ「正面玄関」（facade）をつけて、呼び出すときは必ずその「正面玄関」から入ってもらうようにしましょうという考え方だ。呼び出す側のプログラムは、正面玄関を入った奥のほうの部屋で、どんな複雑なデータ処理がおこなわれているかは意識しなくてもよくなる。

次の「Transfer Object Assembler」は、データ処理プログラムそのものが、さまざまな部品からできているので、利用者からの要求が「正面玄関」から入ってきた後、その要求を満たすには、どの部品とどの部品を組み合わせた処理を実行すればいいのか、適切な部品どうしを組み立てる処理が必要になる。その処理が「Transfer Object Assembler」だ。処理部品を組み立てる処理そのものを一つの部品にしておけば、部品を組み立てる処理はその部品に任せてしまえる。文字どおり「Transfer Object」を組み立てる（assemble）ということである。

次の「Transfer Object」は、「Transfer Object Assembler」が組み立てる個々の部品を示しているわけだが、利用者からの要求にもとづいて呼び出された処理が、利用者に返すデータのことを言っている。ただし、必要なデータを呼び出しては一つ返し、呼び出しては一つ返しするのではあまりに効率が悪い。処理に必要なデータを一回渡して呼び出すだけで、結果のデータをできるだけ大きなまとまりで利用者に返したい。そのように結果のデータをひとまとまりにして乗せるための乗り物が「Transfer Object」で、文字どおりデータをまとめて運搬（transfer）するためのオブジェクトだ。これによって呼び出し回数をできるだけ少なくすることができる。

次の「Composite Entity」は純粋に処理の効率性を上げるためのものと考えていいだろう。利用者からの要求にもとづいて、適切なデータを「Transfer Object」に乗せて返すとき、データベースからデータを取ってきてさまざまな処理をするプログラム部品は、いつでも利用者からの要求に答えられるように、サーバ上に常駐して待ち構えている。これらのプログラム部品は保守性を良くするために、さらに小さな部品に分割されていて、それらがひとまとまりになって一連のデータをかえす処理を行っている。処理を呼び出すときには、小さな部品をいちいち呼び出すのは非効率なので、それらをまとめる親玉を作っておいた方がいい。それを「Composite Entity」と呼んでいる。「Composite Entity」を一回呼び出しさえすれば、その中で小さな部品の呼び出しは利用者から見れば勝手にやってくれる。

「Composite Entity」と「Transfer Object」がまぎらわしいと感じられるかもしれないが、「Composite Entity」はあくまでデータ処理で、その結果のデータを乗せて運ぶ乗り物が「Transfer Object」だと考えるとよい。

次の「Value List Handler」は、利用者からの要求で「Transfer Object」を使ってデータを返そうとするとき、返す結果のデータ件数が何件になるかは予想できない。もし結果の件数が膨大な場合、一度に利用者のWebブラウザへ返してしまうと、いつまでたっても結果表示ページが表示されないというとんでもないことになってしまう。そこで、処理結果を、少しずつ、順番に返す役割を果たすのが「Value List Handler」である。

残る２つのうちの「Data Access Object」は、さまざまなプログラム部品の中で唯一、直接データベースに接続する部品だ。他のすべてのプログラム部品には、直接データベースに接続させないようにして、必ずこの部品を仲介させるようにする。データベースと言っても、関係データベースとは限らない。ユーザ情報を管理するLDAPのようなものかもしれない。とにかく利用者からの要求に答えるのに必要なデータを保持しているデータベースに直接接続する部品のことである。

最後の１つが「Service Activator」だが、これは非同期で処理を呼び出すことを言っている。ここまでのいろいろなデザインパターンは、基本的に利用者からの呼び出しに対してその場で答えるという、同期的な処理について話していたが、非同期な処理でもかまわない場合がある。たとえば会員登録処理を実行した後に、「ようこそ○○さん！」というメールが届くという処理の場合、ようこそメールを送信する処理はその場でWeb画面上に表示する処理ではないので、非同期でかまわない。このような非同期の処理を呼び出すのが「Service Activator」の考え方である。

以上がJ2EEで中核のデザインパターンとされているもののすべてだ。何だ、どれも当たり前のことを言っているだけじゃないかと思ってしまうのだが、当たり前のことをちゃんと抽象化・定式化・文書化するというのが欧米式の形式知の世界。当たり前のことを文書化することで、世界中の誰にでも利用できる共有財産になる。自分の会社という閉じた世界の中だけで「あ・うん」の呼吸で仕事をしている日本人には、こういう発想はなかなか生まれない。