議事録 / 第03回

３章 アーキテクチャ

アーキテクチャの構成要素

データアクセス層とEIS層

• データベースの使用は現実的には1つ
  • 2章で出てきたような気がする
• JCA
  • Java Connector Architecture (Connectionではない)
• JCA使っている人はいますか？
  • 使う予定だったが使っていない。レガシーとの連携に使おうとした。検証はしたが，既存に使用してたJCAの代替案のほうがパフォーマンスが多少優れていたため，それをそのまま使用した。一から作る場合はJCAの方が良いかもしれない

J2EEアーキテクチャ

EJBアーキテクチャ

"古典的"なJ2EEアーキテクチャ

• リモートEJBでスケーラビリティーを実現できるの？
  • スケーラビリティーのためではないが，SwingのGUIから使いたいために使用したことがある
  • リモートEJBによるクラスタリングはAPサーバー依存になってしまう (例：WebLogic?)
  • HomeでやるものRemoteでやるものなど色々
  • WebSphere?はファイルオーバーはするが，クラスタリングはしない(?)
  • リモート呼び出しはコストがかかりすぎ，ローカル比でおよそ100倍
  • ステートレスで100台以上並べないと意味がないのでは

• Webユーザインタフェース

• リモートクライアントのサポート

• 閑話休題
  • 「ディルバート」って？
    • アメリカのIT漫画(3コマぐらい)のツンツン頭上司
  • RodはEJBのパフォーマンス問題を散々指摘しているが，今のEntityBean?(2.0以降)は案外パフォーマンスは良い。DTO変換が面倒なだけ

ローカルEJBアーキテクチャ

• ローカルEJBを使用してる人はいるのか？
  • 太一さんはリモート
  • リモートなのだが同一層で同じJVM内だとローカル呼び出しに最適化される
  • ローカルにして，プレゼンテーション層・Web層でロードバランシングする

EJBアーキテクチャのバリエーション

• 「Core J2EE Patterns」の第2版持っている人いる？
  • VOがDTOになったり
  • 実際書籍を読んでいる人はいない
• 現在のEJBは実際にパフォーマンス自体はどうなのか？
  • 後述のMiddlename Companyの例をとる。EntityBean? 2.0だとパフォーマンス的に問題はない
  • ローカルEJBとDIコンテナを組み合わせる
  • EntityBean?を薄くする。データソースの取得もEJBに直接依存しないようにすれば，ビジネスロジックのテストも容易になる

非EJBアーキテクチャ

EJBを使用しないアーキテクチャ "軽量コンテナ"アーキテクチャ

• 実際Springとか使っている人いますか？Springには依存していませんか？
  • SpringのFactoryBean?を使用すると依存度が高まってしまう
  • SpringとHibernateを使用しているがSpring自体には特に依存していない。ただし，Hibernateには依存してしまうかも
• それ以外のメリット・デメリットはどうですか
  • Spring自体が複雑化している
  • フルセットのSpringはでかい(30MBぐらい)，ただし，コアは小さい
• Springを使うとメモリを食う？
  • ほとんどのサービスはSingletonなので，それほどメモリは消費しないはず

実践J2EEアーキテクチャ

リモートEJBによる"古典的"なJ2EEアーキテクチャ

• BMPとストアドプロシジャーの違いが圧倒的なパフォーマンス差を生み出した
• 初期のPet Storeを参考にした人いますか？
  • コードを読んで挫折した
  • 熱心かどうかは分からないが一通り読んだ
  • MacromediaのPet StoreをSeasarベースに移植するために読んだ
• BMP EntityBean?は使用したことがありますか？
  • CMPよりBMPの方が速かった時期があって使用したことがある
  • XMLからBMP Entityコードを生成するツールを使用していた

OTN J2EE仮想ショッピングモール

ローカルEJBアーキテクチャ

EJBアーキテクチャで共通の問題点

• 例外の扱い方に関して明確なポリシーを使って開発している人はいますか？
  • SQL Exception等ローレベルの例外はそのビジネスロジックなどレイヤーに適した例外に変換して再送出する
  • プレゼンテーション層までは例外はキャッチせず，最終的にキャッチしエラーメッセージと結びつける
    • ローレベルの(システマチックな)例外はエラーメッセージと一対多になるのでは？

• →その場合最初は変換せず，どうしても変換しなければならない例外の場合のみ途中の層で変換する

• 問題判別というタスクを定義し，その中で例外の取り扱いを検討する

• 例外とエラーメッセージの対応を取るには？
  • インハウスソリューションを使用したので，例外発生をコントロール可能だった。例外送出時に例外番号を付けて送出する

EJBを使用しないアドホックなアーキテクチャ

Sun Adventure Builder v 1.0 EA 3.1

• 有名なのこれ？
  • 知りません。オレンジニュースにも載ってなかった

iBatis JPetStore? v 3.1

• ソースが1/4はすごい
  • 元のソースもある意味すごい
• iBatisを使ったことのある人いますか？
  • 使ってました。JDBCでゴリゴリ書くより格段に楽。のち，Seasar1に乗り換え。
    • S2Daoの原型(→Secret)はiBatisを参考にしました
    • 今はS2DaoやHibernateの方が良い

全体的なコメント

"軽量コンテナ"アーキテクチャ：サンプルアプリケーション

• サンプルはないの？
  • 実際はある。Java Pet StoreのSpring + (iBatis)板，Pet Clinic(Spring + Hibernate or OJB)

必要なアプリケーションサーバーを決定する

• ちなみに使用しているのはWebコンテナ(Tomcat等)？アプリケーションサーバー(WebLogic?, WebSphere?等)？
  • 商用！！何でか分からないけど
  • Tomcat 4.1〜,5では結構早くて安定している
  • 商用の利点はEJBコンテナがあるかどうか，クラスタリングをサポートしているかどうか)
    • 全然使ってないけど高いほうがいい
    • →本当は(WebShpere?) Expressで十分なんだけど
• アプリケーションサーバーの修正時に起こる問題
  • Tomcatのセキュリティーホールは頻度が高いため，修正時にパッチを当てる頻度が高まり，その結果，運用がストップする頻度が高くなる
• Apache + Tomcat vs Tomcat単体
  • HTTPサーバーもTomcatに任せる場合，画像の転送の負荷が重くなり，パフォーマンスが落ちるのでは？
    • 実験してみた。実はあまり変わらなかった。

まとめ

• RodはDIコンテナを使用すると設計が良くなると言っているが実際は上(管理側)も下(現場の開発者)も納得させるのは大変
  • トップダウンでやらないと難しい
  • アーキテクト層は納得してくれる可能性が高い
  • ひがさん，俺が説明しても難しい

第４章 単純さの利点

複雑さのコスト

• XP有用性(その教えと実践)をプロジェクトでどのように活かしていますか？
  • J2EE開発でXPを導入するとどのようなメリットがあるのか？
    • J2EEとXPは特に関係はない。
    • (従来の)J2EEの開発はアーキテクチャドリブンだがXPはビジネスドリブンなので，アンチテーゼとなっている
    • →無駄なものは作らない
    • →テストしやすくする
    • →→DIと関係してくる
  • 今まではアーキテクチャ先行
    • XPだと「要求→コード＋テスト→その結果としてアーキテクチャ」
  • ここではテストティングのプラクティスについては触れていない

J2EEアプリケーションの複雑さの要因

複雑さのアーキテクチャ的要因

EJBの使用
オブジェクトの分散

• サーバー側でのドメインオブジェクトの関連構造の移動
  • ネットワーク間(レイヤー間)のDTO←→ドメインオブジェクトの変換にかかるコストを言っている

何故ビジネスオブジェクトを分散させるべきではないのか？

• 分散オブジェクトを用いることによるその他のメリットは？
  • ここ繰り返しているだけでしょう

分散とスケーラビリティ

• Webコンテナ層のクラスタリングはセッションコピーにかかるコストを考慮すべき
  • Stickyのロードバランサーともう一つ
• WebLogic?ではモジュールの変更がサーバー稼動中に可能で，ログオン中の(セッションが存在する)ユーザーは古いモジュールを新たにログオンした(セッションを開始した)ユーザーは新しいモジュールを使用するような設定が可能である
• ASP.NETでは完全にクライアントでセッション情報を持つ方法がある
  • JSFでもクライアントで持つ方法がある
  • J2EEでもバイナリを文字列化，暗号化した後クッキーorhideenに格納という方法を使ったことがある

フェイク：偽者分散オブジェクト

• EJB以外の分散(JavaRMI, CORBA, WebService?等)はどう？
  • WebService?はRMIに比べて更に遅い
    • テキストなのでデータ量が多い，さらにバイナリ←→テキスト変換がクライアントの両方で起こる
  • 速度比(小さいほうが速い)
    • EJB(100), RMI(70), WebService?(7000!!)
    • RMIが速いのは一部ネイティブ実行している
    • RMIの速度を決めるのはソケットの取り扱い(ソケットのオープン，クローズ，プーリング)だがJavaRMIはそれをうまく実装し，ユーザーに透過的になるように提供している。自前で作るのは大変

J2EEは分散のためのもの？
ゴールでないものに向けて：幻の要求

• 幻の要求はほんとうにあるの？
  • DBについては言われる(移植性)ことが多い
  • アプリケーションサーバーについても固有の機能を使わないようにするというのは一般的なのでは？

パターン病

• J2EEパターンの有用性についてはどう思いますか？
  • この問題はJ2EEパターンに限った話ではなく，パターン全般に言えること
  • それなりに一般に受け入れられているのでは？
    • でも駄目な奴も多い
    • GoFをJ2EEのコンテキストで解釈したものは有用。それ以外は有用ではない
    • (フレームワーク等ではなく)アプリケーションの中でパターンを使うのは局所最適化ではないか？

複雑さの文化的原因：複雑な産業

ベンダ主導アーキテクチャ

• アプリケーションサーバーはベンダ主導
  • 日立やBEAはEJBを薦めてくる
  • IBMのようにDBやハードで逃げられるメーカーはEJBを薦めてこない
  • エンドユーザーコンピューティングライクなGUIツールを持ってこられると厄介
    • 上層部が思わず反応し，勝手にそれを前提としてプロジェクトが始まってしまう
• 画面の遷移を定義するツールの是非
  • 遷移をGUIで定義するツールが多くなると管理不能になる
    • でもJSF版も登場している

ツールと複雑性

• モデリングツールを使っているところありますか？
  • Rose，コード生成もしている
  • Togetherのラウンドトリップは結構実用的
    • 依存の線がソースコード上のコメントとして保持されるので、コメントを削除すると、モデルが壊れる
    • コードと一対一で見れる意味が分からない
    • 今のモデリングツールは思考の道具ではなく，清書にしか使われていない
  • 清書の為に必要，設計の前にUMLの成果物を納入するフェーズがある
  • 本質的な価値はない。特に2Wayは
• CVS関連
  • CVSはディレクトリのバージョン管理ができないので，パッケージも含めたリファクタリングには妨げになる
  • ソースが特定の人のもの出ない場合，単純に共有できるほうが良い
• XP
  • モデリングツールはホワイトボード(しかも簡単にコピーし，共有できるように30cm程度)，本当に必要な場合のみツールを使えばよい
• ツール間の変換
  • RoseXDE→Visioは有用。
    • XMI対応のツールなら原則，変換はいらないので，ツール間の乗り換えは比較的容易

組織の迷い
People：人々
偽者のための単純さ
キャリア主導の開発
無干渉アーキテクト

• 皆さんはアーキテクトをどうとらえていますか？
  • 単に主任のAlias
  • なぜかそういう名前が必要
  • 明確な試験があり，基準等が存在する。条件を満たせないと剥奪される
  • プロジェクトの大きな石を取り除く役目
• 現場のコードを見ますか？
  • 見ます。機能等
• 現場での役割
  • フレームワークのカスタマイズしたり，ラッピングしたり
  • 名刺の肩書きを決めるときに適当に決めてます。システムアーキテクトでもシステムエンジニアでもやっている仕事は同じです
  • 火消し役がアーキテクト
    • 火消しではなく最初から入ったほうがうまくいくがプロジェクトの開始時には火消し役アーキテクトは他のプロジェクトで火を消しているため，最初から入れないという悪循環
• Rodはコンサルタントです
  • アーキテクトとはこうあるべしと押し付けている？

勢力拡大と他の政治的要因
単純さへの抵抗

どれくらいの複雑さ行き過ぎなのだろうか？

シンプル or ナイーブ

• ナイーブ
  • 「稚拙」であろう，「認識の甘い」という訳も

良いだけ？

変化の風

まとめ

次回について

• 5章(全員で拾い読み)
• 6章

この議事録を読んで分からないことや、疑問に思ったこと、その他ご意見等がありましたら下記コメント欄にお願いします。匿名でも結構です。