Paper

社団法人 電子情報通信学会
THE INSTITUTE OF ELECTRONICS,
INFORMATION AND COMMUNICATION ENGINEERS
信学技報
TECHNICAL REPORT OF IEICE
異なる連携方式を用いた Web サービスアプリケーションの
開発および評価
石井 健一
串戸 洋平
山内 寛己
井垣 宏
玉田 春昭
中村 匡秀
松本 健一
奈良先端科学技術大学院大学 情報科学研究科 〒630-0192 奈良県生駒市高山町 8916-5
E-mail:
{keni-i, youhei-k, hiroki-y, hiro-iga, harua-t, masa-n, matumoto}@is.aist-nara.ac.jp
あらまし Web サービスは，インターネット上に分散するサービスを統合し，付加価値を高めたサービス提供
を実現するインフラとして注目されている．本稿では，複数の Web サービスが連携して新たなサービスを実現
する際の連携方式に着目し，連携方式の違いが，Web サービスアプリケーションの性能や開発しやすさに如何
に影響するかを評価する．具体的には，同一の仕様に基づく Web サービスアプリケーションを異なる連携方式
（リダイレクト型，プロキシ型，スタンドアロン型）で実装し，実行時間，コード行数から評価を行う． そ
の結果，プロキシ型連携方式が実行時間およびコード行数の両側面において，リダイレクト型連携方式より優
れていることがわかった．また，スタンドアロン型と他の 2 方式の比較から Web サービスの数が性能面および
保守性に大きな影響を与えることを示した．
キーワード Web サービス，サービス連携，連携方式，Web サービスアプリケーション
Development and Evaluation of Web service applications with Different
Integration Schemes
Ken-ichi ISHII
Youhei KUSHIDO
Hiroki YAMAUCHI
Hiroshi IGAKI
Haruaki TAMADA
Masahide NAKAMURA and Ken-ichi MATSUMOTO
Graduate School of Information Science, Nara Institute of Science and Technology
8916-5 Takayama, Ikoma, Nara, 630-0192 Japan
E-mail:
Abstract
{keni-i, youhei-k, hiroki-y, hiro-iga, harua-t, masa-n, matumoto}@is.aist-nara.ac.jp
Web services are a powerful infrastructure to provide value-added services integrating distributed services over the
Internet. This paper focuses the integration schemes to achieve the new service from multiple services. We evaluate how the integration
schemes give impact on performance and development efforts of Web service applications. Specifically, based on the same
specification, we developed three versions of the applications with different integration schemes (redirection type, proxy type,
stand-alone type). Then, we evaluated the execution time, the lines of code of the Web applications. From the result of the experiment,
the proxy type scheme is superior to the redirection type scheme in both performance and lines of codes. Also, the comparison with the
stand-alone type and other two types showed that the number of Web services gave significant influence on performance and
maintainability.
Keyword Web Services, Service Integration, Integration Schemes, Web Service Applications
1. は じ め に
た．その結果，プロキシ型連携方式が実行時間および
近 年 ，イ ン タ ー ネ ッ ト 網 の 急 速 な 整 備 と e-ビ ジ ネ ス
クライアントアプリケーションのコード行数の両側面
の 普 及 に 伴 い ， Web の 利 用 目 的 は ， 単 な る 情 報 流 通 基
において，リダイレクト型より優れていることがわか
盤 か ら サ ー ビ ス 流 通 基 盤 へ 進 化 を と げ て い る ．中 で も ，
っ た ． ま た ， Web サ ー ビ ス の 数 が 性 能 面 に 大 き な 影 響
Web サ ー ビ ス（ Web Service）は ，次 世 代 Web の 動 的 側
を与えることを示した．
面を支える分散計算環境の基盤として多方面で注目さ
れ て い る [5]．Web サ ー ビ ス は ，イ ン タ ー ネ ッ ト 上 に 分
2. Web サ ー ビ ス と 2 つ の 異 な る 連 携 方 式
散するサービスを統合し，付加価値を高めたサービス
本 稿 で は ，同 じ 目 的 を 達 成 す る Web サ ー ビ ス ア プ リ
提 供 を 実 現 す る イ ン フ ラ を 提 供 す る ． ま た ， Web サ ー
ケーションを 2 つの異なる連携方式（リダイレクト型
ビスは，各サービスの独立性や再利用性を確保するこ
とプロキシ型）を用いて設計・実装を行い，その評価
とで，変更や再構築の効率性を高めることが可能であ
を 行 う ． 本 章 で は ， Web サ ー ビ ス と 2 つ の 異 な る 連 携
る [6]．
方式について定義，解説する．
Web サ ー ビ ス は ， サ ー ビ ス 指 向 ア ー キ テ ク チ ャ
2.1. Web サービス
（ Service Oriented Architecture）の 考 え に 基 づ き ，サ ー
Web サ ー ビ ス は ， ソ フ ト ウ ェ ア を サ ー ビ ス と い う 単
ビス提供者，サービス利用者，サービス仲介者の 3 者
位 で コ ン ポ ー ネ ン ト 化 し ， Web サ ー バ 上 で そ の 機 能 を
間の相互作用により構成され，標準化された規格
提供するための標準的な枠組みである．クライアント
（ HTTP， XML, SOAP, UDDI） で サ ー ビ ス を 実 現 す る
ア プ リ ケ ー シ ョ ン は ，サ ー ビ ス へ の ア ク セ ス に Web ブ
も の で あ る ． Web サ ー ビ ス は ， 従 来 の オ ブ ジ ェ ク ト 指
ラウザを必要とせず，直接データの授受が行える．サ
向設計のように，機能を一つのオブジェクトとして設
ービスの利用は，クライアントアプリケーションから
計するのではなく，より粒度の大きいサービスを一つ
リ モ ー ト プ ロ シ ー ジ ャ コ ー ル （ RPC ） で 行 わ れ る ．
の部品（コンポーネント）として設計する．これによ
XML-RPC お よ び SOAP と い っ た Web サ ー ビ ス で 標 準
り ， Web サ ー ビ ス 内 部 の 変 更 が シ ス テ ム 全 体 に 波 及 す
化された手段を用いることで，アプリケーションの開
ることを防止でき，既存サービスの再利用性を向上で
発者は，送受信するメッセージの書式やプロトコルを
き る ． さ ら に ， Web サ ー ビ ス で は ， 標 準 化 さ れ た 通 信
意識することなく，通常のメソッド呼び出しとほぼ同
手段を用いるため，異なるシステム間の連携を効率よ
じ 方 法 で ， Web サ ー バ 上 の サ ー ビ ス を ア プ リ ケ ー シ ョ
く実現できる．
ン に 組 み 込 む こ と が で き る ．図 1 に 一 般 的 な Web サ ー
現 在 ， Web サ ー ビ ス を 用 い た シ ス テ ム が い く つ か 開
ビスの構成を示す．
発 さ れ ， 公 開 さ れ て い る [1] [3] [7] [8]． し か し ， Web
サービスを用いたシステムは，まだ，試験段階のもの
や実地運用が開始されてから日の浅いものが多く，体
系 だ っ た 開 発 方 法 論 は 未 だ に 提 案 さ れ て い な い ．ま た ，
Web サ ー ビ ス ア プ リ ケ ー シ ョ ン の 性 能 を 評 価 す る 体 系
的な手段も存在しない．
本 稿 の 目 的 は ，複 数 の Web サ ー ビ ス が 連 携 し て 新 た
なサービスを実現する場合の連携方式に着目し，連携
方 式 の 違 い が ， Web サ ー ビ ス ア プ リ ケ ー シ ョ ン の 性 能
や開発しやすさに如何に影響するかを評価することで
ある．
図 1
一 般 的 な Web サ ー ビ ス の 構 成
具体的には，クライアントアプリケーションが 2 つ
の Web サ ー ビ ス A,B を 利 用 す る 場 合 を 考 え ，以 下 の 2
本 稿 で は ， Web サ ー ビ ス を 利 用 す る ア プ リ ケ ー シ ョ
種類の連携方式に着目する：クライアントアプリケー
ン を ク ラ イ ア ン ト ア プ リ ケ ー シ ョ ン（ 以 降 CA と す る ），
シ ョ ン が 直 接 A,B を 逐 次 的 に 利 用 す る リ ダ イ レ ク ト 型
Web サ ー ビ ス が 登 録 さ れ て い る サ ー バ を サ ー ビ ス レ ジ
連 携 方 式 ，ク ラ イ ア ン ト ア プ リ ケ ー シ ョ ン が A を 利 用
ス ト リ と 呼 ぶ ．図 1 に お い て ，CA が ，Web サ ー ビ ス S
し，A がクライアントアプリケーションの代わりに B
を呼び出す手順は，以下の通りである．
を利用するプロキシ型連携方式．
性能評価においては，バス時刻表検索サービスを 2
1.
通りの連携方式を用いて開発した．実験においては，
サービスの実行時間およびソースコード行数を計測し
CA は ， サ ー ビ ス レ ジ ス ト リ を 利 用 し て ， Web
サ ー ビ ス S の 検 索 を 行 う （ 図 1(1)）
2.
サ ー ビ ス レ ジ ス ト リ は ，Web サ ー ビ ス S が 提 供
さ れ る サ ー バ と Web サ ー ビ ス S が 公 開 し て い る
3.
メ ソ ッ ド の イ ン タ フ ェ ー ス 情 報 を CA へ 返 す
（ 図 1(2)）
3.
（ 図 2(3)）
4.
Web サ ー ビ ス B は ， CA へ 応 答 す る （ 図 2(4)）
CA は ， メ ソ ッ ド を 介 し て サ ー ビ ス を Web サ ー
ビ ス S へ 要 求 す る （ 図 1(3)）
4.
CA は ， Web サ ー ビ ス B へ サ ー ビ ス を 要 求 す る
Web サ ー ビ ス S は ， CA に 応 答 す る （ 図 1(4)）
2.3. プロキシ型
も う 1 つ の 連 携 方 式 と し て ， CA が 一 方 の サ ー ビ ス
を 要 求 す る と ， そ の サ ー ビ ス が CA の 代 わ り に も う 一
た だ し ， CA が Web サ ー ビ ス S の 存 在 を 知 っ て い る 場
方 の サ ー ビ ス を 要 求 す る 方 式 が 考 え ら れ る ．本 稿 で は ，
合 ，上 記 の 1，2 は 省 略 さ れ る ．ま た ，Web サ ー ビ ス S
こ の よ う な 方 式 を プ ロ キ シ 型 と 呼 ぶ（ 図 3）．プ ロ キ シ
は，存在を公開するために，サービスレジストリへサ
型 に お い て ，CA は ， 目 的 と す る 処 理 を 行 う た め に ， 1
ー ビ ス の 登 録 を 行 う （ 図 1(5)）．
つ の Web サ ー ビ ス の み と 連 携 す る ．
Web サ ー ビ ス S は ， CA に 対 し て ， メ ソ ッ ド m を 通
し て の み サ ー ビ ス を 提 供 す る ．CA は ，Web サ ー ビ ス S
の仕組みや内部構造を意識せずに，サービスを利用で
きる．
CA は ， 複 数 の Web サ ー ビ ス を 利 用 す る こ と が で き
る ．ま た ，Web サ ー ビ ス S は ，他 の Web サ ー ビ ス と 連
図 3
プロキシ型
携し，複合的なサービスを提供することもできる．
Web サ ー ビ ス の こ の よ う な 性 質 か ら ， CA と Web サ
ー ビ ス と の 連 携 に お い て は ，複 数 の 方 式 が 考 え ら れ る ．
図 3 に お い て ， CA が ， Web サ ー ビ ス A を 呼 び 出 す 手
順は，以下の通りである．
以 降 で は ， 考 え の 基 礎 と な る 1 つ の CA と 2 つ の Web
サービスとの異なる連携方式について述べる．
1.
2.2. リダイレクト型
CA は ， Web サ ー ビ ス A へ サ ー ビ ス を 要 求 す る
（ 図 3(1)）
1 つ の CA と 2 つ の Web サ ー ビ ス が 連 携 す る と き ，
2.
ま ず ， CA が 一 方 の サ ー ビ ス を 要 求 し ， そ の 応 答 を 一
旦 受 け 取 っ て か ら ， CA が 他 方 の サ ー ビ ス を 要 求 す る
を 要 求 す る （ 図 3(2)）
3.
Web サ ー ビ ス B は ，Web サ ー ビ ス A へ 応 答 す る
（ 図 3(3)）
方式が考えられる．本稿では，このような方式をリダ
イ レ ク ト 型 と 呼 ぶ （ 図 2）．
Web サ ー ビ ス A は ，Web サ ー ビ ス B へ サ ー ビ ス
4.
Web サ ー ビ ス A は ， CA へ 応 答 す る （ 図 3(4)）
3. バ ス 時 刻 表 検 索 サ ー ビ ス の 開 発
本 研 究 で は ， ケ ー ス ス タ デ ィ と し て ， Web サ ー ビ ス
を用いたバス時刻表検索サービスの開発を行った．
3.1. シナリオ
本 シ ス テ ム は ， ユ ー ザ が CA を 操 作 し ， 現 在 時 刻 以
降に最も早く乗車可能なバスの時刻を知ることを目的
と す る バ ス 時 刻 表 検 索 サ ー ビ ス で あ る ．バ ス の 時 刻 は ，
平日，土曜日，日曜・祝日により運行時間が異なる．
従って，バスの時刻を検索するためには，曜日を調べ
なければならず，カレンダーサービスが必要となる．
しかし，カレンダーサービスは，比較的汎用性が高い
図 2
リダイレクト型
た め ， CA 本 体 に 組 み 込 ま ず ， 我 々 が 別 目 的 に 作 成 し
た 既 存 の カ レ ン ダ ー Web サ ー ビ ス を 再 利 用 す る こ と に
図 2 に お い て ，CA が ，2 つ の Web サ ー ビ ス A，B を 呼
した．本システムの特徴は，以下の通りである．
び出す手順は，以下の通りである．
1.
1.
CA は ， Web サ ー ビ ス A へ サ ー ビ ス を 要 求 す る
（ 図 2(1)）
2.
Web サ ー ビ ス A は ， CA へ 応 答 す る （ 図 2(2)）
時 刻 な ど の 入 力 を 省 略 し ， CA を 1 ク リ ッ ク す
るとバスの時刻がわかる
2.
バスの時刻の検索対象を 1 つのバス停に限定
一 方 ， プ ロ キ シ 型 （ 図 5） で は ， ま ず ， ユ ー ザ の 操
3.2. 設 計
本サービスを開発するにあたっては，以下の 3 つの
機能が必要となる．
作 に よ り CA が バ ス 時 刻 表 Web サ ー ビ ス へ 現 在 時 刻 と
年 月 日 を 送 信 す る （ 図 5(1)）． 次 に ， バ ス 時 刻 表 Web
サ ー ビ ス は ， カ レ ン ダ ー Web サ ー ビ ス へ 年 月 日 を 送 信
F1
F2
F3
時刻表検索機能：与えられた曜日と現在時刻か
す る（ 図 5(2)）．次 に ，カ レ ン ダ ー Web サ ー ビ ス は ，受
ら最も早く乗車可能なバスの時刻を検索する
信 し た 年 月 日 に 基 づ き バ ス 時 刻 表 Web サ ー ビ ス へ 曜
機能
日 を 返 答 す る （ 図 5(3)）． そ し て ， バ ス 時 刻 表 Web サ
曜日取得機能：与えられた年月日が平日，土曜
ービスは，受信した現在時刻と曜日に基づいて時刻を
日，日曜日，祝日かを検索する機能
検 索 し ，検 索 結 果 を CA へ 返 答 す る（ 図 5(4)）．最 後 に ，
表示機能：ユーザに結果を表示する機能
CA は ， 結 果 を 表 示 す る ．
F2 に 関 し て は ，前 述 の カ レ ン ダ ー Web サ ー ビ ス を 再 利
用するため，今回新しく開発を行う必要がない．残り
の F1， F3 の 機 能 の 実 装 法 と し て ， 以 下 の 2 通 り が 考
えられる．
図 5
I.
F1 を Web サ ー ビ ス ， F3 を CA と し て 実 装
II.
F1， F3 共 に CA と し て 実 装
プロキシ型バス時刻表検索サービス
ま た ， 上 記 Ⅱ の よ う に ， F1 と F3 を 共 に CA の 中 へ
実装する方法が考えられる．ここでは，この実装方法
Ⅰ は ，F3 の み を CA と し て 実 装 し ，サ ー ビ ス の 核 で あ
を ス タ ン ド ア ロ ン 型 と 呼 ぶ こ と に す る（ 図 6）．ス タ ン
る F1 を Web サ ー ビ ス（ バ ス 時 刻 表 Web サ ー ビ ス と 呼
ド ア ロ ン 型 で は ， ま ず ， ユ ー ザ の 操 作 に よ り CA が カ
ぶ ） 化 す る 方 法 で あ る ． こ の 場 合 ， CA は ， バ ス 時 刻
レ ン ダ ー Web サ ー ビ ス へ 年 月 日 を 送 信 す る （ 図 6(1)）．
表 Web サ ー ビ ス お よ び カ レ ン ダ ー Web サ ー ビ ス の 2 つ
次 に ， カ レ ン ダ ー Web サ ー ビ ス は ， 受 信 し た 年 月 日 に
と連携が必要となる．従って，2 章で述べたリダイレ
基 づ い て 曜 日 を CA へ 返 答 す る（ 図 6(2)）．そ し て ，CA
クト型とプロキシ型の 2 通りの実装が考えられる．
は ，現 在 時 刻 と 受 信 し た 曜 日 に 基 づ い て 時 刻 を 検 索 し ，
ま ず ， リ ダ イ レ ク ト 型 （ 図 4） で は ， 最 初 に ， ユ ー
検索結果を表示する．
ザ の 操 作 に よ り CA が カ レ ン ダ ー Web サ ー ビ ス へ 年 月
日 を 送 信 す る（ 図 4(1)）．次 に ，カ レ ン ダ ー Web サ ー ビ
ス は ， 受 信 し た 年 月 日 に 基 づ い て 曜 日 を CA へ 返 答 す
る（ 図 4(2)）．次 に ，CA は ，バ ス 時 刻 表 Web サ ー ビ ス
へ 現 在 時 刻 と 曜 日 を 送 信 す る（ 図 4(3)）．そ し て ，バ ス
時 刻 表 Web サ ー ビ ス は ，受 信 し た 現 在 時 刻 と 曜 日 に 基
図 6
スタンドアロン型バス時刻表検索サービス
づ い て 時 刻 を 検 索 し ， CA へ 検 索 結 果 を 返 答 す る （ 図
4(4)）． 最 後 に ， CA は ， 結 果 を 表 示 す る ．
3.3. 実 装
3.2 節 で の 設 計 を 基 に ， リ ダ イ レ ク ト 型 バ ス 時 刻 表
検索サービス，プロキシ型バス時刻表検索サービス，
スタンドアロン型バス時刻表検索サービスの 3 種類の
実装を行った．実装環境は，以下の通りである．
言 語 ： Microsoft Visual C# .NET
プ ラ ッ ト フ ォ ー ム ： Microsoft .NET Framework 1.1
Web サ ー バ ： IIS(Internet Information Services)5.1
バ ス 時 刻 表 Web サ ー ビ ス は ，int 型 の 現 在 時 刻（ 時 ・
分 ） と int 型 の 曜 日 コ ー ド （ 平 日 ： 0， 土 曜 日 ： 1， 日
曜 日：2，祝 日：3）を 入 力 す る と 内 部 の バ ス 時 刻 表（ XML
図 4
リダイレクト型バス時刻表検索サービス
フ ァ イ ル ）を 検 索 し ，int 型 で 最 も 早 く 乗 車 可 能 な バ ス
の 時 刻 を 出 力 す る ． CA は ， ユ ー ザ が 操 作 し や す い よ
うに，ボタンを 1 クリックするだけで最も早く乗車可
CA の 実 行 時 間 に 関 し て は ，3 つ の 連 携 方 式 の う ち ，ス
能 な バ ス の 時 刻 が 表 示 さ れ る （ 図 7）．
タンドアロン型が最も優れた結果となった．これは，
ス タ ン ド ア ロ ン 型 で CA が 利 用 す る Web サ ー ビ ス の 数
が他の 2 方式と比べて少ないからであり，アプリケー
シ ョ ン が 利 用 す る Web サ ー ビ ス の 数 が 性 能 に 大 き な
影響を与えることがわかる．
プロキシ型とリダイレクト型の比較では，プロキシ
型の性能が優れていることがわかる．特に，ループ回
数が多い高負荷時には，顕著な差が見られる．また，
い ず れ の 連 携 方 式 に お い て も ，CA の 初 回 の 実 行 に は ，
時間がかかり，ループ回数の増加に応じて 1 回あたり
図 7
の実行時間が減少していることがみとめられた．これ
CA 実 行 画 面
は ， Web サ ー ビ ス が 実 行 さ れ る サ ー バ 上 で ， サ ー ビ ス
のキャッシングが発生していると思われる．詳細な分
4. 評 価 実 験
本章では，実装した 3 種類のバス時刻表サービスを
用 い て 実 験 を 行 い ，性 能 の 比 較 評 価 を 行 う ．実 験 に は ，
析については，今後の課題とする．
次 に ， LOC の 計 測 結 果 を 表 2 に 示 す ．
1 台のサーバを用いた．実験用サーバのスペックは，
表２
以下の通りである．
LOC の 計 測 結 果 （ 行 ）
プロキシ型
CPU： Pentium 4 2.4GHz
LOC
メ モ リ ： 512MB
CA
WS
102(8) 145(35)
リダイレクト型
スタンドアロン型
CA
WS
CA
108(15) 140(30) 199(106)
WS
NA
OS： Windows XP Professional SP1
プ ラ ッ ト フ ォ ー ム ： Microsoft .NET Framework 1.1
各 連 携 方 式 に お い て ，CA の 行 数 お よ び バ ス 時 刻 表 Web
Web サ ー バ ： IIS(Internet Information Services)5.1
サービスのソースコード行数を計測した．3 種類の実
装は，異なる連携方式であるが，同一のシステム機能
今 回 の 実 験 で は ， CA と Web サ ー ビ ス ， Web サ ー ビ ス
を有するため，実装間で共通のコードが存在する．従
同士のネットワークにおける通信時間を無視するため，
って，連携方式独自のコード行数を括弧中に示す．
1 台 の サ ー バ 内 に CA お よ び Web サ ー ビ ス を 全 て 配 置
ま ず ，プ ロ キ シ 型 と リ ダ イ レ ク ト 型 の LOC の 比 較 を
した．
行 う ． CA の 行 数 に 関 し て は ， プ ロ キ シ 型 の 方 が 少 な
4.1. 比 較 項 目 の検 討
い行数で済む．独自のコード行数の比較では，プロキ
実 験 で は ， 各 連 携 方 式 に お け る CA の 実 行 時 間 を 計
シ型のコード行数がリダイレクト型の約半分である．
測 す る ． 実 行 時 間 と は ， ユ ー ザ が CA の ボ タ ン を ク リ
こ れ は ， プ ロ キ シ 型 で は ， CA が 直 接 呼 び 出 す Web サ
ックしてからバスの時刻が表示されるまでの時間であ
ー ビ ス の 数 が 1 つ（ バ ス 時 刻 表 Web サ ー ビ ス の み ）で
る ．実 行 時 間 の 計 測 は ，そ れ ぞ れ 各 連 携 方 式 で 10 回 ず
あるのに対して，リダイレクト型では，2 つ（バス時
つ行い，その平均を計算する．また，高負荷時での連
刻 表 Web サ ー ビ ス お よ び カ レ ン ダ ー Web サ ー ビ ス ）に
携 方 式 の 違 い を 評 価 す る 目 的 で ， Web サ ー ビ ス の 呼 び
なるからである．分離できる処理は，なるべくサービ
出 し 回 数 を 100 回 ，1000 回 と 変 化 さ せ た 場 合 の 実 行 時
ス側に閉じ込め，クライアント側の呼び出しインタフ
間も測定した．さらに，連携方式と保守性との関連を
ェースをなるべくシンプルにするという目的において
考 察 す る た め に ， 各 連 携 方 式 の CA お よ び バ ス 時 刻 表
は，プロキシ型がリダイレクト型より優れているとい
Web サ ー ビ ス の LOC を 計 測 し た ．
える．
ス タ ン ド ア ロ ン 型 で は ， CA が バ ス 時 刻 表 Web サ ー
4.2. 比 較 評 価
ビ ス 部 分 を 全 て 含 む た め ， 他 の 2 方 式 に 比 べ て CA の
実行時間の計測結果を表 1 に示す．
表 1
ループ回数
1
100
1000
コ ー ド 行 数 が 多 く な っ て い る ． 従 っ て ， CA の 実 装 の
容易性および信頼性の観点からは，他の 2 方式に劣る
実行時間の計測結果（秒）
と い え る （ LOC が 大 き い ほ ど バ グ が 含 ま れ や す い ）．
プロキシ型
3.80
5.11
16.98
リダイレクト型 スタンドアロン型
4.06
5.83
21.65
2.48
3.39
11.39
ま た ， F1 と F3 が 密 に 結 合 し て い る た め ， 保 守 性 に 関
する問題も生じる．もし，バスの時刻表が更新された
場 合 ，CA の 全 て の ユ ー ザ は ，CA を 最 新 版 に す る 必 要
が あ る ．一 方 ，他 の 2 方 式 で は ，バ ス 時 刻 表 Web サ ー
ビ ス の 時 刻 表 の み を 更 新 す れ ば 良 く ， CA の 再 イ ン ス
ト ー ル は 不 要 で あ る ． こ の 利 点 は ， Web サ ー ビ ス の 理
念である疎結合によるものである．
4.3. 考 察
実験では，プロキシ型連携方式が，実行時間および
CA の コ ー ド 行 数 の 両 側 面 に お い て ， リ ダ イ レ ク ト 型
より優れていることがわかった．本実験で開発した小
規 模 な Web サ ー ビ ス ア プ リ ケ ー シ ョ ン に お い て ，こ の
2 方式の差は，それほど大きなものではなかった．し
か し ， ２ つ の Web サ ー ビ ス の 連 携 に お い て ， 一 方 の
Web サ ー ビ ス の 出 力 を 他 方 が そ の ま ま 入 力 と し て と る
ような場合，性能面でプロキシ型の利点がより大きく
な る ． な ぜ な ら ば ， リ ダ イ レ ク ト 型 で は ， 2 つ の Web
サ ー ビ ス の デ ー タ 授 受 を CA が 中 継 す る 手 間 が 入 る か
ら で あ る ． 従 っ て ， こ の よ う な 場 合 ， Web サ ー ビ ス の
設計段階において，連携方式が選択可能ならば，プロ
キシ型を選択する方が望ましいと思われる．
今 回 の 開 発 に お い て は ， 新 た に Web サ ー ビ ス を 設
計・開発したため，連携方式の選択が可能であった．
し か し な が ら ，独 立 し た 既 存 の Web サ ー ビ ス を 組 み 合
わ せ て CA か ら 利 用 す る 場 合 に は ， リ ダ イ レ ク ト 型 を
取 ら ざ る を 得 な い ．こ れ は ，公 開 さ れ て い る Web サ ー
ビスを外部から変更できないためである．この連携の
汎用性という意味においては，リダイレクト型が優れ
ているといえる．
ス タ ン ド ア ロ ン 型 と の 比 較 に よ り ，利 用 す る Web サ
ービスの数が性能面に大きな影響を与えることもわか
った．しかし，これは，疎結合による保守性の向上と
トレードオフの関係にあるため，目的に応じた連携方
式の設計が望まれる．
5. お わ り に
本 稿 で は ，同 じ 目 的 を 達 成 す る Web サ ー ビ ス ア プ リ
ケーションを 2 つの異なる連携方式を用いて設計・実
装を行い，その性能評価を行った．
今 後 の 課 題 と し て は ， Web サ ー ビ ス が 実 行 さ れ る サ
ーバ上のサービスのキャッシングについて詳細な分析
を行うことや各連携方式のサービスを実際の運用環境
に近い形で性能評価することである．また，将来的に
は ，Web サ ー ビ ス に お け る サ ー ビ ス 競 合 問 題 の 研 究 に
つなげていきたい．
文
献
[1] Amazon Web Services， http://www.amazon.com/gp/
browse.html/104-0877510-2922306?node=3435361
[2] 青 山 幹 雄 ， “Web サ ー ビ ス 技 術 と Web サ ー ビ ス ネ
ッ ト ワ ー ク ” ， 信 学 技 報 ， IN2002-163 ， pp.47-52，
Jan.2003．
[3] Google Web APIs， http://www.google.com/apis/
[4] 本 多 泰 理 ， 矢 田 健 ， 山 田 博 司 ， “ト ラ ヒ ッ ク フ ロ
ー を 考 慮 し た Web サ ー ビ ス の ネ ッ ト ワ ー ク 構 成
法 の 一 検 討 ”，信 学 会 総 合 大 会 講 演 論 文 集 ，2003-3，
pp.354， Mar.2003．
[5] 和 泉 憲 明 ， 幸 島 明 夫 ， 車 谷 浩 一 ， 福 田 直 樹 ， 山 口
高 平 ， “多 粒 度 リ ポ ジ ト リ に 基 づ く Web サ ー ビ ス
のビジネスモデル駆動連携”，信学技報，
KBSE2002-32， pp.43-48， Jan.2003．
[6] 西 村 徹 ， 堀 川 桂 太 郎 ，“ Web サ ー ビ ス に お け る 境
界 条 件 の 検 査 ”， 信 学 会 総 合 大 会 講 演 論 文 集 ，
2003-6， pp.234， Mar.2003．
[7] XML Web サ ー ビ ス 対 応 Business Travel System パ
イ ロ ッ ト 版 ， http://net.est.co.jp/jtb/about/
[8] XML Web サ ー ビ ス 対 応 三 省 堂 デ イ リ ー コ ン サ イ
ス 体 験 版 ， http://www.btonic.com/ws/