議事録 / 第05回

8章 AOPの概念を使った宣言的なミドルウェア

• Summaryから入った方がわかりやすいのでSummaryから

Summary

• この章では「宣言的な」エンタープライズサービスというところが重要ではないか。
• ポイントカットではアスペクトのコードを「意識しないこと」が重要となる。
• Aspectという概念は随分と前からある。
• AspectWeaver?というものがSmaltalkであった。

AOP 101

• 101というのは救急車の番号ではないか。

AOP in J2EE

• AOPは全く新しい概念というわけではない。
• EJBで提供されるサービスを提供するものという位置づけ。
  • OOPである継承による実装で解決できないものをAOPで解決するとよく言われる。
    • 委譲でもコードを分散させずに解決することはできないか？
    • コードを書かずに振る舞いを与えることが可能なことがメリットではないか？
    • このあたりの解説がちゃんとあるとよいのだけど。

Definition

• 「関心事」の読み方は「かんしんじ」or「かんしんごと」？
  • 千葉先生に確認しましょう。
• Mix-inは大雑把にいうと多重継承のこと？
  • AspectJでweavingしてもMix-inと呼ぶかも
    • RubyもMix-inできるよ。
• Eiffelをエッフェルと読むかアイフルと読むかは宗教論になる。
• 振る舞いに対するAspcetと構造に対するAspectがある。
  • Introductionは構造にたいするAspect。
  • 構造に対するAspectはOOの原則を壊すので否定的な向きもある。
• PointCut?のstatic/dynamicの区別をしてるのはSpringぐらい？
  • 普通はstaticだけしか使わないからでは？

History

• AspectをチェーンするのはどんなAOPのフレームワークでもほぼ同じやり方でやっていると思われる。

EJB as Subset of AOP

• ここのレストランの比喩はちょっとどうかと思う。

AOP Implementation Startegies

Dynamic Proxies

• DynamicProxy?の場合は、Method AとBにAOPが掛かっていた場合、weavingされたAの内部でBを呼ぶとBに対してはweavingされない！！
  • 例えばNested Transactionでこういうことが必要になる可能性がある。
    • 業務ロジックの実行中にログなどをテーブルに書きたい場合に、元のトランザクションがロールバックされると、ログが別のトランザクションに分けられないと困る。
    • 役割と責任が別ならば別のクラスに切り分ければよいのでは？
• DynamicProxy?のパフォーマンスはそれほど悪いわけではない。

Dynamic Byte Code Generation

• 最近HibernateのMLでCGLIBがメモリリークしてるって情報がある！！
  • えー！？(一同)

Use of Custom Class Loader

• クラスローダに手を入れるやり方ではAPサーバによっては問題があるのでは？

Launguage Extension

• これらのAOP技術は組み合わせて使ったりもできる。

AOP Implementations

AspectJ

• ソースコードを触るので心理的な障壁がある。
  • XMLさわるのとソースコードを触るのとどっちがいいか？
  • ちゃんとコード管理してないとコンパイルが全てのソースに対して走る。
• Adviseを再利用しにくいと感じる。
  • AspectJではAspectを継承できるので、必要なPointcutだけ書くというやり方をしては？
  • AspectJのサンプルで継承をしてる実例がないので知っている人が少ない。

AspectWerkz?

• transformationって何のこと？
• アスペクトヴェルツと読む。
• SpringではAspectWerkz?のプロキシを使えるようになるらしい。
  • SpringではそれぞれのAPサーバ用のクラスローダを持っている。
    • それはびみょーだ。（byひがさん）

JBOSS

• 昔はJOBSS独自だったが最近はaopalienceに準拠しはじめているらしい。

Spring

• 強い型づけの意味するとは？
  • proceedの戻り値や引数がObject型なのでキャストしないと使えないということでは？
  • aopalienceのAPIに準拠する限り無理な気がする。
  • Tigerになれば型付けできるようになるかもしれない。
    • メソッドによって引数の数とか違うので無理じゃないかな？
• AfterAdvise?とかThrowsAdvise?とか違和感を感じる。
  • 実際にはThrowsAdivce?は使わない。Aroundぐらい。(Spring実務経験者談)
  • ThrowsAdvice?は例外を変換したり殺したりはできない。
    • フレームワークの例外をアプリケーションの例外に置き換えたりしたいという要求はある。
• AfterでAdviceをしたものはPointcutを再実行不可能なので、そういう場合は結局Aroundを使うしかない。

The AOP Aliance

• AOPをかける前のクラスが取れないという欠点がある。
  • S2では独自にサポートしている(org.seasar.framework.aop.interceptors.AbstractInterceptor?#getTargetClass?)。

AOP Design Issue

Dangers of AOP

• フィールドインターセプションはOOPのカプセル化を壊すので危険。
• アスペクトの濫用は危険。
• アスペクトの設定は一箇所にしておいた方が吉。
• debugできないというのは、AspectJのみ。
  • AspectJも統合環境をつかえばDebugできたような…。
• Aspectのテストをするときは、最も単純な実装に対してAspect適用してみる。
  • AspectもPOJOだがMethodInvocation?とかを作るのが面倒。
    • S2JSFのサンプル見れ！一つのクラスに３つくらいAspectかけてるよ。

AOP Design Recommendations

• 三段階にわけて使うとよい。

1. とりあえず使ってみる。
2. コードの重複を取り除く。
3. AOPを細かく分割し、mixinさせてつかう。

J2EE a la carte

• 以前と重複しているのでパス

AOP in Practice with Spring

• AutoProxying?は危険？
  • 実装ルールが周知徹底されていないと危険。
  • Aspectが楽に使用できるためにクラス名が縛られるのが嫌。
  • Aspectがどのように掛かってるのかわからなくなってしまう。
    • 順番や、どのAspectが掛かっているか。
    • Aspectがかかる条件もぱっとみてわからない。
  • KijimunaのGUIではautoproxyingのように見せて、設定ファイルは変わらないというアイデアはいいかも。
• 実際のSpringのプロジェクトではAutoProxying?使う。使わないとツライ。(経験者談)
  • Transactionはメタデータでやる。
• Aspectのスタックを定義したり、継承できるようにするとよいかも。
  • JBossやXWorkなどは持っている機能。
  • 継承よりはコンポジションの方がよいと思われ。
    • 実装よろしくー（ｗ＞太一さん

Using Source-level Metadata to Provide an Abstraction above AOP

• メタデータのお話。
• メタデータは便利ですか？ >Spring使ってる人
  • AutoProxying?前提だと無いとこまる。
  • 定義ファイルが肥大化しがちなのでコード上で見えないとつらい。
    • struts-config.xmlと同じ感じ？
• メタデータとアノテーションは同じように使われがちだが、異なる概念。
• メタデータに全て記述して直接実装に関連するような仕組みにしてしまうと、実装が変わったときの影響が大きい。
  • 振る舞いとアノテーションの関連を設定ファイルに記述できるようにする流れになるのではないか。

.NET Example

• メタデータの出自は.NET

Implications for Programming Style

Avoiding Reliance on the AOP Infrastructure

• protectedのところおかしいのでは？
• SpringもJTAをベースにすればいいのに。

Checked Exceptions and Advice

• Srpingのソースでは全てInvocationTargetException?でくるまれる。
  • getCauseなどで元の例外を取り出す必要がある（アスペクトの外で）。

9章 Transaction Management

• またSummaryから入ります。

Summary

• JTAに依存するのは良くないとあるが、何故良くないのか？
  • 例外ハンドリグが面倒くさいぐらいしか理由が思い当たらない。
• PofEAAはHibernateなどのフレームワーク開発者が読む本。
  • とりあえず読む本ではない。
  • トランザクションの基本を学ぶ本ではない。

High-level Transaction Management

• ナイーブな方法ではいろんなオブジェクトでConnectionを持ちまわる必要があり、コードがConnectionに汚染されてしまう。
  • 分散トランザクションとはあまり関係ない話。
  • DataSource?に関係するオブジェクトがDataSource?に関わればよい。

Classic J2EE Transaction Management

• 通常は複数のDBに対して2フェーズコミットが必要になるようなものを分散トランザクションと呼ぶ。

The J2EE Container as Transaction Coordinator

Transaction Manager, XA, 2PC

• ひがさんによるアーキテクチャ解説

UserTransaction?

(JNDIでjava:comp/UserTransaction?) ユーザから見えるのはこれ

TransactionManager?

裏で動くトランザクションマネージャ、TransactionをThreadLocal?でスレッドごとに管理している

XAResource

コネクションを管理してる

Xid

ユニークである必要がある。トランザクションの識別子（64byte）

Syncronization

commitなどのbefore/afterで動く。Hibernateではcommitの寸前でデータをflushしたりする

• XADataSource?とDataSource?の関係は

  UserTransaction? > DataSource?(XADataSource?)

  XAConnection(extends PooledConnection?)

  XAResource

  Connection

JCA

• 大雑把な仕掛けはJTAと同じことをしている

Direct Use of JTA

• ここで挙げられた欠点は、APサーバのJTAを使ったときの話ではないか？
• J2EE準拠のAPサーバはかならずJTAは実装されている。

Interlude: Remote Transaction Propagation

• リモートでトランザクションが伝播するアプリケーションはそんなに多くはない
• MLで話をしていたのはこのあたり。
• トランザクションはCORBAでオブジェクト参照が渡る。

Transaction Management Strategies

• 実装が増えるたびにTransactionManager?が増えてしまうのはどうよ？

• トランザクション関連を勉強したいときは…
  • JTA Specifications Sunのやつを読むとよい。
    • シーケンス図もあってわかりやすいです。
  • JDBCのOptional仕様のPooledConnection?とかのあたりもよい（DataSource?周り）

• 次回は10,11章
• 2/19(土)を予定