読書会(More Java Pitfalls)第8回議事録
[ 戻る ]
"More Java Pitfalls" を読む会 第8回議事録
日時: 2003/12/27 10:15 〜 16:45
場所: 東山社会教育館 第1研修室
参加者(敬称略): 高橋(智), 根本, 村山, 門脇, 井上, 宮本, 村上, 高橋(徹), 石黒
自己紹介: 省略
書記: 門脇
読み手: 順番に輪読
■次の課題図書の話
現在のところ
・EJB デザインパターン 2票
薄い。4ヶ月ぐらいか。
-> 表面はやさしいけど、発展させると(奥まで読むと)難しい。
・達人プログラマ
票が入っている本だけ残して、再度投票するか。
参加者を増やすため他の ML などに宣伝が必要。
ML 上で Struts in Action の話など、反応が低かった。
#Struts in Action -> 和訳あり。
#結論出ず。
■Item 45: Take a Dip in the Resource Pool
Web-enable:
・ウェブ化
レガシーアプリをラップしてウェブ化するとかのことか。
Listing 45.2:
・例外を拾うだけでいいのか? エラー処理は?
-> "単純な例" なので。
・Exception で全部拾っているのは良くない。
Java Exchange:
・Web Site (http://javaexchange.com)
Listing 45.3:
・データベースへの認証を誰が行うかを示す。
Container, Application が指定可能。
p.385: Java Connector Architecture (JCA) 関連
・Sun Micro. が JDBC を JCA でラップしたものを EA として出している。
・J2EE 1.3 以降では RAR (Resource Archive) に記述を含める。
今月の JavaWorld に記事あり。
・全部を EJB で接続、データベースと同じ感覚でアプリケーションに接続可能
にする。
・現時点で JCA の本は英語本のみ。Sun が出している。
■Item 46: JDO adn data Persistence
second guessing:
・second-guesse: あと知恵[結果論]で批判[修正]する;
hog:
・(パフォーマンスの)消費が激しい、大喰らい
Listing 46.1: p.387, 389
・java.benas.XMLEncoder, java.beans.XMLDecoder
最近は (JDK 1.4 から) XML にシリアライズ可能
・JDK のコードネーム
Merlin: 1.4
Tiger: 1.5
losing step:
・ここでのstep は行?
-> "行情報を失う" ことではないか。
XML シリアライズ:
・チェックサムをつけるとかするのか?
-> しない。
例えば手で修正したものをそのまま読み込むはず。
-> XML だとキャラクタのエンコーディングの切り替えがあるので、ハッシュ
などをつけるのは難しいのではないか。
・(XML シリアライズされた) XML ファイルのスキーマは?
・XML にシリアライズすると JDK バージョン間での非互換の問題は無くなる。
p.390:
・RMI で reset() メソッドって何?
-> コネクションを切って初期化するメソッド?
-> シリアライゼーション関連で InputStream, OutputStream とかにありそう。
-> ありました。
RMI について:
・パフォーマンスが良い?
-> パフォーマンスが必要なら RMI でやるよりは TCP で直接にする方が速い。
-> 複雑なことをするなら、自前でやるより CORBA な製品を使ってしまうほう
が速かったりする。
JDO の意義?:
・JDO でテーブルは先に作る必要があるのか?
-> create をやってくれるならスキーマをどこに持たせる?
-> create はやってくれないのではないか?
-> EJB でもデプロイしたときに自動でデータベーステーブルを生成できるは
ずだけれども、実際にやっている人はいないのではないか?
-> (テーブルを生成するための)データベースの制約条件などを記述して、
というのは面倒ではないか。
-> OJB だと repository.xml というものがある。
このファイルに DB とクラスのマッピングを先に定義しておく。
作成にはツールを利用するなどする。
・方法論として二通りあるのではないか
・ER 図を描いて DB 固めてからクラス設計
・UML を書いてクラスから DB 作成
・DB の(スキーマの)方が Java のクラス設計より寿命が長いのでないか。
・"javax.jdo.*" パッケージなんてのがあるんですね。
-> JSR で定義された。jdk にはまだ入っていない。
p.393:
・スレッド内でトランザクションを管理 -> コネクションをスレッドに紐付けし
ている。
・JDBC でトランザクション処理を行う場合と比較してのメリットは?
-> 外部ファイル (repository.xml) で DB のテーブルとのマッピングが指定
出来るなら、それなりにメリットがあるのでは。
・EJB と比較すると、メリットがあまり無いように思える。
-> EJB の方が将来性はある。JDO よりは EJB で良いのではないか。
-> EJB の EntityBean が、JDO なみに容易に使えるようになれば良いのでは。
-> EJB もツールで簡単にできる。
-> JDO もシンプルなアプリケーションであれば、メリットあるのでは。
コンテナが無い環境でも使えるので。
・JDO の一番新しいページに行くと Sun のリファレンスインプリメンテーショ
ンがある。(http://java.sun.com/products/jdo/index.jsp)
■Item 47: Where's the WSDL? Pitfalls of Using JAXR with UDDI
WSDL:
・何が入っているか: エンドポイント, オペレーション, プロトコル
・CORBA の IDL のような物。
・これを取り出すための API が JAXR 。
ebXML:
・コンセプトベースのみ?
-> まだ途上でしょう。
WSDL 使ってる?
・.NET への接続するなら必要。
けれども、MS のは標準と型が違う? つながらない。
・結果がコレクションに入ってくると面倒。違うプラットフォーム間での利用は
難しい。
・Java Web Service Developer Pack を使うと WSDL のアクセスなどが出来る。
Table 47.1:
・引数がコレクション型だったりするので、何を渡してよいのかわからない。
・何が返ってくるかもよくわからない。型が色々あるので、なにがなにやら。
UDDI レジストリは誰が立ち上げる?
・誰が立ち上げても良い。
・RMI とか CORBA のネーミングサービスみたいなもの。
・Google が WSDL の一覧を返してくれれば良いのでは?
・UDDI レジストリ自体にも web サービスとしてアクセス可能。
Figure 47.1:
・ここでは実装 (realization) している形になっているけれども、現在ではそ
れぞれ interface になっている。
named URI: p.403
・名前と URI が対になってる。名前で検索(指定)できるような形で URI が保
持されている。
Listing 47.2:
・間違っている例 (pitfall の例)
・WSDL document を取得している箇所が 2箇所ある。
Service オブジェクトからと ServiceBinding からの両方で、WSDL document
の取得を試している。
p.404:
typo: 74 and 75 -> 75 and 76
Listing 47.3:
・サービスは取れているけれども、WSDL document の URI を取ることに失敗し
ている。
#getExternalLink() の呼び出しが値を返していない。
Listing 47.4:
・これでもまだ pitfall に落ちている。間違っている。
Listing 47.6:
・これは正しい例。
・こんな呼び出しが必要ということをわざわざ書くというのは、あんまり知られ
ていないのか?
・次の章の Dynamic Invokation Interface も参考に。
Listing 47.9:
・サービスが 4つ出てきているのは?
-> findConcepts で検索しているからだろう。
#これまでのは findOrganizations で検索。
Figure 47.2 も一種の pitfall に見える。
RegistryObject -> Classification -> RegistryObject と取得する必要がある
ようには見えない。
■Item 48: Performance Pitfalls in JAX-RPC Application Clients
p.427: (ここまでのまとめ的に)
・メソッド名がわからなくても実行可能なのか?
-> おそらく実行可能。
-> Listing 48.6 での "Call mycall" にはメソッドが格納されるのではない
か。これからメタ情報(引数とか)は取得できるのではないか。
-> できる。型情報などが取得可能。
-> Java Web Service Developer Pack に付属のリファレンスを参照のこと。
・型を動的に決めるのであれば、クラスローダが必要にならないか。
戻り値のオブジェクトの型などが未知である場合など。
-> 必要でしょう。
・DII (Dynamic Invocation Interface) で取得したものが、何をするメソッド
か、がわからないと動的に決めるうまみがないのでは。
というか、"何をする" という情報はどう扱うのか?
-> "何をする" という情報は、結局、人が判断しないといけないのでは。ユー
ザに提示して選択させるという意味で。
・(DII 経由だけでなく) Stub 埋め込みの場合でも同じではないか。
Stub の中に接続先の URL は入ってはいるものの、呼び出し先は切り替え可能
だから、(接続先の)実装が同じであれば接続先は切り替え可能。
-> では DII で実装が切り替え可能である、というメリットは?
-> 汎用な物を実装するのであれば必要でしょう。
Table 48.1: (速度比較の結果)
・WSDL のルックアップ結果を使いまわし(キャッシュ)できないのか。
・実験結果は回数ごとに速度が変わっていないから、キャッシュしていなさそう。
・キャッシュできればそんなに遅くはなさそう。
・仮にキャッシュできたとして、サーバ側が再起動したりした場合は?
-> HTTP なので大丈夫でしょう。
■Item 49: Get Your Beans Off My Filesystem!
Lisiting 49.1:
p.load(new FileInputStream(ファイル名決め内)); は最悪ですね。
クラスローダから読み込むとか、方法はあるだろうに。
p.431:
・実際には SessionBean の中で java.io.* は使うな、ということ。
・java.net.* でも実際にコネクションを張るものは不可。(URL クラスなどは
大丈夫)
#詳しくは EJB の仕様を参照のこと。
・ローカルファイルを扱うための、コンテナ依存の解法もある。
Listing 49.2:
・
でないとダメなのか?
-> Integer, Boolean などの指定も可。
-> Double はどうか?
・EJB の (SessionBean) 中で ClassLoader 経由でのファイル読み込みもダメな
のか?
-> I/O が発生する/しない による?
-> クラスローダ経由で読む場合、大丈夫ではないのか?
XML vs Properties File
・XML ファイルのメリット
・キャラクタコードの自由度
・木構造のデータ表現
・でも XML を DOM で(自前で)読むのは面倒。
-> ダイジェスタを使うとか。
・XPath はいつから使える?
-> XPath は重いからダメかも。
XML を扱うのに SAX はどうか:
・ちょっとだけ読むとか、簡単なルールで書かれているファイルを読むとか、な
ら、実用に耐える。それ以上は大変。
JAR ファイル中の DTD の読み込みに失敗した (XML の検証を行うときに):
・resolver を利用して読み込めば良いのではないか。
・Struts の struts config でも同じようなものが入っていてアプリケーション
サーバで動かないことがあったりした。
-> クラスローダの修正で対処した (Borland) 。(かリゾルバを使うか)
-> 一般的には解決? 謎。
-> XML ファイルに DTD を埋め込んでしまって逃げる。とか。
-> ひとつの XML ファイルなら簡単だが、複数ファイルで共有する場合は
困難。
■Item 50 When Transactions Go Awry, or Consistent State in Stateful Session EJBs
Figure 50.1:
・なぜ Activate, Passivate と表現しない?
callable = Activate した結果の状態
passivated = Passivate した結果の状態
・tx: transaction
・rollback の時は beforeCompletion() は呼ばれない、と書かれた本もある。
-> 実際には、rollback 時の beforeCompletion での処理は必要ない。なので、
コンテナの実装による、のではないか。
p.438: (The Memento Pattern)
・なぜか突然 Memento Pattern が出てくる。
-> 状態保持といえば Memento Pattern だからか?
・EJB ではトランザクション中に Passivate, Activate はしないので、この場
合では、トランザクション中のみ Memento が有効。
・コンテナによる rollback は DB のみが対象で、StatefulSessionBean 自身の
内部状態はコンテナが戻してくれないから、自分で戻る必要がある。
#JTA に参加しない StatefulSessionBean では。
そのため、この戻すための状態を保持するために memento を利用する。とい
う例でしょう。
・実際に使うか?
-> 試験にはでる。;-)
・フィールドをまとめる、フィールド数が多いならば有効。
インナークラスで実装するとか。(例もそう)
・コンテナがロールバックするタイミング
・システム例外
・setRollBackState が呼ばれたとき
参考資料のはなし:
・丸山先生の J2EE の資料はわかりやすいですか?
-> 割と良いです。
-> ボリュームがあるので、印刷は大変そう。1ページずつの印刷が面倒。
-> PDF 版がある。レクチャに出た人にはメールでお知らせがある、らしい。
■JDO の資料ネタ (WEB+DB PRESS vol.18 より)
現在は JDO 1.0 final release 2
リスト5: (p.64, pm.jdo)
・JDO のメタデータ -> マッピングファイル
・ツールによってジェネレートする。
トランザクション: (p.65)
・コンテナ管理のトランザクションサービスも利用可能
ツール:
・XDoclet, EclipseJDO
-> メタデータ作成ツール
■次の課題図書
1/31 に開催予定なので、それまでに決定する必要がある。
投票しましょう。
■その他の余談
EJB, WebService 関連の本:
Martin Fowler さんの新しい本が出た(る?)
(EJB, J2EE あたりのテーマ)
Willy の本
J2EE WebServices Design Pattern ??
J2EE Web Services
by Richard Monson-Haefel (Author)
Addison-Wesley
ISBN: 0321146182
Price: $49.99
http://www.amazon.com/exec/obidos/ASIN/0321146182/ref=rm_item
ヨタ:
・amazon.co.jp と amazon.com だと値段が違う。
・amazon.co.uk とも違う。
-> amazon の値段比較サイトとか、どうです?
[ 戻る ]