日々の破片

_ これどーなったか知ってる人はいないかなぁ

当時、ふーんおもしろいなぁとか思って眺めていたものの、2000年前後は、COM−DCOM−.NETが中心だったし、そのうちすっかり忘れていた。こちらが知らないだけで、そこら中で動いている可能性が当然あるので、とっても知りたいんですが。

エージェント指向。

アンテナとかスパイダーはエージェントじゃないよね。いや、エージェントと言えなくもないか。いや、多分、エージェントだろうって気がしてきたな。スパイダーはともかく、アンテナはエージェント、本当?

クライアントがプログラムを送り込んでサーバーで動かすっていう意味じゃ、XMLでどかんと送り込んでお任せするサービス指向ってのは関連しているかも知れない。

XML Webサービスってのは、エージェント指向の成果なのか? もしかして。

スマートクライアントはエージェントか?

実装技術としてのアグレットってのは、どうなったんだろう?

_ リラクサー

なかなか、調子良い。最初DOMでやってみて遅いなぁ、だめかなぁ、と思ったものの、SAXオプション使って生成したハンドラを使えば許容範囲になったし。

こうなると、XSDをRELAX NGに変換するしか、と思ったら、結構記述ミスがあってコンバーターが通らない。人間コンバーティングするのが早いか、記述ミスを直すのが早いかがいささか微妙。

_ iBookの現在

妻の専用機になってしまっているのであった……

_ サービス指向

なんでオブジェクト指向でないかと言えば、送り込まれてきたメッセージは振る舞いを持たないからだ。もちろん、.NET間、Java間であれば、XMLシリアライズされた（単にSerializableとかISerializableを実装した）オブジェクトとしてアンマーシャルできるから、自分が持ってるデータを使って振舞うこともできるわけだが、そんなよそから入ってきたオブジェクトが傍若無人に振舞ったら、そりゃ、カプセル化の破壊ですな。ここでカプセル化されているのはドメインかな。

しかし、送られてきたメッセージが運んできたデータについては当然だが、受け手は知っている（知らなきゃ無視するーしたがってanyが出てくるわけだが）のが前提だから、受け手がそのメッセージ内のデータをもとに振舞う必要がある、というか、振舞うのがすなわちサービス。

これを額面通りに実装すると、イミュータブルオブジェクト（変更は呼び出し側に反映されない。なぜならば値渡しだからだ）に対して、ゲッタを呼んで、得たデータから自分の側をいじくって、またゲッタを呼んで……となって、Tell, Don't Ask原則の出る幕はないことになる。

そこで、このメッセージを1度、外部から来たオブジェクトとして、振る舞い可能なように服を着せてやることを考える。

すると、メッセージは魂で、服を着せると人間のように行動できるようになる、ってことになる。

サービス産業のメッセージは、心と心のふれあい、裸のおつきあい、ということですな。

たわけたことを（と一言付け加えたくなるよな、そりゃ）。

_ まだ続く

たとえばアクションフォームでもいいや。これだって、外部からやって来た値オブジェクト(DTOでもいいけど)だから。この中に買い物カゴに入るべき商品に対応するチェックボックスのチェックと、数が入っているわけだから、これを受け取った側で、

actionForm.pack(cart);

するほうが(お前さんの中身をカゴに詰めろ)、

 String itemId = actionForm.getItemId();
 int quantity = actionForm.getQuantity();
 cart.pack(itemId, quantity);

より本当ぽいんじゃないだろか。こっちは、目に見えぬ主役（アクション）が1度コンテナから荷を取り出して、こっちのカゴに入れてやるわけだから、確かにコントローラだからこれで良いのだと言う事は可能だが。

もちろん、

 cart.pack(actionForm);

でも良いかも知れないが、この場合、actionFormをcartに与えてはいかんだろう。でも、actionFormが、ShoppersHandsインターフェイスを実装していれば、

 ShoppersHands hands = (ShoppersHands)actionForm;
 cart.pack(hands);

で、それなりにさまになるかも。手の中のものを取り出せってことだ。

でも、このcartに命令するのって、結局、cartのpackメソッドでは、

 String itemId = hands.getItemId();
 int quantity = hands.getQuantity();

っていう買い物客の手に対するaskが走るわけで、いっぽう、最初のやつだと、

 cart.addLine(itemId, quantity); // itemIdとかはActionFormのインスタンス変数

という具合に、askはどこにも出てこない。きれいにtellだけで済む。

これはMVCモデルがオブジェクト指向の原則論にあってないってことではなくて（たとえばGUIアプリケーションであれば、入力は最初からコマンドオブジェクトにしておくことは可能だ）、間にネットワークが入るから値オブジェクト（DTO）が出てくるためだ。もちろん、カートはサーバー側のオブジェクトだから、ここでActionFormがクライアント側オブジェクトとして参照でやって来たらとてもまずいことになる。だから値オブジェクトになるのは全然OKなのだから、こいつをアンマーシャルする（ここではStrutsを無理矢理出しているから、アンマーシャリングとは思えないかも知れないが、url-encodedなストリームとしてマーシャルされたオブジェクトをアンマーシャルした結果がActionFormだと考える）時に、まっとうなオブジェクト（振る舞いを持つ）に変換できれば、良いのだな。

RPCだと、この外部からの値が、引数としてあらかじめアンマーシャルされて来るため（量に依存するけど）

public class Cart implements Remote {
  public void add(String id, int quantity) {
     ....
  }
}

となって、オブジェクトが外部から来るとは、それほど考えないで済むのだが、MBVとかDTOがクライアントからサーバーへ来るシナリオでは、ここに妙な断絶があって、いきなり、問い合わせが始まるのが興味深い。