JP5955385B2 - 情報処理システム - Google Patents

Description

本発明は、複数のサービスを連携するサービス連携技術に関する。
本発明は、例えば、スマートメータシステムに用いられる複数のサービスを連携するサービス連携技術に関する。

スマートメータシステムとは、各家庭に配置された通信機能の付いたスマートメータを電力会社のセンターシステムから制御して、電力量検針値の定期的な収集や、電力供給（ブレーカー開閉）の制御を行うステムである。
スマートメータシステムは、収集したデータの各家庭への公開や、電力使用状況のきめ細かい分析などを可能にする、エネルギーを最適化するための技術として注目されている。
スマートメータシステムは、各家庭のスマートメータ（以下、単に「メータ」ともいう）、電信柱などに配置され近いエリアの複数のスマートメータを取りまとめるコンセントレータ（Ｄａｔａ Ｃｏｎｃｅｎｔｒａｔｏｒ Ｕｎｉｔ）（以下、コンセントレータを「ＤＣＵ」という）、センターシステム（以下、単に「センター」ともいう）からなる。
スマートメータとＤＣＵは無人で運用される。
また、スマートメータとＤＣＵは、携帯電話通信網やＰＬＣ（Ｐｏｗｅｒ Ｌｉｎｅ Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ）通信網など、あまり安定しない通信網を用いて通信を行う。
運用管理者はセンターのみに存在するため、すべての監視や運用はセンターシステムで行える必要がある。

スマートメータシステムでは、複数のアプリケーションを１つのセンターシステムで処理する必要がある。
センターシステムで処理するアプリケーションには、例えば、定期収集業務、メータ監視制御アプリケーション、イベント検知アプリケーションなどがある。
定期収集業務は、メータが示す電力量および異常フラグをセンターシステムが定期的に収集するためのアプリケーションである。
メータ監視制御アプリケーションは、センターシステムからメータに対して指示を出すためのアプリケーションである。
イベント検知アプリケーションは、メータで検知した停電・復電（停電の後に電力供給が再開されること）などを検知するためのアプリケーションである。

センターシステムの負荷バランスは、需要の変化、停電、地域災害、個々の家庭の電源に関する故障、メンテナンスなどシーンにより動的に変化する。
このため、センターシステムでの負荷バランスの調整は、業務の優先度、メータの配置されるエリア、メータが異常を検知したか否かなど、業務とシステム構成を考慮して行う必要がある。
例えば、定期収集業務中に、あるメータが停電などの異常を検知した場合、メータからＤＣＵを通して停電メッセージが送られてイベント検知アプリケーションが動作する。
そして、センターにいる運用管理者に停電メッセージが伝えられ、運用管理者はメータ監視制御アプリケーションを動作させて、メータからのログ取得と障害を解決するための対応を行う。
この時、定期収集業務に優先して、イベント検知アプリケーションやメータ監視制御アプリケーションの実行を行う必要があり、定期収集業務がＤＣＵやメータとの通信帯域、ＤＣＵやメータの処理リソースを占有するような場合には定期収集業務を一時停止させるなどの制御が必要である。

スマートメータシステムの各家庭への展開は１０年など長期にわたり、エリア（ＤＣＵのエリア）ごとに段階的な増強が行われる。
エリアによっては、地域の通信事情などにより通信網などが増強されない場合もある。
このため、センターから、新旧の構成が混ざった状態でメータを制御する必要があり、エリアごとに異なった性能・優先制御が必要である。

従って、優先制御を考慮して、スマートメータシステム上の計算機や構成要素の機器のワークロードバランスのしくみを設けることが必要である。
そして、ワークロードバランスのしくみは、エリアごとの段階的な増強に合わせて拡張・変更できる必要がある。

特許文献１では、アプリケーション内のフローに含まれる各サービスについて、サービスレジストリにより、サービスが実行されるサーバとサービスごとの優先度の情報を設定する。
また、特許文献１では、マッチング制御部がアダプタを通してサービスを実行する計算機を制御することにより、優先度を考慮したサービスの負荷分散を行うことができる。

特開２００８−１８６１０５号公報

特許文献１では、優先制御の対象はセンター内の計算機群のみであり、センター内の計算機群のＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）負荷容量に応じてサービスを実行する計算機間の負荷バランスを調整するだけである。
スマートメータシステムでは、サービス（アプリケーション）の優先度と進捗に応じた調整や、メータ、ＤＣＵ、通信機器など、スマートメータシステムに含まれる構成要素に対する優先制御が必要である。
たとえば、特定のメータに対して優先度の低いサービス（アプリケーション）の処理と優先度の高いサービス（アプリケーション）の処理が重なった場合は、優先度の低いサービス（アプリケーション）の処理の中断させることが必要だが、特許文献１の技術ではこのような制御を行うことができない。
スマートメータシステムでは、構成要素の状況、他のサービスの優先度、他のサービスの進捗状況などを元に、次に行うべきサービスを判断する柔軟な制御が必要となる。

本発明は、これらに鑑みたものであり、構成要素の状況、他のサービスの優先度、他のサービスの進捗状況などに基づき、サービスの実行、サービスの実行の保留を柔軟に決定できるようにすることを主な目的とする。

本発明に係る情報処理システムは、
複数のサービスの実行を管理する情報処理システムであって、
それぞれが異なるサービスに対応し、それぞれが、対応するサービスについて、サービスのインスタンスの情報であるトークンを格納する、複数のトークン格納部と、
サービスの実行順序を調整するための実行順序調整ルールが定義されている実行順序調整ルール情報を記憶する実行順序調整ルール情報記憶部と、
トークン格納部ごとにトークンが格納されているか否かを判断し、対応するトークン格納部にトークンが格納されているサービスを実行候補サービスとして抽出し、実行候補サービスごとに、前記実行順序調整ルール情報に定義されている実行順序調整ルールを用いて、サービスの実行及びサービスの実行の保留のいずれかを決定するサービス実行判定部とを有することを特徴とする。

本発明では、実行順序調整ルールが定義されている実行順序調整ルール情報を用いて、サービスの実行及びサービスの実行の保留のいずれかを決定する。
このため、構成要素の状況、他のサービスの優先度、他のサービスの進捗状況などを反映させた実行順序調整ルールを用いることで、構成要素の状況、他のサービスの進捗状況などに基づき、サービスの実行、サービスの実行の保留を柔軟に決定することができる。

実施の形態１に係るスマートメータシステムの構成例を示す図。 実施の形態１に係るＥＳＢの構成例を示す図。 実施の形態１に係るルーティングファイルの例を示す図。 実施の形態１に係るトークンキューの例を示す図。 実施の形態１に係る実行順序調整ルールの例を示す図。 実施の形態１に係る移動ルールの例を示す図。 実施の形態１に係るルール適用対応表の例を示す図。 実施の形態１に係る負荷調整ルールの例を示す図。 実施の形態１に係る計算機間の関係を説明する図。 実施の形態１に係るセンターシステムにおける動作例を示すフローチャート図。 実施の形態１に係るセンターシステムにおける動作例を示すフローチャート図。 実施の形態１に係るセンターシステムにおける動作例を示すフローチャート図。 実施の形態２に係るスマートメータシステムの構成例を示す図。 実施の形態２に係るフロー・ルール置換部と調整ルールとルーティングファイルとの関係を説明する図。 実施の形態２に係る構成・業務パラメータ対応表の例を示す図。 実施の形態２に係る構成選択ルールの例を示す図。 実施の形態２に係る構成選択ルールの例を示す図。 実施の形態３に係る計算機の構成例を示す図。 実施の形態３に係るルーティングファイルの例を示す図。 実施の形態１〜３に係る計算機のハードウェア構成例を示す図。

実施の形態１．
上述したように、特許文献１の技術では、メータ、ＤＣＵ、通信機器といった構成要素の状況、他のサービスの優先度、他のサービスの進捗状況などを元に、次に行うべきサービスを柔軟に決定することができないという課題（「課題１」という）がある。

また、特許文献１の技術では、優先パラメータとサービスと計算機は固定される。
スマートメータシステムは、長期間（例えば１０年間）をかけてエリア（ＤＣＵのエリア）ごとに段階的に拡張される。
このため、新しい機器が設置されているエリアと、古い機器が設置されているエリアが混在する状態になる。
新しいエリアの機器と古いエリアの機器では、通信網の容量、ＤＣＵの受け入れ可能なコネクション数、メータの機能などが異なり、優先制御に対する制約条件が異なる。
例えば、初期の構成では、１つのＤＣＵエリアのメータの台数は１００万台までであり、また、ＤＣＵは、低スペックであり、各通信で１スレッドしか許容されない。
また、各メータはＡＭＲ（Ａｕｔｏｍａｔｅｄ Ｍｅｔｅｒ Ｒｅａｄｉｎｇ）方式であり、自発通信は行われない。
初期の構成では、通信網が貧弱（例えば、メータとＤＣＵの間の通信網は１９２ＫＢｐｓ、ＤＣＵとセンターシステムの間の通信網も１９２ＫＢｐｓ）であり、通信網を有効利用するための優先制御が必要である。
一方、後期の構成では、１つのＤＣＵエリアのメータの台数は１０００万台超も可能であり、また、ＤＣＵは、高スペックであり、各通信で１０スレッドが許容される。
また、各メータはＡＭＩ（Ａｄｖａｎｃｅｄ Ｍｅｔｅｒｉｎｇ Ｉｎｆｒａｓｔｒｕｃｔｕｒｅ）方式であり、ＨＥＭＳ（Ｈｏｍｅ Ｅｎｅｒｇｙ Ｍａｎａｇｅｍｅｎｔ Ｓｙｓｔｅｍ）に対応している。
後期の構成では、通信網は充実（例えば、メータとＤＣＵの間の通信網は１９２ＫＢｐｓ、ＤＣＵとセンターシステムの間の通信網は１００ＭＢｐｓ）しているものの、ＨＥＭＳが導入されているため、通信量が初期の構成に比べて一桁多く、センター側の資源を多く利用する必要がある。
このように、エリアや使用機器により、優先制御とワークロードバランスの方法を変更できる必要があるが、特許文献１の技術では、センター上の計算機と優先パラメータとサービスとが固定されており、優先制御とワークロードバランスの方法を変更することができないという課題（「課題２」という）がある。

本実施の形態では、センターシステム上に配置する、サービス、サービスフローを実行するメッセージ連携ミドルウェア（ＥＳＢ：Ｅｎｔｅｒｐｒｉｓｅ Ｓｅｒｖｉｃｅ Ｂｕｓ）に対して、業務アプリケーションのフローの他に、アプリケーションの負荷調整を行うための調整ルールを設定する。
この調整ルールは、アーキテクチャ開発者が、構成要素やサービスフローを意識して設定する。
そして、調整ルールには、柔軟な優先制御を可能にするルールが定義される。
また、調整ルールに、スマートメータの段階的な拡張によって生じるＤＣＵエリアごとの制御を定義することで、ＤＣＵエリアごとの制御をアプリケーションから切り離すことができ、アプリケーションの開発を効率化することができる。
本実施の形態では、センターシステム上に配置されるセンター計算機で業務アプリケーションを実行するためのシステム連携基盤を、ＳＯＡ（Ｓｅｒｖｉｃｅ Ｏｒｉｅｎｔｅｄ Ａｒｃｈｉｔｅｃｔｕｒｅ）を実現するためのメッセージ連携ミドルウェア（ＥＳＢ）として実現している。

ＳＯＡとは、複数のサービスを組み合わせてシステムを構築する設計手法である。
サービスとは、意味のある単位の機能を持つ一まとまりのソフトウェアの集合であって、外部から標準化された手順によって呼び出すことができるものである。
意味のあるとは、業務上、あるいは人間にとって何らかの意味があることを指す。
なお、複数のサービスを組み合わせて構成された一連の処理をプロセス又はサービスフローと呼ぶ場合がある。
ＳＯＡに基づくシステム構築では、ＥＳＢを用いることが一般的である。
ＥＳＢとは、外部システムとサービスとの間の連携や、サービス間の連携を図るミドルウェアである。
ＥＳＢでは、メッセージルータ（メッセージバス）を提供し、このメッセージルータを通じて、外部システムとサービスとの間や、サービス間でメッセージの交換を行い、外部システムとサービスとの間の連携や、サービス間の連携を図る。

図１は、本実施の形態に係るスマートメータシステムの構成例を示す。
情報処理システムの例に相当するセンターシステム１０００は、計算機１（１００）、計算機２（２００）及び計算機３（３００）から構成される。
センターシステム１０００の計算機１（１００）及び計算機２（２００）は、多段構成のネットワーク４０１、４０２、４０３を介して複数のＤＣＵ４０４と接続される。
ＤＣＵ４０４には、複数のメータ４０５、４０６が接続されている。
なお、計算機１（１００）はＣ１とも表記し、計算機２（２００）はＣ２とも表記する。
また、計算機１（１００）及び計算機２（２００）は、サーバともいう。
図１では、３台のセンター計算機によりセンターシステム１０００が構成される例を示しているが、センターシステム１０００の計算機の台数は任意である。

センターシステム１０００において、計算機１（１００）及び計算機２（２００）は、各種サービス（定期収集業務、イベント検知アプリケーション、メータ監視制御アプリケーション等）を実行する。
計算機３（３００）は、計算機１（１００）及び計算機２（２００）のワークロードバランスの調整のための動作を行う。
計算機１（１００）及び計算機２（２００）は、同じ機能ブロック構成を有する。
また、計算機１（１００）、計算機２（２００）及び計算機３（３００）は、それぞれＥＳＢ（ＥＳＢ１０６、ＥＳＢ２０６、ＥＳＢ３０５）を含み、ＥＳＢのメッセージルータによって連携されている。
そして、ＥＳＢのメッセージルータを通して計算機間で互いに他の計算機上のサービスを呼び出すことができる。
メッセージルータで連携された計算機では、後述するルーティングファイルを共有している。
ルーティングファイルには、サービスの流れを示すサービスフロー（以下、「サービスフロー」を単に「フロー」ともいう）が記述されている。

計算機１（１００）及び計算機２（２００）の構成を説明する。
計算機１（１００）と計算機２（２００）は同じ構成を有するので、以下では、計算機１（１００）の構成のみを説明する。

通信部１０１は、ネットワーク４０１等を介してＤＣＵ４０４と通信を行う。
また、通信部１０１は、計算機２（２００）及び計算機３（３００）と通信を行う。
入出力部１０２は、運用管理者（ユーザ）からの指示を入力し、また、運用管理者（ユーザ）に処理の実行結果等を出力する。
サービス実行部１０３は、サービスアプリケーションコード（サービスを実現するためのアプリケーションプログラムのコード）を実行する。
サービスアプリケーションコードは記憶部１０４に記憶されている。
性能統計更新部１０５は、計算機１（１００）のトークンキュー内のトークンの集計を行い、統計情報として、計算機３（３００）に送信する。
トークンキュー及びトークンについては、後述する。
また、ＥＳＢ１０６の詳細も図２を参照して後述する。

計算機３（３００）において、通信部３０１は、計算機１（１００）及び計算機２（２００）と通信を行う。
入出力部３０２は、運用管理者（ユーザ）からの指示を入力し、また、運用管理者（ユーザ）に処理の実行結果等を出力する。
負荷調整指示情報生成部３０３は、性能統計更新部１０５から統計情報を取得し、サービス実行部１０３が既に受け入れているトークン数を集計し、サービス実行部１０３が更に受け入れ可能なトークン数を算出し、算出したトークン数を通知する情報を負荷調整指示情報として計算機１（１００）に出力する。
同様に、負荷調整指示情報生成部３０３は、性能統計更新部２０５から統計情報を取得し、サービス実行部２０３が既に受け入れているトークン数を集計し、サービス実行部２０３が更に受け入れ可能なトークン数を算出し、算出したトークン数を通知する情報を負荷調整指示情報として計算機２（２００）に出力する。
なお、負荷調整指示情報生成部３０３は、トークン数算出部の例に相当する。
また、計算機間統計共有部３０４は、負荷調整ルール情報３０４１を保持する。
負荷調整ルール情報３０４１には、図８に例示する負荷調整ルールが定義されている。

負荷調整ルールは、計算機１（１００）及び計算機２（２００）の間で負荷を調整するための意思決定を行うためのルールである。
図８において、「シーン」とは、運用管理者が設定するシステム状態であり、スマートメータシステムでは通常時、停電時などがある。
シーンに応じて、各計算機の負荷を調整するために、負荷調整ルール情報３０４１では、計算機ごとにトークンの受入可能数と各優先度のトークンの比率を指定する。
図８では、例えば「シーン：通常時」の「計算機：Ｃ１」では、トークンの受入可能数は、トークンの受け入れの上限数である１００から既に受け入れているトークンの数である実行トークン総数を引いた値であることが示されている。
また、同様に、「シーン：通常時」の「計算機：Ｃ１」では、受入可能数のうちの８０％が高優先度のトークンであり、１０％が中優先度のトークンであり、更に１０％が低優先度のトークンであることが示されている。
負荷調整指示情報生成部３０３は、負荷調整ルール情報３０４１で定義された負荷調整ルールに基づき、サービス実行部１０３及びサービス実行部２０３が受入可能なトークン数を優先度別に算出する。

次に、図２を参照して、計算機１（１００）のＥＳＢ１０６及び計算機２（２００）のＥＳＢ２０６の詳細を説明する。
なお、ＥＳＢ１０６とＥＳＢ２０６は同じ構成を有するので、以下では、ＥＳＢ１０６の構成のみを説明する。
ＥＳＢ１０６は、サービス制御部５０１、ルーティングファイル記憶部５０２、トークンキュー管理部５０３、ルール記憶部５０４、メッセージルータ５０５、ＥＳＢ間インタフェース５０６を有する。
なお、ＥＳＢ３０５は、図２と同じ構成をとる必要はなく、少なくともメッセージルータ５０５及びＥＳＢ間インタフェース５０６を有していればよい。

サービス制御部５０１は、サービスの実行順序の調整、ワークロードバランスの調整を行う。
サービス制御部５０１は、サービス実行待機評価部５０１１、他サーバ移動部５０１２、受信部５０１３及び送信部５０１４を含む。
サービス制御部５０１の構成要素の詳細は、後述する。

ルーティングファイル記憶部５０２は、ルーティングファイルを記憶している。
図２の例では、ルーティングファイル記憶部５０２は、Ｐ１（５０２１）、Ｐ２（５０２２）、通信サービス（５０２３）の３つのルーティングファイルを記憶している。
各ルーティングファイルは、例えば、図３に示す内容をもつ。
図３に示すように、Ｐ１（５０２１）は、定期収集業務のフローが示されるルーティングファイルである。
ルーティングファイルのフローでは、複数のサービスが、サービスの実行順序とともに定義されている。
Ｐ１（５０２１）のルーティングファイルにおいて、ａ１〜ａ５の各々がサービスに該当する。
また、「ａ２：通信１」サービスの詳細は、通信サービス（５０２３）の「通信１：ＤＣＵ定期通信」に定義されている。
同様に、「ａ３：通信２」サービスの詳細は、通信サービス（５０２３）の「通信２：メータ通信」に定義されている。
Ｐ２（５０２２）は、メータ監視制御アプリケーションのルーティングファイルである。
Ｐ２（５０２２）のルーティングファイルにおいても、ｂ１〜ｂ３の各々がサービスに該当する。
Ｐ１（５０２１）及びＰ２（５０２２）において、各サービスの近傍に記述されている「Ｌ」、「Ｍ」及び「Ｈ」は優先度を示している。
つまり、「Ｌ」は低優先度、「Ｍ」は中優先度、「Ｈ」は高優先度を意味する。
なお、サービスの優先度は、サービスフローごとに一様ではない。
図２の例では、サービス：ａ１〜ａ３は、Ｐ１（５０２１）のフローでは、「Ｍ」（中優先度）となっているが、例えば、図２に図示していない「Ｐ３」という別のフローでは、サービス：ａ１〜ａ３は「Ｌ」（低優先度）又は「Ｈ」（高優先度）であってもよい。

トークンキュー管理部５０３には、複数のトークンキューが設けられている。
トークンキューは、それぞれ、異なるサービスに対応する両端キューである。
図２に示すように、トークンキュー５０３１は、サービスａ１に対応し、サービスａ１のトークンを格納する。
同様に、トークンキュー５０３２は、サービスａ２に対応し、サービスａ２のトークンを格納する。
各トークンキューは、トークン格納部の例に相当する。
また、トークンとは、サービスのアプリケーションの実行情報を保持実行するオブジェクトであり、サービスのインスタンスの情報である。
サービスの実行はトークンごとに行われる。
また、トークンには、サービスの優先度が設定されている。
トークンキューは、図４に示すように、優先度別にトークンの格納領域が区分されている。
図４は、サービスａ２のトークンキュー５０３２を例示しているが、トークンキュー５０３２は高優先度、中優先度、低優先度に区分されている。
優先度別の格納領域を、優先度キューともいう。
そして、図４において符号６００の円がトークンを表している。
前述したように、サービスの優先度はフローごとに一様ではないため、あるフローではサービスａ２の優先度が「中」であり、他のフローでは「低」であるということが生じる。

ルール記憶部５０４は、複数のルール情報を記憶する。
具体的には、ルール記憶部５０４は、実行順序調整ルール情報５０４１、移動ルール情報５０４２及びルール適用対応表５０４３を記憶する。
なお、実行順序調整ルール情報５０４１、移動ルール情報５０４２及びルール適用対応表５０４３に記述されているルールを、まとめて調整ルールともいう。
実行順序調整ルール情報５０４１には、サービスの実行順序を調整するための実行順序調整ルールが１つ以上定義されている。
移動ルール情報５０４２には、トークンを計算機間で移動させるか否かの判定のための移動ルールが１つ以上定義されている。
ルール適用対応表５０４３は、実行順序調整ルール及び移動ルールを、ルーティングファイルに記述したどのフローのどのサービスに適用するかが定義されている。

実行順序調整ルール情報５０４１には、例えば、図５に示す実行順序調整ルールが定義されている。
実行順序調整ルール情報５０４１では、条件判断文（ｉｆ文）を評価してＴＲＵＥの結果が得られた場合に実行する内容とＦＡＬＳＥの結果が得られた場合に実行する内容とが、スクリプト言語により記述されている。
実行順序調整ルール情報５０４１には、条件判断式（ｉｆ文）を評価した結果に実行する内容として、例えば、ｗａｉｔ（）、ｓｔｏｐ（）、ｒｅｃｅｉｖｅ（）を記述することができる。
ｗａｉｔ（）は、トークンキューから取り出したトークンを同じトークンキューに戻させる命令である。
ｓｔｏｐ（）は、トークンキューから取り出したトークンを同じトークンキューに戻すとともに、そのトークンキューからの取り出しを停止させる命令である。
ｒｅｃｅｉｖｅ（）は、トークンキューから取り出したトークンを受信部５１０３に送らせる命令である。
ｒｅｃｅｉｖｅ（）によって、受信部５１０３に送られたトークンは、受信部５０１３によってサービス実行部１０３に送られ、サービス実行部１０３がトークンに基づき、該当するサービスのサービスアプリケーションコードを実行する。
ｗａｉｔ（）及びｓｔｏｐ（）は、トークンキューから取り出したトークンのサービスの実行を保留する命令であり、ｒｅｃｅｉｖｅ（）は、トークンキューから取り出したトークンのサービスの実行を開始させる命令である。

図５の実行順序調整ルールでは、優先して実行される優先サービスが定義され、優先サービスのトークンキューにトークンが格納されていない場合に、優先サービス以外のサービスが実行されるというルールが定義されている。
図５の実行順序調整ルールは、ルールＩＤ（Ｉｄｅｎｔｉｆｉｅｒ）がＲ１であり、ルール適用対応表５０４３（図７）では、フロー「Ｐ１」のサービス「ａ１」、「ａ２」、「ａ３」に実行順序調整ルール（ＩＤ：Ｒ１）が適用される旨が規定されているため、図５のｉｆ文は、サービス「ａ１」、「ａ２」、「ａ３」のトークンがトークンキューから取り出される場合に評価される。
そして、図５の実行順序調整ルールでは、フロー「メータ監視制御」のサービス「準備２」、「通信２」、「ＭＤＭ３」が優先サービスとして定義されており、優先サービスのトークンがトークンキューに存在している場合は、サービス「ａ１」、「ａ２」、「ａ３」のトークンは、トークンキューに戻される（ｗａｉｔ）。
一方、優先サービスのトークンが存在しない場合は、サービス「ａ１」、「ａ２」、「ａ３」のトークンは受信部５０１３に送られる（ｒｅｃｅｉｖｅ）。
このように、実行順序調整ルール情報５０４１では、サービスの実行順序の調整ルールが、サービスの属性（図５の場合は、フロー「メータ監視制御」のサービス「準備２」、「通信２」、「ＭＤＭ３」という属性）に関連付けて定義されている。

なお、図５は、実行順序調整ルール情報５０４１に記述される実行順序調整ルールの一例を示しており、他の評価基準が用いられたルールでもよい。
例えば、最も優先度が高いトークンのサービスが実行されるという実行順序調整ルールが定義されていてもよい。
また、サービスの実行に関連するＤＣＵエリアに対応付けた実行順序調整ルールが定義されていてもよい。
例えば、ＤＣＵエリアＡからデータを収集するサービスのトークンが存在していない場合のみ、他のエリアからデータを収集するサービスを実行することができるという実行順序調整ルールが定義されていてもよい。
また、評価対象の計算機（例えば計算機１（１００））の負荷（トークン数）と他の計算機（例えば計算機２（２００））の負荷（トークン数）とに対応付けた実行順序調整ルールが定義されていてもよい。
更に、前述の負荷調整ルール情報３０４１（図８）のオブジェクト変数が評価基準として含まれる条件判断式が記述された実行順序調整ルールであってもよい。
なお、負荷調整ルール情報３０４１は、計算機間で負荷バランスを調整するためのルール情報である。
また、ＤＣＵエリアごとに、異なる実行順序調整ルールを用いるようにしてもよい。

移動ルール情報５０４２には、例えば、図６に示す移動ルールが定義されている。
移動ルール情報５０４２では、条件判断文（ｉｆ文）を評価してＴＲＵＥの結果が得られた場合に実行する内容とＦＡＬＳＥの結果が得られた場合に実行する内容とが、スクリプト言語により記述されている。
実行順序調整ルール情報５０４１には、条件判断式（ｉｆ文）を評価した結果に実行する内容として、例えば、ｓｅｎｄＴｏ（）、ｌｅａｖｅ（）を記述することができる。
ｓｅｎｄＴｏ（）は、ある計算機（例えば計算機１（１００））のトークンキューから取り出したトークンを他の計算機（例えば計算機２（２００））のトークンキューに移動させる命令である。
ｌｅａｖｅ（）は、ある計算機（例えば計算機１（１００））のトークンキューから取り出したトークンを他の計算機（例えば計算機２（２００））のトークンキューに移動させずに、その計算機（例えば計算機１（１００））のトークンキューに戻させる命令である。

図６の移動ルールでは、優先して実行される優先サービスが定義され、優先サービスのトークンが格納されている計算機から、優先サービスのトークンが格納されていない他の計算機にトークンを移動させるというルールが定義されている。
図６の移動ルールは、ルールＩＤがＲ２であり、ルール適用対応表５０４３（図７）では、全てのサービスに移動ルール（ＩＤ：Ｒ２）が適用される旨が規定されている。
つまり、図６のｉｆ文は、全てのサービスのトークンがトークンキューから取り出される場合に評価される。
そして、図６の移動ルールでは、フロー「メータ監視制御」のサービス「準備２」、「通信２」、「ＭＤＭ３」が優先サービスとして定義され、計算機１（１００）に優先サービスのトークンが存在しており、計算機２（２００）に優先サービスのトークンが存在していない場合は、計算機１（１００）において取り出されたトークンを、計算機２（２００）トークンキューに移動させる（ｓｅｎｄＴｏ）。
一方、上記の条件が成立しない場合は、計算機１（１００）において取り出されたトークンを、元のトークンキューに戻す（ｌｅａｖｅ）。
このように、移動ルール情報５０４２では、トークンの移動ルールが、サービスの属性（図６の場合は、フロー「メータ監視制御」のサービス「準備２」、「通信２」、「ＭＤＭ３」という属性）に関連付けて定義されている。
また、移動ルール情報５０４２では、優先サービスのトークンが存在する計算機がトークンの移動元として定義され、優先サービスのトークンが存在しない計算機がトークンの移動先として定義されている。

なお、図６は、実行順序調整ルール情報５０４１の一例を示しており、他の評価基準が用いられた移動ルールでもよい。
例えば、特定レベル以下の優先度のトークンは他の計算機に移動させるという移動ルールが定義されていてもよい。
また、サービスの実行に関連するＤＣＵエリアに対応付けた移動ルールが定義されていてもよい。
例えば、ＤＣＵエリアＡからデータを収集するサービスのトークンは他の計算機に移動させるという移動ルールが定義されていてもよい。
また、評価対象の計算機（例えば計算機１（１００））の負荷（トークン数）と他の計算機（例えば計算機２（２００））の負荷（トークン数）とに対応付けた移動ルールが定義されていてもよい。
更に、前述の負荷調整ルール情報３０４１（図８）のオブジェクト変数が評価基準として含まれる条件判断式が記述された実行順序調整ルール情報５０４１であってもよい。
また、ＤＣＵエリアごとに、異なる移動ルールを用いるようにしてもよい。

メッセージルータ５０５は、サービスが通信プロトコル等を意識せずに通信を行えるようにするためのメッセージバスである。
ＥＳＢ間インタフェース５０６は、ＥＳＢ間のインタフェースを提供する。

サービス制御部５０１は、ＥＳＢのサービスごとに構成されルーティングファイルに従ったフロー実行の際のサービス間の連携と優先制御を行う機能である。
サービス制御部５０１は、例えば、トークンごとにサービスの実行開始又は実行の保留を決定し、また、優先制御に従った負荷バランス調整のためトークンを他の計算機に移動させる。

図９は、サービス制御部５０１の各要素と調整ルールとの関係、サービス制御部５０１の各要素と他の要素との関係を示している。

サービス実行待機評価部５０１１は、調整ルールに従って、トークンごとにサービスを実行するか待機して実行しないかを決定する。
サービス実行待機評価部５０１１は、トークンキューごとにトークンキューの先頭のトークンを取り出し、図９に示すように、主に実行順序調整ルール情報５０４１とルール適用対応表５０４３を参照して、取り出したトークンに対応するサービスの実行又はサービスの実行の保留を決定する。
サービス実行待機評価部５０１１は、サービス実行判定部の例に相当する。

他サーバ移動部５０１２は、調整ルールに従った判断によりトークンを他の計算機に移動させる。
他サーバ移動部５０１２は、トークンキューごとにトークンキューの最後尾からトークンを取り出し、主に移動ルール情報５０４２とルール適用対応表５０４３を参照して、取り出したトークンを、他の計算機のトークンキューに移動させるか否かを決定し、トークンの移動を決定した場合に、移動の対象となるトークンを、他の計算機のトークンキューに移動させる。
他サーバ移動部５０１２は、トークン移動部の例に相当する。

また、サービス実行待機評価部５０１１は、実行順序調整ルール情報５０４１に記述されている実行順序調整ルールに応じて、負荷調整指示情報７０２を参照してサービスの実行又は実行の待機を決定する場合がある。
また、他サーバ移動部５０１２は、移動ルール情報５０４２に記述されている移動ルールに応じて、負荷調整指示情報７０２を参照してトークンを他の計算機に移動させるか否かを決定する場合がある。
負荷調整指示情報７０２は、負荷調整指示情報生成部３０３により生成された情報である。
負荷調整指示情報７０２において、計算機統計情報は、例えば、サービス実行待機評価部５０１１が実装されている計算機のサービス実行部（例えば計算機１（１００）のサービス実行部１０３）で受入可能なトークンの数が優先度別に示される情報である。
また、サーバ間調整情報は、例えば、他の計算機（例えば計算機２（２００））でサービスが実行されているトークンの数、トークンキュー内のトークンの数が優先度別に示される情報である。
サービス実行待機評価部５０１１は、負荷調整指示情報７０２を参照することで、自計算機の負荷レベルと他の計算機の負荷レベルとを判断して、サービスの実行又は実行の待機を決定することができる。
また、他サーバ移動部５０１２は、負荷調整指示情報７０２を参照することで、自計算機の負荷レベルと他の計算機の負荷レベルとを判断して、トークンを他の計算機に移動させるか否かを決定することができる。
なお、負荷調整指示情報生成部３０３は、各計算機の性能統計更新部１０５で生成された計算機統計情報７０１と負荷調整ルール情報３０４１を用いて、負荷調整指示情報７０２を生成する。
計算機統計情報７０１に含まれるサーバ実行負荷統計には、サービスが実行されているトークンの数が優先度別に示される。
また、サービス要求負荷統計には、トークンキュー内にあるトークンの数が優先度別に示される。
負荷調整ルール情報３０４１は、図８に例示したように、計算機ごとにトークンの受入可能数と各優先度のトークンの比率が指定された情報である。

受信部５０１３は、サービス実行待機評価部５０１１によりサービスの実行が決定されたトークンをサービス実行待機評価部５０１１から取得し、取得したトークンをサービス実行部１０３に出力して、サービス実行部１０３にサービスアプリケーションコードを実行させる。

送信部５０１４は、サービス実行部１０３のサービスアプリケーションコードの実行結果が格納された後のトークンを取得し、取得したトークンをメッセージルータ５０５に送信する。
なお、送信部５０１４からトークンを渡されたメッセージルータ５０５は、ルーティングファイル（図３）に従い、次に実行するサービスのトークンを送信部５０１４に渡す。
送信部５０１４は、メッセージルータ５０５から渡されたトークンを該当するサービスのトークンキューに格納する。

なお、通常のＥＳＢのサービス制御機能は、単一のメッセージルータの内部キューと、受信部５０１３に相当する機能、送信部５０１４に相当する機能、サービスアプリケーションコードで構成され、内部キューから取り出したトークンによりサービスアプリケーションを実行してメッセージルータに渡すだけであり、調整ルールに従って、トークンの優先制御、他サーバへの移動、サービス実行待機を行う機能はない。

次に、本実施の形態のセンターシステム１０００の動作について説明する。
図１０及び図１１は、サービス実行待機評価部５０１１が、トークンをキューから取り出し、実行順序調整ルール情報５０４１を用いてサービスの実行又は待機を判断する動作の流れを示す。
なお、サービス実行待機評価部５０１１は、トークンキューごとに（つまり、サービスごとに）、図１０及び図１１の動作を行う。

ｓｔ１１では、サービス実行待機評価部５０１１は、トークンキューの各優先度キューにトークンが含まれるかどうかを調査する。

ｓｔ１２では、サービス実行待機評価部５０１１は、トークンが含まれる優先度キューがない場合は、処理を終了する。
一方、トークンが含まれる優先度キューがある場合はｓｔ１３に遷移する。
なお、トークンが含まれる優先度キューがあるサービスが実行候補サービスの例に相当する。

ｓｔ１３では、サービス実行待機評価部５０１１は、トークンが含まれる優先度キューのうち最高優先度の優先度キューを選択し、以降の処理は、この選択した優先度キューを対象として行う。

ｓｔ１４では、ｓｔ１３で選択した優先度キューの先頭のトークンを取り出す。

ｓｔ１５では、サービス実行待機評価部５０１１は、ルール適用対応表５０４３を調査し、現在対象としているサービスに適用する実行順序調整ルールがルール適用対応表５０４３に定義されているか（サービス名に対してルールＩＤが定義されているか）を判断する。

ｓｔ１６では、現在対象としているサービスに適用する実行順序調整ルールがない場合は、サービス実行待機評価部５０１１は、ｓｔ１１３に遷移する。
一方、適用するルールがある場合は、サービス実行待機評価部５０１１は、ｓｔ１７に遷移する。

ｓｔ１７では、サービス実行待機評価部５０１１は、実行順序調整ルールのオブジェクト変数を生成する。

ｓｔ１８では、サービス実行待機評価部５０１１は、ルールＩＤに対応するルール内容の条件式を評価する。

ｓｔ１９では、サービス実行待機評価部５０１１は、条件式の評価結果に応じた関数を選択する。

ｓｔ１１０では、サービス実行待機評価部５０１１は、ｗａｉｔ（）を選択した場合はｓｔ１１１に遷移し、ｓｔｏｐ（）を選択した場合はｓｔ１１２に遷移し、ｒｅｃｅｉｖｅ（）を選択した場合は、ｓｔ１１３に遷移する。

ｓｔ１１１では、サービス実行待機評価部５０１１は、サービスの実行を待機させるために、ｓｔ１４で取り出したトークンを取り出し元の優先度キューの先頭に入れる。

ｓｔ１１２では、サービス実行待機評価部５０１１は、ｓｔ１４で取り出したトークンを取り出し元の優先度キューの先頭に入れるとともに、取り出し元の優先度キューから以後トークンの取り出しを停止する。

ｓｔ１１３では、サービス実行待機評価部５０１１が、取り出したトークンを受信部５０１３に送信し、受信部５０１３がトークンを受信する。

ｓｔ１１４では、受信部５０１３がトークンをサービス実行部１０３に送信し、サービス実行部１０３がトークンを受け入れ、該当するサービスのサービスアプリケーションコードを実行する。

ｓｔ１１５では、サービス実行部１０３が、サービスアプリケーションコードの実行結果をトークンに保存する。

ｓｔ１１６では、サービス実行部１０３がトークンを送信部５０１４に送信し、送信部５０１４がトークンをメッセージルータ５０５に送信する。

ｓｔ１１７では、メッセージルータ５０５がルーティングファイルより次のサービスを決定し、送信部５０１４が、次のサービスのトークンを、対応するトークンキューの優先度キューに格納する。

図１２は、他サーバ移動部５０１２が、トークンをキューから取り出し、移動ルール情報５０４２を用いてトークンを移動させるか否かを判断する動作の流れを示す。
なお、他サーバ移動部５０１２は、トークンキューごとに（つまり、サービスごとに）、図１２の動作を行う。

ｓｔ２１では、他サーバ移動部５０１２は、トークンキューの各優先度キューにトークンが含まれるかどうかを調査する。

ｓｔ２２では、他サーバ移動部５０１２は、トークンが含まれる優先度キューがない場合は、処理を終了する。
一方、トークンが含まれる優先度キューがある場合はｓｔ２３に遷移する。

ｓｔ２３では、他サーバ移動部５０１２は、トークンが含まれる優先度キューのうち最高優先度の優先度キューを選択し、以降の処理は、この選択した優先度キューを対象として行う。

ｓｔ２４では、ｓｔ２３で選択した優先度キューの最後尾のトークンを取り出す。

ｓｔ２５では、他サーバ移動部５０１２は、ルール適用対応表５０４３を調査し、現在対象としているサービスに適用する移動ルールがルール適用対応表５０４３に定義されているか（サービス名に対してルールＩＤが定義されているか）を判断する。

ｓｔ２６では、現在対象としているサービスに適用する移動ルールがない場合は、他サーバ移動部５０１２は、ｓｔ３０に遷移する。
一方、適用するルールがある場合は、サービス実行待機評価部５０１１は、ｓｔ２７に遷移する。

ｓｔ３０では、他サーバ移動部５０１２は、ｓｔ２４で取り出したトークンを取り出し元の優先度キューの同じ位置に戻し、ｓｔ２４で取り出したトークンの１つ前のトークンを取り出す。
以降は、他サーバ移動部５０１２は、ｓｔ２５とｓｔ２６の動作を繰り返す。

ｓｔ２７では、他サーバ移動部５０１２は、移動ルールのオブジェクト変数を生成する。

ｓｔ２８では、他サーバ移動部５０１２は、ルールＩＤに対応するルール内容の条件式を評価する。

ｓｔ２９では、他サーバ移動部５０１２は、条件式の評価結果に応じた関数を選択する。

ｓｔ２１０では、他サーバ移動部５０１２は、ｓｅｎｄＴｏ（）を選択した場合はｓｔ２１１に遷移し、ｌｅａｖｅ（）を選択した場合はｓｔ２１２に遷移する。

ｓｔ２１１では、他サーバ移動部５０１２は、移動ルールで指定されている計算機のトークンキューにトークンを移動させる。

ｓｔ２１２では、他サーバ移動部５０１２は、ｓｔ２４で取り出したトークンを取り出し元の優先度キューの同じ位置に戻す。

実施の形態１の効果について述べる。
実施の形態１によりルーティングのフローのサービス実行の粒度で負荷調整が可能である。
そして、調整ルールを用いたキューベースの優先制御により、後続処理として優先サービスがある場合なども考慮した柔軟な優先処理が可能となる。
また、本実施の形態では、ＣＰＵの負荷と単一のサービス優先度だけで負荷バランスを調整するのでなく、調整ルールの条件式を用いて状況判断を行いながらシーンに応じた負荷調整が可能となる。
このため、課題１を解決することができる。

実施の形態２．
図１３に、実施の形態２のスマートメータシステムの構成例を示す。
図１の構成に比べて、図１３では、計算機１（１００）にフロー・ルール置換部１０７が追加され、計算機２（２００）にフロー・ルール置換部２０７が追加されている。
図１３の他の要素は、図１と同じである。
フロー・ルール置換部１０７及びフロー・ルール置換部２０７は、スマートメータのアプリケーションの起動時の業務パラメータに基づき、実行するルーティングファイルのフローと調整ルールを別のものに置き換える。
フロー・ルール置換部１０７とフロー・ルール置換部２０７の動作は同じであるため、以下では、フロー・ルール置換部１０７の動作を説明する。

図１４は、フロー・ルール置換部１０７の動作を説明する図である。
本実施の形態では、あるサービスを実現するための処理アルゴリズムに複数のバリエーションがあることを前提としている。
なお、処理アルゴリズムに複数のバリエーションがあるサービスを、特例サービスという。
図１４の例では、「通信１」が特例サービスである。
「通信１」のサービスを実現するための処理アルゴリズムとして、「ＤＣＵ通信置換フローＡ」と「ＤＣＵ通信置換フローＢ」という２つの処理アルゴリズムが存在している。
フロー・ルール置換部１０７は、例えば、「Ｐ１：定期収集」のサービスフローの開始要求をユーザから入力するとともに、「Ｐ１：定期収集」のサービスフローに関連する業務パラメータを入力する。
ここでは、フロー・ルール置換部１０７が入力する業務パラメータがＤＣＵのＩＤであるとする。
フロー・ルール置換部１０７は、入力した業務パラメータ（ＤＣＵのＩＤ）と、業務パラメータルール・フロー置換設定ファイルに基づき、「Ｐ１：定期収集」の「通信１」に対して、「ＤＣＵ通信置換フローＡ」又は「ＤＣＵ通信置換フローＢ」を選択する。
そして、サービス実行部１０３は、「Ｐ１：定期収集」において、フロー・ルール置換部１０７により選択された処理アルゴリズム（「ＤＣＵ通信置換フローＡ」又は「ＤＣＵ通信置換フローＢ」）に従って「通信１」のサービスを行う。
また、本実施の形態では、「Ｐ１：定期収集」の「通信１」に対して「調整ルールＡ」と「調整ルールＢ」の２つが設定されている。
フロー・ルール置換部１０７は、入力した業務パラメータ（ＤＣＵのＩＤ）と、業務パラメータルール・フロー置換設定ファイルに基づき、「Ｐ１：定期収集」の「通信１」に対して、「調整ルールＡ」又は「調整ルールＢ」を選択する。
そして、サービス実行待機評価部５０１１は、「通信１」のトークンに対して、フロー・ルール置換部１０７により選択された調整ルール（「調整ルールＡ」又は「調整ルールＢ」）を適用して、「通信１」のサービスの開始又は待機を判断する。
また、他サーバ移動部５０１２は、「通信１」のトークンに対して、フロー・ルール置換部１０７により選択された調整ルール（「調整ルールＡ」又は「調整ルールＢ」）を適用して、「通信１」のトークンを他の計算機に移動させるかどうかを判断する。
フロー・ルール置換部１０７は、開始要求入力部、アルゴリズム選択部及びルール選択部の例に相当する。

図１５は、業務パラメータルール・フロー置換設定ファイルに含まれる構成・業務パラメータ対応表の例を示す。
また、図１６及び図１７は、業務パラメータルール・フロー置換設定ファイルに含まれる構成選択ルールの例を示す。
図１５では、構成Ａと構成Ｂが示され、構成Ａに対しては「調整ルールＡ」が用いられ、また、「ＤＣＵ通信置換フローＡ」が用いられることが定義されている。
また、構成Ｂに対しては「調整ルールＢ」が用いられ、また、「ＤＣＵ通信置換フローＢ」が用いられることが定義されている。
図１６の構成選択ルールでは、業務パラメータとして入力されたＤＣＵのＩＤが「０」から「１０００」までであれば、「構成Ａ」が選択されることが定義されている。
一方、図１７の構成選択ルールでは、業務パラメータとして入力されたＤＣＵのＩＤが「１００１」から「１００００」までであれば、「構成Ｂ」が選択されることが定義されている。
このようにして、フロー・ルール置換部１０７は、入力した業務パラメータ（ＤＣＵのＩＤ）と、業務パラメータルール・フロー置換設定ファイルとに基づき、サービス「通信１」に対して、「ＤＣＵ通信置換フローＡ」又は「ＤＣＵ通信置換フローＢ」を選択し、また、「調整ルールＡ」又は「調整ルールＢ」を選択する。

次に、実施の形態２の効果について説明する。
フロー・ルール置換部１０７により、フロー開始時に調整ルールとルーティングファイルのフローを、サービスのパラメータにより切り替えることができる。
そして、パラメータとしてＤＣＵのエリア（ＤＣＵのＩＤ）を使用すると、エリアの違いによりルールを切り替えてそれぞれのエリアにふさわしい、優先制御とワークロードバランスが可能となる。
このため、課題２を解決することができる。

実施の形態３．
図１８に、実施の形態３の計算機３（３００）の構成例を示す。
本実施の形態では、計算機３（３００）以外の構成は、図１又は１３と同じである。
図１又は図１３に示す計算機３（３００）の構成と比べて、図１８では、システム構成予約管理部３０６、システム構成要素予約サービス３０７及びシステム構成予約情報３０８が追加されている。
システム構成予約管理部３０６は、スマートメータシステム内のシステム構成要素のうちセンターシステム１０００以外のシステム構成要素の使用状況をサービス間で共有して、各システム構成要素が使用可能かどうかを管理する。
システム構成要素予約サービス３０７は、センターシステム１０００以外の各システム構成要素の使用状況の情報を保持する。
システム構成予約情報３０８は、センターシステム１０００以外のシステム構成要素の使用状況を変更するサービスである。
また、本実施の形態では、図１９に例示するルーティングファイルが用いられる。
図３の通信サービスのフロー５０２３と比較して、図１９の通信サービスのフロー５０２４では通信予約が行われている。
また、図１９のルーティングファイルでは、ＤＣＵ、通信装置、メータとの通信予約のためのシステム構成要素予約サービスが含まれている。

本実施の形態では、実行順序調整ルール情報５０４１に、例えば、システム構成要素予約サービスを優先サービスとして定義し、システム構成要素予約サービスのトークンが存在していない場合にシステム構成要素予約サービス以外のサービスが実行されるという実行順序調整ルールを記述しておくことが考えられる。
この実行順序調整ルールにより、システム構成要素予約サービスは他のサービスに優先して実行される。

実施の形態３の効果について述べる。
システム構成予約管理部３０６とシステム構成要素予約サービス３０７とシステム構成予約情報３０８により、センターシステム１０００以外のシステム構成要素を考慮した優先制御が可能となる。
すなわち、センターシステム１０００上のアプリケーションだけでなく、メータ、ＤＣＵ，通信機器などスマートメータシステムに含まれるシステム構成要素に対する優先制御が可能となる。

以上、実施の形態１〜３では、スマートメータシステムにおけるサービス、サービスフローを実行するメッセージ連携ミドルウェア（ＥＳＢ）を用いたサービス連携装置を説明した。
そして、実施の形態１〜３では、業務アプリケーションのフローの他に、構成要素やフローを意識した個別のアプリケーションの負荷調整を行うことを目的とした、サービス実行機能とＥＳＢコンテナ間調整機能からなる優先制御つきサービス連携装置を説明した。

そして、サービス実行機能は、以下の機能を有することを説明した。
１）サービスの流れを定義したフローの定義と、システム構成要素予約サービスを含むルーティングファイルと、ルーティングファイルにより制御されるＥＳＢバス
２）以下の機能により構成されるサービスアプリケーションロジックを呼び出すサービス制御機能
ａ）サービスのインスタンスをトークンとして優先度ごとに保持する優先度キュー
ｂ）優先度キューの最後尾からトークンを取り出し、調整ルール設定ファイルと負荷調整指示情報を用いて評価し他サーバに移動するかどうかを判断する他サーバ移動機能
ｃ）優先度キューの先頭からトークンを取り出し、調整ルール設定ファイルと負荷調整指示情報を用いて評価し、サービス実行を行うか、実行しないで待機させるかを判断するサービス実行待機評価機能
ｄ）サービス実行待機評価機能からトークンを受信して、サービスアプリケーションコードを実行する受信機能
ｅ）サービスアプリケーションコードの結果より実行後のトークンを生成して次のサービスに遷移させる送信機能
３）システム連携サーバの計算機全体の性能情報（ＣＰＵ負荷など）と、各サービスの優先度キュー上のトークンの統計情報を収集してＥＳＢコンテナ間調整機能の計算機統計情報に送る自サーバ性能統計更新機能。

また、ＥＳＢ間コンテナ間調整機能は、以下の機能を有することを説明した。
１）複数のＥＳＢでサーバごとの、サーバ実行負荷統計とサービス要求負荷統計を含む計算機統計情報を共有するための計算機間統計共有機能
２）計算機間統計共有機能とシステム構成要素予約サービスから、各システム連携計算機に対する負荷調整指示メッセージを作成する負荷調整指示生成機能。

また、実施の形態１〜３では、サービス実行機能が、以下の機能を有することを説明した。
業務パラメータルール・フロー置換設定ファイルに従って、実行するトークンのエリア（ＤＣＵエリア）などのフロー開始時のパラメータより、実行するトークンのエリア（ＤＣＵエリア）などのパラメータに応じて、開始するフローを切り換えるフロー・ルール置換機能。

また、実施の形態１〜３では、ＥＳＢコンテナ間調整機能が、以下の機能を有することを説明した。
スマートメータの機器の構成と使用状況を含むシステム構成予約情報と、システム構成予約情報を管理するシステム構成予約管理機能と、アプリケーションからシステム構成予約を行うシステム構成要素予約サービス。

最後に、実施の形態１〜３に示した計算機１（１００）、計算機２（２００）、計算機３（３００）のハードウェア構成例を図２０を参照して説明する。
以下では、計算機１（１００）のハードウェア構成例を説明するが、以下の説明は、計算機２（２００）及び計算機３（３００）にも適用可能である。
計算機１（１００）はコンピュータであり、計算機１（１００）の各要素をプログラムで実現することができる。
計算機１（１００）のハードウェア構成としては、バスに、演算装置９０１、外部記憶装置９０２、主記憶装置９０３、通信装置９０４、入出力装置９０５が接続されている。

演算装置９０１は、プログラムを実行するＣＰＵである。
外部記憶装置９０２は、例えばＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）やフラッシュメモリ、ハードディスク装置である。
主記憶装置９０３は、ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）である。
通信装置９０４は、例えば通信カードである。
入出力装置９０５は、例えばマウス、キーボード、ディスプレイ装置等である。
実施の形態１〜３で示した、「記憶部１０４」、「ルーティングファイル記憶部５０２」、「トークンキュー管理部５０３」及び「ルール記憶部５０４」は、外部記憶装置９０２又は主記憶装置９０３で実現される。

プログラムは、通常は外部記憶装置９０２に記憶されており、主記憶装置９０３にロードされた状態で、順次演算装置９０１に読み込まれ、実行される。
プログラムは、図１に示す「〜部」（「記憶部１０４」、「ルーティングファイル記憶部５０２」、「トークンキュー管理部５０３」及び「ルール記憶部５０４」を除く、以下でも同様）として説明している機能を実現するプログラムである。
更に、外部記憶装置９０２にはオペレーティングシステム（ＯＳ）も記憶されており、ＯＳの少なくとも一部が主記憶装置９０３にロードされ、演算装置９０１はＯＳを実行しながら、図１に示す「〜部」の機能を実現するプログラムを実行する。
また、サービスアプリケーションコードも外部記憶装置９０２に記憶されており、主記憶装置９０３にロードされた状態で、順次演算装置９０１により実行される。
また、実施の形態１〜４の説明において、「〜の判断」、「〜の判定」、「〜の決定」、「〜の抽出」、「〜の調査」、「〜の評価」、「〜の実行」、「〜の設定」、「〜の登録」、「〜の選択」、「〜の生成」、「〜の入力」、「〜の出力」、「〜の受信」、「〜の送信」等として説明している処理の結果を示す情報やデータや信号値や変数値が主記憶装置９０３にファイルとして記憶されている。
また、ＤＣＵやメータから受信したデータが主記憶装置９０３や外部記憶装置９０２に記憶される。
また、暗号鍵・復号鍵や乱数値やパラメータが、主記憶装置９０３にファイルとして記憶されてもよい。

なお、図２０の構成は、あくまでも計算機１（１００）のハードウェア構成の一例を示すものであり、計算機１（１００）のハードウェア構成は図２０に記載の構成に限らず、他の構成であってもよい。

１００ 計算機１、１０１ 通信部、１０２ 入出力部、１０３ サービス実行部、１０４ 記憶部、１０５ 性能統計更新部、１０６ ＥＳＢ、１０７ フロー・ルール置換部、２００ 計算機２、２０１ 通信部、２０２ 入出力部、２０３ サービス実行部、２０４ 記憶部、２０５ 性能統計更新部、２０６ ＥＳＢ、２０７ フロー・ルール置換部、３００ 計算機３、３０１ 通信部、３０２ 入出力部、３０３ 負荷調整指示情報生成部、３０４ 計算機間統計共有部、３０５ ＥＳＢ、３０６ システム構成予約管理部、３０７ システム構成要素予約サービス、３０８ システム構成予約情報、４０１ ネットワーク、４０２ ネットワーク、４０３ ネットワーク、４０４ ＤＣＵ、４０５ メータ、４０６ メータ、５０１ サービス制御部、５０２ ルーティングファイル記憶部、５０３ トークンキュー管理部、５０４ ルール記憶部、５０５ メッセージルータ、５０６ ＥＳＢ間インタフェース、１０００ センターシステム、３０４１ 負荷調整ルール情報、５０１１ サービス実行待機評価部、５０１２ 他サーバ移動部、５０１３ 受信部、５０１４ 送信部、５０３１ トークンキュー、５０３２ トークンキュー、５０３３ トークンキュー、５０３４ トークンキュー、５０３４ トークンキュー、５０３６ トークンキュー、５０４１ 実行順序調整ルール情報、５０４２ 移動ルール情報、５０４３ ルール適用対応表。

Claims (13)

1. 複数のサービスの実行を管理する情報処理システムであって、
   それぞれが異なるサービスに対応し、それぞれが、対応するサービスについて、サービスのインスタンスの情報であるトークンを格納する、複数のトークン格納部と、
   サービスの実行順序を調整するための実行順序調整ルールが定義されている実行順序調整ルール情報を記憶する実行順序調整ルール情報記憶部と、
   トークン格納部ごとにトークンが格納されているか否かを判断し、対応するトークン格納部にトークンが格納されているサービスを実行候補サービスとして抽出し、抽出した実行候補サービスごとに、実行候補サービスを実行するか否かを決定するサービス実行判定部と、
   前記サービス実行判定部により実行が決定された実行候補サービスのトークンを受け入れ、受け入れたトークンに対応する実行候補サービスを実行するサービス実行部と、
   前記サービス実行部が既に受け入れているトークン数を集計し、前記サービス実行部が更に受け入れ可能なトークン数を算出するトークン数算出部とを有し、
   前記サービス実行判定部は、
   前記実行順序調整ルール情報の実行順序調整ルールと、前記トークン数算出部により算出された、前記サービス実行部が更に受け入れ可能なトークン数とを用いて、実行候補サービスごとに、実行候補サービスを実行するか否かを決定し、
   前記情報処理システムは、更に、
   複数のサービスが含まれるサービスフローの開始要求を入力するとともに、前記サービスフローに関連するパラメータを入力する開始要求入力部と、
   開始要求のあったサービスフローに、処理アルゴリズムに複数種のバリエーションがある特例サービスが含まれている場合に、前記開始要求入力部により入力されたパラメータに基づき、前記特例サービスの複数の処理アルゴリズムの中から特定の処理アルゴリズムを選択するアルゴリズム選択部とを有し、
   前記サービス実行部は、
   前記アルゴリズム選択部により選択された処理アルゴリズムに従って前記特例サービスを実行することを特徴とする情報処理システム。
2. 各トークン格納部は、
   優先度が設定されているトークンを格納し、
   前記トークン数算出部は、
   前記サービス実行部が既に受け入れているトークン数を優先度別に集計し、前記サービス実行部が更に受け入れ可能なトークン数を優先度別に算出し、
   前記サービス実行判定部は、
   実行候補サービスごとに、対応するトークン格納部から所定の条件に合致するトークンを抽出し、
   実行候補サービスごとに、抽出したトークンの優先度と、前記実行順序調整ルール情報の実行順序調整ルールと、前記トークン数算出部により算出された、前記サービス実行部が更に受け入れ可能な優先度別のトークン数とを用いて、実行候補サービスを実行するか否かを決定することを特徴とする請求項１に記載の情報処理システム。
3. 複数のサービスの実行を管理する情報処理システムであって、
   それぞれが異なるサービスに対応し、それぞれが、対応するサービスについて、サービスのインスタンスの情報であるトークンを格納する、複数のトークン格納部と、
   サービスの実行順序を調整するための実行順序調整ルールが複数定義されている実行順序調整ルール情報を記憶する実行順序調整ルール情報記憶部と、
   複数のサービスが含まれるサービスフローの開始要求を入力するとともに、前記サービスフローに関連するパラメータを入力する開始要求入力部と、
   開始要求のあったサービスフローに含まれる特定のサービスに対して、前記開始要求入力部により入力されたパラメータに基づき、前記実行順序調整ルール情報に定義されている複数の実行順序調整ルールの中から特定の実行順序調整ルールを選択するルール選択部と、
   トークン格納部ごとにトークンが格納されているか否かを判断し、対応するトークン格納部にトークンが格納されているサービスを実行候補サービスとして抽出し、抽出した実行候補サービスが前記特定のサービスである場合に、前記ルール選択部により選択された前記特定の実行順序調整ルールを用いて、前記特定のサービスを実行するか否かを決定するサービス実行判定部とを有することを特徴とする情報処理システム。
4. 前記実行順序調整ルール情報記憶部は、
   実行順序調整ルールがサービスの属性に関連付けて定義されている実行順序調整ルール情報を記憶しており、
   前記サービス実行判定部は、
   実行候補サービスごとに、実行候補サービスの属性と前記実行順序調整ルール情報の実行順序調整ルールとの照合及び他の実行候補サービスの属性と前記実行順序調整ルール情報の実行順序調整ルールとの照合の少なくともいずれかを行い、
   実行候補サービスを実行するか否かを決定することを特徴とする請求項１又は３に記載の情報処理システム。
5. 前記実行順序調整ルール情報記憶部は、
   優先して実行される優先サービスが示され、前記優先サービスのトークン格納部にトークンが格納されていない場合に、前記優先サービス以外のサービスが実行されるという実行順序調整ルールが定義されている実行順序調整ルール情報を記憶し、
   前記サービス実行判定部は、
   前記優先サービスのトークン格納部にトークンが格納されている場合は、実行候補サービスとして抽出された前記優先サービスを実行することを決定し、前記優先サービス以外の実行候補サービスを実行しないことを決定し、
   前記優先サービスのトークン格納部にトークンが格納されていない場合は、前記優先サービス以外の実行候補サービスを実行することを決定することを特徴とする請求項１又は３に記載の情報処理システム。
6. 各トークン格納部は、
   優先度が設定されているトークンを格納し、
   前記実行順序調整ルール情報記憶部は、
   ２つ以上のトークン格納部に格納されている２つ以上のトークンのうち、最も優先度が高いトークンのサービスが実行されるという実行順序調整ルールが定義されている実行順序調整ルール情報を記憶し、
   前記サービス実行判定部は、
   抽出した実行候補サービスごとに、対応するトークン格納部に格納されているトークンの優先度を検査し、
   トークンの優先度が最も高い実行候補サービスを実行することを決定し、
   他の実行候補サービスを実行しないことを決定することを特徴とする請求項１又は３に記載の情報処理システム。
7. 各トークン格納部は、
   優先度別の格納領域を有し、優先度が設定されているトークンを、対応する優先度の格納領域に格納し、
   前記サービス実行判定部は、
   実行候補サービスごとに、対応するトークン格納部の優先度別の格納領域のうちトークンが格納されている格納領域で最も高い優先度の格納領域を選択し、選択した格納領域の先頭に格納されているトークンを抽出し、
   抽出したトークンに対する実行候補サービスを実行するか否かを決定することを特徴とする請求項１又は３に記載の情報処理システム。
8. 複数のサービスの実行を管理する情報処理システムであって、
   それぞれがサービスを実行する、複数のサービス実行部と、
   それぞれが異なるサービス実行部に対応し、それぞれが、サービスのインスタンスの情報であるトークンを格納する、複数のトークン格納部と、
   トークンの移動ルールが定義されている移動ルール情報を記憶する移動ルール情報記憶部と、
   前記移動ルール情報に定義されている移動ルールに基づき、サービス実行部ごとに、対応するトークン格納部に格納されているトークンを、他のサービス実行部のトークン格納部に移動させるか否かを決定し、トークンの移動を決定したサービス実行部のトークン格納部に格納されているトークンを、他のサービス実行部のトークン格納部に移動させるトークン移動部とを有することを特徴とする情報処理システム。
9. 前記移動ルール情報記憶部は、
   トークンの移動ルールがサービスの属性に関連付けて定義されている移動ルール情報を記憶しており、
   前記トークン移動部は、
   サービス実行部ごとに、対応するトークン格納部に格納されているトークンが対応しているサービスの属性と前記移動ルール情報の移動ルールとの照合及び他のサービス実行部のトークン格納部に格納されているトークンが対応しているサービスの属性と前記移動ルール情報の移動ルールとの照合の少なくともいずれかを行い、
   サービス実行部ごとに、対応するトークン格納部に格納されているトークンを、他のサービス実行部のトークン格納部に移動させるか否かを決定することを特徴とする請求項８に記載の情報処理システム。
10. 前記移動ルール情報記憶部は、
    優先して実行される優先サービスが示され、対応するトークン格納部に前記優先サービスのトークンが格納されているサービス実行部から、対応するトークン格納部に前記優先サービスのトークンが格納されていない他のサービス実行部に、トークンを移動させるという移動ルールが定義されている移動ルール情報を記憶し、
    前記トークン移動部は、
    対応するトークン格納部に前記優先サービスのトークンが格納されているサービス実行部を移動元サービス実行部として抽出し、対応するトークン格納部に前記優先サービスのトークンが格納されていないサービス実行部を移動先サービス実行部として抽出し、
    前記移動元のサービス実行部のトークン格納部に格納されているいずれかのトークンを、前記移動先のサービス実行部のトークン格納部に移動することを特徴とする請求項８に記載の情報処理システム。
11. 前記トークン移動部は、
    前記移動元のサービス実行部のトークン格納部の最後尾に格納されているトークンを、前記移動先のサービス実行部のトークン格納部に移動することを特徴とする請求項９に記載の情報処理システム。
12. 各サービス実行部は、
    対応するトークン格納部に格納されているトークンを順次受け入れ、受け入れたトークンに対応するサービスを実行し、
    前記情報処理システムは、更に、
    各サービス実行部が既に受け入れているトークン数を集計し、各サービス実行部が更に受け入れ可能なトークン数を算出するトークン数算出部を有し、
    前記トークン移動部は、
    前記移動ルール情報に定義されている移動ルールと、前記トークン数算出部により算出された、各サービス実行部が更に受け入れ可能なトークン数とを用いて、サービス実行部ごとに、対応するトークン格納部に格納されているトークンを、他のサービス実行部のトークン格納部に移動させるか否かを決定することを特徴とする請求項８に記載の情報処理システム。
13. 各トークン格納部は、
    優先度が設定されたトークンを格納し、
    前記トークン数算出部は、
    各サービス実行部が既に受け入れているトークン数を優先度別に集計し、各サービス実行部が更に受け入れ可能なトークン数を優先度別に算出し、
    前記トークン移動部は、
    前記移動ルール情報に定義されている移動ルールと、前記トークン数算出部により算出された、各サービス実行部が更に受け入れ可能な優先度別のトークン数と、各サービス実行部のトークン格納部に格納されているトークンの優先度とを用いて、サービス実行部ごとに、対応するトークン格納部に格納されているトークンを、他のサービス実行部のトークン格納部に移動させるか否かを決定することを特徴とする請求項１２に記載の情報処理システム。

Images