(57)【要約】      （修正有）【課題】システム更改を行うことなく、ＧＵＩ制御によるシステム連携におけるスケーラビリティを確保する。【解決手段】マスタ管理部６により、マスタ仮想端末をマスタ仮想端末保管部１１に保管させ、その追加や削除、マスタ仮想端末への被連携アプリケーションの配置、シナリオの作成や配置を実行し、連携制御部７により、マスタ仮想端末のクローンをワーカ仮想端末としてワーカ仮想端末保管部１２に保管させ、外部からの要求に応じてワーカ仮想端末を選択し、シナリオ実行の命令を振り分けることで連携を制御し、ＧＵＩ制御の制約情報に応じてワーカ仮想端末の作成、削除もしくはリソース変更を実施し、連携制御モジュールにより、連携制御部７からの命令に応じて、シナリオを格納するためのシナリオＤＢ中のシナリオを実行して被連携アプリケーションのＧＵＩを制御することで当該被連携アプリケーションを自動操作する。【選択図】図１
2015088093.tif 000002
【特許請求の範囲】
【請求項１】
既存のシステム間または既存のシステムとサービスを連携するシステム連携装置であって、
連携させたい既存のシステムまたはサービスを実現するアプリケーションである被連携アプリケーションが動作する端末を模擬する仮想端末であって、当該被連携アプリケーションに対応するプラットフォームを有するとともに当該被連携アプリケーションが配置されたマスタ仮想端末を少なくとも一つ保管するマスタ仮想端末保管部と、
管理者が前記マスタ仮想端末保管部を管理するためのユーザインターフェースを具備し、マスタ仮想端末の追加もしくは削除、マスタ仮想端末への被連携アプリケーションの配置、または被連携アプリケーションを制御するためのＧＵＩ制御プログラムであるシナリオの作成もしくは配置を実行するマスタ管理部と、
前記マスタ仮想端末のクローンをワーカ仮想端末として保管するワーカ仮想端末保管部と、
外部からの要求に応じて当該要求を処理するワーカ仮想端末を選択し、当該選択したワーカ仮想端末に対してシナリオ実行の命令を振り分けることで連携を制御するとともに、要求数の変化、ワーカ仮想端末の状態およびＧＵＩ制御の制約情報に応じてワーカ仮想端末の作成、削除もしくはリソース変更を実施し、スケーラビリティを確保する連携制御部と、
前記マスタ仮想端末およびワーカ仮想端末に各々配置され、シナリオを格納するためのシナリオＤＢと、シナリオを実行して被連携アプリケーションのＧＵＩを制御することで当該被連携アプリケーションを自動操作するＧＵＩ制御部とを具備し、前記連携制御部からの命令に応じてシナリオを実行する連携制御モジュールとを備えた
ことを特徴とするシステム連携装置。
【請求項２】
前記連携制御部は、
要求数の変化、ワーカ仮想端末の状態およびＧＵＩ制御の制約情報に応じて、ワーカ仮想端末の作成、削除もしくはリソース変更を定期的に実行するワーカ制御部と、
要求数の変化、ワーカ仮想端末の状態およびＧＵＩ制御の制約情報に応じて、外部から要求を受け取るたびに当該要求を処理するワーカ仮想端末を選択してその要求を振り分けることで処理を分散させる分散処理制御部と、
外部に対してシナリオを呼び出すためのＷｅｂインターフェースを提供するとともに、当該Ｗｅｂインターフェースから入力される要求を取得し、各シナリオに対する要求総数および／または要求数の時間変化を記録するとともに、要求を前記分散処理制御部へ橋渡しをするＩＦ制御部とを具備する
ことを特徴とする請求項１に記載のシステム連携装置。
【請求項３】
前記ワーカ制御部として、
ＩＦ制御部が記録している要求の監視結果として、各シナリオに対する要求総数および要求数の時間変化を取得するステップと、
ワーカ仮想端末保管部に作成されているワーカ仮想端末の監視結果として、少なくとも各ワーカ仮想端末のＣＰＵ負荷およびメモリ使用量、並びにワーカ仮想端末内の連携制御モジュールのキューの要素数を取得するステップと、
ＧＵＩ制御の制約として、シナリオの同時実行制約と、アプリケーションの多重起動制約と、アプリケーションの互換制約と、シナリオの環境作用制約とからなる制約情報を取得するステップと、
これらの情報およびワーカ仮想端末保管部の空き容量を考慮して、少なくとも待機ジョブ方式または制約重み付け方式のいずれかによって配置するワーカ仮想端末を決定し、
ワーカ仮想端末の作成、削除またはリソースの変更を実施してワーカ仮想端末を再配置するステップと、
これら一連のステップを一定周期で実施するために待機するステップと、
前記ワーカ仮想端末の再配置のステップに適用するワーカ再配置方式を動的に読み込むステップとを実行するワーカ制御部を具備する
ことを特徴とする請求項２に記載のシステム連携装置。
【請求項４】
前記分散処理制御部として、
ＩＦ制御部が記録している要求の監視結果として、各シナリオに対する要求総数および要求数の時間変化を取得するステップと、
ワーカ仮想端末保管部に作成されているワーカ仮想端末の監視結果として、少なくとも各ワーカ仮想端末のＣＰＵ負荷およびメモリ使用量、並びにワーカ仮想端末内の連携制御モジュールのキューの要素数を取得するステップと、
ＧＵＩ制御の制約情報として、シナリオの同時実行制約と、アプリケーションの多重起動制約と、アプリケーションの互換制約と、シナリオの環境作用制約とからなる制約情報を取得するステップと、
これらの情報から、ＩＦ制御部から渡された要求を処理するワーカ仮想端末を少なくとも固定配置方式、要求数比例方式または制約重み付け方式のいずれかによって選択し、選択したワーカ仮想端末の連携制御モジュールにシナリオ実行を命令するステップと、
これら一連のステップを要求がＩＦ制御部に到着するたびに実施するために待機するステップと、
前記ワーカ仮想端末を選択するステップに適用するワーカ選択方式を動的に読み込むステップとを実行する分散処理制御部を具備する
ことを特徴とする請求項２に記載のシステム連携装置。
【請求項５】
前記連携制御モジュールとして、
分散処理制御部からのシナリオ実行命令を１つのジョブとして、ジョブをＦＩＦＯのキューに挿入するステップと、
これから実行するジョブをキューから取得するステップと、
プラットフォームの状態を取得するステップと、
前記取得した情報をもとに、ジョブ実行の可否を判断するステップと、
ジョブ実行が否と判断された場合には、プラットフォームの状態を取得するステップに戻り、ジョブ実行が可と判断された場合には、シナリオＤＢから実行するシナリオを読み込むステップと、
制御対象の被連携アプリケーションを起動するステップと、
任意の既存自動操作技術により、読み込んだシナリオの操作内容に沿って被連携アプリケーションを自動操作し、自動操作の結果を取得して分散処理制御部に返却するステップとを実行する連携制御モジュールを具備する
ことを特徴とする請求項２に記載のシステム連携装置。
【請求項６】
コンピュータを、請求項１乃至５のいずれかに記載のシステム連携装置の各部として機能させるためのプログラム。
【請求項７】
既存のシステム間または既存のシステムとサービスを連携するシステム連携方法であって、
マスタ管理部により、連携させたい既存のシステムまたはサービスを実現するアプリケーションである被連携アプリケーションが動作する端末を模擬する仮想端末であって、当該被連携アプリケーションに対応するプラットフォームを有するとともに当該被連携アプリケーションが配置されたマスタ仮想端末を少なくとも一つマスタ仮想端末保管部に保管させるとともに、マスタ仮想端末の追加もしくは削除、マスタ仮想端末への被連携アプリケーションの配置、または被連携アプリケーションを制御するためのＧＵＩ制御プログラムであるシナリオの作成もしくは配置を実行するステップと、
連携制御部により、マスタ仮想端末のクローンをワーカ仮想端末としてワーカ仮想端末保管部に保管させ、外部からの要求に応じて当該要求を処理するワーカ仮想端末を選択し、当該選択したワーカ仮想端末に対してシナリオ実行の命令を振り分けることで連携を制御するとともに、要求数の変化、ワーカ仮想端末の状態およびＧＵＩ制御の制約情報に応じてワーカ仮想端末の作成、削除もしくはリソース変更を実施し、スケーラビリティを確保するステップと、
連携制御モジュールにより、前記連携制御部からの命令に応じて、前記マスタ仮想端末およびワーカ仮想端末に各々配置され、シナリオを格納するためのシナリオＤＢ中のシナリオを実行して被連携アプリケーションのＧＵＩを制御することで当該被連携アプリケーションを自動操作するステップとを備えた
ことを特徴とするシステム連携方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、既存のシステムやサービスを連携・統合する技術に関する。
【背景技術】
【０００２】
システム連携は業務効率化において欠かせない技術であり、多くの業務システムが連携している。しかし、業務システムの多くは作成段階において他のシステムとの連携を想定しておらず、連携のためのインターフェースである連携用インターフェースを具備していないことが多い。また、連携用インターフェースを具備している場合でも、システムの運用方法は日々変化するため、具備されている連携用インターフェースだけでは業務プロセスに適した連携を提供できない。
【０００３】
このような問題を解決するために、ＳＯＡ（サービス・オリエンテッド・アーキテクチャ）等が提唱されているが、そのソリューションの多くはシステムインテグレーターの介入のもとで大幅なシステム更改を必要とするためにコストが大きい。さらに、本社で開発したシステムを全国の支店で利用するような環境では、支店毎にシステム運用や業務プロセスが異なるため、ＳＯＡのような全体最適化のアプローチによって全支店の運用に合ったシステム更改を実現するのは困難であった。
【０００４】
［従来技術］
大規模なシステム更改を不要にして既存のシステムやサービスの連携を実現する従来技術として、ラッピング技術（非特許文献１、２参照）が提案されている。従来技術では、対象となるシステムのキャラクターユーザインターフェースやＷｅｂユーザインターフェースといったユーザインターフェース（ＵＩ）を制御して当該システムを自動操作することで、連携用インターフェースを持たない古いシステム（レガシーシステム）やＷｅｂシステムを連携可能とした。さらに、システムへの改造が不要となり、自動操作の内容を変えることで任意の連携用インターフェースをいつでも作成することが可能となった。
【０００５】
一方で、ＵＩを制御してシステムを自動操作するというアプローチに起因する課題もあり、その解決が求められている。例えば、ＵＩ制御によりシステムを自動操作する処理はオーバヘッドが大きく、応答が遅くなることが指摘されており、非特許文献３にて対策が提案されている。しかしこれまで、特にグラフィカルユーザインターフェース（ＧＵＩ）を備えるシステムの連携においてスケーラビリティを実現する方法が検討されてこなかった。それ故、従来技術では、規模（システム連携を利用するユーザ数や連携用インターフェースへの要求数）に応じて、汎用的に連携サービスを提供することが困難であるという問題が解決されていない。
【０００６】
従来技術の問題について図３、図４を用いて説明する。図３はＧＵＩ制御によるシステムの自動操作の概要を示したものである。ＧＵＩ制御では、ＧＵＩ制御プログラム（シナリオ）に制御対象のシステムへの自動操作の手順を記述し、その手順に沿って当該制御対象のシステムを実現するアプリケーション・プログラム（以下、アプリケーション）である被連携アプリケーションのＧＵＩ部品（ボタンやエディット等）を操作する。
【０００７】
そして、ＧＵＩ制御によるシステム連携では、図４（ａ）に示すように連携したシステムを実際にユーザが利用するための連携ＡＰからの要求を連携用インターフェースを経由してシステム連携装置が受けて被連携アプリケーションを端末内で起動し、ＧＵＩ制御によって自動操作することで連携を実現する。
【０００８】
先に述べた非特許文献３は、単一の要求が発生してから自動操作が完了するまでの応答時間を高速化する提案である。しかし、連携ＡＰの利用者数が増加し、単位時間あたりの要求数が増えるなど、システム連携利用の規模そのものが拡大した場合には、ＧＵＩ制御による制約によって大幅な遅延が発生する。その一例を示したのが図４（ｂ）である。
【０００９】
図４（ｂ）の例ではＧＵＩ制御の制約として、既に別のシナリオが実行中の場合、即ち既に制御中のＧＵＩが端末内に存在する場合、新たにシナリオを実行できないことである。この場合は、端末内のＧＵＩ制御が完了するのを待ってから次のシナリオを実行することになり、システム連携利用の規模そのものが拡大した場合には大幅な遅延が発生する。
【発明の概要】
【発明が解決しようとする課題】
【００１０】
そこで本発明では、大規模なシステム更改を不要にしたＧＵＩ制御によるシステム連携において、スケーラビリティの確保を実現するという課題を解決する。
【課題を解決するための手段】
【００１１】
本発明によるシステム連携の基本的な考え方は、図５に示すように、仮想環境を利用してシナリオや被連携アプリケーションを配置したマスタ仮想端末（元となる仮想端末）を作成し、当該マスタ仮想端末のクローンであるワーカ仮想端末をシステム連携利用の規模に応じた数だけ設け、ワーカ仮想端末毎にシナリオ実行を振り分けることでスケーラビリティを実現するものである。しかし、単にワーカ仮想端末の数を増減するだけではスケーラビリティを確保することは難しく、本発明では種々のＧＵＩ制御による制約を考慮した上で、仮想端末の配置やシナリオ実行の割り振りを実現することでスケーラビリティを確保する。
【００１２】
具体的には、
既存のシステム間または既存のシステムとサービスを連携するシステム連携装置であって、
連携させたい既存のシステムまたはサービスを実現するアプリケーションである被連携アプリケーションが動作する端末を模擬する仮想端末であって、当該被連携アプリケーションに対応するプラットフォームを有するとともに当該被連携アプリケーションが配置されたマスタ仮想端末を少なくとも一つ保管するマスタ仮想端末保管部と、
管理者が前記マスタ仮想端末保管部を管理するためのユーザインターフェースを具備し、マスタ仮想端末の追加もしくは削除、マスタ仮想端末への被連携アプリケーションの配置、または被連携アプリケーションを制御するためのＧＵＩ制御プログラムであるシナリオの作成もしくは配置を実行するマスタ管理部と、
前記マスタ仮想端末のクローンをワーカ仮想端末として保管するワーカ仮想端末保管部と、
外部からの要求に応じて当該要求を処理するワーカ仮想端末を選択し、当該選択したワーカ仮想端末に対してシナリオ実行の命令を振り分けることで連携を制御するとともに、要求数の変化、ワーカ仮想端末の状態およびＧＵＩ制御の制約情報に応じてワーカ仮想端末の作成、削除もしくはリソース変更を実施し、スケーラビリティを確保する連携制御部と、
前記マスタ仮想端末およびワーカ仮想端末に各々配置され、シナリオを格納するためのシナリオＤＢと、シナリオを実行して被連携アプリケーションのＧＵＩを制御することで当該被連携アプリケーションを自動操作するＧＵＩ制御部とを具備し、前記連携制御部からの命令に応じてシナリオを実行する連携制御モジュールとを備えたことを特徴とする。
【００１３】
また、前記連携制御部は、
要求数の変化、ワーカ仮想端末の状態およびＧＵＩ制御の制約情報に応じて、ワーカ仮想端末の作成、削除もしくはリソース変更を定期的に実行するワーカ制御部と、
要求数の変化、ワーカ仮想端末の状態およびＧＵＩ制御の制約情報に応じて、外部から要求を受け取るたびに当該要求を処理するワーカ仮想端末を選択してその要求を振り分けることで処理を分散させる分散処理制御部と、
外部に対してシナリオを呼び出すためのＷｅｂインターフェースを提供するとともに、当該Ｗｅｂインターフェースから入力される要求を取得し、各シナリオに対する要求総数および／または要求数の時間変化を記録するとともに、要求を前記分散処理制御部へ橋渡しをするＩＦ制御部とを具備することを特徴とする。
【００１４】
また、前記ワーカ制御部として、
ＩＦ制御部が記録している要求の監視結果として、各シナリオに対する要求総数および要求数の時間変化を取得するステップと、
ワーカ仮想端末保管部に作成されているワーカ仮想端末の監視結果として、少なくとも各ワーカ仮想端末のＣＰＵ負荷およびメモリ使用量、並びにワーカ仮想端末内の連携制御モジュールのキューの要素数を取得するステップと、
ＧＵＩ制御の制約として、シナリオの同時実行制約と、アプリケーションの多重起動制約と、アプリケーションの互換制約と、シナリオの環境作用制約とからなる制約情報を取得するステップと、
これらの情報およびワーカ仮想端末保管部の空き容量を考慮して、少なくとも待機ジョブ方式または制約重み付け方式のいずれかによって配置するワーカ仮想端末を決定し、
ワーカ仮想端末の作成、削除またはリソースの変更を実施してワーカ仮想端末を再配置するステップと、
これら一連のステップを一定周期で実施するために待機するステップと、
前記ワーカ仮想端末の再配置のステップに適用するワーカ再配置方式を動的に読み込むステップとを実行するワーカ制御部を具備することを特徴とする。
【００１５】
また、前記分散処理制御部として、
ＩＦ制御部が記録している要求の監視結果として、各シナリオに対する要求総数および要求数の時間変化を取得するステップと、
ワーカ仮想端末保管部に作成されているワーカ仮想端末の監視結果として、少なくとも各ワーカ仮想端末のＣＰＵ負荷およびメモリ使用量、並びにワーカ仮想端末内の連携制御モジュールのキューの要素数を取得するステップと、
ＧＵＩ制御の制約情報として、シナリオの同時実行制約と、アプリケーションの多重起動制約と、アプリケーションの互換制約と、シナリオの環境作用制約とからなる制約情報を取得するステップと、
これらの情報から、ＩＦ制御部から渡された要求を処理するワーカ仮想端末を少なくとも固定配置方式、要求数比例方式または制約重み付け方式のいずれかによって選択し、選択したワーカ仮想端末の連携制御モジュールにシナリオ実行を命令するステップと、
これら一連のステップを要求がＩＦ制御部に到着するたびに実施するために待機するステップと、
前記ワーカ仮想端末を選択するステップに適用するワーカ選択方式を動的に読み込むステップとを実行する分散処理制御部を具備することを特徴とする。
【００１６】
また、前記連携制御モジュールとして、
分散処理制御部からのシナリオ実行命令を１つのジョブとして、ジョブをＦＩＦＯのキューに挿入するステップと、
これから実行するジョブをキューから取得するステップと、
プラットフォームの状態を取得するステップと、
前記取得した情報をもとに、ジョブ実行の可否を判断するステップと、
ジョブ実行が否と判断された場合には、プラットフォームの状態を取得するステップに戻り、ジョブ実行が可と判断された場合には、シナリオＤＢから実行するシナリオを読み込むステップと、
制御対象の被連携アプリケーションを起動するステップと、
任意の既存自動操作技術により、読み込んだシナリオの操作内容に沿って被連携アプリケーションを自動操作し、自動操作の結果を取得して分散処理制御部に返却するステップとを実行する連携制御モジュールを具備することを特徴とする。
【発明の効果】
【００１７】
本発明により、システム更改を必要としないＧＵＩ制御によるシステム連携において、スケーラビリティの確保が可能となる。これにより、各現場の運用や規模に応じたシステム連携サービスをより容易に提供可能となり、業務効率化を強力に推進できる。
【図面の簡単な説明】
【００１８】
【図１】本発明のシステム連携装置の実施の形態の一例を示す構成図
【図２】図１のシステム連携装置の詳細を示す構成図
【図３】従来のＧＵＩ制御によるシステムの自動操作の概要を示す説明図
【図４】従来のＧＵＩ制御によるシステム連携の一例を示す説明図
【図５】本発明によるシステム連携の基本的な考え方を示す説明図
【図６】ＧＵＩ制御における制約を示す説明図
【図７】ＧＵＩ制御における“同時実行制約（制約１）”の説明図
【図８】シナリオの同時実行可／不可の例を示す説明図
【図９】ＧＵＩ制御における“多重起動制約（制約２）”の説明図
【図１０】被連携アプリケーションの多重起動可能／不可能の例を示す説明図
【図１１】ＧＵＩ制御における“互換制約（制約３）”の説明図
【図１２】被連携アプリケーションの起動可能な互換プラットフォームの例を示す説明図
【図１３】ＧＵＩ制御における“環境作用制約（制約４）”の説明図
【図１４】ＧＵＩ制御における“環境作用制約（制約４）”の説明図
【図１５】シナリオ実行時の環境による副作用の例を示す説明図
【図１６】ワーカ制御部の動作フローチャート
【図１７】分散処理制御部の動作フローチャート
【図１８】連携制御モジュールの動作フローチャート
【図１９】固定配置方式によるワーカ再配置の例を示す説明図
【図２０】要求数比例方式によるワーカ再配置の例を示す説明図
【図２１】制約重み付け方式によるワーカ再配置の例を示す説明図
【図２２】待機ジョブ数方式による最適ワーカ選択の例を示す説明図
【図２３】制約重み付け方式による最適ワーカ選択の例を示す説明図
【発明を実施するための形態】
【００１９】
本発明の一実施の形態について図面を参照して説明する。
【００２０】
図１は、本発明のシステム連携装置の実施の形態の一例を、その運用環境とともに示すものである。本実施の形態に係るシステム連携装置５では、既存システム／アプリケーションやクラウド等の外部サービス４との連携を支援するサービスを行う。即ち、図１に示すように、本発明のシステム連携装置５により、任意の業務システムやサービスを連携させるための連携用インターフェースを提供することで、ユーザ２のオペレーション（運用）や業務プロセスに適合した連携ＡＰ３の作成を可能とし、業務効率化を実現する。
【００２１】
本発明に係る連携ＡＰ３は、システム連携装置５が提供する連携用インターフェースと、外部サービス４の連携用インターフェースとを用いて作成されたアプリケーションである。管理者１が連携させたい既存の業務システムやサービスを実現するアプリケーションである被連携アプリケーションをシステム連携装置５に登録することで、既存の業務システムやサービスを連携させるための連携用インターフェースが提供される。管理者１は提供された連携用インターフェースを用いて、マッシュアップやＥＳＢ（Ｅｎｔｅｒｐｒｉｓｅ  Ｓｅｒｖｉｃｅ  Ｂｕｓｓ）などの任意の方法により、ユーザ２の運用や業務プロセスに適合した連携ＡＰ３を作成することができる。
【００２２】
次に、システム連携装置５の構成について詳述する。本発明に係るシステム連携装置５は、図１に示すように、マスタ管理部６、連携制御部７、マスタ仮想端末保管部１１、ワーカ仮想端末保管部１２を備えている。さらに、連携制御部７は、ワーカ制御部８、分散処理制御部９、ＩＦ制御部１０を具備する。なお、本発明に係るシステム連携装置５はコンピュータとプログラムによって実現でき、６〜１２の各機能部は１つのコンピュータ上で動作可能であり、分散した環境でも動作可能である。
【００２３】
図２は図１のシステム連携装置の詳細を示すもので、以下、図１と図２を参照してシステム連携装置５の各機能部について詳述する。
【００２４】
マスタ管理部６は、マスタ仮想端末保管部１１に保管された少なくとも一つのマスタ仮想端末１３、詳細には被連携アプリケーションの動作に必要なプラットフォーム（ＯＳ）ごとのマスタ仮想端末１３を管理する。マスタ仮想端末１３は、被連携アプリケーションが動作する端末を模擬するもので、連携制御モジュール１４と、被連携アプリケーションの集合である被連携アプリケーション群１５とが配置されている。
【００２５】
管理者１は、被連携アプリケーションを、当該被連携アプリケーションが対応しているＯＳ（Ｏｐｅｒａｔｉｎｇ  Ｓｙｓｔｅｍ）を有するマスタ仮想端末１３に配置（アプリ配置）する。配置された被連携アプリケーションは被連携アプリケーション群１５に加えられる。被連携アプリケーションに対応したＯＳのマスタ仮想端末が存在しない場合には、マスタ管理部６により追加（マスタ追加）することができる。また不要なマスタ仮想端末が存在する場合には、マスタ管理部６により削除できる（マスタ削除）。
【００２６】
さらに、マスタ管理部６では連携制御モジュール１４の機能を用いて、被連携アプリケーションを自動操作するためのＧＵＩ制御プログラムであるシナリオを作成することができる。シナリオは連携させたい機能に応じて作成（シナリオ作成）する。例えば、スケジューラを被連携アプリケーションとした場合、「任意日の予定を取得するシナリオ」や「任意日に予定を追加するシナリオ」といった形である。作成されたシナリオはシナリオデータベース（ＤＢ）１６に配置（シナリオ配置）され、後述する連携制御部７からの命令に応じてＧＵＩ制御部１７により実行される。なお、シナリオの作成／実行は非特許文献４、５、６などに記載された任意の方法を利用できる。
【００２７】
連携制御部７は、後述するワーカ制御部８によってワーカ仮想端末保管部１２に保管された、マスタ仮想端末１３のクローンであるワーカ仮想端末１８を管理するとともに、ＩＦ制御部１０によって連携ＡＰ３へ連携用インターフェースを提供して要求を受け取り、後述する分散処理制御部９が要求を処理するワーカ仮想端末１８を選択して、要求に対応するシナリオの実行をワーカ仮想端末１８に対して命令する。命令を受けたワーカ仮想端末１８は、後述する連携制御モジュール１４がシナリオに記述された通りに被連携アプリケーションを自動操作する。
【００２８】
本発明が対象としているＧＵＩ制御によるシステム連携のスケーラビリティの問題は、連携制御部７によって解決される。その詳細について述べる前に、ＧＵＩ制御に起因する制約について述べる。
【００２９】
ＧＵＩ制御では、先に述べたＧＵＩ制御プログラム（シナリオ）に沿って被連携アプリケーションを自動操作する。このシナリオと、制御対象の被連携アプリケーションには考慮すべき制約があり、その制約がスケーラビリティの実現に影響する。ＧＵＩ制御における制約として、特に考慮すべきものを図６に示す。制約はシナリオとアプリケーションによる分類と、並行性および環境起因による分類で計４つに分けられる。
【００３０】
シナリオの並行性に関する“同時実行制約（制約１）”について図７を用いて説明する。シナリオはその作りによって同時実行可能なもの、同時実行不可能なものの２つに分けることができる。
【００３１】
実行したいシナリオＡがあったとき、他のシナリオＢが既に実行されており、制御中のＧＵＩが存在する場合に、シナリオＡが実行可能であればシナリオＡは同時実行可能である。同時実行可能なシナリオは図７の上部に示すように、操作対象のＧＵＩ部品（ボタンやエディットなど）をＩＤなどの識別子で厳密に特定し、そのＧＵＩ部品に対して直接操作を実行する。これにより、他のシナリオが制御中のＧＵＩが存在しても、操作対象を正しく特定して制御することができる。
【００３２】
ＩＤなどの識別子を用いた同時実行可能なシナリオを作成するにはＧＵＩがどのような部品で構成されているのかという構造情報を取得する必要がある。
【００３３】
構造情報は、ＷｅｂアプリケーションであればＨＴＭＬを解析することで取得でき、Ｗｉｎｄｏｗｓ（登録商標）のアプリケーションの場合でもＡｃｃｅｓｓｉｂｉｌｉｔｙ  ＡＰＩなどを用いることで取得可能であるが、Ｊａｖａ（登録商標）で作られたアプリケーションや、特殊な実装のアプリケーションでは一部の構造情報を取得できない。そのような場合には、操作したいＧＵＩ部品を座標指定や画像認識で特定し、その特定箇所でクリックイベントを発生させることで操作を実行する。
【００３４】
このような作りのシナリオは図７の下部に示すように、他のシナリオが制御中のＧＵＩが存在する場合に、意味のない場所がクリックされてしまったり、制御対象でないＧＵＩを操作するなどの問題があるため実行することができない。このようなシナリオは同時実行不可能となる。同時実行制約を考慮すると、図８に示すように、仮想端末でシナリオ１が実行中である場合に、新たにシナリオ１の実行を命令することは可能であるが、シナリオ２の実行を命令することはできない。
【００３５】
次に、被連携アプリケーションの並行性に関する“多重起動制約（制約２）”について図９を用いて説明する。アプリケーションはその作りによって多重起動可能なもの、多重起動不可能なものの２つに分けることができる。あるアプリケーションＡが端末内で起動しているとき、同一のアプリケーションＡをさらに起動することが可能であれば、アプリケーションＡは多重起動可能である。逆に、起動不可能であれば多重起動不可能となる。
【００３６】
注意すべき点は、図９の下部に示すように、アプリケーションが多重起動不可能な場合、先に述べたシナリオの同時実行制約が“可”のシナリオであっても、同時には制御することができない。多重起動制約を考慮すると、図１０に示すように、仮想端末でシナリオ１が実行中である場合に、新たにシナリオ１、２の実行を命令することはできない。
【００３７】
次に、被連携アプリケーションの環境起因に関する“互換制約（制約３）”について図１１を用いて説明する。アプリケーションはプラットフォーム毎に互換性が有るものと無いものが存在する。図１１に示すように、アプリ１はプラットフォーム１とプラットフォーム２で互換がある場合、各々のプラットフォームがインストールされている仮想端末１、２の両方で起動可能である。それ故、アプリ１を制御するシナリオは仮想端末１、２の両方に割り振り、実行することができる。
【００３８】
一方、アプリ２は互換がなくプラットフォーム１にのみ対応しているため、プラットフォーム１がインストールされている仮想端末１でのみ起動可能である。それ故、アプリ２を制御するシナリオは仮想端末１にしか割り振ることができない。多重起動制約を考慮すると、図１２に示すように、仮想端末１にはシナリオ１，２，３を割り振ることができるが、仮想端末２にはシナリオ３のみ割り振ることが可能であり、シナリオ１，２は割り振ることができない。
【００３９】
次に、シナリオの環境起因に関する“環境作用制約（制約４）”について図１３、図１４を用いて説明する。先の互換制約により複数のプラットフォームで起動可能なアプリケーションを制御するシナリオであっても、環境作用制約によりシナリオを実行できない場合がある。
【００４０】
図１３の例では、アプリ１は互換有りのためプラットフォームの異なる仮想端末１、２の両方で起動できる。そして、図１３の上部に示すようにＩＤによりＧＵＩ部品を指定するシナリオや、画像マッチによりＧＵＩ部品を指定するシナリオの両方が仮想端末１において実行できる。しかし、仮想端末２では、アプリ１が起動可能ではあるが、例えばプラットフォームによりボタンの表示が変わるなどの影響を受けて、画像マッチによりＧＵＩ部品を特定するシナリオは実行できなくなる。それに対し、ＩＤによりＧＵＩ部品を特定するシナリオは実行できる。この場合では、画像マッチによりＧＵＩ部品を特定するシナリオがプラットフォーム２において環境作用有りとなる。
【００４１】
一方、図１４に示すように、ＩＤによりＧＵＩ部品を特定するシナリオであっても、プラットフォームによりＧＵＩ部品の構造情報が変化するなどの影響を受けて、シナリオが実行できない場合がある。このような場合には、ＧＵＩ部品を特定するシナリオも環境作用有りとなる。環境作用制約を考慮すると、図１５に示すように、シナリオ３はＯＳ１において環境作用有りのため仮想端末２では実行できるが、仮想端末１では実行できない。
【００４２】
本発明では、前記の制約１〜４に代表されるＧＵＩ制御による制約に関する情報であるＧＵＩ制御の制約情報とともに、一般的に用いられる要求数の変化、ワーカ仮想端末の状態（ＣＰＵ負荷、メモリ使用量など）の指標を用いて、ワーカ仮想端末１８の数や物理リソースなどを制御するワーカ制御部８と、ワーカ仮想端末１８にシナリオ実行を割り振る分散処理制御部９によってスケーラビリティを実現する。
【００４３】
ワーカ制御部８は、ワーカ仮想端末１８の再配置周期で定期的に図１６の処理を実行する。
【００４４】
まず、ＩＦ制御部１０が記録している要求の監視結果を取得する（Ｓ１１）。監視結果については、例えば、要求総数（どのシナリオへの要求がいくつあったか）や、要求数の時間変化を含む。次に、ワーカ仮想端末１８の監視結果を取得する（Ｓ１２）。監視結果については、例えば、各ワーカ仮想端末１８のＣＰＵ負荷、メモリ使用量およびワーカ仮想端末内の連携制御モジュールのキューの要素数（待機ジョブ数）を含む。次に、ＧＵＩ制御の制約情報を取得する。制約情報については、例えば、シナリオの同時実行制約と、アプリケーションの多重起動制約と、アプリケーションの互換制約と、シナリオの環境作用制約とからなる制約情報を含む。
【００４５】
次に、Ｓ１１〜Ｓ１３で取得した情報をもとに、ワーカ仮想端末１８の再配置が実行される（Ｓ１４）。ワーカ仮想端末１８の再配置では、マスタ仮想端末１３のクローンをワーカ仮想端末保管部１２のストレージ容量に収まる範囲で作成または削除する。また、ワーカ仮想端末１８のＣＰＵのコア数やメモリ量などにも変更を加えることができる。
【００４６】
次に、ワーカ仮想端末１８の再配置周期で待機（Ｓ１５）し、定期的にＳ１１〜Ｓ１４のステップを実行する。ここで、Ｓ１４のステップで実行する再配置方式についてはワーカ制御部８の実行時において動的に読み込み、切り替えることができる。
【００４７】
分散処理制御部９は、ＩＦ制御部１０が外部に提供している連携用インターフェースが要求を受け取るたびに図１７の処理を実行する。
【００４８】
まず、要求監視結果取得（Ｓ２１）、ワーカ監視結果取得（Ｓ２２）、およびＧＵＩ制御制約取得（Ｓ２３）の各ステップを実行するが、これは図１６のＳ１１〜Ｓ１３と同様である。次に、Ｓ２１〜Ｓ２３で取得した情報をもとに、要求に対応するシナリオを実行するのに最適なワーカ仮想端末１８を選択する（Ｓ２４）。そして選択したワーカ仮想端末１８にシナリオ実行が命令され、命令を受けたワーカ仮想端末１８内の連携制御モジュール１４によって処理される。最後に、新たな要求が到着するまで待機する（Ｓ２５）。ここで、Ｓ２４における最適ワーカの選択方式については、分散処理制御部９の実行時において動的に読み込み、切り替えることができる。
【００４９】
次に、ワーカ制御部８と分散処理制御部９によってスケーラビリティを確保する一例を図１９〜図２３を用いて説明する。
【００５０】
図１９は、固定配置方式によるワーカ再配置の例を示す。固定配置方式では、予め設定した個数／割合でワーカ仮想端末１８を配置する。図１９に示すように、予めシナリオの要求頻度が分かっており、変化も少ないような環境では、要求頻度に合わせて固定的に配置することで要求の処理に必要なリソースを確実に確保し、スケールを実現する。また固定配置方式では周期的なワーカのクローン配置や削除によるオーバヘッドも不要となる。
【００５１】
図２０は、要求数比例方式によるワーカ再配置の例を示す。要求数比例方式では、要求数に応じて、要求を処理可能なマスタ仮想端末１３のクローン（ワーカ仮想端末）を配置する。ここで、マスタ仮想端末Mi、シナリオSj、ワーカ仮想端末保管部１２に格納できるワーカ仮想端末数をStorageCapacityとし、MiのシナリオＤＢ１６に保存されているシナリオの集合をSenarioDB(Mi)、シナリオSjの要求数をNumberOfRequests(Sj)とすると、配置されるMiのクローン数（ワーカ仮想端末数）NumberOfClones(Mi)は以下となる。
【００５２】
【数１】
2015088093.tif 000003
【００５３】
図２０の例では、マスタ仮想端末Ｍ１のシナリオＤＢ１６に登録されているシナリオＳ１〜Ｓ４の要求数が各々１００で、マスタ仮想端末Ｍ２のシナリオＤＢに登録されているシナリオＳ５〜Ｓ８の要求数が各々５０で、StorageCapacityが８の場合である。このとき、Ｍ１のワーカ仮想端末数はNumberOfClones(M1)＝（８／６００）・４００＝5.333...＝５（四捨五入）となり、Ｍ２のワーカ仮想端末数は３となる。要求数比例方式では、要求が多くなってきたシナリオがあれば、そのシナリオを処理できるワーカ仮想端末１８が増えるので、要求数が変化しても要求の処理に必要なリソースを確実に確保しスケールを実現する。
【００５４】
図２１は、制約重み付け方式によるワーカ再配置の例を示す。制約重み付け方式では、先の要求数比例方式にＧＵＩ制御による制約を考慮した重みを付与することで、ワーカ仮想端末１８の配置数を決定する方式である。例えば、図２１の表の例では、シナリオＳ１には同時実行制約は「可能」である。一方、Ｓ６は「不可」である。仮にシナリオＳ１とＳ６の要求数が同じ場合、同時実行制約が「不可」のシナリオＳ６は待ち合わせが多く発生するためにシナリオＳ１に比べて応答が遅延することが予測できる。このような場合（シナリオＳ１とＳ６だけを考慮すると）シナリオＳ１を処理できるＭ１のクローン（ワーカ仮想端末）よりも、シナリオＳ６を処理できるＭ２のクローン（ワーカ仮想端末）を多く配置したほうが要求をより多く処理しスケールを実現できる。
【００５５】
このような背景から、同時実行制約による重みPjと、多重起動制約による重みDjを導入したものが以下となる。重みPjはシナリオSjが同時実行可能なとき「１」の値となり、不可のときは「１」よりも大きい値を設定する。重みDjはシナリオSjの操作対象であるアプリケーションが多重起動可能なとき「１」の値となり、不可のときは「１」よりも大きい値を設定する。
【００５６】
【数２】
2015088093.tif 000004
【００５７】
図２１の例では、重みP1，P3，P5，P7は「１」であり、重みP2，P4，P6，P8は「２」である。また、重みD1，D2，D5，D6，D7，D8は「１」であり、重みD3，D4は「２」である。このとき、Ｍ１のワーカ仮想端末数はNumberOfClones(M1)＝（８／１５００）・９００＝4.8...＝５（四捨五入）となり、Ｍ２のワーカ仮想端末数は３となる。これにより、要求数はシナリオＳ１〜Ｓ８で均一であるが、制約の厳しいＭ１のクローン（ワーカ仮想端末）の数の方が多くなり、要求数比例方式よりもより効率良くスケールが実現できる。
【００５８】
図２２は、待機ジョブ数方式による最適ワーカ選択の例を示す。後述するワーカ仮想端末１８内の連携制御モジュール１４は、シナリオの実行命令をキューに蓄積して管理している。待機ジョブ数方式は、このキューの長さ（待機ジョブ数）をもとに、待機ジョブ数が最も少ないワーカを選択する。ここで、シナリオSi、ワーカ仮想端末Wj、シナリオSiを実行可能なワーカ仮想端末の集合をFeasibleWorkers(Si)としたとき、シナリオSiの要求を受け取ったときに選択されるワーカ仮想端末SelectedWorker(Si)は以下となる。
【００５９】
【数３】
2015088093.tif 000005
【００６０】
図２２の例では、シナリオＳ３の要求を受け取った場面である。このとき実行可能なワーカＷ１とＷ２の中で、待機ジョブ数が最も少ないＷ１が選択される。待機ジョブ数方式により、空きリソースを有効利用して処理を実行できるためより効率良くスケールが実現できる。
【００６１】
図２３は、制約重み付け方式による最適ワーカ選択の例を示す。制約重み付け方式は先の待機ジョブ数方式にＧＵＩ制御による制約を考慮した重みを付与することで、ワーカ仮想端末１８を選択する方式である。例えば、図２３の例ではシナリオＳ１の要求を受け取り、要求を処理するワーカ仮想端末１８を選択する場面である。シナリオＳ１はＭ１とＭ２で互換性があるため、全てのワーカで実行可能であり、先の待機ジョブ数方式であれば待機ジョブ数が最も少ないＷ１が選択される。しかし、ここで他のシナリオを見てみると、シナリオＳ２〜Ｓ４はＭ１のワーカ仮想端末１８でしか実行することができない。さらにそのうち、シナリオＳ２とＳ４は同時実行制約が不可である。これらを考慮すると、シナリオＳ１の要求はＭ１のワーカではなく、Ｍ２のワーカで処理し、Ｍ１のワーカはシナリオＳ２〜Ｓ４のために空けておいた方がより効率的にスケールできる。
【００６２】
このような背景から、互換制約と環境作用制約により規定される各ワーカ仮想端末１８で実行可能なシナリオ群と、先に導入した同時実行制約による重みPkと、多重起動制約による重みDkをもとに、重みLjを導入したものが以下となる。なお、ワーカWjのとき、Master(Wj)はそのもととなったマスタを示す。
【００６３】
【数４】
2015088093.tif 000006
【００６４】
図２３の例では、重みP1，P3は「１」であり、重みP2，P4は「２」である。また、重みD1，D2は「１」であり、重みD3，D4は「２」である。よって、図２３の例のようにシナリオＳ１の要求を受け取ったとき、各ワーカの重みはL1＝L2＝「９」、L3＝L4＝「１」となる。これらと各ワーカの待機ジョブ数をかけ合わせると、それぞれ「９、１８、３、４」となり、最小はＷ３の「３」となる。よって、図２３の例ではＷ３が選択される。これにより、待機ジョブ数はＷ１が最小であるが、Ｗ３を選択することが可能となり、全体のシナリオを考慮したより効率的なスケールを実現できる。
【００６５】
次に、図１８を参照して仮想端末内に配置される連携制御モジュール１４の動作について説明する。連携制御モジュール１４の動作は２つに分けられる。
【００６６】
１つ目の動作は、図１８の上部に示すように、分散処理制御部９からのシナリオ実行命令を受けて、実行命令を１つのジョブとしてＦＩＦＯ（ＦＩｒｓｔ  Ｉｎ  Ｆｉｒｓｔ  ＯＵＴ）のキューの最後尾に挿入（Ｓ３１）して終了するのみの動作である。
【００６７】
２つ目の動作は、図１８の下部に示すように、キューの先頭のジョブを取り出し（Ｓ３２）、プラットフォームの状態、ここではデスクトップで起動しているアプリケーションの種類と数、実行されているジョブ（シナリオ）の種類と数、ＣＰＵ負荷およびメモリ使用量を取得する（Ｓ３３）。Ｓ３３で取得した情報をもとに、取り出したジョブが実行可能かを判定し（Ｓ３４）、実行不可の場合は実行可能となるまでＳ３４を繰り返す。ジョブが実行可能な場合は、ジョブのシナリオをシナリオＤＢ１６から読み込む（３５）。
【００６８】
次に、自動操作する制御対象の被連携アプリケーションを仮想端末で起動する（Ｓ３６）。次に、ＧＵＩ制御部１７がシナリオに沿って被連携アプリケーションのＧＵＩを制御することで自動操作する（Ｓ３７）。ここで、Ｓ３７の自動操作の完了を待たずに、Ｓ３２へと戻り、Ｓ３２〜Ｓ３７を繰り返す。また、連携制御モジュール１４は、ワーカ監視結果取得の要求に応じて仮想端末の状態（ＣＰＵ負荷やメモリ使用率など）を返す機能や、シナリオＤＢにシナリオを保管する機能なども含む。
【００６９】
本発明のシステム連携フレームワークにより、スケーラビリティを確保し規模によらずシステム連携のサービスを提供可能となった。これにより、システム連携をより推進し業務効率化を実現することが可能となる。
【符号の説明】
【００７０】
１：管理者、２：ユーザ、３：連携ＡＰ、４：外部サービス、５：システム連携装置、６：マスタ管理部、７：連携制御部、８：ワーカ制御部、９：分散処理制御部、１０：ＩＦ制御部、１１：マスタ仮想端末保管部、１２：ワーカ仮想端末保管部、１３：マスタ仮想端末、１４：連携制御モジュール、１５：被連携アプリケーション群、１６：シナリオデータベース、１７：ＧＵＩ制御部、１８：ワーカ仮想端末。
【先行技術文献】
【非特許文献】
【００７１】
【非特許文献１】Gerardo Canfora, Anna Rita Fasolino, Giannni Frattolillo, Porfirio Tramontana, "Migrating Interactive Legacy Systems To Web Services,"CSMR'06, 2006, pp.24-26
【非特許文献２】塚本良太、吉村礼子、山足光義、「スクリーンラッピングによる既存Ｗｅｂシステムのサービス化」、情報処理学会第７０回全国大会、2008、pp.4-543-4〜544
【非特許文献３】塚本良太、吉村礼子、山足光義、「レガシーラッピングで提供されるＷｅｂサービスの応答高速化手法」、第７回情報科学技術フォーラム、2008、pp.399〜400
【非特許文献４】横瀬、田中、豊田、堀田、井上、杉本、「端末操作自動化ソフトＵＭＳの概要と適用事例」、信学技報、vol.111、no.488、ICM2011-73、2012年3月、pp.149-154
【非特許文献５】”Ｗｉｎｄｏｗｓ自動化ソフト  ＵＷＳＣ”、［ｏｎｌｉｎｅ］、umiumi、［平成２５年１０月５日検索］、インターネット＜ＵＲＬ：http://www.uwsc.info/＞
【非特許文献６】”自動化スクリプト言語  ＡｕｔｏＩｔ”、［ｏｎｌｉｎｅ］、AutoIt Consulting Ltd.、［平成２５年１０月５日検索］、インターネット＜ＵＲＬ：http://www.autoitscript.com/site/＞
【図１】
2015088093.tif 000007
【図２】
2015088093.tif 000008
【図３】
2015088093.tif 000009
【図４】
2015088093.tif 000010
【図５】
2015088093.tif 000011
【図６】
2015088093.tif 000012
【図７】
2015088093.tif 000013
【図８】
2015088093.tif 000014
【図９】
2015088093.tif 000015
【図１０】
2015088093.tif 000016
【図１１】
2015088093.tif 000017
【図１２】
2015088093.tif 000018
【図１３】
2015088093.tif 000019
【図１４】
2015088093.tif 000020
【図１５】
2015088093.tif 000021
【図１６】
2015088093.tif 000022
【図１７】
2015088093.tif 000023
【図１８】
2015088093.tif 000024
【図１９】
2015088093.tif 000025
【図２０】
2015088093.tif 000026
【図２１】
2015088093.tif 000027
【図２２】
2015088093.tif 000028
【図２３】
2015088093.tif 000029