JavaをSEとEEに分類するのは今では無意味になってきている？
ご存知のとおり、かなり以前からJavaプラットフォームはJava SEとJava EEとに分かれています。Java EEはJava SEを含んだ拡張APIを含み、エンタープライズ開発向けのプラットフォームということで一般的にはなんとなく理解されていますが、よくよく調べてみると両者の境界線はかなりあいまいで、人によってさまざまな解釈の違いや混乱があるようです。
一応、Java SEとJava EEのJava DOCを調べてみると主なものとして以下のようなAPIが含まれていることがわかります。
| プラットフォーム | API |
|---|---|
| Java SE | 基本言語ライブラリー、通信ライブラリー、 GUI関連ライブラリー、JDBC、JNDI、RMI、Java IDL（CORBA）、JMX |
| Java EE | サーブレット、JSP、JSF、EJB、JPA、JMS、JTA、JCA Webサービス関連ライブラリー、Java Mail、DIコンテナ関連 |
この一覧を眺めてみて、自分自身も今までずっと勘違いしていたものもあるのに気づいたのですが、結構意外なものがそれぞれのカテゴリーに分類されているのですよね。
パッケージで言えば、java.lang、java.util、java.io、GUIライブラリーあたりまでは確実にJava SEというイメージで問題ないのですが、通信系が絡んでくるとちょっと微妙な感じとなり、特にサーバー側でミドルウェアの存在が前提となるJDBC、JNDI、CORBAなどに至っては、これがどうしてEEでなくてSEに含まれているのという不思議な気もしてしまいます。一方、逆に、サーブレットやJSPを使ったアプリケーションは高価なミドルウェアがなくてもTomcatなどの環境で動作するため、純粋なTomcat上のアプリケーションをJava EEのアプリケーションとは思っていない人も大勢いるのではないかと思いますが、少なくともAPIが属しているカテゴリーからはこれらはJava EEに属する技術を使っているということになるのです。
このように分類がわかりにくくなっている背景を理解するには、Javaの歴史を考える必要があると思います。まず、Java2と呼ばれたJDK1.2がリリースされる以前は、Java SEとJava EEという分割はなく、JDBCなどのAPIが個別に定義されて配布されていたということがあります。歴史的にはJDBCがJDKに取り込まれた後にJava EEという概念が出てきたため、上位互換性から機能を削減するということはできずに、JDBCをJava SEに分類せざるを得ないという事情があったのでしょうか。また、その分類の整合性を保つため、JNDIやJava IDLなど統合用のAPIも一緒にJava SEに含めるという方針になったのだと思われます。実際、Java SEの中でもっともエンタープライズ色の強いこれらのAPIは統合ライブラリーとしてカテゴリー分けされていますので、そういう意味では一応理解できなくはありません。でも、WebサービスとJMSはEEなのですけれどね。
Oracle Technology Network for Java Developers | Oracle Technology Network | Oracle
そして、もともとJava EEの前身であるJ2EEはアプリケーションサーバーなどのベンダーが中心となって策定されたという事実も重要です。当時はOSSのアプリケーションサーバーというものはほとんど知られておらず、これらは高価な有償の製品を利用するというのが前提でした。それゆえ、サーブレットなども含めて、サーバーサイドで何らかのミドルウェアを利用するためのAPIとしては当然お金の出せるエンタープライズが対象ということになったのでしょうか？今と10年前とでは全く状況が異なってしまっています。DIコンテナは実質的にすべてOSSですし、アプリケーションサーバーもOSSが中心で商用のサーバーは勢いがありません。現在では、OSSはJMSやESBなどの領域にまで進出してきています。さらに言えば、JSF2やCDIなどはSeamの影響が色濃く出ていますし、標準自体がOSSの仕様に牽引される形で決まるという流れすらあります。
ところで、Spring Frameworkの場合は、もともとはJ2EEの以上の分類に忠実に従っていたように思われます。Rod Johnsonの有名な
Expert One-on-One J2EE Development without EJB
- 作者: Rod Johnson,Juergen Hoeller
- 出版社/メーカー: Wrox
- 発売日: 2004/06/18
- メディア: ペーパーバック
- 購入: 1人 クリック: 8回
- この商品を含むブログ (24件) を見る
You may be wondering, "What's left of J2EE without EJB?"
「EJB抜きのJ2EEにはいったい何が残るというのだ？」と疑問に思われるかもしれない。
The answer is:a great deal. J2EE is much more than EJB. Many J2EE developers believe otherwise, and will tell you so when the see this book on your desk, but a dispassionate analysis of what EJB does, and what J2EE does overall, shows that EJB is only part of a much bigger an more important picture.
答えは「たくさん残るよ。」ということだ。J2EEにはEJBよりはるかにたくさんの価値が含まれている。多くのJ2EE開発者はそのように考えてはおらず、あなたの机にこの本が置いてあったらEJB抜きのJ2EEは無意味だと言うだろう。でも、EJBのしていることとJ2EEの全体を客観的に分析するとEJBはもっと重要な全体像のほんの一部に過ぎないことがわかる。
と書かれてます。そして、Version 2.5まではSpringのマニュアルにもJ2EEのフレームワークであるということが表紙に明記されていたのですよね。
特に、日本のSeasar2のユーザーの中には、軽量コンテナをJ2EEのアンチテーゼと解釈している人も多く、それゆえ、多くの人は同様に考えてSpringのアプリケーションもJava EEのアプリケーションとは対極に位置するものととらえているところがあるのではないかと思います。しかし、本来Springが目指したのはwithout EJBであって、without J2EEでないという事実は一応理解しておく必要はあります。もともとの思想としてエンタープライズと対立するのではなく、J2EEを使いつつアプリケーション開発の生産性を向上させるというのがあったと考えられるのです。*1
しかし、さすがにSpringの最新バージョンでは表紙からJ2EEの文字がなくなっています。既に説明したように現在では昔と違ってEJBもPojoで簡単に作成できてしまうし、JPAのようなORMもフリーで実行できてしまうのですよね。そういう意味では、10年前のミドルウェアベンダーの価値観によって定義された「エンタープライズ」という言葉*2の定義自体、既に古くて無意味になってしまってきているということなのかもしれません。
