Java EEの“抽象化”はSOAへとつなげるために：JavaOne Tokyo 2005 Report

Javaのエンタープライズ利用。Java EEによって実現されてきたが、さらなる上層レイヤー“SOA”の出現によってデベロッパーが考えるべきアプローチも具体化されてきた。スペックリードのハプナー氏が進むべき道を示す。

[木田佳克，ITmedia]

　8日（火）に東京国際フォーラムで開幕した「JavaOne Tokyo 2005」。Java生誕から10年を迎えた2005年、6月に米国で開催された「2005 JavaOne Conference」、9月開催の「JavaOne China」、そして東京開催で締めくくられる。今カンファレンスでサンは、米国からJavaを司るそれぞれのエディション（Java ME、Java SE、Java EE）のスペックリードを招き、国内のデベロッパーに向けて最新動向を説いた。

　Java SEのスペックリード、米Sun Microsystems、リアルタイム＆エンジニアリングサービスのジョン・パンプチ氏は、同エディションのロードマップについて語り、Mustang（Java SE 6）、Dolphin（Java SE 7）の動向、そしてJCP（Java Community Process）によってJavaコミュニティーは健全に成長し続けていることを報告した。JCPは、約950人以上の活動によって支えられているモチベーションの高いグループであることを強調し、会場に功績への拍手を求めた。

Java SEのスペックリード、米Sun Microsystems、リアルタイム＆エンジニアリングサービスのジョン・パンプチ氏

　コードネーム“Tiger”と呼ばれていたJava 2 SE 5.0は既に2004年9月リリースされて多くのデベロッパーに利用されているが、安定度も高まり高速化も果たしているという。今後は5.1のマイナーバージョンアップは計画されていないことを強調し、6.0となるコードネームMustangについてを語り出した。

Javaの10年を振り返ると、当初は組み込みとしてスタートしたものの、クライアント＆サーバでインターネットに対応、そしてモバイルへの展開も行ってきた。この10年で最も重要なテクノロジー実装は、ガベージコレクションやスレッティングなど、とプレゼンで示した

Sun Fire V490のSPARC版Solaris 9上で比較したところ、Java SE 6.0は当初（J2SE 1.2.2）に比べ6倍のパフォーマンスを記録しているという

　Java SE 6となるコードネームMustungについては、約1年間毎週のスナップショットを公開し続けておりさまざまなスペックが盛り込まれているが、JSR-199やWebサービスなど世代を反映するものばかりだという。その採用テーマは？　というと、さまざまな意志判断はあるものの、大別してXML、Webサービス、EoD、デスクトップなどが挙げられた。

Sunとしては見慣れなかったLonghoneサポート、Direct Xなどが読み取れる。マイクロソフトとの協調がいよいよこのエディションで見え始めるのだろうか

　互換性、安定性、品質も大きなポイントだが、すべてのリリースで課題となっているのは“互換性”だという。また、ツールで品質管理を行うことが重要視されてきたと言い、パフォーマンス改善がキーポイントの一つだとコメントした。

Java EEはSOAを視野に入れたさらなる躍進へ

　続いて登壇されたエンタープライズ向けのJava EEスペックリード、米Sun MicrosystemsでJava Webサービス・ストラテジストのマーク・パプナー氏は、サーバサイドの動向についてを語った。

Java EEスペックリード、米Sun MicrosystemsでJava Webサービス・ストラテジストのマーク・パプナー氏

　「エンタープライズ向けにリリースしてきたEnterprise Editionだが、高度化することで開発者が生産性を上げることが難しくなってきた」と言い、EoD（Ease of Development）に関わるPOJOベースプログラミング手法の採用、アノテーション、リソース・インジェクション、新たなAPIとして取り上げられることの多いPersistance APIが大きなポイントだと語った。

　ハプナー氏は、これまでのEnterprise EditionについてJava EE 5.0までの革新を振り返った。1.4でのWebサービス実装を挙げ、EE 5.0での実装例を比較、その抽象化度合い（アノテーション）をソースで示し、強調した。

　リリースされているJava EE 5.0では、JSP（JSR-52）はもちろん、StAX（JSR-173）、Webサービスメタデータ（JSR-181）、Persistence API（JSR-220）、JAXB（JSR-222）、JAX-WS（JSR-224）、アノテーション（JSR-250）、JSF（JSR-252）などさまざまなスペックが追加されてきたが、複雑化すると同時に抽象化を行うべく扱いの容易さを追加していることだという。この根底には、今後、SOA実現のために相互運用性が問われてくれば、デベロッパーはEJBだけの知識では収束できなくなってくることが予想される。つまりは抽象化をしなければ前述のハプナー氏のコメント通り生産性向上とは反比例してしまう危険性をカバーしてのものだろう。

　Sunは、11月4日付けでオープンソースによる相互運用性について発表したが（関連記事）、この講演でもハプナー氏はGlassFishへの参加を何度も強調していた。

　ハプナー氏は、SOAについてもデベロッパーの考えるべき視点でコメントし、「将来を見通すと、さらに適用範囲を広げなければならない。Java EEの域をさらに超える必要性があり、Javaコミュニティーがサービスを作って行かなくてはならないだろう」と語った。今カンファレンスではマイクロソフトもセッションを行っており、相互運用性はJava情勢主導で進んでいくことも現実的となってきた（関連記事）。

　前述のように、ハプナー氏はSOAに関わる開発者は、いくつかの技術を組み合わせる必要性が必須になると言及し、Java（EJBなど）テクノロジーだけではなくXSLTやSQL、BPEL、Rule、XQueryなどを挙げた。しかし、これらの連携した統合開発環境（IDE）が求められるはずだともコメントした。

　さらに、広範囲なESBについても語り、「インフラを示すためのもの。ツールやミドルウェアなどを包括し、実行し、モニターする必要性もあるが、ESBはJava上で実装して異なったインフラを持つもののこれらを統合しなければならない」とJava陣営における課題を挙げた。アプリケーション統合は容易ではないだろうとコメントするものの、Javaプラットフォームとしての課題であることを示していた。