Linked Data を用いたサービス連携アーキテクチャの提案と評価
M2011MM041 小島 弘誉
指導教員 青山 幹雄

1. はじめに

5. 二層LDAの提案

クラウドなどのサービスをブローカで連携する方法が注目されているが，連携には大量のデータを扱えるスケーラビリティが求められている．本稿は Linked Data を用いた連携アーキテクチャを提案する．サービス連携を制御と処理の二層に分け，Linked Data で振舞いを制御することにより，非集中な連携を可能とする．これにより，スケーラブルなデータ連携を実現する．

5.1. 二層LDAの構造
二層LDA の構造を図2 に示す．メタレイヤで連携の制御，ベースレイヤで連携の処理を行う．

2. 研究課題
2.1. スケーラブルなデータ連携が困難
不特定多数のサービス連携では，連携に参加しているサービスの負荷がブローカに集中する．これにより，スケーラブルなデータ連携が困難になっている．
2.2. クラウドサービスの疎結合な連携が困難
不特定多数のサービス連携では，連携参加者の時間，位置，状態によらずデータを送受信する必要がある．

3. 関連研究(1) ESB(Enterprise Service Bus): SOA(Service-OrientedArchitecture)に基づきエンタープライズ全体のサービス統合を実現する技術である[1]．
(2) Linked Dataを用いた技術連携: セマンティクスの違いに対して，Linked Dataを用いて多様な設計データを連携する研究がされている[4]．

4. 連携アーキテクチャのアプローチ
連携を制御と処理の二層に分け，Linked Data で振舞いを制御するアーキテクチャにする(図 1)．このアプローチをとることでブローカへの負荷の集中を各クラウドサービスに分散させ，負荷が非集中の連携アーキテクチャを実現する．
これを二層 LDA(Linked Data Architecture)と呼ぶ．
制御層
Linked Data

ブローカ

Linked Data

処理層
サービスA
リソースリポジトリ

HTTP GET http://…/image
画像

サービス
B

図 1 提案のアプローチ
制御層はPublish/Subscribe Architecture(以降PSA)[2]に基づき連携参加者の時間分離，空間分離を可能とする．処理層はリソース指向に基づきデータ交換することで連携参加者の状態分離を可能とし，疎結合な連携を実現する．

メタレイヤ

問い合わせ サービスブローカ
購読登録(2)購読管理サービス
参照
登録/参照
フィルタリング
データモデル
購読情報
サービス
配信
挿入
(3)Linked Data マネージャ(通知用)
リクエスト/
挿入
レスポンス(3)Linked Data マネージャ(リクエスト/レスポンス用)

ベースレイヤ Linked Data配信
リソース
リポジトリ
配信者

(1)Linked Data
配信サービス

リクエストレスポンス

データ取得(4)グラフ操作
サービス
サービス
購読者

図 2 二層 LDA の構造(1) Linked Data 配信サービス
リソースを指定する Linked Data を配信する．配信される Linked Data は次の二種類ある．(i)配信者のリソースリポジトリで保持しているデータを指定する Linked
Data と(ii)配信者以外のサービスのリソースリポジトリで保持しているデータを指定する Linked Data である．
(2) 購読管理サービス
購読者の情報を管理する．購読登録では購読者のエンドポイント，取得するLinked Dataの条件，振舞いが登録される．
(3) Linked Data マネージャ
購読者の振舞いに合わせて Linked Data を配信する．
購読者の連携パターンには通知型とリクエスト/レスポンス型がある．通知型は全ての購読者のLinked Dataを一つのメッセージキューで管理して配信を可能とする．リ
クエスト/レスポンス型では任意のタイミングでの配信を可能とするため，配信者毎にメッセージキューを用意し，管理する．
(4) グラフ操作サービス配信されたLinked Dataから取得したいデータのURIを抽出する．
5.2. 二層LDAの振舞い
複数の購読者と複数の配信者のデータ交換を例に二層LDA の振舞いを図 3 に示す．配信者(サービス X)，購読者(サービス A，サービス B)を記述する．購読者は異なる振舞いを持つサービスである．サービス A はリクエスト/レスポンス型，サービス B は通知型のサービスである．また，サービ

ス Y はサービス X が配信した Linked Data が指すリソースリポジトリを保持しているとする．
購読者
サービスブローカ
配信者
サービスA サービスB 購読管理 フィルタリング Linked Data サービスX サービスY
サービスマネージャ
サービス
メタレイヤ

購読登録
購読登録

購読情報
取得

Linked Dataの配信
フィルタ
登録

ベースレイヤグラフ
操作

Linked Dataのリクエスト
Linked Dataの配信
データのリクエスト
グラフ
操作

Linked Dataの配信データのリクエスト

図 3 二層 LDA の振舞い
5.2.1. 全体の振舞い連携全体の振舞いを説明する．
(1) 購読登録
購読者のサービス A，サービス B が購読登録する．
(2) Linked Data の配信
配信者のサービス X がサービスブローカに Linked Dataを配信する．
(3) Liked Data マネージャへの登録
サービスブローカは購読管理サービスから購読情報を要求し，取得する．購読情報が記述されている情報に従って Linked Data をフィルタリングし，Linked Data に購読者の振舞い，配信時間，購読者の宛先などを指定して，購読管理サービスに登録する．
(4) Linked Data の配信
サービス A のようなリクエスト/レスポンス型のサービスの場合は購読者から Linked Data を要求し，Linked Data を取得する．そして，グラフ操作サービスを用いて Linked Dataから要求する URI を取得する．その URI を用いてサービスX のリソースリポジトリにアクセスし，データを取得する．サービス B のような通知型のサービスの場合はサービスブローカから購読情報に記載されたトリガに従って Linked Dataを配信する．
(5) データの取得
グラフ操作サービスを用いて，Linked Data から要求するURI を取得する．取得した URI を用いて，サービス Y からデータを取得する．サービスYはLinked Dataを配信していないが，サービス X が配信した Linked Data がサービス Yのリソースリポジトリを指しているために，サービス Y のリソースリポジトリにアクセスし，データを取得する．
5.2.2. 二層分割による効果
連携アーキテクチャを二層に分けることによる効果をメタレイヤ，ベースレイヤに分けて示す．
(1) メタレイヤ
メタレイヤでは連携参加者が疎結合な連携を可能とするために振舞いの制御を行う．疎結合な連携を可能とする二つの性質を示す．
(a) 空間分離
連携参加者はお互いの位置を知らなくても連携することを可能とする．ブローカが連携参加者のエンドポイントを管理し，登録された購読要求に従って，Linked Data を配信するため，連携途中で配信者や購読者のエンドポイントが変更されても，連携が可能である．
(b) 時間分離
連携参加者は Linked Data の配信，取得を任意のタイミングで行うことを可能とする．ブローカは配信された Linked Data をメッセージキューで保持するため，Linked Data を任意のタイミングで連携することが可能となる．
(2) ベースレイヤ
ベースレイヤでは異なるリソースリポジトリに配置されたデータをリンクさせた Linked Data を用いてデータを取得する．それにより，データ交換の分散とデータ保持の分散を可能とし，負荷が非集中の連携を実現する．
(a) データ交換の分散
購読者が Linked Data の指すリソースリポジトリから直接データ交換する．そのため，不特定多数の連携
でも，ブローカに負荷は集中せず，購読者とリソースリポジトリを保持するサービスに負荷分散する．
(b) データ保持の分散
二層LDAではブローカがデータを保持しない．データは配信者，または，リソースリポジトリを保持しているサービスに配置されるため，ブローカに集中していたデータ保持の負荷を配信者と他のリソースリポジトリに分散させることが可能となる．

6. プロトタイプによる実証
6.1. プロトタイプの構成と実現
実装したプロトタイプの構成を図 4 に示す．
配信者
Linked Data
生成サービス 配信サービス
Apache Jena Apache CXF
jetty
購読者
購読登録
グラフ操作
サービス
サービス
Apache CXF
jetty

Linked Data

サービスブローカ
購読管理
サービス

フィルタリングサービス

Apache CXF
Linked Datajetty
PC2 (CPU Pentinum2GHz, メモリ1GB）
Webサイト

データ取得
サービス
Apache Jena

PC1 (CPU CORE i3 1.8GHｚ, memory 4GB）

.pdf
.pdf

.pdf

.pdf

ApachePC3 (CPU Pentinum1.6GHz, メモリ2.5GB)

図 4 二層 LDA プロトタイプの構成
連携時間を正確に計測するため，配信者と購読者は同じPC 上に配置した．ネットワーク遅延などで連携時間の計測結果に影響を与えないため，全てのアクタを同一のネットワ

ーク上に開発した．プロトタイプの実行環境を示す．
(1) サーバソフトウェア
配信者，購読者，サービスブローカにはサーバソフトウェ
アに Jetty 2.7.1 を用い，Web サイトには Apache 2.0.64 を用いた．近年，Web サービスは Apache Maven などのプロジェクト管理ツールを用いて開発される．その際にはサーバソフトウェアに Jetty を用いることが一般的である．また，Webサイトではサーバソフトウェアに Apache を用いることが一般的であるため，Apache を用いた．
(2) Web サービス
Web サービスは Apache CXF 2.7.1 を用いて開発した．
Apache CXF には PSA を実現するライブラリが用意されているため，Apache CXF を用いた．
(3) Linked Data 処理機能
Linked Data 処理機能は Apache Jena 2.9.3 を用いて開発した．プロトタイプでは Linked Data を作成する機能とLinked Data から要求する URI を検索する機能を開発する必要があったため，SPARQL のライブラリが用意されている
Apache Jena を用いた．
6.2. 適用ユースケース
二層 LDA を定期購読ユースケース(図 5)に適用する．
アクタは執筆者，編集者，e コーマス，購読者の四つである．
編集者は Linked Data を用いて三人の執筆者の情報や原稿のデータを管理しているとする．執筆者は画像や PDF ファイルなどサイズの大きいデータを保持し，それらを Webサイトで公開しているとする．
定期購読
Linked Data
Linked Dataのリクエスト
時間指定の管理<<include>> <<include>> データ取得
トピック指定
編集者

執筆者

購読登録
Linked Data
データの公開の通知<<include>>
データの保持レスポンス処理
タイムトリガ
データの編集購読者

eコーマス

トに三回データをリクエストしている．
購読登録
サービス

rdf: type
http://JavaBook
ldp:Container
rdfs:member
rdfs:member
rdfs:member
http://169.254.135.16/section3.pdf
http://169.254.135.16/section1.pdf
dc:title
dc:title
dc:title
http://169.254.135.16/section1.pdf
多態性
Hello World
カプセル化

図 6 Linked Data の構造
6.4. プロトタイプの振舞い
プロトタイプの振舞いを図 7 に示す．ユースケースではLinked Data が三つのファイルを指しているため，Web サイ購読者
配信
Linked Data
サービス 生成サービス

購読登録
購読情報取得Linked Dataの配信

Linked Data
配信要求

執筆者

フィルタ

通知登録
通知取得

Linked Dataの配信
URI
抽出

URIの送信Section1.pdfのリクエスト

pdfの保存Section2.pdfのリクエスト

pdfの保存Section3.pdfのリクエスト

pdfの保存図 7 プロトタイプのシーケンス図6.5. 連携時間の計測
データサイズを 1KB，25KB，50KB，100KB，200KB と変更し，連携時間を計測した．Linked Data を 3,000ms 間隔で100 回送信して全体の連携時間を計測した．計測結果を表1 に示す．全体の連携時間とは配信者が Linked Data を配信してから，購読者がデータを取得し，保存するまでの時間である．
表 1 計測結果
データサイズ(KB)

1平均連携時間(ms)74.61 112.68

183.6 385.88

424 1094.09

8.93

8.74

86.21

標準偏差

2550

11.26

100

19.77

200

500

140.52

7. 評価と考察
7.1. 関連研究との比較によるスケーラビリティの評価
二層 LDA と PSA を比較することでスケーラビリティを評価する．例として共著の文書や画像アルバムなど複数のデータの配信を想定して振舞いとデータ配置の差異を図 8 に示す．
(b) 二層LDA(a)PSA

図 5 定期購読ユースケース
6.3. Linked Dataの構造
Linked Dataの構造を図 6 に示す．ユースケースに基づき，三人の執筆者が共著の本を執筆することを例にLinked
Dataを定義した．構造はLinked Data Platform[3]に基づいている．

編集者
eコーマス
グラフ操作 データ取得 購読管理 フィルタリング
サービス
サービス サービス サービス

制御層 Linked Data

リソース
リポジトリ

サービス
ブローカ

サービス
ブローカ

Linked Data

処理層配信者

購読者

購読者

配信者

リソース
リポジトリ

リソース
リポジトリ

リソース
リポジトリ

サービスA

サービスB

サービスC

図 8 各アーキテクチャの振舞いの比較
各アーキテクチャにおける連携全体の負荷をデータ交換，データ保持の観点から比較する(表 2)．
表 2 各アーキテクチャにおける負荷の比較
振舞い

データ配置

(a) PSA

アーキテクチャ

ブローカに集中

ブローカに集中(b) 二層 LDA

サービスに分散サービスに分散

(a)PSA(b)二層LDA
制御層

配信者

T2

サービス
ブローカ

T2

サービス
ブローカ

Linked Data

T1
リクエスト
購読者
T0

T1

購読者
処理層

配信者
T2

図 9 連携時間の比較(b) 計測結果の比較による連携時間の評価
提案プロトタイプと PSA プロトタイプの計測結果を用いて，静的な評価が正しいことを確認する．データ
サ イ ズ を 1KB ， 25KB ， 50KB ， 100KB ， 200KB ，500KB と変更し，連携時間を計測する．Linked Data
を 3,000ms 間隔で 100 回送信して平均の連携時間とその近似式を求めた(図 10)．
5000

連携時間

(1) 振舞いの比較
PSA ではブローカを介してデータ交換を行う．そのため，データ交換がブローカに集中する．しかし，本研究が提案する二層 LDA ではブローカを介さずデータ保持者と直接データ交換する．そのため，データ交換が各サービスに分散する．
(2) データ配置の差異
PSA では連携する全てのデータを一度ブローカに保持する必要がある．そのため，データの配置がブローカに集中する．しかし，二層 LDA ではブローカがデータを保持する必要はない．また，Linked Data を配信するサービスは必ずしもデータを保持する必要はなく，配置の異なるソースリポジトリ指すLinked Dataを配信することが可能である．そのため，二層LDA はデータの配置を分散させることが可能である．
以上から，二層 LDA はデータ交換の分散とデータ配置の分散を可能にし，全体として負荷が非集中の連携を実現する．よって，二層 LDA は他のアーキテクチャよりスケーラビリティが高いと評価できる．
7.2. 二層LDAの妥当性の確認
不特定多数のデータ連携を実現する際に重要な二つの項目を評価することで二層 LDA の妥当性を確認した．
(1) 連携参加者の結合度
不特定多数の連携アーキテクチャを実現するためには連携参加者の状態によらず連携が可能である必要がある．
連携参加者がエンドポイントを変更しても連携を可能としなければならない．二層 LDA は制御層を PSA に基づくことで，連携参加者の時間分離，空間分離を実現した．処理層はリソース指向に基づいてデータを取得するため，状態分離を可能とする．二層LDA は時間分離，空間分離，状態分離を可能とし，疎結合な連携を実現した．そのため，結合度は低い．
(2) 連携時間
連携時間をアーキテクチャの振舞いの比較，計測結果の比較に分けて評価する．
(a) アーキテクチャの振舞いの比較による評価
二層 LDA の Linked Data 配信時間 T1，データ取得時間 T0+T2，PSA のデータ配信時間 T2 と定義する ( 図 9) ． 二 層 LDA の 全 体 の 連 携 時 間 はT1*2+T0+T2 となる．PSA はブローカの全体の連携
時間は T2(ms)となる．これらから T2*2>T1*2+T2+T0より，T2/2>T1 が求まる．そのため，データサイズが大きい連携では二層 LDA の連携時間の方が短い．

y = 19.58x ‐ 100.57

4500

PSA(T2*2)

4000

二層LDA (T1*2+T2+ T0)

3908.543500
3000
2500(ms)

2000
1699.81500

500

y = 1.99x + 87.41
1094.09834.141000

55.963 61.45
74.61
112.68 183.6

386.67424.310025

5075

100 125 150 175 200 225 250 275 300 325 350 375 400 425 450 475 500

データサイズ(KB)

図 10 計測結果の比較データサイズが 10.68KB 未満では二層 LDA の方が PSA より連携時間が長いが，10.68KB 以上では二層 LDA の方が PSA より連携時間が短い．二層 LDAと PSA の傾きが 10 倍異なるため，サイズが１00KB のデータでは二層 LDA の連携時間が PSA の約 1/4 倍となる．
以上から，妥当な連携アーキテクチャと評価できる．
(c)

8. 今後の課題
8.1. 複数の連携参加者用いた負荷の計測
多数の実機を用いて，サービス，ブローカにかかる負荷を計測することが必要である．
8.2. Linked Dataの信頼性管理
Linked Data が指すデータがリポジトリに存在していない場合や Linked Data の指し先が異なっていることが考えられるため，Linked Data の信頼性を管理する必要がある．

9. まとめ本稿は Linked Data を用いたサービス連携アーキテクチ
ャを提案した．連携を制御と処理の二層に分け，Linked
Data で振舞いを制御することにより，非集中な連携を可能とし，スケーラブルなデータ連携を実現する．また，プロトタイプを開発し，有効性を示した．

10. 参考文献[1] D. A. Chappell, Enterprise Service Bus, O’Reilly, 2004.
[2] P. T. Eugster, et al., The Many Faces of Publish/ Subscribe，
ACM Computing Survey，Jun. 2003, pp. 114-131.
[3] Linked
Data
Platform
WorkingGroup,
http://www.w3.org/2012/ldp/wiki/Main_Page.
[4] M. Graube, et al., Linked Data as Integrating Technology
for Industrial Data, Proc. NiBS 2011, Sep. 2011, pp.
162-167.