昨日に続いて二日目の速報とインタビューです。
セッション速報編
午前中のゼネラルセッションは盛り沢山でした。
Java Studio Enterprise 8がちょうどリリース
になり、UMLとの連携強化部分がデモされました。
メソッド単位でシーケンスダイアグラムなどを
個別に生成できる機能はちょっと重宝しそうです。
さらにRicohのコピー機やDoCoMo携帯へのJava
搭載の最新事例が紹介された後、Puzzlersでも
お馴染みのJoshua BlochとNeal Gafer氏が登壇
しました。現在はお二人ともGoogleに在籍して
います。GMailやAdwardsのバックエンドはJava
なのだそうです。今後はGoogleがJavaを利用する
機会はかなり増えていくだろうとのことでした。
[Sun Java Studio Creator2]
JSF対応開発ツールの次期版に関するセッションです。
興味深かった強化ポイントとしては
1.テーマ機能の導入
一連のCSSのセットを「テーマ」としてまとめておき
切り替えることができる
2.バーチャルフォーム
一画面内に複数のフォームおよびサブミットボタン
が存在する場合、どのボタンでどの入力内容が評価
されるのかを指定できす。個々の入力内容は複数の
バーチャルフォームに所属させることができるため
複雑なフォームの場合でもユーザーにとってわかり
やすいバリデーション処理などが実現できる。
3.データプロバイダAPI
テーブルUIコンポーネントに結びつけるデータソース
としてRDBのテーブルのみならず、EJBメソッドの返値
やWEBサービスのレスポンスを指定することができる。
その際に返されたデータ構造を自動的に読み取るため
煩雑なカラム値やプロパティ値の取得を指定する必要
がない。
さらに、自分で追加したコンポーネントのデザイン用の
クラスはBeanInfoを自動生成することで自動的に用意
してくれるといった機能やJSFタグとそれに対応した
バリデーションメッセージ用タグとの結びつき(for属性
で指定するもの)を記憶しておき、JSFタグのidが変更
された場合でも結びつきを保持してくれるといった便利
な機能が追加されています。特にバーチャルフォームは
特筆すべきかと思います。複数フォームを持つ複雑な
画面を作成したことがある人であれば、誰でも悩む点を
ツール上の簡易な設定でサラッとやれてしまうのは凄い
の一言に尽きます。
JAXB2.0
JAXBについては当初から熱い視線を投げていたのですが
1.x世代では変換が片方向であったのと、サンプル例が
なんだか難しそうだったということもあって実際に使う
ことがありませんでした。今回、変換が両方向になった
だけでなく、かなり手軽に使えるようになった印象を
受けました。バイナリを含めたXML文書を処理できたり
使用するスキーマを実行時に選択できたり、XML固有の
情報をアノテーションにうまく落とし込んで表現したり
といった格段の進歩が見られます。いずれもJAXB2.0
単独ではなく、Tigerの新機能やJAXP1.3nなどの関連
する仕様の新機能をうまく活用した結果のようです。
これまでJAXBを敬遠していた方もいるかも知れませんが
(ボクもその一人ですが..)JAXB2.0については本格的に
利用してみる価値が十分にあると思います。
[Desktop Technology in Mustang]
JavaSEのデスクトップ周りに関してのMustangでの強化
ポイントについてのセッションです。内容的には昨日の
櫻庭さんのセッションとかなり重複していたので、内容
の確認といった感じでした。
[Pragmatic SOA]
Core J2EE Patterns:Best Practices and Design Strategies
の著者の一人であるJohn Crupi氏のセッションです。
以前にも書いたようにSOAネタでは期待大のコマです。
Pragmatic SOAに関連しての示唆に富んだお話を聴く
ことができましたので、別途エントリで詳細をご報告
したいと思います。
[JBI その２]&[JBI BOF]
今回の個人的な重要テーマであるJBIですが、昨日も
合わせてMark Hapner氏のセッションに計3回も参加
してしまいました。当初はJBIが目指しているものと
他社製品のBusiness Integration Server系に見ら
れるようなミドルウエアとの違いや、BPELエンジン
との区別、といったところが自分としては良く理解で
きていませんでした。今回わかったことはJBIは重厚
長大な仕組みではなく、思っていたよりLight Weight
だったということです。Java Business Integration
という名称からすると、ビジネスルールやセキュリティ、
トランザクションといった仕掛けが盛りだくさんである
ような印象を受けます。ですが、実際にはそれらの役割
は個々のService EngineやBinding Componentが担う
もので、JBIはそれらを透過的に橋渡ししているだけと
いうのが実際の姿のようです。Service Engineや
Binding Componentを一種の「メッセージプロセッサ」
と見なした場合の「ルータ」に相当するのがJBIである
というように今は理解しています。
インタビュー編
本日もキーマンの方に直撃インタビューしてみました。
[Shaleについて]
本当は昨日のShaleのセッションの後に質問したかったのですが
時間が取れなかったので、本日のCreator2のセッション開始前に
Craig McClanahan氏に尋ねてみました。
Q: ShaleはJSFを必要とするのですか？
A: そうです、JSFが必要になります。
Q: 見た感じではShaleを使うにはJSFのスキルが必要になりそう
ですが、実際にそうでしょうか？
A: はい、JSFのスキルが必要になってきます。
ということで、Shaleはstrutsの後継ではあるけれども、従来の
strutsの延長というよりは、JSFによって刷新された新しい別の
フレームワークであると捉えた方が良さそうです。
Q: Shaleの中のDialog機能(SpringのWeb Flowのようにアクション
に応じた画面遷移をXMLで記述できる)はJSFのナビゲーション
ルールを置き換えるものでしょうか？
A: 置き換えてしまうものではありません、場合によって使い分ける
ものになります。
Q: どうやって使い分けたらいいですか？
A: Outcome(次の画面遷移先を示す文字列、通常はアクションの
返値として返されたり、タグ内に静的に記述したりするもの)
があるような場合はDialogを使うことになります。
ということで、Outcomeが伴わないスタティックな画面遷移はJSFの
ナビゲーションルールで記述し、それ以外のアクションの処理結果
によって遷移が動的に変わるようなものについてはDialogを使うと
いうのが使い分けの規準になるようです。
[SOA関連について]
John Crupi氏にSOAに関連した質問をしてみました。
Q: Pragmatic SOAのポイントの一つとしてレガシーシステムは
取り除いて刷新するのではなく、既存のものをラップして
利用するというガイドラインがあるかと思います。ですが、
古いシステムの場合は往々にして古くなったハードウエア
を故障やサポート切れ/リース切れなどの理由で新しいもの
に交換しないといけないケースがあります。新しいハード
は新しいOSを必要とし、新しいOSは新しいミドルウエアを
必要とします。結果として新しいミドルウエアに対応する
ためにアプリケーションを書き換えなければならなくなり
単にラップするわけにもいかなくなってしまう場合も多々
あるように感じます。そうした場合Pragmatic SOAの観点
ではどのように対処するのが最善なのでしょうか？
A: アプリケーションの書き換えに着目するのではなく、ビジネス
のニーズおよびExposeされるポイント(Business Facadeの
ようなもの)をうまく抽出することに着目することが重要です。
アプリケーションの中身を書き換えるか、そのままラップする
かはSOA全体の観点では隠蔽されて見えない部分の話です。
重要なのはExposeされるポイントを如何に見出すかですが、
その部分は多くの場合、結構薄いレイヤーだったりします。
つまり、レガシーシステムに対して「刷新するのか?ラップする
のか?」という議論をすること自体が個々のシステムの実装面に
とらわれてしまっているということではないかと感じました。
大切なのはExposeされるポイントを適切に見出して、システム
の切り口がビジネスの切り口ときちんと対応しているように整理
することだということですね。
Q: これからデベロッパーがSOAの時代を生きていく上で身に
つけるべきスキルというのはどんなものがありますか？
A: まずはツールに精通することです。SOAでは様々な生成ツール
を使います。それらをきちんと使いこなすことが第一歩です。
その後、アーキテクトとしてスキルアップしたいなら、モデル
を扱えるようにすることが重要です。アーキテクトになるには
デベロッパーとしてのパスを通っていることが必要ですが、
プログラミングの視点だとどうしても物事を具象面で捉えて
しまいがちです。モデリングに必要なのは物事を抽象化して
捉える視点なので、それを身につけるように努力することが
必要になってきます。
アーキテクトを目指す場合に限らず、複雑化するIT技術を整理して
理解するためには物事を抽象化して捉える思考が必要ではないかと
個人的も考えています。そうした意味ではJavaの習得と合わせて
モデリングなどのスキルアップも図ることが大事だということを
あらためて確認することができました。
[JBIについて その２]
昨日に続けて、本日のBOFの後にもMark Hapner氏にJBIについて
追加でお話を伺いました。
Q: セキュリティや信頼性についてはJBIではどうなっていますか？
A: セキュリティや信頼性はService EngineやBinding Component
が用いるプロトコルのレベルで実現します。JBIはそれらを通す
だけになります。
Q: Normalized Message Routerによって処理されるローカルの
メッセージングについてはどうなりますか？
A: ローカルメッセージング内でのセキュリティや信頼性については
必要に応じてメタデータに情報を付加することで対応できます。
そのあたりは柔軟に拡張が可能なようになっているのです。
セッション速報にも記載しましたが、JBIは全てをガチガチに決める
のではなく、それ自体は思ったよりもシンプルな仕様になっている
ようです。ですが、それが故に特定のサービスやプロトコルの束縛
を受けることなく、サービス同士を仲介する「ルータ」として機能
することができるということですね。
[Night for Java]
今回のNight for Javaのヒントは「JavaOne」ということで、
『どこが、どうヒントなんじゃ？？』と思っていましたが、JBIの
BOFの後に遅れて会場入りした時には我が目を疑いました。会場の
中心にリングが設置されており、若手の総合格闘家が試合さながら
にスパーリングを展開しているのです。そう、何と今回のテーマは
「K-1グランプリ」ならぬ「J-1グランプリ」ということなのでした。
プログラミング対決は本当にエキサイティングでした。携帯端末に
LG3Dを再現したものや、SwingGUIのシナリオテストを実行できる
もの、リアルタイム処理をつかって年末ジャンボ宝くじの抽選の
ような場面をコントロールするものなどがありました。特に最後の
エントリは凄かったです。四つのルーレットにそれぞれ別々に弓矢
を放つのですが、タイミングを制御して[J][A][V][A]と特定の
箇所に四本の矢が当たるようにするという大変難しいものです。
予行では一度も成功していないという中、緊張の一瞬でしたが、
何と本番で大成功し、会場内は拍手喝采の嵐でした。実はボクは
Night for Javaに参加するのは今回が初めてで、いつもウラの
BOFに参加していました。今回も参加したいBOFがあったのですが
ここでNight for Javaのレポートをしないわけにもいかないので
JBIのBOFの後、Mark Hapner氏と一緒に急いで会場へ行きました。
ですが、あまりに面白く、かつ感動できたので来年からは外さずに
参加したいと思います(^^)
