この記事を書いている今では、Javaはエンタープライズシステム構築の場面で、非常に大きな成功を収めていると思います。サーブレット/JSP、EJBといったサーバーサイド技術や、JDBC、JNIといったJ2EE技術、RMIによる分散オブジェクト技術。Javaで業務用アプリケーションを作った事のある人なら、一度は聞いたことのある名前だと思います。
エンタープライズシステム構築技術の中には、忌み嫌われるものもいくつかあります。それでも僕は、その原理や実装、実情を踏まえた上で良し悪しを決めたい。そのための知識を得るために本書を読みました。
特徴
本書は、Javaにおけるエンタープライズシステム構築技術(手っ取り早く言うとJ2EEです)について解説しています。幅広く深い知識を要求されるエンタープライズJavaを、一冊でこれだけの情報を得られるのは、非常に評価できると思います。ただ、エンタープライズJavaに知識のない人が、興味本位で読もうとすると焼けどします。少し知識のある人が読むことが、本書を一番理解できると思いました。
本書は、少し訳がわかりづらいです。その上、複雑な技術に関しての解説となっていますから、初心者には非常に厳しかったです。ある程度知識を蓄えた後で本書を読むことをおすすめします。技術的に濃い部分を中心に解説していますので、入門書としては失格ですが中級者以上の人には、是非読んでもらいたいと思いました。本書のよさがわかると思います。
本書の目次
- エンタープライズJavaによるシステム開発の基礎
- JDBCについて
- Javaサーブレットの展開
- JNIによるJavaと既存システムとの融合
- オブジェクトの直列化
- RMIについて
- Java IDL-JavaとCORBAの接続
- EJBについて
覚書き
JDBCのURL構文
URLとは、リソースが存在する実際の位置を表したものです。インターネットをやるときによく見る「アドレス」が主な例です。JDBCドライバを目的のデータベースと通信させるためにURLを指定します。このURLも、実は、インターネットのアドレスとまったく同じ表記になっています。
JDBC::://:/
例: jdbc:mysql://www.xlegend.dip.jp:7777/testdb
上記の例では、「jdbc:mysql」の部分がプロトコル、「www.xlegend.dip.jp:7777」の部分がホスト名とポート番号、「testdb」というのが実際のデータベース名になります。
このように、JDBC接続時に使われるURLも、インターネットのアドレス部分となんら変わらないことがわかると思います。
トランザクション隔離レベル
java.sql.Connectionクラスには、トランザクション隔離レベルが定義されています。
- TRANSACTION_NONE
- トランザクションはサポートされない
- TRANSACTION_READ_COMMITTED
- 不確定な読み込み(dirty read)を阻止。繰り返し不能な読み込み(nonrepeatable read)、架空読み込み(phantom read)は可能。
- TRANSACTION_READ_UNCOMMITTED
- 不確定な読み込み(dirty read)、繰り返し不能な読み込み(nonrepeatable read)、架空読み込み(phantom read)のどれも可能。
- TRANSACTION_REPEATABLE_READ
- 不確定な読み込み(dirty read)、繰り返し不能な読み込み(nonrepeatable read)を阻止。架空読み込み(phantom read)は可能。
- TRANSACTION_SERIALIZABLE
- 不確定な読み込み(dirty read)、繰り返し不能な読み込み(nonrepeatable read)、架空読み込み(phantom read)のどれも阻止。
- 不確定な読み込み(Dirty read)
- 読んだデータが後で無効にされる
- 繰り返し不能な読み込み(Nonrepeatable read)
- 同じデータを2回読むと値が違う
- 架空読み込み(Phantom read)
- 存在しなかったはずのデータが後から現れる
トランザクションの隔離レベルを変更するのは、トランザクションを開始する前にするべきです。トランザクション実行中に隔離レベルを変更すると、その時点でトランザクションがコミットされてしまいます。
RMI
オブジェクトを直列化(Serialize)してネットワーク通信を行う場合、バイトコードは単純なテキストとして送られます。金融系など、セキュアな環境で利用を想定している場合、バイトコードを暗号化するという処理が必要になります。
もうひとつの方法は、そもそも重要なデータをネットワーク通信で送らないという方法があります。「transient」というキーワードを付けることで、そのフィールドは直列化されません。
オブジェクトバージョンの管理
直列化されたオブジェクトには、固有の識別番号SUIDが振られます。SUIDは、クラス定義によって流動的に変わってしまいます。これでは、一度リリースした後に修正をするとバージョンが変わってしまって、直列化したデータを元に戻すことができなくなります。
そこで、クラス自体にバージョン番号を持たせるという方法がとれます。JDKで提供される「serialver」というツールを使って、SUIDを生成できます。これをstatic final long serialVersionUID= 387249290804798024L というように埋め込むことで、常に同じSUIDを使うことができるようになります。
参考
- J2EEに関する技術の紹介は、こちらでもしています。
- さらなる知識のたくわえに
- 読みやすいです。