[jfriends-ml 11006] 議事録もどき (1/31)

[murayama <murayama@xxxxxxxxxxxxx>]

村山@netgeneです．

議事録もどきです．

EJBは専門外で話についていけなかっただけに，間違いも多数ある
でしょう．それだけにどうしようかとも思いましたが，枯れ木も
山の賑わいということで，一応流しておきます．皆さんで適当に
突っ込みを入れて下さい．

-------------------------------------------------
1/31

古橋，原， 金井，高橋（徹），
伊藤，高橋（智），百瀬，宮本，
西野，新井，根本，布留川，井上
村山，村上，中村，松尾，
＃記載漏れもあるかも．

○推薦の言葉，目次，序文

・オライリー，「EJB」第三版の訳あり．
非常に良いらしい．

ワークブック
アーカイブあり．googleで検索かければ見つけるのは容易．

・原書には全パターンが載っているポスター？が付いているが
日本語版にはない．

・"Mastering Enterprise Javabeans 2nd"
順番からいくとこちらから先に読むべき．
＃日本語訳もあるらしい．
＃http://www.amazon.co.jp/exec/obidos/ASIN/479810213X/250-7162296-2589010

・翻訳もしっかりしている．

・ソースコードは最後にまとめて置かれている．
本文とコードと行ったり来たりで面倒．

・アレキサンダーの「デザインパターン」
階層構造で，
「町」から「家」，「窓，扉」等々
の階層で書かれているらしい．

○始めに

・EJB2.0に
コンテナ〜パーシステンスの強化によって，
デザインパターンも一変．

CMPは使うな？

自分で管理するよりコンテナに任せた方が性能が高い．
Beanの配置にも影響する．
＃まるでGCやインライン展開のよう．

Local Entity Beanがなかったから手作業でチューニングしていた？
今は異なる便利な書き方があるということか？

・この本はEJB2.0ベース．

・「最良の解決策」
"best practice solution"

＃「こうやったらうまくいった」
＃「実体験に基づく最良の解決策」

・Christopher Alexander，
オリジナルの「デザインパターン」．

IT技術者にとって直接の関係はない．
書き方とか「階層がある」とかでなら多少は参考になる．

建築学会では流行ったのは昔．現在はいまひとつ？

GoFのデザインパターンも，今やわざわざ口にしない．
それだけ成熟した証拠では？
"getInstance()"とかがあっても，それが何であるかなど
悩んだりしない．

・謝辞．無数の校閲者．
www.serverside.comのレビュアでは．
新技術を先に勉強するチャンスでもある．

--------------------------------------------------------
第一部

○Chapter1

・JavaコマンドBean
the java COMMAND beans

コマンドパターンを実装したJavaBean?
あとのお楽しみでは．

○Session Facade

・図1.1
UserHome，findByPrimaryKey()等々は，見る人が見れば分かる．

UserHome，AccountHome等はEntityBean．

・承認
既に認証した後の話．

・「少なくとも6回の呼び出しを必要とする．」
図1.1の6本の右向き矢印がそれ．

・「一貫性」
consistency

・「JTAを介して〜」
具体的な方法は書いていない．

アプリケーションサーバーはJTAを持っていなければならない．
 J2EEの必須の機能．JTAなしではJ2EE対応とは言えない．

2フェーズコミットをサポートしているか否か．
＃サポートしていて当然？？

2フェーズコミットとは？
 例えば，2台のマシン上にそれぞれDBがある場合でさえも，
 一貫性を保証する仕掛け，らしい．

MySQL4.xは非対応なはず．5.xは不明．
  1フェーズでも同様の処理は実現できる？？

2フェーズ対応．Oracle，DB2など．
＃話についていけない．

・２フェーズコミットは次の条件が揃っていないと実現されない．

1，DBMSがサポートしている，
2，JDBCドライバもサポートしている，
3，アプリケーションサーバーにも？？がある．
4，JTE対応？
など．

一つでも足りない物があると，当然1フェーズになる．

・データの方が寿命が長い．
データベースを一度決めたら滅多に変更できない．
先にデータベースが決まっていることも多い．

その場合は2フェーズコミットが必要な場合でも，
他の方法で実現せざるを得ない場合もある．

・「同じエンティティビーンのインスタンス」
ロックになる，ならない？

普通は行ロック．

別プライマリーキーならば可能．
そのユーザーのアカウントはロックされるが，他ユーザ？の場合は可能．

同じユーザーへの入金と出金が同時に来ると，同時に平行して処理できない．

トランザクションの個数のLimitにもなる．
リミッタが無い場合には，さらにひどい状態にもなる．


・「宣言的なトランザクション」
EJBのメソッドで行われるトランザクション．
デプロイメント=ディスクリプタに記述するだけで，
勝手にやってくれる．

デフォルト値（多分required）というのがあったような気がする．
  ->宿題．
	
・「ローカルインターフェース」
図1.2の左右でエンティティビーンの設計が異なる．

ローカルインターフェースはEJB2.0から．
外部からは見えない（つまり呼べない）インターフェース．

・「ビジネスロジック〜 すべてアプリケーションの中に置くべきです．」
「環境に固定したホスト名」などでは．
P170に階層分けの図．

bean tellerの．．．

・P28「通常はステートレスセッションビーンとして実装されます」
素直にMVCを実装すればそうなるのでは．

＃パフォーマンス面の問題もあるのでは．ステートレスならサーブレットの
＃ようにマルチスレッドでも非同期実行可能だから．

・CoreJ2EE patternに載っている？
"Patterns of Enterprise Architecture"
ファウラーのパターン本．売れている．
サンプルはJava又はC#．

サービスレイヤー：セッションファサードに相当．

「ドメインモデル」

＃「アプリケーション」？宿題．

・呼び出し順序のようなものは別．
entity beanに入れると再利用性が下がる．切り分けが困難．

--------------------------
○メッセージファサード

・「ユースケースをキューに入れ」
意味は分かるが変な表現．

・戻り値voidでも同期する必要があるか？
戻り値は不要でも例外を取得する必要がある場合は必要．
＃でも，これって同期といえるのか？？

・「2秒以上辛抱できることは」
誤訳．"a couple of seconds"で「数秒」．
さすがに「2秒ルール」では実現不可能．

・図1.6
図がおかしい．
ツールの制約によるものでは．
UMLとは一言も書いていないからぎりぎりセーフ？

・Visioも次々エラーが出るので，使い物にならない．
リヴァースすると「関連」が出ない．

"Enterprise Architect"．安いツール．意外に良い？
唯一のデルファイ対応．「安い」．
すごく便利．


・単一障害点
"single points failuer"

・JMS
パブリッシャー=サブスクライバー形式，等々．．．

「飛行機が離陸した後にも座席予約できる．」
  ほっとくと，いつか必ず処理してしまう．
  不要な場合はキャンセルしないと，かえって変な動作になる．

メッセージングでは「ロールバック」とは言わず「キャンセル」とか言う．


・IBM MQ
MQネイティブに使うのなら

Webスフィアに「ついてこない」ものの方が機能は多い．
Webスフィアに付属のものはJMS準拠で，機能が減らされている．

・JMS製品は，普通に付いているのを使うか別に買うのか．
従来は密に結合していて取り替え不可能だったが，今後は
可能になっていくだろう．

昔は互換性テストが甘かったので変更可能と言いつつ，実際は
変更できなかった．JMS標準のテストが厳しくなったので，今後は
取り替えらられるようになるのでは．

・セッションファサードとメッセージファサードでロジックが重複．
最初にセッションファサードがあって，後からメッセージ〜を書く．
その結果重複する．

・委譲はどこで．
メッセージファサードでやるべきかJavaのクラスでやるべきか．

セッションビーンで囲まれているから，Javaのクラスでもいいのでは？
？？

＃話についていけない．


・「弱い型付け」
型は一応あるけれど，どんな型が来ているかはキャストしないと分からない．
Javaでいう「Object型」的な処理．

・メッセージキュー
バージョン変更にはどうするか．
メッセージキューにたまったものは．

XMLで送ればバージョン変更に対応できるか．
		->難しい．
  XML技術自体にバージョン間の互換性云々の機能はない．
  あるとすればJavaのXMLシリアライザ側の機能．

バージョン情報を持たせ，バージョンごとにキューを用意する
のが現実的．処理が複雑になるのが難．


一斉に全システム更新は，まず不可能．
一部地域のみ新技術に変更

UDDIで「処理できる人」を選んで送信するという手も．

・XML
XMLは重い．Webサービスなども処理が遅い．W3C XML Schema（WXS）も重い．

WXSは必ず毎回ヴァリデーションを入れなければならない．これ自体が重い．
DOM実装やXPath等を使っている場合は，この仕様自体が重い．
現在の実装はおそらくDOM実装の上に実装されており，最適化も十分ではない．
SAXが使えるような仕様なら，それなりに軽い可能性がある．
  WXSを使ったが最後，SAXで軽量に実行したくても，毎回WXSのヴァリデーション
  を実行しなければならず，軽量実装は不可能になる．

Castorはまあまあ良い．細かいバグがあるが．．．

・型チェックができなくてもいいじゃないか．

・JMS
ノーティフィケーション=サービス．（notification service?）
＃CORBAの仕様．

パーシステントが未サポート．
サーバーが死ぬと消える．

これがあれば，今の問題はすべて解決．（する予定．）
＃「今の問題」が何なのか理解できず．

・オライリー「Java Messaging Service」
メッセージだけに鳩本．

・プッシュとプル
プルの方が効率がよい．「暇だからこそ取りに行く」．

「空いたら次の処理する．」
コンテナまで含めると，キューから取り出すというアクションで動いている．

JMSだと，本当に両方ある．（「自分から取りに行く」「送ってもらう」）

・JbossはJMSの実装を含む．

P2P．

・Java PRESS Vol34に宮本さんの記事．
みんなで読みましょう．

--------------------------
○EJB Command

・「転送ロジックから〜」get..., set....,
なぜget/set可能か．

P238のコード例を参照しながら．．．

・ソースコード
簡単な例．超簡易版，あくまで単なるサンプル．

・P236
ctx.setRollbackOnly()

ユーザー定義例外なので，これがないと自動的にロールバック
されるわけではない．(P229に解説あり．)

・EJBコマンドは大規模でないと使えないか．

・分割して発注できること自体がメリットでは．

・アスペクト指向なら無くなるか？
アスペクト指向は直行しているもの用．

直行してないものは，アスペクト指向じゃ無理．
トランザクションは直行してないから無理？

・メタデータ

・xdoclet
決まり切った処理を書かなくて良いツール．

----------------------------------------------------
余談．

・Thinkpad 5，VAIO 1，let's note 1．
相変わらずThinkpad優勢．
＃ちなみに一番古いのは，やはり予想通り私のX20．

無線LAN内蔵4（以上）．

・さすがに24人全員は揃わなかったものの，十数名が参加．
昼食も大きな楕円形のテーブルを囲んで賑やかでした．

注文が運ばれてくる順番が謎．
----------------------------------------------------