素人翻訳

 W. Keith Edwards 氏の「Session Management for Collaborative Applications」を読んだ。以下はその時のメモ。

★「Session Management」の定義
 ネットワークを越えて、協働状況(collaborative situations)を開始し、停止し、これに参加し、これから離脱し、あるいはこれを閲覧する処理のこと。協働状況とは、例えば、複数の利用者が共通のエディタを使って単一の文書を編輯している状況や、大勢の人間で行うビデオ会議など。

★１９９４年当時の問題
・セッション・マネジメントは各アプリケーションの下位システムとして実装されており、アプリケーションを作る度に車輪の再開発を行っている。
・セッション・マネジメント機能は各アプリケーションのおまけに過ぎず、作りが甘い。
・セッション・マネジメント機能が各アプリケーションに属しているため、全体(例えばある利用者のデスクトップ全体)的な機能の切り替えが出来ない。

★「application-centered」な実装から「environment-centered」な実装への移行
・個々のアプリケーションにセッション・マネジメント機能を持たせるのではなく、共通機能(shared run-time facility)とそれを呼び出す共通API(Common API)を用意する、という考え方が出てきた。
・これによってポリシーが実装可能になった。共通機能と共通APIのお陰で、同APIを使用するアプリケーション全てに対して、統制を加えることが出来るようになった。
☆アプリケーションのセッション管理から、デスクトップのセッション管理へ？？？

★セッション・マネジメントの２つのモデル
・「explicit session management」型と「implicit session management」型。
・アプリケーション中心の開発ではなく、環境中心の開発に適した新しいセッション・マネジメントのモデルは「implicit session management」モデルである。

★「explicit session management」とは何か
・明示的にセッションを創設する。
・セッションを命名し、その名前を利用者に広報する。
・明示的にセッションへの参加を表明したり、招待したりする。
・招待制(initiator-based)セッション・・・ある利用者が他の利用者を招待し、招待された利用者は参加するか否かを判断する。
・応募制(joiner-based)セッション・・・ある利用者がセッションを創設する。他の利用者はセッションの一覧を確認し、参加を申し込む。
・どちらもセッションの存在を告知するのに一手間必要。
・セッションの参加の申し込みも大変。
・セッションの初期費用が高い。
・セッション関連機能は、各アプリケーションにとって付随的で余分な機能に過ぎない。(この機能がアプリケーション内部に埋め込まれているなら)
・explicit なモデルでは、非公式の協働は為され難い。

★「"mediaspace" application」
・利用者等に直接通信を行わせるため、セッション管理の問題を全て避けて通ることができるという利点あり。
・「communication-oriented」なシステムならこれで良い。しかし、通信を目的としないアプリケーションにとっては、その種のアプリケーションを前提としたシステムは使いやすいものではない。
・そこで、通信を主としないアプリケーションのためのセッション・マネジメントの枠組みを作ることに意義が生まれる。
・これは、explicit session management を完全に置き換えるものではないが、同方式の苦手とする部分を補うものになる。

★「implicit session management」とは何か
・事情を知っている少数の集まりの場合は、大抵、招待や入場制限は必要ない。
・協働作業の対象物を開く動作そのものを以って、潜在的には協働作業が始まったものと見做す(協働作業の参加者の待合せが始まったと見做す)。例えば、複数の利用者が同時にあるファイルを開いたら、システムは協働作業が起こりうること(the potential for collaboration)を検知する。セッションの参加希望者は、開催中のセッションの一覧を確認する必要等は無い。
・協働の可能性とは次のようなもの。例えば、図書館の本の裏についている貸し出しカードを見て、そこに書かれている名前を確認した場合、確認者は自分と興味関心を同じくする人物に対して、協働作業を持ちかけても良いし、持ちかけなくても良い、というようなこと。待合せ(rendezvous)は、共有資源(共通の目的物)を利用する。
・「implicit session management」の利点は、明示的なセッション創設、セッションの命名、段階の確認(browsing phase通信の段階？)の手間(overhead)がかからないこと。
・explicit session management の「initiator-based」「joiner-based」に対して、「artifact-based」である。
・ここまで述べたことは、利用者視点から見た「implicit session management」の姿である。

★「implicit session management」の実装のために(その１)
・アプリケーションが自動的に implicit session management の機能の恩恵を受けられるようにするには、システム側から見て、どのような機能の実装が要るのか。
・アプリケーションの「activity information」をシステム側で取得できる必要がある。

★「activity information」とは何か
・ネットワークを跨いで実行されている作業の詳細情報。以下のもの。
・システム上に存在する利用者。
・利用者等が作業しているアプリケーションもしくはタスク。
・同アプリケーション・同タスクが操作・使用しているデータ・オブジェクト。

★「activity information」の識別
・利用者を一意に表す識別子を使用。
・アプリケーションを一意に表す識別子を使用。
・データの名前空間を表す「namespace identifier」と、その空間においてデータを一意に表す識別子「name」を使用。あるファイルシステムの中にあるファイル、あるデータベースの中にあるデータなど、データ・オブジェクトは意味空間(semantics of use and representation)を指定しなければ、一意に特定できない。

★「implicit session management」の実装のために(その２)
・セッションに参加したいアプリケーションは、「activity information」を公表・発行(publish)しなければならない。セッション・マネジメント・サーヴィスは、協働が起こり得ることを自動的に検知し、利用者やアプリケーションの設定に従って、適切な「action」をとる。
・利用者識別子、アプリケーション識別子、データ名前空間識別子、データ名識別子の組みで表される「activity」が複数観測され、その中の２つの「activity」でデータ・オブジェクトのトークン(名前空間と名前)が一致する場合、セッション・マネジメント・サーヴィスは、利用者が協働を始められるように準備する。例えば、２人の利用者の同一ファイルを操作していることが分かった場合、セッション・マネジメント・サーヴィスはこれを利用者等に告知する。利用者は、一方が声を掛け、他方が応じれば協働を始めることが出来る。
☆アプリケーションあるいは協働環境の附属機能として「policy controls」の仕組みが必要。「implicit session management」は透明なので、アプリケーションが自動的且つ強制的にセッションに参加させられないように、利用者が色々設定できなければならない。

★「Intermezzo」
・Intermezzo は、協働を支援する環境である。
・アプリケーション中心の開発ではなく、環境中心の開発に適した新しいセッション・マネジメントのモデルは「implicit session management」モデルであり、同モデルに則ってセッション管理を実装したものが「Intermezzo」である。