yojikのlog

yojikのブログです

ぶり祭り

tech

ぶり祭りに行ってきた。
特にid:t-wadaさんのRESTfulBuriに衝撃を受けた。これはすごい。自分が想定していたものよりもはるかにヤヴァイ代物だった。かなり強力な電波を受信した気がします。アンテナ立ちまくり。

あとでかく。書いた。
その日のお話の詳細は誰かが書いているはずなので、自分で理解したメモっぽいものを箇条書きスタイルで書いた。(間違いがあるかも)

ワークステートエンジンBuriについて

ワークステートエンジンとは
  • 状態を扱うエンジンなんだけど、状態遷移マシンモデルじゃない*1
  • データ(トークン?)がアクティビティという箱を動いていくイメージ
    • アクティビティとそれをつなぐトランジションを含むネットワーク全体がプロセス
    • アクティビティはコンピュータ処理を表すAutoとユーザの入力待ち状態を表すManual*2がある
    • Manualの箱の中にデータが滞在する
  • データを箱に入れることによってデータの状態を表す*3
    • 状態遷移とは箱から箱にデータを移すこと
    • 「箱」のイメージがのちのちRESTfulBuriを理解する上で役に立った
データと状態の分離
  • 状態をワークステートエンジンに管理させることにより「データ」がシンプルになる
  • データは状態に関連する項目(フラグとか)を持たずにすむ
    • よくある論理削除とかも実は特定の状態(箱)にデータを移すこと
    • 例えば社員マスタだったら論理削除フラグを立てるのではなく、退社の箱に移動する
  • データが複数にプロセスに参加することもできるし、新しいプロセスが増えてもデータのスキーマには影響しない(はず)
プロセスを中心としたドメインモデル
  • 「データ」「処理」「状態」の視点を分離して考える
  • 「データ」「処理」「状態」はプロセスに統合される
いろんな機能
  • プロセスのバージョニングなどBPMエンジンの本質的な機能は充実している
  • jPDLをグラフィカルに編集するエディタ(jaWE)がしょぼい(いまのところ)
  • プロセス監視の機能とかは存在しない(ぶりコンソールに期待)

RESTfulBuriについて

基本的にはBuriの上にアタッチしてつかうWebアプリケーション(でいいのかしら)

RESTとは
  • RESTとはアーキテクチャスタイル → 参照
  • そのインスタンスはROA(REST Oriented Architecture)
  • RESTで重要なのは「リソース」にURLを割り当てること
  • 何をリソースとすればいいの? RESTfulDAOなら(多分)データ
  • (基本的にはここはさらっと流してました)
RESTfulBuriでは、アクティビティがURLで表現されるリソースである
  • アクティビティにURLが割り当てられている
  • 先ほどの箱のイメージが重要になる
  • 箱(=アクティビティ)の中にデータがたまっている
  • 箱に対応するURLにアクセスして、データを読み書きする
    • 特定のアクティビティからGETすることによって、そこに留まるデータを見ることができる
    • 特定のアクティビティにPOSTすることによってプロセスにデータを流しこむ
    • 特定のアクティビティにPUTすることによって、プロセスのデータを変更する(?)
    • PUTとDELETEに関しては、実際どうなってるのか確認するのを忘れた
  • json表現やRSSによる表現を取り出すこともできる
  • (追記)あ、もちろん個々のデータにもURLを振られるのかな?

で、RESTfulだと何がうれしいの?

クライアントを選ばない
  • アクティビティにURLが割り当てられているため、ブックマーク可能!!
  • 自分が承認すべきデータが集まる箱(=アクティビティ)のURLを自分の好きなRSSリーダで購読出来る!!
  • RSSで取得したデータには、承認や却下といったリンクも埋め込まれている
  • デモではThunderbirdで承認、却下をやっていた
認証、認可の実装をシンプルにできる
  • 認証と認可の実装を、めちゃシンプルにできる(かもしれない)
  • 普通はアクティビティに対する権限などを実装するのは難しい
    • そこに製品に対する依存が生まれる
  • RestfulBuriの場合は、URLに対するアクセス制限(GET,POST)を行うだけ
    • つまり普通のWebページに対するアクセス制御の延長で、プロセス関連の権限関連の機能を実現できる
    • Apacheのフィルタとか、Servletのフィルタとか

上記コンセプトを支援する道具

  • RestfulBuriエディタ
    • グラフィカルなプロセスエディタでプロセスを定義し、インストールする
  • DynamicComponent
    • データの定義書から、プロセスを流れるデータに関するもろもろ(DAOとかDTOとか)を生成する
    • 実行時にソースを生成し、コンパイルして、デプロイする
    • レイヤのすべてを自動生成してしまう

これを使えば、数時間でバグトラッキングシステムのプロトを作れそうな気がする。
もしくは、キャバクラのねーちゃんが自身の顧客管理(CRM)を数時間で作って携帯で確認するぐらい、余裕で出来るのが理想とはぶさんが言ってました*4

感想

アクティビティはデータを入れる箱で、それがURL*5として、文字通り目に見える存在になっている。概念と表現の一致、メタファが扱いやすくて技術的にも有用であるという点に、OO厨な俺も大満足。なんというか、オブジェクト指向がかつて目指していたのは、再利用性とかメンテナンス性じゃなくてこういうことなんじゃないか、と思う。
RESTfulBuri単体で考えると超絶テクノロジで実現されたものでないことは想像できる*6。技術よりもアイディアの閃きが重要だしすごいなーと思う。もちろんMacのハードディスクがぶっ壊れてもゼロから作りなおす粘りも重要なのでしょう。
正直、ROAとSOAについて、もやもや考えていたのに、何も思いつかなかった自分がちょっとイヤになるくらい。コードを書かなきゃ。

*1:UMLなら状態マシン図じゃなくてアクティビティ図

*2:タイマーによる発火も含む

*3:分岐などがあれば、より複雑な状態を示す

*4:一部誘導と誇張あり

*5:で表現されるリソース

*6:基本的にはS2Buriのよび出しを行うServletなはず