(57)【要約】【課題】業務統合サーバのメモリの使用量を少なくし、サービスＸＭＬの構築処理低減、およびプロセスロジック記述の自由度を高くする。【解決手段】業務統合サーバは、クライアントからのサービス要求入力１４をデフォルトサービスＸＭＬ１３Ａとして構築し、プロセスロジック１１の指示があればマッピングＸＭＬ１５を生成、サービスＸＭＬ１３を削除し、これらＸＭＬを付属させて業務支援サーバ１２にタスク実行を依頼する。タスク実行結果をタスク結果ＸＭＬ１３Ｂとして構築し、プロセスロジックの指示があればマッピングＸＭＬを削除、タスク結果ＸＭＬをサービスＸＭＬとして構築する。全タスク終了で、保持されているデフォルトサービスＸＭＬおよびタスク結果ＸＭＬを最終的なサービスＸＭＬとして構築し、スタイルシート１８を使用して最終的なサービスＸＭＬを変換し、クライアントに出力する。【選択図】  図１
2006031500.tif 000002
【特許請求の範囲】
【請求項１】
ネットワークを介して分散配置された各種業務支援サーバとクライアントとの間に業務統合サーバを配置し、クライアントから業務統合サーバに業務処理サービスを要求し、この要求を業務統合サーバがサービスＸＭＬとして構築および該サービスＸＭＬをマッピングＸＭＬに変換して各業務支援サーバに各種タスクの実行を依頼し、各業務支援サーバからのタスク実行結果を業務統合サーバがサービスＸＭＬとして構築し、該サービスＸＭＬをＧＵＩスタイルに変換してクライアントに応答する業務統合システムにおいて、
前記業務統合サーバは、
クライアントからのサービス要求をデフォルトサービスＸＭＬとして構築し、必要に応じて前記デフォルトサービスＸＭＬをサービスＸＭＬとして構築して前記マッピングＸＭＬを生成し、必要に応じて該サービスＸＭＬを削除する過程と、
前記マッピングＸＭＬ、デフォルトサービスＸＭＬおよびサービスＸＭＬのうちから必要なもの付属させて前記業務支援サーバにタスク実行を依頼し、タスク実行結果をタスク結果ＸＭＬとして構築し、必要に応じて前記マッピングＸＭＬを削除し、必要に応じて前記タスク結果ＸＭＬをサービスＸＭＬとして構築する過程と、
全タスク終了時に、保持されている前記デフォルトサービスＸＭＬおよびタスク結果ＸＭＬを最終的なサービスＸＭＬとして構築し、スタイルシートを使用して最終的なサービスＸＭＬを変換し、クライアントに出力する過程と、
を有することを特徴とする業務統合システム。
【請求項２】
前記業務統合サーバは、前記タスク結果ＸＭＬ、デフォルトサービスＸＭＬ、マッピングＸＭＬ、サービスＸＭＬを変数として個々に名前を付けて保持することを特徴とする請求項１に記載の業務統合システム。
【請求項３】
前記業務統合サーバは、前記タスク結果ＸＭＬ、デフォルトサービスＸＭＬ、マッピングＸＭＬ、サービスＸＭＬを同じＸＭＬ変数として構築することを特徴とする請求項１に記載の業務統合システム。
【請求項４】
前記業務統合サーバは、前記業務支援サーバから得るタスク結果をオブジェクトのまま保持し、必要なときに前記タスク結果ＸＭＬに変換する過程を有することを特徴とする請求項１〜３のいずれか１項に記載の業務統合システム。
【請求項５】
前記業務統合サーバは、前記業務支援サーバからタスク結果を受取ったときのストリームイメージでファイルに保存し、必要なときにオブジェクトに復元して前記タスク結果ＸＭＬに変換する過程を有することを特徴とする請求項１〜３のいずれか１項に記載の業務統合システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ネットワークを介し分散配置されている各種業務支援サーバとクライアントとの間に業務統合サーバを配置して、各業務を統合的に機能させる業務統合システムに係り、特に業務統合サーバのデータ保持方法に関する。
【背景技術】
【０００２】
近年、情報化の促進やネットワーク環境の整備、さらにネットワークの高速化を背景に、従来スタンドアロン型であった業務支援システム（例えば監視業務における監視支援システムや保守業務における保守支援システム等）がＷｅｂ技術をベースにしたネットワーク対応型へとなってきている。
【０００３】
これまでの各業務支援システムは、それぞれが独立したアプリケーションシステムであるため、ネットワーク上で各システムが動作していても各システム間の連携が困難であった。
【０００４】
この各システム間の連携を可能とする業務統合システムを本願出願人は既に提案している（例えば、特許文献１参照）。このシステムは、図４に示すように、クライアントＡと各種業務サーバＢとの間に業務統合サーバＣをネットワークを介して配置し、業務統合サーバＣには図５に示す機能ブロックをソフトウェア構成で実装している。
【０００５】
図５において、クライアントゲート部１は、クライアントから送信されたデータの中から、実行する業務プロセスロジックＸＭＬ（eXtensible Markup Language）ファイル名、該ロジックの実行に必要な各種パラメータ、作成するＧＵＩに対するスタイルシートの情報を抽出し、内部データとして格納する。
【０００６】
業務プロセスロジック実行部２は、クライアントゲート部１より取得した業務プロセスロジックＸＭＬファイル名をもとに、業務プロセスロジックＸＭＬとして展開し、業務プロセスロジックＸＭＬに保存されている業務プロセス機能の名前に対応する業務支援サーバの詳細情報をサービスリポジトリ管理部３より取得し、これら名前及び業務支援サーバの詳細情報を業務支援サーバ通信部４を通して業務支援サーバにサービス実行を依頼し、このサービス実行の結果は内部データとして格納する。
【０００７】
サービスリポジトリ管理部３は、業務プロセスロジック実行部２が指定する業務プロセス機能のサービス名に対応する業務支援サーバの詳細情報を取得し、業務プロセスロジック実行部２に通知する。
【０００８】
業務支援サーバ通信部４は、業務プロセスロジック実行部２が指定するサービス名及び業務支援サーバの詳細情報をもとに、業務支援サーバと通信し、業務支援サーバのサービス実行結果を業務プロセスロジック実行部２に通知する。
【０００９】
サービスリポジトリ５は、業務プロセス機能の名前（サーバ名）に対応する業務支援サーバの詳細情報（サーバ名またはＩＰアドレス、サーバ実行に必要なパラメータ要素等）を格納する。
【００１０】
ＧＵＩ作成部６は、内部データに格納されている前記業務プロセスロジック実行部の処理結果と、指定されたスタイルシート情報をもとに、クライアントへ送信すべきＧＵＩを動的に作成する。
【特許文献１】特開２００３−２４２１２７
【発明の開示】
【発明が解決しようとする課題】
【００１１】
図６は、従来の業務統合サーバにおけるデータ関連図を示す。業務プロセスロジック実行部によるプロセスロジック１１に従って業務支援サーバのタスク１２を起動させ、その実行結果をサービスＸＭＬ１３としてデータを保持する。同様に、クライアントから入力されたデータ（パラメータ）１４をサービスＸＭＬ１３として保持する。
【００１２】
このように、プロセスロジックによる実行結果は、サービスＸＭＬ１３という一括したＸＭＬデータとして、ＤＯＭ（Document Object Model）で保持している。全てのデータを１箇所で管理することにより、サービスＸＭＬ１３からマッピングＸＭＬ１５への変換やクライアントへのＧＵＩ出力１６を得るための変換には、単純にマッピングＸＳＬＴ（ＸＭＬ Stylesheet Language Transfoemation）１７やスタイルシート１８を通せばよく、プログラム構造が簡単になっている。
【００１３】
なお、マッピングとは、業務プロセスロジックＸＭＬファイル中のタスクの引数やコントローラの属性に対して、サービス実行結果を利用する際に行う関連付け処理のことである。サービス実行結果には対応する業務プロセスロジックＸＭＬファイル固有の情報や、業務プロセスロジックＸＭＬファイル中にあるタスクの実行結果が含まれる。このサービス実行結果の一部あるいは全部を業務プロセスロジック内で利用する場合には、変換元となるサービス実行結果内の部分（複数指定が可能）を指定すること、変換先となるタスクの引数やコントローラの属性などを指定する必要がある。マッピングファイルは、上記のマッピングに関する情報を保持したファイルであり、変換元と変換先におけるデータ関連付けの手順が記述される。この情報は、１つのマッピングファイルの中で複数保持することができる。
【００１４】
上記のマッピングＸＳＬＴやスタイルシートによる変換を行うプロセスロジック処理方式とすると、タスク（業務支援サーバ）が返すデータ量が多くなった場合、または１回のプロセスロジックの起動でタスクを何度も実行した場合、サービスＸＭＬが大きくなり、メモリを圧迫する。また、マッピングとタスクを連鎖させて実行するような場合、必要なくなったデータも最後まで保持しているため、メモリ効率が悪い。このため、大量のデータを扱う場合、メモリが足らなくなり、エラーを起こすおそれがある。
【００１５】
本発明の目的は、上記の課題を解決した業務統合サーバのデータ保持方法を提供することにある。
【課題を解決するための手段】
【００１６】
本発明は、前記の課題を解決するため、業務統合サーバが連携処理を行うときに、
・処理中の結果を１つにまとめて常時サービスＸＭＬとして保持することをせず、必要なときに必要な分だけサービスＸＭＬを構築する。このため、クライアントパラメータの内容でデフォルトサービスＸＭＬを構築し、サービスＸＭＬの名前を指定しなかった場合はデフォルトサービスＸＭＬをタスク実行に使用する。また、タスク結果はタスク結果ＸＭＬとして構築し、必要なときに必要な分だけサービスＸＭＬの構築とマッピングＸＭＬへの変換をする。
【００１７】
・プロセスロジックの指示により、タスク結果、マッピングＸＭＬ、またはサービスＸＭＬを個別に適宜削除できるようにする。
【００１８】
・デフォルトサービスＸＭＬ、タスク結果ＸＭＬ、マッピングＸＭＬ、サービスＸＭＬをＸＭＬ変数として区別無く使用可能にする。
【００１９】
・プロセスロジックの指示により、デフォルトサービスＸＭＬ、タスク結果ＸＭＬ、マッピングＸＭＬ、サービスＸＭＬを使用して新たにＸＭＬ変数を構築可能にする。
【００２０】
以上までの方法に加えて、
・タスク結果を名前を付けてオブジェクトとして保持し、必要なときにタスク結果ＸＭＬに変換する。
【００２１】
・タスク結果を名前を付けてストリームイメージファイルとして保持し、必要なときにオブジェクトに展開し、タスク結果ＸＭＬに変換する。
ようにしたもので、以下の方法を特徴とする。
【００２２】
（１）ネットワークを介して分散配置された各種業務支援サーバとクライアントとの間に業務統合サーバを配置し、クライアントから業務統合サーバに業務処理サービスを要求し、この要求を業務統合サーバがサービスＸＭＬとして構築および該サービスＸＭＬをマッピングＸＭＬに変換して各業務支援サーバに各種タスクの実行を依頼し、各業務支援サーバからのタスク実行結果を業務統合サーバがサービスＸＭＬとして構築し、該サービスＸＭＬをＧＵＩスタイルに変換してクライアントに応答する業務統合システムにおいて、
前記業務統合サーバは、
クライアントからのサービス要求をデフォルトサービスＸＭＬとして構築し、必要に応じて前記デフォルトサービスＸＭＬをサービスＸＭＬとして構築して前記マッピングＸＭＬを生成し、必要に応じて該サービスＸＭＬを削除する過程と、
前記マッピングＸＭＬ、デフォルトサービスＸＭＬおよびサービスＸＭＬのうちから必要なもの付属させて前記業務支援サーバにタスク実行を依頼し、タスク実行結果をタスク結果ＸＭＬとして構築し、必要に応じて前記マッピングＸＭＬを削除し、必要に応じて前記タスク結果ＸＭＬをサービスＸＭＬとして構築する過程と、
全タスク終了時に、保持されている前記デフォルトサービスＸＭＬおよびタスク結果ＸＭＬを最終的なサービスＸＭＬとして構築し、スタイルシートを使用して最終的なサービスＸＭＬを変換し、クライアントに出力する過程と、
を有することを特徴とする。
【００２３】
（２）前記業務統合サーバは、前記タスク結果ＸＭＬ、デフォルトサービスＸＭＬ、マッピングＸＭＬ、サービスＸＭＬを変数として個々に名前を付けて保持することを特徴とする。
【００２４】
（３）前記業務統合サーバは、前記タスク結果ＸＭＬ、デフォルトサービスＸＭＬ、マッピングＸＭＬ、サービスＸＭＬを同じＸＭＬ変数として構築することを特徴とする。
【００２５】
（４）前記業務統合サーバは、前記業務支援サーバから得るタスク結果をオブジェクトのまま保持し、必要なときに前記タスク結果ＸＭＬに変換する過程を有することを特徴とする。
【００２６】
（５）前記業務統合サーバは、前記業務支援サーバからタスク結果を受取ったときのストリームイメージでファイルに保存し、必要なときにオブジェクトに復元して前記タスク結果ＸＭＬに変換する過程を有することを特徴とする。
【発明の効果】
【００２７】
以上のとおり、本発明によれば、以下の効果がある。
【００２８】
（１）処理中の結果を１つにまとめて常時サービスＸＭＬとして保持することをせず、必要なときに必要な分だけサービスＸＭＬを構築するため、メモリの使用量を少なくできる。
【００２９】
（２）タスク結果ＸＭＬ、デフォルトサービスＸＭＬ、マッピングＸＭＬ、サービスＸＭＬを変数として個々に名前を付けて保持することにより、互いの使いまわしができるようになり、後で必要になったときに再度構築処理をする必要がなくなる。
【００３０】
（３）タスク結果ＸＭＬ、デフォルトサービスＸＭＬ、マッピングＸＭＬ、サービスＸＭＬを、区別することなく同じＸＭＬ変数として扱うことにより、プロセスロジックの記述が単純になり、自由度が高くなる。
【００３１】
（４）マッピング結果をクライアントに返すことができる。
【００３２】
（５）実施形態２のように、タスク結果をオブジェクトやファイルで保持することにより、使用しなかった場合、無駄なＸＭＬ構築処理を省くことができる。
【００３３】
（６）実施形態３のように、タスク結果をファイルで保持することにより、使用しなかった場合、メモリ使用量を節約することができる。
【発明を実施するための最良の形態】
【００３４】
（実施形態１）
本実施形態では、クライアントパラメータやタスク結果は一つのサービスＸＭＬとして集約することなく、サービスＸＭＬとは区別して分散保持し、マッピングＸＭＬの作成やスタイルシートによるＧＵＩ出力が必要になるときだけ、必要なものをサービスＸＭＬとして構築する。この「必要になるとき」とは、クライアントからの業務処理サービス要求に応じた業務支援サーバの各タスク実行をプロセスロジックが指令するときに、必要か否かが決まるものであり、例えば、プロセスロジックがあるタスク実行を指令する場合にそれより前のタスク実行結果を利用する場合や、あるタスク実行にマッピングＸＭＬを使用する場合に、サービスＸＭＬとして構築する。
【００３５】
本実施形態によるデータ関連イメージは図１に示すようになり、図６と同等の部分は同一符号を付して示す。図１に示すように、本実施形態では、クライアントから入力されるパラメータを使用してデフォルトサービスＸＭＬ１３Ａを構築しておき、必要に応じてプロセスロジック１１からの指示によってデフォルトサービスＸＭＬ１３ＡからサービスＸＭＬ１３を構築する。また、プロセスロジック１１が起動する業務支援サーバによるタスク実行結果はタスク結果ＸＭＬ１３Ｂとして構築しておき、必要に応じてプロセスロジック１１からの指示によってタスク結果ＸＭＬ１３ＢからサービスＸＭＬ１３を構築する。これら、サービスＸＭＬ１３の構築したときには、元のデフォルトサービスＸＭＬやタスク結果ＸＭＬは削除する。また、必要に応じてプロセスロジック１１からの指示によってサービスＸＭＬ１３からマッピングＸＭＬ１５を構築する。
【００３６】
このように、本実施形態では、タスク結果やクライアントパラメータ、マッピングＸＭＬなどは変数として名前を付けて個別に、タスク結果ＸＭＬ１３やデフォルトサービスＸＭＬ１３Ａ、マッピングＸＭＬ１５としてＸＭＬに変換し保持する。そして、マッピングやスタイルシート使用時に必要なものだけでサービスＸＭＬ１３を構築させるために、プロセスロジック１１に命令を追加し、その命令で選択したタスク結果からサービスＸＭＬを構築する。構築したサービスＸＭＬも同様に変数として名前を割り当て、複数保持できるようにする。これにより、処理結果の使いまわしができるようになり、後で同じ結果が必要になった場合、再処理・再構築をする必要がなくなる。また、メモリを圧迫させないように、必要なくなったサービスＸＭＬは削除できるようにする。
【００３７】
なお、本実施形態では、必要とする都度、サービスＸＭＬを構築するため、時間が余計にかかるように考えられるが、実際にはタスク結果を得るたびにサービスＸＭＬに追加していた処理が、必要な時に必要なデータだけで構成されるためＸＭＬが無駄に大きくならず、追加処理も必要なものだけに対して行われるため、処理時間はそれほど増加しない。
【００３８】
また、マッピングＸＭＬも名前を付けて変数として保持しておくことにより、使いまわしができるようになり、後で同じマッピングが必要になったときに再度ＸＳＬＴを行わなくてもよくなる（適用するサービスＸＭＬが変化していないときに限る）。
【００３９】
以上の処理形態を実現するため、業務統合サーバは図２に示す連携処理フローをソフトウェア構成で実現する。同図において、
（Ｓ１、Ｓ２）クライアント１４から入力されたパラメータは、デフォルトサービスＸＭＬ（名前無し）１３Ａとして構築する。
【００４０】
（Ｓ３）プロセスロジック１４の指示があれば（この後のタスク実行に必要ならば）、マッピングＸＳＬＴ１７を使用して、デフォルトサービスＸＭＬ１３ＡをサービスＸＭＬ１３として構築し、これを基にマッピングＸＭＬ１５を生成する。
【００４１】
（Ｓ４）マッピングＸＭＬ１５に変換したサービスＸＭＬ１３について、プロセスロジック１４の指示があれば（この後のタスク実行に不要ならば）、そのサービスＸＭＬ１３を削除する。
【００４２】
（Ｓ５）プロセスロジック１４の指示により、タスク１２を起動し、タスク結果をタスク結果ＸＭＬ１３Ｂとして構築する。このタスク起動には、マッピングＸＭＬ１５、デフォルトサービスＸＭＬ１３ＡおよびサービスＸＭＬ１３のうちから必要なもの付属させて業務支援サーバに送信する。
【００４３】
（Ｓ６）プロセスロジック１４の指示があれば（この後のタスク実行に不要ならば）、マッピングＸＭＬ１５を削除する。
【００４４】
（Ｓ７）プロセスロジック１４の指示があれば（マッピングＸＭＬを必要ならば）、タスク結果ＸＭＬ１３ＢをサービスＸＭＬとして構築し、マッピングＸＭＬに変換しておく。
【００４５】
（Ｓ８）上記までの処理Ｓ２〜Ｓ７を、クライアント入力に対する処理に必要な全タスクを終了するまで繰り返す。これにより、クライアント入力にはデフォルトサービスＸＭＬ１３Ａとして保持し、タスク結果はタスク結果ＸＭＬとして保持し、必要に応じてサービスＸＭＬの構築およびマッピングＸＭＬに変換しながら全タスクを実行する。
【００４６】
（Ｓ９）全タスクを終了したとき、プロセスロジック１４の指示により、保持されているデフォルトサービスＸＭＬ１３Ａおよびタスク結果ＸＭＬを最終的なサービスＸＭＬとして構築する。
【００４７】
（Ｓ１０）スタイルシートを使用して、最終的なサービスＸＭＬを変換し、クライアントに出力する。
【００４８】
図３は、図２の処理における各種ＸＭＬファイルの指定例を示す。図３において、命令Ｃ１は、名前の無いデフォルトで使用されるサービスＸＭＬがあり、クライアントパラメータはここに入る。各処理で、サービスＸＭＬの名前を指定しなかった場合は、デフォルトサービスＸＭＬが使用される。
【００４９】
命令Ｃ２は、サービスＸＭＬの構築をプロセスロジック中の命令により行うが、このときに指定されたサービスＸＭＬの名前を指定順に直列に並べ、ルートタグで括ったものとし、使用するデフォルトサービスＸＭＬとタスク結果Ａ，Ｂを指定する。ルートタグ名は固定名の他、指定した変数名などとする。また、サービスＸＭＬや後述のマッピングＸＭＬの構築の際に、既にある名前を指定した場合は、システムの設定またはプロセスロジック中のモード指定により、既存ＸＭＬに対して「上書き」か「追加」が行われる。名前が指定されなかった場合は、デフォルトサービスＸＭＬに対して「上書き」か「追加」が行われる。
【００５０】
命令Ｃ３は、マッピングＸＭＬ作成時に使用するサービスＸＭＬを名前で指定する。
【００５１】
命令Ｃ４は、マッピングＸＭＬの名前を引き数としてタスクＣを起動する。このタスク起動時にはタスク結果の名前を指定しておき、サービスＸＭＬ構築時の指定で使用する。
【００５２】
命令Ｃ５は、マッピングＸＭＬおよびサービスＸＭＬを削除する。この削除には、名前を指定しないで削除を行った場合は、デフォルトサービスＸＭＬがクリアされる。名前を指定して削除を行った場合は、指定されたＸＭＬが実際に削除される。
【００５３】
命令Ｃ６は、サービス結果をスタイルシートで使用するため、サービスＸＭＬの名前Ｌａｓｔで指定する。
【００５４】
なお、各ＸＭＬの保持の実装は問わないが、ＤＯＭ（フラグメント）の他、ファイルや文字列オブジェクト、ＸＭＬデータベース内のデータとして保持することができる。
【００５５】
（実施形態２）
実施形態１では、タスク結果をタスク結果ＸＭＬとして保持するが、本実施形態ではタスク結果をオブジェクトのまま保持し、必要なときにタスク結果ＸＭＬに変換する。これにより、タスク結果が使用されなかった場合、無駄な変換処理を省くことができる。
【００５６】
（実施形態３）
本実施形態では、実施形態１におけるタスク結果をメモリ上に保持せず、タスク結果を受取ったときのストリームイメージでファイルに保存し、必要なときにオブジェクトに復元してタスク結果ＸＭＬに変換する。これにより、タスク結果が使用されなかった場合、無駄な変換処理を省くことができるのと同時に、メモリの使用量を抑えることができる。
【図面の簡単な説明】
【００５７】
【図１】本発明の実施形態１を示す業務統合サーバのデータ関連図。
【図２】実施形態１における連携処理フロー。
【図３】実施形態１におけるプロセスロジックの命令の例。
【図４】業務統合システムの構成図。
【図５】業務統合サーバのＳ／Ｗブロック図。
【図６】従来の業務統合サーバのデータ関連図。
【符号の説明】
【００５８】
１  クライアントゲート部
２  業務プロセスロジック実行部
３  サービスリポジトリ管理部
４  業務支援サーバ通信部
５  サービスリポジトリ
６  ＧＵＩ作成部
１１  プロセスロジック
１２  業務支援サーバのタスク
１３  サービスＸＭＬ
１４  クライアント入力
１５  マッピングＸＭＬ
１６  クライアント出力
１７  マッピングＸＳＬＴ
１８  スタイルシート
１３Ａ  デフォルトサービスＸＭＬ
１３Ｂ  タスク結果ＸＭＬ
【図１】
2006031500.tif 000003
【図２】
2006031500.tif 000004
【図３】
2006031500.tif 000005
【図４】
2006031500.tif 000006
【図５】
2006031500.tif 000007
【図６】
2006031500.tif 000008