このブログの更新は Twitterアカウント @m_hiyama で通知されます。
Follow @m_hiyama

メールでのご連絡は hiyama{at}chimaira{dot}org まで。

はじめてのメールはスパムと判定されることがあります。最初は、信頼されているドメインから差し障りのない文面を送っていただけると、スパムと判定されにくいと思います。

参照用 記事

ハイパーメディア・アプリケーションをどう捉えればいいのか

先週は、URLやらハイパーリンクやらの話をしてました。僕の用語法がどうも杜撰〈ずさん〉で誤解を招いたキライがあります。言葉の説明を付け足しながら、少し抽象的に、「ハイパーメディア・アプリケーション」をどう捉えればいいのか? これについて述べたいと思います。

内容:

基本的な概念

「Webアプリケーション」、「Webサイト」、「Webサービス」、「Web API」とか、これらの言葉を区別するのは面倒なので、僕は区別してません。しかし、それぞれの言葉に特有の意味を想定している人もいるでしょうから、総称的に「Webシステム」ということにします。

Webシステムの基本は、HTTPによるリクエストとレスポンスです。レスポンスで返されたデータにハイパーリンクが含まれないようなWebシステムは、僕の興味の対象です。良い悪いではなくて、ハイパーリンクがないのでは面白くない、という個人的好みの問題です。ハイパーリンクを含むデータはハイパーメディアと呼ばれます。特に、個別性/個体性を強調するときは、ハイパーメディア・オブジェクトとかハイパーメディア・インスタンスと言うことにします。

ハイパーリンクは、ハイパーメディア・オブジェクトから出る矢印として図示できますが、問題は矢印の先は何か? です*1。「Webにおける参照にはURLを使うのだから、URLが指すモノ、つまりサーバー側のリソースだ」というのが一般的理解だと思いますが、僕はその解釈には反対です。が、ここで説明や議論に深入りしたくないので、詳細を棚上げして「サービスエントリポイント」という、ほぼ未定義な用語を導入します。サービスエントリポイントは、ハイパーメディアの矢印の先にあるものです。実体として何であるかには言及しません。ただし、サービスエントリポイントがURLと1:1に対応するとは仮定しないでください

ハイパーメディア・オブジェクトには、ハイパーリンクだけではなくて、もちろん通常のデータ項目を含んでもかまいません。例えば、あるリクエストに対して次のJSONデータが返ってきたとします。

{
  "familyName": "檜山",
  "givenName": "正幸",
  "uris" : ["http://www.chimaira.org/", "http://d.hatena.ne.jp/m-hiyama/"]
}

urisの値である配列項目達は、事前の合意に基づきハイパーリンクだと解釈できます。familyNameとgivenNameはハイパーリンクではありませんが、これもまたハイパーメディア・オブジェクトの一部です。

クラアント側の状態遷移

クラアント側の状態を、既存の用語「アプリケーション状態」で表そうと思ったのですが、「アプリケーション状態」にもなんか特有の定義と解釈がありそうだから、使うのやめた。ごく一般的な意味での、状態遷移系(オートマトン)をクライアント側のモデルとして使います。「状態(状態点)」、「状態空間」、「遷移」などは、なんのバイアスもかかってない普通の定義を採用します。

状態遷移系としては非決定性のモノを採用します*2。念のため確認すると、(V, S, t) が状態遷移系だとは、VとSが集合で、t:V×S→S が非決定性写像であることです。Pow(S) をSのベキ集合として、tは V×S→Pow(S) という写像だと言っても同じです。あるいは、tは V×S とSのあいだの関係、つまり t⊆(V×S)×S とも言えます。ここでは、t:V×S→Pow(S) の形だと仮定して、v∈V、s∈S に対して t(v, s)⊆S と考えます。

Vは状態遷移系の入力値(入力記号)の集合、Sは状態空間です。状態空間の要素を状態または状態点と呼びます。tは、遷移写像(非決定性であることに注意)、遷移関係、あるいは単に遷移と呼びます。

状態遷移系をオートマトンと呼んでもかまいませんが、入力値の集合Vも状態空間(状態の集合)Sも有限であることは仮定してないことに注意してください。

状態遷移系のチャンキング

大きくて複雑な状態遷移系を一度に定義するのは大変です。小さな部分に分けて、部分ごとに記述・定義していきましょう。分割統治(divide and conquer)の原理ですね。

(V, S, t) を状態遷移系だとして、添字(インデックス)の集合Iを用意します。Iは、現実にはすごく重要な意味を持つのですが、ここでは単なる添字集合です。i∈I ごとに、状態空間Sの部分集合 Si が定まっているとします。{Si | i∈I} は、S上の部分集合族となります。

集合族 {Si | i∈I} は次の性質を持つと仮定します。

  1. すべてのiについて、Si は空集合ではない。
  2. i ≠ j ならば、Si∩Sj は空集合である。
  3. すべてのiについて、Si 達を合併するとSになる。

つまり、{Si | i∈I} は、Sの直和分割を与えます。このことを、次のように書いてもいいでしょう。

  • S = Σi∈I Si

それぞれのSiを、状態空間のチャンクと呼ぶことにします。分割して統治されるべき小さな領土ということです。

入力値の空間も、各iごとにViとします。Vi⊆V ですが、これ以上の条件は付けません*3。さらに、K⊆(I×I) があるとして、(i, j)∈K ごとに、(Vi, Si, Sj, ti,j) が対応しているとします。

  • Si と Sj は状態空間のチャンクです。i = j であってもかまいません。
  • Vi は Si に対する入力値の集合です。Vi は前もって決まってますが、集合Viに対する条件は特にありません。
  • ti,j は、Vi×Si→Sj という非決定性の写像です。

各 (Vi, Si, Sj, ti,j) は状態遷移系の部品となります。これらの部品を貼り合わせると、状態空間がSである大きな状態遷移系を定義することができます。貼り合わせの詳細は割愛しますが、(Vi, Si, Sj, ti,j) を全部寄せ集めたら、状態遷移系 (V, S, t) が構成される状況を思い浮かべることはできるでしょう。

{(Vi, Si, Sj, ti,j) | (i, j)∈K} が貼り合わさって、大きな(大域的な)状態遷移系 (V, S, t) を構成するとき、{(Vi, Si, Sj, ti,j) | (i, j)∈K} は、(V, S, t) のチャンキングになっていると表現しましょう。各 (Vi, Si, Sj, ti,j) は、状態遷移系のチャンクです。

半遷移族から状態遷移系の構成

前節で、状態遷移系のチャンク達の族 {(Vi, Si, Sj, ti,j) | (i, j)∈K} が、大きな状態遷移系 (V, S, t) を定義すると述べました。別な素材から出発しても (V, S, t) を構成することができます。

別な素材とは、qi:Vi×Si→I という非決定写像の族です。現実との対応で言うと、qi がハイパーリンクの定式化になっています。ですが、ここでいきなり「ハイパーリンク」という言葉を使ってしまうと誤解や齟齬の原因になりそうなので、半遷移(semi-transition)と呼ぶことにします。

半遷移の族 {qi:Vi×Si→I | i∈I} があるとき、これからチャンクの族 {(Vi, Si, Sj, ti,j) | (i, j)∈K} を作ってみましょう。

まず、K⊆(I×I) を次のように定義します。

  • (i, j)∈K ⇔ j∈(qi の像集合)

ti,j:Vi×Si→Sj は次のように定義します。

  • ti,j(v, s) = Sj (どこにでも遷移可能)

いきなりこの定義を出されてもなんだかワカラナイかもしれませんが、次のような意味を持っています。

  1. Iはサービスエントリポイント全体の集合
  2. Siは、サービスエントリポイントiが戻す可能性があるクライアント状態空間の部分集合(状態空間のチャンク)
  3. qi:Vi×Si→I はハイパーリンク/ハイパーメディアの記述
  4. ti,jは、サービスエントリポイントiで生成された状態から、サービスエントリポイントjを経由しての遷移

ハイパーメディア・アプリケーション

ハイパーメディア・オブジェクトの集まりは、ハイパーメディア型を定義します。データ・オブジェクトの集まりがデータ型を定義するのと同じことです(ただし、Sets-as-Typesの立場)。ハイパーメディア型は、サーバー側からの出力(レスポンス)型という意味と、クライアント側状態空間/状態遷移系のチャンクという、二重の意味を持ちます。

最初、単なる添字の集合として導入された集合Iは、実際にはサービスエントリポイント全体の集合です。i∈I に対するチャンクSiは、サービスエントリポイントiの出力型であり、クライアントの状態空間Sの部分集合でもあります。そして、半遷移 qi:Vi×Si→I はハイパーメディアの特徴であるハイパーリンクの持ち方を記述しています。

以上のような枠組みを使って状態遷移系を構成しているソフトウェアを、ハイパーメディア・アプリケーションと呼びたいと思います。この枠組みには、直接にはHTTPもURLも登場していません。しかし、実際上はWebシステムになることがほとんどでしょう。サービスエントリポイントや半遷移も、Webの技術により実装されることになります。

ちょっと抽象的で実感が湧きにくい話だったかもしれせん。我々(Hiyama and Kuwata)のWebアプリケーションフレームワークCatyは、このようなモデルをメタプログラミングを通じて実現するインフラになっています*4。具体例や実際的な話は、いずれ、Catyを使った実装と共に伝えられるかと思います。

*1:矢印の根本〈ねもと〉は何か? もけっこう問題ですけどね。

*2:決定性ではうまくモデル化できません。

*3:Viが空でも特に問題はないのですが、空なViは取り去っても同じなので、「空でない」という条件を付けておいたほうが便利かもしれません。

*4:メタプログラミングを使わなくてもいいのですが、メタプログラミングを使ったほうが生産的で楽しいです。