クラウドコンピューティング連携のためのパブリッシュ/サブスクライブアーキテクチャの提案
M2010MM015 影石 英紀
指導教員 青山 幹雄

1. はじめに現在，ネットワークを介してサービスを提供するクラウド
コ ンピ ュ ー ティン グ に注目が集ま って い る ． さら に，Salesforce.com の CRM や GoogleApps などインターネット経由でアプリケーションを利用する SaaS（Software as aService）が実務で使われている．このようなクラウドコンピューティングの普及に伴い，SaaS間，SaaS とオンプレミスアプリケーション間の連携の必要性が増加している．しかし，SaaS やオンプレミスアプリケーションは，ベンダごとに開発されていることから，連携が困難である．本稿ではクラウドコ
ンピューティングにおける SaaS の連携方法を提案する．

2. 研究課題
現在，SaaS やオンプレミスアプリケーションは企業ごとに開発されていることからアーキテクチャが異なる．そのため各アプリケーションはインタフェースとメッセージ交換の方法が異なり，連携を行うためにはデータや振舞いを整合する必要がある．

3. 関連研究SaaS の連携方法としてリクエストレスポンスを用いた連携方法が提案されている[１]．また，OASIS により Web サー
ビスにおけるパブリッシュ/サブスクライブの処理方法が定義されている[3]．
3.1. SaaS/クラウドサービス間のメッセージ連携方法
SOA(Service-Oriented Architecture)に基づくクラウドコン
ピューティング環境におけるSaaSの連携方法が提案されている[1]．
サービスコンシューマはブローカにリクエストを送り，ブローカはデータの変換を行う．そして，サービスコンシューマにレスポンスを送ることで，異なるクラウドコンピューティング環境のSaaSの連携を実現している．この研究ではサービスコンシューマからブローカにリクエストレスポンスによる1対1のタイミングの連携に対応している．しかし送信側と受信側のメッセージの関係が多対多のタイミングによるメッセージ交換に対応していないという問題がある．
3.2. WS-Notification
WS-Notification は SOA の技術基盤である Web サービ

スを基礎としてパブリッシュ/サブスクライブの処理方法を定義している[3]．
(1)WS-BaseNotification
通知を送信する NotificationProducer とメッセージを受信する NotificationConsumer の 2 つの主要なコンポーネント間のメッセージの方法を示す．NotificationProducer は，発行する通知に関するトピックを公開し，NotificationConsumer
はサブスクリプションを NotificationProducer に送信する．
(2)WS-BrokeredNotification
NotificationConsumer と NotificationProducer の 間 にNotificationBrokerを用いることで2者間の関係を分離する．
NotificationBroker では NotificationProducer が公開するトピックの情報や NotificationConsumer からのサブスクリプションの管理，通知の分散に関する処理などを行う．
(3)WS-Topics
メッセージのトピックの構造を木構造で規定している．

4. アプローチ
クラウドコンピューティング環境における SaaS 間のメッセージ交換のタイミングに着目し，タイミング整合の問題を解決するための方法を提案する．本稿では送信側と受信側のタイミングの分類を行い，それぞれのタイミングをモデル化し分析を行う．
Salesforce.com のCRM とGoogle のSaaS 連携を前提とし，Salesforce.com のサービスを送信側，Google のサービスを受信側とする．送信側のメッセージはアウトバウンドメッセージとする．
4.1. 送信側のタイミング
Salesforce.com か ら の ア ウ ト バ ウ ン ド メ ッ セ ー ジ はSalesforce.com のサービス上でユーザの操作によりトランザクションが実行される．また，アウトバウンドメッセージは
One-Way のメッセージでリクエストを要求していないことから非同期メッセージとなる．
4.2. 受信側のタイミング
受信側の SaaS アプリケーションではユーザの要求に対して応答を返す同期型のメッセージ交換となる．
4.3. タイミング整合
送信側の非同期メッセージ送信と受信側の同期メッセージ交換の間で連携を行う場合，送受信のアプリケーション間にブローカを設置し，タイミング整合する必要がある．送信側と受信側のトポロジの関係を 1 対 1 とし，送信側と受信側のタイミングの関係を 3 つ分類する．
(1)送信側と受信側のタイミングが 1 対 1送信側からのメッセージ通知毎に，受信側の要求によりブローカから 1 回で送信する．
(2) 送信側と受信側のタイミングが N 対 1 の場合送信側から複数のメッセージ通知を受信側に 1 回で送信する．
(3) 送信側と受信側のタイミングが N 対 M の場合送信側から複数のメッセージ通知を複数回に分けて送信する．
4.4. クラウドコンピューティングへのパブリッシュ/サブスクライブの適用
SaaS 間の振舞いの整合を行うにはメッセージ交換のタイミングの問題を解決する必要がある．本稿では，送信側と受信側のメッセージの関係が多対多の連携を実現するた
めにパブリッシュ/サブスクライブアーキテクチャを用いて，メッセージのタイミングの問題を解決し，多対多のタイミングによる SaaS 連携を実現する．

5. クラウド連携のためのパブリッシュ/サブスクライブアーキテクチャの提案
5.1. アーキテクチャに対する要求タイミングの整合を実現するために，ブローカは以下の 3つの要求を満たす必要がある．
(1)複数のメッセージ通知を受信し保持する
送信側のメッセージはユーザのトランザクションにより，非同期で送信されることから一方向の複数のメッセージが送信される．受信側はリクエストレスポンス型の同期メッセージであることから，送信側から複数のメッセージを保持しておく必要がある．
(2)受信側の要求に応じて通知するメッセージの分類
送信側から送られるメッセージを受信側にすべて送信するのはネットワークの負荷がかかり，非効率的である．SaaS
AP の要求を指定し，ブローカアーキテクチャがフィルタリングを行い SaaS AP の要求を満たすメッセージを送信すべきである．
(3)受信側にメッセージの通知
ブローカで保持したメッセージを，ブローカは受信側に通知する必要がある．
以上の 3 つの要求を満たすためにパブリッシュ/サブスクラ
イブアーキテクチャを用いて送信側，受信側間のタイミングを整合するブローカアーキテクチャを提案する．
5.2. ブローカアーキテクチャの機能
5.1 節の要求を満たすブローカのユースケース図を図 1に示す．ブローカの機能はサブスクリプション登録，アウト
バウンドメッセージ受信，フィルタリング，メッセージ受信、メッセージストアへ登録の 5 つである．

サブスクリプション登録

データの検索サブスクリプションの可否
アウトバウンド
メッセージ受信

Salesforce.com

SaaS AP

メッセージストアへ登録

フィルタリング
メッセージ通知メッセージブローカ

図 1 クラウド連携ブローカのユースケース図
5.3. ブローカアーキテクチャの構成
5.1 節の 3 つの要求を満たすクラウド連携ブローカアーキ
テクチャの構成を図 2 に示す．ブローカアーキテクチャは
WS-BaseNotification の仕様を基に作成する．クラウド連携
ブローカは 2 つのマネージャ(PublisherRegistration マネー
ジャ，Subscription マネージャ)と3つのデータベース(パブリッシャストア，サブスクリプションストア，メッセージストア)から構成される．
PublisherRegistration マネージャで Salesforce.com から送信され る ア ウ トバ ウ ン ド メ ッ セ ー ジ の 情報を管理し ，Subscription マネージャで SaaS AP のサブスクリプション情報を管理する．SaaS アプリケーションとクラウド連携ブローカ間のメッセージプロトコルは標準メッセージである
SOAP/REST を使用する．
Salesforce.com

プロバイダ
SOAP/REST の取得

SaaS AP

サブスクリプション
メッセージ
メッセージ
SOAP/REST
SOAP/REST
情報の登録
SOAP/REST(1)Publisher(2)Subscription
Registration サブスクリプ
マネージャ
マネージャ ションの可否(3)パブリッシャ
ストア(DB)(4)サブスクリプション
ストア(DB)

メッセージ
通知
SOAP/REST(5) メッセージ
ストア(DB)

クラウド連携ブローカ

図 2 クラウド連携ブローカアーキテクチャ
次にブローカ内の各コンポーネントの機能を定義する．
(1) PublisherRegistration マネージャ
Salesforce.com からの送信されるアウトバウンドメッセージの登録を行う．Subscription マネージャからサブスクリプションの可否を検索し，結果を返信する．
(2) Subscription マネージャ
SaaS AP からのサブスクリプションの登録を行う．サブス
クリプションの可否の問い合わせ，メッセージのフィルタリン
グ，データの検索，SaaS AP への配信を行う．
(3) パブリッシャストア
Salesforce.com のメッセージを送信するパブリッシャを登録する．
(4) サブスクリプションストア
受信側のアプリケーションのサブスクリプション情報を登録するデータベース．
(5) メッセージストア
Salesforce.com から送信されたアウトバウンドメッセージの要素を保存するデータベース．
5.4. ブローカの振舞い
ブローカの振舞いをサブスクリプション登録，メッセージ通知の 2 つに分けて説明する．
(1)サブスクリプションの振舞い
1)サブスクリプションのアクティビティ
SaaS AP のサブスクリプションの実行からシステムのアクティビティを図 3 に示す．
Salesforce.com

Publisher
Registation
マネージャ

パブリッシャ
ストア

Subscription
マネージャ

サブスクリ
プション
ストア

パブリッシャ
情報の検索

メッセージストア

SaaS AP

Salesforce.com

Publisher
Registration
マネージャ

Subscription
マネージャ

パブリッシュストア

メッセージストア

サブスクリプションストアSaaS
AP

パブリッシュ情報の取得
検索サブスクリプションの可否

サブスクリプション

検索alt[サブスクリプション可能]
サブスクリプションの登録

faultの返却

図 4 サブスクリプション時のブローカの振舞い(2)メッセージ通知
1) メッセージ通知のアクティビティ
Salesforce.com のアウトバウンドメッセージから SaaS APへメッセージ通知を行うアクティビティを図 5 に示す．

パブリッシャ
情報の取得

Salesforce.com

サブスクリプション

アウトバウン
ドメッセージの送信

Publisher
Registation
マネージャ

パブリッシャ
ストア

Subscription
マネージャ

サブスクリ
プション
ストア

メッセージ
ストア

SaaS AP

パブリッシャ
情報のレスポンス
パブリッシャ
情報のレスポンス
サブスクリプションの可否を問い合わせる

サブスクリプション情報の検索

パブリッシャ
情報のレスポンス

サブスクリプション情報のレスポンス
サブスクリプション可否のレスポンス

サブスクリプションの登録アウトバウン
ドメッセージの登録

メッセージ
ストアに登録サブスクリプションのレスポンス

フィルタリング

サブスクリプション情報の登録

faultの通知

メッセージ
通知

メッセージ
受信

図 3 サブスクリプション登録のアクティビティ図2)サブスクリプションの処理の流れ
SaaS AP のサブスクリプションの実行からシステムの処理の流れを図 4 に示す．
(a)クラウド連携アーキテクチャが公開するパブリッシャ情報を基に，SaaS AP は PublisherRegistation マネージャからパブリッシャ情報を要求する．
(b)PublisherRegistration マネージャはパブリッシャストアにパブリッシャ情報の検索を行い，結果を SaaS AP に返信する．
(c)SaaS AP は要求する Subscription 情報を Subscription マネージャに送信する．SubscriptionマネージャはSaaS APのサブスクリプションの可否を PublisherRegistation マネージャに問い合わせる．
(d)PublisherRegistration マネージャはパブリッシャにパブリッシャ情報の検索を行い，Subscription マネージャに返信する．
(e)Subscription マネージャはサブスクリプション可能であれは，サブスクリプションストアにサブスクリプションの登録を行い，サブスクリプション不可能であれば fault を SaaS APに返信する．

図 5 パブリッシュからメッセージ通知のアクティビティ図2)メッセージ通知の処理の流れ
Salesforce.com からのアウトバウンドメッセージから SaaSAP へ通知までのブローカの振舞いを以下に示す(図 6)．
パブリッシュ，フィルタリング，メッセージ通知の順で実行する．
(a)パブリッシュ：Salesforce.com がアウトバウンドメッセージを Subscription マネージャへ送信する．Subscription マネー
ジャは受信メッセージを受け取り，メッセージストアにメッセージの内容を登録する．
(b)フィルタリング：Subscription マネージャはサブスクリプションストアに事前に SaaS AP に指定されたサブスクリプションの取得を行う．さらに，保持しているSalesforce.comからのメッセージの内容を取得する．Subscription マネージャはWS-Topics で指定された条件に基づいてメッセージのフィルタリングを行う．
(c)メッセージ通知：Subscription マネージャはフィルタリングしたメッセージを，受信側の要求に応じたタイミングで SaaSAP へ配信する．
Salesforce.com

Publisher
Registration
マネージャ

パブリッ
シュストア

アウトバウンドメッセージ

Subscription
マネージャ

メッセージ
ストア

信側と受信側のメッセージの関係が多対多の連携を可能とした．
サブスクリプションストアSaaS
AP

メッセージの登録

サブスクリプションの取得

メッセージの検索

フィルタリング
フィルタリングを行ったメッセージの通知

図 6 フィルタリングと通知時のブローカの振舞い
5.5. タイミング制御
Subscription マネージャで送信側と受信側のメッセージのタイミング整合を行うために，WS-BaseNotification の仕様に基づき，サブスクリプションメッセージを送信する．サブスクリ
プションメッセージでは次の 3 つのプロパティを指定する．
(1)ProducerProperties：サブスクリプションの可否の条件式を指定する．
(2)MessageContent：サブスクリプションするメッセージの内容を XPath で指定する．
(3)SubscriptionPolicy：ユーザが要求する配信方法の指定する．SubscriptionPolicyでメッセージの通知回数を制御すること
でSaaS APの要求するタイミングでブローカから通知される．
図 6 より，ブローカが Salesforce.com からのアウトバウンドメッセージを受信し，フィルタリングを行うことでタイミングの異なる SaaS からのメッセージの連携を可能としている．

7. 今後の課題
今後の課題として，以下の 2 つの課題が挙げられる．
(1) クラウド環境での検証
本稿の目的はクラウド環境における送信側と受信側のメッセージの関係が多対多のタイミングによるメッセージ交換である．パブリッシュ/サブスクライブアーキテクチャとWS-BaseNotification をクラウド連携に適用し，アーキテクチャを提案した．Salesforce.com と Google の SaaS を用いてプロトタイプを実装し，クラウド環境におけるブローカアーキテクチャの検証を行う必要がある．
(2) メッセージ変換方法の検討
異なるプロトコルを利用する SaaS アプリケーションとの連携を実現するために，SOAP と REST，JSON とのメッセージの相互変換の詳細を検討する．

8. まとめクラウドコンピューティング環境における多対多のタイミングによるメッセージ交換を実現するために，本稿ではメッセージの振舞いに着目し，パブリッシュ/サブスクライブアーキテクチャの適用を検討した．さらに，
WS-BaseNotification を適用し，提案したアーキテクチャのブローカ内でメッセージのタイミングの制御を行い，受信側の SaaS の要求に応じたメッセージの配信を可能とした．

6. 評価と考察

参考文献

6.1. 評価(1) タイミングの異なるメッセージ交換の整合提案したアーキテクチャはパブリッシュ/サブスクライブを用いた．パブリッシュ/サブスクライブモデルは，非同期の連携を可能としていることから，送信側の非同期メッセージ，受信側の同期メッセージの 2 つの異なるタイミングのアプリケーションの連携の実現を可能としている．
(2) 受信側アプリケーションの要求に応じた配信
受信側の SaaS AP の サ ブ ス ク リ プ シ ョ ン 方法は
WS-BaseNotification の仕様に基づきサブスクリプションの指定を行うことで要求に応じた配信することが可能である．
6.2. 考察論文[1]では，SaaS 連携を実現しているがサービスコンシューマからのリクエストレスポンスによりデータ連携をしていることから，1 対 1 の連携になる．このため複数のタイミングによる N 回のメッセージの連携に対応してなかった．パブリッシュ/サブスクライブアーキテクチャを用いることで，送[1]

[2]

[3]

[4]

[5]

バンダリ スワティ，他，SaaS/クラウドサービス間のメッセージ連携方法の提案と評価，情報処理学会 第72 回 全国大会 講演論文集 (3), Mar. 2010, pp. 389-390.
P. Th. Eugster, et al., The Many Faces of Publish/Subscribe, ACM Computing Survey, Jun. 2003. pp.
114-131.
OASIS, Web Services Base Notification (WSBaseNotification), Ver. 1.3, 2006, http://docs.oasisopen.org/wsn/wsn-ws_base_notification-1.3-spec-os.pdf.
OASIS, Web Services Brokered Notification (WSBrokeredNotification), Ver. 1.3, 2006, http://docs.oasisopen.org/wsn/wsn-ws_brokered_notification-1.3-spec-os.pdf.
OASIS, Web Services Topics (WS-Topics), Ver. 1.3, 2006,
http://docs.oasis-open.org/wsn/wsn-ws_topics-1.3-spec-os.pdf.