| 著作一覧 |
These terms only appear in links pointing to this page: XXXX
キャッシュのほうを見なければわからないからこれ結構ガックリする。
ここ2〜3週間ほど本業の負荷が高くてあまり物事を見ることができなかったが、久々にいろいろ情報を掻き集めていろいろ想起させてみる。
いろいろ読んだ感じから考えてみると、こんな図式が書けるのかなぁ？（バズワードのオンパレードだけど）
1.密結合→疎結合
極論すれば、EJBによる分散オブジェクトから、SOAによる分散サービス
どうでも良いが、どっちも「コンポーネント」なんだよね。
例によってDCOM→SOAPに対する後追い感をなんとなく感じるが。
2.プログラムから記述言語（うまい言い方がわからない）
JSF（というかELということになるのか）にしろBPELにしろ、脱プログラム言語（というか脱プログラマーと言うか）。こういうのは今まで絶対的には勝利できなかったわけだが。
#っていうか、ELがキーワードみたいだから記述言語で良いのかも。
#ホワイトホースもからんでくるな。
#追記：Groovyもここだな。
※1+2=EJB3.0？
今後3年で予測されるバジーなビッグウェーブは？
ずばり、非同期プロセッシング（のキャッチーな言い換え）でしょう。
MSのIndigo、IBMのESB（のどっかにあるサブシステム）。
で、思い出すのはRambus（綴りは例によっていい加減）の圧倒的な先進的なイメージで、システムバス上をメモリーコントローラとメモリーがパケットをバカバカ投げあうやつだ。
で、消えてなくなってしまったわけだが。少なくても見てくれ上は。どっかに生きているとは思うが。
コンセプトの先進性に対して、実装コストが追いつかなかったのだろうか。
非同期プロセッシングとはなんだろうか？
基幹系置き換えにマストな機能だ。
基幹系とは何か？
JCLを使って
（ファイル→プログラム→ファイル）＋ （この＋は正規表現の＋）
を並べていくことだ。途中で分岐もある。
ファイル→プログラム→ファイル[A-Z]
ファイルA→プログラムA→帳票A
ファイルB→プログラムB→ファイルb
ファイルC→プログラムC→帳票C
...
ファイルZ＋ファイルb→プログラムZ→帳票Z
というようにファイルの入出力でプロセスを繋ぐことだ。ここで帳票の代わりにWebベースのオンデマンド出力に置き換え可能なものはありうるわけだが、日計のようなものは、オンデマンドすることが本当に良いかどうか微妙になる。あと、レポートそのもののイミュータビリティ（なんて言葉はあるのかなぁ）が重要なものでは、印字しなければならなかったり（CD-RへのPDFでのファイル出力とかでも良いかも）。
この時、機能を単純にたとえばJ2EEで置換していく場合、既に存在する機能そのものをリストラクチャリングすることは移行負荷が高くなるため、単にテクノロジアーキテクチャのみの置換とすることは十分にありうる（もちろん、クリティカルな領域についてはビジネスアーキテクチャの見直し変更もありうる）。
ここでプログラムとプログラムの接続をファイルではなくオブジェクト（あるいはメッセージ）で結合していく（そのほうがアプリケーションアーキテクチャからは設計しやすい）ためには、プログラムZのように待ち合わせを行うプログラムが存在する以上非同期メッセージングが必須となる。
さらに極論していくと、各プログラムを意味単位にまとめてサービスとして構成していくことが可能となる。この場合、トリガーとなる行為（JOBの投入に相当）から見た場合、同期プロセッシングされてはむしろ困る。
追記：J2EEバッチプロセッシングという方法も選択枝としてはあり得るから、必ずしもメッセージングで繋ぐ必要は無い。が配備個所が複数になると運用障害の発生要因となり得ること、POJOをうまく使えばオンデマンド処理と基幹系更新処理でクラスの共用が可能なこと、クライアントが極少数なためDBサーバー＝アプリケーションサーバーとすることによるメリットが多いこと（特にハードウェア障害に対し）、メモリーは複数JVMの実行より1JVMおよびDBへのキャッシュに振り向けたほうが有効なこと、モニタリング対象のの集中、オンライン更新（移行する以上これは目玉となり得るわけだから外しようがない）、特に最後の点から、サービスはバッチから切り離してやる必要がある。
そのためには非同期プロセッシングがうまくできなければならない。
本来は、MDBの役割のはずだが。
なんか、EJBでMDBって人気が無いように見える。
非同期プロセッシングそのものが持つ設計ノウハウの広い意味での欠落が原因なのではなかろうか？ たとえば、まともな非同期プロセッシングの本の少なさが1つの証左かも。
で、Rambusだ。
ハードウェアで起きたことはソフトウェアでも起きうる。
その場合未来はどうなんのかなぁ、とか考えながら、おいらは非同期プロセッシングが大好物なんでにやりにやりしてれば良いのだが。
さすがに、ここまでまとまりが無いとメモ未満だな。
と考えていけば、（このジャンルに関して言えば）SOAがバズワードなんていうのはとんでもない話だ。
まさに、30年かけて構築したメインフレーム上の基幹系をオープンシステム（オープンソースじゃない。マクネーリの言葉の意味でのオープンだ）で再構築するためには、必須となる。
なぜなら、30年かけて作られたマニエリスティックなゴシック建築をモダーン建築に置き換えることに相当するんだから、一朝一夕にできるわけがない（と思う）。
途中で、システムをバラバラに分割して繋げていく必要が出てくる。
この再構築自体に5年かかると想定した場合、5年間有効で移行負荷が軽く設計がしやすく設計が単純で負荷予測が簡単で障害対応がそこそこ簡単でマルチベンダーでも問題が起きにくくフロントエンドコントローラの設計実装保守がしやすく誰でもノウハウがそれなりにあり安く買い叩ける……と考えていけばSOA（HTTPベースのメッセージング）の現実性は明らかだ。
誰もこの領域にMQ（IBM）やMSMQやRPCやORPCを想定する気にはならないだろう。
なんとなくアパートメントモデルという言葉を考えつく。各フロアを繋ぐのは階段とエレベータ、各部屋を繋ぐのは廊下。すべて枯れきってお釣りが来るような技術ですな。
追記：で、旧館と新館をつなぐ渡り廊下のことをストラングラーアプリケーションと言うのかな？ ある日、誰も旧館には足を踏み入れていないことに気付く。そこで渡り廊下を叩っ切って旧館を取り壊す。
と思った。たとえば反もいるわけで(Googleのトップ。まあ、トップにふさわしいかも知れない。概観できかつ主張も明白)、当然のように反あるところに正がある。僕が生まれるちょっと前からある。それも声高にある（あった？）。だからこそ反もあるのだが。
それが、そんな言い方は無いとか言われるとさすがにビックリしてしまう。そんなもんだ。
追記：「そんなもんだ」というのは便利なもんだ。まるでreturn null;
ジェズイットを見習え |
カート・ヴォネガット？ 「そういうものだ」とか「ハイホー」とかなんとか。決めゼリフというか決り文句というか。
いや単に村上春樹です（あまり自信は無いです。もしかしたら脳内妄想村上春樹かも）。そう言われてみれば僕はカートヴォネガットJrって読んだことないです。なんかチャンスが無かったというか。
そういえば、最初期の村上春樹はヴォネガットに影響を受けていると、どこかで読んだ気がしますが。脳内でかも。
どうせだから1冊くらい読んでおこうかなぁ。どれかお勧めはありますか？ （ちなみにケージのやつは気に入ってます。―シベリウスもそうでした、でもザンデルリンクのは見つからなかったけど――どうもありがとうございます）
「スローターハウス5」「猫のゆりかご」「ローズウォーターさん、あなたに神のおめぐみを」「ジェイルバード」あたりでしょうか。「スローターハウス5」は代表作ですが鬱すぎるです。一冊というなら、ローズウォーターさんでしょうか。
どうもです。題のかっこ良さならジェイルバードかなぁ。取り合えずローズウォーターさんを読んでみます。