SOA に基づくシステムのメッセージ変換に関する研究
M2013SE011 坪井智哉
指導教員：野呂昌満

1

はじめににより，一般にメッセージ変換は困難である．
セマンティック Web[3] は，Web 上のリソースに意味を表すデータを付加することで，意味を解釈した情報の検索を可能にする．本研究でも，メッセージのデータ構造に意味を付加するすることで，同じ意味をもつ異なるメッセージの相互変換を可能にすることを目指す．

SOA に基づくシステム (以下，SOA システム) の開発
は，通常，複数のサービスを連携させて実現する．サービス連携では，異なるベンダによって提供されたサービスを連携させる場合もある．この際，サービス毎に公開しているメッセージ形式に基づいてメッセージを作成する必要がある．サービスの入れ替えに伴い，メッセージ 3 概念モデルの構築
形式の変更があると，クライアントを変更しなければな
本研究では，ドメイン毎にサービス設計の基礎となるらない場合がある．変更されたメッセージ形式の把握や概念をモデル化する．すなわち，ビジネスロジックを決メッセージを変換する手間がかかる．
定付ける概念を整理する．商品検索メッセージを変換対メッセージのパラメータの名前が一致する場合，その象とし，ドメインを商品購買に限定する．商品購買はビ
意味は同義という前提でのメッセージの変換方法が提案
ジネスロジックのアクターとそれらの関係，役割が明確されている [7]．これは，SOAP と REST 間のメッセーになっており，事例として適切だと考える．消費者行動論
ジの自動変換方式の提案であるが，REST 間の変換も同[5] を参考にして，ステークホルダの行動をモデル化する．
じ方法で可能である．しかし，サービスベンダは独自にパラメータの名前付けを行なっているので，一般にメッ 3.1 消費者行動論
セージ変換は困難である．我々は，対象のドメインにお消費者がある製品およびサービスを購入するまでには，けるサービス設計の基礎となる概念を定義し，その概念 いくつかの段階がある．商品を購入するまでの一連のプとパラメータの意味の対応関係を定義する．これにより， ロセスを購買意思決定プロセスとよぶ．購買意思決定プ
共通の意味をもつメッセージ間の相互変換を目指す．
ロセスと影響要因の関係を図 1 に示す．購買意思決定プ
本研究の目的は，メッセージのデータがもつ意味を考慮 ロセスには，５つの工程が含まれる．1) 問題認識：あるしたメッセージ変換の仕組みを提案することである．メッ 商品の不足ないし欠如により，消費者の生活の上で不満セージ形式の変更に応じたメッセージの自動変換を考察 や不自由を感じさせる場合，問題として認識する，2) 情する．
報探索：選択対象となる商品を購買するかどうか判断す本研究では，サービス設計の基礎となる概念をモデル化 るために必要な情報を収集する，3) 代替案の評価：収集した概念モデルとメッセージのオブジェクトモデルの対応 した情報を基に，選択候補となる商品を評価しランク付関係を整理した．概念モデルの定義にあたっては，サービ けする，4) 購買意思決定：代替案の評価に基づいて，最ス共通のビジネスロジックを分析した．サービスの API も評価の高い商品を最も評価の高い店舗で購買する，5)を基にメッセージのオブジェクトモデルを定義し，概念 購買後評価：商品の購買が終了した後，その意思決定をモデルとオブジェクトモデルの対応関係を整理した．こ 評価する．
れにより，概念モデルを介してあるメッセージのオブジェ
クトモデルと異なるメッセージのオブジェクトモデルの対応関係が明らかになった．メッセージのデータがもつ意味を考慮した SOAP，REST など様々なメッセージの自動変換が可能になる．
本研究では Amazon Web サービス [1] と価格.com[6] の商品検索メッセージを対象に研究を進めた．Atlas Transformation Language(以下，ATL)[4] のモデル変換ツール
を利用し，自動変換の実現可能性を示す．別の事例でもメッセージ変換を行ない，提案方法の妥当性について考察する．

2

メッセージ変換における課題

メッセージのパラメータには，異なる文字列で同じ意味をもつ場合と，同じ文字列でも異なる意味をもつ場合がある．これは，サービスベンダは独自にパラメータの名前付けを行なっているからである．異なるメッセージ間において，パラメータの名前と意味が一致しないこと

図 1 消費者の購買までの意思決定プロセスと影響要因

3.2

商品購買に関する概念モデルの構築

購買意思決定プロセスの各工程毎に概念を整理した．図2 は情報探索を決定付ける概念を整理し，構築した概念モデルである．消費者は，消費者自身の記憶に蓄積されている内部情報と，周囲から得られる外部情報を基に商品に関する情報を取得する．外部情報は次のように分類される．1) 口コミによる情報：友人，知人等による情報，
2) マーケティング情報：広告，セールスマン，価格，店舗などから提供される情報，3) パブリクスからの情報：
新聞や雑誌の記事，4) 試行に基づく情報：消費者が実際に商品に接することにより得られる情報．
図 3 S3 アーキテクチャとオブジェクトモデルの関連
消費者にとっての情報収集は，購買経験不足や評価軸の不確かさに起因するリスクを削減するための努力である．リスクは次のように分類される．1) 機能的リスク： 4.2 Amazon Web サービスのオブジェクトモデル
品質や性能の不備，不良に関するリスク，2) 金銭的リス
Amazon Web サービスは，インターネット上で商品のク：商品購入による支出，金銭的損失に関するリスク，3)通信販売を行なうサービスである．商品とサービス利用
肉体的リスク：健康に及ぼす害，安全性への危惧に関す者，出品者，商品を検索するメッセージに関するパラメー
るリスク，4) 社会的リスク：他者から評価を悪くするこタの型を定義し，それらの関係を整理してオブジェクトとに関するリスク，5) 心理的リスク：自己イメージ，自モデルを構築する．構築したオブジェクトモデルを図 4
分らしさを損なうことに関するリスク．に示す．
オブジェクトモデルを用いてこれらの概念を整理し，各概念モデルと Amazon Web サービスのオブジェクトモオブジェクトの関連を明確にする．外部情報におけるマーデルの対応関係を整理する．概念モデルの消費者と Amaケティング情報については，実際の広告を分析し，商品zon の Customer，概念モデルの販売価格と Amazon のに関する詳細情報を抽出する．
SellingPrice は対応関係にある．概念モデルの金銭的リス
クは商品を検索する条件とみなすことができ，Amazonの販売価格の低い順に表示する-PriceRank と対応付けることができる．

図 2 消費者の情報探索に関する概念モデル

4

メッセージのオブジェクトモデルの構築

サービスが提供している API を基にメッセージのオブジェクトモデルを構築する．SOA システムの参照アーキテクチャである S3 アーキテクチャ[2] を基にオブジェク
図 4 Amazon Web サービスのオブジェクトモデル
トモデルを構築する．ドメインを商品購買に限定し，商品販売サービスの商品検索メッセージを研究対象とする．
4.3 価格.com のオブジェクトモデル
事例として，Amazon Web サービス [1] と価格.com[6] の価格.com は，インターネット上で様々な商品の価格を商品検索メッセージのオブジェクトモデルを構築する．
検索するためのサービスである．主にサービス利用者は4.1 S3 アーキテクチャ
商品のカテゴリを選択し，そのカテゴリ内で検索対象と
S3 Architecture は SOA システムのための標準的な参 なる商品を価格の低い順に表示する．商品とサービス利照アーキテクチャである．SOA システムの構成要素と 用者，商品を検索するメッセージに関するパラメータのその役割を抽象化し，９層の階層構造を示している．S3 型を定義し，それらの関係を整理してオブジェクトモデル
Architecture で示される階層構造を図 3 に示す図中の左 を構築する．構築したオブジェクトモデルを図 5 に示す．
概念モデルと価格.com のオブジェクトモデルの対応関係
側の５つの層は SOA アプリケーションの関心事を階層構造により分離している．メッセージのオブジェクトモデ を整理する．概念モデルの消費者と価格.com の Customer，
ルは，Service Components 層のコンポーネントの構造を 概念モデルの販売価格と価格.com の SellingPrice は対応基に構築する．本研究では，サービスの内部構造がわか 関係にある．Amazon と同様に概念モデルの金銭的リスらないので，Services 層の API を参考にして構築する． クは，価格.com の-pricerank と対応付けることができる．

型の対応関係に基づいてモデル変換を行ない，概念モデ
ルから出力インスタンスを生成する，3) 出力インスタン
スの型と価格.com の構成要素の型の対応関係に基づいてモデル変換を行ない，価格.com のオブジェクトモデルから出力インスタンスを生成する，4) 出力インスタンスに基づいて価格.com の REST メッセージを作成する．

5.2.1

メタモデル間の変換ルールの定義

概念モデルと各サービスのオブジェクトモデルの対応関係を整理する．概念モデルと Amazon Web サービスのオブジェクトモデル，価格.com のオブジェクトモデルと概念モデルの対応関係をそれぞれ整理する．
図 5 価格.com のオブジェクトモデル
構成要素の名前が一致する場合，対応関係はある．しかし，構成要素の名前が一致しない場合でも構成要素の意味
5 メッセージ変換を考慮し，対応関係が生まれる場合がある．例えば，Amazon Web サービスの検索メッセージには，ReviewRank と5.1 ATL を用いたモデル変換の仕組みいうユーザレビューが高い順に商品を表示するためのパラATL[4] では，変換対象のモデルの構成要素と変換後のメータがあるが，価格.com にはない．しかし，価格.com
モデルの構成要素の対応関係に従い，モデル変換を実現すのパラメータには，商品の人気順に検索するための Popる．ATL を用いてメッセージの自動変換の実現可能性をularityRank がある．これらは消費者が社会的に人気があ確認する．ATL を用いたモデル変換の概要を図 6 に示す．
る商品を検索したいという目的がある場合に利用するパラメータである．概念モデルの SocialRisk を仲介してこれらのパラメータは相互変換すべきと判断する．

5.2.2

入力インスタンスモデルの作成

入力メッセージからパラメータと値を抽出し，インスタンスモデルを作成する．インスタンスモデルを作成する
際には，サービスのオブジェクトモデルを参考にして型の定義を行なう．Amazon Web サービスの REST メッセー
ジからインスタンスモデルを作成した例を図 7 に示す．
図 6 ATL を用いたモデル変換の概要

ATL では，対象となる入力インスタンス ModelA を出力インスタンス ModelB へモデル変換する．モデル変換を実現するためには，入力インスタンスのメタモデル MetaModelA と出力インスタンスのメタモデル MetaModelBを定義する必要がある．また，メタモデル間の変換ルールを定義した変換ルールファイル MMA2MMB.atl を定義する必要がある．MMA2MMB.atl は MetaModelA とMetaModelB の構成要素の間の型の対応関係に基づいて記述される．MMA2MMB.atl に記述された変換規則を処理することによりモデル変換を実現する．
5.2

商品検索の事例によるメッセージ変換

本研究では，ATL モデル変換ツールを用いて Amazon
Web サービス [1] と価格.com[6] の検索メッセージのメッセージ変換を行なう．概念モデルと各サービスのオブジェ
クトモデルをメタモデルとして定義する．Amazon Web
サービスの REST メッセージを価格.com の REST メッセージに変換する場合，次の手順でメッセージ変換を行
なう．1)Amazon Web サービスの REST メッセージから入力インスタンス (パラメータと値) を抽出する，2) 入力
インスタンスの型と商品購買の概念モデルの構成要素の

図 7 入力メッセージからパラメータと値の抽出

5.2.3

出力メッセージの作成

概念モデルから価格.com のオブジェクトモデルへモデル変換を行ない，出力されたインスタンスモデルを基にREST メッセージを作成する．出力されたインスタンスの型とパラメータの対応関係により，メッセージを作成する．価格.com の REST メッセージを作成した例を図 8に示す．

図 8 出力インスタンスから REST メッセージの作成

6

考察

6.1

別の事例による考察

別の事例として，SNS などのサービスから利用者の投稿を検索するメッセージの変換を行なう．概念モデルを構築する際，ステークホルダの行動としてコミュニケーションを分析し，モデル化する．コミュニケーションに関する概念モデルを図 9 に示す．一般的なコミュニケーションモデルを参考にして発信者，コミュニケーションの内容，メディア，受信者を分析する．

研究で提案するメッセージ変換は次のように実行される．
1) 入力メッセージを解析し，パラメータと値の抽出，2)抽出したパラメータの型の確認，3) 入力メッセージのオブジェクトモデルを基にインスタンスモデルの作成，4)インスタンスモデルを概念モデルに変換，5) 概念モデルから変換先のサービスのインスタンスモデルに変換，6)変換されたインスタンスモデルからパラメータを抽出し，メッセージの出力．ただし，これらの変換を実現するた
めには，前提として概念モデルと各サービスのオブジェクトモデル，それらの対応関係を定義する必要がある．
本研究で試行し，メッセージの自動変換が確認できたのは，3)，4)，5) の工程である．他の工程は開発者自ら手作業，または他の自動生成ツールを用いて行なわなければならない．また，3)，4)，5) の各工程での成果物を次工程で入力し実行する作業も自動化する必要がある．

7

図 9 コミュニケーションに関する概念モデル

Twitter と Facebook の利用者の投稿の検索メッセージを対象とする．Twitter と Facebook の REST API を基にメッセージのオブジェクトモデルを構築した．各サービスのオブジェクトモデルとコミュニケーションに関する概念モデルの対応関係を整理した．結果，商品検索の事例と同様にメッセージのデータがもつ意味を考慮したメッセージ変換を実現できることを確認した．
6.2

おわりに

本研究では，メッセージのデータがもつ意味を考慮したメッセージ変換の仕組みを提案することを目的に，サービス設計の基礎となる概念をモデル化した概念モデルとメッセージのオブジェクトモデルの対応関係を整理した．
概念モデルを介して異なるメッセージ間の対応関係が明らかになった．今後の課題として，メッセージのパラメー
タと値の抽出の自動化，モデル変換の自動化，メッセージの生成系の作成が挙げられる．また，ドメイン毎に概念モデルを作成し，概念モデルを作成するプロセスを標準化する必要がある．

参考文献[1] Amazon Simple Storage Service, REST API,”
http://docs.aws.amazon.com/AmazonS3/latest/API/APIRest.html, 2006.

概念モデルに関する考察[2] A. Arsanjani, L. J. Zhang, M. Ellis, A. Allam, and K.
ドメイン毎に標準化された概念モデルを定義すること
Channabasavaiah, ”S3: A service-oriented reference
により，サービス利用者の共通認識のもと，パラメータ
architecture,” IT Professional, vol. 9, no. 3, pp. 10がもつ意味を定義することが可能になる．標準化された
17, 2007.
概念モデルを利用し，メッセージ形式の変更に応じたメッ [3] D. Fensel, J. A. Hendler, H. Lieberman, and W.
セージの自動変換が可能となる．メッセージの自動変換
Wahlster, Spinning the Semantic Web: Bringing theのシナリオは以下である．標準化機構は概念モデルを定World Wide Web to Its Full Potential, The MIT
義し，概念モデル，概念モデルと各サービスのオブジェ
Press, 2003.
クトモデルの対応関係を管理する．サービスベンダは各[4] F. Jouault, F. Allilaire, J. Bezivin, and I. Kurtev,
サービスのオブジェクトモデルを構築し，オブジェクトATL: A model transformation tool, Science ofモデルと概念モデルの対応関係を標準化機構に登録する．
Computer Programming, vol. 72, no. 1, pp. 31-39,
サービスベンダは，メッセージ形式を変更した場合，標2008.
準化機構に登録した対応関係を更新する．メッセージ変
換系は標準化機構が管理するオブジェクトモデルと概念 [5] 井上崇通，消費者行動論，同文舘，2012．
モデルの対応関係を参照し，メッセージ変換を行なう．結 [6] 株式会社カカクコム， 価格.com WEB サービス API
マニュアル,” http://apiblog.kakaku.com/
果，サービスクライアントはメッセージを変更すること
KakakuItemSearchV1.0.html，2009．
なく，メッセージ変換系を利用することで目的のメッセージに自動変換することが可能になる．

6.3

メッセージの自動変換に関する考察

本研究では，ATL を利用してメッセージのデータがもつ意味を考慮したメッセージの自動変換を確認した．本[7] 山登庸次，宮城安敏，中野雄介，中村義和，大西浩
行， SOAP-REST サービス連携のための実行制御機能の研究開発，” 情報処理学会論文誌，vol.51，no.2，
pp.503-516，Feb. 2010．