いまさら聞けないサーバーサイドJava 第1回 これだけは知っておきたいJ2EEの基本

Webアプリケーションの開発には，さまざまな技術が用いられています。Perl，Ruby，PHP（Hypertext Preprocessor）といった優れたWeb対応のスクリプト言語も増えていますし，Visual Basic（VB）技術者がWebアプリケーション開発にシフトしやすいASP（注1）も根強い人気を持っています。

しかし，企業向け，大規模開発，信頼性，高い開発生産性といったキーワードをすべて満たす技術と言えば，サーバーサイドJava，すなわちJ2EE（Java2 Platform，Enterprise Edition）が現状では主流でしょう。そこで今月から，サーバーサイドJavaのアプリケーション開発について解説していきたいと思います。「Javaプログラミングは少しはわかるけれど，サーバーサイドJavaはさっぱり」という方にはぴったりの内容です。よろしくお付き合いのほどをお願いします。

さまざまな API で構成するのが J2EE

最初に「J2EEとはいったい何なのか」を明らかにしておきましょう。J2EEは，米Sun Microsystemsが策定したJavaによる企業システム構築のための仕様です。現在のバージョンは2002年1月にリリースされた1.3.1（注2）。皆さんがアプレットやスタンドアロンのJavaアプリケーションを開発するときに使うJ2SE（Java2 Platform, Standard Edition）を，企業規模のシステムに対応するよう拡張した仕様という位置付けになります（図1）（注3）。

図01

J2EEでは，ほとんど耳にタコができるほど聞かされてきたJavaの理念「Write once, Run anywhere（一度書けば，どこでも動く）」が生きています。J2SEにおいて「Anywhere」はOSやハードウエアを指すものでしたが，J2EEでは企業システム構築に必要なさまざまなミドルウエア（データベースなど）を指します。これらのミドルウエアを抽象化し，環境が異なっても統一したAPIを利用できるようにすること。それがJ2EEの役割なのです。そのためJ2EEには表1のようなさまざまなAPIが含まれています。

表1 J2EE1.3に含まれるAPIとその用途

主なものから順番に説明しましょう。

JDBC 2.0オプション・パッケージは，データベースとJavaプログラムを接続するAPIです（注4）。J2SEに含まれているJDBCコアAPIでは，データベース・ドライバ，データベースのメタ情報（注5），接続，SQL（注6）文，処理結果，SQL型のJavaオブジェクト・マッピングが提供されていますが，大規模システムでは力不足です。そこでオプション・パッケージとして，大量のクライアントに効率よくデータベース接続するための機能などが追加されているわけです。

EJB（Enterprise JavaBeans）は，ビジネス・ロジックのコンポーネント化を目的とした仕様です。トランザクション制御をサポートし，ビジネス・ロジックそのものを実装するオブジェクトとなるため，多層構造アプリケーションの中心となります。J2EEの中でも特に複雑な仕様と言っていいでしょう。EJBは，J2EEの他のAPIを利用する上位レイヤーの仕様なので，J2EEを理解することはEJBを理解することといっても過言ではないかもしれません。

サーブレット（Servlet）とJSP（JavaServer Pages）は，Perl/C/PHPなどを使ったCGIプログラム（注7）の代替となるように策定されたWebアプリケーション構築用のAPI群です。HTTPによるリクエストに対して（一般的に）HTMLを返す，ユーザー・インタフェースに一番近い層をつかさどります。サーブレットの実体はJava言語で記述される通常のクラスで，リクエストがあるたびにサーバーで起動します。一方JSPは，HTMLにJava言語を埋め込んだような独自の書式を採用したファイルです。そのため「HTMLはわかるけれどJavaプログラミングはちょっと...」といったWebデザイナでも理解しやすく，見た目だけを意識して書くことができるようになっています。実を言うとJSPは，実行前に自動的にサーブレットに変換されて動作するので，JSPとサーブレットは兄弟みたいなものと思えばいいでしょう。

JMS（Java Message Service）は，メッセージングを実現するためのAPIです。もちろんメッセージングといっても人間同士が音声やメモでやりとりするものではなく，システム同士がメッセージを送り合って連携することを指しています。JMSの特徴は，呼び出し側からは非同期に実行されることと信頼性が向上することです。信頼性とは，メッセージの紛失が発生しない，発行と到着の順序を保証するなどです。

JTA（Java Transaction API）は，分散トランザクション（注8）を管理するトランザクション・マネジャを利用するためのインタフェースです。複数の企業システムを連携させつつWebから利用する場合などに，このAPIは重要になります。

JavaMailは，Javaからメールの送受信，処理を行うためのインタフェースです。添付ファイルや日本語対応をはじめとした国際化にも対応しています。

JAF（JavaBeans Activation Framework）は，JavaBeans（注9）仕様の拡張として，さまざまにエンコードされた各種データ型を，対応するJavaBeansへマッピングして処理を自動化するフレームワークです。例えば前述のJavaMailは，JAFを利用してメールのボディ部分を処理し，MIMEタイプ（注10）に対応したJavaオブジェクトを生成しています。JAXP（Java API for XML Processing）は，JavaからXML（注11）を処理するためのAPIの一つです。DOM（注12）のレベル1とSAX（注13）1.0を利用できます。

最後のJAAS（Java Authentication and Authorization Service）は，Javaアプリケーションにおける認証と承認のフレームワークになります。アクセスしているユーザーを個別に見分けて本人であると認める「認証」，認証されたユーザーに許されている処理・サービスだけを提供する「承認」は，アプリケーションを安全なものにするための基盤となります。

以上，J2EE仕様に含まれるAPIをざっと概観してみましたがいかがでしたか？

おそらくその膨大さに驚いている方もいらっしゃるかと思います。でも，心配はいりません。この連載を通じて一つずつ理解を深めていきましょう。

J2EEアプリケーションは4階層で考えよう

表1に挙げたJ2EEのAPIは製品ではありません。あくまで「仕様」の話です。仕様というからには実装があるわけで，これが各ベンダーが出荷している「J2EEサーバー」になります。したがってJ2EEアプリケーションといった場合，J2EEサーバー上に構築するアプリケーションのことを意味します。

J2EEアプリケーションの全体構成を見てみましょう（図2）。

さまざまなコンポーネントがありますが，このうち開発者が記述しなくてはならないのは青色の長方形で表したコンポーネント（HTML，アプレット，サーブレットなど）になります。全体のボリュームから見ると，小さい範囲に絞られているのがわかりますね。システム全体は，細かく見るとクライアント層，Web層，ビジネス層，EIS（Enterprise Information Service）層の四つに分かれます。図2の一番左側に位置するのがユーザー・インタフェースとなるクライアント層です。多くはWebアプリケーションとして，Webブラウザを利用したHTMLあるいはアプレットがクライアントとなります。もちろん，独立して動作するクライアント・アプリケーションであることもあります。

次に位置するのがJ2EEサーバーです。J2EEサーバー内部は，Webコンテナ（Web層）とEJBコンテナ（ビジネス層）という二つのコンテナに大きく分かれます。コンテナというのは，コンポーネントの入れ物と考えてください。Web層には，前述のサーブレットやJSPのプログラムが含まれます。また，Web層というからにはWebサーバー（HTTPサーバー）機能が必要ですが，後述するJ2EE SDKは，WebコンテナとしてWebサーバーのTomcatを装備しています。しかし開発でTomcatを使ったとしても，運用時にTomcatを使うことはありません。一般的には，セキュリティやパフォーマンス面で優れているApacheまたはApacheをベースにした商用Webサーバーを使うことがほとんどです。この場合，Webブラウザからの要求はApacheが受けて，ApacheとJ2EEサーバーが通信し合うことになります。

ビジネス層では，ビジネス・ロジックを実現するコンポーネントを，SessionBean，EntityBean，MessageDrivenBeanの三つのEJBとして配置します（EJBについては連載の後半で解説します）。ビジネス・ロジックとは何かという定義は難しいですね。

ここでは「口座Aから引き落として口座Bに入金する」「サイト利用者に対して課金を行う」「会員数推移のサマリーを管理者に通知する」など，アプリケーションの中心となるロジックのことと考えておいてください。

最後に現れるのがEIS層です。これはJ2EEアプリケーションというより，既存の外部システムやデータベースが該当します。ここをなぜJ2EEアプリケーションと分けて考える必要があるかというと，J2EEアプリケーションとはライフサイクルが異なるからです。例えば，流通業の会社が新規に構築するEC（電子商取引）サイトであれば，既存の物流や決済のための社内システムと連携することが必要となります。また，企業においてデータベースは生命線です。ビジネスが変わればアプリケーションも再構築されますが，いったん蓄積したデータを捨て去ることは普通ありません。そこで，データベースを含めたこれらのシステムやサービスを，EIS層として明示的に切り分けて考えることが必要なわけです。

このようにJ2EE仕様は，多層構造のアーキテクチャ（注14）を前提としています。そのためアプリケーションを開発する場合も，常にこの構造を意識する必要があります。そこでこの多層構造アーキテクチャについて，もう少し深く見てみることにしましょう。

J2EEアプリケーションを配布（deploy）する方法

企業システムを考えてみると，出入金を扱うEJBや在庫管理EJB，人事関連EJBなど，取り扱う情報の種類に応じて多くの種類のEJBが必要になります。これらEJBは部品ですから，複数のWebアプリケーションで利用します。例えば人事EJBであれば，一般社員向けの勤怠入力Webアプリケーションや人事管理Webアプリケーション，管理職向けの人事考課Webアプリケーションなどで利用されるでしょう。

これらのEJBやWebアプリケーションを，一度に全部を作ることはあまりありません。初年度は人事EJBと人事部向けWebアプリケーション，次年度は同じ人事EJBを利用する一般社員向け勤怠入力Webアプリケーションといった具合に，リリースのタイミングをずらしていきます。

そのためにJ2EEが提供している仕組みが，EJB jarとwar（Web Application Archive）です。EJBとWebアプリケーションを一かたまりのファイルとして取り扱えます。中心となるEJBとEJBが利用するクラスをまとめたものがEJB jar，サーブレット，JSP，それらが利用するクラス群，さらに普通のHTMLファイルや画像ファイル（gif，jpegなど）まで含めたものがwarになります。J2EEサーバーに対しては，これらの単位でアプリケーションをdeploy（配布/配備）していくことができます。

J2EEアプリケーションの開発は，EJBをjarとしてコンポーネント化することと，Webコンポーネントをwarとして作成することとを分けて考えておくべきです。そうすることで，ソフトウエア再利用性の向上が図れます。また，そうした心がけがよりよい設計を生むきっかけにもなります。

ちなみにJ2EEは，企業システム全体を一つのファイルにまとめてしまう仕組みear（Enterprise Application Archive）も持っています。複数のEJB jarとwarをまとめてしまうわけです。J2EEアプリケーションのインストーラのようなものと覚えておけばいいでしょう。

これらの「オマケ機能」は便利な半面，ただでさえ複雑なJ2EEをさらに難しく見せている原因でもあります。とりあえずは「なるほどね，そういう仕組みがあるんだ～」とだけ理解しておいてください。

常に多層構造とMVCを意識するのがポイント

J2EEが多層構造のアーキテクチャを採用している理由の一つは，開発生産性を向上させるためです。

例えばクライアント層は見た目や使い勝手にかかわる部分なので，エンドユーザーの要望によって変更されたり，Webデザイナなど開発者とは異なる人によって設計されたりします。そのたびにビジネス・ロジックを記述したソースコードに手を入れるのは難儀ですね。それならば，ここを層として切り分けたほうがデザイナと開発者の間で仕事の切り分けが可能になり，生産性向上が期待できます。また，そのためにはJ2EEサーバー内部においても，クライアントに近い部分であるWeb層と，ビジネス・ロジックを記述するビジネス層に分けたほうが，メンテナンスの面からも都合がよいでしょう。そのため多層構造化が必要だったわけです。

多層構造のメリットはそれだけではありません。各層はネットワーク通信を行うので1台のマシンでJ2EEサーバーを動かす必要はなく，多層構造に分かれていると，各層を複数のノード（マシン）に分散しやすくなります。つまり大量アクセスがあった場合の負荷分散や，セキュリティといった面でメリットを享受できるのです。

このようにJ2EEが多層構造を採用したのには，深い意味があります。開発者は，これらのメリットを最大限に利用する方向でJ2EEを使うべきでしょう。ポイントは「ビジネス上の重要な機能はEJBに集中させ，JSP，サーブレット，アプレットなどには組み込まない」ということに尽きます。

ところでユーザー・インタフェースとロジックを分ける，とくれば，MVCというアーキテクチャをご存知だと思います。MVCはもともとSmalltalkにおいて多用されていたものですが，GUIアプリケーションの開発を効率よく行うものとして知名度を上げてきています。

MVCでは，アプリケーションの構成要素をM（Model），V（View），C（Controller）の3種類に分類します。Modelはアプリケーション・データとその扱いに責務を持ち，Viewはアプリケーション・データの表示と操作のためのインタフェースです。ControllerはViewに対するユーザーの操作やModelの変化を相互に通知する仕組みを持ちます。と言ってもわかりにくいと思うので，具体的な例を見てみましょう。図3は，株価情報を参照して株の売り買い注文を行うアプリケーションの例を表しています。

Modelは，株価情報が更新されるとControllerに対して情報の更新を通知します(1)。Viewは前もってControllerに「この株価が変わったら教えてね」と登録してあるので，株価が変わったタイミングでユーザーにそれを提示します(2)。ユーザーが売り買いの注文をViewに対して行うと，ViewはControllerにアクセスして(3)，ControllerがModelにその注 文を依頼します(4)。

このように責務を切り分けるメリットは二つあります。一つはアプリケーションの見通しがよくなること。もう一つは，アプリケーションを利用するユーザーが増えてもViewの数が増えるだけで，一番複雑で重要なModelには影響がない，ということです。

ところが，Webアプリケーションの場合は厳密にはちょっと違います。というのもクライアント側でアプレットやプラグインなどを使わない限り，Webサーバー側からWebブラウザに対して更新を通知する方法がないからです。Web環境では，常にクライアント（Webブラウザ）からサーバー（Webサーバー）に対してリクエストを送り，サーバーがそれに応えるだけです。そのため，MVCの「ModelからViewへ変更を通知する」機能は実現できません。

そこで，現在多くのJ2EEアプリケーションで用いられているのが，MVCモデル2（筆者は「一方通行のMVC」と呼んでいます）の設計です。JSPをViewに置き，サーブレットをController，EJB/JavaBeansをModelとするのです。MVCとしては簡略化されたものになってしまっていますが，J2EEの構成と親和性が高いために，特に大規模なアプリケーションになるほど好んで採用されています（図4）。

図04

もちろん，小規模のアプリケーションであれば，JSPのみ，サーブレットのみで書くこともあります。MVCを採用すればそれだけクラス数が増えるので，そこは全体のバランスを見ながら決定していけばよいでしょう。

本連載では，J2EE上でのアプリケーション開発をできるだけ実践的に，段階を追って解説していきます。当初はサーブレットのみのサンプル・アプリケーションを紹介し，ついでそれをJSP化，JDBCによるデータベース・アクセス，EJBの導入と進んでいく予定です。連載が進んでいく中で，当初は単純なサンプルが，最後には大規模サイトにも適用できるアーキテクチャに進化していけるように考えています。それに伴って，皆さんが大規模サイトの開発に参加できる技術と知識を身に付けていただければうれしく思います。

J2EEサーバーが起動しない？

インストールしたのにJ2EEがきちんと起動しない場合，J2EE SDKの利用するポートが他のアプリケーションによってすでに利用されていることが考えられます。J2EE SDKは，デフォルトで1050番（ORB），7000番（HTTPS），8000番（HTTP），9191番（EJB）のポートを利用します。コマンド・プロンプトでnetstat -a -p TCPとし，これらのポートが利用されているかどうかを確認してみてください。右端の列に「LISTENING」と表示されている場合は他のアプリケーションが利用しているので，ポート番号を変えて起動する必要があります。

ポート番号は，C:j2sdkee1.3.1configの下の.properties ファイルに設定されています。ORBの利用するポート番号はorb.properties，EJBの利用するポート番号はejb.properties，HTTP/HTTPSの利用するポート番号はweb.propertiesに記述されています。該当する部分を編集してj2ee.batを再起動してみてください。

J2EEサーバーをインストールしよう！

さて，堅苦しい話が続いてしまいました。ようやくここから実際のJ2EE環境を構築し，サンプル・プログラムを作っていきましょう。「プログラムが出てこないぞ！」とご不満だった方，お待たせしました！

「え？でもJ2EEサーバーなんて持ってないよ」----おっと，確かに多くの皆さんはそうかもしれませんね。じゃあ，この際ですから購入すべきでしょうか。確かに本格的な業務アプリケーションを構築しようとするなら，サポートなどの充実した商用のJ2EEサーバーを選択することが一般的です。しかしそれらの製品は，おおむね数百万円～という価格帯がつけられているので，とても個人で手が出せる代物ではありません（注15）。

ということで本連載では，個人でもJ2EEを楽しめるように無償のものを使うことにしました。教材は，SunがJ2EE仕様とともに提供している参照実装（Reference Implementation）（注16）である「J2EE SDK（Software Development Kit）」です。J2EE SDKには，データベース管理システムのCloudscapeもバンドルされているので，単体でデータベース・アプリケーションを作成することも可能です。さっそく，Sunのサイト（ http://java.sun.com/j2ee/ja/ ）からダウンロードしましょう（図5）。

J2EE SDKが動く環境はWindows 2000，Solaris 8，Red hat Linux 6.2J。本連載ではWindows 2000 Professionalをベースに解説していくので，Windows版（j2sdkee-1_3_1-win.exe，約16.5MB）をダウンロードしてください。J2EE SDKに付属するツールはベンダー製品とはやや異なっていますが，なんと言ってもJ2EEは「Write once, Run anywhere」ですから，記述したアプリケーション自体にほとんど手を入れなくても他のJ2EEサーバーで稼働させることが可能です。ちなみに，同じサイトにある日本語版追補（j2sdkee-1_3_1-win-ja.exe，約1.12 MB）を追加インストールすることで，部分的に日本語化できます。こちらもダウンロードしておきましょう。

J2EEを動かすにはJ2SEも必要です。SunのサイトからJ2SE 1.4のWindows版（j2sdk-1_4_0_01-windows-i586.exe，各国語版で約35MB）をダウンロードするか，J2SE 1.4を収録した本誌2002年7月号の付録CD-ROMを使って先にインストールしておいてください。J2SEに日本語追補はありません。ファイルをダブルクリックし，ウィザードを起動するだけでインストールできます。インストール先はデフォルトのC:j2sdk1.4.0_01とします。

では，J2EE SDKと日本語追補を順番にインストールします。こちらもファイルをダブルクリックしてインストーラを実行するだけです。本連載では，J2EE SDKがデフォルトのC:j2sdkee1.3.1にインストールされたものとします（図6）。

すると日本語版追補のインストールでは，自動的にそのディレクトリを検出してくれます。

次は設定です。J2EE SDKを起動するには，J2EE_HOME，JAVA_HOMEの二つの環境変数の設定が必要です。J2EE_HOMEはJ2EE SDKのインストール先ディレクトリ（C:j2sdkee1.3.1）を，JAVA_HOMEはJ2SE 1.4をインストールしたディレクトリ（C:j2sdk1.4.0_01）を設定します。システムあるいはユーザーの環境変数として設定するのがよいでしょう。Windows 2000であれば，[コントロール・パネル]-[システム]で「詳細」タブを選択し，「環境変数」ボタンをクリックして表示されるダイアログで設定します（図7）（注17）。

ここまで済みましたら，C:j2sdkee1.3.1binj2ee.batのファイルをダブルクリックして，J2EEサーバーを起動してみましょう。コマンド・プロンプトのウィンドウが開き，図8のようなメッセージが表示されるはずです。さあここで，Webブラウザを使って http://localhost:8000/index.html にアクセスしてみてください。図9のようになれば，J2EEサーバーの起動成功です！ うまくいったら，コマンド・プロンプトを開き，C:j2sdkee1.3.1binj2ee.bat -stop を実行して，いったんJ2EEサーバーを停止しましょう。

J2EEはいかにしてWebサービスに対応するか

ここ2年くらいのIT関連の大きなトピックと言えば，多くの人が「Webサービス」を挙げることでしょう。Webサービスについては多くの定義がありますが，XMLをインタフェースに利用する，分散アプリケーション・サービスというのが最大公約数でしょうか。

Webサービスの技術的なキーワードには，UDDI（Universal Description, Discovery, and Integration），WSDL（Web Services Description Language），SOAP（Simple Object Access Protocol）があります。UDDIは，Webサービスを登録/参照できる電話帳のようなものです。「うちの会社では株価情報サービスを提供していますよ，提供形態はこれこれですよ」と登録しておいて，サービスの利用者に探して使ってもらうのです。UDDIで提供するサービスのインタフェース定義情報は，XML（Extensible Markup Language）を基にしたWSDLで記述します。「このサービスはどのURLにありますよ，パラメータはこれこれ，戻り値の型はこれこれですよ」といったことを定義するわけです。

SOAPは，UDDIへのアクセスや，Webサービスそのものへのアクセスに用いられるプロトコルです。現時点では主にHTTP上で動作することを想定しており，ファイアウォールを越えて通信することができます。

このようなWebサービスにJ2EEが対応するために，Sunが提供しているのがJava Web Services Developer Pack（Java WSDP）です。Java WSDPには，XMLを扱うための最も基本的なAPIであるJAXPのほかに，JAXM（Java API for XML Messaging），JAXR（Java API for XML Registries），JAX-RPC（Java API for XML-based RPC），SAAJ（SOAP with Attachments API for Java）といったAPI群が含まれています。JAXMは，SOAPを利用したXML文書のやりとり（Messaging）をサポートします。JAXRはJ2EEからUDDIなどのレジストリにアクセスするためのものです。JAX-RPCはXMLを入出力に利用したRPC（Remote Procedure Call）を行うもので，Webサービスの利用そのものをサポートしています。SAAJはSOAPメッセージを作成・操作するためのAPIです。

このように技術的な情報では賑わっているWebサービスですが，本当にビジネスとして成功するかについては結論が出ていません。ユーザー主導ではなくベンダー主導で無理やりに需要を作ろうとしているという指摘もあります。それでも，大きなトピックであることに間違いはありませんから，先行して調査・学習しておくのも悪くないかもしれないですね。

サーブレットとJSPをちょっと動かす

J2EEサーバーが起動できたので，サーブレットとJSPのプログラミングにさっそく挑戦してみます。

まず，作業用のディレクトリ（フォルダ）を作成してください。その下にソースコード（拡張子java）用ディレクトリsrc，クラス・ファイル（拡張子class）用ディレクトリclasses，JSPファイル用（拡張子jsp）ディレクトリpublic_htmlをそれぞれ作成します。開発作業はこのディレクトリで行い，コンパイルしたものを順次J2EE SDKのディレクトリに配置していくわけです。ここでは作業ディレクトリとしてC:workを作り，C:worksrc，C:workclasses，C:workpublic_htmlとしたとしましょう。また，今回のサンプルはexamplesパッケージとして扱うため，C:worksrcexamplesディレクトリも作成しておきます。

なお，C:workディレクトリでJavaのプログラムをコンパイルするには，CLASSPATH（クラスやパッケージのファイルを探すための環境変数）などの設定も必要です。テキスト・エディタで次のコードのバッチ・ファイル（ファイル名はC:worksetenv.batなど）を作成し，コマンド・プロンプト（C:work上）で実行しておきます。

set path=c:j2sdk1.4.0_01bin;%path%
set CLASSPATH=C:j2sdkee1.3.1libj2ee.jar

ではリスト1のコードを入力したファイルを作成し, C:worksrcexamplesExampleServlet.javaとして保存してください。

リスト1 サーブレットのコード (ExampleServlet.java)

package examples;
　　　　　　　　  
import java.io.*;
import javax.servlet.*;
import javax.servlet.http.*;

public class ExampleServlet extends HttpServlet {
　　public void doGet (HttpServletRequest req, HttpServletResponse res)
　　　　throws ServletException, IOException {
　　res.setContentType("text/html; charset=Shift_JIS");
　　PrintWriter out = res.getWriter();
　　out.println(
　　"<html>" +
　　　　"<head><title>Example Servlet</title></head>" +
　　　　　　"<body>" +
　　　　　　　　"<h1>Hello, world!</h1>" +
　　　　　　　　"<p>はじめてのサーブレットです。</p>" +
　　　　　　"</body>" +
　　　　"</html>"
　　　　);
　　}
}

サーブレットのコードの意味については次回以降で詳しく説明しますので，ここは呪文だと思ってそのまま入力します。このプログラムを図10のようにコンパイルしてみると，C:workclassesexamplesExampleServlet.classというファイルが生成されているはずです。これを作業ディレクトリのclassesディレクトリごと，C:j2sdkee1.3.1public_htmlWEB-INF以下にコピーしてください（図11）（注18）。

図10

コピーできたら，j2ee.batでJ2EEサーバーを起動し，Webブラウザから http://localhost:8000/servlet/examples.ExampleServlet にアクセスしてみましょう。図12の画面が表示されれば，おめでとうございます！

成功です。うまく表示されない場合は，C:j2sdkee1.3.1logs以下に各種のログが出力されているはずですので，そちらを確認して対処します。 成功した方はこの勢いで，続いてJSPも試してみましょう。テキスト・エディタでリスト2のコードを入力し，example.jspというファイル名で保存します。

リスト2 jsp のサンプル・コード(example.jsp)

<%@ page ContentType="text/html;charset=Shift_JIS" language="java" %>
<html>
<head>
　　<title>Example Servlet</title></head>
　　<meta http-equiv="Pragma" content="no-cache"/>
　　<meta http-equiv="Cache-Control" content="private"/>
</head>
<body>
　　<h1>Hello, world!</h1>
　　<p>はじめてのJSPです。</p>
</body>
</html>

続いて，このファイルをC:j2sdkee1.3.1public_htmlにコピーして，Webブラウザで http://localhost:8000/example.jsp にアクセスします。これで図13のようになったら，こちらも成功です！

さて実装編はちょっと駆け足でしたが，いかがでしたか？

今回は，J2EEの全体像を大まかにつかんでいただくために，概念的な話が多くなってしまいました。今後はサーブレット/JSP，JDBC，EJBを実際に作ってみながら，J2EE環境でのテストやフレームワークの作成・利用にまで踏み込んで実践的に進めていこうと思います。「コードが出てこないと退屈」という方もいらっしゃるでしょうが（筆者もそうですのでよくわかります），今回説明した概要は，この先実際にコードを書いていて悩んだとき，困ったときの指針になります。ぜひ頭の片隅に置いておいてください。それでは，また来月お目にかかりましょう。