(57)【要約】本発明は、アプリケーション・コンポーネントからバックエンド・システム上のメッセージを解決するためのシステムおよびプロセスに関する。システムは、アプリケーション・コンポーネントがメッセージ・ハンドラと交信する際に使用するタグ付きフィールド形式を使用する標準化されたメッセージ定義を含む。メッセージ・ハンドラは、メッセージの内容に基づいて実施すべき処置および情報の受信者を定義するルールを適用する。これらのルールは、一般にコンポーネントに適用される共通のルールに基づき、またはサービス加入のレベルまたはその他の特徴などのサービス・プロバイダと関連するサービス・ルールに基づき、または前記の基準のいずれかまたはすべての組み合わせに基づき、メッセージを生成するアプリケーション・コンポーネントに関連する顧客側で事前に定義することができる。パブリッシュされているメッセージ形式を利用することにより、本発明では、アプリケーション・ホスティング・バックエンド・システムを顧客アプリケーションに公開するためのプラットフォーム独立のフレームワークを実現する。【特許請求の範囲】
【請求項１】
アプリケーション・コンポーネントによりネットワーク経由で送信されるメッセージに対する応答を開始するネットワーク・ベースの自動メッセージ処理システムであって、
少なくとも１つの顧客定義メッセージ処理ルールと、
メッセージ・ハンドラを備え、前記メッセージ・ハンドラはメッセージ・レシーバ、メッセージ・リゾルバ、ルール・アプライヤ、およびメッセージ・ジェネレータを備え、前記メッセージ・レシーバはアプリケーション・コンポーネントからメッセージを受信し、前記リゾルバは前記少なくとも１つの顧客定義メッセージ処理ルールの適用がメッセージの内容により示されているかどうかを判別し、前記ルール・アプライヤは前記少なくとも１つの顧客定義ルールを受信メッセージの内容に適用すべきかどうかを判別し、前記メッセージ・ジェネレータは前記顧客定義メッセージ処理ルールの適用がメッセージの内容により示されている場合前記少なくとも１つの顧客定義メッセージ処理ルールにより識別される受信者への新しいメッセージを生成するネットワーク・ベースの自動メッセージ処理システム。
【請求項２】
前記少なくとも１つの顧客定義メッセージ処理ルールは、ソフトウェア・フォルトがメッセージの内容により示された場合にサード・パーティのソフトウェア開発者の通知を指示する請求項１に記載のネットワーク・ベースの自動メッセージ処理システム。
【請求項３】
さらに、顧客インターフェイス・ポータルを備え、前記ポータルは顧客が顧客定義ルールを表明するためのインターフェイスを備える請求項１に記載のネットワーク・ベースの自動メッセージ処理システム。
【請求項４】
顧客が顧客定義ルールを定義するための前記ポータル・インターフェイスを使用して顧客が、メッセージの内容が自動的に少なくとも１つの目的の受信者に転送されるメッセージを識別するルールを表明することができる請求項３に記載のネットワーク・ベースの自動メッセージ処理システム。
【請求項５】
前記ポータル・インターフェイスを使用して顧客が、使用可能な配送方法のリストから前記少なくとも１人の目的の受信者にメッセージを自動的に転送するための配送方法を識別することができ、使用可能な配送方法のうちの少なくとも１つがページャ通知方法である請求項４に記載のネットワーク・ベースの自動メッセージ処理システム。
【請求項６】
前記ポータル・インターフェイスを使用して顧客が、使用可能な配送方法のリストから前記少なくとも１人の目的の受信者にメッセージを自動的に転送するための配送方法を識別することができ、使用可能な配送方法のうちの少なくとも１つが電子メール通知である請求項４に記載のネットワーク・ベースの自動メッセージ処理システム。
【請求項７】
前記ポータル・インターフェイスを使用して顧客が、使用可能な配送方法のリストから前記少なくとも１人の目的の受信者にメッセージを自動的に転送するための配送方法を識別することができ、使用可能な配送方法のうちの少なくとも１つがインターネット・アドレスに書き込まれるメッセージである請求項４に記載のネットワーク・ベースの自動メッセージ処理システム。
【請求項８】
前記ポータル・インターフェイスを使用して顧客が、少なくとも１人の受信者に要求することなく表明することができる請求項４に記載のネットワーク・ベースの自動メッセージ処理システム。
【請求項９】
前記アプリケーション・ホスティング・システムはさらに連絡先リスト・ツールを備え、前記連絡先リスト・ツールはホスト対象アプリケーションに関連するエンティティを識別し、前記ポータル・インターフェイスはさらに、連絡先リスト・ツールを参照してホスト対象アプリケーションに関連するエンティティを識別し、ホスト対象アプリケーションに関連するエンティティを自動転送メッセージの潜在的受信者としての顧客に提示する請求項４に記載のネットワーク・ベースの自動メッセージ処理システム。
【請求項１０】
前記システムはさらに、少なくとも１つのサービス・ベース・ルールを含み、前記ルール・アプライヤはさらに、前記少なくとも１つのサービス・ベース・ルールの適用がメッセージの内容により指示されているかどうかを判別し、前記メッセージ・ジェネレータは前記サービス・ベース・ルールがメッセージの内容により示されている場合に前記少なくとも１つのサービス・ベース・ルールにより識別された受信者への新しいメッセージを生成する請求項１に記載のネットワーク・ベースの自動メッセージ処理システム。
【請求項１１】
前記システムはさらに、少なくとも１つの共通ルールを含み、前記ルール・アプライヤはさらに、前記少なくとも１つの共通ルールの適用が受信したメッセージの内容により指示されているかどうかを判別し、前記メッセージ・ジェネレータは前記共通ルールが受信したメッセージの内容により示されている場合に前記少なくとも１つの共通ルールにより識別された受信者への新しいメッセージを生成する請求項１に記載のネットワーク・ベースの自動メッセージ処理システム。
【請求項１２】
前記システムはさらに、少なくとも１つのサービス・ベース・ルールおよび少なくとも１つの共通ルールを含み、前記ルール・アプライヤはさらに、前記少なくとも１つのサービス・ベース・ルールまたは前記少なくとも１つの共通ルールの適用が受信したメッセージの内容により指示されているかどうかを判別し、前記メッセージ・ジェネレータは前記少なくとも１つのサービス・ベース・ルールまたは前記少なくとも１つの共通ルールが受信したメッセージの内容により示されている場合に前記少なくとも１つのサービス・ベース・ルールまたは前記少なくとも１つの共通ルールにより識別された受信者への新しいメッセージを生成する請求項１に記載のネットワーク・ベースの自動メッセージ処理システム。
【請求項１３】
アプリケーション・コンポーネント情報の自動配布のプロセスであって、
少なくとも１つの顧客定義メッセージ処理ルールを顧客から受信するステップと、
アプリケーション・コンポーネントから情報メッセージを受信するステップと、
情報メッセージのコンポーネントを解釈して顧客定義メッセージ処理ルールの適用が情報メッセージの内容に基づいて示されているかどうかを判別するステップと、
少なくとも１つの顧客定義メッセージ処理ルールの適用が情報メッセージの内容により示されている場合に少なくとも１つの顧客定義メッセージ処理ルールを情報メッセージに適用するステップと、
少なくとも１つの顧客定義メッセージ処理ルールを受信したメッセージに適用した結果、受信した情報メッセージのコンポーネントがさらに処置を必要とすると判断した場合に少なくとも１つの顧客定義メッセージ処理ルールに従って前記他の処置を開始するステップと、
前記少なくとも１つの顧客定義メッセージ処理ルールの適用が情報メッセージの内容により示されている場合に少なくとも１つの顧客定義メッセージ処理ルールに従って少なくとも１つの他のメッセージを生成するステップと、
前記少なくとも１つの顧客定義メッセージ処理ルールの適用が情報メッセージの内容により示されている場合に少なくとも１つの顧客定義メッセージ処理ルールにより識別された受信者に前記少なくとも１つの他のメッセージを送信するステップを含むプロセス。
【請求項１４】
前記少なくとも１つの他のメッセージを送信するステップが前記少なくとも１つの他のメッセージをページャ・システムを介して送信することを含む請求項１３に記載のアプリケーション・コンポーネント情報の自動配布のプロセス。
【請求項１５】
前記少なくとも１つの他のメッセージを送信するステップが前記少なくとも１つの他のメッセージをインターネット書き込みオペレーションを介して送信することを含む請求項１３に記載のアプリケーション・コンポーネント情報の自動配布のプロセス。
【請求項１６】
少なくとも１つの顧客定義メッセージ処理ルールは、ソフトウェア・フォルトが情報メッセージの内容により示された場合にサード・パーティのソフトウェア開発者の通知を指示する請求項１３に記載のアプリケーション・コンポーネント情報の自動配布のプロセス。
【請求項１７】
少なくとも１つの顧客定義メッセージ処理ルールを顧客から受信するステップがメッセージの自動転送を行うための使用可能な配送方法のリストを顧客に提示するステップおよび顧客から目的の受信者にメッセージを送信するための目的の配送方法を決定するステップを含み、少なくとも１つの配送方法はページャへの送信を含む請求項１３に記載のアプリケーション・コンポーネント情報の自動配布のプロセス。
【請求項１８】
少なくとも１つの顧客定義メッセージ処理ルールを顧客から受信するステップがメッセージの自動転送を行うための使用可能な配送方法のリストを顧客に提示するステップおよび顧客から目的の受信者にメッセージを送信するための目的の配送方法を決定するステップを含み、少なくとも１つの配送方法は電子メール送信を含む請求項１３に記載のアプリケーション・コンポーネント情報の自動配布のプロセス。
【請求項１９】
少なくとも１つの顧客定義メッセージ処理ルールを顧客から受信するステップがメッセージの自動転送を行うための使用可能な配送方法のリストを顧客に提示するステップおよび顧客から目的の受信者にメッセージを送信するための目的の配送方法を決定するステップを含み、少なくとも１つの配送方法はインターネット書き込みオペレーションを介した送信を含む請求項１３に記載のアプリケーション・コンポーネント情報の自動配布のプロセス。
【請求項２０】
少なくとも１つの顧客定義メッセージ処理ルールを顧客から受信するステップは、少なくとも１つの顧客定義メッセージ処理ルールが連絡先リスト・ツールを参照することで適用可能なホスト対象アプリケーションに関連するエンティティのリストを決定するステップおよび転送メッセージの目的の受信者を顧客が判別するのを補助するため少なくとも１つの顧客定義メッセージ処理ルールが顧客に適用可能なホスト対象アプリケーションに関連するエンティティのリストを表示するステップを含む請求項１３に記載のアプリケーション・コンポーネント情報の自動配布のプロセス。
【請求項２１】
さらに、
少なくとも１つのサービス・ベース・ルールを決定するステップと、
情報メッセージのコンポーネントを解釈して少なくとも１つのサービス・ベース・ルールの適用が情報メッセージの内容によって示されているかどうかを判別するステップと、
少なくとも１つのサービス・ベース・ルールの適用が情報メッセージの内容により示されている場合に少なくとも１つのサービス・ベース・ルールを情報メッセージに適用するステップと、
前記少なくとも１つのサービス・ベース・ルールの適用が情報メッセージの内容により示されている場合に少なくとも１つのサービス・ベース・ルールに従って少なくとも１つの他のメッセージを生成するステップと、
前記少なくとも１つのサービス・ベース・ルールの適用が情報メッセージの内容により示されている場合に少なくとも１つのサービス・ベース・ルールにより識別されている受信者に前記少なくとも１つの他のメッセージを送信するステップを含む請求項１３に記載のアプリケーション・コンポーネント情報の自動配布のプロセス。
【請求項２２】
さらに、
少なくとも１つの共通ルールを決定するステップと、
情報メッセージのコンポーネントを解釈して少なくとも１つの共通ルールの適用が情報メッセージの内容によって示されているかどうかを判別するステップと、
少なくとも１つの共通ルールの適用が情報メッセージの内容により示されている場合に少なくとも１つの共通ルールを情報メッセージに適用するステップと、
前記少なくとも１つの共通ルールの適用が情報メッセージの内容により示されている場合に少なくとも１つの共通ルールに従って少なくとも１つの他のメッセージを生成するステップと、
前記少なくとも１つの共通ルールの適用が情報メッセージの内容により示されている場合に少なくとも１つの共通ルールにより識別されている受信者に前記少なくとも１つの他のメッセージを生成するステップを含む請求項１３に記載のアプリケーション・コンポーネント情報の自動配布のプロセス。
【請求項２３】
コンピュータによって実行されたときに、ホスト対象アプリケーション・システム内に自動メッセージ処理のプロセスを実装する命令を具体的に実現するコンピュータ可読媒体であって、命令が実行されると、メッセージ・ハンドラは、
少なくとも１つの顧客定義メッセージ処理ルールを顧客から決定し、前記少なくとも１つの顧客定義メッセージ処理ルールでメッセージ・ハンドラにより処置を実行する際の状況を識別し、処置を実行する際の状況がメッセージ・ハンドラにより受信したメッセージで伝達されたときにメッセージ・ハンドラによって処置を実行し、
コンピュータ・ネットワーク経由で、前記少なくとも１つの顧客定義メッセージ処理ルールをメッセージ・ハンドラから使用できるようにするコンピュータ可読媒体。
【請求項２４】
前記少なくとも１つの顧客定義処理ルールはさらに、少なくとも１つの他の受信者に受信したメッセージを転送する処置を含む請求項２３に記載の命令を具体的に実現するコンピュータ可読媒体。
【請求項２５】
受信したメッセージを転送する前記処置はさらに、少なくとも１つの他の受信者に前記メッセージを転送する送信方法を定義する請求項２４に記載の命令を具体的に実現するコンピュータ可読媒体。
【請求項２６】
前記送信方法では前記メッセージがページャ・システムを介して前記少なくとも１つの他の受信者に転送される請求項２５に記載の命令を具体的に実現するコンピュータ可読媒体。
【請求項２７】
前記送信方法では前記メッセージが電子メールを介して前記少なくとも１つの他の受信者に転送される請求項２５に記載の命令を具体的に実現するコンピュータ可読媒体。
【請求項２８】
前記送信方法では前記メッセージがインターネットへの書き込みを介して前記少なくとも１つの他の受信者に転送される請求項２５に記載の命令を具体的に実現するコンピュータ可読媒体。
【請求項２９】
メッセージ・ハンドラによって処置が実行される前記状況に、ソフトウェア・フォルトを識別するメッセージを受信することが含まれる請求項２３に記載の命令を具体的に実現するコンピュータ可読媒体。
【請求項３０】
前記状況がソフトウェア・フォルトを識別するメッセージを受信することを含む場合にメッセージ・ハンドラによって実行される処置で、ソフトウェア・フォルト・メッセージの自動転送先の少なくとも１人の他の受信者の識別も行う請求項２９に記載の命令を具体的に実現するコンピュータ可読媒体。
【請求項３１】
顧客から少なくとも１つの顧客定義メッセージ処理ルールを決定するステップはさらに、連絡先リスト管理ツールに格納されているデータを参照することにより自動的に転送されるソフトウェア・フォルト・メッセージの転送先である潜在的受信者のリストを決定し、顧客向けに決定されたリストを表示し顧客がソフトウェア・フォルト・メッセージの自動転送先の受信者を識別するのを補助することを含む請求項３０に記載の命令を具体的に実現するコンピュータ可読媒体。
【請求項３２】
コンピュータによって命令が実行されると、この命令により、さらに、メッセージ・ハンドラが、
少なくとも１つのサービス・ベース・メッセージ処理ルールを決定し、前記少なくとも１つのサービス・ベース・メッセージ処理ルールでメッセージ・ハンドラにより処置を実行する際のサービス・ベースの状況を識別し、処置を実行する際のサービス・ベースの状況がメッセージ・ハンドラにより受信したメッセージで伝達されたときにメッセージ・ハンドラによって処置を実行し、
コンピュータ・ネットワーク経由で、前記少なくとも１つのサービス・ベース・メッセージ処理ルールをメッセージ・ハンドラから使用できるようにする請求項２３に記載の命令を具体的に実現するコンピュータ可読媒体。
【請求項３３】
コンピュータによって命令が実行されると、この命令により、さらに、メッセージ・ハンドラが、
少なくとも１つの共通メッセージ処理ルールを決定し、前記少なくとも１つの共通メッセージ処理ルールでメッセージ・ハンドラにより処置を実行する際の共通の状況を識別し、処置を実行する際の共通の状況がメッセージ・ハンドラにより受信したメッセージで伝達されたときにメッセージ・ハンドラによって処置を実行し、
コンピュータ・ネットワーク経由で、前記少なくとも１つの顧客定義メッセージ処理ルールをメッセージ・ハンドラから使用できるようにする請求項２３に記載の命令を具体的に実現するコンピュータ可読媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ネットワーク・ホスト・アプリケーションの管理に関するものであり、具体的には、ホスト対象アプリケーションを管理するバックエンド・システムにおいてオペレータ介入を低減する自動データ経路指定機能を実装することに関するものである。
【背景技術】
【０００２】
アプリケーションのホスティングは、インターネット・アプリケーションの提供で増える傾向にある。ホスト・ファームは、多数のサーバおよびその他のアプリケーション・ホスティング・コンポーネント（これ以降、アプリケーション・コンポーネントと総称する）を地理的に都合のよい場所にまとめて配置し、インターネット・ハブへの効率のよいアクセスを行うアプリケーション・ホスティング・サービスを提供する。単一セットのサポート、運営、および管理システムおよびツール（これ以降「バックエンド・システム」と総称する）を通じて異なるホスト対象アプリケーションと関連するアプリケーション・コンポーネントを管理することができるため、アプリケーション・コンポーネントの中央一括配置もまた、アプリケーション・コンポーネントの運用の効率化を進める。
【０００３】
アプリケーション・ホスティング・システムのバックエンド・システムは、バックエンド・ネットワークを中心に構築することができるが、ホスト対象ＷｅｂアプリケーションとＷｅｂサイト訪問者との通信に使用されるフロントエンド・インターフェイスと分離することができる。バックエンド・ネットワークは、バックエンド・システムとアプリケーション・コンポーネントの間の通信経路を備えるが、バックエンド・ネットワークは、送信者から受信者へ情報を受動的に送信することに限られている。通常、バックエンド・ネットワークで送信される各メッセージには、そのメッセージの受信者を識別するネットワーク・アドレスおよびそのメッセージの本文を含むデータが収められる。各メッセージの宛先は、メッセージの送信者により決められる。メッセージの受信者がそのメッセージ内に含まれるデータを理解できるように、送信側コンポーネントと受信側コンポーネントの両方が了解するプロトコルに応じてメッセージのフォーマットが定められていなければならない。さらに、送信側コンポーネントは、意図した受信側コンポーネントの有無とメッセージをそのコンポーネントに送信する必要の有無を知っていなければならない。したがって、このような通信プロトコルは、２つのコンポーネントが通信できる必要がある場合に実現可能であるが、コンポーネントが追加されてゆくうちにますます難しくなる。
【０００４】
送信側コンポーネントと受信側コンポーネントの両方への既知のフォーマットの提供は、コンポーネントの間の変換機能として動作するアプリケーション・プログラム・インターフェイスを使用することにより解決できる。それとは別に、既知のフォーマットに従ってバックエンド・ネットワーク上で通信するツールを最初に作成できるように、コンポーネントではデータを送信する既知のフォーマットを使用する。メッセージ・フォーマットでは、さらに、パブリッシュされている定義を使用して、コンポーネントがそのパブリッシュされている定義を参照してメッセージの内容を解釈できるようにする。このようなパブリッシュされた定義セットは、ＨＴＭＬ（ハイパーテキスト・マークアップ言語）を解釈するための情報を含むインターネット・ブラウザの使用など、コンポーネント上で直接実装することができる。ハイブリット方式も使用することができ、この場合、フォーマット定義の一部をそれぞれのコンポーネントに分配しながら、特定のメッセージ・タイプのフォーマット定義を第３の場所に格納してコンポーネント側で特定のメッセージ定義にアクセスできるようにし、また第３の場所に格納されている素材を参照することにより第１の場所でメッセージを送信する必要があることを通知することもできる。
【０００５】
バックエンド・システムを備えるツールは、機能毎に異なる。ホスト対象アプリケーションのパフォーマンスを監視するのに特に効果のあるツールを製作しているベンダもあれば、サービス要求を追跡するための効果的なツールを製作しているベンダもある。さまざまなバックエンド機能を処理するために異なるツールを使用するのでは、送信側コンポーネントがもともと、各メッセージの宛先を識別する命令とともにプログラムされていない限り、送信側コンピュータから目的のアドレスに送信される情報に依存している応答を自動化する能力が制限される。
【０００６】
このような機能をアプリケーション・ホスティング・システム内の各コンピュータに実装することは、大幅に制約されている。コンピュータから送信される各メッセージの宛先は、内部的な考慮事項と外部的な考慮事項の両方に左右される。内部的な考慮事項としては、メッセージの内容およびメッセージを送信するコンピュータの識別がある。外部的な考慮事項としては、送信側コンピュータから特定のメッセージに応答する責任のあるパーティを識別することがあげられる。したがって、現状では、コンポーネントによってメッセージが送信されるときに、メッセージ内に記述されているイベントまたは条件の識別および解決には、指示されている応答を受け取る前に人間のオペレータがかかわる必要がある。人間のオペレータがかかわると、メッセージによって示されている状況の解決が遅れ、そのため、メッセージを開始したコンポーネントのパフォーマンスに悪影響が及ぶ可能性がある。
【０００７】
このような状況の例として、アプリケーション・ソフトウェアに関係するフォルト・メッセージの送信がある。このようなメッセージは、アプリケーション・ソフトウェアに関連するホスト対象アプリケーションの顧客に送信することができる。顧客は、メッセージを受信すると、是正処置を決定できなければならず、またその是正処置を開始する必要があることをだれに通知するべきかも決定しなければならない。このようなメッセージは、ポータルのところで管理システムに投稿することにより顧客に送信する場合があるため、さらに、顧客がポータルにアクセスするまで解決が遅れることになる。
【０００８】
それとは別に、顧客がアプリケーション・ホスティング・システムに要求を出す場合に、その要求の処理の仕方、およびさらにどのような管理機能にその要求および提案された対応策を知らせる必要があるかを決定する必要がある。したがって、このような決定を下す際に必然的に伴う遅れにより、要求の解決が遅れ、その要求で便益が得られるのが遅れる。
【特許文献１】米国特許出願第０９／７８３７４５号
【発明の開示】
【０００９】
本発明は、アプリケーション・コンポーネントからバックエンド・システム上のメッセージを解決するためのシステムおよびプロセスに関する。システムは、アプリケーション・コンポーネントがメッセージ・ハンドラと交信する際に使用するタグ付きフィールド形式を使用する標準化されたメッセージ定義を含む。メッセージ・ハンドラは、メッセージの正しい解決および経路指定を決定するためメッセージのタグ付きフィールド内に含まれる情報を利用するリゾルバを備える。リゾルバは、メッセージの内容に基づいて実施すべき処置および情報の受信者を定義するルールを適用する。これらのルールは、一般にコンポーネントに適用される共通のルールに基づき、またはサービス加入のレベルまたはその他の特徴などのサービス・プロバイダと関連するサービス・ルールに基づき、または前記の基準のいずれかまたはすべての組み合わせに基づき、メッセージを生成するアプリケーション・コンポーネント関連する顧客側で事前に定義することができる。パブリッシュされているメッセージ形式を利用することにより、本発明では、アプリケーション・ホスティング・バックエンド・システムを顧客アプリケーションに公開するためのプラットフォーム独立のフレームワークを実現する。
【００１０】
本発明は、オペレータの介入なしでアプリケーション・コンポーネントによりネットワーク経由で送信されるメッセージに対する応答を開始するネットワーク・ベースの自動メッセージ処理システムで実現することができる。システムは、メッセージが何らかの条件またはイベントを示した場合に顧客が実施したいと望んでいる処置を定義する少なくとも１つの顧客メッセージ処理ルールを備えることができる。さらに、システムは、アプリケーション・コンポーネントにより送信された情報メッセージを受信し、それらのメッセージを分析して、不測事態対策を講じなければならないことをメッセージの内容が示しているかどうかを判別するメッセージ・ハンドラを備えることもできる。メッセージ・ハンドラは、メッセージの内容が不測事態対策を講じなければならないことを示している場合に他のメッセージを生成することができる。他のメッセージの受信者は、顧客定義メッセージ処理ルールにより識別することができる。
【００１１】
本発明は、他の形式では、少なくとも１つの顧客定義メッセージ処理ルールを顧客から受信するステップ、情報メッセージの内容に基づき情報メッセージのコンポーネントを解釈し顧客定義メッセージ処理ルールを情報メッセージに適用するかどうかを決定するステップ、顧客定義メッセージ処理ルールを情報メッセージに適用することが情報メッセージの内容により指示されている場合に適用するステップ、および情報メッセージの内容によりルールの適用が指示されている場合に顧客定義メッセージ処理ルールに従って転送メッセージを生成し送信するステップを含むプロセスにおいて実現することができる。
【００１２】
他の形式では、本発明は、少なくとも１つの顧客定義メッセージ処理ルールを顧客から判別し、コンピュータ・ネットワーク経由で顧客定義メッセージ処理ルールをメッセージ・ハンドラから利用できるようにするプロセスを実装するコンピュータ・プログラムで実現することができる。顧客定義メッセージ処理ルールにより、メッセージ・ハンドラにより処置を講じるべき状況およびその状況の条件が満たされた場合にメッセージ・ハンドラにより講じるべき処置を識別する。顧客定義メッセージ処理ルールをそのルールを定める顧客に関係するメッセージに関係する範囲に制限することもできる。
【００１３】
本発明で適用可能なルールには、顧客が加入するサービスのレベルに依存するサービス・ベースのルール、さらにすべての顧客に適用可能な共通のルールが含まれる。これらのメッセージは、電子メール、ページ、ファクス、他のシステムへのインターネット経由の投稿で転送することができる。
【００１４】
顧客定義ルールは、顧客に表示されるウィザードを使用して決定することができる。ウィザードでは、他のデータベースへの参照を使用することにより、指定されたルールが適用されるアプリケーション・コンポーネントや問い合わせ先リスト管理ツールの参照などによる指定されたルールの潜在的受信者など、ルールに関連付けられる特徴を判別することができる。
【００１５】
最後に、本発明が顧客ベースのルールを自動的に適用できるだけでなく、サービス・ベースのルールおよび共通のルールも適用できることにより、アプリケーション・ホスティング・システム内の管理タスクを自動処理することが可能である。このような自動プロセス処理の一例として、個々のメッセージにより、プロビジョニング要求に固有のステップを形成するタスクが開始するプロビジョニング要求に関連するメッセージなどのメッセージの自動転送があり、プロビジョニング要求を迅速で効率のよい方法により処理することができる。
【００１６】
本発明の他の特徴および利点は、好ましい実施形態の以下の説明および請求項から明白であろう。
【発明を実施するための最良の形態】
【００１７】
特に、図１を参照すると、類似の番号は類似の要素を表しており、本発明を実施するアプリケーション・ホスティング・システム１００が示されている。本発明のシステムは、顧客向けにインターネット・アプリケーションをホスティングするために使用されるシステムなどのネットワーク・アプリケーション・ホスティング・システム１００に組み込むことができる。基本実施形態における本発明のメッセージ処理システム１０２は、メッセージ・ハンドラ１０４および顧客定義ルール・データベース１０６を含む。アプリケーション・ホスティング・システム１０２は、アプリケーション・サーバ１０８、ルータ１１０、スイッチ１１２、ソフトウェア・プログラムおよびサービスなどのソフトウェア・コンポーネント１１４、さらにホスト対象アプリケーション・システムを運営するために使用されるツールなどを含むがこれらに限定はしない。アプリケーション・ホスティング・システムのこのようなコンポーネントを、これ以降、「アプリケーション・コンポーネント」と総称する。アプリケーション・ホスティング・システム１０２を最も効率よく実現するために、アプリケーションに関連する機能の多くは別々のコンポーネント上でホスティングされ、複数のコンポーネントが機能に対する要求に十分応えられるキャパシティを備える機能を実行することがしばしばである。例えば、２つのアプリケーション・サーバ１０８およびルータ１１０をアプリケーションのホスティングに使用し、第３のサーバ１１６をホスト対象アプリケーションのデータ格納に使用する。これらのデバイスはそれぞれ、ソフトウェア・パッケージ１１４がインストールされており、カスタマー・ポータル１１８などのリモート・ツールを使用して、個々のコンポーネントおよびソフトウェア・パッケージのパフォーマンスを監視することができる。したがって、ホスト対象アプリケーション・システム１００にかかわるコンポーネントの個数は極めて大きなものとなる可能性がある。
【００１８】
メッセージ・ハンドラは、メッセージ・レシーバ１０５、メッセージ・リゾルバ１０７、メッセージ・ジェネレータ１０９、およびルール・アプライヤ１１１を備える。メッセージ・レシーバ１０５は、ソフトウェアで実装された機能グループであり、メッセージ・ハンドラ１０４はこのグループを利用してアプリケーション・コンポーネントからメッセージを受信することができる。メッセージ・リゾルバ１０７は、ソフトウェアで実装された機能であり、メッセージ・ハンドラ１０４はこの機能を利用して標準メッセージ構造に従ってメッセージの内容を解釈することができる。メッセージ・ジェネレータ１０９は、ソフトウェアで実装された機能であり、メッセージ・ハンドラはこの機能を利用し、あらかじめ定められている命令に従ってメッセージを生成することができ、このあらかじめ定められている命令は、メッセージ・ハンドラを形成するソフトウェアで実現してもよいし、メッセージ・ジェネレータの外部に格納されているルールであってもよい。ルール・アプライヤ１１１は、ソフトウェアで実装された機能であり、メッセージの内容に適用される受信メッセージへの応答を定義するルールはこの機能を利用し、メッセージの内容に基づいて個々のルールをメッセージに適用するかどうかを決定することができる。これらの機能は本発明の説明では異なるものとして示しているが、これらの機能を単一のソフトウェア・パッケージにまとめてそれらの機能を実行するようにできる。本発明の好ましい一実施形態では、これらの機能を利用するために、ＭＩＣＲＯＳＯＦＴ  ＢＩＺ−ＴＡＬＫ（商標）ソフトウェアを使用している。
【００１９】
送信側コンピュータおよび受信側コンピュータにより共通メッセージ構造が解釈できるようなスキーマと呼ばれる標準メッセージ構造が用意されている。パフォーマンス監視、資産管理、ケース・マネジメント、請求書作成、および運用方針用の個々のスキーマが用意されている。
【００２０】
スキーマの機能を使用すると、アプリケーション・ホスティング・システム１００内のメッセージ・ハンドラ１０４およびその他のコンポーネントがメッセージの内容を解釈することができる。メッセージがメッセージ・ハンドラ１０４に到着し、フィールドに値．９９が入っていると、メッセージ・ハンドラは、データに基づいて処置が示されているかどうかを判別することができない。．９９が含まれているフィールドを定義することにより、メッセージ・ハンドラは、値のコンテキストを理解することができ、しかるべく決定を下すことができる。例えば、フィールドを割合で表したメモリ利用度として定義することができ、メッセージ・ハンドラは特定のコンポーネントでのメモリ利用度が、空きメモリが不十分なためコンポーネントの速度低下が生じる可能性のあることを示す９９％であることを認識する。
【００２１】
図２には、ソフトウェア・フォルト通知メッセージと関連するスキーマが示されている。ファイルのヘッダ２０２によりメッセージ・タイプが識別される。フィールドおよび要素に関連する特性も、スキーマ２０４、２０６で定義される。スキーマ定義は、外部関係者がスキーマにアクセスできるようにアプリケーション・ホスティング・サービスによってホスティングされているアプリケーション上にパブリッシュするか、またはバックエンド・ネットワーク上のツール経由でパブリッシュすることができる。本発明の好ましい実施形態では、スキーマはメッセージ・ハンドラ、この場合、文書定義としてＭＩＣＲＯＳＯＦＴ  ＢＩＺ−ＴＡＬＫ（商標）というソフトウェア・ツール上に格納される。メッセージがＭＩＣＲＯＳＯＦＴ  ＢＩＺ−ＴＡＬＫ（商標）のやり取りに入る際に、それらのメッセージは文書定義で参照されているスキーマと突き合わせて妥当性の確認が行われる。それとは別に、スキーマは、ＨＴＴＰ接続でファイル・システムなどの階層型ファイル・ストレージ媒体を公開するＨＴＴＰ  １．１規格の拡張であるＷｅｂ  Ｄｉｓｔｒｉｂｕｔｅｄ  Ａｕｔｈｏｒｉｎｇ  ａｎｄ  Ｖｅｒｓｉｏｎｉｎｇ（「ＷｅｂＤＡＶ」）１３２（図１に示されている）を通じてアクセス可能な別のサーバ上に格納することができる。
【００２２】
従来のメッセージ形式では、フィールドは事前に定義されており、値が関連していようといまいと、メッセージに含めることができる。このような固定されたフィールド・メッセージでは、メッセージの内容を解釈することはできるが、関連があろうとなかろうとフィールドを含めなければならないため、解釈の効率がよくない。ＸＭＬなどのタグ付きフィールド・メッセージ形式に依存することにより、メッセージへのヘッダは、メッセージの本文の中にどのようなフィールドが含まれているかを示すことができ、不効率な固定フィールド・メッセージを使用しなくてもデータを解釈することができる。したがって、メッセージの本文で必要なフィールドのみを用意すればよく、必要に応じてフィールドをメッセージ形式に追加することができる。最後に、スキーマ内にヘッダ情報の定義を記述し、他のコンポーネントからメッセージを受信するコンポーネントに知らせるタグ付きフィールド・メッセージを解釈する仕方に関する基本的定義を行うことができる。
【００２３】
このようなスキーマを使用することにより、コンポーネントは受信コンポーネントの識別または有無を参照しなくてもイベントおよび条件を報告することができる。したがって、本発明の実施形態であるアプリケーション・ホスティング・システム内でコンポーネントが機能するようにするロジックをコンポーネントに組み込む必要はない。
【００２４】
より具体的には、コンポーネントから送信されたメッセージがあらかじめ定義されているスキーマに従うように個々のコンポーネントを作成するのが好ましい。コンポーネント内では、データ断片に変数名を割り当てることができる。このデータをコンポーネントからエンティティに報告するために、コンポーネント側で受信者によるデータへの名前の付け方を知っている必要はない。データが送信メッセージ内に適切に書式化されている限り、受信側コンピュータはデータのコンテキストをフィールド・タグから判別することができる。
【００２５】
さらに、メッセージでは、メッセージ・ハンドラを受信者として使用し、メッセージ・ハンドラにより送信側コンポーネントの識別に基づいてメッセージ受信者を判別することができる。図１に示されているように、バックエンド・ネットワークはバックエンド・ネットワークと通信する各コンポーネントとともにループとして示されている。論理的には、メッセージ・ハンドラはコンポーネントから各メッセージを受信し、必要に応じてそれらのメッセージを再送する。したがって、図１のシステムは、交互に各コンポーネントを、バックエンド・ネットワーク経由ではなく、メッセージ・ハンドラに直接接続することができ、コンポーネント間の通信の経路はメッセージ・ハンドラを通る。
【００２６】
個々の要素タイプ定義はさらに、ＸＭＬ名前空間１２０、またはシステム内で使用するスキーマをパブリッシュするためにシステム定義領域内で定義することができる。個々のデータ型に基づくだけでなく、一方のコンポーネントから他方のコンポーネントへの情報の送信に使用したいさまざまな内容に基づいて異なるスキーマを定義することができる。
【００２７】
ホスト対象アプリケーション・システム内のイベントの発生はイベント発生後に応答しなければならないことを示していることが知られている。示されている応答は、一般に、イベント自体の特性により制約される。例えば、メモリ保護フォルトが発生したことをソフトウェア・コンポーネントが報告してきた場合、指示応答がビデオ・モニタを交換することであると考えられることはあり得ない。
【００２８】
必要な応答を示しているメッセージを処理する第１のステップは、メッセージを通知すべき相手を判別することである。この機能は、本発明の図解されている実施形態におけるメッセージ・ハンドラ１０４によって処理される。メッセージ・ハンドラ１０４では、バックエンド・ネットワーク１２２にそって流れるメッセージの内容を検討し、メッセージの内容にルールを適用して（またはルールを適用してもらって）、メッセージおよびその内容をコンポーネントに通知する必要があるかどうか、またはどのコンポーネントに通知する必要があるかを判別する。本発明のメッセージ・ハンドラ１０４は、アプリケーション・ホスティング・サービスに関連付けられている他のコンポーネントとは異なるサーバで実現することができる。それとは別に、メッセージ・ハンドラは、複数のサーバ内に実現できるが、作業負荷は複数のサーバ間に分散されているメッセージ・レビューに関連付けられる。それとは別に、メッセージ・ハンドラをメッセージの個々の受信者に分散させ、個々の受信者が受信したメッセージを他の受信者に反映させる責任を持つようにすることができる。
【００２９】
メッセージ・ハンドラをアプリケーション・ホスティング・システムに組み込むことにより、個々のコンポーネントがメッセージの宛先を判別する必要がなくなる。メッセージは、メッセージ・ハンドラに送信され、そこで指示された受信者が判別される。
【００３０】
現在は、ＭＩＣＲＯＳＯＦＴ  ＢＩＺ−ＴＡＬＫ（商標）ソフトウェアを使用して、メッセージ処理機能を使用可能にしている。このソフトウェアは、メッセージの他の受信者を識別する役割を持つ。そのもともとのフォームの、または書き換えたフォームの転送メッセージは、アプリケーション・ホスティング・サービス内の他のコンポーネントへの命令として使用することができる。したがって、転送メッセージでは、他の内容をメッセージに付加してから、メッセージを転送するか、または内容を削除することができる。
【００３１】
メッセージ・ハンドラ１０４でメッセージをレビューできるように、最初にメッセージを生成コンポーネントから固定アドレス、特にメッセージ・ハンドラ１０４のネットワーク・アドレスに送信する。このような実装では、メッセージの意図した受信者が存在する場合にメッセージにメッセージの本文の中のフィールドとしてその意図された受信者を記述することができる。
【００３２】
メッセージの生成は、ホスト対象アプリケーション・コンポーネントによって異なる。ホスト対象アプリケーションが稼働しているオペレーティング・システムなどの基本コンポーネントは、アプリケーション・ソフトウェアの動作状態を監視する機能を備える。これらのサービスはさらに、サービス自体の動作を監視するための機能も備えることができる。これらのサービスは、通常、本発明のメッセージ処理システムに準拠せずに作成され、ソフトウェア内のイベントまたは状態を示すメッセージおよび警告はメッセージ・ハンドラがメッセージを解釈するために必要な形式で送信されることはない。この制限は、通常ハードウェア・コンポーネントの機能を制御するためにソフトウェアを利用する、ハードウェア・コンポーネントと関連するメッセージにも適用される。アプリケーション・プログラミング・インターフェイスをコンポーネントに提供することにより、コンポーネントによって生成されたメッセージをメッセージ・ハンドラ側で想定されている形式に従って書式化することができる。
【００３３】
コンポーネントが、アプリケーション・プログラム・インターフェイス（「ＡＰＩ」）の組み込みによるメッセージ書式化の実行に対応していない場合、メッセージは、メッセージをメッセージ・ハンドラに転送する前に標準形式でメッセージを書式化する変換ツールへの間接参照を通じて経路指定することができる。変換ツールを使用するには、メッセージの意図した受信者を識別することと関連する情報を保持しながらメッセージ・ハンドラに再送する前にメッセージを解釈するためのメカニズムが必要である。
【００３４】
最後に、バックエンド・ツールは、アプリケーション・コンポーネント上に常駐するエージェントをアプリケーション・コンポーネントの動作を監視する手段として使用することができる。このようなエージェントの代表的な例として、顧客のアプリケーションをホスティングするために使用されるサーバ上のメモリ使用度を監視するためにサーバ上に配置されるエージェントがある。エージェントからの使用度メッセージをポータル・ツール、または動作情報を分散させる他のツールに送信することを意図して、このようなエージェントをツールに配置することができる。このようなメッセージの経路を最初にメッセージ・ハンドラを宛先とする経路に選択するようにエージェントを適合させることで、メッセージの内容を監視し、他の処置が必要かどうかを判別する。
【００３５】
メモリ使用度ツールの場合、メモリ使用度に基づき他の処置を開始するためこのツールがすでに使用されている場合があるが（通知機能など）、そうれあれば機能を異なるツールに分散させることで他の処置を開始する能力と効率が制限される。例えば、４台のサーバをアプリケーションのホスティングに使用している場合、１台のサーバをオフラインにすると、オフラインになっているサーバはオンラインに戻り、メモリ使用度を下げることが予想されるため、サーバがオフラインになっている間にメモリ使用度が高くなったとしても許容することができる。すべてのコンポーネントが完全に機能している時点で高メモリ使用度が発生した場合、高メモリ使用度であるということは、高使用度が発生しているコンポーネントにメモリを追加しなければならないことを示している可能性がある。ツール間の情報の相互参照を行えるようにすることにより、自動開始応答の有効性および効率を改善することができる。
【００３６】
本発明の基本実施形態では、ホスト対象アプリケーション１２６のホスト対象アプリケーション顧客１２４によって提供されるルールに基づき処置を開始することにメッセージ・ハンドラを制限することができる。ルール．・セットを制限することにより、アプリケーション・ホスティング・サービスおよび顧客１２４側で効率を高めながら、顧客の満足度に関して便益を最大限まで高めることができる。さらに、ルール・セットを顧客定義ルールに制限することにより、アプリケーション・ホスティング・サービスが自動開始処置に基づく顧客の不満にさらされることを制限することができるが、これは処置が顧客の指令に起因するためである。
【００３７】
メッセージ・ハンドラ１０４が適切な応答がどのようなものであるかを正しく判別できる能力は、ホスト対象アプリケーション・システム１０２のコンポーネントからのメッセージの受信に対するものであり、メッセージ・ハンドラは応答を定義する内部ルール・セットを備えていなければならない。例えば、単純な応答として、ホスト対象アプリケーション１２６のメモリ使用度が閾値を超えた場合にホスト対象アプリケーション顧客１２４に送る通知がある。さらに複雑な応答として、フォルトが検出されたときに是正処置を開始することを対象とするものもある。メッセージの内容に基づいてイベントを識別可能な限りシステム内のイベントへの顧客側が望む応答を送るように顧客定義ルールを作成する顧客定義ルールを適用できるメッセージ内容に制限はない。
【００３８】
単純な顧客ベースのルールにより、イベント発生後に実行される通知戦略を定義することができる。例えば、サード・パーティ・ベンダによって顧客のために作成されたアプリケーション・ソフトウェアでソフトウェア・フォルトが発生したときに、顧客１２４は、サード・パーティ・ベンダにそのソフトウェア・フォルトを直ちに通知するようにしたい場合がある。このようなメッセージは、アプリケーション・ソフトウェア内にソフトウェア・フォルトが発生した場合に、サード・パーティ・ベンダにフォルトを通知する電子メール・メッセージをサード・パーティ・ベンダに送信するよう指定するルールにより自動的に処理することができる。それとは別に、通知を、ページで、ファクシミリ伝送で、または音声合成機能を使用する通話発生により行うこともできる。
【００３９】
イベント発生にのみ依存する顧客定義ルールに加えて、外部参照を参照する顧客ベースのルールも実装することができる。例えば、１３０などの連絡先リスト・ツールをアプリケーション・ホスティング・サービスのバックエンド・システム内に実装する場合、通知指令の宛先をタイトルによって識別された個人またはパーティとし、そのタイトルに関連する実際の個人またはパーティを連絡先リスト・ツールで参照するようにできる。したがって、顧客がメッセージをコンポーネントから受け取ったときにサービス担当に通知するようにしたい場合、メッセージ・ハンドラは、「顧客サービス担当」を受信者として識別するルールに基づき、連絡先リスト・ツールを参照して、現在の「顧客サービス担当」がだれであるかを決定してから、メッセージを現在のサービス担当に転送することができる。間接参照を使用することにより、顧客ベースのルールの外部の組織上の責任関係を作成することができるが、顧客ベースのルールで外部で定義された組織責任関係を実装することで、組織の責任関係定義に変更が生じる毎に顧客ベースのルールを更新しなくて済むようにできる。
【００４０】
最後に、顧客ベースのルールは、外部で形成された情報に基づいて分岐することもできる。例えば、顧客は報告されたイベントおよび追加要因の存在に基づいてメッセージ転送優先度を定義することができる。例えば、複数のサーバがアプリケーションのホスティングに使用されている場合、高メモリ使用度の報告により、ホスト対象アプリケーションと関連するルータによる情報要求の分散のレビューの実行が開始する。ルータが着信情報要求の通常の分散を報告する場合、顧客側は、アプリケーション・ソフトウェアを担当するサード・パーティ・ベンダに電子メールで通知したい場合がある。ルータが着信情報要求の不均等分散を報告する場合、顧客側は、サード・パーティ・ベンダではなく、異なるパーティ、つまりルータの機能を受け持つパーティに状態を通知したい場合がある。単純ではあるが、この例は、外部ソースに情報を要求するルールを使用して受信したメッセージおよび外部情報源の情報に基づいてどのような処置を開始するかを決定することができることを示している。
【００４１】
顧客ルール・クエリ・ウィザード３０２の例が掲載されている図３に示されているように、顧客は通知の処理方法に関する情報の入力を求められる。プルダウン・ボックス３０４を用意し、顧客が顧客定義ルールの適用されるメッセージのあるクラス３０６を選択できるようにする。プルダウン・ボックス３０４は、連絡先リスト変更通知の、パフォーマンス通知、ソフトウェア・フォルト通知、請求書作成通知などのクラスを含めることができる。図４に示されているように、さらに顧客に対して、現在入力中のルールを適用すべきクラス内の特定のコンポーネントのリストを表示できる。選択したクラスがソフトウェア・フォルトを対象とするものであった場合、顧客は、サード・パーティ製ソフトウェア４０２と関連するフォルトにサード・パーティ・ベンダへの直接の通知を含めたいことがある。図５に示されているのは、メッセージの転送コピーの目的の受信者を手動で識別するためのクエリ・ウィザードである。それとは別に、図６に示されているように、ルールが適用されるコンポーネントを選択した後、ウィザードが表示するラジオ・ボタン６０２で、顧客は現在のクラス／コンポーネント内のメッセージの通知に関してパーティ６０４を識別することができる。表示されるオプションが顧客がルールを入力する特定の状況に基づくように、連絡先リスト・ツールに含まれる情報から潜在的受信者のリストを作成することができる。
【００４２】
図７には、アプリケーション・コンポーネントからメッセージの自動処理を実装する基本プロセスが示されている。ステップ７０２では、顧客ベースのルールが決定される。これらのルールは、頻繁に見られるイベントおよび状態への望ましい応答をするように顧客に促すことにより決定することができる。上で説明した図２〜６では、通知手順に関係する顧客ベースのルールを説明している。これらのルールが決定されたら、メッセージ・ハンドラがメッセージをレビューして、顧客ベースのルールを適用するかどうかを決定する。メッセージは、メッセージ・ハンドラに届く（７０４）。メッセージ定義に従って、受信したメッセージの構文解析および解釈７０６が行われる。メッセージの解釈された内容をレビューして、１つまたは複数の顧客ベースのルールを適用すべきかどうかを決定する。ルールを適用しないと決定した場合（７０８）、このプロセスは次のメッセージが届くまで続行する（７１０）。特定の顧客ベースのルールを適用すべきであると決定した場合（７０８）、特定の顧客ベースのルールをレビューして、特定の顧客ベースのルールを実装するために外部情報を取得する必要があるかどうかを調べる（７１２）。外部情報が必要であると判断された場合、その外部情報が取得される（７１４）。特定の顧客ベースの１つまたは複数のルールをメッセージ内容に適用することができる（７１６）。アプリケーションは、例えばメッセージの内容と関連する処置を転送するステップからなるか、あるいは、処置を開始するために他のコンポーネントへの命令またはコマンドの生成７１８を含むことができる。これらの例は、単なる説明であって、ルールをメッセージに適用する場合に実行することができる処置の範囲を制限するものではない。特定の顧客ベースのルールが適用されたら、メッセージ・ハンドラは他の特定のルールを適用するかどうかを決定することができる。さらに、ほかに特定のルールがあれば、上のようにして適用する。１つまたは複数のルールの適用が完了すると、プロセスはメッセージの受信およびレビューを続行する（７１０）。
【００４３】
顧客ルール・ウィザード３０２へのアクセスだけでなく、ホスト対象アプリケーションに関係する他の情報へのアクセスも可能にするため、図８に示されているようなポータル１２８を顧客１２４に用意することで、顧客１２４がホスト対象アプリケーション１２６に関連する情報を表示し、さらにホスト対象アプリケーション１２６を管理できるようにする。ポータル１２８は顧客ベースのルールを定義する顧客１２４用にインターフェイスを備えるほかに、連絡先リスト・ツール１３０内の連絡先リストのメンテナンス、ホスト対象アプリケーションに関連するパフォーマンス・データのレビュー、ホスト対象アプリケーションのハードウェアおよびソフトウェアの構成に関するレビュー、加入サービス・レベルのレビューまたは変更、およびソフトウェアまたはハードウェア・コンポーネントの追加または削除などのホスト対象アプリケーションの構成の変更要求などアプリケーション・ホスティング・サービスに関連する他の機能へのアクセスも顧客１２４から利用できるようにする。
【００４４】
ポータル・サーバは、情報表示を生成し、インターネット経由で顧客に送信することのできるソフトウェアを備えるのが好ましい。情報を生成して顧客に送信する方法はよく知られている。情報自体は、情報の特性に基づいて編成することができる。例えば、情報表示は、メモリ使用効率または複数のサーバへの要求の分散効率、または複数の訪問者などアプリケーションの使用度測定基準など、アプリケーションがホスティングされている１つまたは複数のサーバのパフォーマンスなどのトピックに基づいて隔離することができる。ポータルは、個別の監視ツール、サービス・ポリシーまたは機器の料金などの請求書作成情報、送信されたトラブル通知またはチケットをフォローアップするためのトラブル・チケット追跡情報、およびアプリケーションがホスティングされるサーバのオペレーションおよび／またはメンテナンス、さらにホスト対象アプリケーション自体のオペレーションを受け持つパーティの連絡先情報を組み込むのが好ましい。説明しているポータルのインターフェイスが図９に示されている。図に示されているポータル９００では、「Ａｐｐ．Ｃｏｎｆｉｇ．」タスク９０２を使用して、顧客定義ルールを識別するウィザードを呼び出すことができる。
【００４５】
図８に戻ると、メッセージ送受信ツール８０４システムが示されており、音声、ページャ、電子メール、ＨＴＴＰ  ＰＯＳＴ、および／またはファクシミリ通知を使用して、イベントが発生したときに、ポータル・サーバに接続して通信しなくても顧客にその発生を通知することができる。メッセージ送受信システムを通じてメッセージを送受信することができる使用可能な宛先を連絡先リスト・ツール１３０に相互接続して、取得された情報に関する通知が特定のホスト対象アプリケーションに関連する顧客を超えて注目するパーティに届くように経路を選択することができる。
【００４６】
ページャ通知は、電子メールをページャに転送する機能を備えるサービスを利用するか、またはメッセージ・ハンドラ自体の中に電子メールをページャに送信する機能を実装することにより、行うことができる。ＨＴＴＰ  ＰＯＳＴは、ＨＴＴＰ  ＧＥＴ要求に応答してデータを供給するのとは反対に、元のメッセージ内の添付データを転送する。ＰＯＳＴは、ＳＯＡＰまたはＸＭＬ構文解析のいずれかを使用して実行することができる。いずれかの方法の下で、データが添付されているメッセージを送信するコンポーネントは、そのデータに基づいてＸＭＬ形式メッセージを構築し、メッセージ・ハンドラ１０２に送信することができる。
【００４７】
ポータルは、ホスト対象アプリケーションの情報へのアクセスを制御するセキュリティ機能８０６を備えるのが好ましい。セキュリティ・システムでは、ユーザーＩＤ／パスワード機能を使用するか、または公開鍵暗号化またはユーザー証明書法などのより高度な機能を使用することができる。選択する方法は、顧客がポータルを経由した情報へのアクセスを許可したいユーザーの数、およびその方法の使用を通じて使用可能な情報の機密度に基づいて選択することができる。したがって、情報の利用が使用されているセキュリティの方法に基づいて制限される複数の方法を実装することができる。そのため、アプリケーションがホスティングされている大企業は高レベル・アクセス権を有しており、これを通じてすべてのポータル情報にアクセスすることができ、また高レベル・マネージャ・コンピュータ上で証明書を使用することによりセキュリティ保護対策を講じることができる。低レベル・アクセスはユーザーＩＤ／パスワード・セキュリティに基づいており、それぞれのパスワードに関連付けられている制限付きの情報を利用する。１つのパスワードで、顧客の会計部門の請求書作成情報にアクセスすることが可能であり、他のパスワードで、顧客のマーケティング部門へのサイト訪問情報にアクセスすることができる。
【００４８】
上述のように、ポータル・ツールを通じて使用可能な独立のツールとして、またはメッセージ・ハンドラに組み込まれているアドレス帳として実装可能な連絡先リスト・ツール１３０を使用して、ホスト対象アプリケーションと関連付けられている連絡先情報を定義するレコードを保持することができる。この情報により、組織の責任関係を定義するだけでなく、電話番号などの連絡先情報を保持するための中央の集中格納場所を備えることができる。レコードで、ホスト対象アプリケーションに関連付けられている顧客側およびアプリケーション・ホスティング・サービス側の両方の要員を識別することができる。これらのレコードに関連付けられている情報は、連絡先情報ツールによりデータベース８０８に格納することができる。連絡先リスト内の情報は、ポータルから連絡先リスト・ツール１３０に送られた要求メッセージを通じてポータルに伝達される。連絡先ツール１３０は、要求を受け取ると、情報が要求された位置に関連する情報を識別することによりポータルに応答することができる。最初に、情報を要求できる位置のリストが、ポータルからの位置使用可能要求への応答として、連絡先ツールによりポータルに位置のリストとして伝達することができ、ポータルは柔軟にプログラムできる、つまり連絡先情報ツールから取得できるポータルについて連絡先情報が使用可能である位置のリストを生成するために使用可能な位置を知る必要はないということである。
【００４９】
コンポーネントがメッセージを送信する機能は、メッセージ・ハンドラに関連付けられたスキーマに従ってＸＭＬ形式でメッセージを書き込むアプリケーションを作成することにより使用可能にできる。それとは別に、メッセージをコンポーネント専用形式からメッセージ・ハンドラと互換性のあるスキーマに変換する機能を実行するソフトウェア・モジュールを実装し、モジュールがコンポーネントとメッセージ・ハンドラとの間でメッセージの解釈および形式変更を行うようにできる。これらのモジュールは、さらに、メッセージ・ハンドラからメッセージをコンポーネントに変換するだけでなく、コンポーネントからメッセージ・ハンドラへの変換を行うことができる。ソフトウェア開発者キット（ＳＤＫ）はアプリケーション開発者に最適な形で提供され、これを用いてメッセージ・ハンドラと互換性のあるスキーマでメッセージを送信するアプリケーションを作成できる。このようなＳＤＫは、コンポーネントにより送信されるメッセージのスキーマ互換性の妥当性を確認するツールなどを組み込むことができる。
【００５０】
上述のように、顧客とアプリケーション・ホスティング・サービスとの間にインターフェイスまたはポータルを用意することにより、顧客とサービスとの間の情報のやり取りが容易になる。ポータルは、さらに、顧客がホスト対象アプリケーションを管理するために使用できる効率のよいインターフェイスも備える。決定を下すためのコントロールを使用し経営上の決定を下す際に基づく情報を同じ場所に配置するためこのように効率がよい。
【００５１】
ポータルに情報提供するために使用するツールは、アプリケーション・ホスティング・サービスの運用のためアプリケーション・ホスティング・サービスで使用するツールと同じであってもよい。
【００５２】
図８に示されている構成では、本発明が適用されるアプリケーション・ホスティング・サービスは、アプリケーション・ホスティング・サービスを管理するための複数のツールを備えることができる。これらのツールには、サービス・チケット管理ツール８１０、請求書作成ツール８１２、連絡先管理ツール１３０、構成マッピング・ツール８０２、構成管理ツール８１４、および必要に応じてその他のツールが含まれる。
【００５３】
請求書作成ツール８１２を使用して、顧客の金融債務および状況の判別など請求書作成機能を管理することができる。ポータルの情報は、請求書作成機能ツールによって指定されたデータ・テーブル構造に基づきクエリを生成するように構成されている請求書作成ツール・データベースから、クエリ・エージェントを介して、アクセスされる。クエリは標準化されたシステム形式を使用してメッセージ形式でポータルから請求書作成ツールへ伝達され、メッセージ・ハンドラがそれらのメッセージを渡し、レビューして、処置が示されているかどうか（代替え請求書連絡先の通知など）を判別する。
【００５４】
顧客のアプリケーションをホスティングするために使用されているコンポーネントのインベントリおよび構成を追跡する構成マッピング・ツール８０２をバックエンド・システムに組み込むことができる。このようなツールは、簡単に言うと、ホスト対象はアプリケーションに関連付けられているコンポーネントを識別するデータベースであるが、識別されたコンポーネント間のリンクを含めるとさらに好ましい。例えば、データベースは、ソフトウェア・コンポーネントを特に識別可能なサーバ上にインストールされているものとして識別したり、または特定のルータを特定のアプリケーションに関連付けられているものとして識別することができる。
【００５５】
構成管理ツール８１４は、ホスト対象アプリケーションと関連付けられているコンポーネントに変更を加えることができるかどうかを判別することができるツールである。例えば、構成マネージャは、アプリケーションをホスティングするために使用されている特定のサーバにＲＡＭを増設しやすいかどうか、サーバが別のハード・ドライブを受け入れやすいかどうかを判別することができる。構成管理ツールは、エキスパート・システムを利用して、要求された修正を行いやすいかどうかに関する知識ベースをホスト対象アプリケーション構成に適用するのが好ましい。
【００５６】
プロビジョニング・オプション８１６を備えるツールはさらに、独立したツールとして、または構成管理ツールの一部としてポータル内に組み込むこともできる。プロビジョニング・ツールの目的は、ホスト対象アプリケーションに関連するコンポーネントまたはサービス・レベルに関して顧客から利用可能な顧客オプションを識別することである。このようなプロビジョニング・ツールは、ホスト対象アプリケーションに関連するパラメータに基づいて構成変更の推奨を行うことができる。例えば、プロビジョニング・ツールに対して、ホスト対象アプリケーション・サーバの高メモリ使用度状態を再送により伝達することができる（このような通知は、もともとの通知メッセージに適用されたサービスまたは共通ルールにより開始される）。援助の申し込みもまた同様に、顧客ベースのルールに基づいてフィルタ処理することができる。このようなルールの一例として、顧客はハードウェアの提案を受け入れるが、ソフトウェアまたはサービス提案を受け入れない。
【００５７】
サービス・チケット８１２の追跡に他のツールを使用することもできる。サービス・チケットには、新規ハードウェアまたはソフトウェアの追加、フォルトまたは欠陥の是正、およびホスト対象アプリケーションの構成の変更を行うサービス要求などがあるが、これらに限定はされない。サービス・チケット情報は、チケットの要求、基本サービス要求の要約、および実行する処置およびサービス要求の状況を識別するエントリを含む。ホスト対象アプリケーションのパフォーマンス８１８を監視する他のツールを備えることもできる。このツールでは、ＣＰＵ利用度、ディスク領域利用度、メモリ利用度、ネットワーク帯域幅利用度、サービス状況、ネットワーク・ハードウェア利用度、およびアプリケーション可用性などの、これらには限定されないパラメータを監視することができる。パフォーマンス監視に関連する情報は、パフォーマンス監視ツールに関連するデータベース（図に示されていない）に格納することができる。
【００５８】
顧客ベースのルールのほかに共通ルールをホスト対象のすべてのアプリケーションに適用するために確立することができる。通常、これらのルールは、すべてのホスト対象アプリケーションおよびコンポーネントにわたって共通に適用可能なイベントまたは状態を含む。例えば、サービス加入レベルを変更するメッセージは、請求書作成ツールに報告する必要はあるが、新しい加入者レベルに基づいて追加連絡先を入力する場合には連絡先リスト・ツールに報告する必要がある。また、構成マッピング・ツールは、ホスト対象アプリケーション構成情報が保持されるように、サービス・レベルの変更に従って更新する必要がある。これらの状況におけるメッセージ処理ルールは、クライアントに関連するサービス・レベルと無関係であり、したがって、すべてのメッセージに適用することができる。
【００５９】
この例は、加入レベルを変更する顧客要求を示す、ポータルからツールへのメッセージに基づいているが、さらに共通ルールを他のコンポーネントに適用できる。例えば、ファイヤ・ウォール監視ツールは、ホスト対象アプリケーションへの情報要求の急激な流入を検出することができる。急激な流入がサービス拒否攻撃によるものである場合などに、勤務中のセキュリティ担当オペレータにページャで連絡し、是正処置が必要かどうかを判断させる共通ルールを指定することができる。それとは別に、流入が単一アドレスからの場合に、情報要求に対しフィルタ処理を自動起動するなど処置を自動実行し、単一アドレスからの情報要求がアプリケーションのホストであるサーバに配給されるのを防止することができる。
【００６０】
第３のルールのカテゴリは、これ以降サービス・ベースのルールと呼ぶが、採用すると有益である、メッセージ内に報告されているイベントまたは状態に関する外部状態に依存するルールである。例えば、通知および応答の優先度など、さまざまなメッセージ処理手順が、サービス加入レベルに基づく状況がある。顧客に異なるサービス・レベルを提供すると、顧客は異なるサービス・レベルに関連する財務上の影響を考慮し、ホスト対象アプリケーションの機密度に合わせてサービス応答を手直しすることができる。
【００６１】
サービス・ベースのルールの簡単な例が、顧客サービス担当通知応答に示されている。ホスト対象アプリケーションと関連するコンポーネント内にイベントが発生し、そのイベントが顧客サービス担当の通知を必要とした場合、通常の手順だと、先入れ先出し方式で、顧客サービス担当のメッセージ・キューにメッセージを入れることができる。そのイベントを報告したコンポーネントに関連する顧客がより高いレベルのサービスに加入している場合、そのメッセージに異なる優先度を設定するか、またはメッセージを最も手が空いている顧客サービス担当に送信することができる。それとは別に、ページャなどより直接的な形式でメッセージを送信することもできる。
【００６２】
サービス・ベースのルールは、サービス・プロバイダをホスティングするアプリケーションによって提供されるルールであるのが好ましい。これらのルールは、顧客毎に異なる。例えば、ホスト対象アプリケーション内で生じたイベントへの応答に関するルールは、顧客が加入しているサービス・レベルに基づいて生成される。標準サービス・レベルとプレミアム・サービス・レベルを提供するサービスの場合、イベントに応答するルールは、顧客が標準サービス・レベルに加入しているのか、それともプレミアム・サービス・レベルに加入しているかにより決定される。このような決定は、サービス・レベルにより定義されている請求書作成情報を含む請求書作成モジュールなどの外部データベースを参照するか、またはサービス・レベルを明示的に識別するホスト対象アプリケーション構成ツールを参照して行うことができる。
【００６３】
例えば、他のサービス・ルールを使用できるのであれば、これは場所またはプラットフォームに基づく。アプリケーション・ホスティング・サービス・プロバイダが、サーバ・ファームを形成するなどの方法で、地理的に異なる場所でアプリケーションをホスティングするために使用されるコンポーネントを編成する場合、イベントに対する応答は、イベントを報告したコンポーネントが配置されている特定のサーバ・ファームによって決定できる。異なるコンポーネント・タイプを使用する場合、各コンポーネント・タイプに対する異なるルールを呼び出すことができる。例えば、アプリケーション・ホスティング・サービス・プロバイダがＨｅｗｌｅｔｔ  Ｐａｃｋａｒｄ製サーバを他の顧客のアプリケーションのホスティングに使用しているときに、Ｃｏｍｐａｑと顧客との間のマーケティング契約により、複数のホスト対象アプリケーション顧客が、Ｃｏｍｐａｑブランドのサーバをアプリケーションのホストとして使用するよう要求することができる。Ｃｏｍｐａｑブランドのサーバで生じたイベントにより１つの応答が発生し、その一方でＨＰサーバからの類似のイベントで異なる応答が発生するようにサービス・ルールを適用することができる。
【００６４】
サービス固有のルールに基づいてメッセージを処理することを示しているプロセスの例が図１０に示されている。ステップ１００２で、メッセージがメッセージ・ハンドラに届く。その後、メッセージ・ハンドラは、そのメッセージに関連するフィールド定義にアクセスする（１００４）。サービス・ルールをメッセージに適用する（１００６）操作が、フィールド定義に適用すべきルールの識別に基づいて行われ、フィールドが存在することで特定のルールがそのフィールドの内容に適用される。したがって、メッセージに関連するフィールド定義が決定された後、適用すべきルールがフィールドの内容に適用され、適用すべきサービス・ベースのルールの処置が生成される（１００８）。
【００６５】
図１１に示されている例の目的に関して、サービス・チケットは処置の状況を追跡するビジネス上の方法である。顧客が顧客のアプリケーションをホスティングするサーバにＲＡＭを増設することを要求した場合、作業はいくつかのステップで実行される。ＲＡＭを複数のシャシに実際に装着することに加えて、対価を支払わなければならない追加機器を請求書作成部門に知らせる必要がある。構成マッピング・ツールがアプリケーション・ホスティング・サービスに関連付けられているバックエンド・システムに組み込まれる場合、使用中の実際のホスト対象アプリケーション・コンポーネントに関する、ツールが管理する情報を更新する必要がある。さらに、顧客に、要求されたサービス・チケットの状況に関する情報を提供し、顧客がサービス・チケットの状況に基づいて計画を立てられるようにする。
【００６６】
サービス・チケットは、一般に、チケットに関連する基本サービスに基づく特定の経路を辿る。前段で説明したＲＡＭの増設を使用し、要求を、増設を行う前に承認が要求されるアプリケーション構成マネージャに送ることができる。このような承認は、要求された増設メモリ用のサーバのシャシ内に空きがあるかどうかに基づいて行うことができる。ＲＡＭ増設が可能かどうかを評価するために、構成マネージャはホスト対象アプリケーションと関連するサーバを定義した仕様書を構成マッピング・ツールに要求し、決定を下すための情報を取得することができる。
【００６７】
ＲＡＭをサーバのシャシに装着されることが判明したら、ロジスティックス部門に問い合わせ、要求されたＲＡＭが使用可能かどうかを調べることができる。ＲＡＭが現在使用可能であれば、ロジスティックス部門は構成マネージャに使用可能であることを知らせる。ＲＡＭが現在使用可能でなければ、ロジスティックス部門は要求されたＲＡＭを注文し、注文したＲＡＭの使用可能日を判別し、その使用可能日をアプリケーション構成マネージャに知らせることができる。これから、アプリケーション構成マネージャは、ＲＡＭをサーバのシャシに挿入するハードウェア技師の時間のスケジュールを立てることができる。ＲＡＭを装着し終わったら、ハードウェア技師は、請求書作成ツールおよび構成マッピング・ツールなどの関連するツールに装着を通知する。さらに、要求されたＲＡＭの装着が成功したことを顧客に通知したい場合がある。サービス・チケット・ツールを使用して、予定完了日とともにこのプロセスの各ステップの一覧を作成する。この情報に基づいて、顧客は要求されたＲＡＭの装着の進行状況を追跡することができる。
【００６８】
図１１に示されているように、この機能は、本発明で実現された場合、顧客のアプリケーションのホストとなるサーバにＲＡＭを増設する要求を顧客が入力する（１１０２）ことにより起動される。要求が入力されるツールで、顧客がＲＡＭの増設を望んでいることを示すプロビジョニング要求メッセージを生成することができる（１１０４）。要求を受け取るのにポータル・ツールを使用すると、要求を開始する方法の使い勝手が向上するが、標準形式によるメッセージの手動符号化など要求を生成する他の方法も使用することができる。
【００６９】
その後、ポータルからメッセージ・ハンドラへプロビジョニング要求メッセージを送信することができる（１１０６）。メッセージ・ハンドラは、メッセージの形式をメッセージ・ハンドラが理解できることに基づいてメッセージを受け取って（１１０８）、解釈する（１１１０）ことができる。目的のハードウェア・アップグレードがあるということのメッセージの指示に基づいて、メッセージ・ハンドラはクエリを生成して（１１１２）構成管理ツールに送信し（１１１４）、ホスト対象アプリケーション構成が要求されたＲＡＭ増設に使いやすいものであるかどうかを判別する。クエリを受信する（１１１６）構成管理ツールは、構成マッピング・ツールへのクエリを生成し（１１１８）、ホスト対象アプリケーション構成を記述する情報を調べて、要求されたＲＡＭを既存の機器に増設できるかどうかを構成管理ツールに判別させることができる。それとは別に、構成管理ツールでは、アプリケーション構成情報が判明していることが必要であるが、メッセージ・ハンドラは情報の受け取り側として識別される構成管理ツールとともに情報要求を処置として含むことができる。この場合に送信するメッセージとその受信者を決定する作業は、本発明が適用される特定のアプリケーション・ホスティング・サービスに応じて、共通ルールまたはサービス・ベースのルールに従って行うことができる。
【００７０】
送信された構成マップ要求は、メッセージ・ハンドラによって受信され（１１２２）、顧客ベース、サービス・ベース、および共通のルールがメッセージの内容に適用される（１１２４）。この場合には、これらのルールは、転送以外の処置は指示されず、メッセージ・ハンドラは単に、構成マップを構成マッピング・ツールに転送する（１１２６）だけであることを示す。
【００７１】
構成マッピング・ツールは、構成マッピング・ツール用のデータベース内に含まれているデータに基づきホスト対象アプリケーション構成を記述するメッセージを生成することができる（１１２８）。データは、メッセージ・ハンドラを介して生成される構成変更メッセージにより示されているように、追加または削除が発生したときにハードウェアまたはソフトウェアの追加または削除を記録することにより保持するのが好ましい。その後、構成マッピング・ツールにより、構成記述を含むメッセージがメッセージ・ハンドラに送信される（１１３０）。
【００７２】
メッセージ・ハンドラは、構成マッピング・ツールからメッセージを受信し（１１３２）、ルールをメッセージの内容に適用し（１１３４）、追加処置が指示されているかどうかを判別する。この実施例では、他の処置は指示されないため、メッセージ・ハンドラは単に、アプリケーション構成メッセージを構成管理ツールに転送するだけである（１１３６）。
【００７３】
構成管理ツールは、アプリケーション構成マップを受け取った後（１１３８）、ホスト対象アプリケーションが要求されている追加ハードウェアまたはソフトウェアを受け入れるかどうかを判別することができる（１１４０）が、これは、この実施例の目的に関しては、ホスト対象アプリケーション用のサーバにＲＡＭを増設する要求である。構成管理ツールは、アプリケーション構成がＲＡＭ増設に適している場合に適切なメッセージを生成することにより（１１４６）要求された増設ＲＡＭがアプリケーション構成と互換性があるかどうかについてメッセージ・ハンドラに応答することができる。構成管理ツールがＲＡＭを増設できないと応答した場合、メッセージ・ハンドラは拒絶メッセージを、その要求を最初に行った顧客に転送する。さらにメッセージ・ハンドラは、サービスベースまたは共通のルールに対応して、その顧客担当のアカウント・マネジャーなどの他の当事者に拒絶を通知することができる。メッセージを関連するパーティに追加配布すると、アプリケーション・ホスティング・サービスは、そのような拒絶が発生した場合にクライアント・マネージャなどの個人が介入できるようにし、クライアント・マネージャがホスト対象アプリケーションから望ましいパフォーマンスを得る他の選択肢を提案できるようにすることで顧客満足度を最大限まで高めることができる。
【００７４】
構成管理ツールがＲＡＭ増設可能であるということに応答した場合、メッセージ・ハンドラはメッセージを要求側顧客に転送し、その顧客がＲＡＭ増設を望んでいるかどうかを尋ねる。顧客がＲＡＭ増設を望んでいることを指示した場合、その顧客の指示がメッセージ形式でメッセージ・ハンドラに送信される。メッセージ・ハンドラは、次に、あらかじめ設定されている共通ルール、サービス・ベースのルール、および顧客ベースのルールに従ってメッセージの内容に基づき動作することができる。
【００７５】
メッセージ・ハンドラは、新しいサービス・チケットを開くことを示すサービス・チケット管理ツールへのメッセージを生成することができる（１１５０）。新しいサービス・チケット・レコードを要求するために使用される情報は、ルールを参照することにより決定することができる。例えば、前記の顧客定義通知選択をサービス・チケット要求および情報に含めることで、サービス・チケットの進行状況に関する情報通知の対象となる受信者である顧客によって識別されたパーティは、サービス・チケット・ツールに対して状況通知の対象となる受信者であるとして識別される。
【００７６】
メッセージ・ハンドラは、さらに、必要なハードウェアの在庫を調べて注文を出す作業を担当するロジスティックス・ツールへのＲＡＭ可用性要求を生成することもできる（１１５２）。ロジスティックス・ツールは、メッセージを受信すると（１１５６）、要求されたＲＡＭが在庫にあるかどうかを調べる（１１５８）。通常、このツールは、在庫データベースをチェックして、ＲＡＭが在庫にあるかどうかを調べるか、またはＲＡＭが在庫にない場合に外部仕入れ先にＲＡＭを注文する。在庫か注文かのＲＡＭの状況および入手可能日を、ロジスティックス・ツールによって生成された（１１６０）のＲＡＭ入手可能性メッセージ経由でメッセージ・ハンドラに送信することができる。
【００７７】
メッセージ・ハンドラは、ＲＡＭ入手可能性メッセージを受信した後（１１６２）、ほとんど指示されることはないがＲＡＭのメッセージの内容に基づき処置を指示するかどうかを決定するルールを適用し、ＲＡＭメッセージをサービス・チケット・ツールに転送し（１１６４）、サービス・チケット・ツールにＲＡＭが入手可能であることを通知することができる。
【００７８】
サービス・チケット・ツールは、メッセージを受信し（１１６６）、顧客ベース、サービス・ベース、および共通のルールをメッセージの内容に適用する（１１６８）。通常、サービス・チケット・ツールは、これらのルールに基づきＲＡＭを要求された指定場所に装着するプロセスに関するスケジュールを生成するだけでなく、イベントのスケジュールの期間内にマイル・ストーンの発生を誰に通知する必要があるか、およびサービス・チケット・ツールによりどのようなイベントを開始する必要があるかを判別することができる。例えば、サービス・チケット・ツールは、メッセージを生成し（１１７０）、ハードウェア装着技師に送信し（１１７２）、ＲＡＭの増設要求、ＲＡＭの装着先、増設するＲＡＭを選択する場所および時期、および装着完了日時を通知する必要がある。
【００７９】
送信されたハードウェア・メッセージは、メッセージ・ハンドラによって受信され、再びルールがメッセージの内容に適用される。転送メッセージの宛先を連絡先リストを参照することにより決定し、顧客のアプリケーション担当として配属されているハードウェア技師をハードウェア装着メッセージの受信者として指定することができる。さらに、ハードウェア装着メッセージを発行することを、顧客、または技師配属マネージャなどの他のパーティに通知することもできる。
【００８０】
ハードウェア技師は、ハードウェア装着メッセージを受信すると（１１８２）、要求されたハードウェア変更１１８４、この場合ＲＡＭの増設を実施する。ハードウェア技師は、次に、ＲＡＭの装着が成功したことを示すメッセージを発行することができる（１１８６）。このメッセージは、メッセージ・ハンドラに送信される（１１８８）。メッセージ・ハンドラは、メッセージを受信すると（１１９０）、再び、ルールをメッセージの内容に適用し（１１９２）、成功した装着メッセージの内容により示されている必要なメッセージを生成する。メッセージをサービス・チケット追跡ツールに転送するほかに（１１９４）、メッセージ・ハンドラは、構成マッピング・ツールにアプリケーション構成に変更が生じたことを通知し（１１９６）、装着が成功したことを示すメッセージを顧客に対して発行し（１１９７）、増設ＲＡＭの購入、装着、および利用に関する変更が必要であることを示すメッセージを請求書作成ツールに対して発行する（１１９８）。これらのメッセージが生成され送信されると、メッセージ・ハンドラは、メッセージの全般的な流れの監視状態に戻り（１１９９）、指示された処置を識別することができる。
【００８１】
ＲＡＭ装着を実施することと関連する個々のステップを実行する作業は、サービス・チケット・ツールを通じて調整するか、またはメッセージ・ハンドラ自体によって調整することができる。要求されたＲＡＭの増設を実行するのに必要な各ステップを実行する際に、そのステップを担当するツールはメッセージを介して命令を受け取り、応答メッセージを介してタスクの完了を報告することができる。
【００８２】
市販のソフトウェア・パッケージを使用して異なるツールの機能を実行するには、メッセージにより受け取り側アプリケーションでプロセスを開始する機能があればよい。メッセージには、一組のデータおよびそのデータに基づいて何らかのタスクを実行するメッセージの受信者への命令が含まれ、そのメッセージへの応答は渡されたデータに基づいて受信者がタスクを実行した結果である。この方法は、関数呼び出しの受け渡しに似ている。基本的なプログラミングでは、定義済み関数を作成し、呼び出し側プログラムにリンクして、異なるベンダによって作成された異なるツールの組み込み能力を制限する必要がある。ベンダがツールを改訂または更新する毎に、呼び出し側プログラムとツールとの間のリンクを設定し直さなければならず、その結果、呼び出し側ツールと受け取り側ツールとの互換性を保証するために作業が必要になるので効率が悪くなる。
【００８３】
ＸＭＬ、ＸＭＬ−ＲＰＣ、およびＳＯＡＰなどの標準形式を使用してメッセージを符号化することにより、個々のツールに標準化されたインターフェイス定義を提供し、ツール側でパブリッシュされている定義を参照して必要な形式を識別できるようにする。したがって、アプリケーション・マッピング・ツールは、ホスト対象アプリケーションに関連付けられているコンポーネントの目的のマップを識別する要求を受け取ることが可能である。この識別は、要求メッセージに含まれるデータに基づく。メッセージ内のデータの特性を識別するパブリッシュされているスキーマを参照することにより、マッピング・ツール側でメッセージの構文解析を実行し、供給された情報を理解することができる。情報が理解されれば、マッピング・ツールは関連するアプリケーション構成を識別することにより要求に対する応答を判別することができる。応答の情報が判別されるか、データベースから呼び出されるか、または他の何らかの手段により取得された後、マッピング・ツールは要求された情報を供給する要求側ツールにメッセージを送り返すことができる。ここでもまた、送信側ツールは書式定義にアクセスできるので、応答メッセージでは、要求側ツールで理解可能な標準化された形式を使用することが可能である。
【００８４】
それぞれのツールに合わせてインターフェイスを手直しし、他のツールと通信できるそれぞれのおよびすべてのツールを組み込まなくても、共通メッセージ形式によって提供される標準機能を使用すれば、メッセージ・プロトコル全体を設計し直すことなくツールの追加または削除を行うことができる。新しいツールの機能を使用できるようにするために新しいスキーマを開発しパブリッシュする必要があるかもしれないが、ツールでパブリッシュされた定義を参照することができれば設計し直しの作業が限定され、オペレータのプログラミングまたは介入に頼らずともツールでメッセージ形式を判別することが可能になる。
【００８５】
サービス・チケット追跡またハードウェア増設タスクと関連するメッセージを処理することができることのほかに、本発明のメッセージ・ハンドラは、２００１年２月１５日に出願され全体が参照により本発明に組み込まれている米国特許出願第０９／７８３７４５号に開示されているようなソフトウェア・ビルド・スクリプト・ジェネレータとともに使用することができる。このようなツールをバックエンド・システムに組み込むことにより、メッセージ・ハンドラと関連付けられているルールを使用してアプリケーション・コンポーネント上のソフトウェア変更をスケジュールし制御することでソフトウェアの再構成、追加、または削除を完全自動化することができる。
【００８６】
ソフトウェア・プロビジョニング機能の自動化は、メッセージをビルド・スクリプト生成ツールに送出し、メッセージへの応答として要求されたソフトウェア・パッケージをインストールするスクリプトを生成し、ソフトウェア変更が望まれているコンポーネント上のスタートアップ・ルーチンに挿入するという方法で実現できる。したがって、このプロビジョニング自動化は、メッセージを受信したコンポーネントである、インストールするソフトウェアを識別するビルド・スクリプト生成ツールに送信することに基づいており、さらに、コンポーネントのダウンタイムがオフピーク時間帯に調整されるようにソフトウェアをインストールするスケジュールを用意することもできる。スケジューリングの識別は、顧客のアプリケーションの利用度に基づき、顧客定義ルールに従って行う。
【００８７】
上の説明は一般に、アプリケーション・ホスティング・サービスのバックエンド・システムの完全自動化オペレーションに関するものであるが、システム・オペレータが自動化機能を徐々に実装されるようにすることで手動でツールを使用可能にすることもできる。例えば、人間が構成マネージャとして作業することにより構成管理ツール機能を使用可能にすることができる。要求された構成変更要求をオペレータに送信する。このようなシナリオでは、メッセージ・ハンドラがオペレータに変更要求を送信するのに先立ってアプリケーション構成マップ要求をすでに発行していると都合がよい場合が多く、構成マップに変更要求を付属させることができる。サービス加入レベルに基づいて変更要求に優先度を割り当て、サービス・ベースのルールが構成変更レビューのスケジューリングに影響を及ぼすようにできる。これらの機能は、メッセージ・ハンドラがルールの基礎となるプロセスを使用可能にする十分な規則を備えている限り、それぞれ使用可能にすることができる。
【００８８】
メッセージ・ハンドラは、上の説明では独立したツールとして示されているが、サービス・チケット追跡ツールなど他のツールに組み込むこともできる機能である。メッセージ・ハンドラを他のツールに組み込むことが好適であるかどうかは、ルールがメッセージに適用される範囲によって決まる。アプリケーションを顧客に送信される通知命令に限る場合、メッセージ・ハンドラをポータルに組み込むと、すべてのバックエンド・メッセージをメッセージ・ハンドラによってレビューすることに関連する不効率を最小限に抑えることができる。
【００８９】
それとは別に、メッセージ・ハンドラ機能をアプリケーション間に分散させ、それぞれのツールにそのツールに送られるメッセージをレビューする役割を持たせるようにできる。分散システムでは、個々のツールは中央の顧客ベース・ルール知識ベースに依存し、ツールはそれらのルールにアクセスしてメッセージ処理を決定することができる。
【００９０】
それとは別に、分散処理命令を使用すると、多様なツールがクエリ・メッセージの内容に基づいて処置を決定する中央顧客ベース・ルール・ツールに処置命令を要求することができる。このような実装では、多様なツールが顧客ベース・ルール決定ツールに合わせて処置クエリの書式を設定する。メッセージの内容は、元のメッセージの内容と、メッセージの内容に関連付けられている顧客の識別の両方を含む。
【００９１】
本発明は、本発明の精神または本質的特性から逸脱することなく上で説明した実施形態と異なる特定の形態で実現することが可能である。したがって、上記の明細書ではなく、本発明の範囲を示している、付属の請求項を参照しなければならない。
【図面の簡単な説明】
【００９２】
【図１】メッセージ処理に顧客定義ルール・データベースを利用するアプリケーション・ホスティング・システムの図である。
【図２Ａ】図２Ａは、アプリケーション・ソフトウェア・エラー・メッセージを定義するスキーマの説明図である。
【図２Ｂ】図２Ｂは、アプリケーション・ソフトウェア・エラー・メッセージを定義するスキーマの説明図である。
【図２Ｃ】図２Ｃはアプリケーション・ソフトウェア・エラー・メッセージを定義するスキーマの説明図である。
【図２Ｄ】図２Ｄはアプリケーション・ソフトウェア・エラー・メッセージを定義するスキーマの説明図である。
【図３】顧客定義ルールの適用対象のメッセージ・クラスを識別するための顧客定義ルール・クエリ・ウィザードの説明図である。
【図４】顧客定義ルールの適用対象のコンポーネントを識別するための顧客定義ルール・クエリ・ウィザードの説明図である。
【図５】ソフトウェア・フォルト・メッセージを対象とする自動転送通知の受信者識別を手動で入力するための顧客定義ルール・クエリ・ウィザードの説明図である。
【図６】ソフトウェア・フォルト・メッセージを対象とする自動転送通知の受信者を識別するための顧客定義ルール・クエリ・ウィザードの説明図である。
【図７】顧客定義ルールに応答生成のための他の情報源への間接的参照が含まれるメッセージの内容による指示に従って顧客定義ルールを使用してメッセージを処理するプロセスに関連する詳細を示す図である。
【図８】共通ルール、サービス定義ルール、および顧客定義ルールを使用してメッセージに応答するアプリケーション・ホスティング・システムの図である。
【図９】顧客がバックエンド・サービスにアクセスする際に使用するポータルの説明図である。
【図１０】メッセージの内容の指示に従ってサービス・ベースのルールを使用してメッセージを処理することと関連する簡略化したプロセスの図である。
【図１１Ａ】図１１Ａは、顧客定義ルール、サービス・ベース・ルール、および共通ルールをメッセージ、特に、アプリケーションをホスティングするサーバへのＲＡＭの追加の要求に適用する方法を使用するプロセスを示す図である。
【図１１Ｂ】図１１Ｂは、顧客定義ルール、サービス・ベース・ルール、および共通ルールをメッセージ、特に、アプリケーションをホスティングするサーバへのＲＡＭの追加の要求に適用する方法を使用するプロセスを示す図である。
【図１１Ｃ】図１１Ｃは、顧客定義ルール、サービス・ベース・ルール、および共通ルールをメッセージ、特に、アプリケーションをホスティングするサーバへのＲＡＭの追加の要求に適用する方法を使用するプロセスを示す図である。
【図１１Ｄ】図１１Ｄは、顧客定義ルール、サービス・ベース・ルール、および共通ルールをメッセージ、特に、アプリケーションをホスティングするサーバへのＲＡＭの追加の要求に適用する方法を使用するプロセスを示す図である。
【図１１Ｅ】図１１Ｅは、顧客定義ルール、サービス・ベース・ルール、および共通ルールをメッセージ、特に、アプリケーションをホスティングするサーバへのＲＡＭの追加の要求に適用する方法を使用するプロセスを示す図である。
【図１１Ｆ】図１１Ｆは、顧客定義ルール、サービス・ベース・ルール、および共通ルールをメッセージ、特に、アプリケーションをホスティングするサーバへのＲＡＭの追加の要求に適用する方法を使用するプロセスを示す図である。
【図１１Ｇ】図１１Ｇは、顧客定義ルール、サービス・ベース・ルール、および共通ルールをメッセージ、特に、アプリケーションをホスティングするサーバへのＲＡＭの追加の要求に適用する方法を使用するプロセスを示す図である。
【図１】
2005517234.tif 000002
【図２Ａ】
2005517234.tif 000003
【図２Ｂ】
2005517234.tif 000004
【図２Ｃ】
2005517234.tif 000005
【図２Ｄ】
2005517234.tif 000006
【図３】
2005517234.tif 000007
【図４】
2005517234.tif 000008
【図５】
2005517234.tif 000009
【図６】
2005517234.tif 000010
【図７】
2005517234.tif 000011
【図８】
2005517234.tif 000012
【図９】
2005517234.tif 000013
【図１０】
2005517234.tif 000014
【図１１Ａ】
2005517234.tif 000015
【図１１Ｂ】
2005517234.tif 000016
【図１１Ｃ】
2005517234.tif 000017
【図１１Ｄ】
2005517234.tif 000018
【図１１Ｅ】
2005517234.tif 000019
【図１１Ｆ】
2005517234.tif 000020
【図１１Ｇ】
2005517234.tif 000021
【国際調査報告】
2005517234.tif 000022