WOMeeting2005/08

出席&発表してきた。

発表資料はこちら

* WOMeeting発表資料 * WOMeeting200508 – WOWiki

なんかやたらと眠かったので、飲み会はパスさせていただいた。 行った方がよかったかな?とちょっと思ったり。

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から読み込まれる。 […]