torutkのブログ

ソフトウェア・エンジニアのブログ

Java Computing 2005 Spring 2日目

昨日は会社に戻って終電頃まで仕事したので、かなり寝不足で臨みました。
朝受け付けで書籍
J2EEレガシーインテグレーション
をもらいました。

基調講演

Linda DeMichiel女史のEnterprise Java Bean 3.0のお話し。
Enterpriseプラットフォーム向けJavaの理念、EJB1.1から3.0へ至る経緯の紹介から始まりました。EJBは機能追加がかなりうまくいっており、その柔軟な設計についてはちょっとご自慢の様子でした。ただし、EJBへの批判やアンチパターンを謙虚に受け入れて、EJB3.0では大きなEoD(開発容易性)を目指しています。APIをかなり簡素化した上に、デフォルト定義を用意してデフォルトの振る舞いでよい範囲については設定を省略してもよいという徹底振り。
EJB3.0では、EJB2.1を捨てる訳ではなく、適材適所で共存するように持っていくようです。

EntityBeanについては、O/Rマッピングに際してEJBコンテナ外へ取り出してもよい構造になります。POJOに非常に近いクラスで定義されるので、従来ならDTO(Data Transfer Object)に属性を詰め替えて別Tierに送っていた問題を解決できそうです。DTOは優れた設計のパターンではなく、現状のレイヤー分割(永続層とビジネスロジック層)において永続層の実装をビジネスロジック層へ引き込まないようにする「苦肉の策」なのです。

EJB3.0における永続化の仕組みに関しては、OODB(Object-Oriented Dababase)を知っている人ならイメージが容易につきそうな構造です。永続オブジェクトがライフサイクルを持っており、アタッチ・デタッチ・再アタッチ(merge)が出来るようになっています。永続化機構への依存性を持たないPOJOなオブジェクトを、必要に応じてDB等から切り離してプレゼンテーション層へ渡し、DTOを介さずに属性を読み書きしたりロジックを実行したりすることが可能になります。属性を変更した場合、永続化する必要があれば再び永続層へオブジェクトを戻してmergeすればよいという仕組みです。
これって、昔いじったObjectStoreと同じようです。POJOを永続化させる方法が、昔のOODBだとポストプロセッサ等でPOJOのクラスファイルを修正して必要な機能を組み込みます。EJB3.0ではアノテーションを使うのでやはりPOJOのクラスファイルをどこかで修正して必要な機能を組み込むのでしょう。ただし、AOP等で動的に組み込むのであれば、依存性の問題は解決できそうに思えますが・・・。まずはEJB3.0の仕様と実装をいくつか見てみたいところです。

また、J2EEO/RマッピングAPIは、J2EEの外に取り出せるようにしているそうです。今ひとつ普及していないJDOの一つの帰着点になるのでしょうか。

EJB3.0の実現には、J2SE 5.0で導入されたメタデータを積極的に使用するので、EJB3.0を含んだJ2EE 5.0がリリースされると急速にJ2SE 5.0も広まるのではないかと思いました。

本日の基調講演では、Linda女史のお話しは実は1時間で、続いてはNTTドコモのお話しになります。お昼が混むことが予想されるので、ここで抜け出してランチに向かいました。

昼食

11時から、六本木ヒルズのレストランガイドを見ながらあっちへうろうろ、こっちへうろうろしてみました。高級店も多く、ランチとはいえ三千円・五千円以上としているところがあります。気分的にお米を食べたかったので、「老虎東一居」で麻婆豆腐定食を食べました。1000円でお釣りが来ました。

Webフレームワーク選択のポイントと開発の実際

NTTデータの方のプレゼン。題名と内容はかなりずれています。Webフレームワークの比較の話ではなく、自社SI案件において社内標準フレームワークを開発しており、そこにStrutsをベースとしていろいろ機能を付加していることの説明でした。オープンソースを利用して社内標準フレームワークを整備していくという企業活動としては大いに参考になりました。

J2SE 5.0の技術的な概要

SunのRaghavan Srinivas氏によるマシンガントーク。とても早口でした。同時通訳はよく固まっていました。最初のクイズ(Threadオブジェクトのrunメソッドを呼ぶ間違い)にはひっかかってしまいました。
Tigerのテーマでは、Qualityをとっても重視しています。互換性も大事にしています。という当たり前ながら難しいことを述べていました。

Java Webサービスおよびサービス指向アーキテクチャ(SOA)

前述と同じくRaghavan Srinivas氏によるマシンガントーク。同時通訳しょっちゅうこけてました。
Java Business Integration(JBI)がJSRで審議されているようです。J2EE 5.0には含めるかも。
一応SOAについて原則をまとめていました。

  • ドキュメントベース(vs. 手続き)
  • 非同期メッセージング(vs. 同期)
  • 会話的インタラクション的(vs. 単純なリクエスト/リプライ)
  • サービス登録と再利用(UDDI)
  • ラップしてレガシーを利用する
  • サービスのオーケストレーション(動的にサービスを連携させる)

あとはキーワードをメモ

  • Federated Identity and Policy
  • サービスの管理と監視
  • Portal Presentation Layer (Federated ID)
    • United Customer View
    • Unified Role-Based View (Portal)
    • WSRP
  • SOAWebサービスがなくても実現できるが、Webサービスが最良のSOA実現方法
  • J2EE 1.4では、エンドポイント、WSDL、SAAJ、JAXR、EJB2.1、JCAなどのWebサービスの傘を提供
  • J2EE 1.5以降では、Java Business Integration(JSR-208)でSOAのコア、サービスエンジンの拡張、などなどを提供していく
  • JBI(Java Business Integration)仕様
    • Service Engine, Binding Components, Normalized Messaging Service(NMS), NMSのメッセージフロー標準
    • SEはフレームワークへのSPIを持つコンポーネントで、SPIをサポートしていればどんな言語でもよい
    • BCは、SOAP(WS-I)、ebXML、AS1/AS2、JMS、JCA、カスタムバインドなど
    • NMSは、メッセージのルーティング

Java Server FacesおよびCreator

SunのChunk-Munn Lee氏による講演。Creatorのデモが中心。
ツール上でユーザーインタフェース部品をDrag&Dropして、それをデータソース(RDBMSEJB)と結びつけて画面とコントロールを生成させるイメージでWeb画面を構築していく開発スタイル。一部Javaのコードを書く部分もあるようですが、コードサンプル(snippet)からペーストして埋め込むだけで済むようになっています。

小中規模なWeb画面であれば、Creatorで随分と簡単にWeb層の作成ができるようになってきています。しかし複雑な画面はやはりCreatorでは難しいとの話もありました。Creatorの利用者がJava開発技術が高くない、主にシステムのユーザーなので、それはそれでよいのかと思います。

BOF ja-jakarta

2つのBOFが同時間帯にあり、どちらに出るかを悩みました。
片方はProject Looking Glass、もう片方はJa Jakarta Project、前者は内容的に魅力があり、後者はCraig McClanahan氏やSeasor2のひが氏も参加しています。悩んだ今回はJa Jakartaに参加しました。InternetWeek2004でJa Jakartaの皆様にお世話になったこともあったことだし。。。

Webアプリケーション開発は、Tomcatが誕生する以前の頃、Apache httpにJServと呼ばれたモジュールを導入した環境を仕事でちょっとだけ導入したことがあっただけです。JSPもなく、ひたすらprintlnでHTML文を出力していました。

さて、BOFの内容はCraig氏のStruts shale話やApacheプロジェクトの運営や英語でのコミュニケーションなど広い話題を扱っていました。
StrutsJSFどちらを使うかという疑問についてCraig氏の話によれば、既存のStrutsベースのアプリを維持しているなら、全面書き換えは大変なのでStrutsを使い続ければよろしい、新規アプリならJSFを勧める、というものでした。なお、Struts shaleとは、JSF対応した(もしかするとDIコンテナ対応も?)Strutsだが、あまりにドラスティックに変更するため、Struts2.0としてではなく別プロジェクトとして開発しているとのこと。