なにものかというと、いろいろな要素を集めあわせているもの。
その主要なものは、JDBC、Enterprise
JavaBeans、JNDI、Servlet、JSPによるエンタープライズアプリケーションの仕組みであるようだ。
なにか、といえば、フレームワーク、らしい。具体的にどんなものか、というと、設計手法的なところがおおきいのか、いまいちピンとこない。
システム自体に開発者が作ったプログラムを組み込んで、全体として1つのシステムとして動くものがフレームワーク、というもので、システムを呼び出すためにクラスやメソッドがあるように、利用する側もいくつかの決められたインターフェースに沿ったクラスを作ることで、システム側から利用者が作ったクラスを呼び出したりできるようになる。
J2EEの部分集合ともいえるServlet/JSPは、MVCのうちのViewとControlに相当する。Model にあたる部分がJavaBeansであり、Enterprise JavaBeans であるのだろうか。
J2EEの構成要素について、ちょっとだけ知っておくのがいいのかも
Java 2の2が消え、Java EE 5となり、正式リリースもされました。
各種ツール類がリリースされています。
Java EE 5 SDKには Java SE 5なども入っているので、わざわざJava EEを使うより、Application Server をダウンロードした方がいいです。各種ごちゃごちゃさせるより、もうすこしわかりやすくならんのでしょうか。
参考
J2EE 1.4仕様とJ2EEアプリケーションサーバ Developer版がリリースされました。ドキュメントとしては、J2EE仕様、J2EE1.4チュートリアルなどがあります。
リファレンス実装のJ2EE RIは、Java System Application Server 8に統合されています。
J2EE ディレクトリで勝手に仕様の翻訳などをしてみているところです。
とりあえず手持ちの本などで、読む順番はどんながいいかな・・・と。悩むところ。
おすすめかもしれない読む順番
sdc.sun.co.jp/java/j2ee/ にJ2EEチュートリアルやJ2EEアプリケーション設計ガイド
の pdf 版などがある。
J2EEチュートリアル
JMS、JNDI、JAXPなどのチュートリアルは英語版しかないようだが、後で見てみることにしよう。
ほかには、サンプルとしてこんなのがある。
Sunの入門はBruePrints という各種サンプルのようなものにそって各種エンタープライズアプリケーションの手法を知っていくという手法?
どれからみてみればいいのか?
Servlet / JSPについては知っているので、J2EEチュートリアルから見てみたが、失敗だったかな。先に[Enterprise
JavaBeans]を知っておいた方が効果的? チュートリアルを先に読んでわからないことだらけで設計ガイドを読んだらわかりやすかった。
J2EEといっても、その構成要素はいろいろあります。それらを統合して企業の基幹業務システムづくりができるセットがJ2EEですね。
基幹システムを知っている人には、従来の基幹システムと比較してみるのがわかりやすいのかもしれません。J2EEでは、4層システムという形になっています。
J2EEは、Webインターフェイス(JSP/Servlet/アプリケーション)などなどのクライアント層Web層と、エンタープライズBean(EJB)などなどのビジネス層、データベースのEIS層からなるなると。それぞれを、J2EEコンポーネントといふのだな。
| どんなの? | J2EE階層 | 3層 | 2層 | たとえば |
|---|---|---|---|---|
| アプリケーション/HTML | クライアント層 | ブラウザ | アプリケーション | Webブラウザ、アプリケーション、アプレット等 |
| JSP,Servlet,JavaBeans(オプション) | Web層 | CGI等 | Tomcat等(J2EE) | |
Enterprise JavaBeans(EJB) |
ビジネス層 | EJB環境(J2EE) | ||
| エンタープライズ情報システム | EIS層 | EIS層 | DBMS(データベース等) | |
各階層は、1つのサーバ/クライアントで動作させることもできますが、それぞれ個別の独立した環境です。また、各階層が1対1の関係ではなく、多対多で必要に応じて複数の組み合わせで構成することができます。Web層から複数サーバのビジネス層(EJB)を使ったり、ビジネス層間の連携、各層からEIS層(データベース)を使うなどです。
EIS層は、従来のシステム的なところも組み合わせられるようです。
こんな感じで、各社からJ2EEとしてリリースされているのは、Web層、ビジネス層を中心としたサーバソフトウェアです。EIS層も入ってたりしますね。クライアント層は、基本的にJ2SEの範疇かもしれません。EJBなどへアクセスするために一部クライアント層でもJ2EEが必要なのかも?
下のEIS層から順に見ていくとわかりやすいのかもしれません。EIS層は、データベースなどの従来のシステムです。その上に、ビジネス層として、様々な業務のロジックがあります。従来と違うのは、ビジネス層(EJB)が機能、役割ごとに分割されているので、それぞれが必要なビジネス層/EIS層と相互に連携できるということでしょうか。
クライアント層とビジネス層は、なぜ分かれているのでしょうか。サービスをビジネスロジックとしてビジネス層に実装し、1つの実装からServlet/JSPを使ったり、他のクライアント層を使って複数のクライアント環境(パソコン、携帯電話など)に同じサービスを提供できるようにするためです。WebだけならEJBを使わずに普通のクラスを使ってビジネス層を作るという選択肢もあります。
J2EE内で各層を結んでいるのは、JNDIという簡単な環境変数のようなものです。このJNDIを参照することで、相手がどこのサーバにあっても(EJBのみ?)、多少違うクラスや違うデータベースなどであってもインターフェース的に同一であれば呼び出すことができます。この対応は、配備(deploy)という最終段階で行われます。
J2EEではこのJNDIによる抽象化のおかげで、従来のシステムではEIS層からWeb層まで1つのセットなどの場合が多かった各層は、ビジネス層とEIS層をセットにして、Web層は複数のビジネス層を扱ったり、またビジネス層で他のビジネス層を利用/参照することも簡単にできるようになっています。
ビジネス層を使う場合はRMIを使うので、普通にクラスを呼び出すのとほとんど同じです。
JSPなどなどWeb層の機能はTomcatで実行できますが、EJBを実行するのはJ2EEの環境(EJBコンテナ)が必要となります。EJBはどのようなものなのか、見ていくことにしましょうか。作り始めるのはまだまだ先です。
[Enterprise Java Beans] へ続く?
参考
Servlet/JSPの実行環境としては Jakarta Tomcat が有名であるが、Sunも、無料の環境を提供しはじめたようである。
Sun ONE Application Server 7 Platform Editionを使ってみようか。開発環境も含めて無料で使いたいならJBossしかないです。
J2EEに対応したアプリケーションサーバ(EJBの利用できそうなもの)は、いろいろある。
Application Server とEJB開発まで対応する開発環境
開発はどの開発環境でもできるが、配備するためにパッケージングするとなると、各種事情が・・・というわけで、ほとんどのJ2EEアプリケーションサーバは開発ツールに依存する。どの開発ツールがどのアプリケーションサーバに対応するのか確認しておきましょう。Eclipseなら大抵のASに対応していたり?
機能比較?
| J2SE1.4 | Tomcat | J2EE1.3 | |
| Servlet | - | ○ | ○ |
| JSP | - | ○ | ○ |
| JavaMail | - | △ | ○ |
| Relm | - | ○ | ○ |
| JNDI | ○ | ||
| EJB | - | - | ○ |
| JMS | - | - | ○ |
| EAR | - | - | ○ |
| JAAS | ○ | ||
| JDBC | ○ |
フル機能のアプリケーションサーバは、Tomcatの機能のほかにEJBやJMSなどが使えるようになっています。Servletなどの部分はTomcatと組み合わせても使えると思います。たぶん。
J2EEは、Web層やクライアント層とビジネス層とを作るわけですが、それらが完成すると、配布用のファイルにまとめます。こんな感じ
DBMSなどです。JDBCも登場するかもしれませんが、EJBからはJDBCを意識する必要がない場合もあるとかないとか。
データベース以外の資源にアクセスするために「J2EEコネクタアーキテクチャ」が新しく用意されているようです。
ビジネスロジックを実装します。特に分散などではなければEJBである必要もないようです。EJBを使うにはJNDIなど面倒なこともありますからね。
主にセッションBeanに実装しましょう。エンティティBeanは、EIS層へのアクセスのために使う程度でいいのかな?
WebコンポーネントとかWebモジュールとか
warファイルとしてパッケージングして、いろんなサーバに配備します。
さて、とりあえずひととおりJ2EEについてわかったところで、 J2EEのクライアント環境についてみてみます。
クライアント層は、Webブラウザなどのほかに、アプレットやアプリケーションとして構築することもできます。
配布するのには、Java Web Startなんていうのを使っても便利かもしれません。クライアント層でもEJBなどを呼び出して使う場合はJ2EEのライブラリを用意しておきます。
J2EE RIでは実行の方法が複雑ですね。他の環境ではどうなっているのでしょうか。
開発をはじめる場合、どこから手をつけましょうか。EJB組んで、それにWeb的操作を加えていけばいいのかもしれません。
EJBなどの各要素がわかっても、それをどういう組み合わせにして使えばシステムが構築できるのでしょうか。
まずはServlet/JSPだけ、それにJavaBeansやJDBCなどを組み合わせながら作るということができます。Strutsなどもありますね。
EJBを使おうとしたときに、難関が待っています。ServletからはセッションBeanを使います。セッションBeanからエンティティBeanを使うのでしょうか、それともServletから直接エンティティBeanにもアクセスするのでしょうか。CMPエンティティBeanの場合はローカルインターフェースを持っているので、リモートインターフェースは持っていないことが多く、Servletなどからアクセスするためにはリモートインターフェースを用意する必要があります。セッションBeanにビジネスロジックを書きつつ、セッションBeanからエンティティBeanを使いましょうか。
Servlet -> Session EJB -> Entity EJB(CMP/BMP) -> EIS(DB)
↓
JSPで出力
という形になるのかな?
参考?
J2EEで重要なのが、各種配備記述子というものです。Tomcatを使っていれば、web.xmlのことかなとわかるかもしれません。これがEJBモジュール(ejb-jar)やJ2EEアプリケーション(ear)にもあります。基本的にはツールによって(半)自動生成されますが、なんのために自動生成しているのかは知っておきましょう。ここに書かれるのは、JNDIなどを使った他のコンポーネントとの関係などです。
配備記述子は、内側のものを外に公開したり、また外のものを参照するという目的で利用されます。最終的な関連は、アプリケーションサーバへの配備のときに行われますが、どの配備記述子どうしが関連しているのか、またJ2EEサーバ内のリソースとの関係はどうなっているのか、理解しておきませぅ。
ServletがどこのURLに配置されるとか、そんなこと
JNDIを使った外部のどの機能(EJBなど)を内部で参照しているかという情報です。外部の名前は、earの配備記述子で具体的な場所と対応づけられます。
外部のクラス名と、内部的なJNDI名の対応です。
各モジュールは、JNDI名を使って相互に参照することができます。JNDIに登録できるのは、EJB、JDBCのDataSource、JMSなどがあります。
JNDI名と参照名、この2つで参照関係を作るのですが、ややこしいようです。
参照名もJNDI名も、JNDIのjava:comp/env の下に作られるという点では同じなのですが…。参照名は、ソースコードとweb.xml の間で決められた名前、JNDI名は、アプリケーションサーバ側のリソース名で、web.xml
などでそれらを対応させます。
EJB間の関連はどうなっているのかというと、参照名とJNDI名の間にEJB名があり、EJB名でEJBを選択しています。
java:comp/env/ejb/TheServiceBean これが参照名(ソースコード中での記述)、配備記述子内では <ejb-ref-name>ejb/TheServiceBean</ejb-ref-name> の部分だけであらわします。JavaのコードではJNDIで参照するときに全部記述します。
new InitialContext().lookup("java:comp/env/ejb/TheServiceBean");
参照名は、ひとつのwarやejb-jarの中で定義(配備記述子)して使われ(ソースコード)る、ローカルの定義です。J2EEの仕様にあるものです。
参照名は、参照名を使用するServlet(war)やejb-jar内の配備記述子で、<ejb-name>と関連づけられます。このejb-nameが、EJBの配備記述子とクライアント(参照元)の配備記述子の間で一致することで、EJBを検索、利用することができます。ホームインターフェースの型なども、もちろん同じでなければなりません。
同じアーカイブ内から参照する場合は、参照元のEJBなどの中に<ejb-link>としてEJB名を関連づけます。(内部EJB参照)
ExampleEJB のような名前だけです。たぶん。
JNDI名 これはどこででてくるかというと、どこかな。EJBを作るときにEJBの配備記述子に<ejb-name> のようにして書かれているものではありません。このejb-nameと関連づけられて、EJBがJNDIに登録されています。その名前がJNDI名です。
<ejb-name>と実際のEJBのHomeインターフェースを結びつけるためのEJB配備のための名称です。これは、アプリケーションサーバ固有のものです。もしかしたら、これを使わない実装もあるかもしれません。
Sun ONE ApplicationServerの管理画面でEJB以外のリソースを登録するときも、こっちを記述します。
別のコンポーネントのEJBを参照(リモート参照)する場合などに必要となります。参照元のAS固有配備記述子で利用します。
EJB以外のJDBCなども、同様です。
こちらも ejb/～ のような名前でしょうか。
WEB-INF/web.xml
配備記述子内にはこの2つの情報があります。
サーバのどこのURLに対応させるかなどは含まれていません
META-INF/?.xml だったかな?
配備記述子内にはこの2つの情報があります。
さらに、AS固有配備記述子に、JNDI名があります。JNDI名は標準的なものではありません。
META-INF/application.xml かな?
各モジュールのJNDI名の対応など? はありません?
どんなEJBやWARがあるかという情報、WARの配備位置(URL)も指定できます。
どのモジュールでどこに配備されているどのモジュールのどのEJBやJDBCを参照するか、というような、情報は書かれていないようです。
EARの配備記述子かな?
EJB、WARなどを単体で配備する場合にはアプリケーションサーバごとに固有の配備記述子があるようです。
WAR内のクラス -> 参照名(ejb/～) ->WARの配備記述子 <ejb-ref-name> -> <ejb-name>EJBの配備記述子 -> JNDI名 -> EJBのHomeインターフェース
配備する(組み合わせる)ときに web.xml などの参照元配備記述子を参照先の配備記述子にあわせて編集する必要があります
EAR/WAR内のクラス -> (jdbc/参照名) -> 参照元のEJBのAS固有配備記述子 ? -> (JNDI名) -> サーバ内の設定 -> JDBCリソース?
ここの参照名とJNDI名は違うものかな。たぶん。
JSP等々 -> EARの配備記述子 -> ???? -> 認証情報 ではないような・・・
さて、これがわかるかな?
つづく
[JNDI]
Webなどからアクセスできるユーザを制限するには、ロールやレルムという仕組みを使います。
JAASなどが関係している?
個別のアカウントを判定するのが認証。どのリソースにアクセスするかを決めるのが承認です。
認証の実装は、アプリケーションサーバごとに異なります。ファイルを使った認証、LDAPを使った認証などは、基本的にはどのApplicationServerでも使えるようです。データベースを使った認証は、TomcatにもSun ONE Application Serverにもありますが、ちょっと違うのかな?
[セキュリティ]
EJBなどを複数サーバに分散させることができる。これはどうやって実現できるのか。
JNDIがローカルだけでなく、別サーバのJNDIリソースも参照できればよいのかな。Sun ONE Application ServerのPlatform Editionではできませんね。たぶん。WebとEJBが同一サーバ内で動作することになるのでしょうか。
Java Messaging Service(JMS)を利用すると、非同期的な分散も実現できるようです。
JDBCなどは、もともと通信するものなので、データベースとJ2EE的サーバは別にすることができます。
[Java]