(57)【要約】【解決手段】ソフトウェアのホットデプロイメントは、各々がサービスを実施するように第１のサービス処理エンジン及び第２のサービス処理エンジンを構成し、第１のサービス処理エンジンを動作状態に、第２のサービス処理エンジンを待機状態に設定し、サービスのパフォーマンスに影響を及ぼす変更を検出し、当該検出された変更に少なくとも部分的に基づいて、待機状態にある第２のサービス処理エンジンをアップデートすること、を含む。【選択図】図１
2013520748.tif 000002
【特許請求の範囲】
【請求項１】
ソフトウェアデプロイメントの方法であって、
各々がサービスを実施するように、第１のサービス処理エンジン及び第２のサービス処理エンジンを構成し、
前記第１のサービス処理エンジンを動作状態に、前記第２のサービス処理エンジンを待機状態に設定し、
前記サービスのパフォーマンスに影響を及ぼす変更を検出し、
前記検出された変更に少なくとも部分的に基づいて、前記待機状態にある第２のサービス処理エンジンをアップデートすること、
を備える方法。
【請求項２】
請求項１に記載の方法であって、更に、
前記アップデートされた第２のサービス処理エンジンを動作状態に、前記第１のサービス処理エンジンを待機状態に設定し、
前記検出された変更に少なくとも部分的に基づいて、前記第１のサービス処理エンジンをアップデートすること、
を備える方法。
【請求項３】
請求項２に記載の方法であって、
前記アップデートされた第２のサービス処理エンジンを動作状態に設定することは、前記第１のサービス処理エンジンに無効化命令を送信することを含む、方法。
【請求項４】
請求項１に記載の方法であって、
前記第１のサービス処理エンジンは、第１のサービスルールストレージに対応するように構成され、前記第２のサービス処理エンジンは、第２のサービスルールストレージに対応するように構成される、方法。
【請求項５】
請求項１に記載の方法であって、
前記動作状態は、１つ又は２つ以上のサービスリクエストを受信すること、前記１つ又は２つ以上のリクエストの少なくとも一部分が少なくとも１つのサービスルールを満たすか否かを決定すること、を含む、方法。
【請求項６】
請求項１に記載の方法であって、
前記待機状態は、処理設定若しくはサービスルールをアップデートすること、又は前記サービスのパフォーマンスに影響を及ぼす次の変更を検出すること、のいずれかを含む、方法。
【請求項７】
請求項１に記載の方法であって、
前記変更は、サービスルールの追加若しくは修正、及び／又は前記第１のサービス処理エンジンに関連付けられている処理設定に対する修正を含む、方法。
【請求項８】
請求項１に記載の方法であって、
検出は、定期的に又はリアルタイムで実施される、方法。
【請求項９】
請求項６に記載の方法であって、
アップデートは、対応するサービスルール、又は前記第２のサービス処理エンジンに関連付けられている処理設定を修正し、サービスルールの追加若しくは修正、及び／又は前記第１のサービス処理エンジンの処理設定に対する修正に対応させることを含む、方法。
【請求項１０】
ソフトウェアデプロイメントのためのシステムであって、
１つ又は２つ以上のプロセッサと、
前記プロセッサに接続され、前記プロセッサに命令を提供するように構成されているメモリと、
を備え、
前記１つ又は２つ以上のプロセッサは、
各々がサービスを実施するように構成されている第１のサービス処理エンジン及び第２のサービス処理エンジンを実行し、
前記第１のサービス処理エンジンを動作状態に、前記第２のサービス処理エンジンを待機状態に設定し、
前記サービスのパフォーマンスに影響を及ぼす変更を検出し、
前記検出された変更に少なくとも部分的に基づいて、前記待機状態にある第２のサービス処理エンジンをアップデートするように、
構成されている、システム。
【請求項１１】
請求項１０に記載のシステムであって、
前記１つ又は２つ以上のプロセッサは、更に、
前記アップデートされた第２のサービス処理エンジンを動作状態に、前記第１のサービス処理エンジンを待機状態に設定し、
前記検出された変更に少なくとも部分的に基づいて、前記第１のサービス処理エンジンをアップデートするように、
構成されている、システム。
【請求項１２】
請求項１１に記載のシステムであって、
前記アップデートされた第２のサービス処理エンジンを動作状態に設定することは、前記１つ又は２つ以上のプロセッサが、前記第１のサービス処理エンジンに無効化命令を送信するように構成されていることを含む、システム。
【請求項１３】
請求項１０に記載のシステムであって、
前記第１のサービス処理エンジンは、第１のサービスルールストレージに対応するように構成され、前記第２のサービス処理エンジンは、第２のサービスルールストレージに対応するように構成される、システム。
【請求項１４】
請求項１０に記載のシステムであって、
前記動作状態は、前記１つ又は２つ以上のプロセッサが、１つ又は２つ以上のサービスリクエストを受信するように、及び前記１つ又は２つ以上のリクエストの少なくとも一部分が少なくとも１つのサービスルールを満たすか否かを決定するように構成されることを含む、システム。
【請求項１５】
請求項１０に記載のシステムであって、
前記待機状態は、前記１つ又は２つ以上のプロセッサが、処理設定若しくはサービスルールをアップデートするように、又は前記サービスのパフォーマンスに影響を及ぼす次の変更を検出するように構成されることを含む、システム。
【請求項１６】
請求項１０に記載のシステムであって、
前記変更は、サービスルールの追加若しくは修正、及び／又は前記第１のサービス処理エンジンに関連付けられている処理設定に対する修正を含む、システム。
【請求項１７】
請求項１０に記載のシステムであって、
検出は、定期的に又はリアルタイムで実施される、システム。
【請求項１８】
請求項１６に記載のシステムであって、
前記１つ又は２つ以上のプロセッサがアップデートするように構成されることは、前記１つ又は２つ以上のプロセッサが、対応するサービスルール、又は前記第２のサービス処理エンジンに関連付けられた処理設定を修正し、サービスルールの追加若しくは修正、及び／又は前記第１のサービス処理エンジンの処理設定に対する修正に対応させるように構成されることを含む、システム。
【請求項１９】
ソフトウェアデプロイメントのためのコンピュータプログラム製品であって、コンピュータによって読み取り可能なストレージメディアに実装され、
各々がサービスを実施するように構成されている第１のサービス処理エンジン及び第２のサービス処理エンジンを実行するためのコンピュータ命令と、
前記第１のサービス処理エンジンを動作状態に、前記第２のサービス処理エンジンを待機状態に設定するためのコンピュータ命令と、
前記サービスのパフォーマンスに影響を及ぼす変更を検出するためのコンピュータ命令と、
前記検出された変更に少なくとも部分的に基づいて、前記待機状態にある第２のサービス処理エンジンをアップデートするためのコンピュータ命令と、
を備えるコンピュータプログラム製品。
【発明の詳細な説明】
【技術分野】
【０００１】
［関連出願の相互参照］
本出願は、あらゆる目的のために、参照によって本明細書に組み込まれる、２０１０年２月２６日付けで出願された、発明の名称を「METHOD AND SYSTEM FOR HOT DEPLOYMENT FO SOFTWARE SYSTEM（ソフトウェアシステムのホットデプロイメントのための方法及びシステム）」とする中国特許出願第２０１０１０１１４３６９．７号に基づく優先権を主張する。
【０００２】
本出願は、ソフトウェアデプロイメントに関し、特に、ソフトウェアのホットデプロイメントに関する。
【背景技術】
【０００３】
金融システムや電子商取引システムなどの基幹システムにとっては、システムアベイラビリティが不可欠である。基幹システムは、一般に、中断されない２４時間のサービスを必要とする。システムが利用できないと、財務上の損失が生じる恐れがある。あいにく、このようなシステムは、変動する複雑なサービスルールを有することが多く、頻繁なアップグレードを必要とする。サービスルールが変更された後、システムは、アップグレードのために再起動が必要であり、これは、システムのアベイラビリティを中断させる恐れがある。
【０００４】
アップグレードのためのシステムの再起動に起因する損失を回避するために、ソフトウェアのホットデプロイメントの技術が生み出されてきた。「ホットデプロイメント」は、ソフトウェアを実行しているシステムを再起動させることなくそのソフトウェアの動作中にソフトウェアをアップグレードすることを言う。中国特許出願第２００６１０１２３８８３．０は、外部に対してサービスを提供している間に、アップグレードされるべきサーバのバックアップが取られ、そのアップグレードが終了したときにアップグレード済みウェブサーバへの切り替えを行うことによって、外部（例えばサーバに対してリクエストを出すクライアント）にとってはホットデプロイメントの方法に見えるようにされた、既存のホットデプロイメント方法を提案している。このようなホットデプロイメント方法では、ホットデプロイメントのために、少なくとも２つのサーバが必要とされる。
【０００５】
上記の特許出願文献は、更に、以下のホットデプロイメント方法を論じている。
【０００６】
既存のシステムで一般に採用されているブラウザ／サーバ（Ｂ／Ｓ）アーキテクチャベースのプラットフォームでは、ビュー、コントロール、及びモデルの各層に分割されたＭＶＣ（モデル、ビュー、及びコントロール）のアーキテクチャモデルの形をとるＪａｖａ（登録商標）ベースのウェブサーバが、一般に採用されている。具体的に言うと、以下の通りである。
【０００７】
ビュー層は、ユーザインタラクションインターフェース、すなわちウェブインターフェースを言い、一般に、スタティックテキストファイル又はＪａｖａサーバページ（ＪＳＰ）である。ＪａｖａＥＥ仕様にしたがえば、ウェブアプリケーションは、ビュー層において修正が成されたときに再起動されることなく有効化することができる。
【０００８】
コントロール層は、ユーザからリクエストを受信して、当該ユーザのリクエストを共同で分析するためにモデル層とビュー層とを整合させるように構成される。この部分は、いかなるサービスロジックからも独立しており、ビュー層から対応するモデル層へのリクエストの転送のみを伴うので、コントロール層は、転送ルールではなく転送構成によってのみ変更される。転送構成が変更される場合と、システム全体を再起動させることなく新しい、すなわち修正後の構成だけをリロードすれば十分である。
【０００９】
モデル層は、サービスフロー／状態及びサービスルールを処理するように構成され、サービスロジックモジュールを言う。従来のウェブサーバでは、モデル層は、同じウェブアプリケーションのクラスローダにロードされる。アップデートされるべきロードされたクラスは、ウェブアプリケーションのクラスローダにリロードされなければならない。したがって、モジュールは、追加／アップデート／削除されなければならず、これは、ウェブアプリケーションの再起動を必要とする。出願第２００６１０１２３８８３．０に開示された解決策は、オープンサービスゲートウェイアーキテクチャがＢ／Ｓアーキテクチャの形でサーバの中に配され、Ｂ／Ｓアーキテクチャの形をとるサーバのモデル層がオープンサービスゲートウェイアーキテクチャのそれぞれのサブモジュールの中に配される、ＭＶＣに基づく従来のウェブサーバの使用を提案している。オープンサービスゲートウェイアーキテクチャのそれぞれのサブモジュールは、自身のクラスローダを提供されているので、或る特定のサブモジュールが変更されたときは、そのサブモジュールに特有なクラスローダのみを再起動させれば十分であり、そうして、ウェブアプリケーション全体のクラスローダの再起動が回避される（すなわち、ウェブアプリケーションによるクラスローダのホットデプロイメントが実施される）。
【００１０】
既存のホットデプロイメント方法には、数々の問題が残る。別のサーバとしてサーバ全体のバックアップを取ることを伴う第１のホットデプロイメント方法では、追加のサーバが必要とされる。しかしながら、サーバの追加には、費用がかかる恐れがある。オープンサービスゲートウェイアーキテクチャの導入を伴った第２のホットデプロイメント方法では、オープンサービスゲートウェイアーキテクチャのそれぞれのサブモジュールの中にモデル層が配されなければならず、モデル層が変更されたときは、オープンサービスゲートウェイアーキテクチャのそれぞれのサブモジュールが、ウェブアプリケーションのクラスローダのホットデプロイメントの可能性如何によらず、やはり再起動されなければならない。したがって、この方法は、完全なホットデプロイメントではなくなる。更に、このホットデプロイメントの方法を適用するためには、既存のシステムが大幅に修正されなければならず、これは、安定性の低下及びセキュリティの脆弱化の問題をもたらす恐れがある。
【図面の簡単な説明】
【００１１】
本発明の様々な実施形態が、以下の詳細な説明及び添付の図面で開示される。
【００１２】
【図１】ホットデプロイメントのためのシステムの一実施形態を示す図である。
【００１３】
【図２】ホットデプロイメントのためのプロセスの一実施形態を示すフローチャートである。
【００１４】
【図３】サービス処理エンジンの内部構造の一実施形態を示す図である。
【００１５】
【図４】切り替え処理ユニットの一実施形態を示す図である。
【００１６】
【図５】ホットデプロイメントのプロセスの別の一実施形態を示すフローチャートである。
【００１７】
【図６】ホットデプロイメントのためのシステムの別の一実施形態を示す図である。
【００１８】
【図７】ホットデプロイメント処理ユニットが第１及び第２のサービス処理エンジンとどのようにやり取りしえるかの一実施形態を示す図である。
【発明を実施するための形態】
【００１９】
本発明は、プロセス、装置、システム、合成物、コンピュータによって読み取り可能なストレージメディアに実装されたコンピュータプログラム製品、並びに／又は結合先のメモリに記憶されている命令及び／若しくは結合先のメモリによって提供される命令を実行するように構成されたプロセッサなどのプロセッサを含む、数々の形態で実装することができる。本明細書では、これらの実装形態、又は本発明がとりえるその他のあらゆる形態が、技術と称される。総じて、開示されているプロセスのステップの順序は、本発明の範囲内で可変である。別途明記されない限り、タスクを実施するように構成されているものとして説明されているプロセッサ又はメモリなどのコンポーネントは、所定時にタスクを実施するように一時的に構成される汎用コンポーネントとして、又はタスクを実施するように製造された特殊コンポーネントとして実装されえる。本明細書で使用される「プロセッサ」という用語は、コンピュータプログラム命令などのデータを処理するように構成された１つ又は２つ以上のデバイス、回路、及び／又は処理コアを言う。
【００２０】
本発明の原理を例示している添付の図面とともに、以下で、本発明の１つ又は２つ以上の実施形態の詳細な説明が提供される。本発明は、このような実施形態との絡みで説明されているが、いかなる実施形態にも限定されない。本発明の範囲は、特許請求の範囲によってのみ限定され、本発明は、数々の代替形態、変更形態、及び均等物を内包している。以下の説明では、本発明の完全な理解を可能にするために、数々の具体的詳細が明記されている。これらの詳細は、例示を目的として提供されており、本発明は、これらの詳細の一部又は全部を伴わずとも、特許請求の範囲にしたがって実施されえる。明瞭さを期するために、発明に関係する技術分野で知られている技術要素は、発明が不必要に不明瞭にされないように、詳細な説明を省略されている。
【００２１】
同じシステムにおいて交互に動作可能である少なくとも２つのサービス処理エンジンを使用したホットデプロイメントが開示される。一部の実施形態において、２つのサービス処理エンジンは、サービス処理エンジンの一方が動作状態にあるときはもう一方が待機状態にあるように交互に使用される。２つのサービス処理エンジンは、同じサービス及び機能を実施するように構成され、ゆえに、リクエストされた同じサービスを実施するために交互に使用されえる。動作状態にあるサービス処理エンジンのみが、クライアントユーザのサービスリクエストを受け入れると共に処理することができ、その間、待機状態にあるもう一方のサービス処理エンジンは、その対応するサービスルールストレージユニット及び／又は処理設定を（例えばサービスルール又は処理設定に対して成された検出された変更に応えて）アップデートしえる。システムのサービスルールが（例えば第１若しくは第２のサービスルールストレージユニットにおいて及び／又はシステムのためのサービスルールライブラリにおいて）変更され、システムのアップデートが適切であるときは、待機状態にあるサービス処理エンジンは、新しく追加された又は修正されたサービスルール又は処理設定によってアップデートされる。新しくアップデートされたサービス処理エンジンは、次いで、待機状態から動作状態に切り替わり、これまで動作状態にあったサービス処理エンジンによって（例えばクライアントユーザのサービスリクエストを受け入れ、処理することによって）処理されていたサービスを引き継ぐ。また、これまで動作状態にあったサービス処理エンジンは、無効化され、ソフトウェア及び／又はソフトウェアを実行しているシステムに対する次のアップデートを待つべく待機状態にされる。各種の実施形態において、待機状態にあるサービス処理エンジンは、新しいサービスルールによってアップデートされた後に再起動される。
【００２２】
一部の実施形態において、各サーバには、少なくとも２つのサービス処理エンジンが実装される。したがって、ソフトウェアを実行している（例えば１つのシステムに属している）全てのサーバは、システムを再起動させることなくシステムのアップグレード中に一度にアップデートされえる。それと同時に、システムは、依然、アップデートプロセス中にサービスを提供することができる。各種の実施形態において、ホットデプロイメントは、動的なアップデートを達成するために、また、システムのアベイラビリティを向上させるために、１つのサーバ上で実施することもできる。各種の実施形態において、開示されるようなホットデプロイメントは、アップデートされるべきサーバのバックアップを取る必要なく実現されえる。
【００２３】
図１は、ホットデプロイメントのためのシステムの一実施形態を示す図である。システム１００は、接続されたサーバ１１とデータベース１２とを含む。一部の実施形態において、サーバ１１及びデータベース１２は、ネットワーク（不図示）を通じて互いに通信しあう。ネットワークとしては、高速データネットワーク及び／又は電気通信ネットワークが挙げられる。本明細書で言及される処理エンジン、ユニット、及びモジュールは、１つ又は２つ以上の汎用プロセッサ上で実行されるソフトウェアコンポーネントとして、プログラマブルロジックデバイス及び／若しくは所定の機能を実施するように設計された特殊用途向け集積回路などのハードウェアとして、又はそれらの組み合わせとして実装することができる。一部の実施形態において、処理エンジン、ユニット、及びモジュールは、本発明の実施形態で説明されている方法をコンピュータデバイス（パソコン、サーバ、ネットワーク機器など）に実行させるための幾つかの命令を含み且つ不揮発性のストレージメディア（光ディスク、フラッシュストレージデバイス、モバイルハードディスクなど）に記憶させることができるソフトウェア製品の形で具現化することができる。処理エンジン、ユニット、及びモジュールは、１つのデバイスに実装されえる、又は複数のデバイスに分散されえる。
【００２４】
データベース１２は、サービスルールを記憶するように構成されたサービスルールライブラリ２１を含む。本明細書で使用されるサービスルールは、データが満たしえる条件を言い、その条件が満たされると、ある特定の事象が発生する。例えば、ある特定の回数にわたって製品が購入されると、ログエントリが作成される。１つ又は２つ以上のデータ、及びそれら１つ又は２つ以上のデータによって満たされるべき複数の条件がありえる。サービスルールライブラリ２１は、頻繁にアップデートされえる。一部の実施形態において、サービスルールライブラリ２１は、サービスルールライブラリ２１におけるサービスルールの追加又は修正を希望するオペレータ（例えばユーザ）によってアップデートされえる。
【００２５】
例示されるように、第１のサービスルールストレージユニット２２は、サービスルールライブラリ２１に接続され、１つ又は２つ以上のサービスルールを記憶するように構成される。第２のサービスルールストレージユニット２３は、サービスルールライブラリ２１に接続され、１つ又は２つ以上のサービスルールを記憶するように構成される。各種の実施形態において、第１のサービスルールストレージユニット２２及び第２のサービスルールストレージユニット２３は、１つ又は２つ以上の同じサービスルールを記憶する。
【００２６】
第１のサービスルールストレージユニット２２及び第２のサービスルールストレージユニット２３に記憶されているサービスルールは、全て、サービスルールライブラリ２１にも記憶されている。サービスルールの１つを修正するためには、オペレータは、サービスルールライブラリ２１に記憶されているコンテンツを修正すればよい。各種の実施形態において、第１のサービスルールストレージユニット２２は、第１のサービス処理エンジン３２に対応し、第２のサービスルールストレージユニット２３は、第２のサービス処理エンジン３３に対応する。
【００２７】
サーバ１１は、サービス処理リクエストを（例えばサーバ１１に対してリクエストを出すクライアントユーザから）受信するように構成された入力データ処理ユニット３１を含む。入力データ処理ユニット３１は、様々なインターフェースを通じて伝送されたサービス処理リクエストを受信し、それらを処理して所定のフォーマットのデータパケットにする。入力データ処理ユニット２１は、次いで、データパケットを、第１のサービス処理エンジン３２及び第２のサービス処理エンジン３３のうち現時点で動作しているいずれかに伝送する。すなわち、入力データ処理ユニット３１は、サービス処理リクエストを受信及び解析し、（例えば処理されたリクエストをデータパケットのフォーマットにすることによって）対応するデータを導き出すことを含む、前処理動作を実施する。例えば、サービス処理リクエストは、２つのインターフェースを通じて伝送される。いずれかのインターフェースからサービス処理リクエストが受信されたら、入力データ処理ユニット３１は、サービス処理リクエストが２つのインターフェースのうちのいずれから伝送されたかを決定し、サービス処理リクエストを解析して対応するコンテンツを導き出し、受信されたコンテンツがサービスルールを満たすか否かを決定するためにそれらのコンテンツを現時点で動作状態にあるサービス処理エンジンに伝送する。
【００２８】
動作状態に設定されているときは、第１のサービス処理エンジン３２は、受信されたサービス処理リクエストが対応する第１のサービスルールストレージユニット２２に記憶されているルールを満たすか否かを決定するように構成されている。待機状態に設定されているときは、第１のサービス処理エンジン３２は、システムで実行されているソフトウェアの処理設定に対する変更を検出し、対応する設定をアップデートし、次いで、その状態を動作状態に設定するように構成されている。各種の実施形態において、ソフトウェアの処理設定に対する変更としては、中でも特に、サービスルールの１つに対する変更、及び／又は処理エンジンの１つの処理設定に対する変更が挙げられる。
【００２９】
各種の実施形態において、第１のサービス処理エンジン３２は、サーバ１１への入力に応答し、特定のサービスロジックを処理してサービス処理結果を生成することができる。第１のサービス処理エンジン３２は、また、動作状態にある間、決定結果を加算する又は結果に対してその他の動作を実施することができる。第１のサービス処理エンジン３２は、入力に応答し、特定のサービスロジックを処理してサービス処理結果を生成する。一部の実施形態において、第１のサービス処理エンジン３２は、少なくとも、受信されたサービス処理リクエストが対応する第１のサービスルールストレージユニット２２に記憶されているルールを満たすか否かを決定して決定結果を得ること、当該決定結果に応答して既定のフローでプロセスを実施すること、及びサービス処理結果を返すことによって動作する。すなわち、第１のサービス処理エンジン３２は、様々な動作フローを事前に設定し、特定のサービス処理リクエストに応答してプロセスを実施するとともに対応する動作フローで動作を実施する。
【００３０】
第２のサービス処理エンジン３３は、動作状態にあるときに、受信されたサービス処理リクエストが第２のサービスルールストレージユニット２３に記憶されている第２のルールを満たすか否かを決定するように構成されている。第２のサービス処理エンジン３３は、また、待機状態にある間、システムで実行されているソフトウェアの処理設定に対する変更を検出し、それにしたがって、対応する設定をアップデートし、次いで、その状態を動作状態に設定するように構成されている。すなわち、待機状態にある間、第２のサービス処理エンジン３３は、サービスルール及び／又はシステムで実行されているソフトウェアの処理設定が変更されたか否かを検出し、変更された場合には、第２のサービスルールストレージユニット２３をアップデートし且つ／又は自身の処理設定をアップデートし、次いで、自身を動作状態に設定する。
【００３１】
第１のサービス処理エンジン３２及び第２のサービス処理エンジン３３は、少なくとも、受信されたサービス処理リクエストがそれぞれに記憶されているサービスルールを満たすか否かを決定するプロセスを実施する。各種の実施形態において、第１のサービス処理エンジン３２及び第２のサービス処理エンジン３３が到達する結果は、これら２つのエンジンが交互に（例えば動作状態で）使用されえるように、たとえ厳密に同じではないにしても同様である。
【００３２】
出力データ処理ユニット３４は、サービス処理結果を出力するように構成されている。一部の実施形態では、サービス処理エンジンのうち動作状態にある１つ（例えば第１のサービス処理エンジン３２又は第２のサービス処理エンジン３３のいずれか）が、サービス処理リクエストを処理し、次いで、その結果を出力データ処理ユニット３４に伝送する。したがって、出力データ処理ユニット３４は、処理結果を既定のフォーマットに変換し、次いで、それを、対応するリクエストの発信元又は結果の宛先に返すことができる。
【００３３】
サービスルールライブラリ２１は、記憶されているサービスルールを調整するために修正することができる基準サービスルールライブラリとして機能する。一部の実施形態において、サービスルールライブラリ２１が構成されると、第１のサービスルールストレージユニット２１及び第２のサービスルールストレージユニット２２は、サービスルールライブラリの中と同じコンテンツを記憶する。そうでなく、サービスルールライブラリが構成されない場合には、第１及び第２のサービスルールストレージユニットの各々は、最初に全てのサービスルールを記憶する。一部の実施形態において、第１のサービスルールストレージユニット２２及び第２のサービスルールストレージユニット２３は、定期的に又は条件／事象に応答し、ルールの１つが追加又は変更されたか否かを決定するためにサービスルールライブラリ２１と比較される。一部の実施形態において、第１のサービスルールストレージユニット２２及び第２のサービスルールストレージユニット２３は、サービスルールライブラリ２１において修正が検出されると、それにしたがってアップデートされる。
【００３４】
一部の実施形態において、記憶されているサービスルールは、第１のサービスルールストレージユニット２２及び第２のサービスルールストレージユニット２３のいずれか又は両方において修正されえる。例えば、待機状態にある第１のサービス処理エンジン３２に対応する第１のサービスルールストレージユニット２２は、任意のルールを変更するために直接修正することができる。
【００３５】
一部の実施形態において、第１のサービスルールストレージユニット２２及び／又は第２のサービスルールストレージユニット２３は、別々に（例えばデータベース１２の中に）配される代わりに、対応する第１のサービス処理エンジン３２及び／又は第２のサービス処理エンジン３３に統合され得る。
【００３６】
一部の実施形態において、第１のサービス処理エンジン３２及び第２のサービス処理エンジン３３は、共にルールを記憶するように構成されている第１のサービスルールストレージユニット２２及び第２のサービスルールストレージユニット２３にそれぞれ対応する。第１のサービス処理エンジン３２は、入力に応答し、受信されたサービス処理リクエストが第１のサービスルールストレージユニット２２に記憶されているサービスルールを満たすか否かを決定することを含む特定のサービスロジックを処理する。第１のサービス処理ユニット３２は、また、入力に応答してサービス処理結果を生成する。一部の実施形態において、第１のサービス処理エンジン３２は、第１のサービスルールストレージユニット２２に論理的に接続されている、又は第１のサービスルールストレージユニット２２は、第１のサービス処理エンジン３２の中に（例えば処理エンジンのコンポーネントとして）直接実装されている。第２のサービス処理ユニット３３も、同様に、第２のサービスルールストレージユニット２３に対応する。
【００３７】
更に、第２のサービス処理エンジン３３及び第１のサービス処理エンジン３２のいずれを動作状態とし、いずれを待機状態とするかは、様々な適切なハードウェア又はロジックによって実装されえる。例えば、第１のサービス処理エンジン３２及び第２のサービス処理エンジン３３の各々には、第１のサービス処理エンジン３２に第１の状態コントロールユニットが配置されるとともに第２のサービス処理エンジン３３に第２の状態コントロールユニットが配置されるように状態コントロールユニット（不図示）が配置される。したがって、２つのサービス処理エンジンは、どちらのサービス処理エンジンが動作状態にあるか及びそれゆえにどちらが待機状態にあるかを調整するために、第１の状態コントロールユニットと第２の状態コントロールユニットとの間の通信を通じてコントロールされる。
【００３８】
図２は、ホットデプロイメントのためのプロセスの一実施形態を示すフローチャートである。一部の実施形態において、プロセス２００は、システム１００によって実施されえる。
【００３９】
ステップ２１０では、第１のサービス処理エンジン及び第２のサービス処理エンジンの各々が、サービスを実施するように構成される。各種の実施形態において、第１及び第２のサービス処理エンジンの各々は、他方のサービス処理エンジンと同様な且つ／又は互換性のサービス／機能を実施するように構成される。
【００４０】
各種の実施形態において、第１のサービス処理エンジンは、第１のサービスルールストレージユニットに対応するようにも構成され、第２のサービス処理エンジンは、第２のサービスルールユニットに対応するようにも構成されている。一部の実施形態において、第１のサービスルールストレージユニット及び第２のサービスルールストレージユニットの各々は、サービスルールを記憶するように構成されている。第１のサービス処理エンジンは、入力に応答し、（例えば２つのサービス処理エンジンを実行しているサーバにおいて）受信されたサービス処理リクエストが第１のサービスルールストレージユニットに記憶されているルールを満たすか否かを決定することを含む特定のサービスロジックを処理する。受信されたリクエストが第１のルールストレージユニットに記憶されているルールを満たすか否かに関する決定に基づいて、第１のサービス処理エンジンは、決定結果を生成する。一部の実施形態において、第１のサービス処理エンジンは、ロジックを通じて第１のサービスルールストレージユニットに接続される。一部の実施形態において、第１のサービスルールストレージユニットは、第１のサービス処理エンジンの中に直接構成される（例えば、第１のサービスルールストレージユニットは、第１のサービス処理エンジンのコンポーネントとして構成される）。第２のサービス処理エンジンは、同様に、第２のサービスルールストレージユニットに対応するとともに第２のサービスルールストレージユニットに接続されるように構成されえる。
【００４１】
ステップ２２０では、第１のサービス処理エンジンは、動作状態に設定され、第２のサービス処理エンジンは、待機状態に設定される。各種の実施形態において、第１及び第２のサービス処理エンジンの各々は、対応するサービス処理エンジンが動作状態にある又は待機状態にあるかを記す指標（例えば値を記憶しているデータ構造）を含む（例えば、値がゼロであるときにエンジンは待機状態にある、値が１であるときにエンジンは待機状態にあるなど）。
【００４２】
ステップ２３０では、サービスのパフォーマンスに影響を及ぼす変更が検出される。各種の実施形態において、ソフトウェアに対して成される変更（例えば修正又は追加）は、サービスルールに対する変更又は処理設定に対する変更を含む。サービスルールに対する変更又は処理設定に対する変更は、ホットデプロイメントの不在下では、サービスで実行されているソフトウェアアプリケーションの再起動又はソフトウェアアプリケーションを実行しているシステム全体の再起動を引き起こすと考えられる。しかしながら、ホットデプロイメントは、アプリケーション／システム全体を再起動する必要性を軽減する。一部の実施形態において、変更は、その主要な機能がこのような変更を検出することである第１及び第２のサービス処理エンジンのいずれかのコンポーネント（例えばスキャン処理ユニット）によって検出される。変更は、例えば、サービスルールライブラリ、第１のサービスルールストレージユニット、又は第２のサービスルールストレージユニットの中で検出されえる。
【００４３】
ステップ２４０では、待機状態にある第２の処理エンジンが、検出された変更に少なくとも部分的に基づいてアップデートされる。一部の実施形態において、第２のサービス処理エンジンは、第２のサービスルールストレージユニットに記憶されているサービスルールをアップデートして、第１のサービスルールストレージユニット又はサービスルールライブラリに記憶されている変更されたルールに対応させることによって、アップデートされる。一部の実施形態において、第２のサービス処理エンジンは、その処理設定をアップデートして、対応する変更された処理設定に対応させることによって、アップデートされる。
【００４４】
各種の実施形態において、第２のサービス処理エンジンは、アップデートされた後に動作状態に設定され、その間に、第１のサービス処理エンジンは、待機状態に設定される。一部の実施形態において、動作しているサービス処理エンジンは、待機しているサービス処理エンジンから受信される無効化命令に少なくとも部分的基づいて、待機状態に設定されるように通知される。第１のサービス処理エンジンは、待機状態にあるときに、第２のサービス処理エンジンのアップデートと同様なやり方で（例えば、検出された変更に少なくとも部分的に基づいて）アップデートされえる。一部の実施形態において、第１のサービス処理エンジンは、アップデートが完了された後も、別の変更が検出されるまで待機状態にとどまる。別の変更が検出された時点で、待機しているサービス処理エンジン（例えば第１のサービス処理エンジン）は、アップデートされて動作状態に切り替えられ、これまで動作していたサービス処理エンジン（例えば第２のサービス処理エンジン）は、待機状態に設定される。
【００４５】
図３は、サービス処理エンジンの内部構造の一実施形態を示す図である。一部の実施形態において、第１のサービス処理エンジン３２及び／又は第２のサービス処理エンジン３３は、構造３００を使用して実装されえる。図３に示されるように、ユニット４１、４２、４３、及び４４は、バス若しくは接続ネットワークなどのハードウェアを通じて、且つ／又はソフトウェアロジックに基づいて接続されえる。
【００４６】
構造３００は、以下の要素を含む。
【００４７】
図１に示されるように入力データ処理ユニット３１及び出力データ処理ユニット３４に接続された、サービス処理ユニット４１。サービス処理ユニットは、入力データ処理ユニット３１から受信された入力に応答し、特定のサービスロジックを処理してサービス処理結果を生成し、次いで、その結果を出力データ処理ユニット３４に送信するように構成されている。各種の実施形態において、サービス処理ユニット４１は、サービス処理リクエストに含まれているデータを、そのデータがサービスルールを満たすか否かを判断するために、構造３００によって表されるようなサービス処理エンジンに対応する第１のサービスルールストレージユニット２２及び／又は第２のサービスルールストレージユニット２３のいずれか一方に記憶されているサービスルールと比較する。例えば、サービス処理リクエストは、３つのフィールド、すなわちフィールドＡ、フィールドＢ、及びフィールドＣに記憶されているデータを含む。第１のサービスルールストレージユニット２２及び第２のサービスルールストレージユニット２３は、フィールドＡ、フィールドＢ，及び／又はフィールドＣが満たしえる条件（例えばサービスルール）を記憶している。この例では、入力処理ユニット３１は、（例えば入力処理ユニット３１が受信した）サービス処理リクエストを、現時点で動作状態にある第１のサービス処理エンジン３２及び第２のサービス処理エンジン３３のいずれか一方のサービス処理ユニット４１に送信する。一部の実施形態において、サービス処理ユニット４１は、サービス処理リクエストのフィールドＡ、フィールドＢ、及び／又はフィールドＣに含まれているデータを抽出する。サービス処理ユニット４１は、データを、対応する第１のサービスルールストレージユニット２２及び／又は第２のサービスルールストレージユニット２３に記憶されているサービスルールと比較し、（例えば、サービスルールが満たされているか否かを示す）決定結果を生成し、次いで、それを出力データ処理ユニット３４に伝送する。
【００４８】
スキャン処理ユニット４２は、サービスルールの１つ、及び／又は処理エンジンの１つの処理設定が変更されたか否かを検出するように構成されている。具体的には、スキャン処理ユニット４２は、対応するサービスルールストレージユニット、及び／又は対応するエンジンの処理設定が変更されたか否かを検出する。一部の実施形態において、スキャン処理ユニット４２は、対応するサービスルールストレージに記憶されている対応するサービスルールに対する変更のみを検出する。例えば、スキャン処理ユニット４２が、第１のサービス処理エンジン３２の内部構造の一部である場合には、第１のサービスルールストレージユニット２２は、第１のサービス処理エンジン３２に対応しているので、スキャン処理ユニット４２は、第１のサービスルールストレージユニット２２に記憶されているサービスルールに対する修正のみを検出するだろう。また、スキャン処理ユニット４２が、第２のサービス処理エンジン３３の内部構造の一部である場合には、第２のサービスルールストレージユニット２３は、第２のサービス処理エンジン３３に対応しているので、スキャン処理ユニット４２は、第２のサービスルールストレージユニット２３に記憶されているサービスルールに対する修正のみを検出するだろう。一部の実施形態において、スキャン処理ユニット４２は、サービスルールライブラリ２１に記憶されているコンテンツ及び現時点で動作している処理エンジン（例えば、待機状態にあるサービス処理エンジンではなく、第１又は第２のサービス処理エンジン３２又は３３のうち現時点で動作状態にあるもの）の設定が変更されたか否かも検出することができる。変更が検出されたならば、スキャン処理ユニット４２は、アップデートトリガ信号を切り替え処理ユニット４４に伝送し、すると、切り替え処理ユニット４４は、アップデート処理ユニット４３へのアップデートトリガ信号の伝送をコントロールする。あるいは、変更が検出されると、スキャン処理ユニット４２は、アップデートトリガ信号をアップデート処理ユニット４３に伝送し、すると、アップデート処理ユニット４３は、アップデート動作を実施した後に、アップデートトリガ信号を切り替え処理ユニット４４に伝送する。
【００４９】
アップデート処理ユニット４３は、サービスルールライブラリ２１との整合を図るために第１のサービスルールストレージユニット２１／第２のサービスルールストレージユニット２２に記憶されているルールをアップデートするように、及び現時点で動作状態にある処理エンジンをアップデートするように構成されている。アップデート処理ユニット４３のアップデート動作は、対応するサービスルールストレージユニットに記憶されているサービスルールのみをアップデートして、サービスルールライブラリ２１に記憶されているサービスルールと整合させること、を含むことができる。アップデート処理ユニット４３は、更に、対応する処理エンジン（例えばアップデート処理ユニット４３が一部をなしている第１又は第２のサービス処理エンジンのいずれか）を再起動させる動作を実施して、修正された処理エンジンを有効化する（例えば動作状態にする）ことができる。
【００５０】
一部の実施形態において、アップデート処理ユニット４３のトリガは、代替的にスキャン処理ユニット４２から開始させることができる。例えば、アップデート処理ユニット４３は、スキャン処理ユニット４２から伝送されたトリガ信号が受信されたらアップデート動作を実施し、アップデート動作を実施した後、アップデート完了信号を切り替え処理ユニット４４に伝送することができる。一部の実施形態において、アップデート処理ユニット４３のトリガは、切り替え処理ユニット４４から開始させることができる。例えば、アップデート処理ユニット４３は、切り替え処理ユニット４４から伝送されたトリガ信号が受信されたらアップデート動作を実施し、アップデート動作を実施した後、アップデート完了信号を切り替え処理ユニット４４に伝送することができる。
【００５１】
一部の実施形態において、サービス処理ユニット４１及びスキャン処理ユニット４２は、同時に動作可能ではない。スキャン処理ユニット４２は、対応する処理エンジンが待機状態にあるときのみ動作可能であり、サービス処理ユニット４１は、対応する処理エンジンが動作状態になるまで待ってから動作する。一部の実施形態において、切り替え処理ユニット４４は、スキャン処理ユニット４２及びサービス処理ユニット４１のいずれが動作しているかを（例えば、サービス処理エンジンが現時点で動作状態又は待機状態のいずれにあるかに基づいて）決定する。
【００５２】
以下は、スキャン処理ユニット４２、切り替え処理ユニット４４、及びアップデート処理ユニット４３がどのようにして互いに通信し合うかの一例である。
【００５３】
１）スキャン処理ユニット４２が動作しているとき（例えばサービス処理エンジンが待機状態にあるとき）に、サービスルールライブラリ２１の中のサービスルールの１つが修正されたことが検出されると、トリガ信号は、アップデート処理ユニット４３に伝送され得る。
【００５４】
２）アップデート処理ユニット４３は、対応するサービスルールストレージユニットの中のサービスルールをアップデートして、サービスルールライブラリ２１の中の修正されたサービスルールと整合させ、アップデート完了信号を切り替え処理ユニット４４に伝送する。
【００５５】
３）アップデート完了信号を受信すると、切り替え処理ユニット４４は、もう一方のサービス処理エンジンに、（例えば、そのもう一方のサービス処理エンジンを待機状態にする）無効化命令を伝送し、次いで、現サービス処理エンジンを動作状態に設定する。切り替え処理ユニットは、更に、動作無効化命令をスキャン処理ユニット４２に伝送し、（例えば、現サービス処理エンジンが動作状態に設定されえるように、）サービス処理ユニット４１を動作させる。
【００５６】
現サービスエンジンが動作しているときに、もう一方のサービス処理エンジンから伝送された無効化命令を受信すると、切り替え処理ユニット４４は、現サービス処理エンジンを待機状態に設定し、動作停止信号をサービス処理ユニット４１に伝送して、スキャン処理ユニット４２を動作させる。更に、アップデート処理ユニット４３が、アップデート動作を実施することができる。
【００５７】
以下は、スキャン処理ユニット４２、切り替え処理ユニット４４、及びアップデート処理ユニット４３がどのようにして互いに通信し合うかの第２の例である。
【００５８】
１）スキャン処理ユニット４２が動作状態にあるときに、サービスルールライブラリ２１の中のサービスルールの１つが修正されたことが検出されると、トリガ信号は、切り替え処理ユニット４４に伝送され得る。
【００５９】
２）トリガ信号を受信すると、切り替え処理ユニット４４は、そのトリガ信号をアップデート処理ユニット４３に伝送し、アップデート処理ユニット４３は、すると、アップデート動作を実施し、アップデート完了信号を切り替え処理ユニット４４に伝送する。
【００６０】
３）アップデート完了信号を受信すると、切り替え処理ユニット４４は、もう一方のサービス処理エンジンに無効化命令を伝送し、次いで、現サービス処理エンジンを動作状態に設定し、動作停止信号をスキャン処理ユニット４２に伝送し、サービス処理ユニット４１を動作させる。
【００６１】
動作状態にある現サービスエンジンにおいて、もう一方のサービス処理エンジンから伝送された無効化命令が受信されたら、切り替え処理ユニット４４は、現サービス処理エンジンを待機状態に設定し、動作停止信号をサービス処理ユニット４１に伝送し、スキャン処理ユニット４２を動作させる。更に、アップデート処理ユニット４３が、アップデート動作を実施することができる。
【００６２】
図４は、切り替え処理ユニットの一実施形態の図である。一部の実施形態において、図４は、切り替え処理ユニット４４の一例である。
【００６３】
状態サブユニット４４１は、対応するサービス処理エンジンが現時点で動作状態又は待機状態のいずれにあるかを記憶するように構成されている。
【００６４】
アップデートトリガサブユニット４４２は、現サービス処理エンジンが待機状態にあるときに、スキャン処理ユニット４２から信号を受信すると、アップデート処理ユニット４３にトリガ信号を伝送し、アップデート処理ユニット４３のアップデート動作をアクティブにするように構成されている。
【００６５】
アクティブ化サブユニット４４３は、無効化命令をもう一方のサービス処理エンジンに伝送し、次いで、現サービス処理エンジンの状態サブユニット４４１を動作状態に設定するように構成されている。アクティブ化サブユニット４４３は、また、アップデート処理ユニット４３から伝送された無効化命令を受信すると、動作停止信号をスキャン処理ユニット４２に伝送するように構成されている。
【００６６】
無効化処理サブユニット４４４は、もう一方のサービス処理エンジンから伝送された無効化命令を受信すると、現サービス処理エンジンを待機状態に設定し、動作停止信号をサービス処理ユニット４１に伝送し、スキャン処理ユニット４２を動作させるように構成されている。
【００６７】
無効化アップデートサブユニット４４５は、無効化処理サブユニット４４４に接続されており、無効化処理サブユニット４４４から伝送されたトリガ信号を受信すると、そのトリガ信号をアップデート処理ユニット４３に伝送するように構成されている。
【００６８】
一部の実施形態において、スキャン処理ユニット４２が、アップデート処理ユニット４３にアップデート動作を実施するように直接命令するときは、アップデートトリガサブユニット４４２は、省略することができる。
【００６９】
図５は、ホットデプロイメントのプロセスの別の一実施形態を示すフローチャートである。プロセス５００は、システム１００などのシステムにおいて実施されえる。
【００７０】
ステップ５１０では、第１のサービス処理エンジン及び第２のサービス処理エンジンが、第１のサービスルールストレージユニット及び第２のサービスルールストレージユニットにそれぞれ対応するように構成されている。
【００７１】
ステップ５２０では、第１のサービス処理エンジン及び第２のサービス処理エンジンの一方が待機状態に設定され、もう一方が動作状態に設定される。言い換えると、一度に動作しているのは、第１及び第２のサービス処理エンジンのうちの一方のみであり、もう一方のエンジンは、その間は待機状態にある。一部の実施形態において、待機状態にあるエンジンは、動作状態に入るための通知を受信するまで待機状態にとどまる。
【００７２】
動作状態に設定されているサービス処理エンジンは、入力に応答し、特定のサービスロジックを処理してサービス処理結果を生成する。このステップは、現時点で動作しているサービス処理エンジンが、受信されたサービス処理リクエストが対応するサービスルールストレージユニットに記憶されているルールを満たすか否かを検出し、（例えばサービスルールが満たされているか否かを示す）結果を出力することを含む。
【００７３】
待機状態に設定されているもう一方のサービス処理エンジンは、サービスルール、及び／又は現サービス処理エンジンの処理設定が（例えばユーザによって）変更されたか否かを（例えばリアルタイムで又は定期的に）検出する。
【００７４】
サービスルールライブラリが構成されているとすると、サービスルールに対する変更は、サービスルールストレージユニットの中のルールがサービスルールライブラリに記憶されている同じルールのヴァージョンと整合しないことを示す。
【００７５】
サービスルールライブラリが構成されていないとすると、更なるステップは、サービスルールストレージユニットの中のルールが例えば修正された、削除されたなどのように変更されたときに開始させることができる。
【００７６】
ステップ５３０では、待機状態に設定されているサービス処理エンジンは、システムの設定に対してなされた変更が検出されると、対応する記憶されているシステムの設定をアップデートする。
【００７７】
一部の実施形態において、ソフトウェアシステムの設定に対する変更としては、サービスルールの１つに対する変更、及び／又は待機しているサービス処理エンジンの処理設定に対する変更が挙げられる。
【００７８】
ステップ５４０では、待機状態に設定されているサービス処理エンジンは、もう一方のサービス処理エンジンに無効化命令を伝送し、現サービス処理エンジンを動作状態にする。動作状態にあることは、入力に応答し、特定のサービスロジックが処理されてサービス処理結果が生成されることを伴う。これは、動作しているサービス処理エンジンが、受信されたサービス処理リクエストが対応するサービスルールストレージユニットに記憶されているルールを満たすか否かを決定して結果を出力することを含む。
【００７９】
ステップ５５０では、もう一方のサービス処理エンジン（例えば、ステップ５４０で無効化命令を受信した、動作状態にあるサービス処理エンジン）は、受信したサービス処理リクエストが対応する第１のサービスルールストレージユニットに記憶されているルールを満たすか否かを決定する動作を停止させ、現サービス処理エンジンを待機状態に設定し、更に、ソフトウェアシステムにおいてアップデート動作を実施する。待機状態に設定されているもう一方のサービス処理エンジンは、サービスルール、及び／又は現サービス処理エンジンの処理設定が変更されたか否かを（例えばリアルタイムで又は定期的に）検出しえる。
【００８０】
図６は、ホットデプロイメントのためのシステムの別の一実施形態を示す図である。システム１００とシステム６００との少なくとも１つの相違は、２つのサービス処理エンジンのどちらが現時点で動作状態にあるかをホットデプロイメント処理ユニット５５がコントロールすることである。
【００８１】
システム１００と同様に、システム６００は、データベース１１とサーバ１２とを含む。システム１００と同様に、サーバ１１は、更に、入力データ処理ユニット５１と、第１のサービス処理エンジン５２と、第２のサービス処理エンジン５３と、出力データ処理ユニット５４とを含む。システム１００と異なり、システム６００の中のサーバ１１は、ホットデプロイメント処理ユニット５５を含む。ホットデプロイメント処理ユニット５５は、第１のサービス処理エンジン５２及び第２のサービス処理エンジン５３の両方に接続されており、一方のサービス処理エンジンによってもう一方のサービス処理エンジンに伝送された無効化命令に少なくとも部分的に基づいて、第１のサービス処理エンジン５２及び第２のサービス処理エンジン５３の状態を修正するように構成されている。図６に示された例では、ホットデプロイメント処理ユニット５５は、第１のサービス処理エンジン５２及び第２のサービス処理エンジン５３のどちらが動作状態にあるか（及びどちらが待機状態にあるか）をコントロールする。
【００８２】
システム１００と同様に、一部の実施形態において、第１のサービス処理エンジン５２及び第２のサービス処理エンジン５３は、各々、サービス処理ユニットと、切り替え処理ユニットと、アップデート処理ユニットと、スキャン処理ユニットとを含むことができる。一部の実施形態において、第１のサービス処理エンジン５２及び第２のサービス処理エンジン５３は、サービス処理ユニット、スキャン処理ユニット、及びアップデート処理ユニットのみを含むことができ、切り替え処理ユニットの機能は、ホットデプロイメント処理ユニット５５に統合することができる。
【００８３】
一部の実施形態において、第１のサービス処理エンジン５２及び第２のサービス処理エンジン５３の各々が、システム１００と同様に、サービス処理ユニット、切り替え処理ユニット、アップデート処理ユニット、及びスキャン処理ユニットを含むときに、第１のサービス処理エンジン５２及び第２のサービス処理エンジン５３は、更に、以下の要素を含むことができる。
【００８４】
入力データ処理ユニット５１及び出力データ処理ユニット５４に接続されているサービス処理ユニット。サービス処理ユニットは、入力データ処理ユニット５１から受信したサービス処理リクエストが現サービスルールストレージユニットに記憶されているルールを満たすか否かを決定するように、また、結果を出力データ処理ユニット５４に出力するように構成されえる。
【００８５】
サービスルールの１つ、及び／又は処理エンジンの１つの処理設定が変更されたか否かを検出するように構成されているスキャン処理ユニット。
【００８６】
スキャン処理ユニットが、サービスルールの１つ、及び／又は処理エンジンの１つの処理設定に対する変更を検出すると、第１のサービスルールストレージユニット２２及び／又は第２のサービスルールストレージユニット２３をアップデートして、現処理エンジンをアップデートするように構成されているアップデート処理ユニット。
【００８７】
ホットデプロイメント処理ユニット５５からの命令を受信すると、サービス処理ユニット６１（不図示）又はサービス処理ユニット６２（不図示）を動作させるように構成されている切り替え処理ユニット。
【００８８】
一部の実施形態において、第１のサービス処理エンジン５２及び第２のサービス処理エンジン５３は、各々、サービス処理ユニット、スキャン処理ユニット、及びアップデート処理ユニットのみを含むことができる。ホットデプロイメント処理ユニット５５は、それぞれの処理エンジンの両方のサービス処理ユニット、スキャン処理ユニット、及びアップデート処理ユニットに接続されている。したがって、ホットデプロイメント処理ユニット５５は、それぞれのユニットをコントロールして動作させる。
【００８９】
図７は、ホットデプロイメント処理ユニットが第１及び第２のサービス処理エンジンとどのようにやり取りしえるかの一実施形態を示す図である。この例に示されるように、第１のサービス処理エンジン５２は、第１のサービス処理ユニット５２１と、第１のスキャン処理ユニット５２２と、第１のアップデートユニット５２３とを含み、第２のサービス処理エンジン５３は、第２のサービス処理ユニット５３１と、第２のスキャン処理ユニット５３２と、第２のアップデートユニット５３３とを含む。また、この例では、第１のサービス処理エンジン５２は、動作状態にあり、第２のサービス処理エンジン５３は、待機状態にある。ホットデプロイメント処理ユニット５５は、第２のスキャン処理ユニット５３１からトリガ信号を受信すると、第２のアップデートユニット５３３にアップデート動作を実施するように指示する。ホットデプロイメント処理ユニット５５は、第２のアップデートユニット５３３からアップデート完了信号を受信すると、第１のサービス処理ユニット５２１及び第２のスキャン処理ユニットに動作停止信号を伝送し、第１のスキャン処理ユニット５２２及び第１のサービス処理ユニットを動作状態にする。
【００９０】
一部の実施形態において、ホットデプロイメントシステムのホットデプロイメント処理ユニットは、以下のステップで、第１のサービス処理エンジン及び第２のサービス処理エンジンにおいてホットデプロイメントを実施することができる。
【００９１】
１）ホットデプロイメント処理ユニットが構成される。
【００９２】
２）第１のサービス処理エンジン及び／又は第２のサービス処理エンジンは、サービスルール、又は処理エンジンの処理設定に対する変更を検出すると、現時点で動作している処理エンジンに対応するサービスルールストレージユニットを直接アップデートし、リクエストをホットデプロイメント処理ユニットに伝送する。一部の実施形態において、リクエストは、変更が検出されたこと及び／又はどのサービスルール若しくは処理設定が変更されたかを示す。
【００９３】
３）一部の実施形態において、リクエストを伝送したサービス処理エンジンが現時点で動作状態にあるならば、そのサービス処理エンジンは、その対応する設定がアップデートされえるように待機状態に設定される必要があると考えられる。また、これまで待機状態にあったもう一方のサービス処理エンジンは、動作状態に設定される必要があると考えられる。一部の実施形態において、リクエストを伝送したサービス処理エンジンが現時点で待機状態にあるならば、そのサービス処理エンジンは、先ずアップデートすることができ、次いで、現時点で動作状態にあるもう一方のサービス処理エンジンも、やはりアップデートされえるように待機状態に切り替えることができる。例えば、ホットデプロイメント処理ユニットは、リクエストを伝送した第１のサービス処理エンジン又は第２のサービス処理エンジンのいずれか一方をアップデートし、次いで、それを動作状態に設定し、また、もう一方のサービス処理エンジンを、それに無効化命令を伝送することによって待機状態にする。無効化命令を受信すると、もう一方のサービス処理エンジンは、現サービス処理エンジンを待機状態に設定し、次いで、そのサービスルールストレージユニットの中のルール、又は対応するサービス処理エンジンのソフトウェア設定をアップデートする。
【００９４】
アプリケーションシナリオの一例
【００９５】
以下の例は、ネットワークを通じた信用認証のためのホットデプロイメントのシステムに関する。入力データ処理ユニットは、信用認証リクエストを受信する。第１のサービス処理エンジン及び第２のサービス処理エンジンのうち動作状態にあるいずれか一方が、受信された信用認証リクエストに応答して認証を実施する。サービスルールライブラリの中のルールの１つ（例えば個人信用ルール）が変更されると、両方のサービス処理エンジンが動作を停止される（例えば、システム上で実行されているアプリケーション全体が中断される）ことなくそれぞれのサービス処理エンジンのルールを最終的にアップデートすることができる。以上の開示は、本発明の幾つかの実施形態を単に例示したものであり、本発明は、それらに限定されず、本発明の特許請求の範囲には、当業者ならば想到しえるあらゆる変形例が含まれる。
【００９６】
以上の実施形態は、理解を明瞭にする目的で幾らか詳細に説明されてきたが、本発明は、提供された詳細に限定されない。本発明の実現には、多くの代替的手法がある。開示された実施形態は、例示のためであって、限定的なものではない。
【図１】
2013520748.tif 000003
【図２】
2013520748.tif 000004
【図３】
2013520748.tif 000005
【図４】
2013520748.tif 000006
【図５】
2013520748.tif 000007
【図６】
2013520748.tif 000008
【図７】
2013520748.tif 000009
【国際調査報告】
2013520748.tif 000010