サービス指向アーキテクチャー
サービス指向のアーキテクチャー。この説明は、本発明を完全に説明するものでもないし、又、その範囲を限定するものでもない。本発明の他の特徴、態様、及び目的は、明細書、添付図面及び特許請求の範囲を検討することにより理解できよう。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、一般に、サービスのためのミドルウェアに係り、より詳細には、クライアントとサービスが通信できるようにするメッセージ処理能力を有したスイッチングファブリックに係る。
【０００２】
優先権の請求：本出願は、参考としてここにその全体を援用する次の出願中の特許出願から優先権を請求する。
２００４年５月２１日に出願されたマテウ・ミッシュ氏等の「SYSTEM ANDMETHOD FOR ENTERPRISE APPLICATION INTEGRATION BUS」と題する米国プロビジョナル特許出願第６０／５７３，３５４号（代理人ドケットＮｏ．ＢＥＡＳ−０１６８４ＵＳ０）；
２００４年５月２１日に出願されたアルフレッド・チャン氏等の「LIQUID COMPUTING」と題する米国プロビジョナル特許出願第６０／５７３，７１７号（代理人ドケットＮｏ．ＢＥＡＳ−０１７０３ＵＳ０）；
２００５年５月１９日に出願されたポールＢ．パトリック氏等の「SERVICE ORIENTED ARCHITECTURE WITH MESSAGE PROCESSING STAGES」と題する米国特許出願（代理人ドケットＮｏ．ＢＥＡＳ−０１６８３ＵＳ０）；
２００５年５月１９日に出願されたポールＢ．パトリック氏等の「SERVICE ORIENTED ARCHITECTURE WITH MESSAGE PROCESSING PIPELINES」と題する米国特許出願（代理人ドケットＮｏ．ＢＥＡＳ−０１６８４ＵＳ１）；
２００５年５月１９日に出願されたポールＢ．パトリック氏等の「SERVICE ORIENTED ARCHITECTURE」と題する米国特許出願（代理人ドケットＮｏ．ＢＥＡＳ−０１６８４ＵＳ２）；
２００５年５月１９日に出願されたポールＢ．パトリック氏等の「FAILSAFESERVICE ORIENTED ARCHITECTURE」と題する米国特許出願（代理人ドケットＮｏ．ＢＥＡＳ−０１６８４ＵＳ３）；
２００５年５月１９日に出願されたポールＢ．パトリック氏等の「SCALEABLE SERVICE ORIENTED ARCHITECTURE」と題する米国特許出願（代理人ドケットＮｏ．ＢＥＡＳ−０１６８４ＵＳ４）；
２００５年５月１９日に出願されたポールＢ．パトリック氏等の「DYNAMICALLY CONFIGURABLE SERVICE ORIENTED ARCHITECTURE」と題する米国特許出願（代理人ドケットＮｏ．ＢＥＡＳ−０１６８４ＵＳ５）；
２００５年５月１９日に出願されたポールＢ．パトリック氏等の「SECURE SERVICE ORIENTED ARCHITECTURE」と題する米国特許出願（代理人ドケットＮｏ．ＢＥＡＳ−０１６８４ＵＳ６）；
２００５年５月１９日に出願されたポールＢ．パトリック氏等の「CO-LOCATED SERVICE ORIENTED ARCHITECTURE」と題する米国特許出願（代理人ドケットＮｏ．ＢＥＡＳ−０１６８４ＵＳ７）；
２００５年５月１９日に出願されたポールＢ．パトリック氏等の「PROGRAMMABLE SERVICE ORIENTED ARCHITECTURE」と題する米国特許出願（代理人ドケットＮｏ．ＢＥＡＳ−０１６８４ＵＳ８）；
２００５年５月１９日に出願されたポールＢ．パトリック氏等の「BATCH UPDATING FOR A SERVICE ORIENTED ARCHITECTURE」と題する米国特許出願（代理人ドケットＮｏ．ＢＥＡＳ−０１６８４ＵＳ９）；
２００５年５月１９日に出願されたポールＢ．パトリック氏等の「RELIABLE UPDATING FOR A SERVICE ORIENTED ARCHITECTURE」と題する米国特許出願（代理人ドケットＮｏ．ＢＥＡＳ−０１６８４ＵＳＡ）；
２００５年５月１９日に出願されたポールＢ．パトリック氏等の「SERVICE ORIENTED ARCHITECTURE WITH FILE TRANSPORT PROTOCOL」と題する米国特許出願（代理人ドケットＮｏ．ＢＥＡＳ−０１６８４ＵＳＢ）；
２００５年５月１９日に出願されたポールＢ．パトリック氏等の「SERVICE ORIENTED ARCHITECTURE WITH ELECTRONIC MAIL TRANSPORT PROTOCOL」と題する米国特許出願（代理人ドケットＮｏ．ＢＥＡＳ−０１６８４ＵＳＣ）；
２００５年５月１９日に出願されたポールＢ．パトリック氏等の「DYNAMICALLY CONFIGURABLE SERVICE ORIENTED ARCHITECTURE」と題する米国特許出願（代理人ドケットＮｏ．ＢＥＡＳ−０１６８４ＵＳＤ）；
２００５年５月１９日に出願されたポールＢ．パトリック氏等の「PROGRAMMABLE MESSAGE PROCESSING STAGE FOR A SERVICE ORIENTED ARCHITECTURE」と題する米国特許出願（代理人ドケットＮｏ．ＢＥＡＳ−０１６８４ＵＳＥ）；
２００５年５月１９日に出願されたポールＢ．パトリック氏等の「SERVICE PROXY DEFINITION」と題する米国特許出願（代理人ドケットＮｏ．ＢＥＡＳ−０１６８４ＵＳＦ）；
２００５年５月１９日に出願されたポールＢ．パトリック氏等の「DYNAMICROUTING IN A SERVICE ORIENTED ARCHITECTURE RULES」と題する米国特許出願（代理人ドケットＮｏ．ＢＥＡＳ−０１６８４ＵＳＧ）；
２００５年５月１９日に出願されたポールＢ．パトリック氏等の「DYNAMICPUBLISHING IN A SERVICE ORIENTED ARCHITECTURE」と題する米国特許出願（代理人ドケットＮｏ．ＢＥＡＳ−０１６８４ＵＳＨ）；
２００５年５月１９日に出願されたポールＢ．パトリック氏等の「SERVICE ORIENTED ARCHITECTURE WITH MONITORING RULES」と題する米国特許出願（代理人ドケットＮｏ．ＢＥＡＳ−０１６８４ＵＳＩ）；
２００５年５月１９日に出願されたポールＢ．パトリック氏等の「SERVICE ORIENTED ARCHITECTURE WITH INTERCHANGEABLE TRANSPORT PROTOCOLS」と題する米国特許出願（代理人ドケットＮｏ．ＢＥＡＳ−０１６８４ＵＳＪ）；
２００５年５月１９日に出願されたポールＢ．パトリック氏等の「SERVICE ORIENTED ARCHITECTURE WITH ALERTS RULES」と題する米国特許出願（代理人ドケットＮｏ．ＢＥＡＳ−０１６８４ＵＳＫ）；
２００５年５月１９日に出願されたポールＢ．パトリック氏等の「SERVICE ORIENTED ARCHITECTURE WITH CREDENTIAL MANAGEMENT」と題する米国特許出願（代理人ドケットＮｏ．ＢＥＡＳ−０１６８４ＵＳＬ）；
２００５年５月１９日に出願されたポールＢ．パトリック氏等の「SERVICE ORIENTED ARCHITECTURE WITH MESSAGE PROCESSING PIPELINES」と題する米国特許出願（代理人ドケットＮｏ．ＢＥＡＳ−０１６８４ＵＳＭ）；
２００５年５月１９日に出願されたポールＢ．パトリック氏等の「ERROR HANDLING FOR A SERVICE ORIENTED ARCHITECTURE」と題する米国特許出願（代理人ドケットＮｏ．ＢＥＡＳ−０１６８４ＵＳＮ）；
２００５年５月１９日に出願されたポールＢ．パトリック氏等の「DYNAMICPROGRAM MODIFICATION」と題する米国特許出願（代理人ドケットＮｏ．ＢＥＡＳ−０１６８４ＵＳＯ）；及び
２００５年５月１９日に出願されたポールＢ．パトリック氏等の「DYNAMICPROGRAM MODIFICATION」と題する米国特許出願（代理人ドケットＮｏ．ＢＥＡＳ−０１６８４ＵＳＰ）。
【背景技術】
【０００３】
エンタープライズソフトウェアアプリケーションがウェブブラウザベースのフロントエンドと一緒に機能する必要性によりアプリケーションサーバーが開発されるに至った。アプリケーションサーバーは、フロントエンドウェブアプリケーションをバックエンドのエンタープライズアプリケーションと一体化するためのフレームワークを与える。アプリケーションサーバーからエンタープライズアプリケーション単に呼び出すことを越えて、異なるエンタープライズアプリケーションの断片を複合アプリケーションへとコンポーズする必要性が生じる。これを行い得る１つの仕方は、エンタープライズアプリケーションを、他のシステムがアクセスできる再使用可能なサービスのセットとして露出させることである。しかしながら、エンタープライズアプリケーションは、通常、多数のアプリケーションプラットホーム及び異種環境において展開される。これらのファクタは、コンポーズの努力を独占的で且つプログラム駆動されるものとし、もろくて高価な一体化を生じさせる。従って、サービスを動的にコンポーズすると共に、それらの間に生じ得る非両立性を取り扱う柔軟性のあるインフラストラクチャーが要望される。
【発明を実施するための最良の形態】
【０００４】
本発明は、同様の要素が同じ参照番号で示された添付図面に一例として示すが、これに限定されるものではない。この開示において実施形態を言及するときには、必ずしも同じ実施形態ではなく、そのような言及は、少なくとも１つを意味する。特定の実施について説明するが、これは、説明上のものであることを理解されたい。当業者であれば、本発明の範囲及び精神から逸脱せずに他のコンポーネント及びコンフィギュレーションを使用できることも明らかであろう。以下の説明において、本発明の完全な説明を与えるために多数の特定の細部について述べる。しかしながら、本発明は、これら特定の細部を伴わずに実施できることが当業者に明らかであろう。他の場合には、本発明を不明瞭にしないために、良く知られた特徴は、詳細に説明しない。
【０００５】
図１ａを参照すれば、説明上、このシステムは、メッセージブローカー、ウェブサービス、ビジネス対ビジネス（Ｂ２Ｂ）サービスゲートウェイ、及びサービスマネージメントコンセプトを、ランタイムコンフィギュレーション情報ディレクトリー／レポジトリー１０６及びコンソール１０４を中心とする組み合せへと融合することを表わすサービスバス１００を備えている。このサービスバスは、使い易いコンフィギュレーション駆動の中間物で、次のことを、効率的に、且つ高い利用性、拡張性及び信頼性で達成する（制限なく）。
【０００６】
−エンベローププロトコル、トランスポートプロトコル、セキュリティ機構、ペイロードコンテンツ、一方向及び要求／応答パラダイム、同期及び非同期通信、ポイント対ポイント、及びパブリッシュ／サブスクライブのエリアにおいて、どんなメッセージを送信者１１４が送信するかと、受信者１１６が何を期待するかとの間のギャップを橋絡する。
−多行先パブリッシュ、コンテンツベースのルーティング、認証及び許可、並びに証明書マッピングのような（これらに限定されないが）タスクを実行するための付加的なコンピューティング能力を与える。
−メトリック収集及び表示、警告表示、追跡事象収集及び使用、メッセージアーカイブ及びサービスレベルアグリーメント（ＳＬＡ）マネージメントを伴うモニタリング能力を与える。
【０００７】
図１ｂは、一実施形態によるシステムを示す。一実施形態において、このシステムは、クライアントとサービスとの間の中間物として働くことのできるサービスバス１００を備えている。当業者であれば、本開示は、特定形式のサービス又はサービス技術に限定されず又はそれに依存しないことが明らかであろう。既に知られているもの及びこれから開発されるものを含む多数のサービス形式／技術が、本開示の範囲及び精神に完全に包含される。サービスバスへのメッセージは、トランスポート１０８に到着し、そして例えば、メッセージをルーティングし及び／又はパブリッシュすべき行先、メッセージに対して実行すべき変換、及び／又はセキュリティ処理を決定するように処理することができる。次いで、メッセージは、サービス又は別のサービスバスに向けられたトランスポート１１０に送出される。一実施形態では、メッセージに対する応答は、サービスバスを通る逆の経路をたどることができる。
【０００８】
一実施形態において、サービスバスは、ＢＥＡシステムズ・インクから入手できるＷｅｂＬｏｇｉｃ（登録商標）サーバーのようなアプリケーションサーバー１０２において部分的に又は完全に実施することができる。このシステムは、コンフィギュレーション情報１０６により駆動され、このコンフィギュレーション情報は、これを生成し、変更し、そして削除するためのユーザインターフェイスを与えるコンフィギュレーション／モニタリングコンソール１０４を経て特定することができる。システムの全ての観点は、動的に構成することができる。例えば、これに限定されないが、ユーザインターフェイスは、次の１つ以上を含むことができる：１）ディスプレイ装置にレンダリングされるか又はユーザの網膜に投影されるグラフィックユーザインターフェイス（ＧＵＩ）；２）サウンド及び／又はボイスコマンドに応答する能力；３）リモートコントロール装置（例えば、セルラー電話、ＰＤＡ、又は他の適当なリモートコントロール）からの入力に応答する能力；４）ジェスチャー（例えば、顔面及びその他）に応答する能力、５）同じ又は別のコンピューティング装置のプロセスからのコマンドに応答する能力；及び６）コンピュータマウス及び／又はキーボードからの入力に応答する能力。この開示は、特定のユーザインターフェイスに限定されない。当業者であれば、本開示の精神及び範囲内で多数の他のユーザインターフェイスも考えられることが明らかであろう。
【０００９】
一実施形態において、図２を参照すれば、コンフィギュレーション情報は、サービスバスをホストする１つ以上のマネージされるサーバーに対するアドミニストレータサーバー１１２によりエンタープライズ全体に配布される。これら実施形態の態様において、マネージされるサーバーは、この分野で良く知られたようにクラスターで展開することができる。コンフィギュレーション情報は、サービスバスにより高速ローカル検索するために、マネージされるサーバーへ自動的に伝播することができる。モニタリングメトリックは、集計してコンソールに表示するために、全てのマネージされるサーバーから自動的に収集することができる。
【００１０】
一実施形態において、サービスバスによりホストされるサービス（「サービスプロキシー」）と、サービスバスによりホストされずに、サービスプロキシーにより呼び出されるサービス（「外部サービス」）は、両方とも、サービスとしてモデリングされる。サービスプロキシーは、サービス（即ち、外部サービス及びサービスプロキシー）に対する代役又はその見掛け(facade)として働く。例えば、これに限定されないが、サービスは、次を含むことができる。
【００１１】
−トランスポートアドレス及びそれに関連したコンフィギュレーションを各々伴うポートと称される（エンドポイントとも称される）具体的インターフェイスのセット。一実施形態では、ポートのセットは、サービスに対する負荷バランス及びフェイルオーバー代替物を構成し、そして特性が同一である。
−一実施形態では、オペレーションによりおそらくブレークダウンされるインターフェイスにおいてメッセージ部分の構造を定義したものであるオプションのアブストラクトインターフェイス。
−具体的メッセージに対するアブストラクトインターフェイスにおけるメッセージ部分のパッケージングと、トランスポートに対するそのメッセージのバインディングとを定義するバインディング。
−ウェブサービスセキュリティ（ＷＳＳ）及びウェブサービス信頼性メッセージング（ＷＳ−ＲＭ）に対するポリシー、許可ポリシー、及びバインディングレイヤーにより透過的に実行される必要のあるアクション（例えば、ロギング）。
【００１２】
一実施形態において、ハイパーテキストトランスファープロトコル（セキュリティ）ＨＴＴＰ（Ｓ）又はＪａｖａメッセージングサービス（ＪＭＳ）トランスポートをベースとするシンプルオブジェクトアクセスプロトコル（ＳＯＡＰ）ウェブサービスに対して、アブストラクトインターフェイス、具体的インターフェイス及びバインディングのウェブサービス記述言語（ＷＳＤＬ）表示が考えられる。この実施形態の態様では、ＷＳＤＬリソース又は既存のサービスを、新たなサービスのインターフェイスを定義するためのテンプレートとして使用できる。又、ｅメール、ファイル、ＷＳ−ＲＭ及びファイルトランスポートプロトコル（ＦＴＰ）トランスポートもサポートされる。一実施形態では、サービスバスが、ファイルシステムディレクトリーを周期的にポーリングし、ファイルトランスポートの場合にファイルを処理する準備ができたかどうか決定することができる。サービスバスは、ＨＴＴＰ及びＪＭＳ非同期トランスポートに対して要求／応答及び一方向パラダイムをサポートすることができる。又、メッセージの順序付けされた配送も任意にサポートするが、これは、基礎となるトランスポートがそれをサポートする場合である。更に別の実施形態では、サービスバスは、外部マークアップ言語(eXternal Markup Language)（ＸＭＬ）、非ＸＭＬ（ＭＦＬで記述される構造）、アタッチメント（ｅメール）を伴うバイナリー多目的インターネットメールエクステンション（ＭＩＭＥ）、及びＳＯＡＰパッケージングをサポートする。
【００１３】
サービス／サービスプロキシープロセスは、同じバインディングに対して多数のポートをもつことができる。これらのポートは、負荷バランス及びフェイルオーバー代替物として使用することができる。サービス／サービスプロキシーは、そのポートに対して使用するための負荷バランスポリシーを定義することができる。一実施形態では、これらポリシーは、ラウンドロビン及びランダム（重み付けされた又は非重み付けの）を含むことができる。これらポートは、負荷バランス行先として働くが、失敗の際にはフェイルオーバー代替物として働くこともできる。利用性の高い負荷バランス機構として２つのコンセプトが一緒に結合される。
【００１４】
又、サービスプロキシーは、失敗時の再試みポリシー、（要求／応答に対する）時間切れポリシー、及びそのインターフェイスにおけるメッセージに適用するセキュリティポリシーを定義することもできる。これは、サービスレベルで指定することもできるし（全てのメッセージに適用する）、又はサービスのオペレーションに対して個々のメッセージで指定することもできる。
【００１５】
一実施形態において、サービスは、１つ以上のカテゴリー機構により分類される。例えば、カテゴリーは、鍵となる名前であり、そしてカテゴリー値は、その鍵となる名前に対する値である。サービスは、多数のカテゴリー名に対して多数の値をもつことができる。カテゴリーは、発見目的に有用である。鍵となる名前と、許された値のハイアラーキーとを定義する多数の良く知られた存在論（又はカテゴリー機構）がある。この実施形態の態様において、カテゴリーハイアラーキーのリーフ値は、サービスを分類するのに使用される。一実施形態では、サービス消費者をサーチのために分類することができる。サービス消費者は、組織又はアプリケーションでよく、そしてメッセージを送信する（又は同期応答を受信する）ことができる。別の実施形態では、サービス消費者は、証明書に関連付けられ、そしてユーザに結び付けられ、従って、許可のための役割に属することができる。
【００１６】
一実施形態では、サービスプロバイダーと称される組織又はアプリケーションによりサービスのセットを提供することができる。サービスのためのプロバイダーを定義することは任意であり、スタンドアローンサービスをもつことができる。例えば、これらは、エンタープライズの内部サブ組織でもよいし、外部パートナー組織でもよいし、又は個々のアプリケーションでもよい（意味論はユーザまで）。又、サービスプロバイダーは、サーチのためのサービスと同様に分類することもできる。サービスプロバイダーは、証明書に関連付けられ、そしてユーザに結び付けられ、従って、許可のための役割に属することができる。サービスプロバイダーは、メッセージを送信及び受信することができる。
【００１７】
一実施形態において、サービスプロキシーの実施は、少なくとも１つのメッセージ処理パイプライン定義を含む。例えば、これは、要求パイプラインの定義及び応答パイプラインの定義を含むことができる。パイプラインは、外部（又は別のプロキシー）サービスを呼び出す前にサービスプロキシーへの要求メッセージに対してどんなアクションが実行されるか、及びサービスプロキシーがクライアントに応答を返送する前にサービスプロキシーにより呼び出されたサービスからの応答に対してどんな処理が実行されるかを指定するメッセージ処理ノードである。各パイプラインは、一連のステージを含むことができる。ステージは、パイプラインに適合し得るプログラムインターフェイス及び／又はプロトコルを実施する。パイプラインに供給されるメッセージには、パイプラインのステージによりアクセス又は変更できるメッセージコンテクスト変数のセット（メッセージコンテンツを含む変数を備えた）が添付される。
【００１８】
説明上、共通のパイプラインステージは、次のものを含む。
−変換ステージは、コンテクストに影響する実行されるべき変換を選択するためにフロー制御「ｉｆ」構造をネスト状にすることを許す。ウェブサービスコールアウト又はデータベースルックアップは、出力コンテクスト変数をセットするためのＸＭＬ問合せ（ＸＱｕｅｒｙ）又は拡張可能なスタイルシート言語変換（ＸＳＬＴ）変換に対する代替物となり得る。
【００１９】
−ルーティングステージは、メッセージをルーティングするための単一エンドポイント及びオペレーションを定義するために「ｉｆ」構造及び「ｃａｓｅ」構造を結合する（及びネスト状にする）ことを許す。コンテクスト変数に影響する変換のセットは、メッセージが各エンドポイントへパブリッシュされる前に定義することができる。ウェブサービスコールアウト又はデータベースルックアップは、コンテクスト変数をセットするためのＸＱｕｅｒｙ又はＸＳＬＴ変換に対する代替物となり得る。
【００２０】
−パブリッシュステージは、メッセージをパブリッシュするためのエンドポイント及びオペレーションのセットを定義するために「ｉｆ」構造及び「ｃａｓｅ」構造を結合する（及びネスト状にする）ことを許す。コンテクスト変数に影響する変換のセットは、メッセージが各エンドポイントへパブリッシュされる前に定義することができる。ウェブサービスコールアウト又はデータベースルックアップは、コンテクスト変数をセットするためのＸＱｕｅｒｙ又はＸＳＬＴ変換に対する代替物となり得る。コンテクストへの変化は、パブリッシュされる各エンドポイントに対して分離され、そしてパイプラインによるその後の処理に影響しなくなる。
【００２１】
−一実施形態では、ＷＳＳ処理及び許可をバインディングレイヤーにおいて実行することができる。
−追跡ステージは、追跡レコードをユーザ定義情報と共に書き込むのを許し、従って、追跡システムを使用して、ユーザ定義基準によりサーチすることができる。
−アーカイブステージは、経歴及びレコード保持の目的でアーカイブへメッセージを書き込む。
−ロギングステージは、選択されたコンテクストをデバッグの目的でシステムログへロギングするのを許す。
−検証ステージは、ドキュメントをＭＦＬスキーマのＸＭＬに対して検証する。
−カスタムステージは、パイプラインに適合するプログラムインターフェイス及び／又はプロトコルを実施する。
【００２２】
図３は、一実施形態に基づくメッセージ処理パイプラインを示す。オペレーションパイプラインは、メッセージのコンテンツにより指示されたオペレーションに基づいてメッセージを処理することができる。一実施形態では、オペレーションの決定は、ユーザ選択基準により実行される。各パイプラインは、１つ以上のステージ（例えば、３０２、３０４、３０８、３１０）を含むことができる。単一サービスレベル要求パイプライン３００は、複数のオペレーションパイプライン３０６及び３１２へと分岐することができる。応答処理は、当該オペレーションパイプライン（３１４、３１６）でスタートし、これは、次いで、単一サービスレベル応答パイプライン３１８へと接合する。一実施形態では、一方向オペレーションが呼び出される場合に、応答パイプラインは、空のメッセージで実行される。これは、サービスプロキシーに対して応答を構成するのを許し、従って、要求／応答と一方向オペレーションとの間の橋絡が可能になる（例えば、サービスプロキシーの入力は、一方向であるが、その出力は、要求／応答であり、又はその逆にもなり得る）。サービスプロキシーは、呼び出されたサービスからの応答を吸収するか、又はクライアントに対してそれを発生するかのいずれかである。
【００２３】
一実施形態では、要求パイプライン及び応答パイプラインの両方と、他のメッセージ処理ノードとにわたってコンテクストが共有され、そしてその値が、個々の要求／応答メッセージを含む。この実施形態の態様において、コンテクストは、予め定義されたＸＭＬ変数のセットである。コンテクストに対して新たな変数を動的に追加及び削除することができる。予め定義されたコンテクスト変数は、例えば、メッセージに関する情報、トランスポートヘッダー、セキュリティプリンシパル、現在サービスプロキシーに対するコンフィギュレーション情報、及びサービスプロキシーにより呼び出された一次ルーティング及びサブスクリプションサービスに対するコンフィギュレーション情報を有するが、これらに限定されない。一実施形態では、ステージによるＸＱｕｅｒｙ／Ｘｕｐｄａｔｅ表現によりコンテクストを読み取って変更することができる。
【００２４】
更なる説明上、コンテクストは、変数＄ｈｅａｄｅｒ、＄ｂｏｄｙ、及び＄ａｔｔａｃｈｍｅｎｔｓを含むことができる。これらは、ＳＯＡＰヘッダー、ＳＯＡＰ本体コンテンツ、及びＭＩＮＥアタッチメントを各々含むラッパー変数である。コンテクストは、全てのメッセージがＳＯＡＰメッセージで、非ＳＯＡＰメッセージがこのパラダイムにマップされるという印象を与える。バイナリー又はＭＦＬデータの場合に、＄ａｔｔａｃｈｍｅｎｔｓ又は＄ｂｏｄｙのドキュメントを表わすＸＭＬエレメントは、独特な識別子で実際のドキュメントを指す。ＳＯＡＰ ＲＰＣの場合には、本体コンテンツが、それ自体、タイプ分けされたＲＰＣパラメータを含むラッパーエレメントである。
【００２５】
一実施形態において、システムは、デザイン時に必要に応じて使用できる内蔵型システムを有する。デザイン時に条件又は変換のＸＱｕｅｒｙ表現を生成するときには、ＸＱｕｅｒｙを容易に生成する助けとなるように変数をエディタにおいて１つ以上のタイプであると宣言することができる。更に別の実施形態では、ＸＭＬスキーマ、ＭＦＬ又はＷＳＤＬリソースにおいてタイプを指定することができる。このタイプ宣言プロセスは、タイプ分けされるべき変数の性質が分かる（タイプのエレメント又はタイプそれ自体に対するラッパーである）。又、これは、＄ｂｏｄｙにおいてＳＯＡＰ ＲＰＣパラメータ又はドキュメントに容易にアクセスするための支援も与える。
【００２６】
一実施形態において、ステージは、そのステージにエラーが生じた場合に実行するための一連のステップをもつことができる。この一連のステップは、そのステージに対するエラーパイプライン又はハンドラーを構成する。更に、全パイプライン又は全サービスプロキシーに対してエラーハンドラーを定義することもできる。存在する最低範囲のエラーハンドラーは、エラーの際に呼び出される。このエラーハンドラーは、メッセージをエンドポイントへパブリッシュさせ、サービスプロキシーの呼び出し者へ返送されるべきエラー応答メッセージを公式化し、メッセージをログし、コンテクストを変更した後も継続させ、又は例外を引き起こすことを許す。例外を引き起こすと、次に高い範囲のエラーパイプラインへ制御を移管することができる。
【００２７】
図４は、一実施形態による前及び後パイプラインメッセージ処理を示す図である。要求の処理は、インバウンドトランスポート４０２の処理、インバウンドバインディングレイヤー４０４の処理、パイプライン実行４０６、アウトバウンドバインディングレイヤー４０８の処理、及びアウトバウンドトランスポート４１０の処理で構成される。これら実施形態の態様において、バインディングレイヤーは、実行されるべき幾つかの処理、例えば、メッセージをコンテクスト変数へ／からマッピングし、メッセージをパッケージング及びアンパッケージングし、そしてＷＳＳセキュリティ及び許可を実行するといった処理を自動化する。一次ルーティング行先及びパブリッシュ行先の両方をこのパラダイムにおいて動作させることができる。一実施形態において、一次ルーティングエンドポイントが呼び出された後に、応答パイプライン処理は、同様のモデルをたどる。更に別の説明において、パイプラインステージからのウェブサービスコールアウト４２０は、バインディングレイヤー４１６を通過した後に、トランスポートレイヤー４１８を通過する。一実施形態では、コールアウト応答は、逆の経路をたどる。
【００２８】
一実施形態において、ユーザは、人間、組織又はプロセスのいずれかであるセキュリティプリンシパルである。ユーザは、ユーザインターフェイス（コンソールユーザ）又はメッセージングインターフェイス（ユーザがサービス消費者又はプロバイダーとしてモデリングされる）のいずれかを呼び出すことができる。サービス消費者及びプロバイダーは、そのプロバイダー／消費者からのメッセージの認証に対してユーザに関連付けることができる。ユーザは、グループに属することができ、そしてグループも、グループに属することができる。グループ及びユーザは、リソースへのアクセス権が指定されるユニットであるロールに属することができる。一実施形態では、システム内のリソース、プロバイダー、消費者及びサービスは、名前の競合を回避するだけでなく、ある部門に属するリソース及びサービスを編成しそしてそれらをサーチする便利な仕方を与えるために、フォルダーのハイアラーキーを各々伴うプロジェクトのセットに編成することができる。
【００２９】
一実施形態において、コンソールは、タスクレベル許可をサポートする。説明上、サービスバスコンソールユーザ又はプロセスは、予め定義された次のロールの１つ以上において動作することができる。
−一体化アドミニストレータは、サービスバススーパーユーザであり、何かをすることができる。
−一体化オペレータは、コンソールを使用して、サービスバスアクティビティをモニタし、メッセージの追跡を実行し、そしてサービスを保留／再開すると共に、それらの動作時間を変更することができる。
−一体化モニタは、全てのものへ完全な読み取りアクセスをし、そしてリソース、サービス、プロバイダー、消費者又はプロジェクトをエクスポートすることができる。
−一体化デプロイヤーは、全てのものへ完全な読み取りアクセスをし、そしてリソース、サービス、プロバイダー、消費者又はプロジェクトを生成し、削除し、又はインポート／エクスポートすることができる。
−一体化セキュリティアドミニストレータは、ＡＣＬ、証明書、キーストローク、ユーザ、グループ及びロールを読み取り、生成し、削除し、編集することができる。
【００３０】
一実施形態において、リソースは、プロセス／エンティティの再使用可能な共通定義及び／又は記述（例えば、そのエンティティに対するコンフィギュレーション情報）である。リソースは、通常、多数のサービスにより使用され、そしてエンタープライズ又は部門にわたる標準的な定義又は記述である。リソースは、例えば、カテゴリー機構、ＭＦＬスキーマ、ＸＳＤスキーマ、ＸＱｕｅｒｙマップ、ＸＳＬＴマップ、ＷＳＤＬインターフェイス、及びＷＳ−ポリシーファイルである。カテゴリー機構は、単一カテゴリー名と、このカテゴリー名に対する値のハイアラーキーセットとを定義する。サービス、プロバイダー及び消費者は、登録された機構を使用して分類することができる。それらは、カテゴリー機構に対する多数のリーフ値、又は多数のカテゴリー機構からのリーフ値で分類することができる。一実施形態において、システムの全てのリソースを名前でルックアップすることができる。更に別の実施形態では、カテゴリー機構にサーチフィルタを適用することによりリソースをルックアップすることができる。
【００３１】
スキーマは、原始データ又は構造化データのタイプを記述する。ＭＦＬスキーマは、非ＸＭＬデータのタイプを記述する。ＸＭＬスキーマは、ＸＭＬのタイプを記述する。ＸＭＬスキーマのタイプは、他のスキーマのファイルをインポート又は含むことができる。変換マップは、２つのタイプ間のマッピングを記述する。ＸＳＬＴマップは、ＸＳＬＴ規格を使用してＸＭＬデータに対するマッピングを記述する。ＸＱｕｅｒｙマップは、ＸＱｕｅｒｙ規格を使用してＸＭＬ及び非ＸＭＬ（ＭＦＬ）データに対するマッピングを記述する。
【００３２】
ＷＳＤＬインターフェイスは、サービスインターフェイスのテンプレートであり、これは、そのインターフェイスにおけるオペレーションを含むサービスのアブストラクトインターフェイスと、オペレーションシグネチャーにおけるメッセージ部分の形式とを記述する。又、任意であるが、メッセージ（パッケージング）へのメッセージ部分のバインディング、及びトランスポートへのメッセージのバインディングも記述する。又、任意であるが、サービスの具体的インターフェイスも記述する。ＷＳ−ポリシーは、セキュリティ及び信頼性あるメッセージングポリシーを記述する。これは、どんなアルゴリズムを使用してメッセージに何をサイン又は暗号化すべきか記述する。又、受信時にメッセージに対してどんな認証メカニズムを使用すべきかも記述する。
【００３３】
図５は、一実施形態によるコンポーネントアーキテクチャーを示す図である。サービスバスは、アドミニ(admin)サーバー５０２としても働く単一サーバーに配備することもできるし、又はサーバーのクラスター（例えば、クラスターは、マネージされるサーバー５００のクラスターセットで構成される）に配備することもできる。コンフィギュ(config)フレームワークコンポーネント５０４は、オブジェクト及びファイル完全性保護、キャッシング及びインデクシング、参照の完全性、及びコンフィギュレーション伝播と共に、コンフィギュレーション情報に対するＣＲＵＤ（生成、読み取り、更新、削除）能力を与えることができる。アドミニサーバーは、コンフィギュレーション情報を、マネージされるサーバーへ伝播させることができる。
【００３４】
一実施形態において、タスクフレームワークコンポーネント５０６は、個々のコンフィギュ(config)オブジェクトに対する多数のＣＲＵＤオペレーションより成るコンフィギュオペレーションであるタスク又は複合タスク（タスクのタスク）に対してオペレーションアンドゥ及びシリアル化能力を与えることができる。コンフィギュ伝播の単位はタスクであり、そしてタスクは、特殊なコードの実行を含むと共に、マネージされるサーバーにおけるＥＡＲ又はＷＡＲの配備を含むことができ（自動的データベースか、又はトランスポートのための軽量ｗｅｂａｐｐ配備に主として使用される）、そして粒子の粗い同時制御をサポートする（タスクの実行がシリアル化される）。
【００３５】
一実施形態において、集計フレームワークコンポーネント５２４は、メトリックを収集しそしてそれをクラスター規模の集計のためにアドミニサーバーへ伝播する能力を与えることができる。一実施形態では、集計されるデータは、データが古いほど、より粗くなる（期間に関して）。例えば、最新の１時間については、集計インターバルが５分である。それ以前の、昨日については、集計インターバルが１時間である。それ以前の、先週については、集計インターバルが１日である、等々となる。
【００３６】
一実施形態において、警告システム５１０は、集計されたメトリックを分析して、サービスレベルアグリーメント（ＳＬＡ）ルールに違反しているかどうか決定し、そしてもしそうであれば、警告を発する。一実施形態では、警告の行先は、ｅメール、ウェブサービス、ＷＬＩロガー、待ち行列等である（必要に応じて、更に多く追加できる）。
【００３７】
一実施形態において、コンソールユーザインターフェイス（ＵＩ）コンポーネント５１２は、ポータルと一体化されるＪＳＰベースのポートレットである。コンソールＵＩは、コンソールにおけるモニタリング及びコンフィギュレーションの両方をサポートする。
【００３８】
一実施形態において、外部及びサービスプロキシーコンフィギュコンポーネント５１４は、プロキシー又は外部サービスインターフェイスに対するアブストラクト、具体的、セキュリティ及びアクセスポリシー、並びにバインディング情報を定義する。サービスプロキシーは、サービスバスサーバーによりホストされる中間物であり、一方、外部サービスは、他の何らかのサーバーに存在するメッセージがルーティングされるところの外部エンドポイントである。これは、サービスプロキシーとして、パイプラインアーキテクチャーに基づき入力及び出力メッセージに対してサービスプロキシーにより実行される順次メッセージ処理を定義する。又、これは、非常に多数のサービスが存在するときにサーチ能力も与える。
【００３９】
ユーザ及び証明書コンフィギュコンポーネント５１６は、属性を伴うＵＩ及びメッセージングユーザと、一実施形態に基づきそのユーザと共に進行する証明書との両方を定義することができる。この実施形態の態様において、ユーザは、ハイアラーキー式にグループへと編成することができ、そしてグループ及びユーザは、リソースへのアクセスが許可されるロールに属することができる。メッセージングユーザは、メッセージを送信できるサービス消費者であるか、又はメッセージを送信又は受信するサービスを提供するサービスプロバイダーである。
【００４０】
一実施形態において、リソースコンフィギュコンポーネント５１８は、テンプレートＷＳＤＬ（ウェブサービス定義言語）、ＷＳセキュリティポリシー、スキーマ、存在論（サービス及びサービスプロバイダーを分類するカテゴリー機構）、及び多数のサービスによりレバレッジすることのできる変換マップのような（これらに限定されない）共有リソースを定義するのに使用できる。又、これは、非常に多数のサービスが存在するときにサーチ能力も与える。
【００４１】
一実施形態において、モニタリングコンポーネント５２０は、警告及びメトリックを示すためにサービスバスシステムに対するモニタリングＵＩを与える。
【００４２】
一実施形態において、インポート／エクスポートコンポーネント５２２は、サービスバスインストレーションとインストレーションとの間でのサービス及び他のリソースの移動を許す。デザイン、ステージ及びプロダクションは、全て、別々のバニラサービスバスインストレーションである。インポートは、環境特有のコンフィギュレーションパラメータ、及びインポートされたオブジェクトが既に存在する場合に使用すべき解決策（置き換え又は保持）の指定を許す。又、これは、インポートされたオブジェクトにおける非分析参照を、同じタイプの既存のオブジェクトにリンクすることにより、分析することも許す。
【００４３】
一実施形態において、トランスポート及びトランスポートＳＰＩ５２６のコンポーネントは、新たなトランスポートをプラグインするためのフレームワークを与えると共に、ＨＴＴＰ（Ｓ）、ＪＭＳ、ｅメール、ＦＴＰ、ファイル、ＷＳ−ＲＭ（ウェブサービス信頼性メッセージング）、及びボックスからのタイマー事象トランスポートもサポートする。可能であれば、ストリーミング、信頼性、メッセージ順序付け、要求／応答及び一方向メッセージがサポートされる。
【００４４】
一実施形態において、パイプラインランタイム及びステージＳＰＩ５２８のコンポーネントは、ユーザにより新たなカスタムステージをプラグインするためのフレームワークを与えると共に、サービスプロキシーにおける要求及び応答パイプラインを経てコンテクストマネージメント及びメッセージフローを与える。
【００４５】
一実施形態において、サービスプロキシーパイプラインは、バインディングレイヤー５３０を経ていずれかの端においてトランスポートとインターフェイスすることができ、バインディングレイヤーは、サービスプロキシー（インバウンド）で定義されたポリシーと、呼び出された（アウトバウンド）外部又はサービスプロキシーとに基づいて、メッセージのパッケージング、ロギングＷＳＳ処理及び許可を取り扱うことができる。
【００４６】
一実施形態において、エンドポイントは、ユニフォームリソース識別子（ＵＲＩ）に基づくアドレスを有する。例えば、サービスは、サービスディレクトリーに登録されたインバウンド又はアウトバウンドエンドポイントである。例えば、これは、関連するＷＳＤＬ、セキュリティ設定、等をもつことができる。ルーターは、パイプラインの命名された集合である。パイプラインは、非分岐の一方向処理経路を表わす命名された一連のステージである。ステージは、変換、ルーティング等のユーザ構成の処理ステップである。パイプラインは、メッセージ処理グラフの一部分であるメッセージ処理ノードである。メッセージがインバウンドエンドポイント（サービスプロキシー）からアウトバウンドエンドポイント（通常、外部サービス又は別のサービスプロキシー）へシステムを通していかに流れるかの非常に基本的な概要を以下に示す。
トランスポートレイヤー → バインディングレイヤー → メッセージ処理グラフ → バインディングレイヤー → トランスポートレイヤー
【００４７】
一実施形態において、メッセージ処理グラフは、メッセージの処理及び操作を実行できるところである。バインディング及びトランスポートレイヤーは、主として、通信及びメッセージのパッキング／アンパッキングを取り扱うが、これらレイヤーにおいてメッセージの処理及び操作を行うこともできる。
【００４８】
一実施形態において、トランスポートレイヤーは、クライアント及び行先エンドポイントとの通信を取り扱う役割を果たす。これは、ＨＴＴＰ及びＪＭＳのような種々の通信プロトコルをサポートできると共に、エンドポイントＵＲＩや関連トランスポートヘッダーのようなものを含むコンフィギュレーション情報を発生する役割を果たす。メッセージコンテンツについては、トランスポートレイヤーは、主として、入力及び出力ストリームの形態の生のバイト、及びＪＭＳメッセージクラスのインスタンスのようなトランスポート特有のメッセージオブジェクトを取り扱う。別の実施形態では、トランスポートレイヤーは、単に、システムへ及びシステムからメッセージを得るだけであり、即ちメッセージコンテンツの操作は何ら実行しない。
【００４９】
一実施形態において、バインディングレイヤーは、主として、メッセージをパッキング及びアンパッキングする役割を果たす。又、これは、ほとんどバイトストリーム取り扱うトランスポートレイヤーと、よりリッチなメッセージコンテクスト表示を使用できるルーターとの間の中間物として働くこともできる。性能上の理由で、バインディングレイヤーは、メッセージのアンパッキングやデータのアンマーシャリング(unmarshaling)を、それが必要になるまで回避するために、オンデマンド処理を使用することができる。
【００５０】
別の実施形態では、バインディングレイヤーは、セキュリティ処理が実行される場所でもある。インバウンド側では、セキュリティ処理は、受信側サービスプロキシーのコンフィギュレーションにより決定される。アウトバウンド側では、処理は、行先サービスのコンフィギュレーションにより決定される。別の実施形態では、バインディングレイヤーは、サービス特有のもので、そのタスクを実行するためにコンフィギュレーションパラメータに依存する。
【００５１】
一実施形態において、ルーターは、サービスプロキシーの要求及び応答ロジックを実施する役割を果たす。要求及び応答経路は、メッセージコンテンツを操作する一方向メッセージ処理パイプラインノードを使用して実施することができる。分岐ノードを使用して、多数のパイプライン経路のいずれをたどるべきか決定することにより、条件付実行が可能となる。要求経路は、通常、別のサービス又はサービスプロキシーに要求をディスパッチするルーティングノードで終了する。そのサービスからの応答で応答経路処理が開始され、その後、サービスプロキシークライアントへ応答を返送することができる。応答は、メッセージ処理グラフを経て逆方向に進行する。
【００５２】
一実施形態において、パイプラインノードは、要求、応答及びエラーの３つのカテゴリーの１つにタイプ分けすることができる。要求パイプラインは、ルーターの要求経路を処理するのに使用され、一方、応答パイプラインは、応答経路を処理するのに使用される。エラーパイプラインは、エラーハンドラーとして使用され、以下の別のセクションで詳細に説明する。パイプラインの目的を示すのとは別に、タイプは、どのステージがパイプラインに現われてもよいか制限するのに使用されてもよい。このような制限は、個々のステージの実施に委ねられる。
【００５３】
図６ａ及び６ｂは、一実施形態によるメッセージ処理グラフである。上述したように、ルーターは、メッセージ処理パイプラインを使用してサービスプロキシーの要求／応答ロジックを実施することができる。要求及び応答パイプラインノードを一緒に対にし（パイプライン対ノード）、そしてそれらを論理的ツリー構造又はメッセージ処理グラフへと編成することにより、要求及び応答経路が生成される。一実施形態では、ノードは、メッセージ処理グラフに適合するプログラムインターフェイス及び／又はプロトコルを実施する。分岐ノードは、条件付実行を許し、そして分岐の終りにあるルーティングノードは、要求／応答ディスパッチを実行する。一実施形態では、メッセージ処理グラフは、サービスプロキシー振舞いの明確な概要を許し、ルーティングアクション及び分岐条件の両方を全デザインの明確な部分とするのであって、パイプラインステージ内の奥深くにそれらを埋めるのではない。要求メッセージは、メッセージ処理グラフにより第１方向に経路をたどる。それに関連した応答は、メッセージ処理グラフにより逆方向に経路を進行することができる。
【００５４】
一実施形態において、メッセージ処理グラフは、３つのトップレベルコンポーネントの１つ以上のインスタンスを含むことができる（図６ａ−６ｂ）。
−パイプライン対ノード（「ＰＰ」）
−分岐ノード（「ＢＲ」）
−ルーティングノード（「ＲＴ」）
【００５５】
図６ａは、単一パイプライン対ノード６００と、単一ルーティングノード６０２とを有していて、これが、サービス６０３へメッセージを転送するように構成されたメッセージ処理グラフを示す。パイプライン対ノードは、単一要求及び単一応答のパイプラインノードを１つのトップレベルエレメントへと一緒に結合する。別の実施形態では、パイプライン対ノードは、メッセージ処理グラフに１つの直接的な子孫を有してもよい。要求メッセージの処理中に、パイプライン対ノードに訪問したときに要求パイプラインノードを実行することができる。応答処理のために経路を逆行するときには、応答パイプラインノードを実行することができる。
【００５６】
ルーティングノードは、一実施形態によりサービスとの要求／応答通信を実行するのに使用できる。この実施形態の態様において、ルーティングノードは、サービスプロキシーに対する要求処理と応答処理との間の境界を表わす。ルーティングノードが要求メッセージをディスパッチするときには、要求処理が終わったと考えられる。ルーティングノードが応答メッセージを受信すると、応答処理が開始される。ルーティングノードは、それ自体、条件付きルーティングと、アウトバウンド及び応答変換とをサポートする。条件がルーティングノード内に現われるか又は分岐ノードとしてメッセージ処理グラフに現われるかは、ユーザ次第である。一実施形態では、ルーティングノードは、グラフに子孫をもたない。
【００５７】
図６ｂは、一実施形態により分岐ノードを伴うメッセージ処理グラフを示す。分岐ノード６０６は、多数の考えられる経路６０８の厳密に１つを下るように処理を進めるのを許す。これら実施形態の態様において、分岐は、簡単であるが独特のストリング値で各分岐路がタグ付けされた簡単なルックアップテーブルにより推進することができる。メッセージコンテクストにおける変数は、そのノードに対するルックアップ変数として指定することができ、その値を使用して、どの分岐路をたどるか決定することができる。ルックアップ変数の値に一致する分岐路がない場合には、デフォールト分岐路をたどる。ルックアップ変数の値の設定は、分岐ノードに到達する前に行うことができる。分岐ノードは、グラフにおいて、デフォールト分岐路を含む各分岐路に１つづつ、多数の子孫をもつことができる。
【００５８】
一実施形態において、要求処理は、サービスプロキシーにより要求が受け取られたときにメッセージ処理グラフのルート（根）において開始される。あるポイントにおいて、要求メッセージがパイプライン対ノードへ運ばれ、そこで、処理を実行するために要求パイプラインノードが呼び出される。要求メッセージが分岐ノードへ運ばれると、要求は、更に、選択された分岐路に沿って運ばれる。メッセージがルーティングノードに運ばれると、アウトバウンド／応答変換と共にルーティングが実行される。サービスプロキシーにより応答メッセージが受信されると、要求メッセージがたどった経路とは逆の経路に沿ってそれが運ばれる。ルーティングノードをもたずに単純に終わる要求経路に対して同じことが生じ、即ちサービスバスが応答処理を開始しそしてグラフまで戻るが、応答を待機することはない。応答の処理中に、パイプライン対ノードにヒットしたときに、応答パイプラインノードが実行される。分岐ノードにヒットしたときには、ｎｏ−ｏｐとして処理され、そして分岐路に先行するエレメントに応答が搬送される。応答が最終的にグラフのルートに到達すると、要求側クライアント（別のサービス又はサービスプロキシーでよい）へ応答が返送される。
【００５９】
一実施形態において、メッセージ処理グラフのルートに何らかのエレメントが現われてもよい。最も簡単なルーターデザインの１つは、全グラフを代表してその頂部のみにルーティングノードをもたせることである。又、どんな２つのエレメントを一緒に連鎖するかについては何ら制約がない。例えば、２つのパイプライン対ノードは、それらの間に分岐ノードをもたずに、一緒に連鎖することができる。分岐に関しては、各分岐路が異なるエレメントでスタートしてもよく、即ち１つの分岐路は、ルーティングノードで直ちに終了してもよく、別の分岐路は、パイプライン対が後に続いてもよく、そして更に別の分岐路は、子孫を何らもたなくてもよい。後者のケースでは、子孫をもたない分岐路は、その分岐路が選択された場合に応答処理が直ちに開始されることを単に意味する。しかしながら、一般に、メッセージ処理グラフは、おそらく、２つの形態になる。即ち、非オペレーションサービスの場合には、グラフは、おそらく、ルートにおける単一のパイプライン対と、それに続くルーティングノードとで構成される。オペレーションサービスの場合には、メッセージ処理グラフは、おそらく、ルートにおける単一のパイプライン対と、それに続く、オペレーションに基づく分岐ノードとで構成され、各分岐路は、パイプライン対と、それに続くルーティングノードとで構成される。
【００６０】
一実施形態において、ルーターをＷＳＤＬベースのサービスに使用することができ、従って、オペレーション特有の処理を実行する必要がある。ユーザがオペレーションに基づいて分岐ノードを手動で構成するのを要求するのではなく、システムは、オペレーションに基づいて自動的に分岐するゼロコンフィギュレーション分岐ノードを与えることができる。サービスに基づいて定義された各オペレーションに対して分岐路を生成することができ、そして分岐変数は、もちろん、＄ｏｐｅｒａｔｉｏｎとなる。
【００６１】
メッセージの処理中に種々の理由でエラーが発生し得る（例えば、ルーティング中のトランスポートエラー、変換中の検証エラー、アンマーシャリング中のセキュリティエラー、等）。典型的に、これらのエラーは、特定のステージ、ルーティングノード、又はバインディングレイヤーから発生する。というのは、これらは、ルーターロジックの大部分を実施できる場所だからである。一実施形態では、システムは、ユーザがエラーハンドラーを定義するのを許すことによりこれらのエラーを取り扱うメカニズムを与える。一実施形態では、エラーハンドラーは、本質的に、ユーザがロギング、変換及びパブリッシュのような種々のアクションを実行してエラーを適宜取り扱うのを許す別のパイプラインノードである。
【００６２】
一実施形態では、エラーハンドラーは、全サービスプロキシー並びに各パイプラインノード及びその中のステージに対して構成することができる。エラーが発生したときには、最も内側を包囲しているエラーハンドラーによりそれが取り扱われる。例えば、変換エラーが変換ステージに生じた場合には、そのステージのエラーハンドラーによりそれを取り扱うことができる。このようなエラーハンドラーが構成されていない場合には、変換ステージを含むパイプラインのものである次のレベルのエラーハンドラーによりそれを取り扱うことができる。そのエラーハンドラーが存在しない場合には、ルーターレベルエラーハンドラーによりそれが取り扱われる。それが失敗した場合には、デフォールトシステムレベルエラーハンドラーがエラーを処理できる。
【００６３】
図７は、一実施形態によるエラー取り扱いの範囲を示す。各々の包囲ボックスは、エラー取り扱い範囲を表わす。図から明らかなように、ルーティングノード７０４に生じる非捕獲エラーに対する次のレベルのエラーハンドラーは、ルーターレベル範囲７０６にある。この範囲にハンドラーがない場合には、システムレベル範囲７０８にあるハンドラーが呼び出される。それ自身のエラーを捕獲しないパイプラインステージ７００については、エラーがパイプライン範囲７０２へ伝播し得る。そこにエラーハンドラーが定義されていない場合には、エラーがシステムレベル範囲７０８へ伝播し得る。各コンポーネントは、ステージであれ、パイプラインであれ、又はルーターであれ、エラーハンドラーをもつことができる。一実施形態では、インバウンドバインディングレイヤーが特定のステージ又はパイプラインに関連していないので、バインディングレイヤーに生じるエラーは、ルーターレベルのエラーハンドラーにより取り扱うことができる。アウトバウンドバインディングレイヤーのエラーは、どんなエンティティが通信を実行するかに基づいて多数の場所で発生し得る。例えば、ルーティング中に発生するバインディングレイヤーエラーは、ルーティングノードのエラーハンドラーにより捕獲することができる。同様に、パブリッシュステージにおけるパブリッシュオペレーション中に発生するバインディングレイヤーエラーは、ステージレベルのエラーハンドラーにより捕獲することができる。一実施形態では、空の又は非構成のエラーハンドラーは、エラーハンドラーを全くもたないことと同じである。本出願人の以前の変換例では、ステージレベルのエラーハンドラーが生成されたが構成されない場合には、エラーが次のレベルのハンドラーへ「泡立って伝わる(bubble-up)」ことになる。一実施形態では、エラーハンドラーは、再投入、リプライ及び継続の３つのアクションの１つで処理を終了することができる。再投入(rethrow)アクションは、エラーが再投入され、次のレベルのエラーハンドラーにより取り扱われることを意味する。特に指示のない限り、エラーハンドラーのデフォールト振舞いは、再投入することであり、空のエラーハンドラーが不存在のエラーハンドラーのように振舞う理由はこれである。リプライ(reply)アクションは、サービスプロキシークライアントに対して応答を直ちに発生しなければならないことを意味する。更なる全てのパイプライン処理が直ちに停止され、そしてメッセージ関連コンテクスト変数の状態に基づいて応答メッセージが送信される。それ故、これらの変数を必要に応じて変換して、意味のある応答メッセージを発生するようにエラーハンドラーを構成するのは、ユーザ次第である。
【００６４】
継続アクションは、エラーが全く生じなかったかのようにパイプライン処理を続けるのに使用される。エラーが首尾良く消滅されたどんな点においても処理が継続される。これは、コンテクスト変数を固定するようにユーザがエラーハンドラーを構成することを要求し得る。というのは、それらが、ルーターの残り部分により予想されない状態になり得るからである。エラーハンドラーがエラーを消滅すると、エラーハンドラーに関連したコンポーネントが実行を首尾良く終了したかのように処理が再開する。例えば、ステージにエラーが生じそしてそのステージに関連したエラーハンドラーがエラーを消滅した場合には、パイプラインの次のステージで、そのステージが首尾良く終了したかのように処理が継続される。しかしながら、そのステージで構成されたエラーハンドラーがないか、又はエラーハンドラーがエラーを再投入する場合には、パイプラインレベルのエラーハンドラーによりそれを消滅することができる。もしそうであれば、全パイプラインが実行を首尾良く終了したかのように処理が再開する。例えば、そのパイプラインがサービス要求パイプラインである場合には、オペレーション要求パイプラインで処理を進めることができる。ルーターレベルのエラーハンドラーについては、ルーターを首尾よく実行した後の次のアクションが応答をクライアントに送信するので、「継続」が「リプライ」に等しい。
【００６５】
一実施形態において、エラーハンドラーは単に別のパイプラインであるので、他のパイプラインと同様に構成することができる。例えば、パブリッシュステージは、エラー通知を他のサービスへ送信するのに使用してもよく、変換ステージは、コンテクスト変数を変更するのに使用してもよく、等々となる。しかしながら、あるステージは、エラーハンドラーに現われることが許されない。このとき、禁止されるステージは、ルーティングステージである。
【００６６】
標準的なコンテクスト変数に加えて、更に別の態様においてエラーハンドラーに使用可能な２つの付加的なコンテクスト変数がある。これらの変数は、エラーハンドラーが呼び出されたときにセットされ、そして通常のパイプライン処理が「継続」を経て再開された場合に自動的に除去される。２つの変数は＄ｆａｕｌｔ及び＄ｆａｕｌｔＡｃｔｉｏｎである。＄ｆａｕｌｔ変数は、エラーに関する情報及びそれがどこで発生したかを保持する。この変数は、他のコンテクスト変数と共に使用されて、パブリッシュ及び変換のようなステージ内の条件付きアクションを実行することができる。エラーハンドラーは、エラーを次のレベルのエラーハンドラーまで再投入する前に＄ｆａｕｌｔのコンテンツを変更することもできる。
【００６７】
＄ｆａｕｌｔＡｃｔｉｏｎは、エラーハンドラーが実行を終了したときにどんなアクションを実行できるか決定する特殊な変数である。これは、「再投入」、「リプライ」及び「継続」の３つの値の１つをとることのできる簡単なストリング値変数である。エラーハンドラーが実行を終了すると、この変数を検査して、サービスプロキシーがエラーを再投入すべきか、クライアントに直ちに応答すべきか又は処理を継続すべきか決定する。この変数は、「再投入」の値に初期化され、従って、ユーザがエラーハンドラーのデフォールト再投入振舞いを変更したい場合には値を「継続」又は「リプライ」に変化するための変換が必要となる。
【００６８】
一実施形態において、コンテクストは、プロパティバッグである。各プロパティ（「変数」）は、名前と、それに関連する値とを有する。パイプラインにおけるメッセージの断片を表わすと共に、インバウンド及びアウトバウンドサービスエンドポイントに関する情報を保持するために、予め定義されたコンテクスト変数が使用される。パイプライン処理中に付加的な変数が導入されてもよい。一実施形態において、コンテクスト変数は、ＺＱｕｅｒｙ表現で操作することができる。パイプラインステージは、それらの振舞いの一部分としてコンテクストを内部で操作することができる。
【００６９】
以下のリストは、一実施形態におけるシステム定義コンテクスト変数を、一実施形態による簡単な説明と共に示す。
−ｈｅａｄｅｒ（ヘッダー）：ＳＯＡＰメッセージに対するＳＯＡＰヘッダーを含む。
−ｂｏｄｙ（本体）：ＳＯＡＰメッセージに対するＳＯＡＰ本体を含む。
−ａｔｔａｃｈｍｅｎｔｓ（アタッチメント）：メッセージアタッチメントを含む。
−ｉｎｂｏｕｎｄ（インバウンド）：要求を受信したサービスプロキシーに関する情報を含む。
−ｏｕｔｂｏｕｎｄ（アウトバウンド）：メッセージを送信すべきところのターゲットサービスに関する情報を含む。
−ｏｐｅｒａｔｉｏｎ（オペレーション）：呼び出されるサービスプロキシーオペレーション（もし適用できれば）を識別する。
−ｆａｕｌｔ（フォールト）：処理中に発生したエラーに関する情報を含む。
−ｆａｕｌｔＡｃｔｉｏｎ（フォールトアクション）：エラーハンドラーを実行した後にどんなアクションをとるべきか指定する。
【００７０】
一実施形態において、ｈｅａｄｅｒ、ｂｏｄｙ及びａｔｔａｃｈｍｅｎｔｓは、メッセージ処理グラフを経て流れるときのメッセージの状態を表わす。メッセージの変更は、これら変数を変更することにより達成できる。これらの変数は、サービスプロキシーにより受信されるメッセージコンテンツを使用して初期化され、そして他のサービスへディスパッチするときに（例えば、ルーティングを経て）出て行くメッセージを構成するのに使用される。メッセージに関連した全ての変数は、メッセージ処理ノード及びステージにより更新可能である。これらの変数は、完全に独立したものであり、個々に変更することができる。
【００７１】
メッセージがサービスプロキシーにより送信されると、どの変数コンテンツをメッセージに含ませるかについて選択をなすことができる。この決定は、一実施形態では、ターゲットエンドポイントがＳＯＡＰメッセージを期待するか非ＳＯＡＰメッセージを期待するかに依存する。ＳＯＡＰの場合には、ｈｅａｄｅｒ及びｂｏｄｙがＳＯＡＰエンベロープにおいて結合され、メッセージを生成する。非ＳＯＡＰの場合には、ｐａｙｌｏａｄ（ペイロード）が全メッセージである。いずれにせよ、サービスがａｔｔａｃｈｍｅｎｔｓを期待する場合には、それにより得られるメッセージ及びａｔｔａｃｈｍｅｎｔｓ変数からＭＩＭＥパッケージを生成することができる。
【００７２】
ｈｅａｄｅｒ変数は、メッセージに関連したＳＯＡＰヘッダーを含む。これは、ヘッダーをサブエレメントとしてもつ＜ＳＯＡＰ：Ｈｅａｄｅｒ＞エレメントを指す。非ＳＯＡＰメッセージ、又はヘッダーをもたないＳＯＡＰメッセージの場合には、＜ＳＯＡＰ：Ｈｅａｄｅｒ＞エレメントは空となり、サブエレメントをもたない。
【００７３】
ｂｏｄｙ変数は、コアメッセージペイロードを表わし、＜ＳＯＡＰ：Ｂｏｄｙ＞エレメントを指す。ＳＯＡＰメッセージの場合には、ＳＯＡＰ本体がエンベロープから抽出され、そして本体変数に指定される。メッセージが非ＳＯＡＰであるか、又はＸＭＬでない場合には、全メッセージコンテンツが、新たに生成される＜ＳＯＡＰ：Ｂｏｄｙ＞エレメント内に入れられる。従って、ＳＯＡＰ及び非ＳＯＡＰメッセージの両方に対するコアペイロードが、同じ変数を経て且つ同じパッケージングで（例えば、＜ＳＯＡＰ：Ｂｏｄｙ＞エレメントにラップされて）得られることになる。
【００７４】
ａｔｔａｃｈｍｅｎｔｓ変数は、メッセージに関連したアタッチメントを保持する。更に別の実施形態において、ａｔｔａｃｈｍｅｎｔｓ変数は、各個々のアタッチメントに対して１つのサブエレメントを有するＸＭＬの単一ルート断片である。これらのサブエレメントは、アタッチメントに関する情報（ＭＩＭＥヘッダーから導出された）及びアタッチメントコンテンツを含む。この実施形態の態様において、ａｔｔａｃｈｍｅｎｔｓエレメントは、次のエレメントを含むことができる。
【００７５】
−Ｃｏｎｔｅｎｔ−ＩＤ（コンテンツ−ＩＤ）：アタッチメントを識別するグローバルに独特の参照。
−Ｃｏｎｔｅｎｔ−Ｔｙｐｅ（コンテンツ−タイプ）：媒体のタイプ及びアタッチメントのサブタイプを指定する。
−Ｃｏｎｔｅｎｔ−Ｔｒａｎｓｆｅｒ−Ｅｎｃｏｄｉｎｇ（コンテンツ−転送−エンコーディング）：アタッチメントをいかにエンコードするか指定する。
−Ｃｏｎｔｅｎｔ−Ｄｅｓｃｒｉｐｔｉｏｎ（コンテンツ−記述）：コンテンツのテキスト記述。
−Ｃｏｎｔｅｎｔ−Ｌｏｃａｔｉｏｎ（コンテンツ−位置）：アタッチメントを識別するローカルに独特のＵＲＩベースの参照。
−Ｃｏｎｔｅｎｔ−Ｄｉｓｐｏｓｉｔｉｏｎ（コンテンツ−処分）：受信者がアタッチメントをどのように取り扱うべきか指定する。
−Ｂｏｄｙ（本体）：アタッチメントデータを保持する。
【００７６】
一実施形態において、ｉｎｂｏｕｎｄ及びｏｕｔｂｏｕｎｄ変数は、インバウンド及びアウトバウンドエンドポイントに関する情報を含む。ｉｎｂｏｕｎｄ変数は、要求メッセージを受信したサービスプロキシーに関する情報を含み、一方、ｏｕｔｂｏｕｎｄ変数は、メッセージを送信できるところの行先サービス（例えば、ルート）に関する情報を含む。これら変数は、同じＸＭＬスキーマを有すると共に、「サービス」、「トランスポート」及び「クライアント」サブエレメントと、サービスディレクトリーに登録されるときにエンドポイントの名前を識別する単一の「名前」属性とを含む。
【００７７】
一実施形態において、サービス変数は、サービスに関する一般的な情報を含み、そして次のエレメントを含むことができる。
ｐｒｏｖｉｄｅｒＮａｍｅ：サービスプロバイダーの名前を保持する。
ｖｅｒｓｉｏｎＧｒｏｕｐ：サービスのバージョングループを識別する。
ｖｅｒｓｉｏｎ：バージョングループに対するサービスのバージョン番号を識別する。
ｏｐｅｒａｔｉｏｎ：外部サービスで呼び出されるオペレーションの名前を識別する。
【００７８】
一実施形態において、トランスポートエレメントは、サービスに関するトランスポートの細部を含み、そして次のエレメントを含むことができる。
−ｕｒｉ：エンドポイントのＵＲＩを識別する。インバウンドの場合、これは、メッセージが到着するＵＲＩである。アウトバウンドの場合、これは、メッセージを送信するときに使用するＵＲＩであり、サービスディレクトリーに登録されたＵＲＩ値をオーバーライドする。
−ｒｅｑｕｅｓｔ（要求）：トランスポートヘッダーを含む要求に関するトランスポート特有のコンフィギュレーション情報。各トランスポートは、ＲｅｑｕｅｓｔＣｏｎｆｉｇｕｒａｔｉｏｎ情報のそれ自身の特殊化を有してもよく、従って、このエレメントの構造は、最終的に、使用されるトランスポートに依存する。
【００７９】
−ｒｅｓｐｏｎｓｅ（応答）：トランスポートヘッダーを含む応答に関するトランスポート特有のコンフィギュレーション情報。ＲｅｑｕｅｓｔＣｏｎｆｉｇｕｒａｔｉｏｎ情報と同様に、このエレメントの構造は、最終的に、使用されるトランスポートに依存する。
−ｍｏｄｅ（モード）：通信スタイルが要求（一方向）であるか、要求−応答（二方向）であるかを指示する。
【００８０】
−ｓｅｃｕｒｉｔｙＴｙｐｅ（セキュリティタイプ）：トランスポートに対するセキュリティの対応を指示する。一実施形態では、考えられる値は、「なし（ｎｏｎｅ）」、「基本的」、「一方向ＳＳＬ」及び「二方向ＳＳＬ」である。
−ａｃｃｏｕｎｔＡｌｉａｓ（アカウントエイリアス）：このエレメントは、証明書マネージャーに登録された外部サービスアカウントへのエイリアスを識別する。トランスポートレイヤーは、この値を証明書マネージャールックアップにおけるキーとして使用し、アウトバウンドＨＴＴＰ／Ｓ接続で使用するためのｕｓｅｒｎａｍｅ／ｐａｓｓｗｏｒｄ（ユーザ名／パスワード）をフェッチする。
【００８１】
−ｑｕａｌｉｔｙＯｆＳｅｒｖｉｃｅ（サービスクオリティ）：メッセージを送信するときに期待されるサービスのクオリティを指定する。一実施形態では、考えられる値は、「ベスト・エフォート(best-effort)」及び「厳密に一度(exactly-once)」である。
−ｒｅｔｒｙＣｏｕｎｔ（再試みカウント）：メッセージを送信するときに使用すべき試みの回数。
−ｒｅｔｒｙＩｎｔｅｒｖａｌ（再試みインターバル）：メッセージを再送信する試みの前に待機すべきインターバル（秒）。
【００８２】
一実施形態において、メッセージ処理ステージは、ＸＱｕｅｒｙ及び／又はＸＵｐｄａｔｅを使用して、コンテクストを操作することができる。コンテクストにおける各変数は、同じ名前のＸＱｕｅｒｙ変数として表わすことができる。例えば、ｈｅａｄｅｒ変数は、ＸＱｕｅｒｙにおいて＄ｈｅａｄｅｒとしてアクセスすることができる。
【００８３】
一実施形態において、コンテクスト変数値は、オンデマンドで発生して、できるだけ多くストリームさせることができる。例えば、到来する要求及び応答メッセージは、トランスポートレイヤーによりＪａｖａ（登録商標）ＩｎｐｕｔＳｔｒｅａｍとして返送することができる。パススルー処理の場合には、ストリームは、サービスプロキシーが別のサービス又はサービスプロキシーへそれを送信するときまでタッチされない。ＳＯＡＰメッセージについては、ｈｅａｄｅｒ変数は、ｂｏｄｙを実施する必要なく、アンマーシャルとすることができる。同様に、アタッチメントは、ａｔｔａｃｈｍｅｎｔｓ変数がアクセスされる場合にはアンパックすることができる。オペレーションの場合にも、要求メッセージの検査をトリガーして、変数が特別にアクセスされる場合に呼び出されるオペレーションを決定しなければならない。
【００８４】
ルーティング、変換及びモニタリングに加えて、サービスバスは、クライアントと、サービスプロキシーと、サービスとの間のメッセージ交換をセキュアなものとすることのできる種々の特徴を含む。一実施形態では、サービスバスは、ＴＬＳ／ＳＳＬに勝るメッセージの機密性、メッセージの完全性、サーバー認証性及びクライアント認証性；ＳＯＡＰメッセージに対するメッセージレベルの機密性、完全性及び送信者の認証性；トランスポート及びメッセージの両レベルにおけるアクセス制御性；証明書マネージメント；及びセキュリティ監査を与える。
【００８５】
一実施形態において、サービスバスにおけるセキュリティ特徴は、プラグ可能なセキュリティプロバイダーアーキテクチャー及びセキュリティサービス、例えば、認証、身分主張、許可、ロールマッピング、監査、証明書(credential)マッピング、並びに証書(certificate)ルックアップ及び検証の使用である。サービスバスは、これら全てのプロバイダーを構築ブロックとして使用して、より高いレベルのセキュリティサービスを提供することができる。ユーザは、ボックスプロバイダーからのこれらのいずれかを、第三者プロバイダー又はそれら自身のカスタムプロバイダーと置き換えることができる。一実施形態では、サービスバスセキュリティは、ＢＥＡシステムズ・インクから入手できるＢＥＡ ＷｅｂＬｏｇｉｃ Ｅｎｔｅｒｐｒｉｓｅ ＳｅｃｕｒｉｔｙTMにより与えることができる。
【００８６】
図８は、一実施形態におけるサービスプロバイダーを示す図である。１つ以上の外部サービス８０８が外部サービスプロバイダー８０４により提供される。中間サービスバスのサービスは、サービスプロキシー８０６と称されるもので、これは、プロキシー（又はローカル）サービスプロバイダー８０２により提供することができる。サービスプロバイダーは、セキュリティ認識を有するアプリケーション、組織又は部門である。セキュリティ認識を有していて、サービスプロキシーを呼び出すクライアントは、サービス消費者８００と称される。外部サービスプロバイダーは、要求に同期的に又は非同期的に応答し得るので、本来、サービス消費者でもある。
【００８７】
種々の実施形態において、説明上、サービスバス及び外部サービスが、同じネットワーク内で、ファイアウオールの後方にあってもよいし、或いは異なるネットワーク上にあって、ファイアウオールがサービス消費者とサービスバスとの間及び／又はサービスバスと外部サービスとの間に存在してもよい。一実施形態では、サービスプロキシー及びターゲットサービスは、同じドメインに一緒に配列される。この特殊なケースは、ビジネスプロセスマネージメント（ＢＰＭ）である。スペクトルの他の端において、サービスバスプロキシーは、組織外部のトレーディングパートナーからメッセージを受信し又はそこへメッセージをルーティングする。一実施形態では、ユーザマネージメントが、所与の認証プロバイダーにおけるユーザ、グループ及びロールの生成、更新及び削除オペレーションを取り扱う。これらのプロバイダーは、セキュリティフレームワークの一部分である。更に、ユーザマネージメントは、ユーザプロパティの生成も許す。ユーザ、グループ及びロールは、コンソールと共に構成され、コンソールユーザ及びメッセージ送信者の認証に使用される。
【００８８】
一実施形態において、ユーザは、認証プロバイダーにおけるエンティティである。多数の認証プロバイダーがサポートされる。グループは、ユーザの論理的グループ編成であり、そのメンバーシップは静的で、そのグループのアドミニストレータにより指定される。ロールは、ユーザ及びグループの論理的グループ編成であり、そのメンバーシップは、ロールの条件及びポリシーに基づいて動的に計算される。アドミニストレータは、サポートされる認証プロバイダーのいずれかにおいてユーザ、グループ及びロールを生成し、読み取り、更新しそして削除することができる。アクセス制御ポリシーは、通常、ロールに基づく。
【００８９】
一実施形態において、サービスバスは、ＨＴＴＰＳを経ての一方向要求又は要求／応答（クライアントからサービスバスへの）に対してトランスポートレベルの機密性、メッセージの完全性、及びクライアントの認証をサポートする。サービスバスは、ポリシーベースのアクセス制御を実行できると共に、認証及び許可事象を監査することができる。認証又は許可が失敗したときにアラームをトリガーすることができる。一実施形態では、サービスプロキシーがアクチベートされたときに、サービスバスは、オンザフライで希薄なウェブアプリケーションを発生して展開することができる。アプリケーションサーバー（例えば、ＷｅｂＬｏｇｉｃ（登録商標）Ｓｅｒｖｅｒ）は、セッションマネージメント、クライアント証書検証及び認証、信用性マネージメント及びサーバーＳＳＬキー／証書操作を含むサーバー側ＳＳＬサポートを与えることができる。
【００９０】
一実施形態において、アプリケーションサーバーは、その証書をＳＳＬプロトコルにおいてクライアントに送信することができる。換言すれば、クライアントは、サーバーを認証する。それに加えて、ＳＳＬハンドシェーク中に、サーバーは、サーバーがクライアントを認証するように、クライアントに、その証書をサーバーへ送信するよう要求できる。これは、通常、２方向ＳＳＬと称される。クライアントがその証書を送信するよう要求されないときには、１方向ＳＳＬと称される。ＳＳＬの頂部におけるより高いレベルのプロトコルは、それら自身の認証メカニズムを自由に定義する。例えば、ＨＴＴＰＳでは、ＳＳＬハンドシェークが完了すると、クライアントは、そのユーザ名及びパスワードをＷＷＷ−ＡｕｔｈｅｎｔｉｃａｔｅＨＴＴＰヘッダーにおいて送信することによりサーバーに対して認証を行うことができる。これは、ＢＡＳＩＣ認証と称される。
【００９１】
一実施形態において、サービスプロキシーがクライアント認証を要求するように構成された場合には、サーバーは、サービスプロキシーエンドポイントへの全ての要求を認証することができる。ＢＡＳＩＣ認証の場合に、サーバーは、例えば、ＬＤＡＰ、アクティブなディレクトリー等の領域において構成された認証プロバイダーに対してクライアントを認証することができる。ＣＬＩＥＮＴ−ＣＥＲＴ認証の場合には、ＳＳＬエンジンがクライアントの証書を検証することができる。証書の信用性が確立されると、証書が認識主張プロバイダーへ通され、クライアントの認識が抽出される。この実施形態の態様において、認識主張プロバイダーは、サーバーセキュリティフレームワークの別のコンポーネントである。認識主張者は、証書のあるフィールドを抽出して、クライアント認識、通常は、証書のＳｕｂｊｅｃｔＤｉｓｔｉｎｇｕｉｓｈｅｄＮａｍｅのＣＮ（普通の名前）又はＥ（ｅメール）として使用するように構成される。最終的に、認証プロバイダーは、ユーザが属する全てのグループを収集するために呼び出される。最終結果は、クライアント認識を保持する１つのプリンシパルと、ユーザが属する各グループに対して１つのプリンシパルとを伴うサインされたＪａｖａ認証及び許可サービス（ＪＡＡＳ）サブジェクトである。
【００９２】
一実施形態において、サービスバスは、ＨＴＴＰプロキシーにおけるＢＡＳＩＣクライアント認証もサポートする。ＨＴＴＰ／ＨＴＴＰＳプロキシーが最初に配備されるときには、サービスプロキシーＵＲＩに対するアクセス制御ポリシーが認証プロバイダーに記憶される。一実施形態では、サービスバスは、ＸＡＣＭＬをサポートする。
【００９３】
一実施形態において、サービスプロキシーがクライアント認証を要求しない場合には、初期アクセス制御ポリシーが全ての要求へのアクセスを許可する。サービスプロキシーがクライアント認証（ＢＡＳＩＣ又はＣＬＩＥＮＴ−ＣＥＲＴ）を要求する場合には、初期ポリシーは、認証された全てのクライアントへのアクセスを許可する（が、匿名の要求は拒絶される）。セキュリティアドミニストレータは、サービスバスコンソールにおいてアクセス制御ポリシーを変更することができる。サービスバスでは、ユーザが次のポリシー間で選択を行うことができる。非チェック（全ての要求はアクセスが許可される）、除外（全ての要求が拒絶される）、認証ユーザ（匿名要求が拒絶される）、及びロールのセット。
【００９４】
一実施形態において、首尾良い認証は、クライアント認識プリンシパルと、ユーザが属する各グループに対して１つのプリンシパルとをラップするＪＡＡＳサブジェクトを生じさせる。ユーザは、グループに指定することができる。ロールは、グループ（又は他の基準、例えば、日時）に関して定義することができる。ユーザが属するロールのセットは、ランタイムに動的に決定される。アクセス制御ポリシーがロールのセットである場合には、これらロールの１つ以上に属するユーザは、アクセスが許可される。認証が首尾良くいった場合には、ウェブコンテナがサービスバスＨＴＴＰ／ＨＴＴＰＳトランスポートプロバイダーを呼び出す。そこから、メッセージは、サービスバスバインディングレイヤーへと進む。バインディングレイヤーは、認証されたＪＡＡＳサブジェクトからのクライアントプリンシパルをメッセージコンテクストに記憶し、そして要求パイプラインを呼び出す。パイプラインステージは、ビジネスルールにおいてクライアントプリンシパルを使用することができる。例えば、クライアント特有の変換を適用してもよいし、又はルーティングテーブル条件がクライアントプリンシパルを考慮してもよい。
【００９５】
要求パイプラインノードの終りに、プロキシーは、通常、メッセージをターゲットサービスへルーティングする。ターゲットサービスは、パイプラインのルーティングステージにより決定することができる。ルーティングステージは、同じターゲットサービスへルーティングすることもできるし、又はある条件に基づいてターゲットサービスを動的に選択することもできる。いずれにせよ、ターゲットサービスは、サービスバスのサービスディレクトリーに登録された外部サービス（又はサービスプロキシー）への参照として特定される。アドミニストレータは、サービスバスコンソールを使用して、外部サービスを登録する。
【００９６】
一実施形態において、外部サービスが登録されると、サービストランスポート及びサービスに対する１つ以上のＵＲＬが入力される。これは、その特定の外部サービスへ要求をルーティングするためにサービスプロキシーが使用できるトランスポート及びＵＲＬ（１つ又は複数）である。トランスポートがＨＴＴＰＳである場合には、次の認証メソッドの１つを指定することができる。即ち、ＢＡＳＩＣ、ＣＬＩＥＮＴ、又はクライアント認証なし。トランスポートがＨＴＴＰである場合には、ＢＡＳＩＣ、又はクライアント認証なしがサポートされる。認証メソッドがＢＡＳＩＣである場合には、オプションのＳｅｒｖｉｃｅＡｃｃｏｕｎｔを指定することができる。アウトバウンド（クライアント、例えば、プロキシー）認証を後でカバーすることができる。
【００９７】
一実施形態において、サービスバスは、一方向に対するトランスポートレベルセキュリティと、サービスバスプロキシーと外部サービスとの間でＨＴＴＰ（Ｓ）を経て送信された要求−応答メッセージとをサポートする。ＨＴＴＰＳは、機密性及び完全性を与える。又、これは、サービスバスがターゲットサーバーを認証するのを許す。更に、もし必要であれば、サービスバスプロキシーは、外部サービスに対して認証することができる。これは、インバウンドトランスポートセキュリティと同様であるが、この場合に、サービスバスは、ＨＴＴＰＳ接続を開始する。アウトバウンドの場合には、ＳＳＬプロトコルの観点から、サービスプロキシーがクライアントとして働き、そしてターゲットサービスを実行するサーバーがサーバーとして働く。サービスバスのＨＴＴＰＳトランスポートプロバイダーは、ＨＴＴＰＳ接続を経てターゲットサーバーへＨＴＴＰ要求を送信し、そしてＨＴＴＰ応答を受け容れる。ターゲットサーバーは、そのＳＳＬ証書をサーバーへ送信することができる。
【００９８】
一実施形態において、２つのクライアント認証メソッドを、ＨＴＴＰＳ、即ちＣＬＩＥＮＴ−ＣＥＲＴ及びＢＡＳＩＣと共に使用することができる。外部サービスがＣＬＩＥＮＴ−ＣＥＲＴ認証で構成される場合には、ＳＳＬハンドシェーク中に、サービスプロキシーは、そのＳＳＬクライアント証書をターゲットサーバーへ送信することができる。一実施形態において、サービスプロキシーは、ローカルサービスプロバイダーと任意に関連付けされる。証明書マネージャーは、証明書をローカルサービスプロバイダーに結合する。ローカルサービスプロバイダーは、ＳＳＬクライアント認証に対してプライベートキー及び証書をもつことができる。これは、ＳＳＬハンドシェーク中にサービスプロキシーが使用できるキー／証書である。多数のサービスプロキシーは、同じローカルサービスプロバイダーを参照することにより、同じＳＳＬクライアントキー／証書を共有することができる。
【００９９】
一実施形態において、外部サービスは、ユーザ名及びパスワードを送信することにより認証するようにサービスプロキシーに要求することができる。これは、通常、ＨＴＴＰＳを経て行われるが、サービスバスは、ＨＴＴＰを経てＢＡＳＩＣ認証もサポートする。ＨＴＴＰＳは、暗号化チャンネルを与え、それ故、ＨＴＴＰＳを経てパスワードを送信するのが安全である。他方、ＢＡＳＩＣ認証を伴うＨＴＴＰは、パスワードがワイヤ上を平文（ｂａｓｅ６４−エンコード化）で搬送されるので、強く反対される。
【０１００】
一実施形態において、ＨＴＴＰ又はＨＴＴＰＳ外部サービスがＢＡＳＩＣ認証で構成される場合には、付加的なサービスアカウントを任意に指定することができる。サービスアカウントが指定されない場合に、サービスプロキシーは、証明書マネージャーから使用すべきユーザ名及びパスワードを、サービスプロキシーＳＳＬクライアントキーを検索するのに類似した仕方で、決定することができ、即ちサービスプロキシーは、ローカルサービスプロバイダーに関連付けされ、そしてユーザ名／パスワードは、ローカルサービスプロバイダーに関連付けされる。外部サービスがサービスアカウントを指定する場合には、そのサービスアカウントに対するユーザ名及びパスワードが証明書マネージャーに記憶される。この場合に、サービスプロキシーは、ローカルサービスプロバイダーからユーザ名及びパスワードを取得せず、むしろ、サービスプロキシーは、サービスアカウントのユーザ名／パスワードを送信する。
【０１０１】
一実施形態において、メッセージコンテクストは、パイプラインノードのデザイナーが、ユーザ名／パスワード証明書の検索に使用するためのサービスアカウントの名前を指定するのを許すエレメントを有する。要求パイプラインにおける変換ステージは、メッセージコンテクストのこのエレメントをセットすることができる。指定された場合には、このサービスアカウントは、ローカルサービスプロバイダーの証明書もオーバーライドする。
【０１０２】
一実施形態において、サービスバスは、ＯＡＳＩＳウェブサービスセキュリティ（ＷＳＳ又は手短にＷＳＳ）をサポートする。ＷＳＳは、ＳＯＡＰメッセージに対するメッセージ機密性、完全性及び送信者認証についてのフレームワークを定義する。ＷＳＳは、個々のＳＯＡＰエンベロープに適用される。ＷＳＳは、ＸＭＬ−暗号化及びＸＭＬ−ＤＳＩＧを構築ブロックとして使用する。クライアントにおけるＷＳＳランタイムは、１つ以上の個々のメッセージ部分を暗号化し及び又はそれにデジタルでサインする。一実施形態において、新たなＳＯＡＰヘッダーがエンベロープに追加される。ＷＳＳヘッダーは、ＸＭＬ−ＤＳＩＧデジタルシグネチャー、セキュリティトークン、及び他の構成を含む。これらのセキュリティトークンは、送信者を認証し、キーをラッピングし（基本的に受信者のパブリックキーで暗号化されたランダムに発生された対称的暗号を搬送する）、シグネチャー検証証書を搬送し、又は送信者の暗号化パブリックキーと共に証書を含ませる（受信者が応答を暗号化できるように）のに使用できる。その結果、新たなＳＯＡＰエンベロープが得られる。受信者がセキュアなエンベロープを消費すると、暗号化オペレーションが逆の順序で実行され、そしてセキュリティヘッダーが除去される。次いで、受信者は、メッセージがそのポリシーに適合することを検証する（例えば、要求されたメッセージ部分がサイン及び／又は暗号化され、要求されたトークンが、要求された請求物と共に存在する、等々）。
【０１０３】
一実施形態では、ＳＯＡＰエンベロープの個々の部分は、デジタルでサインし及び又は暗号化することができる。それにより得られるメッセージは、依然、有効なＳＯＡＰエンベロープである。例えば、本体が暗号化されてもよいし、ＷＳアドレッシングヘッダーがサインされてもよいし、そして更に別のヘッダーがサインも暗号化もされなくてもよい。ＷＳＳは、セキュアなチャンネルに依存しない。むしろ、個々のＳＯＡＰエンベロープの１つ以上の部分が保護される。このＳＯＡＰエンベロープは、例えば、ＨＴＴＰ又はＪＭＳのような、どんな基礎的なプロトコル／トランスポートが使用されても、それを経て送信される。セキュリティ手段がメッセージそれ自体に組み込まれ、メッセージは、アプリケーションレイヤーへの経路全体にわたり、トランスポートプロトコルを越えて保護される。更に、中間物が、機密性、完全性及び認証のセキュリティプロパティを保持しながら、メッセージを中継することができる。従って、端−端の機密性、メッセージの完全性、及び送信者の認証を達成することができる。
【０１０４】
説明上、インバウンドＷＳＳセキュアメッセージは、次の通りである。
−サービス消費者からプロキシーへの要求。サービス消費者は、ＷＳＳを要求に適用し、そしてサービスプロキシーは、セキュリティヘッダーを処理し、セキュリティポリシーを実施する。
−サービス消費者からプロキシーへの要求。サービス消費者は、ＷＳＳを要求に適用するが、サービスプロキシーは、セキュリティヘッダーを処理せず、又、セキュリティポリシーも実施しない。サービスプロキシーは、要求を外部サービスへルーティングする。外部サービスが、セキュリティヘッダーを処理し、そしてポリシーを実施する。これは、要求パススルーシナリオである。
【０１０５】
−ターゲットサービスからプロキシーへの応答。ターゲットサービスは、ＷＳＳを応答に適用し、そしてサービスプロキシーは、セキュリティヘッダーを処理し、セキュリティポリシーを実施する。
−ターゲットサービスからプロキシーへの応答。ターゲットサービスは、ＷＳＳを要求に適用するが、サービスプロキシーは、セキュリティヘッダーを処理せず、又、セキュリティポリシーも実施しない。サービスプロキシーは、応答をサービス消費者へ転送する。サービス消費者がセキュリティヘッダーを処理し、ポリジーを実施する。これは、応答パススルーシナリオである。
【０１０６】
説明上、アウトバウンドＷＳＳセキュアメッセージは、次の通りである。
−プロキシーから外部サービスへのメッセージ。サービスプロキシーは、ＷＳＳをメッセージに適用し、そしてターゲットサービスは、セキュリティヘッダーを処理し、ポリシーを実施する。
−プロキシーからサービス消費者への応答。サービスプロキシーは、ＷＳＳをメッセージに適用し、そしてサービス消費者は、セキュリティヘッダーを処理し、ポリシーを実施する。
【０１０７】
更に説明上、サービス消費者は、暗号化されたＷＳＳ ＳＯＡＰメッセージをサービスプロキシーへルーティングのために送信することができ、サービスプロキシーは、おそらく、ある平文ヘッダー、例えば、ＷＳ−アドレッシングヘッダー又はカスタムヘッダーの値に基づいて、メッセージをルーティングし、バックエンドのサービスは、暗号化されたメッセージを受信して、それを暗号解読し、そして要求を処理する。次いで、サービスは、応答を、クライアントのパブリックキーで暗号化して送信する。サービスプロキシーは、その応答をクライアントに配送する。サービスプロキシーは、メッセージを暗号解読する必要がない。サービス消費者及びバックエンドのサービスは、サービスプロキシーが微妙なデータを読み取れないことが保証される（サービスプロキシーが暗号解読キーを有していないので）。同様に、サービス消費者は、認証の目的でセキュリティトークンを含んでもよく、そしてサービスプロキシーは、トークンをターゲットサービスへ中継することができる。
【０１０８】
一実施形態において、説明上、サービスプロキシーは、例えば、外部ビジネスパートナーから到来する要求に対してサービスバスがゲートウェイとして使用されるときに、サービス消費者から到来する要求のＷＳＳヘッダーを処理するように構成できる。これは、サービスプロキシー及びターゲットサービスが共通位置にあってゲートウェイにおけるアクセス制御を実施するとき、及びターゲットサービスがＷＳＳをサポートしないときに、計算的に集中する暗号解読、シグネチャーの検証及び認証オペレーションからバックエンドサービスをオフロードするのに有用である。一実施形態において、サービス消費者は、メッセージの１つ以上の部分を暗号化し及び又はそれにサインし、及び／又は認証トークンを含ませる。サービスプロキシーは、トークンを認証し、メッセージを暗号解読し、そしてデジタルシグネチャーを検証する。ＷＳＳ認証トークン及びメッセージコンテンツに基づくアクセス制御をここで行うことができる。次いで、平文メッセージが要求パイプラインを経て進行する。パイプラインの終りに、メッセージは、ターゲットサービスへルーティングされる。
【０１０９】
説明上、サービスプロキシーは、サービス消費者に代わってメッセージにＷＳＳを適用することができる。この場合に、サービスプロキシーは、サービス消費者から平文メッセージを受信する。メッセージは、要求パイプラインを通常通りに流れる。パイプラインの終りに、ターゲットサービスが決定されると、メッセージを実際に送信する前に、サービスプロキシーは、認証トークンを暗号化し及び又はそれにサインし及び／又はそれをメッセージに追加する。この新たなセキュアなＳＯＡＰエンベロープがターゲットサービスへ配送される。
【０１１０】
一実施形態において、システムは、ＯＡＳＩＳウェブサービスセキュリティ規格並びにユーザ名トークンプロフィール及びＸ．５０９トークンプロフィールをサポートする。バックエンドサービス、クライアント及びサービスプロキシーは、ウェブサービスポリシーフレームワーク（ＷＳ−ポリシー）仕様書がＢＥＡ、ＩＢＭ、マイクロソフト、ＳＡＰ、ソニックソフトウェア及びＶｅｒｉＳｉｇｎにより開発された後にモデリングされた任意のＷＳ−ポリシーで構成することができる。このフレームワークは、ウェブサービス要求及び能力を指定し及び構成するための拡張可能なアーキテクチャーを定義する。
【０１１１】
所与の要求／応答ラウンドトリップにおいて、４つ全てのメッセージを個々に保護することができる。全メッセージ経路における４つのメッセージの各々は、ＷＳ−ポリシーで指定された要求を潜在的に受ける。送信者は、例えば、１つ以上のメッセージ部分にサインし及び／又はそれを暗号化し、及び／又は必要な認証トークンを含ませることにより、ポリシーに適合するメッセージを形成するように必要なステップを適用することができる。受信者は、メッセージを消費するに必要なステップ、即ち暗号解読、シグネチャーの検証、及びトークンの検証／認証を実行することができる。加えて、受信者は、メッセージが実際にポリシーに合致することを検証できる。
【０１１２】
一実施形態において、サービスバスは、サービス消費者及び外部サービスとセキュアに対話するのに必要な証明書と共に構成することができる。特に、インバウンドメッセージでは、サービスバスは、次のように構成することができる。
−その（サーバー）証明書を送信して、クライアントがサービスバスサーバーを認証できるようにする（例えば、ＳＳＬハンドオーバーの間に）。
−メッセージ送信者をトランスポートレベル又はメッセージレベルで認証する。
−暗号化されたメッセージをサービスバスのプライベート暗号解読キーで暗号解読する。
−到来するメッセージにおけるデジタルシグネチャーを検証する。
【０１１３】
アウトバウンドメッセージにおいて、サービスバスは、次のように構成することができる。
−接続の他端においてサーバーを認証する（例えば、ＳＳＬハンドシェーク中に）。
−トランスポートレベル又はメッセージレベルで受信者に対してそれ自身を認証する。
−意図された受信者のパブリックキーでメッセージを暗号化する。
−認証又はデータ完全性の目的でメッセージにサインする。
【０１１４】
サービスバスの証明書マネージャーコンポーネントは、証明書をマネージしそして証明書を検索するためにオペレーション、アドミニストレーション及びメンテナンスＡＰＩ並びにランタイムＡＰＩを与えることができる。証明書は、２つのカテゴリーに分けることができる。即ち、外部証明書（サービスプロキシーと対話する外部サービス又はサービス消費者に属する証明書）；及びローカル証明書（サービスプロキシー又はサービスバスシステム全体に属する証明書）。
【０１１５】
更に別の実施形態において、証明書は、タイプで分類することができる。サービスバスは、ユーザ名／パスワード、プライベートキー／Ｘ．５０９証書チェーン、及び信用のあるＸ．５０９証書をサポートすることができる。証明書マネージャーは、他の証明書タイプをサポートするように拡張することができる。一実施形態において、証明書は、それが外部であるかローカルであるかに関わらず、サービスバスリソースに結合することができる。例えば、プロキシーのウェブサービスセキュリティポリシーが、インバウンドメッセージのＳＯＡＰ本体をＲＳＡで暗号化することを要求する場合には、サービスプロキシーに結合されたプライベートキー及びＸ．５０９証書が存在し得る。証明書マネージャーは、サービスバスリソースと証明書との間のこれら結合をマネージする。
【０１１６】
一実施形態において、証明書マネージャーは、次の証明書をマネージする。
−ローカルサービスプロバイダーの場合：暗号化証書及びそれに対応するプライベートキー；デジタルシグネチャープライベートキー及び証書；ユーザ名／パスワード；ＳＳＬクライアント認証に使用されるローカルサービスプロバイダーのためのＳＳＬプライベートキー及び証書；ＷＳＳ認証のためのプライベートキー及び証書（Ｘ．５０９トークン）。
−外部サービスプロバイダーの場合：暗号化証書；デジタルシグネチャー検証証書；ユーザ名／パスワード；ＳＳＬクライアント証書；ＳＳＬサーバー証書；Ｘ．５０９認証証書（ＷＳＳ Ｘ．５０９トークン認証のための）。
−サービス消費者の場合：暗号化証書；デジタルシグネチャー検証証書；ユーザ名／パスワード；ＳＳＬクライアント証書；ＷＳＳ認証のためのＸ．５０９認証証書（Ｘ．５０９トークン）。
【０１１７】
一実施形態において、ルールは、基本的に、表現を評価しそして（通常）ブールの結果を生み出すステートメントである。ルールは、ルールが「真」と評価する場合に実行される関連アクションのリストを含むことができる。ルールに含まれる条件は、現在日時（例えば、ビジネスカレンダー）から、ランタイムコンテクストデータ、ユーザプロフィール等までの範囲とすることができる。例えば、これに限定されないが、ルールを使用して、システム健全さ及び応答時間に基づきＳＬＡ警告をトリガーし、ある条件に基づきサービスバスのサービスの「コスト／健全さ」を動的に調整し、セキュリティ違反の場合に通知を発生し、そしてサービス着手の拒絶を検出することができる。例えば、
ルール１：サービスＯｒｄｅｒＲｏｕｔｅｒの平均応答時間が３５０ミリ秒「より長い」場合には、通知を行う。
ルール２：９ａｍと５ｐｍとの間でサービスＣｒｅｄｉｔＣｈｅｃｋの応答時間が１０秒「より長い」場合には、ウェブサービス「Log a trouble ticket」を呼び出す。
【０１１８】
一実施形態において、コンソールを経てルールを生成し、ＸＭＬで表わすことができる。ＸＭＬコンフィギュレーションスキーマは、ルールフォーマットを定義することができる。サービスバスルールエンジンは、ルールの位置に基づいて多数の異なる種類のルールをサポートすることができる。種々のルールタイプについて、以下に詳細に説明する。一実施形態では、サービスバスルールは、次のフォーマットを有する。
＜条件のセット＞の場合には、＜アクションのセットを実行する＞
【０１１９】
説明上、条件は、時間（カレンダー）と、モニタリングフレームワークにより集計されるモニタリングデータとをベースとすることができる。これは、多数の更なる条件タイプ、例えば、ユーザプロフィール属性、パイプラインコンテクストランタイムデータ、等々を含むように容易に拡張することができる。一実施形態において、各条件タイプは、それ自身をルールフレームワークに登録し、そしてコンフィギュレーション及び評価インターフェイスを与える。これは、将来必要となる多数の条件タイプをプラグインすることを許す。
【０１２０】
一実施形態において、ルールは、次の２つのカテゴリーに広く分類することができる。即ち、ＳＬＡルール、及びインラインルール。ＳＬＡルールは、主として、ＳＬＡを評価し、そして警告をトリガーして潜在的なシステム欠陥を事前に捕えるのに使用される。これは、規則的な間隔で全てのサービスプロキシーからモニタリング情報を集計し、そして発生状態をチェックして、全ての性能制約を満足するよう確保することにより、実行できる。インラインルールが有用であるのは、パイプラインが実行されるときに、モニタリングデータの集計に遅延を伴うことなく、ルールをインラインでトリガーする（大部分はエラーパイプラインから）ことを要求する使用ケースをサポートする必要があるためである。例えば、「セキュリティ証明書の不一致から発信したメッセージを顧客に通知する。」このケースでは、顧客に対するコンタクト情報をユーザマネージメントモジュールからルックアップする必要がある。これは、ルールの「トリガーポイント」をパイプラインの内部に埋め込みそしてビジネスユーザがルールをランタイムにこれらトリガーに関連付けるのを許すメカニズムを必要とする。又、このようなルールは、ある最小限の量のランタイムコンテクストデータをアクション（現在ユーザプロフィール、現在メッセージ、等）に対して通すことしか要求しない。
【０１２１】
ルールは、マネージメントコンソールを経て構成することができる。各ルールは、単一の特定の「エンティティ」（サービス、ステージ、Ｊ２ＥＥリソース、等）に関連付けられる。ルールスキーマは、各ルールのフォーマットを定義することができる。一実施形態において、ルール構築者は、ルールを構成するのに必要な全てのエレメントを一緒に結び付けることにより、ルールを構成するためのユーザに対するフロントエンドを提示する。これは、ルールの名前及びバインディング、即ちルールが結合されるところのエンティティ（サービス、ステージ、ＪＭＳリソース、等）を特定することを含む。サービスを選択することは、パイプライン、ルーター及びトランスポートに得られるモニタリングエレメントを使用してルールを構成できることを意味する。一実施形態において、バインディングは、もしあれば、どんなランタイムデータがルールに得られるかを明確に識別することに関して、ルールに対する「コンテクスト」を与える。
【０１２２】
一実施形態において、ルールのトリガーを指定することができ、即ちルールは、アクションを一度トリガーしそして手動リセット又は条件付き自動リセットを待機することができ；ルールは、それが真と評価するたびにアクションをトリガーし；そしてルールは、それが真と評価する場合に「ｘ」分ごとにアクションをトリガーし、等々となる。
【０１２３】
一実施形態において、ルールは、ゼロ以上の条件を含むことができる。これら条件は、異なるタイプのもので、ビジネスカレンダー、モニタリングデータ、ランタイムコンテクスト変数、等々がある。ルールフレームワークは、ランタイムパースペクティブからの新たな条件タイプを容易にプラグインするように設計される。
【０１２４】
ルールが結合されるエンティティに基づき、ルール構築者のユーザインターフェイスは、特定の条件タイプをルールに含ませるのを許すことができる。例えば、ＳＬＡルールは、特定のバインディングにおいて得られるモニタリングデータに基づいて定義することができる。ＪＭＳリソースに関連したルールは、サーバーにより定義されたＪＭＳリソースメトリックに基づく条件を含むことができる。しかしながら、全てのバインディングポイントへ展開されるルールに関連し得るビジネスカレンダーのような幾つかの条件タイプが存在し得る。これは、カレンダーが特定コンテクスト／バインディング関連データに依存しないためである。各条件は、ＯＲ及びＡＮＤ演算子を使用して任意に加えることができ且つネスト状にすることができる１つ以上の表現で構成される。例えば、次のルールを考える。
【０１２５】
「９ａｍと５ｐｍとの間に」、「サービスＡＢＣのａｖｅｒａｇｅ＿ｒｅｓｐｏｎｓｅ＿ｔｉｍｅが２秒を越えるか「ＯＲ」ｓｅｃｕｒｉｔｙ＿ｖｉｏｌａｔｉｏｎ＿ｃｏｕｎｔが２５を越える場合に」、ｅメールにより私に「手動リセット又は条件付き自動クリアまでに、一度」通知すること。
【０１２６】
上記ルールには、２つの条件タイプ、即ちビジネスカレンダー及びモニタリングデータがある。モニタリングデータに基づく条件は、論理的にＯＲされる。上記ルールが真であるためには、現在システム時間が９ａｍと５ｐｍとの間であり「ＡＮＤ」ａｖｅｒａｇｅ＿ｒｅｓｐｏｎｓｅ＿ｔｉｍｅが２秒を越えるか「ＯＲ」セキュリティ違反が２５を越える。これらの条件は、最上位レベルで全て「ＡＮＤ」される。個々の条件は、（ＯＲ及びＡＮＤを使用して）任意に合成でき且つネスト状にできる表現で構成される。
【０１２７】
一実施形態において、アクションのリストは、ルールが真と評価するときに実行される必要のあるアクションを指定するルールを付随することができる。ユーザは、ルールにアクションを含まないことを選択してもよい。一実施形態では、ルールは、少なくとも１つの条件「ＯＲ」１つのアクションを有する。アクションを実行するのに必要な全ての所要コンフィギュレーションパラメータを指定するためにユーザに尋ねることができる。一実施形態では、アクションは、通知ｅメールを送出するような簡単なタスクから、特定のワークリストへルーティングされたトラブルチケットをログするためのリモートウェブサービスを呼び出すことへと変化し得る。サービスバスに警告するフレームワークにおいて使用できる幾つかのアクションは、次の通りである。即ち、ｅメールによる通知；ウェブサービスの呼び出し；及びサービスコストのセット、即ちサービスディレクトリーにおけるサービスの「コスト」をセットすること。サービスのコストを使用して、ルーティング判断を行うことができる。
【０１２８】
一実施形態において、ルールエバルエーター(evaluator)は、事象によりトリガーされたときにルールを評価する。これは、直接ＡＰＩ呼び出しを経て行うことができ、即ちルールエバルエーターは、ルール評価をトリガーするのに使用できるＡＰＩメソッドを備えている。メソッド呼び出しパラメータは、評価する必要のある１つ以上のルールを識別するための情報を含むことができる。例えば、モニタリングデータアグレゲータ(Aggregator)は、サービスに対して新たなモニタリングデータが使用可能となったときにそのサービスに関連したＳＬＡルールを評価するためのルールエバルエーターＡＰＩを呼び出すことができる。又、ルール評価は、事象契約によりトリガーすることもでき、即ちエバルエーターは、事象メカニズムと契約し、そして事象が生じたときにルール評価をトリガーすることができる。事象コンテクストは、ルール評価及びアクション実行に使用できる全てのランタイム情報を含むことができる。セキュリティ違反事象を生じるセキュリティステージは、ルール評価をトリガーしてアドミニストレータに通知することができる。この例では、事象コンテクストは、メッセージＩＤ及び送信者のアドレスを含むことができ、これは、アドミニストレータが問題の原因を明確に識別する上で助けとなり得る。タイマーベースのルールは、ビジネスカレンダーにより所定のスケジュールに基づいてトリガーすることができる。一実施形態では、スケジューリングサービスがタイマー事象を発生でき、ルールエバルエーターは、これに契約し、そして事象が生じたときにルール評価プロセスをキックオフすることができる。
【０１２９】
一実施形態では、システムの健全さをモニタリングするのに使用できるデータを集計するフレームワークがある。このフレームワークの重要な特徴は、ユーザがコンフィギュレーションにより性能モニタアプリケーションをサービスバスのサービスへ容易に埋め込むのを許し、ランタイムにモニタリングをディスエイブル／イネーブルするメカニズムを与え、データを集計して潜在的なシステム欠陥をユーザに通知するための警告を計算し、そして集計データに基づいて基本的メトリック（例えば、最小、最大、平均等）を与えることを含む。
【０１３０】
一実施形態において、モニタリングフレームワークは、モニタリングエレメントのリストを定義することができる。モニタリングエレメントは、モニタリングメトリックの特定のカテゴリーである。モニタリングエレメントは、広範囲の種々のコンポーネントにより使用できるに充分なほど一般的である。モニタリングエレメントのリストは、拡張可能であり、そして必要に応じて、より多くのエレメントを追加できる。一実施形態では、フレームワークは、現在、次のモニタリングエレメントを定義することができる。
【０１３１】
−カウンタ：処理された要求の数、エラーの数、処理されたメッセージの数、等のものを追跡するために、ユーザがそれらのコードにおいてカウンタを定義して使用するためのメカニズム与える。カウンタは、カウンタの現在値を増加し、減少し及びリセットするためのメソッドを与えることができる。
−タイマー：アプリケーションは、タイマーを使用して、特定のオペレーションを計時することができる。タイマーは、スタートし、ストップし、リセットし、そしてタイマーがスタートして以来の経過時間の長さをチェックするメソッドを与えることができる。
【０１３２】
図９は、一実施形態によるモニタリングコンポーネントを示す図である。アドミニサーバー９００におけるコンフィギュレーションマネージャー９１４は、モニタリングフレームワークに必要なコンフィギュレーション情報を捕獲する。例えば、これは、各アプリケーションに対するモニタリング属性、各属性のデータタイプ、モニタリングがイネーブルされるかどうか、各アプリケーションに対してモニタリングデータを集計する必要のある頻度、等のリストを含むことができる。モニタリングデータにおいて外部アプリケーションに関心がある場合には、それらをコンフィギュレーションマネージャーに登録することもできる。一実施形態において、モニタリングマネージャー９０６は、マネージされるサーバー９０２において実行される。一実施形態において、モニタリングマネージャーは、ＭＢｅａｎｓ９１６を経て外部にそしてファクトリーを経て内部に露出することができる。それらの主たる機能は、各々のマネージされるサーバーにおいてモニタリングされる情報をマネージすることである。又、アプリケーションがそれらのデータ属性に対してモニタリング機能を呼び出せるように、ＡＰＩを設けることもできる。
【０１３３】
一実施形態において、データアグレゲータ９１０は、アドミニサーバーにおいて規則的な間隔で実行され（構成可能である）、そして所与のドメインにおいてマネージされるサーバーからの全ての情報からデータを集計する。集計されたデータは、処理され、そして各アプリケーションのコンフィギュレーションに指定された特定の時間インターバルへと分類される。コンソールは、集計されたデータを使用してモニタリング情報を表示することができる。規則的なインターバルで、モニタリングデータパブリシャー（図示せず）は、アーカイブ又は外部計算の目的で、データを、登録された外部アプリケーションに対してパブリッシュする。ルールマネージャー９１８は、ルールを記憶する役目を果たし、集計されたデータを使用してルールを評価する。一実施形態において、ルールが真であると評価されると、警告マネージャー９１２がコールされる。警告マネージャーは、ルールが真であると評価されたときに他のプロセスを通知する。例えば、ｅメールを送信し、及び／又はルールに関連したアクションに基づいて待ち行列のメッセージをポストすることができる。
【０１３４】
一実施形態において、説明上、データアグレゲータ９１０は、データが古くなるにつれてメモリに保持するデータを益々少なくする。異なる時間周期に異なる精度でデータを見るようにウインドウを定義することができる。例えば、次のウインドウ、即ち５分、１時間、２４時間、が定義される。カウンタについては、最後の５分間に、全ての変化（例えば、１秒、又は１０秒で変化し、及びそのような変化を得ると判断できる）を記憶しようとすることを意味する。最後の１時間については、変化が５分である。最後の２４時間については、変化が１時間である。それより大きな周期については、変化が１日である（暗示的）。このコンフィギュレーションでは、最後の５分に所定数の値、最後の１時間に＋１２の値、最後の１日に＋２４の値、そして１日で＋１の値をメモリに記憶する必要があることを意味する。従って、３６５日間で、〜＝４００の値となる。集計されたデータは、コンソールにおいてグラフに表示し、及び又はこれを使用してルールをトリガーすることができる。
【０１３５】
一実施形態において、ユーザは、コンソールにおいてルールを対話式に指定することができる。例えば、コンソールは、ルールに対してＸＱｕｅｒｙ表現の中にドラグ及びドロップすることのできるサービスのサービス／ステージ／トランスポート／クオリティにより編成されたモニタされる変数のツリーを表示することができる。又、ＸＱｕｅｒｙ表現へ機能をドラグ及びドロップすることもできる。
【０１３６】
一実施形態において、モニタリングフレームワークを使用してモニタリングデータを捕獲することを希望するアプリケーションは、モニタリングされる必要のある属性のリストを指定すると共に、任意であるが、時間のスライディングウインドウと、データを捕獲するためのそのウインドウ内の更新の周波数とを指定することができる。スライディングウインドウ及びそのウインドウ内のインターバルが指定されたときには、システムは、構成された最新の時間インターバル内に形成された全てのモニタリングエンティティのリストである「最新アクティビティウインドウ」を維持するように構成することもできる。一実施形態において、システムは、カウンタ及びタイマーを使用してモニタリングをサポートする。
【０１３７】
一実施形態において、コンフィギュレーション情報は、各アプリケーションがモニタリングする属性のリストを定義する。各アプリケーション（又はトランスポートの場合のように、アプリケーションインスタンス）は、それ自身をモニタリングフレームワークに登録することができる。登録は、独特の名前と、モニタリングできる属性（及びそれに対応するデータタイプ）並びに時間ウインドウ仕様のリストとを与えることを含む。フレームワークは、コンフィギュレーションに対するスキーマをパブリッシュすることができる。
【０１３８】
一実施形態において、アドミニサーバーは、フレームワークにより与えられる全てのランタイム機能を含む。アドミニサーバーにおいて、これは、全てのマネージされるサーバーからのデータを集計し、データを各時間インターバルウインドウへとトリアージュし、集計されたデータに基づいて統計値を計算し、集計されたデータにアクセスするためのＭＢｅａｎインターフェイスを定義し、警告マネージャーにデータの変化を通知し、従って、ルールをトリガーできるようにし（又は規則的なインターバルでルールを評価できるようにし）、そして外部アーカイブシステムへモニタリングデータをパブリッシュするメカニズムを与えることができる。マネージされるサーバーでは、モニタリングマネージャーは、モニタリングデータを記録するためにアプリケーションに対してＡＰＩを定義し、データのランタイム記憶を与え、そしてＭＢｅａｎｓを経てそのデータを露出させることができる。
【０１３９】
一実施形態において、モニタリング値をログするために、アプリケーション（例えば、トランスポート、パイプラインステージ）は、最初に、独特のアプリケーション名を通すことにより各アプリケーションに対してモニタリングコンテクストを検索する必要がある。モニタリングコンテクストは、名前の付いたカウンタ及びタイマーへのアクセスを与え、これらが、データをログするメソッドを与える。例えば、サンプルソースコードは、次のように見える。
ctx.getMonitoringService().getTimer(“execution_time”).start();
ctx.getMonitoringService().getCounter(“nb_messages”).increment();
ctx.getMonitoringService().getTimer(“execution_time”).stop();
【０１４０】
アドミニサーバーは、データアグレゲータ９１０を備え、これは、特定のポーリングインターバルで各マネージされるサーバーをポーリングし、そしてデータを集計する。集計されたデータは、分類され、そしてアプリケーション名及び構成された各時間ウインドウで編成されたメモリ記憶ビンへとビン処理される。次いで、更新されたデータに基づいて統計値が計算される。モニタリングランタイムビーン９１６は、アプリケーションがこの集計されたデータにアクセスするのを許すことができる。加えて、アドミニサーバーは、ルールマネージャー９１８に通知することができ、従って、ルールは、更新されたデータに対して実行され、及び／又はデータをパブリッシュすることができる。
【０１４１】
ルールの条件が真である場合には、それに関連したアクション（１つ又は複数）を実行することができる。一実施形態において、アクションは、サービスとして実施することができる。一実施形態において、ルールは、ユーザ指定のインターバルで周期的に評価することができる。一実施形態において、サービスバスに展開されるサービスとして警告が実施される。フレームワークは、特定のＪＭＳトピックについて集計したモニタリングデータを外部アプリケーションへパブリッシュすることを外部アプリケーションが選択できるようにするコンフィギュレーションメカニズムを与える。
【０１４２】
一実施形態において、ルールは、１つ以上の表現を評価してブールの結果を生じるステートメントである。更に別の実施形態では、ルールは、ルールに含まれた全ての条件を評価した結果として「真」の値が生じる場合に実行される関連アクションのリストも有する。ルールに含むことのできる条件は、例えば、現在日時（ビジネスカレンダー）と、現在ユーザプロフィールと、アプリケーション応答時間（又は他のモニタリングデータ）と、アプリケーションが遭遇するセキュリティ違反である。ルールに含ませることのできるアクションは、例えば、ｅメールアドレスを通知し、メッセージを送信し、新たなタスクエントリーを生成し、サービスを呼び出し、そしてサービスをイネーブル／ディスエイブルすることである。
【０１４３】
ルールの例：
−簡単なアクション：特定サービスの平均応答時間があるスレッシュホールドを越えるときにアドミニストレータへ通知を送信する。
−毎日、９ａｍから５ｐｍの間に５分のインターバルで１０個を越えるセキュリティ違反に遭遇する場合に警告を発する。
−タイプＸのメッセージが最後の１０分に１０回を越えて検出された場合に、エントリーをログする。
−タイプＰのプロセスインスタンスが１２時間以上「ランニング」であった場合に、ワークリストタスクエントリーを生成する。
【０１４４】
一実施形態において、ルールは、自然言語、ＸＱｕｅｒｙステートメント等の多数の異なる方法で表現することができる。コンソールは、ユーザがルールを管理するのを許すことができる。その基礎となるルールは、ＸＭＬドキュメントとして存続することができ、そしてこのＸＭＬに対するスキーマをパブリッシュすることができる。一実施形態では、ルールフレームワークランタイムは、このＸＭＬドキュメントを消費し、そしてランタイムにルールを評価することができる。ＸＭＬドキュメントは、これらのルールを評価するときに適当なランタイムフォーマットへ変換することができる。例えば、モニタリングメトリックベースの条件は、ＸＱｕｅｒｙとして評価することができる。例えば、これに限定されないが、図１０を参照すれば、ルールトリガーは、種々の種類のものがあり、即ち更新されたモニタリングメトリックの利用性１０１０、事象１０１２、ある状態から別の状態へのプロセス遷移、サービスの平均応答時間の変化、あるタイプのメッセージの到着１０１２、及びルールを周期的にトリガーするスケジューリングサービス１０１８がある。
【０１４５】
一実施形態では、ルールコンテクストは、ルールに含まれる条件及びアクションを評価するときにルールにより消費されるランタイムデータをカプセル化する。ルールコンテクストは、ルールトリガーに非常に厳密に関連付けられる。ルールコンテクストに含まれたランタイムデータは、トリガーのタイプに依存する。例えば、サービスの平均応答時間の変化に関連したトリガーにより発生されるルールコンテクストは、サービスの名前及び平均応答時間の新たな値を含むことができる。事象トリガーに基づくルールコンテクストは、事象の性質と、その特定事象に関連したデータとを含むことができる。
【０１４６】
ルールは、種々のエンティティに関連して定義することができる。一実施形態において、ルールバインディングは、ルールに関連したエンティティに関する情報を捕獲する。ルールバインディングは、もしあれば、どんなランタイムデータがルールに使用できるか明確に定義することに関してルールコンテクストに影響する。ルールに関連したこのような各エンティティは、条件及びアクションを構築するのに使用できるデータのセットをルールに与えることができる。例えば、サービスプロキシーに結合されたＳＬＡルールは、そのサービスに対して使用可能なモニタリングメトリックをベースとする条件を含むことができる。
【０１４７】
先に述べたように、ルールは、条件のリスト及びアクションのリストを含むことができる。各ルールは、次の構造をもつことができる。
＜条件のセット＞の場合に、＜アクションのセットを実行する＞
【０１４８】
ルールは、ゼロ以上の条件を含むことができる。一実施形態において、条件を含まないルールは、常に、真であり、そしてルールがトリガーされるたびにアクションが実行される。条件は、異なるタイプのものでよく、即ちビジネスカレンダー、モニタリングデータ、ユーザプロフィール及び他の適当なタイプでよい。フレームワークは、顧客により望まれる新たな条件タイプを受け容れるためにランタイムに新たな条件タイプを容易にプラグインできるように設計される。
【０１４９】
一実施形態において、ルールに含ませることのできる条件のタイプは、ルールバインディングによって指令される。このステートメントに対する例外は、全てのルールに関連付けることのできるビジネスカレンダーのような条件である。というのは、ビジネスカレンダーの定義は、「グローバル」であり、特定のバインディングポイントに結び付けられないからである。各条件は、論理的ＯＲ及び論理的ＡＮＤ演算子を使用して任意に合成し及びネスト状にすることのできる１つ以上の表現で構成される。一実施形態において、条件は、全て、トップレベルにおいてＡＮＤされる。ルールに含まれる全ての条件は、真と評価されるべきルールについては、「真」と評価される必要がある。新たな条件タイプをランタイムにルールフレームワークに追加できるのと同様に、新たなアクションタイプをランタイムに登録することもできる。一実施形態では、警告フレームワークは、新たなアクション及び条件の追加を許すＳＰＩを定義することができる。
【０１５０】
ルールトリガーは、ルールを評価するプロセスをキックオフする役割を果たす。上述するように、ルール評価プロセスは、多数の異なるメカニズムによりトリガーすることができる。一実施形態では、説明上、これらのメカニズムは、更新されたモニタリングメトリックの利用性；事象契約、即ちルールエバルエーターが事象フレームワークと契約しそして事象が生じたときにルール評価をトリガーできるもの；及びタイマーベースのルール、即ちスケジューリングサービスが、ルールエバルエーターが契約するタイマー事象を発生し、そして固定のインターバルでルール評価をキックオフできるもの、を含むことができる。
【０１５１】
一実施形態において、ルールの評価は、ルールに含まれた条件の各々を評価し、そして全ての条件が真と評価される場合に、含まれたアクションを呼び出すことを含む。説明上、ルールエバルエーターは、ルールに含まれた各条件を経て進行し、そして各条件タイプに関連した対応するエバルエーターを呼び出して、条件を評価する。更に別の実施形態では、各条件タイプは、そのタイプの条件を評価できるエバルエーターを登録する。条件エバルエーターを登録することは、警告フレームワークによりパブリッシュされるＪａｖａ（登録商標）インターフェイスを実施することを含む。
【０１５２】
一実施形態において、ルールフレームワークは、サービスプロバイダーインターフェイス（ＳＰＩ）を与え、これを経て付加的な条件及びアクションタイプを登録することができる。一実施形態では、各アクション及び条件タイプは、個別のウェブアプリケーションとして実施される。アプリケーションが展開されるときには、リスナークラスがこれらの条件及びアクションタイプを登録する。
【０１５３】
一実施形態において、ルールバインディングは、ルールに関連付けできる位置を識別する。各サービス（外部及びプロキシーの両方）は、ルールを展開できるところの１つ以上のバインディングポイントを定義することができる。バインディングポイントは、そのサービスプロキシーにおける全てのパイプライン、ステージ及びトランスポートにより登録されるモニタリングメトリックを捕獲することができる。ルールは、このバインディングポイントに結合することができ、そしてこのバインディングポイントに得られるモニタリングメトリックを使用して条件を構成することができる。一実施形態において、コンフィギュレーションマネージャーに登録されたリスナーは、サービスプロキシーが生成／更新／削除されるたびに通知される。このリスナーは、サービスにおけるバインディングポイントを抽出して、それらを警告バインディングマネージャーに登録することができる。
【０１５４】
一実施形態において、ルールバインディングポイントを含む各「エンティティ」（サービス又はプロセス）は、そのエンティティが「存在」状態となったときにこれらバインディングポイントを警告マネージャーに登録することができる。サービスバスのサービスについては、これは、サービスが生成されるときにバインディングポイントが登録されることを意味する。ＢＰＭプロセスについては、この登録は、プロセスが展開されるときに生じる。一実施形態において、バインディングポイントのこのレポジトリーは、持続することができ、そしてコンソール及び他のツールが使用できるＪＭＸインターフェイスを経てブラウジングするのを使用できる。
【０１５５】
一実施形態において、警告マネージャーは、サービス／プロセス名を取り上げるＡＰＩと、新たなモニタリングメトリックを含むルールコンテクストとを与えることができる。次いで、警告マネージャーは、そのサービス又はプロセスに対して登録された全てのバインディングポイントをルックアップし、そして各バインディングポイントに結合された全てのルールを評価することができる。
【０１５６】
一実施形態において、コンフィギュレーション時間にポピュレートされる全ての情報に加えて、ルールコンテクストは、ルールバインディングによって発生される全てのランタイムデータを含むことができる。条件及びアクションエバルエーターは、このランタイムデータを抽出し、そしてそれに対応する値を、発生される警告に埋め込むことができる。以下のテーブルは、ルールコンテクストに使用可能なフィールドをリストしたものである。
【０１５７】
テーブル１：一実施形態によるランタイムルールデータ
【０１５８】
一実施形態において、ルールフレームワークは、ルールを構成するためにＪＭＸ ＡＰＩのセットを露出させることができる。これらのＡＰＩは、ルールを管理するために、挿入、検索、検証及び持続機能を与えることができる。これは、第三者ツールがＪＭＸレイヤーと直接対話して、ルールを管理すると共に、ＷＬＩ９．０アドミニストレーションコンソールを完全にバイパスするのを許すことができる。
【０１５９】
多数のルールを単一のバインディングポイントに関連付けることができる。ルールは、それらが配備された順序で実行することができる。ユーザは、いつでもこの順序を変更することができる。一実施形態において、ルールを生成することは、ルールをバインディングポイントに関連付けることを含む。例えば、これを行う２つの仕方は、次の通りである。
【０１６０】
１．バインディングポイントのブラウジング：アドミニストレータは、先ず、バインディングレポジトリーから全てのバインディングポイントをブラウズし、その１つを選択し、そしてそのバインディングポイントに関連したルールを生成する。
２．エンティティのブラウジング：この場合には、アドミニストレータは、先ず、ルールを関連付けしたいエンティティ（サービスバスのサービスディレクトリー又はＢＰＭプロセスビューア）を識別することによりスタートする。次いで、ユーザは、サービス／プロセスに利用できるルールバインディングポイントのリストが与えられ、そしてそれらバインディングポイントの１つを選択して、そのバインディングポイントに関連したルールを生成する。
【０１６１】
一実施形態において、各ルール条件及びアクションタイプは、アクション又は条件コンフィギュレーションデータを表わすためにそれ自身のスキーマを定義することができる。この条件又はアクションコンフィギュレーションは、シリアル化されたＸＭＬとして警告マネージャーへ返送され、そして警告マネージャーは、このデータをルール定義の一部分として持続させることができる。条件又はアクションを構成するときに各条件及びアクションタイプにルールコンテクストが通される。これは、条件コンフィギュレーションメカニズムが検証を実行して、そのバインディングポイントで使用可能なモニタリングデータエレメントが条件コンフィギュレーションに含まれるよう確保するのを許す。
【０１６２】
一実施形態において、特定のバインディングポイントへと展開されたルールは、その特定のバインディングポイントで使用可能なモニタリングデータエレメントを含むことができる。ＷＬＩコンソールを使用してルールを管理するユーザについては、この検証をコンソールにより自動的に実行することができる。このコンソールは、その関連バインディングで使用可能なデータエレメントを用いて、ルールに含まれた条件及びアクションを構成することを容易に保証できる。
【０１６３】
一実施形態において、モニタリングマネージャーは、モニタリングデータに対してクラスター巾のメトリックを集計し、そして更新されたモニタリングメトリックを使用可能とする各サービス／プロセスに対して各バインディングポイントに関連付けされたルールの評価をトリガーする。警告マネージャーは、最初に、特定のバインディングポイントに対するルールコンテクストを構成することができる。次いで、そのバインディングポイントへ展開される全てのルールをフェッチすることができると共に、ルールが構成された順序でその各々を評価することができる。ルールコンテクストが各条件及びアクションエバルエーターへ通される。ルールエバルエーターにおける全ての条件が真である場合には、そのルールに含まれたアクションが実行される。ルールランタイム状態オブジェクトは、各条件及びアクションをファイアーした結果を追跡する。この情報は、ユーザに既に通知された既存の条件に対して警告が繰り返しファイアーされないよう確保するために使用される。
【０１６４】
一実施形態において、ルールランタイム状態オブジェクトは、各アクション及び条件にも通される。このオブジェクトは、評価されるルールごとに追跡レコードを発生するのに使用できるレコードデータを配置するために各条件及びアクションに対してプレースホルダーを定義することもできる。いずれかのデータセットに含ませることのできる追跡データエレメントとして警告ログエントリーが発生される。追跡レコードは、コンソールに表示することができる。一実施形態において、ルーティングノードは、メッセージ処理グラフに対する要求／応答通信を与える。これは、メッセージを選択されたサービスへディスパッチし、そしてもし適用できれば、応答を待機するのに使用される。一実施形態において、ルーティングは、サービスプロキシーの一次メッセージ経路の一部分と考えられるので、受信された応答は、応答処理における応答メッセージとして使用することができる。一実施形態において、ルーティングノードは、ルートのセットを含む。ルートは、ターゲットサービス（例えば、サービスプロキシー又は外部プロキシー）を識別し、そしてメッセージをいかにパッケージしてそのサービスへ送信するか決定するある付加的なコンフィギュレーションオプションを含む。アウトバウンド変換は、メッセージ及びコンテクストを、ターゲットサービスへの送信の前に変更するのを許す変換アクションのセットである。応答変換も、同様に、受信した応答に適用される変換アクションのセットである。これら実施形態の態様において、ルート選択は、ｉｆ−ｔｈｅｎ−ｅｌｓｅブロック及びルーティングテーブルの組み合せにより条件付きで行われる。
【０１６５】
ルートを構成するときには、スキップと称される特殊なルートを指定するためのオプションも存在する。これは、単に、何も行わないルート、実際には、非ルートである。スキップは、これを選択すると、その後続ルートが考慮又は選択されるのを防止できるという点で、ルートと同様に振舞う。しかしながら、スキップルートでは、メッセージを送信できず、又、応答も期待できない。スキップルートは、更なるコンフィギュレーションをもたない。スキップの目的は、ユーザがルーティングを希望しないケースを明確に定義するオプションをユーザに許すことである。
【０１６６】
一実施形態において、アウトバウンド変換は、ターゲットサービスへ送信できるメッセージの形状をカスタマイズするのに使用される。これは、潜在的に、メッセージそれ自体（例えば、ペイロード、ＳＯＡＰヘッダー）、並びにトランスポート特有の細部、例えば、トランスポートヘッダー、再試みカウント、代替ＵＲＩ、等を変更することを含む。これは、変換ステージに現在露出される変換アクションの標準セットを使用して行うことができる。指定、更新及び削除に加えて、アウトバウンド及び応答変換は、条件、ＷＳ−コールアウトを使用し、そしてエラーを生じさせることもできる。一実施形態において、応答変換は、応答メッセージの形状を、それが応答経路処理のためにパイプラインへと折り返される前に、カスタマイズするのに使用される。ここでは、アウトバウンド及び応答変換は、サービスプロキシーにより使用される要求／応答フォーマットと、ターゲットサービスにより使用される要求／応答フォーマットとの間で効果的に変換を行うように一緒に使用できるものとする。又、応答変換は、ＳＯＡＰ又はビジネス欠陥のようなメッセージレベル欠陥をチェックするのにも使用できる。メッセージ欠陥が検出された場合には、通常の変換ステージと同様に、エラー状態を発生することができる。
【０１６７】
一実施形態において、条件付きルーティングを実行するために、ｉｆ−ｔｈｅｎ−ｅｌｓｅブロックにおいてルートをラップすることができる。条件は、ブール値ＸＱｕｅｒｙ表現でよく、そしてブロックは、任意にネスト状にすることができる。更に別の実施形態では、最終的なアクションがルート又はルーティングテーブルである。一実施形態において、ルーティングテーブルは、スイッチスタイルの条件テーブルでラップされたルートのセットを含む。これは、単一のＸＱｕｅｒｙ表現の結果に基づいて異なるルートを選択するのを許す省略構成である。
【０１６８】
一実施形態において、ルーティングテーブルは、単一のｗｈｅｒｅ条項と、１つ以上のケースのセットとで構成される。ｗｈｅｒｅ条項は、ＸＱｕｅｒｙ表現を含み、そしてメッセージコンテクストの任意の部分を参照することができる。各ケースは、比較演算子と、値表現と、ケースアクションとして働く少なくとも１つのルートとで構成される。全ルーティングノードは、１つのルートの選択を生じるので、ケース当たり多数のルートがサポートされるのではない。先行するケースが満足され名場合には、ルートが選択される端において、デフォールトケースを追加することができる。
【０１６９】
ルーティングテーブルの一例を以下に示すが、これは、必ずしも、コンフィギュレーションコンソールにおいてテーブルをいかに提示できるかを表わすものではない。又、明瞭化のために、ルートの詳細も省略する。
ｗｈｅｒｅ：データ（＄ｍｅｓｓａｇｅ／順序−量）
比較器 値 ルート
＞＝ 100000 ゴールドサービスルート
＞＝ 10000 シルバーサービスルート
その他 標準サービスルート
【０１７０】
ルーティングテーブルは、等号に加えて多数の異なる比較演算子をサポートする。更に、ルーティングテーブルにおける値表現は、ＸＱｕｅｒｙ表現であり、単純な定数値である必要はない。これら実施形態の態様において、ルーティングテーブルは、ｗｈｅｒｅ条項においてＸＱｕｅｒｙ表現を最初に評価することにより評価される。各ケースは、次いで、ｗｈｅｒｅ条項の結果をケースの値表現の結果と比較するために選択された比較演算子を使用することによりリストされた順序で検査される。比較が満足である場合には、それに対応するルート（１つ又は複数）を選択することができる。
【０１７１】
一実施形態において、メッセージディスパッチは、ルーティングノードのランタイムの一部分として実行される。基本的な実行フローは、最初に、条件及びルートテーブルを評価して、ルートが選択されたかどうか調べることである。ルートが選択されていない場合には、ルーティングノードが完全と考えられ、そして応答処理がメッセージコンテクストの現在状態で直ちに開始する。ルートが選択された場合には、それに対応するアウトバウンド変換が、次いで、コンテクストに適用される。次いで、メッセージは、バインディング及びトランスポートレイヤーを経てサービスへ送信される。応答メッセージが期待されない場合には、ルーティングノードが終了と考えられ、そして応答処理が開始される。さもなければ、ルーティングノードは、応答が到達するまで依然アクティブと考えられる。これが生じると、応答変換が適用され、そしてルーティングノードは、終了したと考えられる。一実施形態において、バッチ更新特徴は、サービスバスコンポーネントへの変化を「セッション」において生じさせ、そこに累積して一緒に適用できるようにするのを許す。説明上、ユーザ（コンソールを経て）又はプロセスは、特殊な「バッチセッション」を生成し、そこで、変化が累積されるようにする。バッチセッションでなされた変化は、「コア状態」にセーブされず、むしろ、セッションにセーブされる。これら変化は、それを「コミット」する前に再検討することができる。一実施形態において、変化を直ちにコミットすることができなくてもよい。例えば、コミットは、そのように行うことが許されず、従って、無効な「コア状態」を生じさせる（例えば、それがサイクルを生成し、未分析の参照を生じさせ、等々の場合）。バッチセッションをコミットできると仮定すれば、これら変化が累積されて、コア状態へ反映される。
【０１７２】
一実施形態において、バッチセッションは、どんなコンポーネントがセッションデータにおいて削除され、生成され又は更新されるか追跡する。このデータは、サービスバスの再スタート及びクラッシュに生き残るように存続される。コア状態は、サーバーバスが実行されるメインコンフィギュレーションである。セッション内でなされる変化は、セッションがコミットされるときにコア状態に反映される。コア状態は、最終的に、サービスバスの振舞いを定義する。セッションビューは、セッション中に誰かにより観察されるコンフィギュレーションの状態である。セッションビューは、物理的なデータエントリーではない。これは、コア状態を取り上げてセッションデータを適用することで導出される。バッチ更新は、セッションにおいてサービスバスコンフィギュレーションを変更し、次いで、これら更新をコミットするというアクティビティである。
【０１７３】
一実施形態において、バッチセッション（又は単にセッション）は、サービスバスにおけるバッチ更新サポートの中心的断片である。セッションは、ユーザ及び／又はプロセスにより生成される。いかなる数のセッションが同時に生成されてもよい。各セッションは、そのセッションで実行される変更により決定されたシステムの異なるビューをもつことができる。セッションデータは、永続的であり、クラッシュ又は再スタートに生き残ることができる。セッションは、どんなコンポーネントがユーザにより更新され、生成され及び削除されるか追跡する。これは、セッションデータと称される。セッションデータは、コア状態と共に、セッションビューを定義し、例えば、そのセッションにおいてどんなコンポーネントが見えるか、及びそれらがどんな値を含むか定義する。
【０１７４】
一実施形態において、ＳｅｓｓｉｏｎＭＢｅａｎを経てセッションマネージャーにおけるメソッドを呼び出すことによりセッションが生成される。セッションは、ＳｅｓｓｉｏｎＭＢｅａｎを使用してプロセスにより生成することもできるし、又はコンソールにおいて生成することもできる。コンフィギュレーション変化（更新、削除、生成）は、セッション内で実行することができる。コンフィギュレーションを更新するサービスバスＭＢｅａｎメソッドは、セッション名、例えば、
public void createService (String session, Ref serviceref, ServiceDef definition);
を受け容れるように変更することができる。
【０１７５】
ＭＢｅａｎを使用する外部クライアントは、セッション名を供給するだけでよく、そしてそのメソッドにより実行される更新は、そのセッションに累積することができる。クライアントが多数の更新を全て異なるセッションにおいて実行することが考えられる。以下の例では、Ｊａｖａコードは、セッション１においてサービスを更新し、そしてセッション２においてサービスプロバイダーを削除する。これら２つのセッションは、どんなコンフィギュレーションに似ているかの異なるアイデアをもつことができる。セッション１は、サービスプロバイダーが依然存在すると考えることができ、そしてセッション２は、サービスが古いコンフィギュレーションを有すると考えることができる。
servicembean.updateService (“session1”, service1, newServiceData);
serviceprovidermbean.deleteProvider (“session2”, serviceprovider2);
【０１７６】
一実施形態において、コンソールユーザは、新たなセッションを生成するとき、又は既存のセッションを取り上げて機能させるときに、セッションに入る。同じユーザが異なるセッション間を切り換えることもできるし、異なるユーザが異なるセッションにおいて同時に機能することもできる。セッションにより見たコンフィギュレーションのビューは、他のもの及びコア状態のビューとは異なる。ユーザがサービスＡを生成し、サービスＢを削除し、そしてその後に、サービスのリストを要求する場合には、Ａがリストにあるが、Ｂはないことが分からねばならない。しかしながら、実際のコンフィギュレーション（コア状態）は、Ａをもつことができないが、Ｂは、セッションがコミットされるまでもつことができる。一実施形態において、ＭＢｅａｎ読み取りメソッド（例えば、ゲッター、リストメソッド、サーチメソッド）は、任意のセッションパラメータを受け容れることができる。セッションパラメータがナルである場合には、データをコア状態から得ることができる。セッションパラメータがナルでない場合には、セッションにより見たコンフィギュレーションのビューが返送される。例えば、コア状態がサービスＢ及びＣを含むと仮定する。更に、ユーザがセッションＳ１を生成し、そしてサービスＡを生成し、次いで、このセッションにおいてサービスＢを削除するが、これらの変化をまだコミットしないと仮定する。ｌｉｓｔＳｅｒｖｉｃｅ（ストリングセッション）メソッドは、次のセッションに基づいて異なる結果を返送することができる。
listServices (null) returns B and C
listServices (“S1”) returns A and C
【０１７７】
コンソールユーザは、いずれのセッションにもない場合にコア状態を見る。ユーザは、その変化で満足されると、その変化をコミットし、検証を受けることができる。コミット動作は、ユーザがセッションにおいて行った変化をコア状態に適用する。セッションがコミットされると、もはや使用できないので、削除される。又、ユーザは、セッションを破棄することもできる。これは、単に、セッションデータ状態を削除し、コア状態には影響を及ぼさない。ユーザは、ユーザが現在いるセッションを、コミットしたり破棄したりせずに、立ち去ることができる。このようにすることで、ユーザは、コア状態を見ることが許されるか、又は別のセッションへスイッチすることができる。
【０１７８】
図１１ａ−ｂは、一実施形態に基づき種々の変更がセッション及びコアにおいて実行された後のコア状態、セッションデータ、及びセッションビューである。異なる幾何学的形状を使用して、コンポーネントにより取り上げられた異なる値をハイライトすることができる。セッションビューにおいて太い線をもつ形状は、そのコンポーネントがセッションにより変更されており、従って、その存在及び値がコア状態における同じコンポーネントとは異なることを指示する。セッションビューにおいて通常の線をもつ形状は、そのコンポーネントがセッションにおいて変更されておらず、従って、その存在及び値がコア状態から得られることを指示する。
【０１７９】
図１１ａは、コンポーネントＡ、Ｂ及びＣを含む初期コア状態を示す。セッションにおいて更新はなされておらず、従って、セッションビューは、コア状態に何が含まれるか厳密に反映する。図１１ｂは、セッションデータの更新を示している。コンポーネントＢは、セッションにおいて更新されている。この事実は、セッションデータに記録され、そしてセッションデータは、次いで、セッションビューを計算するために、コア状態と一緒に使用される。
【０１８０】
図１２ａ−ｃは、一実施形態による付加的なセッションシナリオを示す。図１２ａにおいて、コンポーネントＤがセッション中に生成される。Ｄは、セッションビューでは見えるが、コア状態では見えないことに注意されたい。図１２ｂにおいて、コンポーネントＡがセッション中に削除され、それ故、セッションビューは、コンポーネントＡをもはや含まない。しかしながら、セッション中にないユーザは、コア状態を見、そしてコンポーネントＡがコア状態に存在することを観察する。最終的に、図１２ｃは、２つの変更がコア状態において行われ（おそらく別のセッションをコミットすることにより）、即ちコンポーネントＢが削除されそしてＣが更新された後のコア状態及びセッションビューを示す。これら２つの変化は、セッションビューにおいて、それら自体、異なる仕方で現われる。Ｃへの更新は、セッションビューに見ることができる。というのは、Ｃは、セッションにより変更されないからである。しかしながら、Ｂの削除は、セッションにおいて見ることができない。というのは、Ｂは、セッションにより変更され、従って、その値は、セッションデータから直接得られるからである。このケースは、セッションのデータ／ビューとコア状態との間の「競合」の例である。このようなシナリオは、同じアイテムが２つのセッションにより互換性なく変更される場合に生じる。セッションの一方が破棄されない限り、第２のセッションをコミットしたときに競合を解消することができる。
【０１８１】
一実施形態において、セッションデータは、本質的に、そのセッションにおいて変更（生成、更新又は削除）された全てのコンポーネントに対するレコード（情報）のリストである。そのセッションにおいてたとえ何回変更されても（例えば、生成され、削除され、次いで、再び生成されても）、このような各コンポーネントに対して厳密に１つのレコードしかない。このレコードは、コンポーネントがセッションにより初めて更新されるときに生成される。同じコンポーネントに対して更なる変更が実行されるときにそれが更新される。そのコンポーネントに対してセッションにより実行された全ての更新がアンドゥされた場合にレコードが除去される。セッションデータは、ファイルシステムにおいて存続される。又、セッションデータは、セッションが生成されたときのコンフィギュレーションデータのスナップショットではない（サーバーは、スナップショットに基づくセッションデータを使用する）ことに注意されたい。
【０１８２】
一実施形態において、以下は、生成、更新及び削除オペレーションに対するロジックを与える。
１）セッションＳにおいてＡを生成する：
ａ）Ａがセッションにおいて削除された場合には、ＣＲＥＡＴＥ（Ａに対する既存のセッションデータを更新する）
ｂ）その他、Ａがセッションデータに存在する場合は、ＥＲＲＯＲ（再生成できない）
ｃ）その他、Ａがコア状態に存在する場合は、ＥＲＲＯＲ（再生成できない）
ｄ）さもなければ、ＣＲＥＡＴＥ（セッションデータにおいてＡに対する新たなレコードを生成する）
【０１８３】
２）セッションＳにおいてＡを更新する：
ａ）Ａがセッションにおいて削除された場合には、ＥＲＲＯＲ（Ａがセッションに存在しない）
ｂ）その他、Ａがセッションデータに存在する場合には、ＵＰＤＡＴＥ（Ａに対する既存のセッションデータを更新する）
ｃ）その他、Ａがコアに存在する場合には、ＵＰＤＡＴＥ（セッションデータにおいてＡに対する新たなレコードを生成する）
ｄ）その他、ＥＲＲＯＲ（Ａは、コア状態に存在しない）
【０１８４】
３）セッションＳにおいてＡを削除する：
ａ）Ａがセッションにおいて削除された場合には、ＥＲＲＯＲ（Ａがセッションに存在しない）
ｂ）その他、Ａがセッションデータに存在する場合は、適切な参照完全性チェックの後にＤＥＬＥＴＥ
ｃ）その他、Ａがコア状態に存在する場合には、適切な参照完全性チェックの後にＤＥＬＥＴＥ
ｄ）その他、ＥＲＲＯＲ（コア状態に存在しない）
【０１８５】
一実施形態において、読み取りオペレーションは、ユーザがセッションビュー（コア状態ではなく）を見ているという錯覚を与える。それらは、セッションデータ及びコア状態を使用することによりこれを行う。次のロジックは、一実施形態における読み取り（取得）オペレーションの実施を記述する。
１）セッションＳにおいてＡを読み取る：
ａ）セッションにおいてＡが削除された場合に、ナルを返送する
ｂ）その他、セッションにＡが存在する場合に、その値をこのセッションにおいて返送する
ｃ）その他、コア状態にＡが存在する場合に、その値をコア状態において返送する
ｄ）その他、ナルを返送する
【０１８６】
一実施形態において、バッチセッションは、ユーザが、そのセッションにおいて行ったオペレーションを、時間的に厳密に逆の順序で、アンドゥするのを許す。
【０１８７】
一実施形態において、セッションがコミットされるときに、システムは、コア状態に変化を適宜に反映させることができる。コミットは、本質的に、セッションにより変更される種々のコンポーネントに対して一連の更新、削除又は生成を生じさせる。一実施形態において、セッションのコミットは、原子的である。換言すれば、それが中間に入る場合、又はサービスバスがクラッシュする場合には、それまでになされた変化をロールバックすることができる。
【０１８８】
一実施形態において、コミットが矛盾したコア状態を生じない場合にはセッションをコミットすることができる。一実施形態において、次のいずれか１つが真である場合には、コミットが許されない。
【０１８９】
１）セッションのコンポーネントにより参照される幾つかのコンポーネントがコア状態において削除される。これが図１３ａに示されている。コンポーネントが生成され、そして既にコア状態にあるコンポーネントＢを参照する。Ｂがコア状態から削除される。コア状態は有効であるが、セッションは、ＡからＢへの無効参照を含む。
【０１９０】
２）コア状態への変更がセッションビューにあるサイクルの参照を発生することがある。これが図１３ｂに示されている。このようなセッションをコミットすると、コア状態へサイクルを導入することになり、従って、コミットが許されない。それ以降の図において、最初にＡを更新して、それがＢを参照するようにすることにより、サイクルが導入される。次いで、Ｂが、コア状態において、Ａを参照するように変更される。コア状態を見ている者は、ＢからＡへの参照を見ることができるが、セッション中のユーザは、Ａを参照するＢ及びＢを参照するＡの両方を見ることができる。
【０１９１】
３）図１３ｃは、削除できるコンポーネントによる参照完全性違反を示す。コンポーネントがセッションにおいて削除されると、セッションマネージャーは、そのコンポーネントへの参照がないことを確保するためのチェックを行う。削除の後、コンポーネントは、セッションビューにもはや存在しない。しかしながら、セッションがまだコミットされないので、このコンポーネントは、セッションの外部のユーザに見える。コア状態におけるコンポーネントは、セッションにより削除されたコンポーネントを指すように変更されることが考えられる。このようなシナリオは、コミットを行うと、無効の参照となるので、コミットを行えないことを意味する。
【０１９２】
４）セッション及びコア状態における競合する変更。同じコンポーネントがセッションにおいて変更されると共に、コア状態においても変更される（別のセッションのコミットにより）ことがあり得る。例えば、セッションは、コンポーネントを削除してもよく、一方、同じコンポーネントが新たな値で更新されてもよい。このような競合する更新は、ユーザにより明確に解決することができる。この問題は、本書において以下で詳細に探求する。
【０１９３】
５）進行中のサーバー変化リストの競合。セッションにおいて実行されるあるオペレーションは、サーバーへの変更を生じさせる。例えば、サービスを生成すると、通常、サーブレット又はＭｄａｔａｂａｓｅｓが配備される。しかしながら、これらの変化は、サーバーロックを要求すると共に、変化リストにおいて提示されることを必要とする（サーバーは、それらのセッション変化リストをコールする）。不都合なことに、サーバーは、多数の変化リストを許さない。進行中のサーバー変化リストが既にあれば、サービスバスは、それ自身の変化をサーバーへコミットすることができない。
【０１９４】
テーブル２は、競合シナリオと、一実施形態によりシステムがこのような競合をいかに自動的に解決できるかとを示す。又、このテーブルは、セッション及びコア状態の両方において全く同じ変更がなされるために競合を招くことがない３つの同時変更シナリオも示すことに注意されたい。このテーブルは、４つの列を有する。第１の列は、変更される前のコンポーネントの最初の値を表わす。この列のナル値は、コンポーネントが最初に存在しなかったことを示す。第２及び第３の列は、各々、コア状態及びセッションにおけるコンポーネントの値を表わす。これらの列のナル値は、コンポーネントが削除されたこと（又は全く生成されないこと）を示す。第４の列は、競合を説明すると共に、競合をいかに解消できるかについて述べる。一実施形態において、テーブル２を参照すれば、システムにより競合を解決できる仕方は３つあって、「アクセプトセッション(ACCEPT SESSION)」、「アクセプトコア(ACCEPT CORE)」、及び更新競合の場合には、「マージ(MERGE)」である。
【０１９５】
テーブル２：一実施形態による競合解決
注：1 これをいつも行うことができるかどうかは分からない。
2 このケースでは、コンポーネントは、セッションにおいても生成されるが、次いで、削除される。
【０１９６】
一実施形態において、更新プランは、サーバーによりどんなアクションを実行すべきか記述するオブジェクトである。各サーバーに存在する変化マネージャーは、更新プランに記述されたアクションを実行する役割を果たす。アドミニサーバーにおいて実行される更新プランは、マネージされるサーバーにおいて実行されるものとは異なってもよい。
【０１９７】
このセクションは、更新をいかに実行するかの非常に高レベルの概要を与える。これは、更新及び回復の完全な叙述を意味するものではない。
【０１９８】
一実施形態において、更新は、次のケースにおいて開始される。
−ユーザ更新：ユーザは、バッチ更新をコミットする。アドミニサーバー及びマネージされるサーバーにおいて更新プランが発生されて実行される。これらの更新は、通常、アドミニサーバー及びマネージされるサーバーにおいて行われる。
−マネージされるサーバーの回復：マネージされるサーバーは、アドミニサーバーからの長期切断の後に、そのコンフィギュレーションデータが古くなっていることが分かる。従って、アドミニサーバーから更新プランを要求し、これは、マネージされるサーバーにおいて実行することができると共に、マネージされるサーバーのコンフィギュレーションを最新の状態にもっていくことができる。更新は、本質的に、「デルタ」である。
【０１９９】
ユーザ更新のケースでは、更新プランが最初にアドミニサーバーにおいて実行され、そしてこれが首尾良くいった場合に、マネージされるサーバーへ同時に（且つ非同期で）送信されて、そこで実行される。マネージされるサーバーの回復のケースでは、マネージされるサーバーは、最初に、それが知っている全てのリソースのダイジェスト及びそれらのバージョンナンバーを送信する。次いで、アドミニサーバーは、これをそれ自身のデータと比較し、そして何らかの食い違いがある場合に、マネージされるサーバーにおいて実行できる更新プランを作成する。
【０２００】
一実施形態において、更新プランは、サービスバスに対して特別に構成された良く知られたＪＭＳトピックを使用して、マネージされるサーバーへ送信される。各サーバー（アドミニを含む）は、プランを受け取って、それを実行し、そしてその結果をアドミニサーバーへ報告する役割を果たす変化マネージャーコンポーネントを有する。各サーバーは、それが受け取った更新プランを実行する役割を果たす。アプリケーション欠陥（例えば、サーバークラッシュではなく例外）のためにプランの実行がフェイルした場合には、サーバーは、更新プランにより実行された全ての変化を、更新プランを実行する前に存在したコンフィギュレーションの状態へロールバックする役割を果たす。換言すれば、サーバーにおけるプランの実行は、原子的である。これは、成功か又は失敗のいずれかである。いずれにせよ、その結果がアドミニサーバーへ報告される。
【０２０１】
更新が、あるサーバーでは成功したが、他のサーバーでは失敗することが考えられる。これが生じると、成功であるサーバーの更新をロールバックし又はアンドゥすることができる。サーバーは、更新の実行中にクラッシュすることがある。これが生じると、スタートアップ中に回復を実行しなければならない。一実施形態において、説明上、回復は、次のステップを含む。
【０２０２】
１）実行されたがコミットされていないローカルワークをロールバックする。サーバークラッシュが生じたので、持続データ（ファイル）を回復して、その前映像へロールバックする必要がある。
２）更に、マネージされるサーバーにある場合には、
ａ）コンフィギュレーションの現在内容のダイジェストをアドミニサーバーへ送信し、そしてデルタを受け取る。
ｂ）これらのデルタをローカルに適用して、マネージされるサーバーのコンフィギュレーションをアドミニサーバーと共に最新の状態へもっていく。
【０２０３】
一実施形態において、更新プランは、サービスバスコンフィギュレーションへ適用する必要のある変化を記述する。更新プランは、アドミニサーバー及びマネージされるサーバーにおいて実行され、そして個々の変化を記述する「タスク」のリストを含む。一実施形態において、５つの形式のタスクがある：コンポーネント生成タスク；コンポーネント更新タスク；コンポーネント削除タスク；フォルダー又はプロジェクト生成タスク；及びフォルダー又はプロジェクト削除タスク。一般に、更新プランは、最初に、フォルダー又はプロジェクト生成タスクを実行した後に、多数のコンポーネントタスクを実行し、そしてフォルダー及びプロジェクト削除タスクで終了となる。
【０２０４】
一実施形態において、更新プランにおける各タスクは、次の機能を発揮する。
−検証：システムにおいて変更を行わずに影響されるデータを検証する。
−実行：検証されると、単にコンフィギュレーション変化を実行する。即ち、スタフ(stuff)を生成し、更新しそして削除する。
【０２０５】
図１４は、一実施形態による更新プラン実行を示す図である。この図は、更新プラン１４０２がいかに実行されそしてどんなモジュール／サブシステムが与えられるか示す。又、この図は、更新に参加できる３つの主たるプレーヤ、即ちあるものを専門に扱うコンフィギュレーションフレームワークにおける種々のマネージャー（１４００、１４０４、１４０６、１４０８）；更新プラン、タスク等のデータ構造体；及び種々のステートフルなエンティティ（１４１０、１４１４、１４１６、１４１８）を示し、これらは、ある状態を保持する種々の断片である。これらは、ランタイムキャッシュ、持続データ、及びシステム内の他のモジュール（例えば、コンパイルされたＸＱｕｅｒｙプランのキャッシュを保持するＸＱｕｅｒｙマネージャー）により保持される他のデータである。
【０２０６】
一実施形態において、変化マネージャー１４００が更新プラン１４０２を取得してそれを実行するときに更新が開始される。この実施形態の態様において、更新プランは、単に、順次に実行することのできるタスク１４１２のリストである。これらのタスクは、コンポーネント１４２０、フォルダー又はプロジェクト１４１８を更新／生成／削除／再命名するためにプロジェクトマネージャー１４０４又はコンポーネントマネージャー１４０６のメソッドを呼び出す。プロジェクトマネージャー及びコンポーネントマネージャーは、次いで、ランタイムキャッシュ１４１４、参照グラフ、及びファイル１４１６のような当該ステートフルエンティティを更新する。更に別の実施形態では、ファイル更新は、ファイルマネージャーにより取り扱われる。
【０２０７】
一実施形態において、コンポーネント（例えば、サービスマネージャー）１４１０への更新を聴取する種々のモジュールがある。これらモジュールは、特定のコンポーネントタイプに発生する変化を登録し、そしてそのコンポーネントタイプのインスタンスが生成され、削除され、更新され又は再命名されるときに通知がなされる。リスナーは、通常、これらの通知に応答して、それ自身の内部状態を更新する。例えば、トランスポートマネージャーは、サービスの定義に対してなされる変化に基づいてトランスポートエンドポイントを展開／非展開／保留／再開する。これらのリスナーは、エラーが生じたときにロールバックすることのできる状態を保持する。
【０２０８】
一実施形態において、適切な回復を容易に行うために、変化マネージャーは、プランの実行に関する次の事実を持続的に記録することができる。
１）プランの実行の始めに、実行がスタートしたことを指示するレコードをディスクに書き込む。「ＳＴＡＲＴＥＤ」のような簡単なストリング値で充分である。
２）首尾良い実行の後に、実行が首尾良く終了したことを指示するレコードをディスクに書き込む。「ＳＵＣＣＥＳＳ」のような簡単なストリング値で充分である。
３）アプリケーションの失敗の後に、実行が失敗しそして回復が進行中であることを指示するレコードをディスクに書き込む。「ＦＡＩＬＥＤ」のような簡単なストリング値で充分である。
【０２０９】
一実施形態において、アプリケーションの失敗又はサーバークラッシュの後に回復が開始される。第１のケースでは、アプリケーションの失敗の後に更新がストップされ、そして回復が直ちにスタートされる。第２のケースでは、クラッシュの後にサーバーが再スタートするときに回復が実行される。ロールバックは、オペレーション（のグループ）の作用をアンドゥすることを意味する。これに対して、回復は、多数のロールバックを伴うことのあるより一般的なアクティビティ、及び潜在的に多数の他の種類のアクティビティ、例えば、分散型環境における異なるエンティティ間のデータの交換、又は潜在的なリドゥオペレーションを意味する。それでも、これら２つの語は、交換可能に使用できる。
【０２１０】
あるオペレーションＯＰがデータ（例えば、状態）の断片の値をＶ1からＶ2へ変化させると仮定する。このオペレーションは、次の２つの仕方でロールバックすることができる。１）値ベースの解決策（物理的ロールバック）：Ｖ１をこのオペレーションに対する前映像としてセーブし、次いで、ロールバック時にその値へ戻す；及び２）演算的解決策（論理的ロールバック）：オペレーションＯＰの逆数（ＯＰRと称する）を現在値Ｖ2に適用して、Ｖ1を得る。一実施形態において、両解決策は、どのステートフルなエンティティがロールバックされるかに基づいて使用することができる。例えば、前映像（値ベースの解決策）をファイル更新に使用するのが有意義である。これは、クラッシュ回復が、影響のある全てのファイルをそれらの前映像に単に置き換えるのを許す。他方、通知に応答して種々のマネージャーにより実行される状態変化をロールバックするために、演算的解決策を使用する。
【０２１１】
図１５ａは、一実施形態による首尾良い更新を示す。一般に、サーバーは、アプリケーション例外後のロールバック中にクラッシュするか、又はサーバーは、サーバースタート後の回復中にクラッシュすることが考えられる。埋められた円は、そこでシステムがクラッシュし得ることを示す。
【０２１２】
図１５ｂにおいて、実行がアプリケーション例外のためにフェイルし、そして一実施形態では、直ちに回復がスタートする。プランの実行をロールバックすることは、主として、演算的ロールバック解決策に依存する。
【０２１３】
一実施形態において、プランが実行されるときには、そのタスクの各々をあるシーケンスで単に実行する。タスクが実行される前に、そのタスクに対してアンドゥタスクが生成される。このアンドゥタスクは、基本的に、タスクの作用をロールバックするのに使用できる逆のオペレーションである。これら実施形態の態様において、これらのアンドゥタスクは、メモリに累積される。タスクが失敗すると、プランの実行がストップし、そして累積されたアンドゥタスクが逆の順序で実行される。例えば、プランが３つのタスク、即ち更新ポリシーＰ、生成サービスＳ、並びに削除ＸＱｕｅｒｙＸ及びＸＱｕｅｒｙ失敗の削除を有すると仮定する。次のリストは、何が実行されるかを列挙する。
【０２１４】
１）更新ポリシーＰに対してアンドゥタスクを得る。これをアンドゥタスク１と称する。
２）「更新ポリシーＰ」を実行する。これが成功となる。
３）生成サービスＳに対してアンドゥタスクを得る。これをアンドゥタスク２と称する。
４）「生成サービスＳ」を実行する。これが成功となる。
５）削除ＸＱｕｅｒｙＸに対するアンドゥタスクを得る。これをアンドゥタスク３と称する。
６）「削除ＸＱｕｅｒｙＸ」を実行する。これが失敗となる。
７）ロールバックがスタートする。
８）アンドゥタスク３が実行される。
９）アンドゥタスク２が実行される。
１０）アンドゥタスク１が実行される。
【０２１５】
一実施形態において、生成及び削除に対するアンドゥタスクは、削除及び生成タスクである。更新タスクについては、アンドゥタスクが、コンポーネントをその最初の値で更新する別の更新タスクとなる。同様に、再命名タスクについては、アンドゥタスクが、コンポーネントをその最初の名前に再命名して戻す別の再命名タスクである。又、タスクフレームワークは、プログラマーがアンドゥタスクをカスタマイズするのも許す。
【０２１６】
一実施形態において、タスクの実行が進められるときに、ファイルの更新は、ドゥ／アンドゥスタイルでは行われない。タスクが実行され、そしてロールバックのケースでは、そのアンドゥタスクが実行される。ファイルと共に、ファイル更新が先ず「準備」され、そして全プラン実行の終りに、プラン実行が成功であったかどうかに基づいて更新が「コミット」されるか又は「ロールバック」される。例えば、コンフィギュレーションファイルＦ１及びＦ２は、コンポーネントＣ１及びＣ２に対するあるコンフィギュレーション変化の結果として、更新／生成／削除されると仮定する。次のことが生じる。
【０２１７】
１）コンポーネントＣ１が変化される。これは、ファイルＦ１を当該データで準備させる。
２）コンポーネントＣ２が変化される。これは、ファイルＦ２を当該データで準備させる。
３）全プラン実行が成功した場合（例えば、コミット）、最終的なステップとして、次のことを行う。
ａ）ファイルＦ１へ更新をコミットする。
ｂ）ファイルＦ２へ更新をコミットする。
４）さもなければ、ロールバックの一部分として、次のことを行う。
ａ）Ｆ１へ更新をロールバックする。
ｂ）Ｆ２へ更新をロールバックする。
【０２１８】
次のテーブルは、一実施形態においてファイルの生成、更新及び削除をどのように進めるか示す。準備、コミット及びロールバックと命名された列は、これらの段階中に何が生じるか示す。（これらアクションは、フォルダーの生成、又は削除にも適用される。）
【０２１９】
テーブル３：一実施形態によるファイルオペレーション
【０２２０】
ファイルに対するコミット及びロールバックオペレーションは、ＳＵＣＣＥＳＳ又はＦＡＩＬＥＤレコードがＬＡＳＴ＿ＴＲＡＮＳＡＣＴＩＯＮ＿ＩＮＦＯファイルまで持続された後に実行される。これは、通常の実行又はロールバック実行中にサーバークラッシュの後に回復を許す設計上の判断である（これは、次のセクションの詳細を検討したときに読者に分かるかもしれないし分からないかもしれない）。
【０２２１】
図１５ｃは、サーバークラッシュによる実行失敗と、サーバー再スタート後に回復がスタートするところを示す。サーバークラッシュ後に、存続データ（例えば、ファイル）への変化を回復する必要がある。一実施形態において、これは、システムにより次のように行うことができる。
【０２２２】
１）ＬＡＳＴ＿ＴＲＡＮＳＡＣＴＩＯＮ＿ＩＮＦＯファイルを使用して、最後の更新が成功したか否か決定する。
２）最後の更新が失敗となるか又は進行中である場合に（ＬＡＳＴ＿ＴＲＡＮＳＡＣＴＩＯＮ＿ＩＮＦＯがＦＡＩＬＥＤ又はＳＴＡＲＴを含む）、先のセクションで要約を述べたようにファイル更新をロールバックする必要がある。基本的に、「Ｘ．ｎｅｗ」という名前のファイルをサーチしそしてそれらを削除し、次いで、「Ｘ．ｏｌｄ」という名前の全てのファイルを「Ｘ」へ再命名する。
【０２２３】
３）最後の更新が成功であった場合に、依然、ある作業を行う必要がある。「ＳＵＣＣＥＳＳ」レコードを書き込んだ後、依然、ファイル更新をコミットしている間に、更新が失敗となることが考えられる。従って、「Ｘ．ｏｌｄ」という名前のファイルを単にサーチして削除し、次いで、「Ｘ．ｎｅｗ」という名前の全てのファイルを「Ｘ」へ再命名する。これは、「リドゥ」オペレーションと同様の種類である。
４）全てのファイルが回復されると、ＬＡＳＴ＿ＴＲＡＮＳＡＣＴＩＯＮ＿ＩＮＦＯファイルを単に除去する（又はある空きストリングをそこに入れる）。
【０２２４】
このメカニズムは、たとえサーバーが回復中に何回もクラッシュしても、システムがファイルを回復するのを許す。
一実施形態において、マネージされるサーバーの回復は、次のように取り扱われる。
１）スタートアップ中に、マネージされるサーバーは、先のセクションで述べたように、ローカル回復を実行する。
２）次いで、アドミニサーバーにコンタクトし、それが知っているコンフィギュレーションデータに関するダイジェスト情報を送信する。このダイジェストは、それが知っている全てのコンポーネントのｉｄと、それらのバージョンナンバーとを含む。
３）アドミニサーバーは、このダイジェストを、それが有するコンフィギュレーションと比較し、そしてマネージされるサーバーが失うか、古くなるか、又は単に有してはならないのはどんなコンポーネントか決定する。次いで、アドミニサーバーは、そのマネージされるサーバーのみに対するプランであって、実行時に、マネージされるサーバーを、アドミニサーバーにおけるメインコンフィギュレーションに関して最新の状態へともっていくことのできるプランを準備しそして更新する。
【０２２５】
一実施形態において、説明上、ゆるく連合されたシステムにおいてオペレーションを実行するときには、２段階のコミット（２ＰＣ）が要求される。
１）各参加者（リソースマネージャー）は、オペレーションを準備するが、まだコミットしない。準備が成功すると、ＯＫメッセージを２ＰＣコーディネーターへ送信する。
２）２ＰＣコーディネーターが全ての参加者からＯＫを得ると、コミット信号を送信する。さもなければ、キャンセル（ロールバック）信号を送信する。
３）各参加者は、準備された変化をコミットすべきかロールバックすべきかについてコーディネーターからの判断を得る。
【０２２６】
図面は、コンポーネントを論理的に個別のものとして示すが、これは、単なる例示に過ぎない。この図に示すコンポーネントは、個別のソフトウェア、ファームウェア及び／又はハードウェアコンポーネントへと結合したり分割したりできることが当業者に明らかであろう。更に、このようなコンポーネントは、それらをいかに結合し又は分割するかに関わらず、同じコンピューティング装置において実行することもできるし、或いは１つ以上のネットワーク又は他の適当な通信手段により接続された異なるコンピューティング装置間に分散できることも、当業者に明らかであろう。
【０２２７】
種々の実施形態は、コンピュータ分野の当業者に明らかなように、本開示の教示に基づいてプログラムされた従来の汎用又は特殊なデジタルコンピュータ（１つ又は複数）及び／又はプロセッサ（１つ又は複数）を使用して実施することができる。ソフトウェア分野の当業者に明らかなように、熟練したプログラマーであれば、本開示の教示に基づいて適切なソフトウェアコードを容易に準備することができよう。又、本発明は、当業者に容易に明らかなように、集積回路を準備するか、及び／又は従来のコンポーネント回路の適切なネットワークを相互接続することにより、実施することもできる。
【０２２８】
種々の実施形態は、命令が記憶された記憶媒体（メディア）であるか、ここに示す特徴のいずれかを実行するように汎用又は特殊なコンピューティングプロセッサ／装置（１つ又は複数）をプログラムするのに使用できるコンピュータプログラム製品を包含する。記憶媒体は、フロッピー（登録商標）ディスク、光学的ディスク、ＤＶＤ、ＣＤ−ＲＯＭ、マイクロドライブ、磁気−光学ディスク、ホログラフ記憶装置、ＲＯＭ、ＲＡＭ、ＰＲＡＭ、ＥＰＲＯＭ、ＥＥＰＲＯＭ、ＤＲＡＭ、ＶＲＡＭ、フラッシュメモリデバイス、磁気又は光学カード、ナノシステム（分子メモリ、ＩＣを含む）を含む任意の形式の物理的メディア；ペーパー又はペーパーベースのメディア；及び命令及び／又は情報を記憶するための任意の形式のメディア又はデバイスを包含し得るが、これらに限定されない。種々の実施形態は、１つ以上のパブリック及び／又はプライベートネットワークを経て全体的又は部分的に送信できるコンピュータプログラム製品を包含し、この送信は、ここに示す特徴のいずれかを実行するように１つ以上のプロセッサにより使用できる命令を含むものである。種々の実施形態において、この送信は、複数の個別の送信を含んでもよい。
【０２２９】
コンピュータ読み取り可能な媒体（メディア）の１つ以上に記憶されるが、本開示は、汎用／特殊なコンピュータ（１つ又は複数）及び／又はプロセッサ（１つ又は複数）のハードウェアを制御すると共に、これらコンピュータ及び／又はプロセッサが本発明の結果を利用して人間のユーザ又は他のメカニズムと対話できるようにするためのソフトウェアも包含する。このようなソフトウェアは、装置ドライバ、オペレーティングシステム、実行環境／コンテナ、ユーザインターフェイス及びアプリケーションを含むが、これらに限定されない。
【０２３０】
以上、本発明の好ましい実施形態を詳細に説明したが、これは、単なる例示に過ぎない。これは、本発明を余すところなく示すものでもないし、又、ここに開示した正確な形態に制限するものでもない。当業者であれば、多数の変更や修正が明らかであろう。これら実施形態は、本発明の原理及びその実際の応用を最良に説明するために選ばれたものであり、当業者であれば、本発明を理解することができよう。従って、本発明の範囲は、特許請求の範囲によって限定されるものとする。
【図面の簡単な説明】
【０２３１】
【図１ａ】一実施形態のシステムを示す図である。
【図１ｂ】一実施形態によるサービスバスアーキテクチャーを示す図である。
【図２】一実施形態によるメトリック集計及びコンフィギュレーション伝播を示す図である。
【図３】一実施形態によるメッセージ処理パイプラインを示す図である。
【図４】一実施形態による前及び後パイプラインメッセージ処理を示す図である。
【図５】一実施形態によるコンポーネントアーキテクチャーを示す図である。
【図６ａ】単一パイプライン対ノード及び単一ルートノードを有するメッセージ処理グラフである。
【図６ｂ】一実施形態によるブランチノードを伴うメッセージ処理グラフである。
【図７】一実施形態によるエラー取り扱い範囲を示す図である。
【図８】一実施形態のサービスプロバイダーを示す図である。
【図９】一実施形態によるモニタリングコンポーネントを示す図である。
【図１０】一実施形態によるルールトリガーメカニズムを示す図である。
【図１１ａ】一実施形態によるコンポーネントＡ、Ｂ及びＣを含む初期コア状態を示す図である。
【図１１ｂ】一実施形態によるセッションデータの更新を示す図である。
【図１２ａ】一実施形態による付加的なセッションシナリオを示す図である。
【図１２ｂ】一実施形態による付加的なセッションシナリオを示す図である。
【図１２ｃ】一実施形態による付加的なセッションシナリオを示す図である。
【図１３ａ】セッションビューとコア状態との間の非一貫性を示す図である。
【図１３ｂ】セッションビューとコア状態との間の非一貫性を示す図である。
【図１３ｃ】セッションビューとコア状態との間の非一貫性を示す図である。
【図１４】一実施形態による更新プラン実行を示す図である。
【図１５ａ】一実施形態による更新成功を示す図である。
【図１５ｂ】アプリケーションの例外による更新失敗を示す図である。
【図１５ｃ】サーバークラッシュによる更新失敗を示す図である。
【技術分野】
【０００１】
本発明は、一般に、サービスのためのミドルウェアに係り、より詳細には、クライアントとサービスが通信できるようにするメッセージ処理能力を有したスイッチングファブリックに係る。
【０００２】
優先権の請求：本出願は、参考としてここにその全体を援用する次の出願中の特許出願から優先権を請求する。
２００４年５月２１日に出願されたマテウ・ミッシュ氏等の「SYSTEM ANDMETHOD FOR ENTERPRISE APPLICATION INTEGRATION BUS」と題する米国プロビジョナル特許出願第６０／５７３，３５４号（代理人ドケットＮｏ．ＢＥＡＳ−０１６８４ＵＳ０）；
２００４年５月２１日に出願されたアルフレッド・チャン氏等の「LIQUID COMPUTING」と題する米国プロビジョナル特許出願第６０／５７３，７１７号（代理人ドケットＮｏ．ＢＥＡＳ−０１７０３ＵＳ０）；
２００５年５月１９日に出願されたポールＢ．パトリック氏等の「SERVICE ORIENTED ARCHITECTURE WITH MESSAGE PROCESSING STAGES」と題する米国特許出願（代理人ドケットＮｏ．ＢＥＡＳ−０１６８３ＵＳ０）；
２００５年５月１９日に出願されたポールＢ．パトリック氏等の「SERVICE ORIENTED ARCHITECTURE WITH MESSAGE PROCESSING PIPELINES」と題する米国特許出願（代理人ドケットＮｏ．ＢＥＡＳ−０１６８４ＵＳ１）；
２００５年５月１９日に出願されたポールＢ．パトリック氏等の「SERVICE ORIENTED ARCHITECTURE」と題する米国特許出願（代理人ドケットＮｏ．ＢＥＡＳ−０１６８４ＵＳ２）；
２００５年５月１９日に出願されたポールＢ．パトリック氏等の「FAILSAFESERVICE ORIENTED ARCHITECTURE」と題する米国特許出願（代理人ドケットＮｏ．ＢＥＡＳ−０１６８４ＵＳ３）；
２００５年５月１９日に出願されたポールＢ．パトリック氏等の「SCALEABLE SERVICE ORIENTED ARCHITECTURE」と題する米国特許出願（代理人ドケットＮｏ．ＢＥＡＳ−０１６８４ＵＳ４）；
２００５年５月１９日に出願されたポールＢ．パトリック氏等の「DYNAMICALLY CONFIGURABLE SERVICE ORIENTED ARCHITECTURE」と題する米国特許出願（代理人ドケットＮｏ．ＢＥＡＳ−０１６８４ＵＳ５）；
２００５年５月１９日に出願されたポールＢ．パトリック氏等の「SECURE SERVICE ORIENTED ARCHITECTURE」と題する米国特許出願（代理人ドケットＮｏ．ＢＥＡＳ−０１６８４ＵＳ６）；
２００５年５月１９日に出願されたポールＢ．パトリック氏等の「CO-LOCATED SERVICE ORIENTED ARCHITECTURE」と題する米国特許出願（代理人ドケットＮｏ．ＢＥＡＳ−０１６８４ＵＳ７）；
２００５年５月１９日に出願されたポールＢ．パトリック氏等の「PROGRAMMABLE SERVICE ORIENTED ARCHITECTURE」と題する米国特許出願（代理人ドケットＮｏ．ＢＥＡＳ−０１６８４ＵＳ８）；
２００５年５月１９日に出願されたポールＢ．パトリック氏等の「BATCH UPDATING FOR A SERVICE ORIENTED ARCHITECTURE」と題する米国特許出願（代理人ドケットＮｏ．ＢＥＡＳ−０１６８４ＵＳ９）；
２００５年５月１９日に出願されたポールＢ．パトリック氏等の「RELIABLE UPDATING FOR A SERVICE ORIENTED ARCHITECTURE」と題する米国特許出願（代理人ドケットＮｏ．ＢＥＡＳ−０１６８４ＵＳＡ）；
２００５年５月１９日に出願されたポールＢ．パトリック氏等の「SERVICE ORIENTED ARCHITECTURE WITH FILE TRANSPORT PROTOCOL」と題する米国特許出願（代理人ドケットＮｏ．ＢＥＡＳ−０１６８４ＵＳＢ）；
２００５年５月１９日に出願されたポールＢ．パトリック氏等の「SERVICE ORIENTED ARCHITECTURE WITH ELECTRONIC MAIL TRANSPORT PROTOCOL」と題する米国特許出願（代理人ドケットＮｏ．ＢＥＡＳ−０１６８４ＵＳＣ）；
２００５年５月１９日に出願されたポールＢ．パトリック氏等の「DYNAMICALLY CONFIGURABLE SERVICE ORIENTED ARCHITECTURE」と題する米国特許出願（代理人ドケットＮｏ．ＢＥＡＳ−０１６８４ＵＳＤ）；
２００５年５月１９日に出願されたポールＢ．パトリック氏等の「PROGRAMMABLE MESSAGE PROCESSING STAGE FOR A SERVICE ORIENTED ARCHITECTURE」と題する米国特許出願（代理人ドケットＮｏ．ＢＥＡＳ−０１６８４ＵＳＥ）；
２００５年５月１９日に出願されたポールＢ．パトリック氏等の「SERVICE PROXY DEFINITION」と題する米国特許出願（代理人ドケットＮｏ．ＢＥＡＳ−０１６８４ＵＳＦ）；
２００５年５月１９日に出願されたポールＢ．パトリック氏等の「DYNAMICROUTING IN A SERVICE ORIENTED ARCHITECTURE RULES」と題する米国特許出願（代理人ドケットＮｏ．ＢＥＡＳ−０１６８４ＵＳＧ）；
２００５年５月１９日に出願されたポールＢ．パトリック氏等の「DYNAMICPUBLISHING IN A SERVICE ORIENTED ARCHITECTURE」と題する米国特許出願（代理人ドケットＮｏ．ＢＥＡＳ−０１６８４ＵＳＨ）；
２００５年５月１９日に出願されたポールＢ．パトリック氏等の「SERVICE ORIENTED ARCHITECTURE WITH MONITORING RULES」と題する米国特許出願（代理人ドケットＮｏ．ＢＥＡＳ−０１６８４ＵＳＩ）；
２００５年５月１９日に出願されたポールＢ．パトリック氏等の「SERVICE ORIENTED ARCHITECTURE WITH INTERCHANGEABLE TRANSPORT PROTOCOLS」と題する米国特許出願（代理人ドケットＮｏ．ＢＥＡＳ−０１６８４ＵＳＪ）；
２００５年５月１９日に出願されたポールＢ．パトリック氏等の「SERVICE ORIENTED ARCHITECTURE WITH ALERTS RULES」と題する米国特許出願（代理人ドケットＮｏ．ＢＥＡＳ−０１６８４ＵＳＫ）；
２００５年５月１９日に出願されたポールＢ．パトリック氏等の「SERVICE ORIENTED ARCHITECTURE WITH CREDENTIAL MANAGEMENT」と題する米国特許出願（代理人ドケットＮｏ．ＢＥＡＳ−０１６８４ＵＳＬ）；
２００５年５月１９日に出願されたポールＢ．パトリック氏等の「SERVICE ORIENTED ARCHITECTURE WITH MESSAGE PROCESSING PIPELINES」と題する米国特許出願（代理人ドケットＮｏ．ＢＥＡＳ−０１６８４ＵＳＭ）；
２００５年５月１９日に出願されたポールＢ．パトリック氏等の「ERROR HANDLING FOR A SERVICE ORIENTED ARCHITECTURE」と題する米国特許出願（代理人ドケットＮｏ．ＢＥＡＳ−０１６８４ＵＳＮ）；
２００５年５月１９日に出願されたポールＢ．パトリック氏等の「DYNAMICPROGRAM MODIFICATION」と題する米国特許出願（代理人ドケットＮｏ．ＢＥＡＳ−０１６８４ＵＳＯ）；及び
２００５年５月１９日に出願されたポールＢ．パトリック氏等の「DYNAMICPROGRAM MODIFICATION」と題する米国特許出願（代理人ドケットＮｏ．ＢＥＡＳ−０１６８４ＵＳＰ）。
【背景技術】
【０００３】
エンタープライズソフトウェアアプリケーションがウェブブラウザベースのフロントエンドと一緒に機能する必要性によりアプリケーションサーバーが開発されるに至った。アプリケーションサーバーは、フロントエンドウェブアプリケーションをバックエンドのエンタープライズアプリケーションと一体化するためのフレームワークを与える。アプリケーションサーバーからエンタープライズアプリケーション単に呼び出すことを越えて、異なるエンタープライズアプリケーションの断片を複合アプリケーションへとコンポーズする必要性が生じる。これを行い得る１つの仕方は、エンタープライズアプリケーションを、他のシステムがアクセスできる再使用可能なサービスのセットとして露出させることである。しかしながら、エンタープライズアプリケーションは、通常、多数のアプリケーションプラットホーム及び異種環境において展開される。これらのファクタは、コンポーズの努力を独占的で且つプログラム駆動されるものとし、もろくて高価な一体化を生じさせる。従って、サービスを動的にコンポーズすると共に、それらの間に生じ得る非両立性を取り扱う柔軟性のあるインフラストラクチャーが要望される。
【発明を実施するための最良の形態】
【０００４】
本発明は、同様の要素が同じ参照番号で示された添付図面に一例として示すが、これに限定されるものではない。この開示において実施形態を言及するときには、必ずしも同じ実施形態ではなく、そのような言及は、少なくとも１つを意味する。特定の実施について説明するが、これは、説明上のものであることを理解されたい。当業者であれば、本発明の範囲及び精神から逸脱せずに他のコンポーネント及びコンフィギュレーションを使用できることも明らかであろう。以下の説明において、本発明の完全な説明を与えるために多数の特定の細部について述べる。しかしながら、本発明は、これら特定の細部を伴わずに実施できることが当業者に明らかであろう。他の場合には、本発明を不明瞭にしないために、良く知られた特徴は、詳細に説明しない。
【０００５】
図１ａを参照すれば、説明上、このシステムは、メッセージブローカー、ウェブサービス、ビジネス対ビジネス（Ｂ２Ｂ）サービスゲートウェイ、及びサービスマネージメントコンセプトを、ランタイムコンフィギュレーション情報ディレクトリー／レポジトリー１０６及びコンソール１０４を中心とする組み合せへと融合することを表わすサービスバス１００を備えている。このサービスバスは、使い易いコンフィギュレーション駆動の中間物で、次のことを、効率的に、且つ高い利用性、拡張性及び信頼性で達成する（制限なく）。
【０００６】
−エンベローププロトコル、トランスポートプロトコル、セキュリティ機構、ペイロードコンテンツ、一方向及び要求／応答パラダイム、同期及び非同期通信、ポイント対ポイント、及びパブリッシュ／サブスクライブのエリアにおいて、どんなメッセージを送信者１１４が送信するかと、受信者１１６が何を期待するかとの間のギャップを橋絡する。
−多行先パブリッシュ、コンテンツベースのルーティング、認証及び許可、並びに証明書マッピングのような（これらに限定されないが）タスクを実行するための付加的なコンピューティング能力を与える。
−メトリック収集及び表示、警告表示、追跡事象収集及び使用、メッセージアーカイブ及びサービスレベルアグリーメント（ＳＬＡ）マネージメントを伴うモニタリング能力を与える。
【０００７】
図１ｂは、一実施形態によるシステムを示す。一実施形態において、このシステムは、クライアントとサービスとの間の中間物として働くことのできるサービスバス１００を備えている。当業者であれば、本開示は、特定形式のサービス又はサービス技術に限定されず又はそれに依存しないことが明らかであろう。既に知られているもの及びこれから開発されるものを含む多数のサービス形式／技術が、本開示の範囲及び精神に完全に包含される。サービスバスへのメッセージは、トランスポート１０８に到着し、そして例えば、メッセージをルーティングし及び／又はパブリッシュすべき行先、メッセージに対して実行すべき変換、及び／又はセキュリティ処理を決定するように処理することができる。次いで、メッセージは、サービス又は別のサービスバスに向けられたトランスポート１１０に送出される。一実施形態では、メッセージに対する応答は、サービスバスを通る逆の経路をたどることができる。
【０００８】
一実施形態において、サービスバスは、ＢＥＡシステムズ・インクから入手できるＷｅｂＬｏｇｉｃ（登録商標）サーバーのようなアプリケーションサーバー１０２において部分的に又は完全に実施することができる。このシステムは、コンフィギュレーション情報１０６により駆動され、このコンフィギュレーション情報は、これを生成し、変更し、そして削除するためのユーザインターフェイスを与えるコンフィギュレーション／モニタリングコンソール１０４を経て特定することができる。システムの全ての観点は、動的に構成することができる。例えば、これに限定されないが、ユーザインターフェイスは、次の１つ以上を含むことができる：１）ディスプレイ装置にレンダリングされるか又はユーザの網膜に投影されるグラフィックユーザインターフェイス（ＧＵＩ）；２）サウンド及び／又はボイスコマンドに応答する能力；３）リモートコントロール装置（例えば、セルラー電話、ＰＤＡ、又は他の適当なリモートコントロール）からの入力に応答する能力；４）ジェスチャー（例えば、顔面及びその他）に応答する能力、５）同じ又は別のコンピューティング装置のプロセスからのコマンドに応答する能力；及び６）コンピュータマウス及び／又はキーボードからの入力に応答する能力。この開示は、特定のユーザインターフェイスに限定されない。当業者であれば、本開示の精神及び範囲内で多数の他のユーザインターフェイスも考えられることが明らかであろう。
【０００９】
一実施形態において、図２を参照すれば、コンフィギュレーション情報は、サービスバスをホストする１つ以上のマネージされるサーバーに対するアドミニストレータサーバー１１２によりエンタープライズ全体に配布される。これら実施形態の態様において、マネージされるサーバーは、この分野で良く知られたようにクラスターで展開することができる。コンフィギュレーション情報は、サービスバスにより高速ローカル検索するために、マネージされるサーバーへ自動的に伝播することができる。モニタリングメトリックは、集計してコンソールに表示するために、全てのマネージされるサーバーから自動的に収集することができる。
【００１０】
一実施形態において、サービスバスによりホストされるサービス（「サービスプロキシー」）と、サービスバスによりホストされずに、サービスプロキシーにより呼び出されるサービス（「外部サービス」）は、両方とも、サービスとしてモデリングされる。サービスプロキシーは、サービス（即ち、外部サービス及びサービスプロキシー）に対する代役又はその見掛け(facade)として働く。例えば、これに限定されないが、サービスは、次を含むことができる。
【００１１】
−トランスポートアドレス及びそれに関連したコンフィギュレーションを各々伴うポートと称される（エンドポイントとも称される）具体的インターフェイスのセット。一実施形態では、ポートのセットは、サービスに対する負荷バランス及びフェイルオーバー代替物を構成し、そして特性が同一である。
−一実施形態では、オペレーションによりおそらくブレークダウンされるインターフェイスにおいてメッセージ部分の構造を定義したものであるオプションのアブストラクトインターフェイス。
−具体的メッセージに対するアブストラクトインターフェイスにおけるメッセージ部分のパッケージングと、トランスポートに対するそのメッセージのバインディングとを定義するバインディング。
−ウェブサービスセキュリティ（ＷＳＳ）及びウェブサービス信頼性メッセージング（ＷＳ−ＲＭ）に対するポリシー、許可ポリシー、及びバインディングレイヤーにより透過的に実行される必要のあるアクション（例えば、ロギング）。
【００１２】
一実施形態において、ハイパーテキストトランスファープロトコル（セキュリティ）ＨＴＴＰ（Ｓ）又はＪａｖａメッセージングサービス（ＪＭＳ）トランスポートをベースとするシンプルオブジェクトアクセスプロトコル（ＳＯＡＰ）ウェブサービスに対して、アブストラクトインターフェイス、具体的インターフェイス及びバインディングのウェブサービス記述言語（ＷＳＤＬ）表示が考えられる。この実施形態の態様では、ＷＳＤＬリソース又は既存のサービスを、新たなサービスのインターフェイスを定義するためのテンプレートとして使用できる。又、ｅメール、ファイル、ＷＳ−ＲＭ及びファイルトランスポートプロトコル（ＦＴＰ）トランスポートもサポートされる。一実施形態では、サービスバスが、ファイルシステムディレクトリーを周期的にポーリングし、ファイルトランスポートの場合にファイルを処理する準備ができたかどうか決定することができる。サービスバスは、ＨＴＴＰ及びＪＭＳ非同期トランスポートに対して要求／応答及び一方向パラダイムをサポートすることができる。又、メッセージの順序付けされた配送も任意にサポートするが、これは、基礎となるトランスポートがそれをサポートする場合である。更に別の実施形態では、サービスバスは、外部マークアップ言語(eXternal Markup Language)（ＸＭＬ）、非ＸＭＬ（ＭＦＬで記述される構造）、アタッチメント（ｅメール）を伴うバイナリー多目的インターネットメールエクステンション（ＭＩＭＥ）、及びＳＯＡＰパッケージングをサポートする。
【００１３】
サービス／サービスプロキシープロセスは、同じバインディングに対して多数のポートをもつことができる。これらのポートは、負荷バランス及びフェイルオーバー代替物として使用することができる。サービス／サービスプロキシーは、そのポートに対して使用するための負荷バランスポリシーを定義することができる。一実施形態では、これらポリシーは、ラウンドロビン及びランダム（重み付けされた又は非重み付けの）を含むことができる。これらポートは、負荷バランス行先として働くが、失敗の際にはフェイルオーバー代替物として働くこともできる。利用性の高い負荷バランス機構として２つのコンセプトが一緒に結合される。
【００１４】
又、サービスプロキシーは、失敗時の再試みポリシー、（要求／応答に対する）時間切れポリシー、及びそのインターフェイスにおけるメッセージに適用するセキュリティポリシーを定義することもできる。これは、サービスレベルで指定することもできるし（全てのメッセージに適用する）、又はサービスのオペレーションに対して個々のメッセージで指定することもできる。
【００１５】
一実施形態において、サービスは、１つ以上のカテゴリー機構により分類される。例えば、カテゴリーは、鍵となる名前であり、そしてカテゴリー値は、その鍵となる名前に対する値である。サービスは、多数のカテゴリー名に対して多数の値をもつことができる。カテゴリーは、発見目的に有用である。鍵となる名前と、許された値のハイアラーキーとを定義する多数の良く知られた存在論（又はカテゴリー機構）がある。この実施形態の態様において、カテゴリーハイアラーキーのリーフ値は、サービスを分類するのに使用される。一実施形態では、サービス消費者をサーチのために分類することができる。サービス消費者は、組織又はアプリケーションでよく、そしてメッセージを送信する（又は同期応答を受信する）ことができる。別の実施形態では、サービス消費者は、証明書に関連付けられ、そしてユーザに結び付けられ、従って、許可のための役割に属することができる。
【００１６】
一実施形態では、サービスプロバイダーと称される組織又はアプリケーションによりサービスのセットを提供することができる。サービスのためのプロバイダーを定義することは任意であり、スタンドアローンサービスをもつことができる。例えば、これらは、エンタープライズの内部サブ組織でもよいし、外部パートナー組織でもよいし、又は個々のアプリケーションでもよい（意味論はユーザまで）。又、サービスプロバイダーは、サーチのためのサービスと同様に分類することもできる。サービスプロバイダーは、証明書に関連付けられ、そしてユーザに結び付けられ、従って、許可のための役割に属することができる。サービスプロバイダーは、メッセージを送信及び受信することができる。
【００１７】
一実施形態において、サービスプロキシーの実施は、少なくとも１つのメッセージ処理パイプライン定義を含む。例えば、これは、要求パイプラインの定義及び応答パイプラインの定義を含むことができる。パイプラインは、外部（又は別のプロキシー）サービスを呼び出す前にサービスプロキシーへの要求メッセージに対してどんなアクションが実行されるか、及びサービスプロキシーがクライアントに応答を返送する前にサービスプロキシーにより呼び出されたサービスからの応答に対してどんな処理が実行されるかを指定するメッセージ処理ノードである。各パイプラインは、一連のステージを含むことができる。ステージは、パイプラインに適合し得るプログラムインターフェイス及び／又はプロトコルを実施する。パイプラインに供給されるメッセージには、パイプラインのステージによりアクセス又は変更できるメッセージコンテクスト変数のセット（メッセージコンテンツを含む変数を備えた）が添付される。
【００１８】
説明上、共通のパイプラインステージは、次のものを含む。
−変換ステージは、コンテクストに影響する実行されるべき変換を選択するためにフロー制御「ｉｆ」構造をネスト状にすることを許す。ウェブサービスコールアウト又はデータベースルックアップは、出力コンテクスト変数をセットするためのＸＭＬ問合せ（ＸＱｕｅｒｙ）又は拡張可能なスタイルシート言語変換（ＸＳＬＴ）変換に対する代替物となり得る。
【００１９】
−ルーティングステージは、メッセージをルーティングするための単一エンドポイント及びオペレーションを定義するために「ｉｆ」構造及び「ｃａｓｅ」構造を結合する（及びネスト状にする）ことを許す。コンテクスト変数に影響する変換のセットは、メッセージが各エンドポイントへパブリッシュされる前に定義することができる。ウェブサービスコールアウト又はデータベースルックアップは、コンテクスト変数をセットするためのＸＱｕｅｒｙ又はＸＳＬＴ変換に対する代替物となり得る。
【００２０】
−パブリッシュステージは、メッセージをパブリッシュするためのエンドポイント及びオペレーションのセットを定義するために「ｉｆ」構造及び「ｃａｓｅ」構造を結合する（及びネスト状にする）ことを許す。コンテクスト変数に影響する変換のセットは、メッセージが各エンドポイントへパブリッシュされる前に定義することができる。ウェブサービスコールアウト又はデータベースルックアップは、コンテクスト変数をセットするためのＸＱｕｅｒｙ又はＸＳＬＴ変換に対する代替物となり得る。コンテクストへの変化は、パブリッシュされる各エンドポイントに対して分離され、そしてパイプラインによるその後の処理に影響しなくなる。
【００２１】
−一実施形態では、ＷＳＳ処理及び許可をバインディングレイヤーにおいて実行することができる。
−追跡ステージは、追跡レコードをユーザ定義情報と共に書き込むのを許し、従って、追跡システムを使用して、ユーザ定義基準によりサーチすることができる。
−アーカイブステージは、経歴及びレコード保持の目的でアーカイブへメッセージを書き込む。
−ロギングステージは、選択されたコンテクストをデバッグの目的でシステムログへロギングするのを許す。
−検証ステージは、ドキュメントをＭＦＬスキーマのＸＭＬに対して検証する。
−カスタムステージは、パイプラインに適合するプログラムインターフェイス及び／又はプロトコルを実施する。
【００２２】
図３は、一実施形態に基づくメッセージ処理パイプラインを示す。オペレーションパイプラインは、メッセージのコンテンツにより指示されたオペレーションに基づいてメッセージを処理することができる。一実施形態では、オペレーションの決定は、ユーザ選択基準により実行される。各パイプラインは、１つ以上のステージ（例えば、３０２、３０４、３０８、３１０）を含むことができる。単一サービスレベル要求パイプライン３００は、複数のオペレーションパイプライン３０６及び３１２へと分岐することができる。応答処理は、当該オペレーションパイプライン（３１４、３１６）でスタートし、これは、次いで、単一サービスレベル応答パイプライン３１８へと接合する。一実施形態では、一方向オペレーションが呼び出される場合に、応答パイプラインは、空のメッセージで実行される。これは、サービスプロキシーに対して応答を構成するのを許し、従って、要求／応答と一方向オペレーションとの間の橋絡が可能になる（例えば、サービスプロキシーの入力は、一方向であるが、その出力は、要求／応答であり、又はその逆にもなり得る）。サービスプロキシーは、呼び出されたサービスからの応答を吸収するか、又はクライアントに対してそれを発生するかのいずれかである。
【００２３】
一実施形態では、要求パイプライン及び応答パイプラインの両方と、他のメッセージ処理ノードとにわたってコンテクストが共有され、そしてその値が、個々の要求／応答メッセージを含む。この実施形態の態様において、コンテクストは、予め定義されたＸＭＬ変数のセットである。コンテクストに対して新たな変数を動的に追加及び削除することができる。予め定義されたコンテクスト変数は、例えば、メッセージに関する情報、トランスポートヘッダー、セキュリティプリンシパル、現在サービスプロキシーに対するコンフィギュレーション情報、及びサービスプロキシーにより呼び出された一次ルーティング及びサブスクリプションサービスに対するコンフィギュレーション情報を有するが、これらに限定されない。一実施形態では、ステージによるＸＱｕｅｒｙ／Ｘｕｐｄａｔｅ表現によりコンテクストを読み取って変更することができる。
【００２４】
更なる説明上、コンテクストは、変数＄ｈｅａｄｅｒ、＄ｂｏｄｙ、及び＄ａｔｔａｃｈｍｅｎｔｓを含むことができる。これらは、ＳＯＡＰヘッダー、ＳＯＡＰ本体コンテンツ、及びＭＩＮＥアタッチメントを各々含むラッパー変数である。コンテクストは、全てのメッセージがＳＯＡＰメッセージで、非ＳＯＡＰメッセージがこのパラダイムにマップされるという印象を与える。バイナリー又はＭＦＬデータの場合に、＄ａｔｔａｃｈｍｅｎｔｓ又は＄ｂｏｄｙのドキュメントを表わすＸＭＬエレメントは、独特な識別子で実際のドキュメントを指す。ＳＯＡＰ ＲＰＣの場合には、本体コンテンツが、それ自体、タイプ分けされたＲＰＣパラメータを含むラッパーエレメントである。
【００２５】
一実施形態において、システムは、デザイン時に必要に応じて使用できる内蔵型システムを有する。デザイン時に条件又は変換のＸＱｕｅｒｙ表現を生成するときには、ＸＱｕｅｒｙを容易に生成する助けとなるように変数をエディタにおいて１つ以上のタイプであると宣言することができる。更に別の実施形態では、ＸＭＬスキーマ、ＭＦＬ又はＷＳＤＬリソースにおいてタイプを指定することができる。このタイプ宣言プロセスは、タイプ分けされるべき変数の性質が分かる（タイプのエレメント又はタイプそれ自体に対するラッパーである）。又、これは、＄ｂｏｄｙにおいてＳＯＡＰ ＲＰＣパラメータ又はドキュメントに容易にアクセスするための支援も与える。
【００２６】
一実施形態において、ステージは、そのステージにエラーが生じた場合に実行するための一連のステップをもつことができる。この一連のステップは、そのステージに対するエラーパイプライン又はハンドラーを構成する。更に、全パイプライン又は全サービスプロキシーに対してエラーハンドラーを定義することもできる。存在する最低範囲のエラーハンドラーは、エラーの際に呼び出される。このエラーハンドラーは、メッセージをエンドポイントへパブリッシュさせ、サービスプロキシーの呼び出し者へ返送されるべきエラー応答メッセージを公式化し、メッセージをログし、コンテクストを変更した後も継続させ、又は例外を引き起こすことを許す。例外を引き起こすと、次に高い範囲のエラーパイプラインへ制御を移管することができる。
【００２７】
図４は、一実施形態による前及び後パイプラインメッセージ処理を示す図である。要求の処理は、インバウンドトランスポート４０２の処理、インバウンドバインディングレイヤー４０４の処理、パイプライン実行４０６、アウトバウンドバインディングレイヤー４０８の処理、及びアウトバウンドトランスポート４１０の処理で構成される。これら実施形態の態様において、バインディングレイヤーは、実行されるべき幾つかの処理、例えば、メッセージをコンテクスト変数へ／からマッピングし、メッセージをパッケージング及びアンパッケージングし、そしてＷＳＳセキュリティ及び許可を実行するといった処理を自動化する。一次ルーティング行先及びパブリッシュ行先の両方をこのパラダイムにおいて動作させることができる。一実施形態において、一次ルーティングエンドポイントが呼び出された後に、応答パイプライン処理は、同様のモデルをたどる。更に別の説明において、パイプラインステージからのウェブサービスコールアウト４２０は、バインディングレイヤー４１６を通過した後に、トランスポートレイヤー４１８を通過する。一実施形態では、コールアウト応答は、逆の経路をたどる。
【００２８】
一実施形態において、ユーザは、人間、組織又はプロセスのいずれかであるセキュリティプリンシパルである。ユーザは、ユーザインターフェイス（コンソールユーザ）又はメッセージングインターフェイス（ユーザがサービス消費者又はプロバイダーとしてモデリングされる）のいずれかを呼び出すことができる。サービス消費者及びプロバイダーは、そのプロバイダー／消費者からのメッセージの認証に対してユーザに関連付けることができる。ユーザは、グループに属することができ、そしてグループも、グループに属することができる。グループ及びユーザは、リソースへのアクセス権が指定されるユニットであるロールに属することができる。一実施形態では、システム内のリソース、プロバイダー、消費者及びサービスは、名前の競合を回避するだけでなく、ある部門に属するリソース及びサービスを編成しそしてそれらをサーチする便利な仕方を与えるために、フォルダーのハイアラーキーを各々伴うプロジェクトのセットに編成することができる。
【００２９】
一実施形態において、コンソールは、タスクレベル許可をサポートする。説明上、サービスバスコンソールユーザ又はプロセスは、予め定義された次のロールの１つ以上において動作することができる。
−一体化アドミニストレータは、サービスバススーパーユーザであり、何かをすることができる。
−一体化オペレータは、コンソールを使用して、サービスバスアクティビティをモニタし、メッセージの追跡を実行し、そしてサービスを保留／再開すると共に、それらの動作時間を変更することができる。
−一体化モニタは、全てのものへ完全な読み取りアクセスをし、そしてリソース、サービス、プロバイダー、消費者又はプロジェクトをエクスポートすることができる。
−一体化デプロイヤーは、全てのものへ完全な読み取りアクセスをし、そしてリソース、サービス、プロバイダー、消費者又はプロジェクトを生成し、削除し、又はインポート／エクスポートすることができる。
−一体化セキュリティアドミニストレータは、ＡＣＬ、証明書、キーストローク、ユーザ、グループ及びロールを読み取り、生成し、削除し、編集することができる。
【００３０】
一実施形態において、リソースは、プロセス／エンティティの再使用可能な共通定義及び／又は記述（例えば、そのエンティティに対するコンフィギュレーション情報）である。リソースは、通常、多数のサービスにより使用され、そしてエンタープライズ又は部門にわたる標準的な定義又は記述である。リソースは、例えば、カテゴリー機構、ＭＦＬスキーマ、ＸＳＤスキーマ、ＸＱｕｅｒｙマップ、ＸＳＬＴマップ、ＷＳＤＬインターフェイス、及びＷＳ−ポリシーファイルである。カテゴリー機構は、単一カテゴリー名と、このカテゴリー名に対する値のハイアラーキーセットとを定義する。サービス、プロバイダー及び消費者は、登録された機構を使用して分類することができる。それらは、カテゴリー機構に対する多数のリーフ値、又は多数のカテゴリー機構からのリーフ値で分類することができる。一実施形態において、システムの全てのリソースを名前でルックアップすることができる。更に別の実施形態では、カテゴリー機構にサーチフィルタを適用することによりリソースをルックアップすることができる。
【００３１】
スキーマは、原始データ又は構造化データのタイプを記述する。ＭＦＬスキーマは、非ＸＭＬデータのタイプを記述する。ＸＭＬスキーマは、ＸＭＬのタイプを記述する。ＸＭＬスキーマのタイプは、他のスキーマのファイルをインポート又は含むことができる。変換マップは、２つのタイプ間のマッピングを記述する。ＸＳＬＴマップは、ＸＳＬＴ規格を使用してＸＭＬデータに対するマッピングを記述する。ＸＱｕｅｒｙマップは、ＸＱｕｅｒｙ規格を使用してＸＭＬ及び非ＸＭＬ（ＭＦＬ）データに対するマッピングを記述する。
【００３２】
ＷＳＤＬインターフェイスは、サービスインターフェイスのテンプレートであり、これは、そのインターフェイスにおけるオペレーションを含むサービスのアブストラクトインターフェイスと、オペレーションシグネチャーにおけるメッセージ部分の形式とを記述する。又、任意であるが、メッセージ（パッケージング）へのメッセージ部分のバインディング、及びトランスポートへのメッセージのバインディングも記述する。又、任意であるが、サービスの具体的インターフェイスも記述する。ＷＳ−ポリシーは、セキュリティ及び信頼性あるメッセージングポリシーを記述する。これは、どんなアルゴリズムを使用してメッセージに何をサイン又は暗号化すべきか記述する。又、受信時にメッセージに対してどんな認証メカニズムを使用すべきかも記述する。
【００３３】
図５は、一実施形態によるコンポーネントアーキテクチャーを示す図である。サービスバスは、アドミニ(admin)サーバー５０２としても働く単一サーバーに配備することもできるし、又はサーバーのクラスター（例えば、クラスターは、マネージされるサーバー５００のクラスターセットで構成される）に配備することもできる。コンフィギュ(config)フレームワークコンポーネント５０４は、オブジェクト及びファイル完全性保護、キャッシング及びインデクシング、参照の完全性、及びコンフィギュレーション伝播と共に、コンフィギュレーション情報に対するＣＲＵＤ（生成、読み取り、更新、削除）能力を与えることができる。アドミニサーバーは、コンフィギュレーション情報を、マネージされるサーバーへ伝播させることができる。
【００３４】
一実施形態において、タスクフレームワークコンポーネント５０６は、個々のコンフィギュ(config)オブジェクトに対する多数のＣＲＵＤオペレーションより成るコンフィギュオペレーションであるタスク又は複合タスク（タスクのタスク）に対してオペレーションアンドゥ及びシリアル化能力を与えることができる。コンフィギュ伝播の単位はタスクであり、そしてタスクは、特殊なコードの実行を含むと共に、マネージされるサーバーにおけるＥＡＲ又はＷＡＲの配備を含むことができ（自動的データベースか、又はトランスポートのための軽量ｗｅｂａｐｐ配備に主として使用される）、そして粒子の粗い同時制御をサポートする（タスクの実行がシリアル化される）。
【００３５】
一実施形態において、集計フレームワークコンポーネント５２４は、メトリックを収集しそしてそれをクラスター規模の集計のためにアドミニサーバーへ伝播する能力を与えることができる。一実施形態では、集計されるデータは、データが古いほど、より粗くなる（期間に関して）。例えば、最新の１時間については、集計インターバルが５分である。それ以前の、昨日については、集計インターバルが１時間である。それ以前の、先週については、集計インターバルが１日である、等々となる。
【００３６】
一実施形態において、警告システム５１０は、集計されたメトリックを分析して、サービスレベルアグリーメント（ＳＬＡ）ルールに違反しているかどうか決定し、そしてもしそうであれば、警告を発する。一実施形態では、警告の行先は、ｅメール、ウェブサービス、ＷＬＩロガー、待ち行列等である（必要に応じて、更に多く追加できる）。
【００３７】
一実施形態において、コンソールユーザインターフェイス（ＵＩ）コンポーネント５１２は、ポータルと一体化されるＪＳＰベースのポートレットである。コンソールＵＩは、コンソールにおけるモニタリング及びコンフィギュレーションの両方をサポートする。
【００３８】
一実施形態において、外部及びサービスプロキシーコンフィギュコンポーネント５１４は、プロキシー又は外部サービスインターフェイスに対するアブストラクト、具体的、セキュリティ及びアクセスポリシー、並びにバインディング情報を定義する。サービスプロキシーは、サービスバスサーバーによりホストされる中間物であり、一方、外部サービスは、他の何らかのサーバーに存在するメッセージがルーティングされるところの外部エンドポイントである。これは、サービスプロキシーとして、パイプラインアーキテクチャーに基づき入力及び出力メッセージに対してサービスプロキシーにより実行される順次メッセージ処理を定義する。又、これは、非常に多数のサービスが存在するときにサーチ能力も与える。
【００３９】
ユーザ及び証明書コンフィギュコンポーネント５１６は、属性を伴うＵＩ及びメッセージングユーザと、一実施形態に基づきそのユーザと共に進行する証明書との両方を定義することができる。この実施形態の態様において、ユーザは、ハイアラーキー式にグループへと編成することができ、そしてグループ及びユーザは、リソースへのアクセスが許可されるロールに属することができる。メッセージングユーザは、メッセージを送信できるサービス消費者であるか、又はメッセージを送信又は受信するサービスを提供するサービスプロバイダーである。
【００４０】
一実施形態において、リソースコンフィギュコンポーネント５１８は、テンプレートＷＳＤＬ（ウェブサービス定義言語）、ＷＳセキュリティポリシー、スキーマ、存在論（サービス及びサービスプロバイダーを分類するカテゴリー機構）、及び多数のサービスによりレバレッジすることのできる変換マップのような（これらに限定されない）共有リソースを定義するのに使用できる。又、これは、非常に多数のサービスが存在するときにサーチ能力も与える。
【００４１】
一実施形態において、モニタリングコンポーネント５２０は、警告及びメトリックを示すためにサービスバスシステムに対するモニタリングＵＩを与える。
【００４２】
一実施形態において、インポート／エクスポートコンポーネント５２２は、サービスバスインストレーションとインストレーションとの間でのサービス及び他のリソースの移動を許す。デザイン、ステージ及びプロダクションは、全て、別々のバニラサービスバスインストレーションである。インポートは、環境特有のコンフィギュレーションパラメータ、及びインポートされたオブジェクトが既に存在する場合に使用すべき解決策（置き換え又は保持）の指定を許す。又、これは、インポートされたオブジェクトにおける非分析参照を、同じタイプの既存のオブジェクトにリンクすることにより、分析することも許す。
【００４３】
一実施形態において、トランスポート及びトランスポートＳＰＩ５２６のコンポーネントは、新たなトランスポートをプラグインするためのフレームワークを与えると共に、ＨＴＴＰ（Ｓ）、ＪＭＳ、ｅメール、ＦＴＰ、ファイル、ＷＳ−ＲＭ（ウェブサービス信頼性メッセージング）、及びボックスからのタイマー事象トランスポートもサポートする。可能であれば、ストリーミング、信頼性、メッセージ順序付け、要求／応答及び一方向メッセージがサポートされる。
【００４４】
一実施形態において、パイプラインランタイム及びステージＳＰＩ５２８のコンポーネントは、ユーザにより新たなカスタムステージをプラグインするためのフレームワークを与えると共に、サービスプロキシーにおける要求及び応答パイプラインを経てコンテクストマネージメント及びメッセージフローを与える。
【００４５】
一実施形態において、サービスプロキシーパイプラインは、バインディングレイヤー５３０を経ていずれかの端においてトランスポートとインターフェイスすることができ、バインディングレイヤーは、サービスプロキシー（インバウンド）で定義されたポリシーと、呼び出された（アウトバウンド）外部又はサービスプロキシーとに基づいて、メッセージのパッケージング、ロギングＷＳＳ処理及び許可を取り扱うことができる。
【００４６】
一実施形態において、エンドポイントは、ユニフォームリソース識別子（ＵＲＩ）に基づくアドレスを有する。例えば、サービスは、サービスディレクトリーに登録されたインバウンド又はアウトバウンドエンドポイントである。例えば、これは、関連するＷＳＤＬ、セキュリティ設定、等をもつことができる。ルーターは、パイプラインの命名された集合である。パイプラインは、非分岐の一方向処理経路を表わす命名された一連のステージである。ステージは、変換、ルーティング等のユーザ構成の処理ステップである。パイプラインは、メッセージ処理グラフの一部分であるメッセージ処理ノードである。メッセージがインバウンドエンドポイント（サービスプロキシー）からアウトバウンドエンドポイント（通常、外部サービス又は別のサービスプロキシー）へシステムを通していかに流れるかの非常に基本的な概要を以下に示す。
トランスポートレイヤー → バインディングレイヤー → メッセージ処理グラフ → バインディングレイヤー → トランスポートレイヤー
【００４７】
一実施形態において、メッセージ処理グラフは、メッセージの処理及び操作を実行できるところである。バインディング及びトランスポートレイヤーは、主として、通信及びメッセージのパッキング／アンパッキングを取り扱うが、これらレイヤーにおいてメッセージの処理及び操作を行うこともできる。
【００４８】
一実施形態において、トランスポートレイヤーは、クライアント及び行先エンドポイントとの通信を取り扱う役割を果たす。これは、ＨＴＴＰ及びＪＭＳのような種々の通信プロトコルをサポートできると共に、エンドポイントＵＲＩや関連トランスポートヘッダーのようなものを含むコンフィギュレーション情報を発生する役割を果たす。メッセージコンテンツについては、トランスポートレイヤーは、主として、入力及び出力ストリームの形態の生のバイト、及びＪＭＳメッセージクラスのインスタンスのようなトランスポート特有のメッセージオブジェクトを取り扱う。別の実施形態では、トランスポートレイヤーは、単に、システムへ及びシステムからメッセージを得るだけであり、即ちメッセージコンテンツの操作は何ら実行しない。
【００４９】
一実施形態において、バインディングレイヤーは、主として、メッセージをパッキング及びアンパッキングする役割を果たす。又、これは、ほとんどバイトストリーム取り扱うトランスポートレイヤーと、よりリッチなメッセージコンテクスト表示を使用できるルーターとの間の中間物として働くこともできる。性能上の理由で、バインディングレイヤーは、メッセージのアンパッキングやデータのアンマーシャリング(unmarshaling)を、それが必要になるまで回避するために、オンデマンド処理を使用することができる。
【００５０】
別の実施形態では、バインディングレイヤーは、セキュリティ処理が実行される場所でもある。インバウンド側では、セキュリティ処理は、受信側サービスプロキシーのコンフィギュレーションにより決定される。アウトバウンド側では、処理は、行先サービスのコンフィギュレーションにより決定される。別の実施形態では、バインディングレイヤーは、サービス特有のもので、そのタスクを実行するためにコンフィギュレーションパラメータに依存する。
【００５１】
一実施形態において、ルーターは、サービスプロキシーの要求及び応答ロジックを実施する役割を果たす。要求及び応答経路は、メッセージコンテンツを操作する一方向メッセージ処理パイプラインノードを使用して実施することができる。分岐ノードを使用して、多数のパイプライン経路のいずれをたどるべきか決定することにより、条件付実行が可能となる。要求経路は、通常、別のサービス又はサービスプロキシーに要求をディスパッチするルーティングノードで終了する。そのサービスからの応答で応答経路処理が開始され、その後、サービスプロキシークライアントへ応答を返送することができる。応答は、メッセージ処理グラフを経て逆方向に進行する。
【００５２】
一実施形態において、パイプラインノードは、要求、応答及びエラーの３つのカテゴリーの１つにタイプ分けすることができる。要求パイプラインは、ルーターの要求経路を処理するのに使用され、一方、応答パイプラインは、応答経路を処理するのに使用される。エラーパイプラインは、エラーハンドラーとして使用され、以下の別のセクションで詳細に説明する。パイプラインの目的を示すのとは別に、タイプは、どのステージがパイプラインに現われてもよいか制限するのに使用されてもよい。このような制限は、個々のステージの実施に委ねられる。
【００５３】
図６ａ及び６ｂは、一実施形態によるメッセージ処理グラフである。上述したように、ルーターは、メッセージ処理パイプラインを使用してサービスプロキシーの要求／応答ロジックを実施することができる。要求及び応答パイプラインノードを一緒に対にし（パイプライン対ノード）、そしてそれらを論理的ツリー構造又はメッセージ処理グラフへと編成することにより、要求及び応答経路が生成される。一実施形態では、ノードは、メッセージ処理グラフに適合するプログラムインターフェイス及び／又はプロトコルを実施する。分岐ノードは、条件付実行を許し、そして分岐の終りにあるルーティングノードは、要求／応答ディスパッチを実行する。一実施形態では、メッセージ処理グラフは、サービスプロキシー振舞いの明確な概要を許し、ルーティングアクション及び分岐条件の両方を全デザインの明確な部分とするのであって、パイプラインステージ内の奥深くにそれらを埋めるのではない。要求メッセージは、メッセージ処理グラフにより第１方向に経路をたどる。それに関連した応答は、メッセージ処理グラフにより逆方向に経路を進行することができる。
【００５４】
一実施形態において、メッセージ処理グラフは、３つのトップレベルコンポーネントの１つ以上のインスタンスを含むことができる（図６ａ−６ｂ）。
−パイプライン対ノード（「ＰＰ」）
−分岐ノード（「ＢＲ」）
−ルーティングノード（「ＲＴ」）
【００５５】
図６ａは、単一パイプライン対ノード６００と、単一ルーティングノード６０２とを有していて、これが、サービス６０３へメッセージを転送するように構成されたメッセージ処理グラフを示す。パイプライン対ノードは、単一要求及び単一応答のパイプラインノードを１つのトップレベルエレメントへと一緒に結合する。別の実施形態では、パイプライン対ノードは、メッセージ処理グラフに１つの直接的な子孫を有してもよい。要求メッセージの処理中に、パイプライン対ノードに訪問したときに要求パイプラインノードを実行することができる。応答処理のために経路を逆行するときには、応答パイプラインノードを実行することができる。
【００５６】
ルーティングノードは、一実施形態によりサービスとの要求／応答通信を実行するのに使用できる。この実施形態の態様において、ルーティングノードは、サービスプロキシーに対する要求処理と応答処理との間の境界を表わす。ルーティングノードが要求メッセージをディスパッチするときには、要求処理が終わったと考えられる。ルーティングノードが応答メッセージを受信すると、応答処理が開始される。ルーティングノードは、それ自体、条件付きルーティングと、アウトバウンド及び応答変換とをサポートする。条件がルーティングノード内に現われるか又は分岐ノードとしてメッセージ処理グラフに現われるかは、ユーザ次第である。一実施形態では、ルーティングノードは、グラフに子孫をもたない。
【００５７】
図６ｂは、一実施形態により分岐ノードを伴うメッセージ処理グラフを示す。分岐ノード６０６は、多数の考えられる経路６０８の厳密に１つを下るように処理を進めるのを許す。これら実施形態の態様において、分岐は、簡単であるが独特のストリング値で各分岐路がタグ付けされた簡単なルックアップテーブルにより推進することができる。メッセージコンテクストにおける変数は、そのノードに対するルックアップ変数として指定することができ、その値を使用して、どの分岐路をたどるか決定することができる。ルックアップ変数の値に一致する分岐路がない場合には、デフォールト分岐路をたどる。ルックアップ変数の値の設定は、分岐ノードに到達する前に行うことができる。分岐ノードは、グラフにおいて、デフォールト分岐路を含む各分岐路に１つづつ、多数の子孫をもつことができる。
【００５８】
一実施形態において、要求処理は、サービスプロキシーにより要求が受け取られたときにメッセージ処理グラフのルート（根）において開始される。あるポイントにおいて、要求メッセージがパイプライン対ノードへ運ばれ、そこで、処理を実行するために要求パイプラインノードが呼び出される。要求メッセージが分岐ノードへ運ばれると、要求は、更に、選択された分岐路に沿って運ばれる。メッセージがルーティングノードに運ばれると、アウトバウンド／応答変換と共にルーティングが実行される。サービスプロキシーにより応答メッセージが受信されると、要求メッセージがたどった経路とは逆の経路に沿ってそれが運ばれる。ルーティングノードをもたずに単純に終わる要求経路に対して同じことが生じ、即ちサービスバスが応答処理を開始しそしてグラフまで戻るが、応答を待機することはない。応答の処理中に、パイプライン対ノードにヒットしたときに、応答パイプラインノードが実行される。分岐ノードにヒットしたときには、ｎｏ−ｏｐとして処理され、そして分岐路に先行するエレメントに応答が搬送される。応答が最終的にグラフのルートに到達すると、要求側クライアント（別のサービス又はサービスプロキシーでよい）へ応答が返送される。
【００５９】
一実施形態において、メッセージ処理グラフのルートに何らかのエレメントが現われてもよい。最も簡単なルーターデザインの１つは、全グラフを代表してその頂部のみにルーティングノードをもたせることである。又、どんな２つのエレメントを一緒に連鎖するかについては何ら制約がない。例えば、２つのパイプライン対ノードは、それらの間に分岐ノードをもたずに、一緒に連鎖することができる。分岐に関しては、各分岐路が異なるエレメントでスタートしてもよく、即ち１つの分岐路は、ルーティングノードで直ちに終了してもよく、別の分岐路は、パイプライン対が後に続いてもよく、そして更に別の分岐路は、子孫を何らもたなくてもよい。後者のケースでは、子孫をもたない分岐路は、その分岐路が選択された場合に応答処理が直ちに開始されることを単に意味する。しかしながら、一般に、メッセージ処理グラフは、おそらく、２つの形態になる。即ち、非オペレーションサービスの場合には、グラフは、おそらく、ルートにおける単一のパイプライン対と、それに続くルーティングノードとで構成される。オペレーションサービスの場合には、メッセージ処理グラフは、おそらく、ルートにおける単一のパイプライン対と、それに続く、オペレーションに基づく分岐ノードとで構成され、各分岐路は、パイプライン対と、それに続くルーティングノードとで構成される。
【００６０】
一実施形態において、ルーターをＷＳＤＬベースのサービスに使用することができ、従って、オペレーション特有の処理を実行する必要がある。ユーザがオペレーションに基づいて分岐ノードを手動で構成するのを要求するのではなく、システムは、オペレーションに基づいて自動的に分岐するゼロコンフィギュレーション分岐ノードを与えることができる。サービスに基づいて定義された各オペレーションに対して分岐路を生成することができ、そして分岐変数は、もちろん、＄ｏｐｅｒａｔｉｏｎとなる。
【００６１】
メッセージの処理中に種々の理由でエラーが発生し得る（例えば、ルーティング中のトランスポートエラー、変換中の検証エラー、アンマーシャリング中のセキュリティエラー、等）。典型的に、これらのエラーは、特定のステージ、ルーティングノード、又はバインディングレイヤーから発生する。というのは、これらは、ルーターロジックの大部分を実施できる場所だからである。一実施形態では、システムは、ユーザがエラーハンドラーを定義するのを許すことによりこれらのエラーを取り扱うメカニズムを与える。一実施形態では、エラーハンドラーは、本質的に、ユーザがロギング、変換及びパブリッシュのような種々のアクションを実行してエラーを適宜取り扱うのを許す別のパイプラインノードである。
【００６２】
一実施形態では、エラーハンドラーは、全サービスプロキシー並びに各パイプラインノード及びその中のステージに対して構成することができる。エラーが発生したときには、最も内側を包囲しているエラーハンドラーによりそれが取り扱われる。例えば、変換エラーが変換ステージに生じた場合には、そのステージのエラーハンドラーによりそれを取り扱うことができる。このようなエラーハンドラーが構成されていない場合には、変換ステージを含むパイプラインのものである次のレベルのエラーハンドラーによりそれを取り扱うことができる。そのエラーハンドラーが存在しない場合には、ルーターレベルエラーハンドラーによりそれが取り扱われる。それが失敗した場合には、デフォールトシステムレベルエラーハンドラーがエラーを処理できる。
【００６３】
図７は、一実施形態によるエラー取り扱いの範囲を示す。各々の包囲ボックスは、エラー取り扱い範囲を表わす。図から明らかなように、ルーティングノード７０４に生じる非捕獲エラーに対する次のレベルのエラーハンドラーは、ルーターレベル範囲７０６にある。この範囲にハンドラーがない場合には、システムレベル範囲７０８にあるハンドラーが呼び出される。それ自身のエラーを捕獲しないパイプラインステージ７００については、エラーがパイプライン範囲７０２へ伝播し得る。そこにエラーハンドラーが定義されていない場合には、エラーがシステムレベル範囲７０８へ伝播し得る。各コンポーネントは、ステージであれ、パイプラインであれ、又はルーターであれ、エラーハンドラーをもつことができる。一実施形態では、インバウンドバインディングレイヤーが特定のステージ又はパイプラインに関連していないので、バインディングレイヤーに生じるエラーは、ルーターレベルのエラーハンドラーにより取り扱うことができる。アウトバウンドバインディングレイヤーのエラーは、どんなエンティティが通信を実行するかに基づいて多数の場所で発生し得る。例えば、ルーティング中に発生するバインディングレイヤーエラーは、ルーティングノードのエラーハンドラーにより捕獲することができる。同様に、パブリッシュステージにおけるパブリッシュオペレーション中に発生するバインディングレイヤーエラーは、ステージレベルのエラーハンドラーにより捕獲することができる。一実施形態では、空の又は非構成のエラーハンドラーは、エラーハンドラーを全くもたないことと同じである。本出願人の以前の変換例では、ステージレベルのエラーハンドラーが生成されたが構成されない場合には、エラーが次のレベルのハンドラーへ「泡立って伝わる(bubble-up)」ことになる。一実施形態では、エラーハンドラーは、再投入、リプライ及び継続の３つのアクションの１つで処理を終了することができる。再投入(rethrow)アクションは、エラーが再投入され、次のレベルのエラーハンドラーにより取り扱われることを意味する。特に指示のない限り、エラーハンドラーのデフォールト振舞いは、再投入することであり、空のエラーハンドラーが不存在のエラーハンドラーのように振舞う理由はこれである。リプライ(reply)アクションは、サービスプロキシークライアントに対して応答を直ちに発生しなければならないことを意味する。更なる全てのパイプライン処理が直ちに停止され、そしてメッセージ関連コンテクスト変数の状態に基づいて応答メッセージが送信される。それ故、これらの変数を必要に応じて変換して、意味のある応答メッセージを発生するようにエラーハンドラーを構成するのは、ユーザ次第である。
【００６４】
継続アクションは、エラーが全く生じなかったかのようにパイプライン処理を続けるのに使用される。エラーが首尾良く消滅されたどんな点においても処理が継続される。これは、コンテクスト変数を固定するようにユーザがエラーハンドラーを構成することを要求し得る。というのは、それらが、ルーターの残り部分により予想されない状態になり得るからである。エラーハンドラーがエラーを消滅すると、エラーハンドラーに関連したコンポーネントが実行を首尾良く終了したかのように処理が再開する。例えば、ステージにエラーが生じそしてそのステージに関連したエラーハンドラーがエラーを消滅した場合には、パイプラインの次のステージで、そのステージが首尾良く終了したかのように処理が継続される。しかしながら、そのステージで構成されたエラーハンドラーがないか、又はエラーハンドラーがエラーを再投入する場合には、パイプラインレベルのエラーハンドラーによりそれを消滅することができる。もしそうであれば、全パイプラインが実行を首尾良く終了したかのように処理が再開する。例えば、そのパイプラインがサービス要求パイプラインである場合には、オペレーション要求パイプラインで処理を進めることができる。ルーターレベルのエラーハンドラーについては、ルーターを首尾よく実行した後の次のアクションが応答をクライアントに送信するので、「継続」が「リプライ」に等しい。
【００６５】
一実施形態において、エラーハンドラーは単に別のパイプラインであるので、他のパイプラインと同様に構成することができる。例えば、パブリッシュステージは、エラー通知を他のサービスへ送信するのに使用してもよく、変換ステージは、コンテクスト変数を変更するのに使用してもよく、等々となる。しかしながら、あるステージは、エラーハンドラーに現われることが許されない。このとき、禁止されるステージは、ルーティングステージである。
【００６６】
標準的なコンテクスト変数に加えて、更に別の態様においてエラーハンドラーに使用可能な２つの付加的なコンテクスト変数がある。これらの変数は、エラーハンドラーが呼び出されたときにセットされ、そして通常のパイプライン処理が「継続」を経て再開された場合に自動的に除去される。２つの変数は＄ｆａｕｌｔ及び＄ｆａｕｌｔＡｃｔｉｏｎである。＄ｆａｕｌｔ変数は、エラーに関する情報及びそれがどこで発生したかを保持する。この変数は、他のコンテクスト変数と共に使用されて、パブリッシュ及び変換のようなステージ内の条件付きアクションを実行することができる。エラーハンドラーは、エラーを次のレベルのエラーハンドラーまで再投入する前に＄ｆａｕｌｔのコンテンツを変更することもできる。
【００６７】
＄ｆａｕｌｔＡｃｔｉｏｎは、エラーハンドラーが実行を終了したときにどんなアクションを実行できるか決定する特殊な変数である。これは、「再投入」、「リプライ」及び「継続」の３つの値の１つをとることのできる簡単なストリング値変数である。エラーハンドラーが実行を終了すると、この変数を検査して、サービスプロキシーがエラーを再投入すべきか、クライアントに直ちに応答すべきか又は処理を継続すべきか決定する。この変数は、「再投入」の値に初期化され、従って、ユーザがエラーハンドラーのデフォールト再投入振舞いを変更したい場合には値を「継続」又は「リプライ」に変化するための変換が必要となる。
【００６８】
一実施形態において、コンテクストは、プロパティバッグである。各プロパティ（「変数」）は、名前と、それに関連する値とを有する。パイプラインにおけるメッセージの断片を表わすと共に、インバウンド及びアウトバウンドサービスエンドポイントに関する情報を保持するために、予め定義されたコンテクスト変数が使用される。パイプライン処理中に付加的な変数が導入されてもよい。一実施形態において、コンテクスト変数は、ＺＱｕｅｒｙ表現で操作することができる。パイプラインステージは、それらの振舞いの一部分としてコンテクストを内部で操作することができる。
【００６９】
以下のリストは、一実施形態におけるシステム定義コンテクスト変数を、一実施形態による簡単な説明と共に示す。
−ｈｅａｄｅｒ（ヘッダー）：ＳＯＡＰメッセージに対するＳＯＡＰヘッダーを含む。
−ｂｏｄｙ（本体）：ＳＯＡＰメッセージに対するＳＯＡＰ本体を含む。
−ａｔｔａｃｈｍｅｎｔｓ（アタッチメント）：メッセージアタッチメントを含む。
−ｉｎｂｏｕｎｄ（インバウンド）：要求を受信したサービスプロキシーに関する情報を含む。
−ｏｕｔｂｏｕｎｄ（アウトバウンド）：メッセージを送信すべきところのターゲットサービスに関する情報を含む。
−ｏｐｅｒａｔｉｏｎ（オペレーション）：呼び出されるサービスプロキシーオペレーション（もし適用できれば）を識別する。
−ｆａｕｌｔ（フォールト）：処理中に発生したエラーに関する情報を含む。
−ｆａｕｌｔＡｃｔｉｏｎ（フォールトアクション）：エラーハンドラーを実行した後にどんなアクションをとるべきか指定する。
【００７０】
一実施形態において、ｈｅａｄｅｒ、ｂｏｄｙ及びａｔｔａｃｈｍｅｎｔｓは、メッセージ処理グラフを経て流れるときのメッセージの状態を表わす。メッセージの変更は、これら変数を変更することにより達成できる。これらの変数は、サービスプロキシーにより受信されるメッセージコンテンツを使用して初期化され、そして他のサービスへディスパッチするときに（例えば、ルーティングを経て）出て行くメッセージを構成するのに使用される。メッセージに関連した全ての変数は、メッセージ処理ノード及びステージにより更新可能である。これらの変数は、完全に独立したものであり、個々に変更することができる。
【００７１】
メッセージがサービスプロキシーにより送信されると、どの変数コンテンツをメッセージに含ませるかについて選択をなすことができる。この決定は、一実施形態では、ターゲットエンドポイントがＳＯＡＰメッセージを期待するか非ＳＯＡＰメッセージを期待するかに依存する。ＳＯＡＰの場合には、ｈｅａｄｅｒ及びｂｏｄｙがＳＯＡＰエンベロープにおいて結合され、メッセージを生成する。非ＳＯＡＰの場合には、ｐａｙｌｏａｄ（ペイロード）が全メッセージである。いずれにせよ、サービスがａｔｔａｃｈｍｅｎｔｓを期待する場合には、それにより得られるメッセージ及びａｔｔａｃｈｍｅｎｔｓ変数からＭＩＭＥパッケージを生成することができる。
【００７２】
ｈｅａｄｅｒ変数は、メッセージに関連したＳＯＡＰヘッダーを含む。これは、ヘッダーをサブエレメントとしてもつ＜ＳＯＡＰ：Ｈｅａｄｅｒ＞エレメントを指す。非ＳＯＡＰメッセージ、又はヘッダーをもたないＳＯＡＰメッセージの場合には、＜ＳＯＡＰ：Ｈｅａｄｅｒ＞エレメントは空となり、サブエレメントをもたない。
【００７３】
ｂｏｄｙ変数は、コアメッセージペイロードを表わし、＜ＳＯＡＰ：Ｂｏｄｙ＞エレメントを指す。ＳＯＡＰメッセージの場合には、ＳＯＡＰ本体がエンベロープから抽出され、そして本体変数に指定される。メッセージが非ＳＯＡＰであるか、又はＸＭＬでない場合には、全メッセージコンテンツが、新たに生成される＜ＳＯＡＰ：Ｂｏｄｙ＞エレメント内に入れられる。従って、ＳＯＡＰ及び非ＳＯＡＰメッセージの両方に対するコアペイロードが、同じ変数を経て且つ同じパッケージングで（例えば、＜ＳＯＡＰ：Ｂｏｄｙ＞エレメントにラップされて）得られることになる。
【００７４】
ａｔｔａｃｈｍｅｎｔｓ変数は、メッセージに関連したアタッチメントを保持する。更に別の実施形態において、ａｔｔａｃｈｍｅｎｔｓ変数は、各個々のアタッチメントに対して１つのサブエレメントを有するＸＭＬの単一ルート断片である。これらのサブエレメントは、アタッチメントに関する情報（ＭＩＭＥヘッダーから導出された）及びアタッチメントコンテンツを含む。この実施形態の態様において、ａｔｔａｃｈｍｅｎｔｓエレメントは、次のエレメントを含むことができる。
【００７５】
−Ｃｏｎｔｅｎｔ−ＩＤ（コンテンツ−ＩＤ）：アタッチメントを識別するグローバルに独特の参照。
−Ｃｏｎｔｅｎｔ−Ｔｙｐｅ（コンテンツ−タイプ）：媒体のタイプ及びアタッチメントのサブタイプを指定する。
−Ｃｏｎｔｅｎｔ−Ｔｒａｎｓｆｅｒ−Ｅｎｃｏｄｉｎｇ（コンテンツ−転送−エンコーディング）：アタッチメントをいかにエンコードするか指定する。
−Ｃｏｎｔｅｎｔ−Ｄｅｓｃｒｉｐｔｉｏｎ（コンテンツ−記述）：コンテンツのテキスト記述。
−Ｃｏｎｔｅｎｔ−Ｌｏｃａｔｉｏｎ（コンテンツ−位置）：アタッチメントを識別するローカルに独特のＵＲＩベースの参照。
−Ｃｏｎｔｅｎｔ−Ｄｉｓｐｏｓｉｔｉｏｎ（コンテンツ−処分）：受信者がアタッチメントをどのように取り扱うべきか指定する。
−Ｂｏｄｙ（本体）：アタッチメントデータを保持する。
【００７６】
一実施形態において、ｉｎｂｏｕｎｄ及びｏｕｔｂｏｕｎｄ変数は、インバウンド及びアウトバウンドエンドポイントに関する情報を含む。ｉｎｂｏｕｎｄ変数は、要求メッセージを受信したサービスプロキシーに関する情報を含み、一方、ｏｕｔｂｏｕｎｄ変数は、メッセージを送信できるところの行先サービス（例えば、ルート）に関する情報を含む。これら変数は、同じＸＭＬスキーマを有すると共に、「サービス」、「トランスポート」及び「クライアント」サブエレメントと、サービスディレクトリーに登録されるときにエンドポイントの名前を識別する単一の「名前」属性とを含む。
【００７７】
一実施形態において、サービス変数は、サービスに関する一般的な情報を含み、そして次のエレメントを含むことができる。
ｐｒｏｖｉｄｅｒＮａｍｅ：サービスプロバイダーの名前を保持する。
ｖｅｒｓｉｏｎＧｒｏｕｐ：サービスのバージョングループを識別する。
ｖｅｒｓｉｏｎ：バージョングループに対するサービスのバージョン番号を識別する。
ｏｐｅｒａｔｉｏｎ：外部サービスで呼び出されるオペレーションの名前を識別する。
【００７８】
一実施形態において、トランスポートエレメントは、サービスに関するトランスポートの細部を含み、そして次のエレメントを含むことができる。
−ｕｒｉ：エンドポイントのＵＲＩを識別する。インバウンドの場合、これは、メッセージが到着するＵＲＩである。アウトバウンドの場合、これは、メッセージを送信するときに使用するＵＲＩであり、サービスディレクトリーに登録されたＵＲＩ値をオーバーライドする。
−ｒｅｑｕｅｓｔ（要求）：トランスポートヘッダーを含む要求に関するトランスポート特有のコンフィギュレーション情報。各トランスポートは、ＲｅｑｕｅｓｔＣｏｎｆｉｇｕｒａｔｉｏｎ情報のそれ自身の特殊化を有してもよく、従って、このエレメントの構造は、最終的に、使用されるトランスポートに依存する。
【００７９】
−ｒｅｓｐｏｎｓｅ（応答）：トランスポートヘッダーを含む応答に関するトランスポート特有のコンフィギュレーション情報。ＲｅｑｕｅｓｔＣｏｎｆｉｇｕｒａｔｉｏｎ情報と同様に、このエレメントの構造は、最終的に、使用されるトランスポートに依存する。
−ｍｏｄｅ（モード）：通信スタイルが要求（一方向）であるか、要求−応答（二方向）であるかを指示する。
【００８０】
−ｓｅｃｕｒｉｔｙＴｙｐｅ（セキュリティタイプ）：トランスポートに対するセキュリティの対応を指示する。一実施形態では、考えられる値は、「なし（ｎｏｎｅ）」、「基本的」、「一方向ＳＳＬ」及び「二方向ＳＳＬ」である。
−ａｃｃｏｕｎｔＡｌｉａｓ（アカウントエイリアス）：このエレメントは、証明書マネージャーに登録された外部サービスアカウントへのエイリアスを識別する。トランスポートレイヤーは、この値を証明書マネージャールックアップにおけるキーとして使用し、アウトバウンドＨＴＴＰ／Ｓ接続で使用するためのｕｓｅｒｎａｍｅ／ｐａｓｓｗｏｒｄ（ユーザ名／パスワード）をフェッチする。
【００８１】
−ｑｕａｌｉｔｙＯｆＳｅｒｖｉｃｅ（サービスクオリティ）：メッセージを送信するときに期待されるサービスのクオリティを指定する。一実施形態では、考えられる値は、「ベスト・エフォート(best-effort)」及び「厳密に一度(exactly-once)」である。
−ｒｅｔｒｙＣｏｕｎｔ（再試みカウント）：メッセージを送信するときに使用すべき試みの回数。
−ｒｅｔｒｙＩｎｔｅｒｖａｌ（再試みインターバル）：メッセージを再送信する試みの前に待機すべきインターバル（秒）。
【００８２】
一実施形態において、メッセージ処理ステージは、ＸＱｕｅｒｙ及び／又はＸＵｐｄａｔｅを使用して、コンテクストを操作することができる。コンテクストにおける各変数は、同じ名前のＸＱｕｅｒｙ変数として表わすことができる。例えば、ｈｅａｄｅｒ変数は、ＸＱｕｅｒｙにおいて＄ｈｅａｄｅｒとしてアクセスすることができる。
【００８３】
一実施形態において、コンテクスト変数値は、オンデマンドで発生して、できるだけ多くストリームさせることができる。例えば、到来する要求及び応答メッセージは、トランスポートレイヤーによりＪａｖａ（登録商標）ＩｎｐｕｔＳｔｒｅａｍとして返送することができる。パススルー処理の場合には、ストリームは、サービスプロキシーが別のサービス又はサービスプロキシーへそれを送信するときまでタッチされない。ＳＯＡＰメッセージについては、ｈｅａｄｅｒ変数は、ｂｏｄｙを実施する必要なく、アンマーシャルとすることができる。同様に、アタッチメントは、ａｔｔａｃｈｍｅｎｔｓ変数がアクセスされる場合にはアンパックすることができる。オペレーションの場合にも、要求メッセージの検査をトリガーして、変数が特別にアクセスされる場合に呼び出されるオペレーションを決定しなければならない。
【００８４】
ルーティング、変換及びモニタリングに加えて、サービスバスは、クライアントと、サービスプロキシーと、サービスとの間のメッセージ交換をセキュアなものとすることのできる種々の特徴を含む。一実施形態では、サービスバスは、ＴＬＳ／ＳＳＬに勝るメッセージの機密性、メッセージの完全性、サーバー認証性及びクライアント認証性；ＳＯＡＰメッセージに対するメッセージレベルの機密性、完全性及び送信者の認証性；トランスポート及びメッセージの両レベルにおけるアクセス制御性；証明書マネージメント；及びセキュリティ監査を与える。
【００８５】
一実施形態において、サービスバスにおけるセキュリティ特徴は、プラグ可能なセキュリティプロバイダーアーキテクチャー及びセキュリティサービス、例えば、認証、身分主張、許可、ロールマッピング、監査、証明書(credential)マッピング、並びに証書(certificate)ルックアップ及び検証の使用である。サービスバスは、これら全てのプロバイダーを構築ブロックとして使用して、より高いレベルのセキュリティサービスを提供することができる。ユーザは、ボックスプロバイダーからのこれらのいずれかを、第三者プロバイダー又はそれら自身のカスタムプロバイダーと置き換えることができる。一実施形態では、サービスバスセキュリティは、ＢＥＡシステムズ・インクから入手できるＢＥＡ ＷｅｂＬｏｇｉｃ Ｅｎｔｅｒｐｒｉｓｅ ＳｅｃｕｒｉｔｙTMにより与えることができる。
【００８６】
図８は、一実施形態におけるサービスプロバイダーを示す図である。１つ以上の外部サービス８０８が外部サービスプロバイダー８０４により提供される。中間サービスバスのサービスは、サービスプロキシー８０６と称されるもので、これは、プロキシー（又はローカル）サービスプロバイダー８０２により提供することができる。サービスプロバイダーは、セキュリティ認識を有するアプリケーション、組織又は部門である。セキュリティ認識を有していて、サービスプロキシーを呼び出すクライアントは、サービス消費者８００と称される。外部サービスプロバイダーは、要求に同期的に又は非同期的に応答し得るので、本来、サービス消費者でもある。
【００８７】
種々の実施形態において、説明上、サービスバス及び外部サービスが、同じネットワーク内で、ファイアウオールの後方にあってもよいし、或いは異なるネットワーク上にあって、ファイアウオールがサービス消費者とサービスバスとの間及び／又はサービスバスと外部サービスとの間に存在してもよい。一実施形態では、サービスプロキシー及びターゲットサービスは、同じドメインに一緒に配列される。この特殊なケースは、ビジネスプロセスマネージメント（ＢＰＭ）である。スペクトルの他の端において、サービスバスプロキシーは、組織外部のトレーディングパートナーからメッセージを受信し又はそこへメッセージをルーティングする。一実施形態では、ユーザマネージメントが、所与の認証プロバイダーにおけるユーザ、グループ及びロールの生成、更新及び削除オペレーションを取り扱う。これらのプロバイダーは、セキュリティフレームワークの一部分である。更に、ユーザマネージメントは、ユーザプロパティの生成も許す。ユーザ、グループ及びロールは、コンソールと共に構成され、コンソールユーザ及びメッセージ送信者の認証に使用される。
【００８８】
一実施形態において、ユーザは、認証プロバイダーにおけるエンティティである。多数の認証プロバイダーがサポートされる。グループは、ユーザの論理的グループ編成であり、そのメンバーシップは静的で、そのグループのアドミニストレータにより指定される。ロールは、ユーザ及びグループの論理的グループ編成であり、そのメンバーシップは、ロールの条件及びポリシーに基づいて動的に計算される。アドミニストレータは、サポートされる認証プロバイダーのいずれかにおいてユーザ、グループ及びロールを生成し、読み取り、更新しそして削除することができる。アクセス制御ポリシーは、通常、ロールに基づく。
【００８９】
一実施形態において、サービスバスは、ＨＴＴＰＳを経ての一方向要求又は要求／応答（クライアントからサービスバスへの）に対してトランスポートレベルの機密性、メッセージの完全性、及びクライアントの認証をサポートする。サービスバスは、ポリシーベースのアクセス制御を実行できると共に、認証及び許可事象を監査することができる。認証又は許可が失敗したときにアラームをトリガーすることができる。一実施形態では、サービスプロキシーがアクチベートされたときに、サービスバスは、オンザフライで希薄なウェブアプリケーションを発生して展開することができる。アプリケーションサーバー（例えば、ＷｅｂＬｏｇｉｃ（登録商標）Ｓｅｒｖｅｒ）は、セッションマネージメント、クライアント証書検証及び認証、信用性マネージメント及びサーバーＳＳＬキー／証書操作を含むサーバー側ＳＳＬサポートを与えることができる。
【００９０】
一実施形態において、アプリケーションサーバーは、その証書をＳＳＬプロトコルにおいてクライアントに送信することができる。換言すれば、クライアントは、サーバーを認証する。それに加えて、ＳＳＬハンドシェーク中に、サーバーは、サーバーがクライアントを認証するように、クライアントに、その証書をサーバーへ送信するよう要求できる。これは、通常、２方向ＳＳＬと称される。クライアントがその証書を送信するよう要求されないときには、１方向ＳＳＬと称される。ＳＳＬの頂部におけるより高いレベルのプロトコルは、それら自身の認証メカニズムを自由に定義する。例えば、ＨＴＴＰＳでは、ＳＳＬハンドシェークが完了すると、クライアントは、そのユーザ名及びパスワードをＷＷＷ−ＡｕｔｈｅｎｔｉｃａｔｅＨＴＴＰヘッダーにおいて送信することによりサーバーに対して認証を行うことができる。これは、ＢＡＳＩＣ認証と称される。
【００９１】
一実施形態において、サービスプロキシーがクライアント認証を要求するように構成された場合には、サーバーは、サービスプロキシーエンドポイントへの全ての要求を認証することができる。ＢＡＳＩＣ認証の場合に、サーバーは、例えば、ＬＤＡＰ、アクティブなディレクトリー等の領域において構成された認証プロバイダーに対してクライアントを認証することができる。ＣＬＩＥＮＴ−ＣＥＲＴ認証の場合には、ＳＳＬエンジンがクライアントの証書を検証することができる。証書の信用性が確立されると、証書が認識主張プロバイダーへ通され、クライアントの認識が抽出される。この実施形態の態様において、認識主張プロバイダーは、サーバーセキュリティフレームワークの別のコンポーネントである。認識主張者は、証書のあるフィールドを抽出して、クライアント認識、通常は、証書のＳｕｂｊｅｃｔＤｉｓｔｉｎｇｕｉｓｈｅｄＮａｍｅのＣＮ（普通の名前）又はＥ（ｅメール）として使用するように構成される。最終的に、認証プロバイダーは、ユーザが属する全てのグループを収集するために呼び出される。最終結果は、クライアント認識を保持する１つのプリンシパルと、ユーザが属する各グループに対して１つのプリンシパルとを伴うサインされたＪａｖａ認証及び許可サービス（ＪＡＡＳ）サブジェクトである。
【００９２】
一実施形態において、サービスバスは、ＨＴＴＰプロキシーにおけるＢＡＳＩＣクライアント認証もサポートする。ＨＴＴＰ／ＨＴＴＰＳプロキシーが最初に配備されるときには、サービスプロキシーＵＲＩに対するアクセス制御ポリシーが認証プロバイダーに記憶される。一実施形態では、サービスバスは、ＸＡＣＭＬをサポートする。
【００９３】
一実施形態において、サービスプロキシーがクライアント認証を要求しない場合には、初期アクセス制御ポリシーが全ての要求へのアクセスを許可する。サービスプロキシーがクライアント認証（ＢＡＳＩＣ又はＣＬＩＥＮＴ−ＣＥＲＴ）を要求する場合には、初期ポリシーは、認証された全てのクライアントへのアクセスを許可する（が、匿名の要求は拒絶される）。セキュリティアドミニストレータは、サービスバスコンソールにおいてアクセス制御ポリシーを変更することができる。サービスバスでは、ユーザが次のポリシー間で選択を行うことができる。非チェック（全ての要求はアクセスが許可される）、除外（全ての要求が拒絶される）、認証ユーザ（匿名要求が拒絶される）、及びロールのセット。
【００９４】
一実施形態において、首尾良い認証は、クライアント認識プリンシパルと、ユーザが属する各グループに対して１つのプリンシパルとをラップするＪＡＡＳサブジェクトを生じさせる。ユーザは、グループに指定することができる。ロールは、グループ（又は他の基準、例えば、日時）に関して定義することができる。ユーザが属するロールのセットは、ランタイムに動的に決定される。アクセス制御ポリシーがロールのセットである場合には、これらロールの１つ以上に属するユーザは、アクセスが許可される。認証が首尾良くいった場合には、ウェブコンテナがサービスバスＨＴＴＰ／ＨＴＴＰＳトランスポートプロバイダーを呼び出す。そこから、メッセージは、サービスバスバインディングレイヤーへと進む。バインディングレイヤーは、認証されたＪＡＡＳサブジェクトからのクライアントプリンシパルをメッセージコンテクストに記憶し、そして要求パイプラインを呼び出す。パイプラインステージは、ビジネスルールにおいてクライアントプリンシパルを使用することができる。例えば、クライアント特有の変換を適用してもよいし、又はルーティングテーブル条件がクライアントプリンシパルを考慮してもよい。
【００９５】
要求パイプラインノードの終りに、プロキシーは、通常、メッセージをターゲットサービスへルーティングする。ターゲットサービスは、パイプラインのルーティングステージにより決定することができる。ルーティングステージは、同じターゲットサービスへルーティングすることもできるし、又はある条件に基づいてターゲットサービスを動的に選択することもできる。いずれにせよ、ターゲットサービスは、サービスバスのサービスディレクトリーに登録された外部サービス（又はサービスプロキシー）への参照として特定される。アドミニストレータは、サービスバスコンソールを使用して、外部サービスを登録する。
【００９６】
一実施形態において、外部サービスが登録されると、サービストランスポート及びサービスに対する１つ以上のＵＲＬが入力される。これは、その特定の外部サービスへ要求をルーティングするためにサービスプロキシーが使用できるトランスポート及びＵＲＬ（１つ又は複数）である。トランスポートがＨＴＴＰＳである場合には、次の認証メソッドの１つを指定することができる。即ち、ＢＡＳＩＣ、ＣＬＩＥＮＴ、又はクライアント認証なし。トランスポートがＨＴＴＰである場合には、ＢＡＳＩＣ、又はクライアント認証なしがサポートされる。認証メソッドがＢＡＳＩＣである場合には、オプションのＳｅｒｖｉｃｅＡｃｃｏｕｎｔを指定することができる。アウトバウンド（クライアント、例えば、プロキシー）認証を後でカバーすることができる。
【００９７】
一実施形態において、サービスバスは、一方向に対するトランスポートレベルセキュリティと、サービスバスプロキシーと外部サービスとの間でＨＴＴＰ（Ｓ）を経て送信された要求−応答メッセージとをサポートする。ＨＴＴＰＳは、機密性及び完全性を与える。又、これは、サービスバスがターゲットサーバーを認証するのを許す。更に、もし必要であれば、サービスバスプロキシーは、外部サービスに対して認証することができる。これは、インバウンドトランスポートセキュリティと同様であるが、この場合に、サービスバスは、ＨＴＴＰＳ接続を開始する。アウトバウンドの場合には、ＳＳＬプロトコルの観点から、サービスプロキシーがクライアントとして働き、そしてターゲットサービスを実行するサーバーがサーバーとして働く。サービスバスのＨＴＴＰＳトランスポートプロバイダーは、ＨＴＴＰＳ接続を経てターゲットサーバーへＨＴＴＰ要求を送信し、そしてＨＴＴＰ応答を受け容れる。ターゲットサーバーは、そのＳＳＬ証書をサーバーへ送信することができる。
【００９８】
一実施形態において、２つのクライアント認証メソッドを、ＨＴＴＰＳ、即ちＣＬＩＥＮＴ−ＣＥＲＴ及びＢＡＳＩＣと共に使用することができる。外部サービスがＣＬＩＥＮＴ−ＣＥＲＴ認証で構成される場合には、ＳＳＬハンドシェーク中に、サービスプロキシーは、そのＳＳＬクライアント証書をターゲットサーバーへ送信することができる。一実施形態において、サービスプロキシーは、ローカルサービスプロバイダーと任意に関連付けされる。証明書マネージャーは、証明書をローカルサービスプロバイダーに結合する。ローカルサービスプロバイダーは、ＳＳＬクライアント認証に対してプライベートキー及び証書をもつことができる。これは、ＳＳＬハンドシェーク中にサービスプロキシーが使用できるキー／証書である。多数のサービスプロキシーは、同じローカルサービスプロバイダーを参照することにより、同じＳＳＬクライアントキー／証書を共有することができる。
【００９９】
一実施形態において、外部サービスは、ユーザ名及びパスワードを送信することにより認証するようにサービスプロキシーに要求することができる。これは、通常、ＨＴＴＰＳを経て行われるが、サービスバスは、ＨＴＴＰを経てＢＡＳＩＣ認証もサポートする。ＨＴＴＰＳは、暗号化チャンネルを与え、それ故、ＨＴＴＰＳを経てパスワードを送信するのが安全である。他方、ＢＡＳＩＣ認証を伴うＨＴＴＰは、パスワードがワイヤ上を平文（ｂａｓｅ６４−エンコード化）で搬送されるので、強く反対される。
【０１００】
一実施形態において、ＨＴＴＰ又はＨＴＴＰＳ外部サービスがＢＡＳＩＣ認証で構成される場合には、付加的なサービスアカウントを任意に指定することができる。サービスアカウントが指定されない場合に、サービスプロキシーは、証明書マネージャーから使用すべきユーザ名及びパスワードを、サービスプロキシーＳＳＬクライアントキーを検索するのに類似した仕方で、決定することができ、即ちサービスプロキシーは、ローカルサービスプロバイダーに関連付けされ、そしてユーザ名／パスワードは、ローカルサービスプロバイダーに関連付けされる。外部サービスがサービスアカウントを指定する場合には、そのサービスアカウントに対するユーザ名及びパスワードが証明書マネージャーに記憶される。この場合に、サービスプロキシーは、ローカルサービスプロバイダーからユーザ名及びパスワードを取得せず、むしろ、サービスプロキシーは、サービスアカウントのユーザ名／パスワードを送信する。
【０１０１】
一実施形態において、メッセージコンテクストは、パイプラインノードのデザイナーが、ユーザ名／パスワード証明書の検索に使用するためのサービスアカウントの名前を指定するのを許すエレメントを有する。要求パイプラインにおける変換ステージは、メッセージコンテクストのこのエレメントをセットすることができる。指定された場合には、このサービスアカウントは、ローカルサービスプロバイダーの証明書もオーバーライドする。
【０１０２】
一実施形態において、サービスバスは、ＯＡＳＩＳウェブサービスセキュリティ（ＷＳＳ又は手短にＷＳＳ）をサポートする。ＷＳＳは、ＳＯＡＰメッセージに対するメッセージ機密性、完全性及び送信者認証についてのフレームワークを定義する。ＷＳＳは、個々のＳＯＡＰエンベロープに適用される。ＷＳＳは、ＸＭＬ−暗号化及びＸＭＬ−ＤＳＩＧを構築ブロックとして使用する。クライアントにおけるＷＳＳランタイムは、１つ以上の個々のメッセージ部分を暗号化し及び又はそれにデジタルでサインする。一実施形態において、新たなＳＯＡＰヘッダーがエンベロープに追加される。ＷＳＳヘッダーは、ＸＭＬ−ＤＳＩＧデジタルシグネチャー、セキュリティトークン、及び他の構成を含む。これらのセキュリティトークンは、送信者を認証し、キーをラッピングし（基本的に受信者のパブリックキーで暗号化されたランダムに発生された対称的暗号を搬送する）、シグネチャー検証証書を搬送し、又は送信者の暗号化パブリックキーと共に証書を含ませる（受信者が応答を暗号化できるように）のに使用できる。その結果、新たなＳＯＡＰエンベロープが得られる。受信者がセキュアなエンベロープを消費すると、暗号化オペレーションが逆の順序で実行され、そしてセキュリティヘッダーが除去される。次いで、受信者は、メッセージがそのポリシーに適合することを検証する（例えば、要求されたメッセージ部分がサイン及び／又は暗号化され、要求されたトークンが、要求された請求物と共に存在する、等々）。
【０１０３】
一実施形態では、ＳＯＡＰエンベロープの個々の部分は、デジタルでサインし及び又は暗号化することができる。それにより得られるメッセージは、依然、有効なＳＯＡＰエンベロープである。例えば、本体が暗号化されてもよいし、ＷＳアドレッシングヘッダーがサインされてもよいし、そして更に別のヘッダーがサインも暗号化もされなくてもよい。ＷＳＳは、セキュアなチャンネルに依存しない。むしろ、個々のＳＯＡＰエンベロープの１つ以上の部分が保護される。このＳＯＡＰエンベロープは、例えば、ＨＴＴＰ又はＪＭＳのような、どんな基礎的なプロトコル／トランスポートが使用されても、それを経て送信される。セキュリティ手段がメッセージそれ自体に組み込まれ、メッセージは、アプリケーションレイヤーへの経路全体にわたり、トランスポートプロトコルを越えて保護される。更に、中間物が、機密性、完全性及び認証のセキュリティプロパティを保持しながら、メッセージを中継することができる。従って、端−端の機密性、メッセージの完全性、及び送信者の認証を達成することができる。
【０１０４】
説明上、インバウンドＷＳＳセキュアメッセージは、次の通りである。
−サービス消費者からプロキシーへの要求。サービス消費者は、ＷＳＳを要求に適用し、そしてサービスプロキシーは、セキュリティヘッダーを処理し、セキュリティポリシーを実施する。
−サービス消費者からプロキシーへの要求。サービス消費者は、ＷＳＳを要求に適用するが、サービスプロキシーは、セキュリティヘッダーを処理せず、又、セキュリティポリシーも実施しない。サービスプロキシーは、要求を外部サービスへルーティングする。外部サービスが、セキュリティヘッダーを処理し、そしてポリシーを実施する。これは、要求パススルーシナリオである。
【０１０５】
−ターゲットサービスからプロキシーへの応答。ターゲットサービスは、ＷＳＳを応答に適用し、そしてサービスプロキシーは、セキュリティヘッダーを処理し、セキュリティポリシーを実施する。
−ターゲットサービスからプロキシーへの応答。ターゲットサービスは、ＷＳＳを要求に適用するが、サービスプロキシーは、セキュリティヘッダーを処理せず、又、セキュリティポリシーも実施しない。サービスプロキシーは、応答をサービス消費者へ転送する。サービス消費者がセキュリティヘッダーを処理し、ポリジーを実施する。これは、応答パススルーシナリオである。
【０１０６】
説明上、アウトバウンドＷＳＳセキュアメッセージは、次の通りである。
−プロキシーから外部サービスへのメッセージ。サービスプロキシーは、ＷＳＳをメッセージに適用し、そしてターゲットサービスは、セキュリティヘッダーを処理し、ポリシーを実施する。
−プロキシーからサービス消費者への応答。サービスプロキシーは、ＷＳＳをメッセージに適用し、そしてサービス消費者は、セキュリティヘッダーを処理し、ポリシーを実施する。
【０１０７】
更に説明上、サービス消費者は、暗号化されたＷＳＳ ＳＯＡＰメッセージをサービスプロキシーへルーティングのために送信することができ、サービスプロキシーは、おそらく、ある平文ヘッダー、例えば、ＷＳ−アドレッシングヘッダー又はカスタムヘッダーの値に基づいて、メッセージをルーティングし、バックエンドのサービスは、暗号化されたメッセージを受信して、それを暗号解読し、そして要求を処理する。次いで、サービスは、応答を、クライアントのパブリックキーで暗号化して送信する。サービスプロキシーは、その応答をクライアントに配送する。サービスプロキシーは、メッセージを暗号解読する必要がない。サービス消費者及びバックエンドのサービスは、サービスプロキシーが微妙なデータを読み取れないことが保証される（サービスプロキシーが暗号解読キーを有していないので）。同様に、サービス消費者は、認証の目的でセキュリティトークンを含んでもよく、そしてサービスプロキシーは、トークンをターゲットサービスへ中継することができる。
【０１０８】
一実施形態において、説明上、サービスプロキシーは、例えば、外部ビジネスパートナーから到来する要求に対してサービスバスがゲートウェイとして使用されるときに、サービス消費者から到来する要求のＷＳＳヘッダーを処理するように構成できる。これは、サービスプロキシー及びターゲットサービスが共通位置にあってゲートウェイにおけるアクセス制御を実施するとき、及びターゲットサービスがＷＳＳをサポートしないときに、計算的に集中する暗号解読、シグネチャーの検証及び認証オペレーションからバックエンドサービスをオフロードするのに有用である。一実施形態において、サービス消費者は、メッセージの１つ以上の部分を暗号化し及び又はそれにサインし、及び／又は認証トークンを含ませる。サービスプロキシーは、トークンを認証し、メッセージを暗号解読し、そしてデジタルシグネチャーを検証する。ＷＳＳ認証トークン及びメッセージコンテンツに基づくアクセス制御をここで行うことができる。次いで、平文メッセージが要求パイプラインを経て進行する。パイプラインの終りに、メッセージは、ターゲットサービスへルーティングされる。
【０１０９】
説明上、サービスプロキシーは、サービス消費者に代わってメッセージにＷＳＳを適用することができる。この場合に、サービスプロキシーは、サービス消費者から平文メッセージを受信する。メッセージは、要求パイプラインを通常通りに流れる。パイプラインの終りに、ターゲットサービスが決定されると、メッセージを実際に送信する前に、サービスプロキシーは、認証トークンを暗号化し及び又はそれにサインし及び／又はそれをメッセージに追加する。この新たなセキュアなＳＯＡＰエンベロープがターゲットサービスへ配送される。
【０１１０】
一実施形態において、システムは、ＯＡＳＩＳウェブサービスセキュリティ規格並びにユーザ名トークンプロフィール及びＸ．５０９トークンプロフィールをサポートする。バックエンドサービス、クライアント及びサービスプロキシーは、ウェブサービスポリシーフレームワーク（ＷＳ−ポリシー）仕様書がＢＥＡ、ＩＢＭ、マイクロソフト、ＳＡＰ、ソニックソフトウェア及びＶｅｒｉＳｉｇｎにより開発された後にモデリングされた任意のＷＳ−ポリシーで構成することができる。このフレームワークは、ウェブサービス要求及び能力を指定し及び構成するための拡張可能なアーキテクチャーを定義する。
【０１１１】
所与の要求／応答ラウンドトリップにおいて、４つ全てのメッセージを個々に保護することができる。全メッセージ経路における４つのメッセージの各々は、ＷＳ−ポリシーで指定された要求を潜在的に受ける。送信者は、例えば、１つ以上のメッセージ部分にサインし及び／又はそれを暗号化し、及び／又は必要な認証トークンを含ませることにより、ポリシーに適合するメッセージを形成するように必要なステップを適用することができる。受信者は、メッセージを消費するに必要なステップ、即ち暗号解読、シグネチャーの検証、及びトークンの検証／認証を実行することができる。加えて、受信者は、メッセージが実際にポリシーに合致することを検証できる。
【０１１２】
一実施形態において、サービスバスは、サービス消費者及び外部サービスとセキュアに対話するのに必要な証明書と共に構成することができる。特に、インバウンドメッセージでは、サービスバスは、次のように構成することができる。
−その（サーバー）証明書を送信して、クライアントがサービスバスサーバーを認証できるようにする（例えば、ＳＳＬハンドオーバーの間に）。
−メッセージ送信者をトランスポートレベル又はメッセージレベルで認証する。
−暗号化されたメッセージをサービスバスのプライベート暗号解読キーで暗号解読する。
−到来するメッセージにおけるデジタルシグネチャーを検証する。
【０１１３】
アウトバウンドメッセージにおいて、サービスバスは、次のように構成することができる。
−接続の他端においてサーバーを認証する（例えば、ＳＳＬハンドシェーク中に）。
−トランスポートレベル又はメッセージレベルで受信者に対してそれ自身を認証する。
−意図された受信者のパブリックキーでメッセージを暗号化する。
−認証又はデータ完全性の目的でメッセージにサインする。
【０１１４】
サービスバスの証明書マネージャーコンポーネントは、証明書をマネージしそして証明書を検索するためにオペレーション、アドミニストレーション及びメンテナンスＡＰＩ並びにランタイムＡＰＩを与えることができる。証明書は、２つのカテゴリーに分けることができる。即ち、外部証明書（サービスプロキシーと対話する外部サービス又はサービス消費者に属する証明書）；及びローカル証明書（サービスプロキシー又はサービスバスシステム全体に属する証明書）。
【０１１５】
更に別の実施形態において、証明書は、タイプで分類することができる。サービスバスは、ユーザ名／パスワード、プライベートキー／Ｘ．５０９証書チェーン、及び信用のあるＸ．５０９証書をサポートすることができる。証明書マネージャーは、他の証明書タイプをサポートするように拡張することができる。一実施形態において、証明書は、それが外部であるかローカルであるかに関わらず、サービスバスリソースに結合することができる。例えば、プロキシーのウェブサービスセキュリティポリシーが、インバウンドメッセージのＳＯＡＰ本体をＲＳＡで暗号化することを要求する場合には、サービスプロキシーに結合されたプライベートキー及びＸ．５０９証書が存在し得る。証明書マネージャーは、サービスバスリソースと証明書との間のこれら結合をマネージする。
【０１１６】
一実施形態において、証明書マネージャーは、次の証明書をマネージする。
−ローカルサービスプロバイダーの場合：暗号化証書及びそれに対応するプライベートキー；デジタルシグネチャープライベートキー及び証書；ユーザ名／パスワード；ＳＳＬクライアント認証に使用されるローカルサービスプロバイダーのためのＳＳＬプライベートキー及び証書；ＷＳＳ認証のためのプライベートキー及び証書（Ｘ．５０９トークン）。
−外部サービスプロバイダーの場合：暗号化証書；デジタルシグネチャー検証証書；ユーザ名／パスワード；ＳＳＬクライアント証書；ＳＳＬサーバー証書；Ｘ．５０９認証証書（ＷＳＳ Ｘ．５０９トークン認証のための）。
−サービス消費者の場合：暗号化証書；デジタルシグネチャー検証証書；ユーザ名／パスワード；ＳＳＬクライアント証書；ＷＳＳ認証のためのＸ．５０９認証証書（Ｘ．５０９トークン）。
【０１１７】
一実施形態において、ルールは、基本的に、表現を評価しそして（通常）ブールの結果を生み出すステートメントである。ルールは、ルールが「真」と評価する場合に実行される関連アクションのリストを含むことができる。ルールに含まれる条件は、現在日時（例えば、ビジネスカレンダー）から、ランタイムコンテクストデータ、ユーザプロフィール等までの範囲とすることができる。例えば、これに限定されないが、ルールを使用して、システム健全さ及び応答時間に基づきＳＬＡ警告をトリガーし、ある条件に基づきサービスバスのサービスの「コスト／健全さ」を動的に調整し、セキュリティ違反の場合に通知を発生し、そしてサービス着手の拒絶を検出することができる。例えば、
ルール１：サービスＯｒｄｅｒＲｏｕｔｅｒの平均応答時間が３５０ミリ秒「より長い」場合には、通知を行う。
ルール２：９ａｍと５ｐｍとの間でサービスＣｒｅｄｉｔＣｈｅｃｋの応答時間が１０秒「より長い」場合には、ウェブサービス「Log a trouble ticket」を呼び出す。
【０１１８】
一実施形態において、コンソールを経てルールを生成し、ＸＭＬで表わすことができる。ＸＭＬコンフィギュレーションスキーマは、ルールフォーマットを定義することができる。サービスバスルールエンジンは、ルールの位置に基づいて多数の異なる種類のルールをサポートすることができる。種々のルールタイプについて、以下に詳細に説明する。一実施形態では、サービスバスルールは、次のフォーマットを有する。
＜条件のセット＞の場合には、＜アクションのセットを実行する＞
【０１１９】
説明上、条件は、時間（カレンダー）と、モニタリングフレームワークにより集計されるモニタリングデータとをベースとすることができる。これは、多数の更なる条件タイプ、例えば、ユーザプロフィール属性、パイプラインコンテクストランタイムデータ、等々を含むように容易に拡張することができる。一実施形態において、各条件タイプは、それ自身をルールフレームワークに登録し、そしてコンフィギュレーション及び評価インターフェイスを与える。これは、将来必要となる多数の条件タイプをプラグインすることを許す。
【０１２０】
一実施形態において、ルールは、次の２つのカテゴリーに広く分類することができる。即ち、ＳＬＡルール、及びインラインルール。ＳＬＡルールは、主として、ＳＬＡを評価し、そして警告をトリガーして潜在的なシステム欠陥を事前に捕えるのに使用される。これは、規則的な間隔で全てのサービスプロキシーからモニタリング情報を集計し、そして発生状態をチェックして、全ての性能制約を満足するよう確保することにより、実行できる。インラインルールが有用であるのは、パイプラインが実行されるときに、モニタリングデータの集計に遅延を伴うことなく、ルールをインラインでトリガーする（大部分はエラーパイプラインから）ことを要求する使用ケースをサポートする必要があるためである。例えば、「セキュリティ証明書の不一致から発信したメッセージを顧客に通知する。」このケースでは、顧客に対するコンタクト情報をユーザマネージメントモジュールからルックアップする必要がある。これは、ルールの「トリガーポイント」をパイプラインの内部に埋め込みそしてビジネスユーザがルールをランタイムにこれらトリガーに関連付けるのを許すメカニズムを必要とする。又、このようなルールは、ある最小限の量のランタイムコンテクストデータをアクション（現在ユーザプロフィール、現在メッセージ、等）に対して通すことしか要求しない。
【０１２１】
ルールは、マネージメントコンソールを経て構成することができる。各ルールは、単一の特定の「エンティティ」（サービス、ステージ、Ｊ２ＥＥリソース、等）に関連付けられる。ルールスキーマは、各ルールのフォーマットを定義することができる。一実施形態において、ルール構築者は、ルールを構成するのに必要な全てのエレメントを一緒に結び付けることにより、ルールを構成するためのユーザに対するフロントエンドを提示する。これは、ルールの名前及びバインディング、即ちルールが結合されるところのエンティティ（サービス、ステージ、ＪＭＳリソース、等）を特定することを含む。サービスを選択することは、パイプライン、ルーター及びトランスポートに得られるモニタリングエレメントを使用してルールを構成できることを意味する。一実施形態において、バインディングは、もしあれば、どんなランタイムデータがルールに得られるかを明確に識別することに関して、ルールに対する「コンテクスト」を与える。
【０１２２】
一実施形態において、ルールのトリガーを指定することができ、即ちルールは、アクションを一度トリガーしそして手動リセット又は条件付き自動リセットを待機することができ；ルールは、それが真と評価するたびにアクションをトリガーし；そしてルールは、それが真と評価する場合に「ｘ」分ごとにアクションをトリガーし、等々となる。
【０１２３】
一実施形態において、ルールは、ゼロ以上の条件を含むことができる。これら条件は、異なるタイプのもので、ビジネスカレンダー、モニタリングデータ、ランタイムコンテクスト変数、等々がある。ルールフレームワークは、ランタイムパースペクティブからの新たな条件タイプを容易にプラグインするように設計される。
【０１２４】
ルールが結合されるエンティティに基づき、ルール構築者のユーザインターフェイスは、特定の条件タイプをルールに含ませるのを許すことができる。例えば、ＳＬＡルールは、特定のバインディングにおいて得られるモニタリングデータに基づいて定義することができる。ＪＭＳリソースに関連したルールは、サーバーにより定義されたＪＭＳリソースメトリックに基づく条件を含むことができる。しかしながら、全てのバインディングポイントへ展開されるルールに関連し得るビジネスカレンダーのような幾つかの条件タイプが存在し得る。これは、カレンダーが特定コンテクスト／バインディング関連データに依存しないためである。各条件は、ＯＲ及びＡＮＤ演算子を使用して任意に加えることができ且つネスト状にすることができる１つ以上の表現で構成される。例えば、次のルールを考える。
【０１２５】
「９ａｍと５ｐｍとの間に」、「サービスＡＢＣのａｖｅｒａｇｅ＿ｒｅｓｐｏｎｓｅ＿ｔｉｍｅが２秒を越えるか「ＯＲ」ｓｅｃｕｒｉｔｙ＿ｖｉｏｌａｔｉｏｎ＿ｃｏｕｎｔが２５を越える場合に」、ｅメールにより私に「手動リセット又は条件付き自動クリアまでに、一度」通知すること。
【０１２６】
上記ルールには、２つの条件タイプ、即ちビジネスカレンダー及びモニタリングデータがある。モニタリングデータに基づく条件は、論理的にＯＲされる。上記ルールが真であるためには、現在システム時間が９ａｍと５ｐｍとの間であり「ＡＮＤ」ａｖｅｒａｇｅ＿ｒｅｓｐｏｎｓｅ＿ｔｉｍｅが２秒を越えるか「ＯＲ」セキュリティ違反が２５を越える。これらの条件は、最上位レベルで全て「ＡＮＤ」される。個々の条件は、（ＯＲ及びＡＮＤを使用して）任意に合成でき且つネスト状にできる表現で構成される。
【０１２７】
一実施形態において、アクションのリストは、ルールが真と評価するときに実行される必要のあるアクションを指定するルールを付随することができる。ユーザは、ルールにアクションを含まないことを選択してもよい。一実施形態では、ルールは、少なくとも１つの条件「ＯＲ」１つのアクションを有する。アクションを実行するのに必要な全ての所要コンフィギュレーションパラメータを指定するためにユーザに尋ねることができる。一実施形態では、アクションは、通知ｅメールを送出するような簡単なタスクから、特定のワークリストへルーティングされたトラブルチケットをログするためのリモートウェブサービスを呼び出すことへと変化し得る。サービスバスに警告するフレームワークにおいて使用できる幾つかのアクションは、次の通りである。即ち、ｅメールによる通知；ウェブサービスの呼び出し；及びサービスコストのセット、即ちサービスディレクトリーにおけるサービスの「コスト」をセットすること。サービスのコストを使用して、ルーティング判断を行うことができる。
【０１２８】
一実施形態において、ルールエバルエーター(evaluator)は、事象によりトリガーされたときにルールを評価する。これは、直接ＡＰＩ呼び出しを経て行うことができ、即ちルールエバルエーターは、ルール評価をトリガーするのに使用できるＡＰＩメソッドを備えている。メソッド呼び出しパラメータは、評価する必要のある１つ以上のルールを識別するための情報を含むことができる。例えば、モニタリングデータアグレゲータ(Aggregator)は、サービスに対して新たなモニタリングデータが使用可能となったときにそのサービスに関連したＳＬＡルールを評価するためのルールエバルエーターＡＰＩを呼び出すことができる。又、ルール評価は、事象契約によりトリガーすることもでき、即ちエバルエーターは、事象メカニズムと契約し、そして事象が生じたときにルール評価をトリガーすることができる。事象コンテクストは、ルール評価及びアクション実行に使用できる全てのランタイム情報を含むことができる。セキュリティ違反事象を生じるセキュリティステージは、ルール評価をトリガーしてアドミニストレータに通知することができる。この例では、事象コンテクストは、メッセージＩＤ及び送信者のアドレスを含むことができ、これは、アドミニストレータが問題の原因を明確に識別する上で助けとなり得る。タイマーベースのルールは、ビジネスカレンダーにより所定のスケジュールに基づいてトリガーすることができる。一実施形態では、スケジューリングサービスがタイマー事象を発生でき、ルールエバルエーターは、これに契約し、そして事象が生じたときにルール評価プロセスをキックオフすることができる。
【０１２９】
一実施形態では、システムの健全さをモニタリングするのに使用できるデータを集計するフレームワークがある。このフレームワークの重要な特徴は、ユーザがコンフィギュレーションにより性能モニタアプリケーションをサービスバスのサービスへ容易に埋め込むのを許し、ランタイムにモニタリングをディスエイブル／イネーブルするメカニズムを与え、データを集計して潜在的なシステム欠陥をユーザに通知するための警告を計算し、そして集計データに基づいて基本的メトリック（例えば、最小、最大、平均等）を与えることを含む。
【０１３０】
一実施形態において、モニタリングフレームワークは、モニタリングエレメントのリストを定義することができる。モニタリングエレメントは、モニタリングメトリックの特定のカテゴリーである。モニタリングエレメントは、広範囲の種々のコンポーネントにより使用できるに充分なほど一般的である。モニタリングエレメントのリストは、拡張可能であり、そして必要に応じて、より多くのエレメントを追加できる。一実施形態では、フレームワークは、現在、次のモニタリングエレメントを定義することができる。
【０１３１】
−カウンタ：処理された要求の数、エラーの数、処理されたメッセージの数、等のものを追跡するために、ユーザがそれらのコードにおいてカウンタを定義して使用するためのメカニズム与える。カウンタは、カウンタの現在値を増加し、減少し及びリセットするためのメソッドを与えることができる。
−タイマー：アプリケーションは、タイマーを使用して、特定のオペレーションを計時することができる。タイマーは、スタートし、ストップし、リセットし、そしてタイマーがスタートして以来の経過時間の長さをチェックするメソッドを与えることができる。
【０１３２】
図９は、一実施形態によるモニタリングコンポーネントを示す図である。アドミニサーバー９００におけるコンフィギュレーションマネージャー９１４は、モニタリングフレームワークに必要なコンフィギュレーション情報を捕獲する。例えば、これは、各アプリケーションに対するモニタリング属性、各属性のデータタイプ、モニタリングがイネーブルされるかどうか、各アプリケーションに対してモニタリングデータを集計する必要のある頻度、等のリストを含むことができる。モニタリングデータにおいて外部アプリケーションに関心がある場合には、それらをコンフィギュレーションマネージャーに登録することもできる。一実施形態において、モニタリングマネージャー９０６は、マネージされるサーバー９０２において実行される。一実施形態において、モニタリングマネージャーは、ＭＢｅａｎｓ９１６を経て外部にそしてファクトリーを経て内部に露出することができる。それらの主たる機能は、各々のマネージされるサーバーにおいてモニタリングされる情報をマネージすることである。又、アプリケーションがそれらのデータ属性に対してモニタリング機能を呼び出せるように、ＡＰＩを設けることもできる。
【０１３３】
一実施形態において、データアグレゲータ９１０は、アドミニサーバーにおいて規則的な間隔で実行され（構成可能である）、そして所与のドメインにおいてマネージされるサーバーからの全ての情報からデータを集計する。集計されたデータは、処理され、そして各アプリケーションのコンフィギュレーションに指定された特定の時間インターバルへと分類される。コンソールは、集計されたデータを使用してモニタリング情報を表示することができる。規則的なインターバルで、モニタリングデータパブリシャー（図示せず）は、アーカイブ又は外部計算の目的で、データを、登録された外部アプリケーションに対してパブリッシュする。ルールマネージャー９１８は、ルールを記憶する役目を果たし、集計されたデータを使用してルールを評価する。一実施形態において、ルールが真であると評価されると、警告マネージャー９１２がコールされる。警告マネージャーは、ルールが真であると評価されたときに他のプロセスを通知する。例えば、ｅメールを送信し、及び／又はルールに関連したアクションに基づいて待ち行列のメッセージをポストすることができる。
【０１３４】
一実施形態において、説明上、データアグレゲータ９１０は、データが古くなるにつれてメモリに保持するデータを益々少なくする。異なる時間周期に異なる精度でデータを見るようにウインドウを定義することができる。例えば、次のウインドウ、即ち５分、１時間、２４時間、が定義される。カウンタについては、最後の５分間に、全ての変化（例えば、１秒、又は１０秒で変化し、及びそのような変化を得ると判断できる）を記憶しようとすることを意味する。最後の１時間については、変化が５分である。最後の２４時間については、変化が１時間である。それより大きな周期については、変化が１日である（暗示的）。このコンフィギュレーションでは、最後の５分に所定数の値、最後の１時間に＋１２の値、最後の１日に＋２４の値、そして１日で＋１の値をメモリに記憶する必要があることを意味する。従って、３６５日間で、〜＝４００の値となる。集計されたデータは、コンソールにおいてグラフに表示し、及び又はこれを使用してルールをトリガーすることができる。
【０１３５】
一実施形態において、ユーザは、コンソールにおいてルールを対話式に指定することができる。例えば、コンソールは、ルールに対してＸＱｕｅｒｙ表現の中にドラグ及びドロップすることのできるサービスのサービス／ステージ／トランスポート／クオリティにより編成されたモニタされる変数のツリーを表示することができる。又、ＸＱｕｅｒｙ表現へ機能をドラグ及びドロップすることもできる。
【０１３６】
一実施形態において、モニタリングフレームワークを使用してモニタリングデータを捕獲することを希望するアプリケーションは、モニタリングされる必要のある属性のリストを指定すると共に、任意であるが、時間のスライディングウインドウと、データを捕獲するためのそのウインドウ内の更新の周波数とを指定することができる。スライディングウインドウ及びそのウインドウ内のインターバルが指定されたときには、システムは、構成された最新の時間インターバル内に形成された全てのモニタリングエンティティのリストである「最新アクティビティウインドウ」を維持するように構成することもできる。一実施形態において、システムは、カウンタ及びタイマーを使用してモニタリングをサポートする。
【０１３７】
一実施形態において、コンフィギュレーション情報は、各アプリケーションがモニタリングする属性のリストを定義する。各アプリケーション（又はトランスポートの場合のように、アプリケーションインスタンス）は、それ自身をモニタリングフレームワークに登録することができる。登録は、独特の名前と、モニタリングできる属性（及びそれに対応するデータタイプ）並びに時間ウインドウ仕様のリストとを与えることを含む。フレームワークは、コンフィギュレーションに対するスキーマをパブリッシュすることができる。
【０１３８】
一実施形態において、アドミニサーバーは、フレームワークにより与えられる全てのランタイム機能を含む。アドミニサーバーにおいて、これは、全てのマネージされるサーバーからのデータを集計し、データを各時間インターバルウインドウへとトリアージュし、集計されたデータに基づいて統計値を計算し、集計されたデータにアクセスするためのＭＢｅａｎインターフェイスを定義し、警告マネージャーにデータの変化を通知し、従って、ルールをトリガーできるようにし（又は規則的なインターバルでルールを評価できるようにし）、そして外部アーカイブシステムへモニタリングデータをパブリッシュするメカニズムを与えることができる。マネージされるサーバーでは、モニタリングマネージャーは、モニタリングデータを記録するためにアプリケーションに対してＡＰＩを定義し、データのランタイム記憶を与え、そしてＭＢｅａｎｓを経てそのデータを露出させることができる。
【０１３９】
一実施形態において、モニタリング値をログするために、アプリケーション（例えば、トランスポート、パイプラインステージ）は、最初に、独特のアプリケーション名を通すことにより各アプリケーションに対してモニタリングコンテクストを検索する必要がある。モニタリングコンテクストは、名前の付いたカウンタ及びタイマーへのアクセスを与え、これらが、データをログするメソッドを与える。例えば、サンプルソースコードは、次のように見える。
ctx.getMonitoringService().getTimer(“execution_time”).start();
ctx.getMonitoringService().getCounter(“nb_messages”).increment();
ctx.getMonitoringService().getTimer(“execution_time”).stop();
【０１４０】
アドミニサーバーは、データアグレゲータ９１０を備え、これは、特定のポーリングインターバルで各マネージされるサーバーをポーリングし、そしてデータを集計する。集計されたデータは、分類され、そしてアプリケーション名及び構成された各時間ウインドウで編成されたメモリ記憶ビンへとビン処理される。次いで、更新されたデータに基づいて統計値が計算される。モニタリングランタイムビーン９１６は、アプリケーションがこの集計されたデータにアクセスするのを許すことができる。加えて、アドミニサーバーは、ルールマネージャー９１８に通知することができ、従って、ルールは、更新されたデータに対して実行され、及び／又はデータをパブリッシュすることができる。
【０１４１】
ルールの条件が真である場合には、それに関連したアクション（１つ又は複数）を実行することができる。一実施形態において、アクションは、サービスとして実施することができる。一実施形態において、ルールは、ユーザ指定のインターバルで周期的に評価することができる。一実施形態において、サービスバスに展開されるサービスとして警告が実施される。フレームワークは、特定のＪＭＳトピックについて集計したモニタリングデータを外部アプリケーションへパブリッシュすることを外部アプリケーションが選択できるようにするコンフィギュレーションメカニズムを与える。
【０１４２】
一実施形態において、ルールは、１つ以上の表現を評価してブールの結果を生じるステートメントである。更に別の実施形態では、ルールは、ルールに含まれた全ての条件を評価した結果として「真」の値が生じる場合に実行される関連アクションのリストも有する。ルールに含むことのできる条件は、例えば、現在日時（ビジネスカレンダー）と、現在ユーザプロフィールと、アプリケーション応答時間（又は他のモニタリングデータ）と、アプリケーションが遭遇するセキュリティ違反である。ルールに含ませることのできるアクションは、例えば、ｅメールアドレスを通知し、メッセージを送信し、新たなタスクエントリーを生成し、サービスを呼び出し、そしてサービスをイネーブル／ディスエイブルすることである。
【０１４３】
ルールの例：
−簡単なアクション：特定サービスの平均応答時間があるスレッシュホールドを越えるときにアドミニストレータへ通知を送信する。
−毎日、９ａｍから５ｐｍの間に５分のインターバルで１０個を越えるセキュリティ違反に遭遇する場合に警告を発する。
−タイプＸのメッセージが最後の１０分に１０回を越えて検出された場合に、エントリーをログする。
−タイプＰのプロセスインスタンスが１２時間以上「ランニング」であった場合に、ワークリストタスクエントリーを生成する。
【０１４４】
一実施形態において、ルールは、自然言語、ＸＱｕｅｒｙステートメント等の多数の異なる方法で表現することができる。コンソールは、ユーザがルールを管理するのを許すことができる。その基礎となるルールは、ＸＭＬドキュメントとして存続することができ、そしてこのＸＭＬに対するスキーマをパブリッシュすることができる。一実施形態では、ルールフレームワークランタイムは、このＸＭＬドキュメントを消費し、そしてランタイムにルールを評価することができる。ＸＭＬドキュメントは、これらのルールを評価するときに適当なランタイムフォーマットへ変換することができる。例えば、モニタリングメトリックベースの条件は、ＸＱｕｅｒｙとして評価することができる。例えば、これに限定されないが、図１０を参照すれば、ルールトリガーは、種々の種類のものがあり、即ち更新されたモニタリングメトリックの利用性１０１０、事象１０１２、ある状態から別の状態へのプロセス遷移、サービスの平均応答時間の変化、あるタイプのメッセージの到着１０１２、及びルールを周期的にトリガーするスケジューリングサービス１０１８がある。
【０１４５】
一実施形態では、ルールコンテクストは、ルールに含まれる条件及びアクションを評価するときにルールにより消費されるランタイムデータをカプセル化する。ルールコンテクストは、ルールトリガーに非常に厳密に関連付けられる。ルールコンテクストに含まれたランタイムデータは、トリガーのタイプに依存する。例えば、サービスの平均応答時間の変化に関連したトリガーにより発生されるルールコンテクストは、サービスの名前及び平均応答時間の新たな値を含むことができる。事象トリガーに基づくルールコンテクストは、事象の性質と、その特定事象に関連したデータとを含むことができる。
【０１４６】
ルールは、種々のエンティティに関連して定義することができる。一実施形態において、ルールバインディングは、ルールに関連したエンティティに関する情報を捕獲する。ルールバインディングは、もしあれば、どんなランタイムデータがルールに使用できるか明確に定義することに関してルールコンテクストに影響する。ルールに関連したこのような各エンティティは、条件及びアクションを構築するのに使用できるデータのセットをルールに与えることができる。例えば、サービスプロキシーに結合されたＳＬＡルールは、そのサービスに対して使用可能なモニタリングメトリックをベースとする条件を含むことができる。
【０１４７】
先に述べたように、ルールは、条件のリスト及びアクションのリストを含むことができる。各ルールは、次の構造をもつことができる。
＜条件のセット＞の場合に、＜アクションのセットを実行する＞
【０１４８】
ルールは、ゼロ以上の条件を含むことができる。一実施形態において、条件を含まないルールは、常に、真であり、そしてルールがトリガーされるたびにアクションが実行される。条件は、異なるタイプのものでよく、即ちビジネスカレンダー、モニタリングデータ、ユーザプロフィール及び他の適当なタイプでよい。フレームワークは、顧客により望まれる新たな条件タイプを受け容れるためにランタイムに新たな条件タイプを容易にプラグインできるように設計される。
【０１４９】
一実施形態において、ルールに含ませることのできる条件のタイプは、ルールバインディングによって指令される。このステートメントに対する例外は、全てのルールに関連付けることのできるビジネスカレンダーのような条件である。というのは、ビジネスカレンダーの定義は、「グローバル」であり、特定のバインディングポイントに結び付けられないからである。各条件は、論理的ＯＲ及び論理的ＡＮＤ演算子を使用して任意に合成し及びネスト状にすることのできる１つ以上の表現で構成される。一実施形態において、条件は、全て、トップレベルにおいてＡＮＤされる。ルールに含まれる全ての条件は、真と評価されるべきルールについては、「真」と評価される必要がある。新たな条件タイプをランタイムにルールフレームワークに追加できるのと同様に、新たなアクションタイプをランタイムに登録することもできる。一実施形態では、警告フレームワークは、新たなアクション及び条件の追加を許すＳＰＩを定義することができる。
【０１５０】
ルールトリガーは、ルールを評価するプロセスをキックオフする役割を果たす。上述するように、ルール評価プロセスは、多数の異なるメカニズムによりトリガーすることができる。一実施形態では、説明上、これらのメカニズムは、更新されたモニタリングメトリックの利用性；事象契約、即ちルールエバルエーターが事象フレームワークと契約しそして事象が生じたときにルール評価をトリガーできるもの；及びタイマーベースのルール、即ちスケジューリングサービスが、ルールエバルエーターが契約するタイマー事象を発生し、そして固定のインターバルでルール評価をキックオフできるもの、を含むことができる。
【０１５１】
一実施形態において、ルールの評価は、ルールに含まれた条件の各々を評価し、そして全ての条件が真と評価される場合に、含まれたアクションを呼び出すことを含む。説明上、ルールエバルエーターは、ルールに含まれた各条件を経て進行し、そして各条件タイプに関連した対応するエバルエーターを呼び出して、条件を評価する。更に別の実施形態では、各条件タイプは、そのタイプの条件を評価できるエバルエーターを登録する。条件エバルエーターを登録することは、警告フレームワークによりパブリッシュされるＪａｖａ（登録商標）インターフェイスを実施することを含む。
【０１５２】
一実施形態において、ルールフレームワークは、サービスプロバイダーインターフェイス（ＳＰＩ）を与え、これを経て付加的な条件及びアクションタイプを登録することができる。一実施形態では、各アクション及び条件タイプは、個別のウェブアプリケーションとして実施される。アプリケーションが展開されるときには、リスナークラスがこれらの条件及びアクションタイプを登録する。
【０１５３】
一実施形態において、ルールバインディングは、ルールに関連付けできる位置を識別する。各サービス（外部及びプロキシーの両方）は、ルールを展開できるところの１つ以上のバインディングポイントを定義することができる。バインディングポイントは、そのサービスプロキシーにおける全てのパイプライン、ステージ及びトランスポートにより登録されるモニタリングメトリックを捕獲することができる。ルールは、このバインディングポイントに結合することができ、そしてこのバインディングポイントに得られるモニタリングメトリックを使用して条件を構成することができる。一実施形態において、コンフィギュレーションマネージャーに登録されたリスナーは、サービスプロキシーが生成／更新／削除されるたびに通知される。このリスナーは、サービスにおけるバインディングポイントを抽出して、それらを警告バインディングマネージャーに登録することができる。
【０１５４】
一実施形態において、ルールバインディングポイントを含む各「エンティティ」（サービス又はプロセス）は、そのエンティティが「存在」状態となったときにこれらバインディングポイントを警告マネージャーに登録することができる。サービスバスのサービスについては、これは、サービスが生成されるときにバインディングポイントが登録されることを意味する。ＢＰＭプロセスについては、この登録は、プロセスが展開されるときに生じる。一実施形態において、バインディングポイントのこのレポジトリーは、持続することができ、そしてコンソール及び他のツールが使用できるＪＭＸインターフェイスを経てブラウジングするのを使用できる。
【０１５５】
一実施形態において、警告マネージャーは、サービス／プロセス名を取り上げるＡＰＩと、新たなモニタリングメトリックを含むルールコンテクストとを与えることができる。次いで、警告マネージャーは、そのサービス又はプロセスに対して登録された全てのバインディングポイントをルックアップし、そして各バインディングポイントに結合された全てのルールを評価することができる。
【０１５６】
一実施形態において、コンフィギュレーション時間にポピュレートされる全ての情報に加えて、ルールコンテクストは、ルールバインディングによって発生される全てのランタイムデータを含むことができる。条件及びアクションエバルエーターは、このランタイムデータを抽出し、そしてそれに対応する値を、発生される警告に埋め込むことができる。以下のテーブルは、ルールコンテクストに使用可能なフィールドをリストしたものである。
【０１５７】
テーブル１：一実施形態によるランタイムルールデータ
【０１５８】
一実施形態において、ルールフレームワークは、ルールを構成するためにＪＭＸ ＡＰＩのセットを露出させることができる。これらのＡＰＩは、ルールを管理するために、挿入、検索、検証及び持続機能を与えることができる。これは、第三者ツールがＪＭＸレイヤーと直接対話して、ルールを管理すると共に、ＷＬＩ９．０アドミニストレーションコンソールを完全にバイパスするのを許すことができる。
【０１５９】
多数のルールを単一のバインディングポイントに関連付けることができる。ルールは、それらが配備された順序で実行することができる。ユーザは、いつでもこの順序を変更することができる。一実施形態において、ルールを生成することは、ルールをバインディングポイントに関連付けることを含む。例えば、これを行う２つの仕方は、次の通りである。
【０１６０】
１．バインディングポイントのブラウジング：アドミニストレータは、先ず、バインディングレポジトリーから全てのバインディングポイントをブラウズし、その１つを選択し、そしてそのバインディングポイントに関連したルールを生成する。
２．エンティティのブラウジング：この場合には、アドミニストレータは、先ず、ルールを関連付けしたいエンティティ（サービスバスのサービスディレクトリー又はＢＰＭプロセスビューア）を識別することによりスタートする。次いで、ユーザは、サービス／プロセスに利用できるルールバインディングポイントのリストが与えられ、そしてそれらバインディングポイントの１つを選択して、そのバインディングポイントに関連したルールを生成する。
【０１６１】
一実施形態において、各ルール条件及びアクションタイプは、アクション又は条件コンフィギュレーションデータを表わすためにそれ自身のスキーマを定義することができる。この条件又はアクションコンフィギュレーションは、シリアル化されたＸＭＬとして警告マネージャーへ返送され、そして警告マネージャーは、このデータをルール定義の一部分として持続させることができる。条件又はアクションを構成するときに各条件及びアクションタイプにルールコンテクストが通される。これは、条件コンフィギュレーションメカニズムが検証を実行して、そのバインディングポイントで使用可能なモニタリングデータエレメントが条件コンフィギュレーションに含まれるよう確保するのを許す。
【０１６２】
一実施形態において、特定のバインディングポイントへと展開されたルールは、その特定のバインディングポイントで使用可能なモニタリングデータエレメントを含むことができる。ＷＬＩコンソールを使用してルールを管理するユーザについては、この検証をコンソールにより自動的に実行することができる。このコンソールは、その関連バインディングで使用可能なデータエレメントを用いて、ルールに含まれた条件及びアクションを構成することを容易に保証できる。
【０１６３】
一実施形態において、モニタリングマネージャーは、モニタリングデータに対してクラスター巾のメトリックを集計し、そして更新されたモニタリングメトリックを使用可能とする各サービス／プロセスに対して各バインディングポイントに関連付けされたルールの評価をトリガーする。警告マネージャーは、最初に、特定のバインディングポイントに対するルールコンテクストを構成することができる。次いで、そのバインディングポイントへ展開される全てのルールをフェッチすることができると共に、ルールが構成された順序でその各々を評価することができる。ルールコンテクストが各条件及びアクションエバルエーターへ通される。ルールエバルエーターにおける全ての条件が真である場合には、そのルールに含まれたアクションが実行される。ルールランタイム状態オブジェクトは、各条件及びアクションをファイアーした結果を追跡する。この情報は、ユーザに既に通知された既存の条件に対して警告が繰り返しファイアーされないよう確保するために使用される。
【０１６４】
一実施形態において、ルールランタイム状態オブジェクトは、各アクション及び条件にも通される。このオブジェクトは、評価されるルールごとに追跡レコードを発生するのに使用できるレコードデータを配置するために各条件及びアクションに対してプレースホルダーを定義することもできる。いずれかのデータセットに含ませることのできる追跡データエレメントとして警告ログエントリーが発生される。追跡レコードは、コンソールに表示することができる。一実施形態において、ルーティングノードは、メッセージ処理グラフに対する要求／応答通信を与える。これは、メッセージを選択されたサービスへディスパッチし、そしてもし適用できれば、応答を待機するのに使用される。一実施形態において、ルーティングは、サービスプロキシーの一次メッセージ経路の一部分と考えられるので、受信された応答は、応答処理における応答メッセージとして使用することができる。一実施形態において、ルーティングノードは、ルートのセットを含む。ルートは、ターゲットサービス（例えば、サービスプロキシー又は外部プロキシー）を識別し、そしてメッセージをいかにパッケージしてそのサービスへ送信するか決定するある付加的なコンフィギュレーションオプションを含む。アウトバウンド変換は、メッセージ及びコンテクストを、ターゲットサービスへの送信の前に変更するのを許す変換アクションのセットである。応答変換も、同様に、受信した応答に適用される変換アクションのセットである。これら実施形態の態様において、ルート選択は、ｉｆ−ｔｈｅｎ−ｅｌｓｅブロック及びルーティングテーブルの組み合せにより条件付きで行われる。
【０１６５】
ルートを構成するときには、スキップと称される特殊なルートを指定するためのオプションも存在する。これは、単に、何も行わないルート、実際には、非ルートである。スキップは、これを選択すると、その後続ルートが考慮又は選択されるのを防止できるという点で、ルートと同様に振舞う。しかしながら、スキップルートでは、メッセージを送信できず、又、応答も期待できない。スキップルートは、更なるコンフィギュレーションをもたない。スキップの目的は、ユーザがルーティングを希望しないケースを明確に定義するオプションをユーザに許すことである。
【０１６６】
一実施形態において、アウトバウンド変換は、ターゲットサービスへ送信できるメッセージの形状をカスタマイズするのに使用される。これは、潜在的に、メッセージそれ自体（例えば、ペイロード、ＳＯＡＰヘッダー）、並びにトランスポート特有の細部、例えば、トランスポートヘッダー、再試みカウント、代替ＵＲＩ、等を変更することを含む。これは、変換ステージに現在露出される変換アクションの標準セットを使用して行うことができる。指定、更新及び削除に加えて、アウトバウンド及び応答変換は、条件、ＷＳ−コールアウトを使用し、そしてエラーを生じさせることもできる。一実施形態において、応答変換は、応答メッセージの形状を、それが応答経路処理のためにパイプラインへと折り返される前に、カスタマイズするのに使用される。ここでは、アウトバウンド及び応答変換は、サービスプロキシーにより使用される要求／応答フォーマットと、ターゲットサービスにより使用される要求／応答フォーマットとの間で効果的に変換を行うように一緒に使用できるものとする。又、応答変換は、ＳＯＡＰ又はビジネス欠陥のようなメッセージレベル欠陥をチェックするのにも使用できる。メッセージ欠陥が検出された場合には、通常の変換ステージと同様に、エラー状態を発生することができる。
【０１６７】
一実施形態において、条件付きルーティングを実行するために、ｉｆ−ｔｈｅｎ−ｅｌｓｅブロックにおいてルートをラップすることができる。条件は、ブール値ＸＱｕｅｒｙ表現でよく、そしてブロックは、任意にネスト状にすることができる。更に別の実施形態では、最終的なアクションがルート又はルーティングテーブルである。一実施形態において、ルーティングテーブルは、スイッチスタイルの条件テーブルでラップされたルートのセットを含む。これは、単一のＸＱｕｅｒｙ表現の結果に基づいて異なるルートを選択するのを許す省略構成である。
【０１６８】
一実施形態において、ルーティングテーブルは、単一のｗｈｅｒｅ条項と、１つ以上のケースのセットとで構成される。ｗｈｅｒｅ条項は、ＸＱｕｅｒｙ表現を含み、そしてメッセージコンテクストの任意の部分を参照することができる。各ケースは、比較演算子と、値表現と、ケースアクションとして働く少なくとも１つのルートとで構成される。全ルーティングノードは、１つのルートの選択を生じるので、ケース当たり多数のルートがサポートされるのではない。先行するケースが満足され名場合には、ルートが選択される端において、デフォールトケースを追加することができる。
【０１６９】
ルーティングテーブルの一例を以下に示すが、これは、必ずしも、コンフィギュレーションコンソールにおいてテーブルをいかに提示できるかを表わすものではない。又、明瞭化のために、ルートの詳細も省略する。
ｗｈｅｒｅ：データ（＄ｍｅｓｓａｇｅ／順序−量）
比較器 値 ルート
＞＝ 100000 ゴールドサービスルート
＞＝ 10000 シルバーサービスルート
その他 標準サービスルート
【０１７０】
ルーティングテーブルは、等号に加えて多数の異なる比較演算子をサポートする。更に、ルーティングテーブルにおける値表現は、ＸＱｕｅｒｙ表現であり、単純な定数値である必要はない。これら実施形態の態様において、ルーティングテーブルは、ｗｈｅｒｅ条項においてＸＱｕｅｒｙ表現を最初に評価することにより評価される。各ケースは、次いで、ｗｈｅｒｅ条項の結果をケースの値表現の結果と比較するために選択された比較演算子を使用することによりリストされた順序で検査される。比較が満足である場合には、それに対応するルート（１つ又は複数）を選択することができる。
【０１７１】
一実施形態において、メッセージディスパッチは、ルーティングノードのランタイムの一部分として実行される。基本的な実行フローは、最初に、条件及びルートテーブルを評価して、ルートが選択されたかどうか調べることである。ルートが選択されていない場合には、ルーティングノードが完全と考えられ、そして応答処理がメッセージコンテクストの現在状態で直ちに開始する。ルートが選択された場合には、それに対応するアウトバウンド変換が、次いで、コンテクストに適用される。次いで、メッセージは、バインディング及びトランスポートレイヤーを経てサービスへ送信される。応答メッセージが期待されない場合には、ルーティングノードが終了と考えられ、そして応答処理が開始される。さもなければ、ルーティングノードは、応答が到達するまで依然アクティブと考えられる。これが生じると、応答変換が適用され、そしてルーティングノードは、終了したと考えられる。一実施形態において、バッチ更新特徴は、サービスバスコンポーネントへの変化を「セッション」において生じさせ、そこに累積して一緒に適用できるようにするのを許す。説明上、ユーザ（コンソールを経て）又はプロセスは、特殊な「バッチセッション」を生成し、そこで、変化が累積されるようにする。バッチセッションでなされた変化は、「コア状態」にセーブされず、むしろ、セッションにセーブされる。これら変化は、それを「コミット」する前に再検討することができる。一実施形態において、変化を直ちにコミットすることができなくてもよい。例えば、コミットは、そのように行うことが許されず、従って、無効な「コア状態」を生じさせる（例えば、それがサイクルを生成し、未分析の参照を生じさせ、等々の場合）。バッチセッションをコミットできると仮定すれば、これら変化が累積されて、コア状態へ反映される。
【０１７２】
一実施形態において、バッチセッションは、どんなコンポーネントがセッションデータにおいて削除され、生成され又は更新されるか追跡する。このデータは、サービスバスの再スタート及びクラッシュに生き残るように存続される。コア状態は、サーバーバスが実行されるメインコンフィギュレーションである。セッション内でなされる変化は、セッションがコミットされるときにコア状態に反映される。コア状態は、最終的に、サービスバスの振舞いを定義する。セッションビューは、セッション中に誰かにより観察されるコンフィギュレーションの状態である。セッションビューは、物理的なデータエントリーではない。これは、コア状態を取り上げてセッションデータを適用することで導出される。バッチ更新は、セッションにおいてサービスバスコンフィギュレーションを変更し、次いで、これら更新をコミットするというアクティビティである。
【０１７３】
一実施形態において、バッチセッション（又は単にセッション）は、サービスバスにおけるバッチ更新サポートの中心的断片である。セッションは、ユーザ及び／又はプロセスにより生成される。いかなる数のセッションが同時に生成されてもよい。各セッションは、そのセッションで実行される変更により決定されたシステムの異なるビューをもつことができる。セッションデータは、永続的であり、クラッシュ又は再スタートに生き残ることができる。セッションは、どんなコンポーネントがユーザにより更新され、生成され及び削除されるか追跡する。これは、セッションデータと称される。セッションデータは、コア状態と共に、セッションビューを定義し、例えば、そのセッションにおいてどんなコンポーネントが見えるか、及びそれらがどんな値を含むか定義する。
【０１７４】
一実施形態において、ＳｅｓｓｉｏｎＭＢｅａｎを経てセッションマネージャーにおけるメソッドを呼び出すことによりセッションが生成される。セッションは、ＳｅｓｓｉｏｎＭＢｅａｎを使用してプロセスにより生成することもできるし、又はコンソールにおいて生成することもできる。コンフィギュレーション変化（更新、削除、生成）は、セッション内で実行することができる。コンフィギュレーションを更新するサービスバスＭＢｅａｎメソッドは、セッション名、例えば、
public void createService (String session, Ref serviceref, ServiceDef definition);
を受け容れるように変更することができる。
【０１７５】
ＭＢｅａｎを使用する外部クライアントは、セッション名を供給するだけでよく、そしてそのメソッドにより実行される更新は、そのセッションに累積することができる。クライアントが多数の更新を全て異なるセッションにおいて実行することが考えられる。以下の例では、Ｊａｖａコードは、セッション１においてサービスを更新し、そしてセッション２においてサービスプロバイダーを削除する。これら２つのセッションは、どんなコンフィギュレーションに似ているかの異なるアイデアをもつことができる。セッション１は、サービスプロバイダーが依然存在すると考えることができ、そしてセッション２は、サービスが古いコンフィギュレーションを有すると考えることができる。
servicembean.updateService (“session1”, service1, newServiceData);
serviceprovidermbean.deleteProvider (“session2”, serviceprovider2);
【０１７６】
一実施形態において、コンソールユーザは、新たなセッションを生成するとき、又は既存のセッションを取り上げて機能させるときに、セッションに入る。同じユーザが異なるセッション間を切り換えることもできるし、異なるユーザが異なるセッションにおいて同時に機能することもできる。セッションにより見たコンフィギュレーションのビューは、他のもの及びコア状態のビューとは異なる。ユーザがサービスＡを生成し、サービスＢを削除し、そしてその後に、サービスのリストを要求する場合には、Ａがリストにあるが、Ｂはないことが分からねばならない。しかしながら、実際のコンフィギュレーション（コア状態）は、Ａをもつことができないが、Ｂは、セッションがコミットされるまでもつことができる。一実施形態において、ＭＢｅａｎ読み取りメソッド（例えば、ゲッター、リストメソッド、サーチメソッド）は、任意のセッションパラメータを受け容れることができる。セッションパラメータがナルである場合には、データをコア状態から得ることができる。セッションパラメータがナルでない場合には、セッションにより見たコンフィギュレーションのビューが返送される。例えば、コア状態がサービスＢ及びＣを含むと仮定する。更に、ユーザがセッションＳ１を生成し、そしてサービスＡを生成し、次いで、このセッションにおいてサービスＢを削除するが、これらの変化をまだコミットしないと仮定する。ｌｉｓｔＳｅｒｖｉｃｅ（ストリングセッション）メソッドは、次のセッションに基づいて異なる結果を返送することができる。
listServices (null) returns B and C
listServices (“S1”) returns A and C
【０１７７】
コンソールユーザは、いずれのセッションにもない場合にコア状態を見る。ユーザは、その変化で満足されると、その変化をコミットし、検証を受けることができる。コミット動作は、ユーザがセッションにおいて行った変化をコア状態に適用する。セッションがコミットされると、もはや使用できないので、削除される。又、ユーザは、セッションを破棄することもできる。これは、単に、セッションデータ状態を削除し、コア状態には影響を及ぼさない。ユーザは、ユーザが現在いるセッションを、コミットしたり破棄したりせずに、立ち去ることができる。このようにすることで、ユーザは、コア状態を見ることが許されるか、又は別のセッションへスイッチすることができる。
【０１７８】
図１１ａ−ｂは、一実施形態に基づき種々の変更がセッション及びコアにおいて実行された後のコア状態、セッションデータ、及びセッションビューである。異なる幾何学的形状を使用して、コンポーネントにより取り上げられた異なる値をハイライトすることができる。セッションビューにおいて太い線をもつ形状は、そのコンポーネントがセッションにより変更されており、従って、その存在及び値がコア状態における同じコンポーネントとは異なることを指示する。セッションビューにおいて通常の線をもつ形状は、そのコンポーネントがセッションにおいて変更されておらず、従って、その存在及び値がコア状態から得られることを指示する。
【０１７９】
図１１ａは、コンポーネントＡ、Ｂ及びＣを含む初期コア状態を示す。セッションにおいて更新はなされておらず、従って、セッションビューは、コア状態に何が含まれるか厳密に反映する。図１１ｂは、セッションデータの更新を示している。コンポーネントＢは、セッションにおいて更新されている。この事実は、セッションデータに記録され、そしてセッションデータは、次いで、セッションビューを計算するために、コア状態と一緒に使用される。
【０１８０】
図１２ａ−ｃは、一実施形態による付加的なセッションシナリオを示す。図１２ａにおいて、コンポーネントＤがセッション中に生成される。Ｄは、セッションビューでは見えるが、コア状態では見えないことに注意されたい。図１２ｂにおいて、コンポーネントＡがセッション中に削除され、それ故、セッションビューは、コンポーネントＡをもはや含まない。しかしながら、セッション中にないユーザは、コア状態を見、そしてコンポーネントＡがコア状態に存在することを観察する。最終的に、図１２ｃは、２つの変更がコア状態において行われ（おそらく別のセッションをコミットすることにより）、即ちコンポーネントＢが削除されそしてＣが更新された後のコア状態及びセッションビューを示す。これら２つの変化は、セッションビューにおいて、それら自体、異なる仕方で現われる。Ｃへの更新は、セッションビューに見ることができる。というのは、Ｃは、セッションにより変更されないからである。しかしながら、Ｂの削除は、セッションにおいて見ることができない。というのは、Ｂは、セッションにより変更され、従って、その値は、セッションデータから直接得られるからである。このケースは、セッションのデータ／ビューとコア状態との間の「競合」の例である。このようなシナリオは、同じアイテムが２つのセッションにより互換性なく変更される場合に生じる。セッションの一方が破棄されない限り、第２のセッションをコミットしたときに競合を解消することができる。
【０１８１】
一実施形態において、セッションデータは、本質的に、そのセッションにおいて変更（生成、更新又は削除）された全てのコンポーネントに対するレコード（情報）のリストである。そのセッションにおいてたとえ何回変更されても（例えば、生成され、削除され、次いで、再び生成されても）、このような各コンポーネントに対して厳密に１つのレコードしかない。このレコードは、コンポーネントがセッションにより初めて更新されるときに生成される。同じコンポーネントに対して更なる変更が実行されるときにそれが更新される。そのコンポーネントに対してセッションにより実行された全ての更新がアンドゥされた場合にレコードが除去される。セッションデータは、ファイルシステムにおいて存続される。又、セッションデータは、セッションが生成されたときのコンフィギュレーションデータのスナップショットではない（サーバーは、スナップショットに基づくセッションデータを使用する）ことに注意されたい。
【０１８２】
一実施形態において、以下は、生成、更新及び削除オペレーションに対するロジックを与える。
１）セッションＳにおいてＡを生成する：
ａ）Ａがセッションにおいて削除された場合には、ＣＲＥＡＴＥ（Ａに対する既存のセッションデータを更新する）
ｂ）その他、Ａがセッションデータに存在する場合は、ＥＲＲＯＲ（再生成できない）
ｃ）その他、Ａがコア状態に存在する場合は、ＥＲＲＯＲ（再生成できない）
ｄ）さもなければ、ＣＲＥＡＴＥ（セッションデータにおいてＡに対する新たなレコードを生成する）
【０１８３】
２）セッションＳにおいてＡを更新する：
ａ）Ａがセッションにおいて削除された場合には、ＥＲＲＯＲ（Ａがセッションに存在しない）
ｂ）その他、Ａがセッションデータに存在する場合には、ＵＰＤＡＴＥ（Ａに対する既存のセッションデータを更新する）
ｃ）その他、Ａがコアに存在する場合には、ＵＰＤＡＴＥ（セッションデータにおいてＡに対する新たなレコードを生成する）
ｄ）その他、ＥＲＲＯＲ（Ａは、コア状態に存在しない）
【０１８４】
３）セッションＳにおいてＡを削除する：
ａ）Ａがセッションにおいて削除された場合には、ＥＲＲＯＲ（Ａがセッションに存在しない）
ｂ）その他、Ａがセッションデータに存在する場合は、適切な参照完全性チェックの後にＤＥＬＥＴＥ
ｃ）その他、Ａがコア状態に存在する場合には、適切な参照完全性チェックの後にＤＥＬＥＴＥ
ｄ）その他、ＥＲＲＯＲ（コア状態に存在しない）
【０１８５】
一実施形態において、読み取りオペレーションは、ユーザがセッションビュー（コア状態ではなく）を見ているという錯覚を与える。それらは、セッションデータ及びコア状態を使用することによりこれを行う。次のロジックは、一実施形態における読み取り（取得）オペレーションの実施を記述する。
１）セッションＳにおいてＡを読み取る：
ａ）セッションにおいてＡが削除された場合に、ナルを返送する
ｂ）その他、セッションにＡが存在する場合に、その値をこのセッションにおいて返送する
ｃ）その他、コア状態にＡが存在する場合に、その値をコア状態において返送する
ｄ）その他、ナルを返送する
【０１８６】
一実施形態において、バッチセッションは、ユーザが、そのセッションにおいて行ったオペレーションを、時間的に厳密に逆の順序で、アンドゥするのを許す。
【０１８７】
一実施形態において、セッションがコミットされるときに、システムは、コア状態に変化を適宜に反映させることができる。コミットは、本質的に、セッションにより変更される種々のコンポーネントに対して一連の更新、削除又は生成を生じさせる。一実施形態において、セッションのコミットは、原子的である。換言すれば、それが中間に入る場合、又はサービスバスがクラッシュする場合には、それまでになされた変化をロールバックすることができる。
【０１８８】
一実施形態において、コミットが矛盾したコア状態を生じない場合にはセッションをコミットすることができる。一実施形態において、次のいずれか１つが真である場合には、コミットが許されない。
【０１８９】
１）セッションのコンポーネントにより参照される幾つかのコンポーネントがコア状態において削除される。これが図１３ａに示されている。コンポーネントが生成され、そして既にコア状態にあるコンポーネントＢを参照する。Ｂがコア状態から削除される。コア状態は有効であるが、セッションは、ＡからＢへの無効参照を含む。
【０１９０】
２）コア状態への変更がセッションビューにあるサイクルの参照を発生することがある。これが図１３ｂに示されている。このようなセッションをコミットすると、コア状態へサイクルを導入することになり、従って、コミットが許されない。それ以降の図において、最初にＡを更新して、それがＢを参照するようにすることにより、サイクルが導入される。次いで、Ｂが、コア状態において、Ａを参照するように変更される。コア状態を見ている者は、ＢからＡへの参照を見ることができるが、セッション中のユーザは、Ａを参照するＢ及びＢを参照するＡの両方を見ることができる。
【０１９１】
３）図１３ｃは、削除できるコンポーネントによる参照完全性違反を示す。コンポーネントがセッションにおいて削除されると、セッションマネージャーは、そのコンポーネントへの参照がないことを確保するためのチェックを行う。削除の後、コンポーネントは、セッションビューにもはや存在しない。しかしながら、セッションがまだコミットされないので、このコンポーネントは、セッションの外部のユーザに見える。コア状態におけるコンポーネントは、セッションにより削除されたコンポーネントを指すように変更されることが考えられる。このようなシナリオは、コミットを行うと、無効の参照となるので、コミットを行えないことを意味する。
【０１９２】
４）セッション及びコア状態における競合する変更。同じコンポーネントがセッションにおいて変更されると共に、コア状態においても変更される（別のセッションのコミットにより）ことがあり得る。例えば、セッションは、コンポーネントを削除してもよく、一方、同じコンポーネントが新たな値で更新されてもよい。このような競合する更新は、ユーザにより明確に解決することができる。この問題は、本書において以下で詳細に探求する。
【０１９３】
５）進行中のサーバー変化リストの競合。セッションにおいて実行されるあるオペレーションは、サーバーへの変更を生じさせる。例えば、サービスを生成すると、通常、サーブレット又はＭｄａｔａｂａｓｅｓが配備される。しかしながら、これらの変化は、サーバーロックを要求すると共に、変化リストにおいて提示されることを必要とする（サーバーは、それらのセッション変化リストをコールする）。不都合なことに、サーバーは、多数の変化リストを許さない。進行中のサーバー変化リストが既にあれば、サービスバスは、それ自身の変化をサーバーへコミットすることができない。
【０１９４】
テーブル２は、競合シナリオと、一実施形態によりシステムがこのような競合をいかに自動的に解決できるかとを示す。又、このテーブルは、セッション及びコア状態の両方において全く同じ変更がなされるために競合を招くことがない３つの同時変更シナリオも示すことに注意されたい。このテーブルは、４つの列を有する。第１の列は、変更される前のコンポーネントの最初の値を表わす。この列のナル値は、コンポーネントが最初に存在しなかったことを示す。第２及び第３の列は、各々、コア状態及びセッションにおけるコンポーネントの値を表わす。これらの列のナル値は、コンポーネントが削除されたこと（又は全く生成されないこと）を示す。第４の列は、競合を説明すると共に、競合をいかに解消できるかについて述べる。一実施形態において、テーブル２を参照すれば、システムにより競合を解決できる仕方は３つあって、「アクセプトセッション(ACCEPT SESSION)」、「アクセプトコア(ACCEPT CORE)」、及び更新競合の場合には、「マージ(MERGE)」である。
【０１９５】
テーブル２：一実施形態による競合解決
注：1 これをいつも行うことができるかどうかは分からない。
2 このケースでは、コンポーネントは、セッションにおいても生成されるが、次いで、削除される。
【０１９６】
一実施形態において、更新プランは、サーバーによりどんなアクションを実行すべきか記述するオブジェクトである。各サーバーに存在する変化マネージャーは、更新プランに記述されたアクションを実行する役割を果たす。アドミニサーバーにおいて実行される更新プランは、マネージされるサーバーにおいて実行されるものとは異なってもよい。
【０１９７】
このセクションは、更新をいかに実行するかの非常に高レベルの概要を与える。これは、更新及び回復の完全な叙述を意味するものではない。
【０１９８】
一実施形態において、更新は、次のケースにおいて開始される。
−ユーザ更新：ユーザは、バッチ更新をコミットする。アドミニサーバー及びマネージされるサーバーにおいて更新プランが発生されて実行される。これらの更新は、通常、アドミニサーバー及びマネージされるサーバーにおいて行われる。
−マネージされるサーバーの回復：マネージされるサーバーは、アドミニサーバーからの長期切断の後に、そのコンフィギュレーションデータが古くなっていることが分かる。従って、アドミニサーバーから更新プランを要求し、これは、マネージされるサーバーにおいて実行することができると共に、マネージされるサーバーのコンフィギュレーションを最新の状態にもっていくことができる。更新は、本質的に、「デルタ」である。
【０１９９】
ユーザ更新のケースでは、更新プランが最初にアドミニサーバーにおいて実行され、そしてこれが首尾良くいった場合に、マネージされるサーバーへ同時に（且つ非同期で）送信されて、そこで実行される。マネージされるサーバーの回復のケースでは、マネージされるサーバーは、最初に、それが知っている全てのリソースのダイジェスト及びそれらのバージョンナンバーを送信する。次いで、アドミニサーバーは、これをそれ自身のデータと比較し、そして何らかの食い違いがある場合に、マネージされるサーバーにおいて実行できる更新プランを作成する。
【０２００】
一実施形態において、更新プランは、サービスバスに対して特別に構成された良く知られたＪＭＳトピックを使用して、マネージされるサーバーへ送信される。各サーバー（アドミニを含む）は、プランを受け取って、それを実行し、そしてその結果をアドミニサーバーへ報告する役割を果たす変化マネージャーコンポーネントを有する。各サーバーは、それが受け取った更新プランを実行する役割を果たす。アプリケーション欠陥（例えば、サーバークラッシュではなく例外）のためにプランの実行がフェイルした場合には、サーバーは、更新プランにより実行された全ての変化を、更新プランを実行する前に存在したコンフィギュレーションの状態へロールバックする役割を果たす。換言すれば、サーバーにおけるプランの実行は、原子的である。これは、成功か又は失敗のいずれかである。いずれにせよ、その結果がアドミニサーバーへ報告される。
【０２０１】
更新が、あるサーバーでは成功したが、他のサーバーでは失敗することが考えられる。これが生じると、成功であるサーバーの更新をロールバックし又はアンドゥすることができる。サーバーは、更新の実行中にクラッシュすることがある。これが生じると、スタートアップ中に回復を実行しなければならない。一実施形態において、説明上、回復は、次のステップを含む。
【０２０２】
１）実行されたがコミットされていないローカルワークをロールバックする。サーバークラッシュが生じたので、持続データ（ファイル）を回復して、その前映像へロールバックする必要がある。
２）更に、マネージされるサーバーにある場合には、
ａ）コンフィギュレーションの現在内容のダイジェストをアドミニサーバーへ送信し、そしてデルタを受け取る。
ｂ）これらのデルタをローカルに適用して、マネージされるサーバーのコンフィギュレーションをアドミニサーバーと共に最新の状態へもっていく。
【０２０３】
一実施形態において、更新プランは、サービスバスコンフィギュレーションへ適用する必要のある変化を記述する。更新プランは、アドミニサーバー及びマネージされるサーバーにおいて実行され、そして個々の変化を記述する「タスク」のリストを含む。一実施形態において、５つの形式のタスクがある：コンポーネント生成タスク；コンポーネント更新タスク；コンポーネント削除タスク；フォルダー又はプロジェクト生成タスク；及びフォルダー又はプロジェクト削除タスク。一般に、更新プランは、最初に、フォルダー又はプロジェクト生成タスクを実行した後に、多数のコンポーネントタスクを実行し、そしてフォルダー及びプロジェクト削除タスクで終了となる。
【０２０４】
一実施形態において、更新プランにおける各タスクは、次の機能を発揮する。
−検証：システムにおいて変更を行わずに影響されるデータを検証する。
−実行：検証されると、単にコンフィギュレーション変化を実行する。即ち、スタフ(stuff)を生成し、更新しそして削除する。
【０２０５】
図１４は、一実施形態による更新プラン実行を示す図である。この図は、更新プラン１４０２がいかに実行されそしてどんなモジュール／サブシステムが与えられるか示す。又、この図は、更新に参加できる３つの主たるプレーヤ、即ちあるものを専門に扱うコンフィギュレーションフレームワークにおける種々のマネージャー（１４００、１４０４、１４０６、１４０８）；更新プラン、タスク等のデータ構造体；及び種々のステートフルなエンティティ（１４１０、１４１４、１４１６、１４１８）を示し、これらは、ある状態を保持する種々の断片である。これらは、ランタイムキャッシュ、持続データ、及びシステム内の他のモジュール（例えば、コンパイルされたＸＱｕｅｒｙプランのキャッシュを保持するＸＱｕｅｒｙマネージャー）により保持される他のデータである。
【０２０６】
一実施形態において、変化マネージャー１４００が更新プラン１４０２を取得してそれを実行するときに更新が開始される。この実施形態の態様において、更新プランは、単に、順次に実行することのできるタスク１４１２のリストである。これらのタスクは、コンポーネント１４２０、フォルダー又はプロジェクト１４１８を更新／生成／削除／再命名するためにプロジェクトマネージャー１４０４又はコンポーネントマネージャー１４０６のメソッドを呼び出す。プロジェクトマネージャー及びコンポーネントマネージャーは、次いで、ランタイムキャッシュ１４１４、参照グラフ、及びファイル１４１６のような当該ステートフルエンティティを更新する。更に別の実施形態では、ファイル更新は、ファイルマネージャーにより取り扱われる。
【０２０７】
一実施形態において、コンポーネント（例えば、サービスマネージャー）１４１０への更新を聴取する種々のモジュールがある。これらモジュールは、特定のコンポーネントタイプに発生する変化を登録し、そしてそのコンポーネントタイプのインスタンスが生成され、削除され、更新され又は再命名されるときに通知がなされる。リスナーは、通常、これらの通知に応答して、それ自身の内部状態を更新する。例えば、トランスポートマネージャーは、サービスの定義に対してなされる変化に基づいてトランスポートエンドポイントを展開／非展開／保留／再開する。これらのリスナーは、エラーが生じたときにロールバックすることのできる状態を保持する。
【０２０８】
一実施形態において、適切な回復を容易に行うために、変化マネージャーは、プランの実行に関する次の事実を持続的に記録することができる。
１）プランの実行の始めに、実行がスタートしたことを指示するレコードをディスクに書き込む。「ＳＴＡＲＴＥＤ」のような簡単なストリング値で充分である。
２）首尾良い実行の後に、実行が首尾良く終了したことを指示するレコードをディスクに書き込む。「ＳＵＣＣＥＳＳ」のような簡単なストリング値で充分である。
３）アプリケーションの失敗の後に、実行が失敗しそして回復が進行中であることを指示するレコードをディスクに書き込む。「ＦＡＩＬＥＤ」のような簡単なストリング値で充分である。
【０２０９】
一実施形態において、アプリケーションの失敗又はサーバークラッシュの後に回復が開始される。第１のケースでは、アプリケーションの失敗の後に更新がストップされ、そして回復が直ちにスタートされる。第２のケースでは、クラッシュの後にサーバーが再スタートするときに回復が実行される。ロールバックは、オペレーション（のグループ）の作用をアンドゥすることを意味する。これに対して、回復は、多数のロールバックを伴うことのあるより一般的なアクティビティ、及び潜在的に多数の他の種類のアクティビティ、例えば、分散型環境における異なるエンティティ間のデータの交換、又は潜在的なリドゥオペレーションを意味する。それでも、これら２つの語は、交換可能に使用できる。
【０２１０】
あるオペレーションＯＰがデータ（例えば、状態）の断片の値をＶ1からＶ2へ変化させると仮定する。このオペレーションは、次の２つの仕方でロールバックすることができる。１）値ベースの解決策（物理的ロールバック）：Ｖ１をこのオペレーションに対する前映像としてセーブし、次いで、ロールバック時にその値へ戻す；及び２）演算的解決策（論理的ロールバック）：オペレーションＯＰの逆数（ＯＰRと称する）を現在値Ｖ2に適用して、Ｖ1を得る。一実施形態において、両解決策は、どのステートフルなエンティティがロールバックされるかに基づいて使用することができる。例えば、前映像（値ベースの解決策）をファイル更新に使用するのが有意義である。これは、クラッシュ回復が、影響のある全てのファイルをそれらの前映像に単に置き換えるのを許す。他方、通知に応答して種々のマネージャーにより実行される状態変化をロールバックするために、演算的解決策を使用する。
【０２１１】
図１５ａは、一実施形態による首尾良い更新を示す。一般に、サーバーは、アプリケーション例外後のロールバック中にクラッシュするか、又はサーバーは、サーバースタート後の回復中にクラッシュすることが考えられる。埋められた円は、そこでシステムがクラッシュし得ることを示す。
【０２１２】
図１５ｂにおいて、実行がアプリケーション例外のためにフェイルし、そして一実施形態では、直ちに回復がスタートする。プランの実行をロールバックすることは、主として、演算的ロールバック解決策に依存する。
【０２１３】
一実施形態において、プランが実行されるときには、そのタスクの各々をあるシーケンスで単に実行する。タスクが実行される前に、そのタスクに対してアンドゥタスクが生成される。このアンドゥタスクは、基本的に、タスクの作用をロールバックするのに使用できる逆のオペレーションである。これら実施形態の態様において、これらのアンドゥタスクは、メモリに累積される。タスクが失敗すると、プランの実行がストップし、そして累積されたアンドゥタスクが逆の順序で実行される。例えば、プランが３つのタスク、即ち更新ポリシーＰ、生成サービスＳ、並びに削除ＸＱｕｅｒｙＸ及びＸＱｕｅｒｙ失敗の削除を有すると仮定する。次のリストは、何が実行されるかを列挙する。
【０２１４】
１）更新ポリシーＰに対してアンドゥタスクを得る。これをアンドゥタスク１と称する。
２）「更新ポリシーＰ」を実行する。これが成功となる。
３）生成サービスＳに対してアンドゥタスクを得る。これをアンドゥタスク２と称する。
４）「生成サービスＳ」を実行する。これが成功となる。
５）削除ＸＱｕｅｒｙＸに対するアンドゥタスクを得る。これをアンドゥタスク３と称する。
６）「削除ＸＱｕｅｒｙＸ」を実行する。これが失敗となる。
７）ロールバックがスタートする。
８）アンドゥタスク３が実行される。
９）アンドゥタスク２が実行される。
１０）アンドゥタスク１が実行される。
【０２１５】
一実施形態において、生成及び削除に対するアンドゥタスクは、削除及び生成タスクである。更新タスクについては、アンドゥタスクが、コンポーネントをその最初の値で更新する別の更新タスクとなる。同様に、再命名タスクについては、アンドゥタスクが、コンポーネントをその最初の名前に再命名して戻す別の再命名タスクである。又、タスクフレームワークは、プログラマーがアンドゥタスクをカスタマイズするのも許す。
【０２１６】
一実施形態において、タスクの実行が進められるときに、ファイルの更新は、ドゥ／アンドゥスタイルでは行われない。タスクが実行され、そしてロールバックのケースでは、そのアンドゥタスクが実行される。ファイルと共に、ファイル更新が先ず「準備」され、そして全プラン実行の終りに、プラン実行が成功であったかどうかに基づいて更新が「コミット」されるか又は「ロールバック」される。例えば、コンフィギュレーションファイルＦ１及びＦ２は、コンポーネントＣ１及びＣ２に対するあるコンフィギュレーション変化の結果として、更新／生成／削除されると仮定する。次のことが生じる。
【０２１７】
１）コンポーネントＣ１が変化される。これは、ファイルＦ１を当該データで準備させる。
２）コンポーネントＣ２が変化される。これは、ファイルＦ２を当該データで準備させる。
３）全プラン実行が成功した場合（例えば、コミット）、最終的なステップとして、次のことを行う。
ａ）ファイルＦ１へ更新をコミットする。
ｂ）ファイルＦ２へ更新をコミットする。
４）さもなければ、ロールバックの一部分として、次のことを行う。
ａ）Ｆ１へ更新をロールバックする。
ｂ）Ｆ２へ更新をロールバックする。
【０２１８】
次のテーブルは、一実施形態においてファイルの生成、更新及び削除をどのように進めるか示す。準備、コミット及びロールバックと命名された列は、これらの段階中に何が生じるか示す。（これらアクションは、フォルダーの生成、又は削除にも適用される。）
【０２１９】
テーブル３：一実施形態によるファイルオペレーション
【０２２０】
ファイルに対するコミット及びロールバックオペレーションは、ＳＵＣＣＥＳＳ又はＦＡＩＬＥＤレコードがＬＡＳＴ＿ＴＲＡＮＳＡＣＴＩＯＮ＿ＩＮＦＯファイルまで持続された後に実行される。これは、通常の実行又はロールバック実行中にサーバークラッシュの後に回復を許す設計上の判断である（これは、次のセクションの詳細を検討したときに読者に分かるかもしれないし分からないかもしれない）。
【０２２１】
図１５ｃは、サーバークラッシュによる実行失敗と、サーバー再スタート後に回復がスタートするところを示す。サーバークラッシュ後に、存続データ（例えば、ファイル）への変化を回復する必要がある。一実施形態において、これは、システムにより次のように行うことができる。
【０２２２】
１）ＬＡＳＴ＿ＴＲＡＮＳＡＣＴＩＯＮ＿ＩＮＦＯファイルを使用して、最後の更新が成功したか否か決定する。
２）最後の更新が失敗となるか又は進行中である場合に（ＬＡＳＴ＿ＴＲＡＮＳＡＣＴＩＯＮ＿ＩＮＦＯがＦＡＩＬＥＤ又はＳＴＡＲＴを含む）、先のセクションで要約を述べたようにファイル更新をロールバックする必要がある。基本的に、「Ｘ．ｎｅｗ」という名前のファイルをサーチしそしてそれらを削除し、次いで、「Ｘ．ｏｌｄ」という名前の全てのファイルを「Ｘ」へ再命名する。
【０２２３】
３）最後の更新が成功であった場合に、依然、ある作業を行う必要がある。「ＳＵＣＣＥＳＳ」レコードを書き込んだ後、依然、ファイル更新をコミットしている間に、更新が失敗となることが考えられる。従って、「Ｘ．ｏｌｄ」という名前のファイルを単にサーチして削除し、次いで、「Ｘ．ｎｅｗ」という名前の全てのファイルを「Ｘ」へ再命名する。これは、「リドゥ」オペレーションと同様の種類である。
４）全てのファイルが回復されると、ＬＡＳＴ＿ＴＲＡＮＳＡＣＴＩＯＮ＿ＩＮＦＯファイルを単に除去する（又はある空きストリングをそこに入れる）。
【０２２４】
このメカニズムは、たとえサーバーが回復中に何回もクラッシュしても、システムがファイルを回復するのを許す。
一実施形態において、マネージされるサーバーの回復は、次のように取り扱われる。
１）スタートアップ中に、マネージされるサーバーは、先のセクションで述べたように、ローカル回復を実行する。
２）次いで、アドミニサーバーにコンタクトし、それが知っているコンフィギュレーションデータに関するダイジェスト情報を送信する。このダイジェストは、それが知っている全てのコンポーネントのｉｄと、それらのバージョンナンバーとを含む。
３）アドミニサーバーは、このダイジェストを、それが有するコンフィギュレーションと比較し、そしてマネージされるサーバーが失うか、古くなるか、又は単に有してはならないのはどんなコンポーネントか決定する。次いで、アドミニサーバーは、そのマネージされるサーバーのみに対するプランであって、実行時に、マネージされるサーバーを、アドミニサーバーにおけるメインコンフィギュレーションに関して最新の状態へともっていくことのできるプランを準備しそして更新する。
【０２２５】
一実施形態において、説明上、ゆるく連合されたシステムにおいてオペレーションを実行するときには、２段階のコミット（２ＰＣ）が要求される。
１）各参加者（リソースマネージャー）は、オペレーションを準備するが、まだコミットしない。準備が成功すると、ＯＫメッセージを２ＰＣコーディネーターへ送信する。
２）２ＰＣコーディネーターが全ての参加者からＯＫを得ると、コミット信号を送信する。さもなければ、キャンセル（ロールバック）信号を送信する。
３）各参加者は、準備された変化をコミットすべきかロールバックすべきかについてコーディネーターからの判断を得る。
【０２２６】
図面は、コンポーネントを論理的に個別のものとして示すが、これは、単なる例示に過ぎない。この図に示すコンポーネントは、個別のソフトウェア、ファームウェア及び／又はハードウェアコンポーネントへと結合したり分割したりできることが当業者に明らかであろう。更に、このようなコンポーネントは、それらをいかに結合し又は分割するかに関わらず、同じコンピューティング装置において実行することもできるし、或いは１つ以上のネットワーク又は他の適当な通信手段により接続された異なるコンピューティング装置間に分散できることも、当業者に明らかであろう。
【０２２７】
種々の実施形態は、コンピュータ分野の当業者に明らかなように、本開示の教示に基づいてプログラムされた従来の汎用又は特殊なデジタルコンピュータ（１つ又は複数）及び／又はプロセッサ（１つ又は複数）を使用して実施することができる。ソフトウェア分野の当業者に明らかなように、熟練したプログラマーであれば、本開示の教示に基づいて適切なソフトウェアコードを容易に準備することができよう。又、本発明は、当業者に容易に明らかなように、集積回路を準備するか、及び／又は従来のコンポーネント回路の適切なネットワークを相互接続することにより、実施することもできる。
【０２２８】
種々の実施形態は、命令が記憶された記憶媒体（メディア）であるか、ここに示す特徴のいずれかを実行するように汎用又は特殊なコンピューティングプロセッサ／装置（１つ又は複数）をプログラムするのに使用できるコンピュータプログラム製品を包含する。記憶媒体は、フロッピー（登録商標）ディスク、光学的ディスク、ＤＶＤ、ＣＤ−ＲＯＭ、マイクロドライブ、磁気−光学ディスク、ホログラフ記憶装置、ＲＯＭ、ＲＡＭ、ＰＲＡＭ、ＥＰＲＯＭ、ＥＥＰＲＯＭ、ＤＲＡＭ、ＶＲＡＭ、フラッシュメモリデバイス、磁気又は光学カード、ナノシステム（分子メモリ、ＩＣを含む）を含む任意の形式の物理的メディア；ペーパー又はペーパーベースのメディア；及び命令及び／又は情報を記憶するための任意の形式のメディア又はデバイスを包含し得るが、これらに限定されない。種々の実施形態は、１つ以上のパブリック及び／又はプライベートネットワークを経て全体的又は部分的に送信できるコンピュータプログラム製品を包含し、この送信は、ここに示す特徴のいずれかを実行するように１つ以上のプロセッサにより使用できる命令を含むものである。種々の実施形態において、この送信は、複数の個別の送信を含んでもよい。
【０２２９】
コンピュータ読み取り可能な媒体（メディア）の１つ以上に記憶されるが、本開示は、汎用／特殊なコンピュータ（１つ又は複数）及び／又はプロセッサ（１つ又は複数）のハードウェアを制御すると共に、これらコンピュータ及び／又はプロセッサが本発明の結果を利用して人間のユーザ又は他のメカニズムと対話できるようにするためのソフトウェアも包含する。このようなソフトウェアは、装置ドライバ、オペレーティングシステム、実行環境／コンテナ、ユーザインターフェイス及びアプリケーションを含むが、これらに限定されない。
【０２３０】
以上、本発明の好ましい実施形態を詳細に説明したが、これは、単なる例示に過ぎない。これは、本発明を余すところなく示すものでもないし、又、ここに開示した正確な形態に制限するものでもない。当業者であれば、多数の変更や修正が明らかであろう。これら実施形態は、本発明の原理及びその実際の応用を最良に説明するために選ばれたものであり、当業者であれば、本発明を理解することができよう。従って、本発明の範囲は、特許請求の範囲によって限定されるものとする。
【図面の簡単な説明】
【０２３１】
【図１ａ】一実施形態のシステムを示す図である。
【図１ｂ】一実施形態によるサービスバスアーキテクチャーを示す図である。
【図２】一実施形態によるメトリック集計及びコンフィギュレーション伝播を示す図である。
【図３】一実施形態によるメッセージ処理パイプラインを示す図である。
【図４】一実施形態による前及び後パイプラインメッセージ処理を示す図である。
【図５】一実施形態によるコンポーネントアーキテクチャーを示す図である。
【図６ａ】単一パイプライン対ノード及び単一ルートノードを有するメッセージ処理グラフである。
【図６ｂ】一実施形態によるブランチノードを伴うメッセージ処理グラフである。
【図７】一実施形態によるエラー取り扱い範囲を示す図である。
【図８】一実施形態のサービスプロバイダーを示す図である。
【図９】一実施形態によるモニタリングコンポーネントを示す図である。
【図１０】一実施形態によるルールトリガーメカニズムを示す図である。
【図１１ａ】一実施形態によるコンポーネントＡ、Ｂ及びＣを含む初期コア状態を示す図である。
【図１１ｂ】一実施形態によるセッションデータの更新を示す図である。
【図１２ａ】一実施形態による付加的なセッションシナリオを示す図である。
【図１２ｂ】一実施形態による付加的なセッションシナリオを示す図である。
【図１２ｃ】一実施形態による付加的なセッションシナリオを示す図である。
【図１３ａ】セッションビューとコア状態との間の非一貫性を示す図である。
【図１３ｂ】セッションビューとコア状態との間の非一貫性を示す図である。
【図１３ｃ】セッションビューとコア状態との間の非一貫性を示す図である。
【図１４】一実施形態による更新プラン実行を示す図である。
【図１５ａ】一実施形態による更新成功を示す図である。
【図１５ｂ】アプリケーションの例外による更新失敗を示す図である。
【図１５ｃ】サーバークラッシュによる更新失敗を示す図である。
【特許請求の範囲】
【請求項１】
サービスプロキシーのためのメッセージを処理する方法において、
メッセージをメッセージ処理グラフにおいて第１経路に沿って第１方向に搬送するステップであって、前記第１経路が少なくとも１つのメッセージ処理ノードを含むようなステップと、
前記少なくとも１つのメッセージ処理ノードの各１つに、前記メッセージを処理する機会を与えるステップであって、前記少なくとも１つのメッセージ処理ノードの１つは、前記メッセージの少なくとも一部分に基づいてセキュリティ機能を遂行するようなステップと、
を備え、前記少なくとも１つのメッセージ処理ノードが、前記サービスプロキシーに適合するインターフェイス及び／又はプロトコルを実施するようにした方法。
【請求項２】
前記セキュリティ機能は、暗号化、暗号解読、デジタルサイン、デジタルシグネチャー検証、認証、ポリシーの評価、及びアクセス権の決定、の少なくとも１つを行うことができる、請求項１に記載の方法。
【請求項３】
プロセスへメッセージを通信する方法において、
第２のインターフェイスを露出させるステップであって、前記第２のインターフェイスは、第１のインターフェイスに対する見掛けであるようなステップと、
前記第２のインターフェイスを経てメッセージを受け容れるステップと、
前記プロセスを選択するステップと、
前記第１のインターフェイスを経て前記プロセスへメッセージを与えるステップと、
を備え、前記第１のインターフェイスへの変化が前記第２のインターフェイスへの変化を要求しないようにした方法。
【請求項４】
インターフェイスは、メッセージフォーマット、トランスポートプロトコル、アドレス、サービス定義及びセキュリティ機構、の少なくとも１つを含む請求項３に記載の方法。
【請求項５】
サービスプロキシーのためのメッセージを処理する方法において、
メッセージをメッセージ処理グラフにおいて第１経路に沿って搬送するステップであって、前記第１経路が少なくとも１つのメッセージ処理ノードを含むようなステップと、
行先へのルートを選択するステップであって、前記行先が、別のサービスプロキシー及びサービスの１つであるようなステップと、
前記メッセージを前記行先へ通信するステップと、
を備えた方法。
【請求項６】
前記選択は、前記メッセージのコンテンツに基づく、請求項５に記載の方法。
【請求項７】
前記少なくとも１つのメッセージ処理ノードにおけるメッセージ処理ノードは、前記少なくとも１つのメッセージ処理ノードにおける１つ以上の他のメッセージ処理ノードを指すことができる、請求項５に記載の方法。
【請求項８】
複数のサービスプロキシーをモニタリングする方法において、
サービスプロキシー、サービスプロキシーコンポーネント、及びサービスプロキシーをモニタリングできるプロセス、の少なくとも１つからデータを収集するステップと、
ある時間にわたってデータを集計するステップと、
ルールの評価をトリガーするステップと、
を備えた方法。
【請求項９】
前記集計するステップは、あまり最近収集したものでないデータよりも、より最近収集したデータを保持することを含む、請求項８に記載の方法。
【請求項１０】
前記トリガーするステップは、指定の粒度における集計データの変化に基づいて行う、請求項８に記載の方法。
【請求項１１】
前記トリガーするステップは、事象の発生に基づいて行う、請求項８に記載の方法。
【請求項１２】
サービスプロキシーのためのメッセージを処理する方法において、
メッセージをメッセージ処理グラフにおいて第１経路に沿って搬送するステップであって、前記第１経路が少なくとも１つのメッセージ処理ノードを含むようなステップと、
少なくとも１人の受信者へメッセージをパブリッシュするステップと、
メッセージを行先へ通信するステップであって、前記行先が別のサービスプロキシー及びサービスの１つであるようなステップと、
を備えた方法。
【請求項１３】
前記メッセージのコンテンツに基づいて前記少なくとも１人の受信者を選択するステップを更に備えた、請求項１２に記載の方法。
【請求項１４】
サービスプロキシーをモニタリングする方法において、
サービスプロキシー、サービスプロキシーコンポーネント、及びサービスプロキシーをモニタリングできるプロセス、の１つによりルール評価をトリガーするステップと、
ルールを評価するところのコンテクストを発生するステップと、
前記トリガー動作に応答し、前記コンテクストに基づいて前記ルールを評価するステップと、
前記評価に応答してアクションを実行するステップと、
を備えた方法。
【請求項１５】
ルールは、真又は偽と評価される１つ以上の表現を含み、そして表現は、ネスト状の表現を含むことができる、請求項１４に記載の方法。
【請求項１６】
前記コンテクストは、少なくとも１つの値を含み、該少なくとも１つの値は、前記評価に使用される、請求項１４に記載の方法。
【請求項１７】
サービスプロキシーは、サービス及び別のサービスプロキシーの１つと、クライアントとの間の中間物である、請求項１４に記載の方法。
【請求項１８】
サービスプロキシーでメッセージを処理する方法において、
メッセージをメッセージ処理ノードのネットワークにおいて第１経路に沿って第１方向に搬送するステップであって、前記第１経路がメッセージ処理ノードの少なくとも１つを含むようなステップと、
前記第１経路の各ノードに、メッセージを処理する機会を与えるステップと、
前記メッセージにより識別されたリソース及び／又はサービスに関連する証明書を取得するステップと、
を備え、メッセージ処理ノードが、前記サービスプロキシーに適合し得るインターフェイス及び／又はプロトコルを実施するようにした方法。
【請求項１９】
サービス及びサービスプロキシーの１つに前記メッセージを与えるステップを更に備えた、請求項１８に記載の方法。
【請求項２０】
第１インターフェイスを有するアプリケーションを動的に再目的化する方法において、
第２のインターフェイスを露出させるステップであって、前記第２のインターフェイスは、第１のインターフェイスに対する見掛けであるようなステップと、
前記第２インターフェイスから要求を受け容れるステップと、
前記要求を前記第１インターフェイスへ与えるステップと、
を備え、前記第１インターフェイスへの変化が前記第２インターフェイスへの変化を要求しないようにした方法。
【請求項２１】
インターフェイスは、メッセージフォーマット、トランスポートプロトコル、アドレス、サービス定義、及びセキュリティ機構、の少なくとも１つを含む請求項２０に記載の方法。
【請求項２２】
前記第２インターフェイスはウェブサービスインターフェイスである、請求項２０に記載の方法。
【請求項２３】
前記与えるステップは、前記要求を前記第１インターフェイスへ動的にマップすることを含む、請求項２０に記載の方法。
【請求項２４】
前記与えるステップは、前記メッセージフォーマットを前記第１インターフェイスに適合し得るフォーマットに変換し、前記第１インターフェイスに適合し得るトランスポートプロトコルを使用するか、前記第１インターフェイスに適合し得るセキュリティ機構を使用して、前記アプリケーションに前記要求を送信することの少なくとも１つを実行することを含む、請求項２０に記載の方法。
【請求項２５】
第１インターフェイスを有するアプリケーションを経て情報にアクセスするための方法において、
第２のインターフェイスを露出させるステップであって、前記第２のインターフェイスは、第１のインターフェイスに対する見掛けであるようなステップと、
前記第２インターフェイスから要求を受け容れるステップと、
前記第１インターフェイスへ要求を与えるステップと、
前記第１インターフェイスから情報を得るステップと、
前記第２インターフェイスへ情報を与えるステップと、
を備え、前記第１インターフェイスへの変化が前記第２インターフェイスへの変化を要求しないようにした方法。
【請求項２６】
インターフェイスは、メッセージフォーマット、トランスポートプロトコル、アドレス、サービス定義、及びセキュリティ機構、の少なくとも１つを含む請求項２５に記載の方法。
【請求項２７】
前記第２インターフェイスはウェブサービスインターフェイスである、請求項２５に記載の方法。
【請求項２８】
前記要求を前記第１インターフェイスに与える前記ステップは、前記要求フォーマットを前記第１インターフェイスに適合し得るフォーマットに変換し、前記第１インターフェイスに適合し得るトランスポートプロトコルを使用するか、前記第１インターフェイスに適合し得るセキュリティ機構を使用して、前記アプリケーションに前記要求を送信することの少なくとも１つを実行することを含む、請求項２５に記載の方法。
【請求項２９】
サービスプロキシーのためのメッセージを処理する方法において、
メッセージをメッセージ処理グラフにおいて第１経路に沿って第１方向に搬送するステップであって、前記第１経路が少なくとも１つのメッセージ処理ノードを含むようなステップと、
前記少なくとも１つのメッセージ処理ノードの各１つがメッセージを処理するのを許すステップと、
を備え、前記少なくとも１つのメッセージ処理ノードが、前記サービスプロキシーに適合し得るインターフェイス及び／又はプロトコルを実施するようにした方法。
【請求項３０】
前記第１経路は、メッセージコンテンツに基づいて動的に決定される請求項２９に記載の方法。
【請求項３１】
前記少なくとも１つのメッセージ処理ノードにおけるメッセージ処理ノードは、前記メッセージ処理グラフに動的に追加できるか又はそこから除去できる、請求項２９に記載の方法。
【請求項３２】
前記少なくとも１つのメッセージ処理ノードにおけるメッセージ処理ノードは、メッセージ認証、メッセージ許可、メッセージ検証、メッセージ変換、メッセージルーティング、性能モニタリング、メッセージ追跡、メッセージアーカイブ、メッセージロギング、メッセージパブリケーション、エラーレポート、及びユーザが定義したプロセス、の少なくとも１つを実行することができる、請求項２９に記載の方法。
【請求項１】
サービスプロキシーのためのメッセージを処理する方法において、
メッセージをメッセージ処理グラフにおいて第１経路に沿って第１方向に搬送するステップであって、前記第１経路が少なくとも１つのメッセージ処理ノードを含むようなステップと、
前記少なくとも１つのメッセージ処理ノードの各１つに、前記メッセージを処理する機会を与えるステップであって、前記少なくとも１つのメッセージ処理ノードの１つは、前記メッセージの少なくとも一部分に基づいてセキュリティ機能を遂行するようなステップと、
を備え、前記少なくとも１つのメッセージ処理ノードが、前記サービスプロキシーに適合するインターフェイス及び／又はプロトコルを実施するようにした方法。
【請求項２】
前記セキュリティ機能は、暗号化、暗号解読、デジタルサイン、デジタルシグネチャー検証、認証、ポリシーの評価、及びアクセス権の決定、の少なくとも１つを行うことができる、請求項１に記載の方法。
【請求項３】
プロセスへメッセージを通信する方法において、
第２のインターフェイスを露出させるステップであって、前記第２のインターフェイスは、第１のインターフェイスに対する見掛けであるようなステップと、
前記第２のインターフェイスを経てメッセージを受け容れるステップと、
前記プロセスを選択するステップと、
前記第１のインターフェイスを経て前記プロセスへメッセージを与えるステップと、
を備え、前記第１のインターフェイスへの変化が前記第２のインターフェイスへの変化を要求しないようにした方法。
【請求項４】
インターフェイスは、メッセージフォーマット、トランスポートプロトコル、アドレス、サービス定義及びセキュリティ機構、の少なくとも１つを含む請求項３に記載の方法。
【請求項５】
サービスプロキシーのためのメッセージを処理する方法において、
メッセージをメッセージ処理グラフにおいて第１経路に沿って搬送するステップであって、前記第１経路が少なくとも１つのメッセージ処理ノードを含むようなステップと、
行先へのルートを選択するステップであって、前記行先が、別のサービスプロキシー及びサービスの１つであるようなステップと、
前記メッセージを前記行先へ通信するステップと、
を備えた方法。
【請求項６】
前記選択は、前記メッセージのコンテンツに基づく、請求項５に記載の方法。
【請求項７】
前記少なくとも１つのメッセージ処理ノードにおけるメッセージ処理ノードは、前記少なくとも１つのメッセージ処理ノードにおける１つ以上の他のメッセージ処理ノードを指すことができる、請求項５に記載の方法。
【請求項８】
複数のサービスプロキシーをモニタリングする方法において、
サービスプロキシー、サービスプロキシーコンポーネント、及びサービスプロキシーをモニタリングできるプロセス、の少なくとも１つからデータを収集するステップと、
ある時間にわたってデータを集計するステップと、
ルールの評価をトリガーするステップと、
を備えた方法。
【請求項９】
前記集計するステップは、あまり最近収集したものでないデータよりも、より最近収集したデータを保持することを含む、請求項８に記載の方法。
【請求項１０】
前記トリガーするステップは、指定の粒度における集計データの変化に基づいて行う、請求項８に記載の方法。
【請求項１１】
前記トリガーするステップは、事象の発生に基づいて行う、請求項８に記載の方法。
【請求項１２】
サービスプロキシーのためのメッセージを処理する方法において、
メッセージをメッセージ処理グラフにおいて第１経路に沿って搬送するステップであって、前記第１経路が少なくとも１つのメッセージ処理ノードを含むようなステップと、
少なくとも１人の受信者へメッセージをパブリッシュするステップと、
メッセージを行先へ通信するステップであって、前記行先が別のサービスプロキシー及びサービスの１つであるようなステップと、
を備えた方法。
【請求項１３】
前記メッセージのコンテンツに基づいて前記少なくとも１人の受信者を選択するステップを更に備えた、請求項１２に記載の方法。
【請求項１４】
サービスプロキシーをモニタリングする方法において、
サービスプロキシー、サービスプロキシーコンポーネント、及びサービスプロキシーをモニタリングできるプロセス、の１つによりルール評価をトリガーするステップと、
ルールを評価するところのコンテクストを発生するステップと、
前記トリガー動作に応答し、前記コンテクストに基づいて前記ルールを評価するステップと、
前記評価に応答してアクションを実行するステップと、
を備えた方法。
【請求項１５】
ルールは、真又は偽と評価される１つ以上の表現を含み、そして表現は、ネスト状の表現を含むことができる、請求項１４に記載の方法。
【請求項１６】
前記コンテクストは、少なくとも１つの値を含み、該少なくとも１つの値は、前記評価に使用される、請求項１４に記載の方法。
【請求項１７】
サービスプロキシーは、サービス及び別のサービスプロキシーの１つと、クライアントとの間の中間物である、請求項１４に記載の方法。
【請求項１８】
サービスプロキシーでメッセージを処理する方法において、
メッセージをメッセージ処理ノードのネットワークにおいて第１経路に沿って第１方向に搬送するステップであって、前記第１経路がメッセージ処理ノードの少なくとも１つを含むようなステップと、
前記第１経路の各ノードに、メッセージを処理する機会を与えるステップと、
前記メッセージにより識別されたリソース及び／又はサービスに関連する証明書を取得するステップと、
を備え、メッセージ処理ノードが、前記サービスプロキシーに適合し得るインターフェイス及び／又はプロトコルを実施するようにした方法。
【請求項１９】
サービス及びサービスプロキシーの１つに前記メッセージを与えるステップを更に備えた、請求項１８に記載の方法。
【請求項２０】
第１インターフェイスを有するアプリケーションを動的に再目的化する方法において、
第２のインターフェイスを露出させるステップであって、前記第２のインターフェイスは、第１のインターフェイスに対する見掛けであるようなステップと、
前記第２インターフェイスから要求を受け容れるステップと、
前記要求を前記第１インターフェイスへ与えるステップと、
を備え、前記第１インターフェイスへの変化が前記第２インターフェイスへの変化を要求しないようにした方法。
【請求項２１】
インターフェイスは、メッセージフォーマット、トランスポートプロトコル、アドレス、サービス定義、及びセキュリティ機構、の少なくとも１つを含む請求項２０に記載の方法。
【請求項２２】
前記第２インターフェイスはウェブサービスインターフェイスである、請求項２０に記載の方法。
【請求項２３】
前記与えるステップは、前記要求を前記第１インターフェイスへ動的にマップすることを含む、請求項２０に記載の方法。
【請求項２４】
前記与えるステップは、前記メッセージフォーマットを前記第１インターフェイスに適合し得るフォーマットに変換し、前記第１インターフェイスに適合し得るトランスポートプロトコルを使用するか、前記第１インターフェイスに適合し得るセキュリティ機構を使用して、前記アプリケーションに前記要求を送信することの少なくとも１つを実行することを含む、請求項２０に記載の方法。
【請求項２５】
第１インターフェイスを有するアプリケーションを経て情報にアクセスするための方法において、
第２のインターフェイスを露出させるステップであって、前記第２のインターフェイスは、第１のインターフェイスに対する見掛けであるようなステップと、
前記第２インターフェイスから要求を受け容れるステップと、
前記第１インターフェイスへ要求を与えるステップと、
前記第１インターフェイスから情報を得るステップと、
前記第２インターフェイスへ情報を与えるステップと、
を備え、前記第１インターフェイスへの変化が前記第２インターフェイスへの変化を要求しないようにした方法。
【請求項２６】
インターフェイスは、メッセージフォーマット、トランスポートプロトコル、アドレス、サービス定義、及びセキュリティ機構、の少なくとも１つを含む請求項２５に記載の方法。
【請求項２７】
前記第２インターフェイスはウェブサービスインターフェイスである、請求項２５に記載の方法。
【請求項２８】
前記要求を前記第１インターフェイスに与える前記ステップは、前記要求フォーマットを前記第１インターフェイスに適合し得るフォーマットに変換し、前記第１インターフェイスに適合し得るトランスポートプロトコルを使用するか、前記第１インターフェイスに適合し得るセキュリティ機構を使用して、前記アプリケーションに前記要求を送信することの少なくとも１つを実行することを含む、請求項２５に記載の方法。
【請求項２９】
サービスプロキシーのためのメッセージを処理する方法において、
メッセージをメッセージ処理グラフにおいて第１経路に沿って第１方向に搬送するステップであって、前記第１経路が少なくとも１つのメッセージ処理ノードを含むようなステップと、
前記少なくとも１つのメッセージ処理ノードの各１つがメッセージを処理するのを許すステップと、
を備え、前記少なくとも１つのメッセージ処理ノードが、前記サービスプロキシーに適合し得るインターフェイス及び／又はプロトコルを実施するようにした方法。
【請求項３０】
前記第１経路は、メッセージコンテンツに基づいて動的に決定される請求項２９に記載の方法。
【請求項３１】
前記少なくとも１つのメッセージ処理ノードにおけるメッセージ処理ノードは、前記メッセージ処理グラフに動的に追加できるか又はそこから除去できる、請求項２９に記載の方法。
【請求項３２】
前記少なくとも１つのメッセージ処理ノードにおけるメッセージ処理ノードは、メッセージ認証、メッセージ許可、メッセージ検証、メッセージ変換、メッセージルーティング、性能モニタリング、メッセージ追跡、メッセージアーカイブ、メッセージロギング、メッセージパブリケーション、エラーレポート、及びユーザが定義したプロセス、の少なくとも１つを実行することができる、請求項２９に記載の方法。
【図１ａ】
【図１ｂ】
【図２】
【図３】
【図４】
【図５】
【図６ａ】
【図６ｂ】
【図７】
【図８】
【図９】
【図１０】
【図１１ａ】
【図１１ｂ】
【図１２ａ】
【図１２ｂ】
【図１２ｃ】
【図１３ａ】
【図１３ｂ】
【図１３ｃ】
【図１４】
【図１５ａ】
【図１５ｂ】
【図１５ｃ】
【図１ｂ】
【図２】
【図３】
【図４】
【図５】
【図６ａ】
【図６ｂ】
【図７】
【図８】
【図９】
【図１０】
【図１１ａ】
【図１１ｂ】
【図１２ａ】
【図１２ｂ】
【図１２ｃ】
【図１３ａ】
【図１３ｂ】
【図１３ｃ】
【図１４】
【図１５ａ】
【図１５ｂ】
【図１５ｃ】
【公表番号】特表２００７−５１５７０６（Ｐ２００７−５１５７０６Ａ）
【公表日】平成１９年６月１４日（２００７．６．１４）
【国際特許分類】
【出願番号】特願２００６−５４００５５（Ｐ２００６−５４００５５）
【出願日】平成１７年５月２３日（２００５．５．２３）
【国際出願番号】ＰＣＴ／ＵＳ２００５／０１８１８３
【国際公開番号】ＷＯ２００５／１１４４５２
【国際公開日】平成１７年１２月１日（２００５．１２．１）
【出願人】（５００１０５１６０）ビーイーエイ システムズ， インコーポレイテッド (17)
【氏名又は名称原語表記】ＢＥＡ Ｓｙｓｔｅｍｓ， Ｉｎｃ．
【住所又は居所原語表記】２３１５ Ｎｏｒｔｈ Ｆｉｒｓｔ Ｓｔｒｅｅｔ， Ｓａｎ Ｊｏｓｅ， ＣＡＬＩＦＯＲＮＩＡ ９５１３１ Ｕ．Ｓ．Ａ．
【Ｆターム（参考）】
【公表日】平成１９年６月１４日（２００７．６．１４）
【国際特許分類】
【出願日】平成１７年５月２３日（２００５．５．２３）
【国際出願番号】ＰＣＴ／ＵＳ２００５／０１８１８３
【国際公開番号】ＷＯ２００５／１１４４５２
【国際公開日】平成１７年１２月１日（２００５．１２．１）
【出願人】（５００１０５１６０）ビーイーエイ システムズ， インコーポレイテッド (17)
【氏名又は名称原語表記】ＢＥＡ Ｓｙｓｔｅｍｓ， Ｉｎｃ．
【住所又は居所原語表記】２３１５ Ｎｏｒｔｈ Ｆｉｒｓｔ Ｓｔｒｅｅｔ， Ｓａｎ Ｊｏｓｅ， ＣＡＬＩＦＯＲＮＩＡ ９５１３１ Ｕ．Ｓ．Ａ．
【Ｆターム（参考）】
[ Back to top ]