[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



村山@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など.
#話についていけない.

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

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人全員は揃わなかったものの,十数名が参加.
昼食も大きな楕円形のテーブルを囲んで賑やかでした.

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