■ 寿司

私がどんなにお寿司が好きか知ってるでしょ！もしお寿司食べるなら、たくさん食べたいの！「ちょっと」なんてイヤ！だからお寿司を食べないことにしたのよ。これからは、私の前では「寿司」って言葉も使わないでね！

■ Ninja Uniform Black

via The Amazon guide to real real ultimate power ninja stuff

Amazon.com で忍者服が売ってる。

■ [WORK] XMLで出力されてもなぁ（ごにょごにょ）

……って言われて、んじゃー例えばこんなの作ればいいんじゃないすかねーって書いたのはいいが、なんか送るのは気が引けたのでヤメ。やっぱXSLT書いてあげたほうがいいのかな（嫌だ）。こんだけ書けばいいだけなのにね（誰に言ってるんだ）。

def user_defined_task(xml, target)
  require "rexml/document"
  include REXML

  doc = Document.new(xml)
  doc.elements.each('template/user/element-type/attribute') do |el|
    if el.parent.attributes['name'] == target
      puts el.attributes['name']
    end
  end
end

■ BPMがSOAの波でわーっと来た理由（スーツ向け）

こんな感じで書こうかなのメモ。社内用。

BPM（ビジネスプロセスマネジメント）は80年代くらいのバズワードだった。BPR（ビジネスプロセスリエンジニアリング）などと言われたりもした。それがなんでまたバズワード化してるのか。それには、Webサービスの台頭によるアプリケーションのサービス化（SOA化）が大きく関係している。

以前はアプリケーション層の個々のアプリケーション（レガシーやパッケージなど）が相互にデータ交換をすることは難しかった。しかし、アプリケーションにWebサービスのインターフェース（やり取りの契約）をかましてやることで、アプリケーション群を「サービス」という形で再定義できるようになった（サービス層の構築）。これがいわゆるSOAである。

このサービス層がない場合、ビジネスプロセスの各アクティビティはインターフェースの整っていない剥き出しのアプリケーションの直に触ることになる（サービス層を排除して考えてみよう）。アプリケーションが変更されると、このインターフェースも変更され、そうなるとアクティビティも変更され、とイヤンな感じ続出。一方、サービス層があれば、アプリケーション層を意識せずともビジネスプロセスを定義できるようになる。ビジネスプロセス層とサービス層のやりとりはXMLになりますよってに。

……というお話。くわしくは画を見れ。

Combining BPM, SOA, and Web Services『Understanding Soa With Web Services』Chapter 6. SOA and Business Process Management より

■ 続：orchestration vs choreography

定義によって違うんだバカヤロウ、という話だったが、いちおうの違いが見えてきた。明確な違いじゃないけど、だいたいこういう風に分けてねっていう感じ。まずは、企業内か企業外（B2B）かの違い。Orchestrationは企業内のサービス連携で、ChoreographyはB2Bの連携に使われる。また、参加者の違いもある。Orchestrationの参加者は（基本的に）単数だが、Choreographyの参会者は複数である（P2Pスタイル）。で、BPELはOrchestrationを主に扱う。

『Understanding Soa With Web Services』より