前回のJava+CORBAプロジェクトは丸１年、それが終わった1999年後半。

「アプリケーションサーバ製品」が各メーカーからリリースされはじめてました。主流は、One to One や Cold Fusion などのＣ言語による「メーカー独自仕様」の製品でしたが、そんな中Javaは、アプリケーションの「標準仕様」の策定を進めてきました。企業システムのあるべき姿、作り方、運用方法にいたるまで、世界標準規格（のちのJ2EE）をつくろうとしていたのです。

そのころ、Java言語のバージョンは 1.1 でしたが、Java2/J2EEに先駆けて、EJB と Servlet を先行実装し、実績を作り始めるメーカーも出てきます。その中の最速・最大手が BEA WebLogic（4.x）でした。

私は幸運なことに、WebLogicを使った開発案件に恵まれ、SwingとEJBによるC/Sシステムの開発に着手しました。

基本的なアーキテクチャは、Java+CORBAと変わりません。ブラウザ上で動作するアプレットから分散オブジェクトをコールする、典型的な多層C/Sシステムでした。EJBが登場したおかげで、Java+CORBAと同じことを、Javaだけで実装することができるようになったのです。しかし、それだけでは、実行速度の遅いJavaをあえて使う必要はありません。

開発者の立場から見た場合、CORBAと比べて格段に違っていたことがありました。それは、

ということです（コンテナ管理トランザクション）。開発者はわざわざ「begin～commit～rollback」のコードを書く必要がなくなりました。他のこと（エンティティやらなんやら）なんてどーでもいいくらい、このインパクトは大きかったのです。

個別の業務ロジックの中で、トランザクション制御を記述すると、その業務ロジックは再利用できなくなります。一方で、分散オブジェクト技術を採用する理由は、「ランタイムの再利用」に尽きるわけですから、分散オブジェクトの中にトランザクション制御を書くということは、とても矛盾していることなんです。

CORBAプロジェクトでは、このあたりの問題を解決しようとして、めちゃくちゃになりました。DBコネクションハンドラを各ロジックの引数に渡したり、「トランザクションをbeginしてからコールしてください」などと注意書きをしたり・・・。分散オブジェクトのくせに、自己完結できない、ずいぶんと中途半端なモノが出来上がってしまったのです。

技術以外のところにも大きく影響があります。当時のシステム詳細設計書では、コネクションやトランザクションを一字一句、日本語で記述したりしていました。例えばこんな風に。

• 1.DBに接続する。
• 2.トランザクションを開始する。
• 3.入力された情報を元に、顧客テーブルから全カラムを取得する。
• 4.検索結果をチェックする。
• 4.1.一件の場合
• 4.1.1.給与カラムに1000を追加する。
• 4.1.2.トランザクションをcommitする。
• ：
• 7.DBを切断する。
• :

すべての業務ロジックをこんな調子で書いていましたから、プログラムのデバッグよりも設計書のレビューの方が大変でした。ここまで書かないと、トランザクションが正しく管理されているかどうかを、チェックできなかったのでしょう。

今ではこういう設計書は少なくなり、もっと端的にモデリングしていると思いますが、これも技術の進化に合わせてきた、重要な変化であると思います。「技術が文化を変えた」とも言えるかもしれません。

プロジェクトの途中で、EJBがバージョン1.0からバージョン1.1にアップグレードしました（EJB1.0の配置記述子は、今のようなXMLではなく、Lispみたいな括弧だらけの変なフォーマットだった記憶があります）。
WebLogicのマニュアルも日本語訳がでてきたし、「Java World」-- 当時のJava技術者にとって唯一の日本語情報源 -- にもEJBの記事が掲載されました。急速に盛り上がっていく雰囲気を感じていました。

そしてJSPも登場し、JSP・Servlet・EJBがそろって、Java2の時代・Javaと言えばサーバサイドの時代へ突進していくことになります。

一方で、Swingには「ちょっとリッチなアプレット」みたいな印象しか持てませんでした。あいかわらず、よりいっそう、重たいし。しかし、Swingを含む「JFC」は、いろいろなメディアに対するJavaの浸透を示唆するものだったように思います。