Domain Cross Over Services Markup Language

CroSSML : Domain Cross Over Services Markup Language
岩井将行
Masayuki Iwai ,
Graduate School of Media and Governance, Keio University
5322 Endoh, Fujisawa, Kanagawa 252-8520, Japan
[email protected]
Abstract
CroSSML （ Domain-Crossover Services Markup
Language）は、サービスメタ情報を XML で再
帰的に定義し、異種ドメイン間を相互に登録・
検索・利用を可能にする枠組みである。WEB
サービスの記述系 WSDL[11] と発見機構
UDDI[10] と異なり、サービスの不安定さを考
慮した Lease 機能や位置情報を柔軟に扱う機能、
アクセスコントロール機能を備えている。
ネットワークロボットやユビキタスサービスな
ど異なるドメインのサービス間を連携させるこ
とを目的としている。
本稿では異種ドメイン間接続するサービス発見
機構 CroSSML の概要について述べる。
1. CroSSML について
1.1 目的とシナリオ
CroSSML の目的はユビキタスサービスとの間の
ドメインを超えたサービスの相互利用を促進する。
以下にドメインを超えたサービス間連携の例を示
す。
9 (連携例 1)ユーザが歩いた軌跡をアクティブ
RFID や無線 Lan の電波状況により補足して
いるユビキタス測位サービスがある。いま
までに歩いた軌跡をその場のロボットに音
声通話により教えてもらう。
9 (連携例 2)ロボットはユーザ登録しておいた
行き先の地図と混雑状況をユーザに映像と
音声で通知する。映像は最も近くのディス
プレイに対して表示を依頼する。
9 (連携例３)ユーザが道に迷っているかどうか
をユーザのジャイロ端末から把握し、ユー
ザに近いロボットが行き先を音声でアドバ
イスする。
9 (連携例 4)ユーザが買い物の履歴、見たもの、
触ったものなどを手元の小型ＲＦＩＤリー
ダに実空間ブックマークしておく。情報
（或いは自分のプロファイル）の一部をそ
の場のロボットに預かってもらう。再度買
い物に来たときに以前に気になったものを
推薦してくれる。
(連携例 5)ユーザが小型のロボットと買い物
から帰ってくると、自動でドアを開ける。
同時にユビキタス屋内制御システムに命令
をだし。室内の温度や照明サービスに最適
にするようにロボットが命令をだす。
9 (連携例 6)ユーザが室内を暫く不在にするこ
とを屋内人感センサーが検知するとロボッ
トが電灯を自動で消灯する。さらに家族全
員外出したと屋内システムが判断するセキ
ュリティシステム作動と全部屋の消灯の機
能をロボットが実行し、窓の開閉をロボッ
トカメラで確認する。
9 (連携例 7)ユーザの携帯電話にその日あった
家庭内の出来事をロボットが写真つきで
Web にあげる。不審者情報、宅配便、ペッ
トの様子などは同時にメールする。
以上の様なシナリオを想定し、位置情報のシーム
レスなあつかいと異種サービス間の発見容易性を
考慮しながら CrossML を開発する。
9
1.2 定義
本稿で議論を進めるにあたって必要になる
ServiceSolid と Service の二つの言葉を以下のよう
に定義する。
SericeSolid とはＣ，Ｃ++,Java,C#などの言語で技
術され、そのランタイム上で動作するプログラム
の実体をさす。Socket(ある今さらに上位層のプロ
トコル SOAP,RMI[9])の追伸により他のコミュニ
ケーションが可能とする。実世界に対するセンサ
ーやモータなど影響力を持つ。 Service とは、
ServiceSolid の機能の部分集合を概念レベルで切
り出したものでひとつに ServiceSolid から複数の
Service が切り出すことも可能とする。
2
CroSSML の記述
CroSSML により Service がどのように記述され、
登録に利用されるのかを述べる。
(2-1)CroSSML の全体構成
CroSSML は head 部分と body 部分からなる。
<service xmlns:ss="http://www.CroSSML.org/def/service">
<head>
メタ情報,他の Service との連携方針
</head>
<body>
ServiceSolid に対するアクセス方法
Service 自身の内部の構成情報
</body>
</service>
つまりサービス記述は、CroSSML のディレク
トリ管理サーバ(CroSS サーバ)が保持するか一
定時間しか保持しない。
CroSSMLで記述されたService
CroSSML管理サーバ
(2-2)head 部分の概要
<head>

<ss:leasing></ss:leasing>

<ss:naming></ss:naming>

<ss:location
xmlns:loc:="http://www.CroSSML.org/def/loc"></ss:location>

<ss:auther></ss:auther>

<ss:launcher></ss:launcher>

<ss:description lang="ja-JP"></ss:description>
<ss:level> 2 </ss:level>

<ss:compositionControl
xmlns:rule="http://www.CroSSML.org/def/rule">
</ss:compositionControl>

<ss:authenticaction
xmlns:auth="http://www.CroSSML.org/def/auth">
</ss:authenticaction>
</head>
(2-3)body タグの概要
<body>

<ss:elementServices>
</ss:elementServices>

<ss:soloidAccess xmlns:access="http://access.definition.org">
</ss:soloidAccess>
</body>
以下に各タグの詳細を述べる。
(2-4)Lease タグ
サーバが管理するサービスの数が膨大になる可
能性がある。量的なスケールを実現させるため
Lease 機構を使う。Jini[12]の Lease 機構を参考
にしている。Lease とは限られた期間しか情報
を Directory に保持せず、Directory に半永久的
に情報を残したいときは Lease 更新を常に行う
ことが義務つけられる（図 1参照）。
ServiceSolid
Leaseによる管理
図 1ServiceSolidのLease更新
リース時間内は、サービス記述を CroSS サーバ
が保持する。
しかし、ServiceSolid の永続的な存在を信頼で
きないものとして一定期間しかサーバが保持し
ない。サーバは負荷が高くなるとリース期間を
短くする。
リースを依頼する場合は以下のタグにリースの
長さを記載する。
leaseTimeMinimum：
サービス側から最低限保証してもらいたいリー
ス時間
leaseTimeRequired：
サービス側が望むリース時間
サーバは leaseTimeMinimum＜実際のリース時
間＜
leaseTimeRequired の期間で
実際のリース時間を決定し ServiceSolid に通知
する。
(2-5)Naming タグ
名前付けに関するタグ。複数種類の名前を許
すが fullName,SerialID は全世界で唯一になる
ことが望ましい。
nickName：
fullName：名前体系のもとに決定
serialID：uuid,EPC
Abilities タグは Naming タグの一部である。
そのサービスが持つ機能一覧を表す。
communicator:speaking:Japanese
(2-6)Location タグ
….第 3 章で詳しく記載する。
(2-7)auther タグ
ServiceSolid の開発者の情報を記載する。
<ss:author>
<rdf:RDF
xmlns:rdf="http://www.w3.org/1999/02/22-rdfsyntax-ns#"
xmlns:foaf="http://xmlns.com/foaf/0.1/">
<foaf:Person>
<foaf:name>Masayuki Iwai</foaf:name>
<foaf:mbox rdf:resource="mailto:[email protected]" />
<foaf:depiction
rdf:resource="http://example.org/photos/tailor.jpg" />
</foaf:Person>
</rdf:RDF>
</ss:author>
(2-8) launcher タグ
サービスの起動した人の情報(2-7)と同様に記載
する。
(2-9)level タグ
Service 合成の Level(深さ)を表すタグである。
AotmicSerivice の Level は 1 になり
Level1 同士を組合せたものは Level2 になる。
Level2 と Level1 を組合せると Level3 になる。
構成要素の最大の深さ+1 で表記する。
(2-9) compositionControl タグ
合成に対する制約をつけるタグである。以下に
詳細を述べる
compositableServiceLevel
-合成可能なレベルの定義が必要な場
合に使用する。
compositableServiceAuthers
-合成可能なサービスの作者を限定す
ることが必要な場合に使用する。
compositableServiceLanchers
-合成可能なサービスの利用者を限定
することが必要な場合に使用する。
compositableServiceLocation
-合成可能サービスエリアを限定する
ことが必要な場合に使用する。
(2-10) soloidAccess タグ
ServiceSolid に対するアクセス方法
access:solidAccessGUI：WEB インタフェ
ースなどの GUI のポインター
access:solidAccessMethod ： XML-RPC[6] 、
RMI[9]、UPnP[7]、EchoNet[8]など他のサービス
からのアクセス方法を記載する。
3
CroSSML における位置情報
本章では CroSSML の位置情報の扱いの特徴につ
いて述べる。
3.1 存在位置の情報
静的位置情報（階層的な住所記載）としては一般
的な住所記載を用いる。しかし木構造として扱い
にくい位置情報は既存の研究成果[1,2]を今後取り
入れてもよい。
<loc:address contry="Japan" city="Fijisawa"
zipcode="252-8520">
<loc:street> 5322Keio-SFC</loc:street>
<loc:building>Delta</loc:building>
<loc:room>s213</loc:room>
</loc:address>
area="Endo"
GPS データを用いた記述
<loc:gps type="latitude" N="34.23.19" E="139.25.32"/>
動的位置情報の記載
頻繁に位置情報が変わるものには処理を追いつけ
るため、リアルタイム性を有する場合には位置情
報問い合わせ先を記載させる。
<loc:locationInformationServer
ref=http:// location..crossml.org/gps/?serviceid=12345677”>
3.2 影響範囲の情報
CroSSML では既存の位置情報を扱う記述形の研
究[3,4]にはない、
サービスが影響を与えることができる範囲を規定
する。図 2のように幾何学的に定義する。
例えばディスプレイでは背面にいるユーザは映像
をみるという恩恵を受けることができないため
back=0m になる。
Direct Mode
CroSSServer
SeriveA
ServiceB
(1)登録
CroSSML
ServiceSolid A
ServiceSolid B
front
(2)検索
四角形の影響範囲
(3)検索結果
(4)Direct Access
(N34.23,S139.25)
r
円形の影響範囲
図2
影響範囲の表記法
サービスの位置情報からの相対的距離で規定する
か絶対座標系を使って定義させる。影響を与える
範囲が動的に変わる場合は別に問い合わせ先を定
義する。
図3
ServiceSolidが直接サーバに登録
Indirect Mode では間接プロキシを経由してサービ
スを登録させる。
サービス間の通信はプロキシを経由して行う。
（図 4参照）
Indirect Mode
ServiceA
CroSSServer
ServiceFlowDB
ServiceB
WrapperServiceProxy
(1)登録
ServiceSolid A
(2)Wrapper
CroSSML
ServiceSolid B
(2)検索
(3)検索結果

<loc:serviceScope>
<!– 相対表記。-->
<loc:relativeScope type="square">
<loc:front>1m</loc:front>
<loc:back>0m</loc:back>
<loc:right>1m</loc:right>
<loc:left>1m</loc:left>
</loc:relativeScope>
<!– 絶対表記。-->
<loc:absoluteScope type="cirlce">
<loc:center>
<loc:gps type="latitude" N="34.23.19" E="139.25.32"/>
</loc:center>
<loc:radius>10m</loc:radius>
</loc:absoluteScope>
</loc:serviceScope>
4
(4)Indirect Access
(5)Access
図4
Proxyを介したサービス登録
サーバがない場合は Ad-hoc モードで動作する。
Service 側からマルチキャストパケットを定期的
に送信する。（図 5参照）
Ad-hoc Proactive Mode
ServiceA
ServiceB
(1)定期的告知(マルチキャスト、エニキャスト)
ServiceSolid A
CroSSML
ServiceSolid B
CroSSML の登録・発見手順
CroSSML の特徴として複数のサービス間の発見
と検索のモードを用意している。
Direct Mode（図 3）では個々の ServiceSolid が
直接 CroSSServer に登録する。別の SericeSolidB
は CroSSServer を発見後、Service 間で直接的に通
信を行う。
(2)Direct Access
図5
サーバを介さないad-hocモード
サーバを介さなくても、検索側から定期的に、あ
るいは任意のタイミングで問い合わせをするモデ
ル（図 6参照）がある。
Ad-hoc Reactive Mode
ServiceA
支払い、購入意欲、生活の改善
開発・販売
動作安全確認
利用
開発者
ユーザ
ServiceB
サービス
ServiceSolid A
(1)サービス検索(マルチキャスト、エニキャスト)
公開
ServiceSolid B
付加価値・収益
別のサービス
提供者
（2）CroSSML送信
図8
(3)Direct Access
図 6 検索者が任意のタイミングでCroSSML
情報の転送を要求
サービスの改竄を防ぐため、CA を置き、登録
Service の正当性を保障させるモデルを容易する。
（図 7参照）
Certificated Mode
CroSSServer
ServiceA
CA
Service B
(1)登録
ServiceSolid A
CroSSML
ServiceSolid B
(2)認証依頼
（３）登録許可
(４)検索
（５）クエリ認証依頼
（６）検索許可
(7)検索結果
(８)利用依頼/利用許可
(9)Direct Access
図7
5
署名モデル
CroSSML のアクセスコンロトール
CroSSML は認証機構の一部として３者間のアク
セスコントロール機能を有する。
ひとつのサービスには開発者、提供者、ユーザの
3 者が関わっているため、それぞれの立場からア
クセス制御可能なアクセルコントロールである。
３者間のアクセスコントロール
図 8で示したように Players は３人いる。
開発者とは Developers であり、サービスの実体を
開発した組織・人をさす。
提供者とは Launchers (Service Providers)であり
サービスをユーザに提供する組織・人である。
提供者は発者と同一の場合もある。
利用者はサービスを使うあるいは使おうとして
いるユーザ自身である。
各立場からのアクセスコントロールの必要性をの
べる。
開発者への制限
利用者にとって○○事務所が開発した製品
は利用したくない。
提供者にとって開発者が不明なものを顧客
に提供するのは控えたい
起動者（サービス提供者）への制限
開発者にとって、起動者を制限させ、お金
を払って利用している起動者のみにサービ
スを提供したい。
利用者にとって公共団体が運営しているサ
ービスなら安心して利用できる。
ユーザへの制限

開発者にとって
一定年齢以下のユーザには提供で
きない
安全のため一定人数以下に利用を
制限したい。
提供者にとって
料金をはらっているユーザのみに
サービスの提供を制限したい。
あるユーザの利用時間を制限した
い
アクセスコントロールタグの例
<authenticaction>
<auth:denyList>
<usersList></usersList>
<developersList></developersList>
<providersList></providersList>
</auth:denyList>
<authRules>
Rule ML[5] で様々な制約を記述
</authRules>
</authenticaction>
REFERENCES
1.
On a Location Model for Fine-Grained Geocast.
Dürr, Frank; Rothermel, Kurt: In: Dey, Anind K.
(ed.); Schmidt, Albrecht (ed.); McCarthy, Joseph F.
(ed.): Proceedings of the Fifth International
Conference on Ubiquitous Computing : UbiComp
'03 ; Seattle, WA, Oct. 12-15, 2003. Lecture Notes in
Computer Science; 2864, pp. 18-35, Springer-Verlag,
October 12, 2003. ISBN: 3-540-20301-X.
2.
Information Management and Exchange in the Nexus
Platform, Bauer, Martin; Dürr, Frank; Geiger, Jan;
Grossmann, Matthias; Hönle, Nicola; Joswig, Jean;
Nicklas, Daniela; Schwarz, Thomas:.
University of Stuttgart : Special Research Area SFB
627 (Nexus: World Models for Mobile Context-Based
Systems), Technical Report No. 04.58 pages
3.
Road Web Markup Language (RWML)
4.
NaVigation Markup Language (NVML)W3C Note 6
Aug 1999 http://www.w3.org/TR/NVML
Minoru Sekiguchi, Fujitsu Laboratories Ltd.,
5.
RuleML Rule Markup Language Initiative,
http://www.ruleml.org and
http://www.mit.edu/~bgrosof/#RuleML.
6.
xml-rpc XML-RPC Specification Tue, Jun 15,
1999; by Dave Winer.
Updated 6/30/03 DW
SOAP Simple Object Access Protocol
W3C Note 08 May 2000
http://www.w3.org/TR/soap/
7.
UPnP Universal Plug and Play. http://www.
upnp.org/.
8.
Echonet ECHONET Consortium http://www.echonet.gr.jp/
9.
RMI A. Wollrath, R. Riggs, and J. Waldo, “A
Distributed Object Model for the Java System,”
USENIX Computing Systems, vol. 9,
November/December 1996.
10.
UDDI Universal description discovery and
integration (UDDI). http://www.uddi.org, 2001.
11.
WSDL Web service description language
http://www.w3.org/TR/wsdl Erik Christensen,
Microsoft W3C Note 15 March 2001
12.
Jini J. Waldo. The Jini architecture for networkcentric computing. Communications of the ACM,
42(10):76–82, Oct. 1999.

Download Report