WOMeeting2005/08
出席&発表してきた。
発表資料はこちら
WOMeeting発表資料 WOMeeting200508 - WOWiki
なんかやたらと眠かったので、飲み会はパスさせていただいた。 行った方がよかったかな？とちょっと思ったり。
Archive for WebObjects
WOMeeting2005/07
行ってきた。
Practical WebObjects読書会 Chap11 : XML
毎月恒例のPractical WebObjects読書会 今回のサマリは、Chapter 11. XML and WebObjects をTさんにお願いした。
内容は、XML技術の概要と、WOの持つXMLシリアライズ/デシリアライズ機能を使ったデモアプリケーションの説明 。
著者の用意しているデモアプリケーションの機能・意味合いがちょっと微妙で、XMLシリアライズ/デシリアライズ機能をうまく使ったモノでないため、実際にどのような方面でシリアライズ/デシリアライズ機能を使うべきかがイメージしにくかったようにも思う。 終わった後にTさんと話したのだけど、やっぱりWebサービスを絡めないとご利益が出てきにくいのかもしれない。
Seasar 2 for WO Developer
kakudaさんの発表。
kakudaさんのプレゼンテーションは、概念的なところの説明から、実際のDI動作のデモまでと、非常に準備に手がかかったすばらしいものでした。
試用レベルでも、DIを使ったことがあるのがkakudaさんと自分だけということに驚いた。WO屋さんは、やっぱり一般的なjava屋さんとは違うみたい（笑）。
皆、DIという概念を全く知らなかったのため、デモの説明を理解するのに苦労していたように思えた。やはり、最初は理解しにくいかもしれない。
ただ、私はWO屋さんにDIという概念をこの場でどうしても理解して欲しかったので、 （あえて）暴論気味に、「結局はファクトリですよ。DIというのは。」的な説明をした。 新しい概念を理解してもらうには、既存の似た概念を引き合いに出すのが手っ取り早い。 もちろん、あくまでも「似た概念」に過ぎないので、同じところもあれば、違うところもあるのだけど、 とりあえずのスタートとしては「ファクトリ」を引き合いに出して説明するのがよいと判断した。（その場では）
続けて、「ファクトリはコード内の条件分岐（かそれに類するもの）で生成する具象クラスを決定するが、DIは外だしにした設定ファイルで生成する具象クラスを決定する」という点を説明。微妙に嘘も歩けど、従来は「コード」で実現していたものを、「コンテナ＋設定ファイル」で実現しているという位置づけにしたほうがわかりやすかろうと、あえて言い切った。
また、kakudaさんのデモや、「WOにDIを適用するにはWOComponentのpageWithName()をオーバライドして、内部でS2Container#getComponent()を呼び出して云々」なる説明を通して、Seasarの特性である「インスタンスレベルのAOP」という概念も理解してもらえたようだし、よかったのではないでしょうか。うんうん。と自画自賛。
飲み会
まだ風邪が治っていないので、飲み会はご遠慮させていただいた。
WOMeeting欠席
欠席しちゃいました。 すんません。
WebObjectsのやたらと詳しい解説
WebObjects - Wikipedia, the free encyclopedia
エライ頑張って書いてあるな・・・。
WebObjects 5.3のライセンス情報
reBeLog ≫ WebObjects Licensing
via http://d.hatena.ne.jp/ogijun/20050608/p2
Development is no longer supported on any other platform. Deployment on any platform other than Mac OS X is no longer supported.
なるほどね。Windowsでの開発もサポートされないと。
Appleも思い切ったことするなぁ。まぁ、いつかこのときがくるとは思ってたけど。正直。
Displaying Subclass Attributes in WOBuilder
Displaying Subclass Attributes in WOBuilder
ふむ。
WebObjects 5.3リリース - EOModelerがXcodeに統合、HTML 4.0.1をサポート (MYCOM PC WEB)
WebObjects 5.3リリース - EOModelerがXcodeに統合、HTML 4.0.1をサポート (MYCOM PC WEB)
えーっと、Windowsは？
WOMeeting 2005/05
Practical WebObjects 読書会のみ参加。今月はChapter10. WebObjects In A J2EE World。
シンプルなアーキテクチャでServlet対応できてしまうところに、WebObjectsのスジのよさを感じるわけである。
ただ、あいかわらずマルチスレッド関係の処理に不安が残るわけである・・・。 WWDCに行かれる方は、Chales HillさんにEOEditingContextのLock問題について質問してきてください！(どうやらWWDC@SFにて、Pratical WebObjectsの著者がセミナーをやるらしい)
J2EE勉強会(仮)
J2EE勉強会(仮) - ひがやすを blog
参加してきた。
内容は、
Seasar2のJTA実装、コネクションプール実装をソースコード中心に追っかける JSFの特徴・アーキテクチャをPPTで説明する
でした。説明はすべてひがさん。お疲れ様でした＆ありがとうございました。
PoEAAとか
ロイホにしけこみ読書。
Essential XML・・・うーむどうなんだろう。ちょっと必要以上にわかりにくく書いてないか？この本。 訳が良くないというのもあるけど・・・（シリアライズを「順序化」って、あーた・・・。せめて「直列化」で頼む。） インフォセットの語りもなんだか抽象的でよーわからんし、SAX、DOMのあたりも構成が練れていない感じ。
PoEAA読書会に向けて、2部のパターン、O-Rマッピングあたりをさらりと読む。
1部の概論はイマイチしっくり来なかったが、2部はまぁまぁな気がする。 各パターンの説明の中で、未説明のパターンに言及するあたりがなんだかなーだけど、 各パターンの概要が頭に入ってきてパターン間の関係を頭の中で整理することができると、 比較的すんなり読めた。 ただ、ファウラーのコメントが散文的で踏み込みが甘いので、若干フラストレーションがたまるなぁ。 もう少し、具体的なコメントがほしいところではある。 現在は様々なフレームワークが出回っているわけだから、それらに触れるような切り口もありなのでは？と思ったりした。
EOFとPoEAA
パターンの本来的な役割は、共通の語彙・概念の形成であると理解している。 というわけで、PoEAAの語彙・概念を利用してEOFを表現する。（乱文すぎるので、たぶん、あとで書き直す）
ドメインロジックパターン
ドメインロジック(=ビジネスロジック) の割り当ての方針は、基本的に「ドメインモデルパターン」が推奨される。 もちろん、画面にビジネスロジックを埋め込むような実装・設計も可能ではあるけれども。
物理的にも、「ドメインモデル」を実装したオブジェクト群をパッケージ化・フレームワーク化して、様々なアプリケーション形態（WOFと呼ばれるリッチなWebアプリケーションフレームワークを使用したWebアプリケーション、DirectToWebと呼ばれるルールベースのUI定義ベースのWebアプリケーション、Javaクライアントなどなど）で、それらを共用することが(それなりに)一般的であるようだ。
データソースのアーキテクチャに関するパターン
データソースとオブジェクトの変換は、オブジェクトグラフとリレーショナルモデルの変換という形で実行される。 であるので、「データマッパーパターン」になるのかな？ オブジェクトとリレーショナルの対応は、物理的には*.eomodelファイル群、論理的にはEOModelGroup、EOModelなどのメタモデルクラス群で管理される。（「メタデータマッピングパターン」に相当）
オブジェクトリレーショナル振る舞いパターン
基本的に、「ユニット・オブ・ワーク パターン」。 EOEditingContextと呼ばれる、オブジェクトグラフの編集用ブール、SandBox的なオブジェクトが存在しており、これがオブジェクトグラフの編集状態を管理する。編集をコミットしたタイミングで、オブジェクトの編集処理が、SQLクエリに変換される（「データ・マッパー パターン」）。この際、デフォルトでオプティミスティックロック戦略が使用される・・・ことになっている。(苦笑&謎めき)
EOEditingContextの寿命とWeb層のSessionの寿命がシンクしている点がなかなかいい感じではある。 (超私見)
一意マッピング
異なる2つの世界、RDBMSとオブジェクトの中で、一意性をどのように、どのレベルで確保するか？という戦略。
EOFは一意性に関しては、2種類の一意性管理をもつ。 「ユニット・オブ・ワーク」単位の一意性と、データベース群レベルの一意性であり、EOGlobalIDなるクラスを用いることで一意性管理を実行する。EOGlobalIDは「データソース×テーブル×プライマリキーの組み合わせ」と考えてよい。文字通り、複数データソース内で、グローバルに一意である。
1つの編集用領域(EOEditingContext)には、同じEOGlobalIDのオブジェクトは1つしか読み込まれない。 ただし、複数ユーザーが編集中である場合など、複数の編集用領域が存在する場合、同じEOGlobaIDのオブジェクトが複数存在する。(当たり前！) ただし、下位のデータ管理レイヤがそれぞれのオブジェクトをトラッキングしており、あるオブジェクトが編集された場合、同じEOGlobalIDを持つ別のオブジェクトに変更を伝播させたり、しなかったりする。
レイジーロード
レイジーロードはfaultingと呼ばれる機構でサポートされる。 関連の先にぶら下がっているオブジェクトは、必要に応じてRDBMSから読み込まれる。 （キャッシュと絡むと何がなんだか・・・ということになりそうな気もしないでもない。）
構造パターン
一意フィールド
基本的にPKはoid的扱いが基本。オブジェクトのライフサイクルでPKの値を変更することは想定外!(だったと思う)
外部キーマッピング
外部キーというか、RDBのリレーションシップは、デフォルトでは(オブジェクトグラフにおける)双方向の参照の持ち合いに変換される。toOneは単なる参照に、toManyはコレクションに格納された参照になる。
アプリケーションは(基本的に)上記の仕組みを理解する必要が無い。参照の管理のみをキチンとやればよい。 (「データ・マッパー」の枠組みの中で自動的に行われる)
関連テーブル・マッピング
忘れた・・・
依存マッピング
「依存」という概念は無かったはず。
組込バリュー
メタデータの枠組みの中で、カラム→オブジェクト、オブジェクト→カラムのマッピング戦略を定義可能。 ファクトリメソッドと、シリアライズメソッドを定義しておけばよい(←用語は怪しい)
シリアライズLOB
上記と同様の考えて実現可能（な、はず・・・）
各種継承
用語は違うが、3つの継承をサポートする。 EOFの世界では、
垂直マッピング継承 水平マッピング継承 シングルテーブル継承
と呼ぶ。(つーか、こちらの用語の方が一般的?)
関連資料
自作のWOMeeting - WOWiki用の資料なぞ。
EOModeling Techniques from Practical WebObjects Managing the Object Graph from Practical WebObjects WebObejects/EOFでの継承モデリング
とか。
共通の語彙としてのパターン
うん、確かに便利かもねー。
Profile
渡部亮太 / Watabe Ryota
代官山在住のOracle Database Engineer。 株式会社コーソル所属。講演/講師業もぼちぼち。書籍「プロとしてのOracle運用管理入門」「プロとしてのOracleアーキテクチャ入門」買ってくれるとうれしいなっと。 twitter:wrcsus4
代官山在住のOracle Database Engineer。 株式会社コーソル所属。講演/講師業もぼちぼち。書籍「プロとしてのOracle運用管理入門」「プロとしてのOracleアーキテクチャ入門」買ってくれるとうれしいなっと。 twitter:wrcsus4
Book
Other Works
- Oracleトラブル対策の基礎知識（5）文字化けに関するトラブルに強くなる【基礎編】
- Oracleトラブル対策の基礎知識（5）文字化けに関するトラブルに強くなる【実践編】----UnicodeとJIS X 0213とサロゲートペア
- Developer's Summit 2009 講演 - プロとしてのOracleアーキテクチャ入門 ～ 番外編 ～
Certifications
- Oracle Master 10g Platinum
- Oracle Master 11g Gold
- Oracle Master Silver Oracle PL/SQL Developer
- Oracle Master Expert 10g RAC
- Oracle Master Expert Oracle on Linux
- LPIC level2
- CCNA
- 日商簿記3級
Contact
wrcsus4 _at_ gmail _dot_ comArchives
Recent Posts
- 9/30(金) Oracle LOVERS2 でお話させていただきました。
- フィルタ述語とアクセス述語 (実行計画の読み方#3)
- オペレーションの一覧と最低限覚えておくべきオペレーション (実行計画の読み方#2)
- JPOUGに参加させていただきました！
- 実行計画のツリーのたどり方 (実行計画の読み方#1)
Recent Comments
- WR blog » 9/30(金) Oracle LOVERS2 でお話させていただきました。 on SQLパフォーマンス問題調査でEXPLAIN PLAN、SQLトレースは（ほとんど）使わない
- WR blog » 実行計画の読み方 on 実行計画のツリーのたどり方 (実行計画の読み方#1)
- WR blog » SQLチューニングアドバイザの代用品としての動的サンプリング on DISPLAY_CURSORでCBOの見積りミスを簡単に確認する
- WR blog » DBMS_XPLAN.DISPLAY_CURSORの使い方とちょっとした落とし穴 on SQLパフォーマンス問題調査でEXPLAIN PLAN、SQLトレースは（ほとんど）使わない
- WR blog » 優れたカーソル共有があればバッチ処理SQLのリテラル化は不要か？ on 突然のSQLパフォーマンスダウンを防ぐためのバッチ処理SQLリテラル化のススメ