You can run the Oracle Universal Installer in either graphical mode or silent mode.

Fusion Middleware Installing Software with the Oracle Universal Installer

マジかよ。不便過ぎる…。
WebLogicのためにXを入れろというのか。サイレントモードなんて怪しいものはいきなり使いたくないし。GUIにしたからと言って別に便利になった訳でもないし。
そもそもサーバ製品なので機械にX端末ついてない事がしばしば。なのでどこかにXを飛ばさねばならぬが、昨今はセキュリティにやかましく、昔のようにxhost +してからDISPLAY設定するだけでスパッと手元のEWSの画面にemiclockが出る環境は稀。VNCを設定してからプロキシを経由してSSHポート転送…等々それだけで一苦労。客先に行ってこれが元でインストールできない事態も多いにあり得る。私などVNC Viewerでポート番号を指定すべきところ*1画面番号を指定して繋げずよく悩んだ。
返す返すもBEA Systemsは惜しい人を亡くした…。

Oracle WebLogic Server 11g構築・運用ガイド

posted with amazlet at 18.01.19

伊藤忠テクノソリューションズ株式会社 日本オラクル株式会社
翔泳社
売り上げランキング: 405,217

Amazon.co.jpで詳細を見る

20-22章
Strutsの後釜(になりたがっているらしい)。ちょっと微妙だな。Strutsの宜しく無い点は、URLとクラスの対応及びページ遷移をstruts-config.xmlに書くのが大変面倒くさいのとカスタムタグ暗記が大変点なんだけど、JSFもこれまたページ遷移をfaces-config.xmlに書いてカスタムタグ使うという…。殆ど一緒じゃないか。
Beehive netui流行らないかなー*1。

１６章/１７章
JMSの説明と、MDBじゃない単体APでのJMSプロデューサとJMSコンシューマの例。
JMSの良い点は通信の確実性だな。受信側の処理が正常終了してから始めてキューから削除されるんで途中でサーバが落ちても大丈夫。ただヘボい事すると「受信→処理失敗→また同じメッセージ受信→処理失敗」を延々繰り返すポイズンメッセージ。
・JMSプロバイダに対してキューからの削除指示は、AUTOだとOnMessageを抜けると同時に消え、CLIENTだとメソッドコールで明示するタイミングで消える。
・JMSプロバイダに対して複数メッセージ送信を１トランザクションに、複数メッセージ受信を１トランザクションにすることが出来る。ロールバック発生時は再度最小のメッセージ送信or受信からやり直し。
・他のDB更新等と一緒にグローバルトランザクションに参加することも出来る。

１７章はMDBのコードサンプル。
以下の２つの状態がある
１．アクティブ（＝メモリ上にプールされている状態）、２．存在しない。
管理はコンテナで不定期。生成、破棄の際に呼ばれるコールバックをアノテーションで指定できる。

１５章。１１章〜１４章のJPAは眠くなって仕方ないのでスキップ。
１．同期・要求応答型
２．一方向型
３．非同期/コールバック型
４．非同期/ポーリング型
があるよ、という常識的な話。
ちなみに私の好きなパターンは４。処理要求をHTTPで受けたらJMSキューに入れ、入れる処理成功を確認して200をリプライ。後ほどブラウザから処理結果画面を参照。と書いてみると実は２と１の組み合わせなのか。

１１章。長い。余りの長さと詰まらなさに１章分は読めず。つか私の経歴からすっぽり抜けているのがこのDB設計とファームウェア系。
11.1.1
・リレーションシップの実装はJavaのクラスとRDBとで異なる。概念や出来る事も微妙に異なる。
・JPAではエンティティクラスとテーブルとの対応をアノテーションで示す。リレーションシップもアノテーションで示す。
11.1.2
・リレーションシップのパターンには１．方向　２．多重度がある。
１．方向には単方向と双方向がある。
２．多重度には One-To-One Many-To-One One-To-Many Many-To-Many の４つがある。
具体例がP226に載っていて判り易いので参照。

１０章。
・DAOとJPAのコード比較が。JPAの方が微妙に短い、が、かなり似ている。
・JPAはコードとは別に定義ファイル(persistence.xml)が必要。META-INFに置く。
　JDBCドライバのクラス名とかDBへのログイン用情報とかトランザクション参加方法とか
・DAOパターンの場合は
　DAOクラス＝DBにアクセスしてDTOを返す
　DTOクラス＝ROW１つ分の情報
・JPAの場合は
　エンティティ操作クラス(＝DAOクラスに相当)。ユーザがプログラム。エンティティマネージャを呼んでエンティティを取得したり。
　エンティティマネージャがSQLを発行する。
　エンティティクラス(＝DTOに相当)
・リレーションシップの無いエンティティを使った例
・フィールドとカラムの対応は、エンティティクラスのアクセサメソッド前のアノテーションに記述する(XML定義ファイルではなくソースに書くのでこれは良い)。
・エンティティマネージャの取得方法は、
　１．コンテナ管理　２．ＡＰ管理の二種類。persistence.xmlに記述。
　EJB中で使うなら前者。サーブレットで使うなら後者が良い。理由はP207〜参照。エンティティマネージャはスレッドセーフではない。
・トランザクション
　１．JTAに参加　２．リソースローカルＴＸに参加　がある。persistence.xmlに記述。EJBなら前者が、サーブレットなら後者がよさげ。
・コールバックメソッド
　SQL発行する前後にJPAエンジン側から呼ばれるメソッド。
　DBへのSQL発行を契機に呼ばれる(SQL発行はJPAエンジンが色々まとめて最適化して行う)。INSERT発行前とかSELECT発行後とかいくつか。

うーむ、結構面倒そう。JPAは余り流行らなそうな予感。DAOでいいじゃんみたいな。エンティティオブジェクト/エンティティマネージャのライフサイクルやスコープで何かハマりそうな気がする。でもHibernateは流行りつつあるというし需要はあるんだろうな。

９章 O/Rマッピングの概要
JavaのオブジェクトとリレーショナルDBのマッピング、がO/Rマッピング
・自前マッピング
　・直接JDBCを操作　原始的
　・DAOパターン　現在メジャーな手法。永続化ロジック専門のクラスを噛ませる。
・自動マッピング
　・エンティティBean　イマイチ流行らなかった。
　・O/Rマッピングフレームワーク。　Hibernateとか。
・JPAは自動マッピングの仕組み
　エンティティBeanの後継でHibernateの影響を受けたPOJOベースの自動マッピングアーキテクチャ。
　JPAは仕様。実際に使うには「JPAエンジン」が必要。GlassFishに内蔵されたOracle TopLinkが一例。WebLogicのはBEA KodoでそれをApacheに寄贈してオープンソースにしたのがOpenJPA。