Webアプリケーション統合フレームワークの実装と出張業務支援システムへの適用

全文

(1)2004−IS−90 (5) 2004／11／17. 社団法人情報処理学会研究報告 IPSJ SIG Technical Report. Web アプリケーション統合フレームワークの実装と出張業務支援システムへの適用福田直樹*. 北橋洋三郎** 山口高平*** *静岡大学情報学部 **NTT アドバンステクノロジ ***慶應義塾大学理工学部管理工学科. あらまし：TSIMMIS に代表されるデータ統合のアプローチでは，データの連係に用意されるスキーマの記述力の問題から，データ連係の際にビジネスルール等を介入させることが困難であった．本論文では，データの連係にビジネスルールや人間が介在することが可能な，Ｗｅｂアプリケーション統合フレームワークの実現について述べる．アプリケーション統合の実現に不可欠な，内部共通データ定義を実現するために，アプリケーションの入出力属性とオントロジーを用いた設計支援手法を適用する．本フレームワークを出張業務支援システムの開発に適用し，本フレームワークの有用性を示す．. On Implementing Web Application Integration Framework for Business Trip Support System Naoki Fukuta* Yozaburo Kitahashi** Takahira Yamaguchi*** *Faculty of Informatics, Shizuoka University **NTT Advance Technology Co.Ltd. ***Department of Administration Engineering, Keio University Abstract:. Data integration approaches proposed TSIMMIS etc., suffers a difficulty of. inserting business rule operations and human operations between the data coordinating processes. In this paper, we propose a web application integration framework that enables operations of business rules and humans among the data coordination processes. A design support method for shared data structure definition that plays an important role in web application integration is also proposed. We show the effectiveness of the proposed framework by applying it to business trip support system development. TSIMMIS[Chawathe 94]がある．しかし，デ. １．はじめにこれまでに，データ統合に関する研究が行わ. ータ統合では，データを連携させるためのスキ. れてきた．その一例としては，. ーマが用意されるが，そのデータの連係にはビ. −33−.

(2) イントラネット. インターネットエンドユーザ. ホテル検索ホテル検索乗換案内乗換案内 JR指定席 JR指定席＋予約＋予約【ジョルダン】【ジョルダン】予約予約【旅の窓口】【旅の窓口】【えきねっと】【えきねっと】. ATMENU ATMENU 日帰り旅費請求日帰り旅費請求. ATMENU ATMENU 宿泊旅費請求宿泊旅費請求. 粗粒度のタスク. 細粒度タスク制御（サービス実行部）. 6/6 13:30より静岡大学浜松キャンパス. UI UI Module Module. Page Wrappers. Service Service Processing Processing Module Module. Working Memory. User History. Service Repository. Planning Planning and and Execution Execution Module Module Goal Goal Management Management Module Module. Knowledge Base. 中粒度タスク制御図 1:：Web アプリケーション統合フレームワークの構成. ジネス上のルールや人間の判断を介在させる. た．本フレームワークの有用性を確かめるため. ための仕組みはなく，実世界に副作用を及ぼす. に，企業内システムとインターネット上の幾つ. ようなアプリケーション連携のための基盤と. かのサービスを統合した出張業務支援システ. するには不十分であった．本論文では，データ. ムを構築した．本フレームワークを用いること. 統合のアプローチにおける上述の課題を解決. で，社内システムとインターネット上のアプリ. し，アプリケーション統合を実現するためのフ. ケーションを柔軟に統合できたことを報告す. レームワークを提案する．アプリケーション統. る．. 合を実現するためには，データ統合スキーマのかわりにアプリケーション内部で共通的に利. ２．Ｗｅｂアプリケーション統合フレームワーク. 用するオブジェクト構造を用意する必要があ. 本節では，Ｗｅｂアプリケーション統合フレ. る．我々は，別途開発した共通オブジェクト構. ームワークの設計について述べる．本フレーム. 造をクラス図として設計するための手法を用. ワークの構成を図１に示す．本フレームワーク. い，共通オブジェクト構造に基づいてアプリケ. は，４つのモジュール（UI Module, Service. ーション間の連携を実現し，その連携にビジネ. Processing Module, Planning and Execution. スルールや人間を介在させることのできる枠. Module, Goal Management Module）と４つ. 組みを開発した．さらに，各アプリケーション. のデータベース（ Working Memory, User. が提供するサービスを，その共通オブジェクト. History,. 構造を用いてモデル化することにより，動的な. Base）から構成される．. アプリケーション同士の連携を実現可能とし. −34−. Service. Repository,. Knowledge. Goal Management Module は，ユーザが現.

(3) クラス図. •. オブジェクト. クラスのインスタンス • • •. 場所・・・出発地、出張先駅・・・出発駅、到着駅ルート・・・ルート、ルート候補. スケジュールホテル候補ルートホテル. ホテル：[ホテル1，ホテル2，・・・]. 列車ルート候補リスト. 旅の窓口会員番号電話番号部屋数人数上限金額. 列車ルート：[列車ルート1，列車ルート2，・・・]. 列車リスト列車：[列車1，列車2，・・・]. 用件情報. 場所. 出張用件記述. 宿泊情報. 駅. ルート. 出張用件ホテルの最寄駅個人情報. 列車ルート出発地到着地. 乗り物. 出張日時出張先出張期間. 駅名緯度経度近隣の駅. 周辺情報. 名前出発日時到着日時料金所要時間距離. 出張用件出張期間出張開始日時出張終了日時. コンビニ飲食店. 名前職位姓名姓ふりがな名ふりがな性別連絡先電話番号出発地 JRえきねっと旅の窓口. 出発駅到着駅駅出発日時駅到着日時発着. 料金距離時間. 列車ルート. ルート候補リストルート候補：[ルート1，ルート2，・・・]. 列車. 出発駅到着駅路線名. 船. 出発地到着地. バス. 出発地到着地. 飛行機. 個人情報. ジョルダン入力情報. 列車ルート情報. 名前住所電話番号最寄駅 URL 緯度経度日時駅からの交通手段駅からの距離駅からの時間. 列車リスト：[列車1，列車2，…，列車ｎ] 列車ルート情報. 便名出発地到着地航空会社. ホテル. JRえきねっと席タイプ禁煙/喫煙人数ユーザID パスワード. 特急列車名列車号数予約フラグ. 場所料金目的地までの距離目的地までの時間朝食夕食グレード ID 部屋種別周辺情報予約フラグ. 図 2：共通データ定義のクラスの設計在行っているタスクの最終目的を管理し，ビジ. し，Ｗｅｂアプリケーションとの通信に Page. ネスルールに基づいて，必要に応じて目的の変. Wrapper を利用することにより，構成上の汎. 更をユーザに提示する．たとえば，出張先への. 用性を確保しながら，社内イントラネット上の. 電車での当日の移動経路を探索中に，出張先へ. 業務アプリケーションなどの，様々な種類のＷ. 時間に間に合うように出発すると早朝に出発. ｅｂアプリケーションへの対応が可能となっ. する必要が生じる場合がある．例えばこのとき，. ている．. ビジネスルールで，「往路２００ｋｍ以上の出. 本フレームワークにより，アプリケーション. 張の場合には全日の宿泊が可能」というルール. 連携へのビジネスルールおよび人間の介在が. があった場合，そのルールに則って，ユーザに. 可能となるが，アプリケーション連携プロセス. 前日に出張先近辺に移動し，ホテルを予約する. をどのように規定するかが課題となる．アプリ. よう促すことができる．. ケーション連携プロセスは，対象とするドメイ. 各モジュール間での通信には，共通オブジェ. ンやビジネスルールに依存する．アプリケーシ. クト定義に基づくオブジェクトの受け渡しが. ョン連携プロセスとフレームワークを分離し，. 用いられる．これにより，アプリケーション統. 適用ドメインに応じて柔軟に連携プロセスを. 合におけるデータ連係途上の中間データに対. 構築・修正可能とする必要がある．また，状況. して，ビジネスルールや人間による参照・書き. によってはニーズの個人化等の理由から，あま. 替えおよび統合プロセスの分岐が可能となる．. り頻繁に起きないような連携プロセスが見ら. Service Processing Module を独立した構造と. れる場合があり，そのような連携プロセスの一. −35−.

(4) 出張用件入力画面. 出張用件確認. 修正. 用件情報. 出張用件送信. 用件を解析する. 出張用件記述. 次へ. 出張先出張期間. 1. ルート検索する出張差k. 出張期間出張先出張開始日時出張終了日時. 出張先. 名前住所電話番号最寄駅 URL 緯度経度到着日時駅からの交通手段駅からの距離駅からの時間. 到着地の HPを調べる. 出張先. 名前住所電話番号最寄駅 URL 緯度経度到着日時駅からの交通手段駅からの距離駅からの時間. HPから到着地の最寄駅を調べる. 名前住所電話番号最寄駅 URL 緯度経度到着日時駅からの交通手段駅からの距離駅からの時間. HPから到着地の住所を調べる. If 住所=“”. 4. HPから到着地の電話番号を調べる. 4. 出張先. 名前住所電話番号最寄駅 URL 緯度経度到着日時駅からの交通手段駅からの距離駅からの時間. 出張先. 名前住所電話番号最寄駅 URL 緯度経度到着日時駅からの交通手段駅からの距離駅からの時間. 電話番号から住所を調べる. If 最寄駅=“”. 出発駅. 6. 出発駅到着駅駅出発日時駅到着日時発着. 到着駅. 駅名緯度経度近隣の駅. 到着駅駅名緯度経度近隣の駅. 駅名緯度経度近隣の駅. 駅と出張先との距離を調べる. 出張先. 7. 5. 出発地から駅までの交通手段を決める. 名前住所最寄駅緯度経度出発日時駅までの交通手段駅までの距離駅までの時間. 駅から出張先までの交通手段を決める. 名前住所電話番号最寄駅 URL 緯度経度到着日時駅からの交通手段駅からの距離駅からの時間. 出張先. 出発駅. 個人情報名前職位出発地 JRえきねっと旅の窓口. 駅名緯度経度近隣の駅. ジョルダン入力情報. 出発駅の緯度・経度を調べる. 6. 出発地. 名前住所最寄駅緯度経度出発日時駅までの交通手段駅までの距離駅までの時間. 出発地と駅との距離を調べる. 到着駅の緯度・経度を調べる. 出発駅到着駅駅出発日時駅到着日時発着. データベースから出発地の最寄駅を調べる. 出発地. 到着地のHP. 7. 5. ジョルダン入力情報 else. 名前住所最寄駅緯度経度出発日時駅までの交通手段駅までの距離駅までの時間. 検索エンジン（google）. 出発地. 名前住所電話番号最寄駅 URL 緯度経度到着日時駅からの交通手段駅からの距離駅からの時間. 住所から到着地の最寄駅を調べる. else. 9. 出張先. 名前住所電話番号最寄駅 URL 緯度経度到着日時駅からの交通手段駅からの距離駅からの時間. 10. 名前住所電話番号最寄駅 URL 緯度経度到着日時駅からの交通手段駅からの距離駅からの時間. 住所から出張先の緯度・経度を調べる. 到着地のHP Yahoo!電話帳. 到着地のHP. MapFan. 出発/到着駅の変更. 列車検索条件変更. ルート候補. 出張用件. ルート列車ルート候補リスト. 出発地. 9. 出発地から駅までの時間を計算する. 列車ルート候補：[列車ルート候補1，列車ルート候補2，・・・] 名前住所最寄駅緯度経度出発日時駅までの交通手段駅までの距離駅までの時間. 駅から出張先までの時間を計算する. 駅到着時間を決める. 出発駅到着駅駅出発日時駅到着日時発着. 列車候補を検索する. 列車1. 用件日時場所期間. 出発駅駅名緯度経度近隣の駅. 列車名列車号数列車種別出発駅到着駅駅出発日時駅到着日時路線名. 列車n 列車名列車号数列車種別出発駅到着駅駅出発日時駅到着日時路線名. 14. 14. 出張日時出張先出張期間. If 出張期間=複数日ホテルを検索する. 13. 13. 到着時間を決める. 列車の検索条件を変更する. 列車ルート候補1. 出張先. 名前住所電話番号最寄駅 URL 緯度経度到着日時駅からの交通手段駅からの距離駅からの時間. 検索条件を変更. 出発地列車ルート候補出張先. 列車リスト：[列車1，列車2，…，列車ｎ] 列車ルート情報. 名前住所電話番号最寄駅 URL 緯度経度到着日時駅からの交通手段駅からの距離駅からの時間. 出発/到着日時の変更. 列車1. 列車n 列車名列車号数列車種別出発駅到着駅駅出発日時駅到着日時路線名. 列車名列車号数列車種別出発駅到着駅駅出発日時駅到着日時路線名. 1. 到着駅駅名緯度経度近隣の駅. 近隣の駅を調べる. ホテル周辺の情報を調べる. ホテル： [ホテル1，ホテル 2，・・・]. 17. 個人情報. 旅の窓口. 到着駅. 出発駅. 列車名列車号数列車種別出発駅到着駅駅出発日時駅到着日時路線名. 駅名緯度経度近隣の駅. 駅名緯度経度近隣の駅. ホテル検索をする. 名前職位出発地 JRえきねっと旅の窓口. 列車n 駅名緯度経度近隣の駅. 宿泊到着地旅の窓口. 15. 名前住所電話番号最寄駅 URL 緯度経度到着日時駅からの交通手段駅からの距離駅からの時間. 出発/到着駅の変更. 列車名列車号数列車種別出発駅到着駅駅出発日時駅到着日時路線名. 宿泊情報の生成. 出張先. 出発駅. 列車1. 到着駅. 宿泊日帰宅日検索方法. 宿泊日時を決める. 出発駅到着駅駅出発日時駅到着日時発着. 駅名緯度経度近隣の駅. 宿泊情報ホテル候補. ジョルダン入力情報. ルート候補1. 名前住所最寄駅緯度経度出発日時駅までの交通手段駅までの距離駅までの時間. 出張先. 列車リスト：[列車1，列車2，…，列車ｎ] 列車ルート情報. 用件情報. 列車ルート出発地到着地. ユーザが選択する. 出発到/ 着駅の変更. 10. 出発時間を決める. 12. 列車ルート候補1. 決定. ルート候補：[ルート候補1，ルート候補2，・・・]. 宿泊. 12. 列車ルート候補：[ 列車ルート候補1，列車ルート候補2，・・・]. ジョルダン入力情報. ルート候補の生成. 出発地. 列車ルート候補リスト出張先名前住所電話番号最寄駅 URL 緯度経度到着日時駅からの交通手段駅からの距離駅からの時間. ルート候補リスト. 出発地. 名前住所最寄駅緯度経度出発日時駅までの交通手段駅までの距離駅までの時間. 会員番号電話番号部屋数人数上限金額. 近隣の駅を調べる else. 16 MapFan. 旅の窓口. ジョルダン. ジョルダン. ホテル1. ホテル予約. ホテル1. 予約失敗. If 予約失敗. ホテル1. ホテルホテル候補. 17. ホテル：[ホテル1，ホテル2，・・・]. 緯度・経度を調べる. ホテル1 ホテル名住所料金駅からの時間目的地までの距離目的地までの時間交通手段食事周辺情報緯度経度. ホテル名住所料金駅からの時間目的地までの距離目的地までの時間交通手段食事周辺情報緯度経度. 出張先までの距離を調べる. ホテル名住所料金駅からの時間目的地までの距離目的地までの時間交通手段食事周辺情報緯度経度. 交通手段を決める. ホテル名住所料金駅からの時間目的地までの距離目的地までの時間交通手段食事周辺情報緯度経度. 出張先までの時間を計算する. ホテル名住所料金駅からの時間目的地までの距離目的地までの時間交通手段食事周辺情報緯度経度. 20. 評価する. ホテル： [ホテル1，ホテル2，・・・]. 決定. ユーザが選択する. はい. 15 If 予約成功. 予約する. 列車. 予約失敗列車名列車号数列車種別出発駅到着駅駅出発日時駅到着日時路線名. 21. 21. If 新幹線か特急を利用する. 空席照会をする. 列車予約. If ルート変更. スケジュール. 1. 列車. else If 空席あり. ルートはい. いいえ. 出張先名前住所電話番号最寄駅 URL 緯度経度到着日時駅からの交通手段駅からの距離駅からの時間. ホテル名住所料金駅からの時間目的地までの距離目的地までの時間交通手段食事周辺情報緯度経度. If 空席なし. ホテル候補. ホテル1. ホテル候補. 列車名列車号数列車種別出発駅到着駅駅出発日時駅到着日時路線名. 次へ. 列車ルート出発地到着地. ルート検索する. スケジュール決定. スケジュールの生成列車を予約する. 周辺情報. ホテル検索条件を変更. JRえきねっとコンビニ飲食店. 20. 席タイプ禁煙/喫煙人数ユーザID パスワード. 19. ユーザが選択する. ルートホテル列車の検索条件を変更する. 出発/到着日時の変更. ホテル出発/到着駅の変更. 周辺情報. いいえ. コンビニ飲食店. 特急情報. 特急情報の生成. 列車 JRえきねっと. MapFan 旅の窓口. 図 3：コアサービス連携プロセスのモデル般化は難しい．そこで，サービスの連携プロセ. 下界はすべての属性を含まないもの，上界は全. ス自身にも利用者がある程度介入できるため. ての属性を含むもので，その間の要素は各属性. の仕組みも構築する必要が出てくる．. を含むか否かの組み合わせ集合である．ここで，属性の包含関係に基づいて，初期クラスの親ク. ３．共通オブジェクト定義の設計手法. ラスとなるべき候補が提示され，その支援に基. 本フレームワークを設計するにあたり，各モジュール間でのやりとりに共通オブジェクト. づいて人間が初期クラス図から１段洗練されたクラス図を設計する． Lattice 上への割り付けによって洗練された. 定義の存在を仮定している．我々は，文献 [Minegishi 04]で，共通オブジェクト定義を，. クラス図は，汎用オントロジーとの関係が比較. 利用するアプリケーション（サービス）の入出. され，クラスが含む属性の選択方法，上位下位. 力の組と，汎用のオントロジーを用いて構築支. 関係の汎用オントロジーとの矛盾等が指摘さ. 援する手法を提案している．本節ではその支援. れる．この洗練プロセスを経て，共通オブジェ. 手法の概要を述べる．. クト定義としてのクラス設計が得られる．. 本支援手法では，最初に各サービスの持つ入力，出力をそれぞれ１つの単位として，初期ク. ４．出張業務支援システム構築への適用. ラスとする．この初期クラスには，互いのデー. 本フレームワークを，出張業務支援システム. タの重複や不整合が多数残っている．本誌園手. の構築に適用した．会社内の出張業務では，会. 法では，最初に，これらの初期クラスの持つ属. 議日程の調整等の出張に依存しない業務の他. 性間の包含関係を Lattice 空間上に割り付け，. に，出張先への経路・旅費の調査，旅費の精算. 大まかなクラス階層を構成する．ここで，. のための手続き，出張許可手続き等の煩雑な業. Lattice は全属性集合のべき集合から構成され，. 務が存在する．従来は，これらの業務を個別の. −36−.

(5) web. 結果の表示 Webサイトへアクセス. 要求の入力. UI module. 実行結果. Service Wrapper. Service Wrapper. Service Wrapper. Converter. Service Wrapper. 値の変換. 入力の書き込みサービス実行仕様の抽出. 値の読み書き UH. 要求文解析モジュール. サービス検索モジュール. サービス実行モジュール. WM. Service Repository. 係り受け解析. 語彙の変換. Convert Ontology. CaboCha. 変換された語彙. 図 4：サービス発見機構Ｗｅｂアプリケーション等を人間が直接利用. ョン）を収集した．収集したサービスから，特. することで行ってきていた．しかし，各Ｗｅｂ. に出張業務支援タスクに中心的な役割を果た. アプリケーションを利用するたびに，出張日程. すサービスを選び，それらを元に３節で述べた. 等の共通の情報を何度も入力し直す必要があ. 共通オブジェクト定義の設計手法に基づいて. り，作業の効率化が求められていた．また，イ. 共通オブジェクトのクラス設計を行った．図 2. ンターネット上のＷｅｂアプリケーションに. が，結果として設計されたクラス図である．本. は，その社内固有のビジネスルールを考慮して. クラス図では特に内部で持つ属性に着目し，メ. おらず，特定のＷｅｂアプリケーションによっ. ソッドの表記は省略している．また，クラスの. て得られた情報がビジネスルールに則ってい. 継承関係を見やすくするために，クラス間の関. るかを手作業で確認する必要があった．本シス. 係記述を属性記述で代用している．構成された. テムでは，このような出張業務に置ける非効率. クラス図は，最上位のオブジェクト型を除き，. 性を改善し，複数のＷｅｂアプリケーションを. ２６のクラスから構成された．. ビジネスルールに則ってシームレスに利用でき，データの無駄な転記操作を省略可脳とする．. 4.2 出張業務におけるコアサービス連携プロセスのモデル化. 4.1 出張業務支援タスクにおける共通データ. 出張業務支援における典型的なサービス利用の連携プロセスをモデル化した．図 3 では，. 定義システム構築に先立ち，出張業務支援のタスクに利用可能なサービス（Ｗｅｂアプリケーシ. モデル化したプロセスを，ユーザとの対話過程，サービスの呼び出し，およびそこで受け渡され. −37−.

(6) サービス記述仕様. optionalService service object. 目的語サービスの検索. 述語. Service Repository. 整形目的語. task. サービス実行仕様. サービス検索モジュール. 入力情報. input. 変数値の格納場所（UH/WM内の場所）この値とのマッチングを行う変数名. <optionalServices> <service name="MapFan"> <object value="周辺情報" /> <task value="検索" /> <input> <para name=“address” value=“Schedule.location” converterName="" /> <para name=“genre” value=“WM.MapFan.Genre” converterName="MapFanConverter_1" /> <para name=“gsub” value=“WM.MapFan.GSub” converterName="MapFanConverter_2" /> </input> </service> </optionalService>. コンバータ名. サービス記述例. 図 5：サービス仕様の記述るデータの連係プロセスを図示した場合の，プ. 常，サーバサイドプログラムではユーザに提示. ロセスの概観を示している．プロセスは３段に. する画面がプログラムの単位となっており，処. わたった一続きの流れを持っており，各列の真. 理のみを行いユーザに情報を提示しないプロ. ん中の長四角が１つのプロセスを表現し，その. グラムは頻繁には用いられない．本フレームワ. 上方向へのリンクがユーザとの対話を，下方向. ークでは，サービス連携プロセスとプログラム. へのリンクがサービスの呼び出しを意味して. の構成単位を一致させることにより，サービス. いる．図中から，サービスを頻繁に呼び出す部. 連携プロセスからのプログラムの構成を用意. 分と，プロセス内部でのビジネスルールに基づ. とした．. く処理を行う部分とが存在することがわかる． 4.4 サービス発見機構による動的なサービス 4.3 サービス連携プロセスに基づくアプリケ. 連携の実現 4.3 節までで構築したサービス連携プロセス. ーションの半自動構成モデル化したコアサービスの連携プロセス. は，典型的な場合に対応できるが，頻度の少な. に基づき，本フレームワーク上にシステムを半. い，個別のニーズに対応するためのサービス連. 自動で構成できるようにするために，実装コー. 携は実現されない．ユーザからのニーズに応じ. ドとモデルとの対応づけを行った．本対応づけ. てサービスを検索し，アドホックなサービスの. では，１つのユーザとの対話画面，およびプロ. 連携を実現するために，サービス発見機構を用. セス内での処理が，それぞれ１つのサーバサイ. 意した（図 4）．サービス発見機構は，サービ. ドプログラムと対応づけられるようにした．通. スリポジトリ内に蓄えられたサービスの入出. −38−.

(7) 力対と，それぞれの入出力属性に対する概念階. 応はラッパー構築上の大きな負担となる．. 層を利用し，語彙変換を行うことにより，必要. 本システムでは，ブラウザの振る舞いを模倣. なサービスをリポジトリ内から探し出して実. するコンポーネントである HTTP Unit を利用. 行する．ユーザからの入力は，専用のユーザイ. することで，ラッパー構築を容易にしている．. ンタフェースから自然言語文として与えられ，. 本コンポーネントはもともとＷｅｂアプリケ. CaboCha[CaboCha]による係り受け解析結果. ーションの動作検証を行うために設計された. からパターン照合によって検索すべきサービ. ものであるが，Ｗｅｂページからの値の取得か. スの要求が取得される．その要求とサービスリ. ら，ボタン押下等の操作の模倣までを内部で行. ポジトリ内のサービスの用途や入出力属性と. うことができる．ラッパー自身は，Ｗｅｂアプ. の概念レベルでの照合が行われ，適切と思われ. リケーションから得られた値の変換処理を記. るサービスが検索される．次に，. 述する必要なため，プログラムとして記述され. WorkingMemory(WM)から，連携可能な一時. るが，本コンポーネントを用いることで，開発. データが照合され，サービス連携の際に自動で. 者は実際のＷｅｂアプリケーション上での操. 利用される．サービスの呼び出しは Service. 作に近い形でラッパーを記述することができ，. Processing Module によって行われる．. ラッパー構築にかかる負担が軽減された．. ４．５サービス仕様の記述. ５出張業務支援システムのユーザインタフェース. ４．３節のサービス連携プロセスの実行，および４．４節での動的なサービス検索と実行に. 本システムは，出張先までの列車乗り換え案内，. おいて，サービスリポジトリ内にあるサービス. 特急列車予約，およびホテル予約サービス等を. 仕様記述が参照される．本システムに置けるサ. 連携して検索するサービス（コアサービス部）. ービス仕様記述の概要を図 5 に示す．本サービ. と，コアサービス部で決定した出張スケジュー. ス仕様では，サービスの対象，タスク，入出力. ルに関連する他の情報を検索するサービス（オ. 属性が記述される．入出力属性には，. プショナルサービス部）に分かれる．図 6 に，. WorkingMemory に格納される一時データで. 本システムの概観を示す．. 連係される可能性のある項目が列挙され，値の変換が必要な場合には変換処理機構（コンバータ）が記述される．４．６サービス実行部の実現サービス実行部（ Service Processing Module）では，既存のＷｅｂアプリケーションとの相互通信を実現する必要がある．Ｗｅｂアプリケーションとの通信方法には，ラッパーと呼ばれるデータ相互変換機構を利用するが，ラッパーの構成にかかるコストが問題となる．特に，複雑な構造の HTML 文書を出力するＷｅｂアプリケーションや，JavaScript，フレームを利用するＷｅｂアプリケーションへの対. −39−. 図 6：出張業務支援システムの概観.

(8) ６．おわりに. 言える．またユーザにとっても，これまでユー. インターネット上で提供される従来型のサ. ザ自身が利用してきたサービスが組み込まれ. ービスは，その HTML ベースのインタフェー. ていることで，ユーザにとって親和性の高い使. スがユーザと直接インタラクションを行うこ. 用感や安心感を得られるメリットがある．. とを前提としたものであるため，再利用性に乏. 本論文では，出張業務支援における事例につ. しく相互接続性はほとんど考慮されていない．. いてのみ述べている．本論文で挙げた事例では，. したがって利用者はサービス間を“渡り歩く”. 扱うデータが比較的汎用オントロジーに含ま. 必要があり，同様の情報を何度も入力させられ. れやすいドメインであったため，提案手法がう. るなど，エンドユーザに負担を強いる局面が少. まく機能したと考えられる．汎用オントロジー. なくない．. でのカバーが難しいドメイン，およびその領域. またサービスベンダ／インテグレータの見. 特有のオントロジーが存在するドメインでの. 地からも，サービス間の連携や拡張が容易でな. 提案手法の有効性の検証は，今後の課題である．. いことから，独自のサービス仕様 (インタフェ. 現在，ゲノム情報学，および社内のレガシーア. ース) による顧客の囲い込みを図り，ハイパー. プリケーション統合に同様の設計手法が適用. リンクを設置するなどの低位の連携に留まる. できないかを検討中である．. 例が多い．このように，インターネット上には. 謝辞. これまで多種多様なサービスリソースが膨大. 本研究の一部は，平成１４年～１５年度新. に蓄積されてきたにも関わらず，それらを充分. エネルギー・産業技術総合機構大学発事業創出. に活用するためのフレームワークが存在して. 実用化研究開発事業「ユーザのニーズを駆動源. いないのが実情である．. としたウェブサービスの動的連携とその流通. これに対して本システムでは，既存の Web. 基盤に関する研究開発」による支援を受けた．. サービスの種々雑多なインタフェースをラッ. 参考文献. パーによって隠蔽することにより，既存のサー. [Chawathe 94] S. Chawathe, H. Garcia. ビスリソースに高位の相互接続性を追加する. -Molina. and. J.. Widom.. "Flexible. ことを可能にしている．従って，関連する機能. Constraint. を提供していながら，これまでは独自のインタ. Autonomous Distributed Databases ".. フェースを有していたために連携が不可能で. IEEE Data Engineering Bulletin, Vol. 17,. あったサービス間であっても，意味レベルのデ. No. 2, pp. 23-27, June 1994.. Management. for. ータを「緩やかに」共有できるようになり，そ. [CaboCha] http://chasen.org/~taku/software/cabocha/. れらがあたかも一つのサービスであるかのよ. [Minegishi 04] S. Minegishi, N. Fukuta, T.. うにシームレスに連携を行うことができる．. Iijima, and T. Yamaguchi, ``Acquiring. このようにして，既存の膨大なインターネット. and Refining Class Hierarchy Design of. 資産を利活用することにより，新たなサービス. Web Application Integration Software'',. を独自に立ち上げたり，サービス事業者に対し. Proc. of 5th International Conference on. てインタフェースの仕様変更を求めることな. Practical. く，安価で迅速にサービスを開始できることは. Management, Vienna, Austria, 2004 (to. 本研究の事業化時における大きなメリットと. appear.). −40−. Aspects. on. Knowledge.

(9)