J2EE STUDY MEETING 11th

community

第11回J2EE勉強会にいってきました。(なんか勉強会の時しか日記書いてないような…)
今回は秋葉原のわっくほっく東京サテライト校＠ダイビルで行われました。
内容はいつもながら非常〜に充実していて大変ためになりました。著名な方もさらに多数参加されていてびっくり。いや〜この会ってすごい。
今回は８０人を越える参加者に加えテレビの取材(勉強会の内容とは関係ない趣旨っぽかったけど)も入ったりとちょっとEXCITINGでした。
そんな中、私は徹夜仕事あとのヒゲボーボーのいでたちで参加してもーた。反省。(しかも取材カメラの真正面…きっと放送禁止でカットだな…)
そんなわけで（どんなわけで）(C)koichikさん 今回はメモ風にかきます(当日のミミズ文字encription方式で暗号化されたメモを解読しつつ…)

  • はやめぐり EJB 3.0 Simplified API / 中村さん
    • Simplified API … EJB 3.0 っぽい
    • Important 7 Annotations
      • SLSB(Stateless Session Bean)
        • デプロイメントディスクリプタ記述不要(@Stateless, @Local[デフォルト], @Remote)
        • 普通にJavaのinterface
        • インターセプター(@Intercepter or @Intercepters[配列記述], @AroundInvoke)

インターセプターのメソッド・シグニチャー
public Object someMethod(InvocationContext ic) throws Exception … 太字部分は固定

        • × pointcutsなし … ん〜いまいち

ちなみにインターセプターの実装に関して

  • ダイナミック・プロキシ タイプ … Self Calling NG (自メソッドコール時、インターセプターを通らない)
  • バイト・コード・エンハンスメント タイプ … Self Calling OK (自メソッドコール時、インターセプターを通る)
      • Dependency Annotation (なかなかCOOLなネーミング!) の適用対象
        • Session Bean
        • MDB(Message Driven Bean)
        • Intercepter
        • Servlet
    • Configuration by Exception
      • 普通はデフォルト値で使えるようにして、必要な所だけアノテーションで設定値を上書きし、記述量を減らす
      • ≒ 次期 Seasar2 の Less Configuration コンセプト
      • ココが いけてない EJB 3.0
        • デプロイ
        • インターセプト対象メソッドを選べない
        • 複数のクラスに同時にインターセプターを記述しにくい
        • DIするのに @EJB, @Resource の使い分けがめんどう
        • 環境エントリのセットがめんどう(デプロイメント・ディスクリプタに記述。型の制限がある[String, Integer …])
        • コンテナ外でのテスト
        • アノテーションの記述場所
          • インターフェース ⇔ クラス
          • メソッド ⇔ プロパティ(フィールド)
            • プライベートフィールドへのインターセプション
              • ○ 見やすい(セッター/ゲッターへの記述に比較して)
              • × カプセル破壊


  • Next Generation J2EE Development / 比嘉さん (帰り際へんな質問しちゃってすみません mOm;;;)
    • Agenda
      • DIコンテナは Alternative から Main Stream へ
      • Innovations born from Open Source (by Rod Johnson)
      • オープンソース発展の要素
        • インターネットにより容易に遠隔地間のコミュニケーションが取れる時代
          • コミュニケーション・タイムラグの減少
          • E-mailによる効率的な非同期コミュニケーションの実現
      • ミドルウェア系ソフトウェア・プロダクトのライフサイクル
        • HOT SPOT ⇒ 標準化
      • Less Configuration
        • コンポーネント結合は設定なしで行えるようにし、設定情報としては、必要最小限の環境設定などにする
      • Convention over Configuration
        • ≒Configuration by Exception
    • Seasar2 Next Generation
      • Seasar2のバージョン2.3で実装(EA1)
      • Auto Register ⇒ Auto Binding
      • コンポーネント結合の全体像が見たい ⇒ diconファイル生成機能で対応
      • Auto Reload
        • 開発時における Turn Around Time の低減
        • 開発には リ・ズ・ム♪ がある ← スクリプト言語による開発からInspired (ただしエンタープライズ開発では Type Weak Language はちょっと…)
      • 条件に応じたクラスのロード
    • フレームワークの比較
      • 知名度
        • Spring > Seasar2
        • 'Spring is de-fact standard in the world.' by Rod Johnson

SpringとSeasar2

  • SpringもSeasar2も互いに良い刺激を与え合いながら進化する方向に向かいたい
  • Seasar2とEJB3.0のPersistent APIの組み合わせはよさそう(Persistent APIは良く出来ている)

AOP(Intercepter)

        • インターセプターのグループ化
        • プロキシー タイプ
    • WEBフレームワーク
      • シェア
      • ※ S2JSFは今のJSFが抱える問題点に対する解決策のひとつ
      • JSFの実装はまだ成熟していない
      • 実装の成熟度
      • MyFacesの実装は未熟だがJSFは拡張性は高いのでS2JSFでも使用
      • MyFacesの開発にOracleのJSPチームが加わるので今後の成熟に期待
      • JSFがStrutsに劣る点
        • クライアント側の入力値検証(JavaScriptによる)
        • ページ初期表示時の値設定
        • 例外発生時のエラーページがない
        • デザインの制限(テーブル、列見出し、ラジオボタン)
        • レイアウト(MyFacesではTilesとの連携により可能)
    • S2JSF
      • 特徴
        • HTMLベース(≠JSPベース)
        • クライアント側バリデーション機能
        • 完成度が高い
      • 不足点(※JSFに不足している点でもあるがJSF 1.2では問題の多くが解決される予定)
        • コンポーネントIDがメッセージに表示される
        • サブミットボタンの２度押し対策
        • URL直打ち対策
      • 次期版
        • Less Configuration
          • faces-config.xmlは不要になる予定
        • Ajax対応




※ 内容が特濃なので力尽きました。ここからはへなちょこ英語で書いた個人用メモなので読まないで下さい。(だったら書くな〜ごるぁ〜)

    • O/R Mapper
      • Specification - Persistent API
      • Implementation - Hibernate3, TopLink
      • Weakness - DI, AOP are not supported => Next^2 Generation
      • Hard to testing
      • DAO(Data Access Object) => de facto standard
      • Requirements now and then
        • Codeless: EJBQL, Persistent API
          • method signature
          • annotation
      • 2Way SQL
        • Write once, run both on Query Tool and Application.

SELECT * FROM emp WHERE id=/*id*/1

SELECT * FROM emp
WHERE job = 'clerk' AND
/*IF sal != null*/
sal >= /*sal*/2
/*END*/

      • What is DXO ? (Data Exchange Object)
        • (similar to Data Transfer Object ? / in my opinion)
        • Object which exchange between Domain Model and Presentation Model
        • Codeless transformation ! (because it costs too match in hand writing)
      • Lyering Architectre
        • Layers and related factors
          • Presentation Layer
            • Presentation Model
          • Business Logic Layer
            • Domain model
          • Persistent Layer
        • Practical advantages of Layering
          • Easy to find a person who has a skill of each layer. (not all layers)
          • Minimal effects when specification has changed
        • Factors for further figure
          • Service (Service Layer Pattern)
          • DXO
          • Application Logic
            • independent from SERVICE
            • independent from DOMAIN
            • not 'pure' domain logic
          • Domain Logic
            • Generalization -> Re-Use
            • 'pure' domain logic
          • Domain Model
            • Rich Domain Model - include Domain Logic
            • Thin Domain Model - do not include Doamin Logic
            • Modeling of Domain Model
          • report, master, data-processing
          • manual procedure
          • user's point of view
          • specification
            • Do xxx yyy
            • Listing style
          • Think GOAL first and then make procedure to it.
            • Specification, Business-Procidure, Name, Result, Procedure
          • Categorize Application Logic and Domain Logic
          • Application Logic
            • DO xxx(class) YYY(method)
            • Grouping by XXX
          • Domain Logic
            • Rich
              • mapping XXX to domain model
              • XXX which could not map to any model
              • non-persistent model (object)
                • persistent <-DI- non-persistent
                • solution
                  • persistent --new--> non-persistent
                  • persistent =static= non-persistent
              • ○ Object Oriented
              • × Less Testability
              • × Impossible to replace domain-logic object by DI container
              • × Logic modification effects implies Model modification
            • Thin
              • Opposit to above ○×
              • mapping XXX to none (any domain model could not handle it)
              • class name rule: XXXLogic
            • Martin Fowler
              • Transaction Script => Duplication


  • Lightning talks
    • Mr.Koichik
      • PofEAA / Martin Fowler
      • ??? / Eriksson Penker (look [only?] the chart of p.65)
        • meta model of business model
      • -> Research -> Rule -> Process -> [RRP]
      • Principles of the ..(i've forgot).. Application / Ronald.G.Loss
      • Hoah(?)'s CSP model
    • Mr.Shot
      • Java Reflection in Action (i will buy)
    • Mr.Ota
    • Mr.t-Wada
      • RtP Referctoring to Patterns


  • Refactoring and Testing (TDD story part2)
    • TDD != Certification Test
    • TDD == Specification Technology
      • RAD, Quality
      • Deploy Test
      • Custom Test
      • QA Test
    • Refactoring => easy to understand, easy to modify (for specification satisfaction)
    • 2 types of refactoring
    • Sence of refactoring
      • definition (by Fowler)
        • noun:
        • verb:
    • Who ?
      • Parameters
        • rename
        • extract
        • inline
    • Refactoring is not rework
    • t-WADA's view
      • published method should not be changed (Green to Green)
        • reset-culture - testing/refactoring
      • definition of "simple"
        • refactoring … codes not be thrown away
      • Chart
        • Y-axis: Dirty, Clean
        • X-axis: Don't work, Work
      • Sequence
        • red =commit=> green =commit=> refactor =commit=> green
      • noemal <=> evolutionary design
      • Development Process
        • purpose
        • certification
        • time
        • value
        • maintenance cost
        • improvement of quality
      • Test Phase
        • Unit Test (:= Interaction-based Test / Fowler)
        • Assembly Test
        • Function Test
      • Grouping Tests by Granularity and Type(interraction/state)
        • State-based Test include all Functional Test, almost Assembly Test and a little Unit Test
        • Interaction-based Test include almost Unit test and a little Assembly test
      • Green to Green <=> All Green to All Green
        • Unit test may not work after refactoring
      • Test Scale (Granularity)
        • Mock Test - bottom-up
        • Acceptance Test - satisfy functions (not enough : Red signal term is to long)
    • In J2EE
      • Both 2 below are funcitonal (blackbox) <= work well with refactoring
        • Cactus
        • Http Unit
    • Advanteges of Mock Test
      • feed back
      • bad specification (it takes long time to notice)
      • not EasyMock / too many mocks
      • crash test dummy (illegal)
      • Tell, Don't Ask (collaborator)
        • radical approach
        • stub-out -- assembly test
    • Summary
      • ?????
      • Make balance of specification decision
      • Enjoy Testing !
    • To Be Continued...