(57)【要約】【課題】  １つまたは複数のホストの間および１つまたは複数のデバイス間でのデータ収集と処理を可能にする。【解決手段】  本発明は、システムから少なくとも１つのメッセージを蓄積し（accumulate）、少なくとも１つのメッセージが必要とする処理を決定し、少なくとも１つのディレクタと少なくとも１つの関連付けられたビルダを使用して少なくとも１つのメッセージを処理するための少なくとも１つの一般アクションハンドラを構築し、少なくとも１つのアクションハンドラを実行して所望のアクションを行う管理装置を対象とする。【選択図】図４
2004164610.tif 000002
【特許請求の範囲】
【請求項１】
バス（２０２、３０２）と、１つまたは複数のホスト（２０４、３０４）と、マネージャ（２０１、３０１）と、前記バス（２０２、３０２）に接続された１つまたは複数のデバイス（２１０、３１０）とを有するシステム（２００、３００）で使用されるコンピュータにより読み取り可能な１つまたは複数の媒体上のメッセージ応答処理コード構成であって、該コード構成は、前記マネージャ（２０１、３０１）の１つまたは複数のプロセッサにより実行されて前記１つまたは複数のホスト（２０４）と前記１つまたは複数のデバイス（２１０）の間でのデータ収集と処理を可能にし、
前記システム（２００、３００）からの少なくとも１つのメッセージ（５０２）を蓄積し、該少なくとも１つのメッセージ（５０２）が必要とする処理を決定し、少なくとも１つのディレクタ（４０４５）と少なくとも１つの関連付けられたビルダ（４０５０）を使用して前記少なくとも１つのメッセージ（５０２）を処理するための少なくとも１つの一般アクションハンドラ（４０４６）を構築し、該少なくとも１つのアクションハンドラ（４０４６）を実行して所望のアクションを行うハーベスタコード部分（４０４１）
を備えるコード構成。
【請求項２】
前記ハーベスタコード部分（４０４１）は、さらに前記少なくとも１つのディレクタ（４０４５）に問い合わせて任意の適切なアクションハンドラ（４０４６）を決定し、所与のメッセージ（５０２）に対してすべての適切なアクションハンドラ（４０４６）を蓄積し、前記少なくとも１つの関連付けられたビルダ（４０５０）を使用して適切なアクションハンドラ（４０４６）の集合を構築する
請求項１に記載のメッセージ応答処理コード構成。
【請求項３】
前記ハーベスタコード部分（４０４１）は、メッセンジャコード部分（４０４２）から前記少なくとも１つのメッセージ（５０２）を受け取り、
前記ハーベスタコード部分（４０４１）は、前記少なくとも１つのディレクタ（４０４５）に問い合わせて前記少なくとも１つのメッセージ（５０２）が対象かどうかと、前記少なくとも１つのメッセージ（５０２）が前記少なくとも１つのディレクタ（４０４５）の対象かどうかとを判断し、前記少なくとも１つのディレクタ（４０４５）は前記少なくとも１つのビルダ（４０５０）を調べることで前記少なくとも１つのアクションハンドラ（４０４６）を生成し、
前記ハーベスタコード部分（４０４１）は１つのタスクキュー（４０４３）とトランザクションキュー（４０４４）を使用して前記少なくとも１つのアクションハンドラ（４０４６）を実行して前記少なくとも１つのメッセージ（５０２）に対して前記所望のアクションを行う
請求項１または２に記載のメッセージ応答処理コード構成。
【請求項４】
バス（２０２、３０２）と、１つまたは複数のホスト（２０４、３０４）と、該バス（２０２、３０２）に接続された１つまたは複数のデバイス（２１０、３１０）を有するシステム（２００、３００）に動作可能に結合されたプロセッサとを含む管理装置（２０１、３０１）であって、該管理装置（２０１、３０１）は前記１つまたは複数のホスト（２０４、３０４）と前記１つまたは複数のデバイス（２１０、３１０）の間でのデータ収集と処理を可能にし、
前記システム（２００、３００）からの少なくとも１つのメッセージ（５０２）を蓄積し、該少なくとも１つのメッセージ（５０２）が必要とする処理を決定し、少なくとも１つのディレクタ（４０４５）と少なくとも１つの関連付けられたビルダ（４０５０）を使用して前記少なくとも１つのメッセージ（５０２）を処理するための少なくとも１つの一般アクションハンドラ（４０４６）を構築し、該少なくとも１つのアクションハンドラ（４０４６）を実行して所望のアクションを行う少なくとも１つのハーベスタ（４０４１）
を備える管理装置。
【請求項５】
管理装置（２０１、３０１）であって、
前記少なくとも１つのハーベスタ（４０４１）は、さらに前記少なくとも１つのディレクタ（４０４５）に問い合わせて任意の適切なアクションハンドラ（４０４６）を決定し、所与のメッセージ（５０２）に対してすべての適切なアクションハンドラ（４０４６）を蓄積し、前記少なくとも１つの関連付けられたビルダ（４０５０）を使用してアクションハンドラ（４０４６）の適切な集合を構築する
請求項４に記載の管理装置。
【請求項６】
管理装置（２０１、３０１）であって、
前記少なくとも１つのハーベスタ（４０４１）は、メッセンジャ（４０４２）から前記少なくとも１つのメッセージ（５０２）を受け取り、
前記少なくとも１つのハーベスタ（４０４１）は、前記少なくとも１つのディレクタ（４０４５）に問い合わせて前記少なくとも１つのメッセージ（５０２）が対象かどうかと、前記少なくとも１つのメッセージ（５０２）が前記少なくとも１つのディレクタ（４０４５）の対象かどうかを判断し、前記少なくとも１つのディレクタ（４０４５）は前記少なくとも１つのビルダ（４０５０）を調べることで前記少なくとも１つのアクションハンドラ（４０４６）を生成し、
前記少なくとも１つのハーベスタ（４０４１）は１つのタスクキュー（４０４３）とトランザクションキュー（４０４４）を使用して前記少なくとも１つのアクションハンドラ（４０４６）を実行して前記少なくとも１つのメッセージ（５０２）に対して前記所望のアクションを行う
請求項４または５に記載の管理装置。
【請求項７】
メッセージ収集と処理の方法であって、
少なくとも１つのメッセージ（５０２）を蓄積することと、
該少なくとも１つのメッセージ（５０２）が必要とする処理を決定することと、
少なくとも１つのディレクタ（４０４５）と少なくとも１つの関連付けられたビルダ（４０５０）を使用して前記少なくとも１つのメッセージ（５０２）を処理するための少なくとも１つの一般アクションハンドラ（４０４６）を構築することと、
前記少なくとも１つのアクションハンドラ（４０４６）を実行することであって、それにより、所望のアクションを行う、実行することと、
を含む方法。
【請求項８】
前記構築することは、
前記少なくとも１つのディレクタ（４０４５）に問い合わせることであって、それにより、任意の適切なアクションハンドラ（４０４６）を決定することと、
所与のメッセージ（５０２）に対してすべての適切なアクションハンドラ（４０４６）を蓄積することと、
前記少なくとも１つの関連付けられたビルダ（４０５０）を使用することであって、それにより、適切なアクションハンドラ（４０４６）の集合を構築する、使用することと
をさらに含む請求項７に記載の方法。
【請求項９】
前記構築することは、
前記少なくとも１つのディレクタ（４０４５）に問い合わせることであって、それにより、前記少なくとも１つのメッセージ（５０２）が対象かどうかと、前記少なくとも１つのメッセージ（５０２）が前記少なくとも１つのディレクタ（４０４５）の対象かどうかを判断し、前記少なくとも１つのディレクタ（４０４５）は前記少なくとも１つのビルダ（４０５０）を調べることで前記少なくとも１つのアクションハンドラ（４０４６）を生成する、問い合わせることと、
１つのタスクキュー（４０４３）とトランザクションキュー（４０４４）を使用して前記少なくとも１つのアクションハンドラ（４０４６）を実行することであって、前記少なくとも１つのメッセージ（５０２）に対して前記所望のアクションを行う、実行することと
をさらに含む請求項７または８に記載の方法。
【請求項１０】
装置（２０１、３０１）であって、請求項７ないし９に記載のいずれかの方法を行うように動作可能な
装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、１つまたは複数のホストの間および１つまたは複数のデバイス間でのデータ収集と処理を可能にする管理装置に関する。
【背景技術】
【０００２】
ストレージエリアネットワーク（ＳＡＮ）は、統合されたハードウェアとソフトウェアを利用して堅牢で高速のストレージバックボーンを提供する高速、広帯域のサーバ間ネットワークである。
ＳＡＮを使用することで、ＳＡＮのトポロジに応じて、サーバのクラスタが排他的なデータアクセスによりストレージを共有したり、共通のストレージデバイス上でデータを共有することが可能になる。
ＳＡＮネットワークは、たとえば、各顧客と各取引について収集された数テラバイトの情報のストレージが必要な完全にネットワーク化された企業において有用である。
データの高い可用性と高いセキュリティへのニーズが増大する要求に拍車をかけている。
ＳＡＮは、企業全体で共用可能でありながら、簡略化された操作で管理可能な高速で可用性の高いストレージのプールを提供する。
【０００３】
ＳＡＮには、複数のハードディスクドライブ、テープなどの多数のストレージ要素の集まりが含まれている。
既知のＳＡＮのパフォーマンスを保証するために、データおよびパフォーマンスメトリック（metrics、距離関数）が収集される。
これらのメトリックは、発生し得る問題（帯域ボトルネックなど）を予測して、それらの問題が発生する前にそれらの問題を緩和するための手段を講じるために用いられるパフォーマンスの傾向および統計値を求めるために使用される。
【０００４】
従来技術によるＳＡＮやその他のストレージ環境では、ストレージエリアマネージャ（ＳＡＭ）プロセスをＳＡＮ内のサーバで実行することが知られている。
その名前が示すように、ＳＡＭは、その一部の機能としてストレージ環境のコンポーネント間のやりとり、さらにはストレージへの要求を行うアプリケーションプログラム（クライアント）とストレージ環境のコンポーネントとのやりとりを管理する。
【０００５】
従来のＳＡＭは、ストレージ環境のコンポーネントからイベントを受け取り、対処するが、性能が固定された固定サイズで、動作が静的である。
つまり、ＳＡＭがイベントを受け取ると、ＳＡＭは、どの機能モジュールが呼び出されてイベント内の任意の所与のメッセージを処理しなければならないかということ、それらの機能モジュールが使用可能であるのか、または、メッセージが待たなければならないかということを認識する。
【発明の開示】
【発明が解決しようとする課題】
【０００６】
本発明は、上述した背景からなされた物であり、１つまたは複数のホストの間および１つまたは複数のデバイス間でのデータ収集と処理を可能にする管理装置を提供することを目的とする。
【課題を解決するための手段】
【０００７】
一実施形態においては、本発明は、１つまたは複数のホストの間および１つまたは複数のデバイス間でのデータ収集と処理を可能にする管理装置であって、システムから少なくとも１つのメッセージを蓄積し（accumulate）、少なくとも１つのメッセージが必要とする処理を決定し、少なくとも１つのディレクタと少なくとも１つの関連付けられたビルダを使用して少なくとも１つのメッセージを処理するための少なくとも１つの一般アクションハンドラを構築し、少なくとも１つのアクションハンドラを実行して所望のアクションを行う管理装置を対象とする。
【発明の効果】
【０００８】
本発明によれば、１つまたは複数のホストの間および１つまたは複数のデバイス間でのデータ収集と処理とが可能になる。
【発明を実施するための最良の形態】
【０００９】
図１は、本発明の一実施形態によるシステム２００のハードウェアのブロック図を示している。
システム２００には、本発明の一実施形態によるソフトウェアが組み込まれている。
システム２００は、デバイスサービスのコンシューマ（以降デバイスコンシューマと呼ぶ）２０４、デバイス２１０、デバイス２１８、ストレージエリアマネージャ（ＳＡＭ）２０１が接続されたバス（たとえば、ＳＣＳＩ、Ｅｔｈｅｒｎｅｔ（ｉＳＣＳＩ、ＩＰ、Ｇｂｉｔ  Ｅｔｈｅｒｎｅｔ）、ファイバチャネルなど）２０２を備える。
【００１０】
デバイスコンシューマ２０４は、デバイスコンシューマ２０４がバス２０２に接続し、バス２０２とやりとりするのを許可するホストバスアダプタ（ＨＢＡ）２０６、２０８を備える。
デバイス２１０は、ポート１（２１２）、ポート２（２１４）、．．．、ポートＮ（２１６）を有する。
デバイス２１８は、ポート１（２２０）、ポート２（２２２）、．．．、ポートＮ（２２４）を有する。
開示を簡単にするために、２つのデバイス２１０および２１８ならびに２つのＨＢＡ２０６および２０８だけを示しているが、状態の特定の状況により、バスに取り付けることができるデバイスの数は２つよりも少なくても多くてもよく、コンシューマ内のＨＢＡの数も２つよりも少なく（１）ても多くてもよい。
【００１１】
図２は、特定の種類のシステム２００、つまり、ストレージエリアシステムまたはストレージエリアネットワーク（ＳＡＮ）３００に対応したハードウェアのブロック図を示す。
ＳＡＮ３００は、バス３０２、デバイスコンシューマ３０４、不揮発性ストレージデバイス３１０、およびストレージエリアマネージャ（ＳＡＭ）３０１を備える。
【００１２】
デバイスコンシューマ３０４は、ＨＢＡ３０６および３０８を含むことができる。
状態の状況により、ＨＢＡ３０６／３０８の数を増減することができる。
【００１３】
デバイスコンシューマ３０４は、少なくともＣＰＵ、入力デバイス（複数可）、出力デバイス（複数可）、およびメモリを備えるコンピュータ３２６の形態を取ることができる。
たとえば、コンピュータ３２６は、ＣＰＵ、ＩＯデバイス、およびＲＡＭなどの揮発性メモリ、ＲＯＭなどの不揮発性メモリ、フラッシュメモリ、ディスクドライブ、および／またはテープドライブを備えるものとして示されている。
【００１４】
ストレージデバイス３１０は、ポート１（３１２）、ポート２（３１４）、．．．、ポートＮ（３１６）および論理ユニット（ＬＵＮ）１、２、...、Ｎを備える。
また、ストレージデバイス３１０は、ディスクドライブ、テープドライブ、および／またはフラッシュメモリなどの不揮発性メモリ３１８を備える。
ＬＵＮの論理的性質を読み手に思い起こさせるために、ＬＵＮ３２０、３２２、３２４と物理メモリデバイス３１８間の単純化したマッピングを図２に示す。
【００１５】
ＳＡＭ２０１、３０１も、少なくともＣＰＵ、入力デバイス（複数可）、出力デバイス（複数可）、およびメモリを備えるコンピュータの形態を取ることができる。
【００１６】
ＳＡＭ２０１、３０１は、ストレージ管理者がＳＡＮ２００、３００環境を管理できるようにする。
ＳＡＭ２０１、３０１は、ストレージ管理者が、テープおよびディスクストレージ、サーバおよびファイバーチャネルスイッチ、ならびに任意の直接取り付けられたストレージを含むＳＡＮ２００、３００内のすべてのコンポーネントの健全性を制御し監視できるようにする。
【００１７】
図３に示すように、ＳＡＭ２０１、３０１は、ストレージアロケータ４０２、ストレージビルダ４０４、ストレージアカウンタント４０６、ストレージノードマネージャ４０８、およびストレージオプティマイザ４１０を備えることができる。
【００１８】
ストレージアロケータ４０２は、ストレージとサーバをマップして、ストレージをサーバに安全に割り当てることができるようにする。
ストレージアロケータ４０２は、ＳＡＮ２００、３００に保存されたデータへのアクセスの表示、管理、制御を許可する。
ストレージアロケータ４０２は、ホストのリブートなしにストレージの追加、除去、割り当てを可能にすることで、ＳＡＮ２００、３００の拡張を容易にする。
ストレージアロケータ４０２は、クラスタ化されたサーバ構成を可能にする「共有グループ」をセットアップすることも可能にする。
【００１９】
ストレージをサーバに安全に割り当てて、データの損失と権限のないアクセスを防止するには、ストレージアロケータ４０２を使用して、ＬＵＮやＬＵＮのグループをサーバにドラッグアンドドロップすることにより、ＬＵＮやＬＵＮのグループを選択することができる。
特定のサーバにストレージが必要なくなった場合、ストレージアロケータ４０２は、ストレージの使用率を改善するために、別のサーバへの再割り当てを許可する。
【００２０】
ストレージアカウンタント４０６は、財務分析、予算管理、請求のためにエンドユーザに割り当てられたストレージをサービスプロバイダが測定できるようにする。
ストレージの属性とストレージに割り当てられたサービスとに基づいてストレージの提供を分類することで、ユーザは、顧客のプロファイルを追跡し、時間あたりのギガバイト数によるストレージの価格をストレージサービス提供の総コストと比較し、ＬＵＮの割り当てを管理して、特定の価格をＬＵＮに関連付け、サービスレベル価格、割り当てられたＬＵＮのサイズ、ストレージ消費の期間に基づいて料金を計算することができる。
【００２１】
ストレージアカウンタント４０６はＣＳＶ、ＨＴＭＬ、ＸＭＬ形式で利用と請求についての表示を生成することが可能で、それらは、その後第三者による請求および財務申請書に統合したり、監査ログに保持することができる。
【００２２】
ストレージノードマネージャ４０８は、少なくとも１つのインタフェースを介した集中ＳＡＮ２００、３００管理と、マルチホストストレージデバイス管理ツールの統合を可能にする。
自動デバイス検出、健全性監視、および自動警告により、資産の可用性の改善が保証される。
ストレージ構成の追加、削除または変更とデータセンタ環境の変化の追跡は、少なくとも１つのインタフェースを介して実施することができる。
ストレージノードマネージャ４０８は、システム管理者が場所フィールドをカスタマイズし、分散環境でデバイスの物理的位置を特定することも可能にする。
【００２３】
ストレージオプティマイザ４１０は、ユーザがボトルネットを特定して、ＳＡＮ２００、３００のパフォーマンスを高めるようにする。
ストレージオプティマイザ４１０は、ストレージマネージャが、ホスト、インフラストラクチャ、およびストレージを含むＳＡＮ２００、３００の全体のパフォーマンスを監視することで、速度低下に対処し、ボトルネックを特定するために必要な情報をストレージマネージャに提供する。
【００２４】
ＳＡＮ２００、３００のパフォーマンスの重要なメトリックを監視することで、ストレージマネージャは適切なサービスレベルを実施することができるようになる。
ストレージオプティマイザ４１０は、未加工や要約された一連のデータを収集して管理し、データへのいくつかの種類のアクセスを提供することで、ＳＡＮ２００、３００の動作を改善するのに必要な情報をストレージマネージャに与える。
【００２５】
履歴グラフを使用することで、ストレージマネージャは、それらのＳＡＮ２００、３００インフラストラクチャ内の傾向と異常を特定することができる。
ストレージオプティマイザ４１０を使用して、システム、ストレージ、インフラストラクチャのアップグレードの影響を評価して、ＳＡＮ２００、３００全体のパフォーマンスを改善することが可能である。
【００２６】
ＳＡＭ２０１、３０１は、ストレージの容量の評価、制御、計画を支援して、リソースの使用率を改善するストレージビルダ４０４を含むこともある。
ストレージビルダ４０４は、さまざまなオペレーティングシステムにまたがって、ホスト、ストレージデバイス、ＬＵＮ、パーティション、ボリューム、ディレクトリ、ユーザごとのストレージリソースの現在の割り当てと消費を表示することで、管理者がストレージリソースの使用率を改善できるようにする。
【００２７】
履歴傾向データを使用することで、ストレージビルダ４０４は、ストレージ容量に対する将来的なニーズを推定することもできる。
この推定により、管理者は、容量の追加が必要な時期を積極的に予測することができる。
ストレージビルダ４０４は、潜在的な容量の不足について早期の警告を与え、削除可能なファイル（たとえば、アクセスされることのないファイルや、具体的に特定された拡張子を持つファイル）を特定し、ＩＴ管理者がグループを作成して、そのグループの現在の使用パターンを将来のリソース計画のために分析できるようにすることもできる。
【００２８】
ストレージビルダ４０４は、分散データ収集と、デバイスコンシューマ２０４、３０４上の収集のために定期的にスケジュールされた情報処理も行う。
一実施形態では、データ配信機構はイベントベースで、イベントメッセージをデバイスコンシューマ２０４、３０４からＳＡＭ２０１、３０１へ移動することを可能にし、接続機構は、ＳＡＭ２０１、３０１がデバイスコンシューマ２０４、３０４に接触し、情報をデバイスコンシューマ２０４、３０４から伝達可能にし、ワークスレッドキュー機構は、任意の時刻に使用中の並列スレッド数を減らし、集中ストレージ機構（通常、デバイス２１８、３１８などのデータベース）はストレージに使用される。
【００２９】
図４は、本発明の一実施形態によるストレージビルダ４０４を示している。
Ｈａｒｖｅｓｔｅｒ（ハーベスタ）４０４１は、デバイスコンシューマ２０４、３０４上で集められたデータを収集するためのイベントベースの収集機構である。
イベントベース機構の１つの目的は、２つの局面がある。
【００３０】
第１に、イベントベース機構は、サービスの要求と、サービスを提供する実体との間にあるレベルの抽象化を提供する。
第２に、イベントベース機構は、ＳＡＮ  ２００、３００上のすべてのデバイスコンシューマ２０４、３０４に対して定期的に情報をポーリングする必要のない、データの収集のための機構を提供する。
【００３１】
各デバイスコンシューマ２０４、３０４上のＧａｔｈｅｒｅｒ（ギャザラ）２０４１は、情報を集め、完了後、終了収集イベントを出力する。
イベントは、たとえば、イベントサブスクリプションシステムを介して、各デバイスコンシューマ２０４、３０４のドメイン上で検出されたすべてのＳＡＭ  ２０１、３０１に対して転送される。
【００３２】
ＳＡＭ  ２０１、３０１において、イベント（複数可）は、イベントサブスクリプションシステムを介して１つまたは複数のＭｅｓｓｅｎｇｅｒ（メッセンジャ）４０４２により受け取られる。
Ｍｅｓｓｅｎｇｅｒ  ４０４２は、イベントをＨａｒｖｅｓｔｅｒ  ４０４１までリレーするが、必要な場合はイベントをＨａｒｖｅｓｔｅｒ  ４０４１を対象としたメッセージ５０２に変換する。
Ｈａｒｖｅｓｔｅｒ  ４０４１は、メッセージ５０２を受け取り、メッセージを少なくとも１つのキューに配置する。
一実施形態では、この少なくとも１つのキューはＴａｓｋＱｕｅｕｅ（タスクキュー）４０４３とＴｒａｎｓａｃｔｉｏｎＱｕｅｕｅ（トランザクションキュー）４０４４を含む。
【００３３】
別個のスレッドが、ＴａｓｋＱｕｅｕｅ  ４０４３またはＴｒａｎｓａｃｔｉｏｎＱｕｅｕｅ  ４０４４から項目を取得し、少なくとも１つのＤｉｒｅｃｔｏｒ（ディレクタ）４０４５にメッセージ５０２を処理可能なＡｃｔｉｏｎＨａｎｄｌｅｒ（アクションハンドラ）４０４６について問い合わせる。
少なくとも１つのＤｉｒｅｃｔｏｒ  ４０４５の集合は、Ｈａｒｖｅｓｔｅｒ  ４０４１により生成可能なＡｃｔｉｏｎＨａｎｄｌｅｒ  ４０４６を定義し、それによりＨａｒｖｅｓｔｅｒ  ４０４１の機能性を定義する。
ＡｃｔｉｏｎＨａｎｄｌｅｒ  ４０４６は、キュー機構を使用して別個のスレッド内で実行される。
少なくとも１つのＤｉｒｅｃｔｏｒ  ４０４５の集合はモジュラー形式のため、簡単なプラグイン機能性により必要に応じてＨａｒｖｅｓｔｅｒ  ４０４１の機能性を拡張したり縮小することができる。
スケーラビリティを向上させるには、別個のマシン上にそれぞれ存在する複数のＨａｒｖｅｓｔｅｒ  ４０４１を使用することもできる。
【００３４】
Ｍｏｎｉｔｏｒ（モニタ）４０４７は、定期的にあるいは要求によりトリガされる度にメッセージを生成可能なＨａｒｖｅｓｔｅｒ  ４０４１の機能性である。
ＨａｒｖｅｓｔｅｒＭａｎａｇｅｍｅｎｔ（ハーベスタ管理）４０４８はＨａｒｖｅｓｔｅｒ  ４０４１に使用されるリモートインタフェースである。
【００３５】
各Ｈａｒｖｅｓｔｅｒ  ４０４１の機能性は、そのＨａｒｖｅｓｔｅｒ  ４０４１に関連付けられた少なくとも１つのＤｉｒｅｃｔｏｒ  ４０４５の集合により定義することが可能で、それにより、集められたメッセージ５０２を区分することが可能になることにより、スケーラビリティの要件を達成することができる。
すべてのＨａｒｖｅｓｔｅｒ  ４０４１は、デバイス２１８、３１８などのデータベースと通信するＡｃｔｉｏｎＨａｎｄｌｅｒ  ４０４６を含むことができる。
このデータベースは、別個のマシン上に配置することが可能で、図２に示した標準の機構を使用してスケーラビリティを向上させることができる。
【００３６】
Ｈａｒｖｅｓｔｅｒ  ４０４１は通常、以下のように動作する。
Ｍｅｓｓｅｎｇｅｒ  ４０４２は、ある特定の方式で処理しなければならないイベントを受け取る。
Ｍｅｓｓｅｎｇｅｒ  ４０４２は、イベントを生成したり、イベントをＨａｒｖｅｓｔｅｒ  ４０４１に送る（イベントが実際に単なるメッセージ５０２の場合）。
次に、Ｈａｒｖｅｓｔｅｒ  ４０４１は、自身に関連付けられた少なくとも１つのＤｉｒｅｃｔｏｒ  ４０４５の集合を使用して、ＡｃｔｉｏｎＨａｎｄｌｅｒ  ４０４６を作成する。
次に、ＡｃｔｉｏｎＨａｎｄｌｅｒ  ４０４６は、ＴａｓｋＱｕｅｕｅ  ４０４３かＴｒａｎｓａｃｔｉｏｎＱｕｅｕｅ  ４０４４に追加される。
【００３７】
タスクキューは、作業プール機構で、一般的な非データベース作業用の機構、ＴａｓｋＱｕｅｕｅ  ４０４３と、データベース上でトランザクションを行う別の機構であるＴｒａｎｓａｃｔｉｏｎＱｕｅｕｅ  ４０４４に特化されている。
どちらのキューも、同一のマシン上のすべてのＨａｒｖｅｓｔｅｒ  ４０４１で共有可能である。
ＡｃｔｉｏｎＨａｎｄｌｅｒ  ４０４６はＴａｓｋＱｕｅｕｅ  ４０４３により実行される。
ＡｃｔｉｏｎＨａｎｄｌｅｒ  ４０４６が完了した後、Ｈａｒｖｅｓｔｅｒ  ４０４１は、ＡｃｔｉｏｎＨａｎｄｌｅｒ  ４０４６が処理できなかった実行中に遭遇した項目に対応するメッセージの集合を受け取る。
次に、ＡｃｔｉｏｎＨａｎｄｌｅｒ  ４０４６が正常に完了している場合、未処理のメッセージは、ＡｃｔｉｏｎＨａｎｄｌｅｒ  ４０４６を介してＥｖｅｎｔＳｅｒｖｉｃｅ（イベントサービス）４０４９に送られる。
おそらく、そこで未処理のメッセージは、少なくとも１つのＤｉｒｅｃｔｏｒ  ４０４５の異なる集合、つまり異なる機能性を持つＨａｒｖｅｓｔｅｒ  ４０４１に接続された他のＭｅｓｓｅｎｇｅｒ  ４０４２により探索され、処理サイクルが再度開始される。
未処理のメッセージは、アクションの集合を１つに連結するのに使用することができる。
【００３８】
任意のＤｉｒｅｃｔｏｒ  ４０４５による処理が可能なものにメッセージ５０２が対応しない場合、ＡｃｔｉｏｎＨａｎｄｌｅｒ  ４０４６は作成されないが、この状態にも対応することが可能である。
【００３９】
以下のシーケンス図に示したプロセスは、メッセージ５０２の処理方法のシーケンスを示している。
図５は、統一モデリング言語（ＵＭＬ）の原則（principle）によるシーケンス図である。
図５のシーケンスは、Ｍｅｓｓｅｎｇｅｒ  ４０４２、Ｈａｒｖｅｓｔｅｒ  ４０４１、少なくとも１つのＤｉｒｅｃｔｏｒ  ４０４５、ＴａｓｋＱｕｅｕｅ  ４０４３、ＡｃｔｉｏｎＨａｎｄｌｅｒ  ４０４６、ＥｖｅｎｔＳｅｒｖｉｃｅ  ４０４９間のさまざまな相互作用を示している。
【００４０】
図５に示したように、Ｍｅｓｓｅｎｇｅｒ  ４０４２は、処理メッセージ５０４をＨａｒｖｅｓｔｅｒ  ４０４１に送る。
Ｈａｒｖｅｓｔｅｒ  ４０４１は、Ｄｉｒｅｃｔｏｒ  ４０４５にＡｃｔｉｏｎＨａｎｄｌｅｒ  ４０４６の取得かつ／またはＡｃｔｉｏｎＨａｎｄｌｅｒ  ４０４６の作成を要求する。
Ｄｉｒｅｃｔｏｒ  ４０４５は、Ｈａｒｖｅｓｔｅｒ  ４０４１の指令によりＡｃｔｉｏｎＨａｎｄｌｅｒ  ４０４６を作成し、作成されたＡｃｔｉｏｎＨａｎｄｌｅｒ  ４０４６をＨａｒｖｅｓｔｅｒ  ４０４１に返し、Ｈａｒｖｅｓｔｅｒ  ４０４１に、新しく作成されたＡｃｔｉｏｎＨａｎｄｌｅｒ  ４０４６をＴａｓｋＱｕｅｕｅ  ４０４３およびＴｒａｎｓａｃｔｉｏｎＱｕｅｕｅ  ４０４４のうちの１つに追加できるようにする。
次に、Ｈａｒｖｅｓｔｅｒ  ４０４１はＡｃｔｉｏｎＨａｎｄｌｅｒ  ４０４６をＴａｓｋＱｕｅｕｅ  ４０４３およびＴｒａｎｓａｃｔｉｏｎＱｕｅｕｅ  ４０４４のうちの１つに配置し、ＴａｓｋＱｕｅｕｅ  ４０４３にそのアクションを知らせる。
ＴａｓｋＱｕｅｕｅ  ４０４３内でＡｃｔｉｏｎＨａｎｄｌｅｒ  ４０４６が実行される順番が来ると、適切なシーケンスがＡｃｔｉｏｎＨａｎｄｌｅｒ  ４０４６で実行され、更新される。
ＡｃｔｉｏｎＨａｎｄｌｅｒ  ４０４６が完了すると、ＴａｓｋＱｕｅｕｅ  ４０４３はＨａｒｖｅｓｔｅｒ  ４０４１にＡｃｔｉｏｎＨａｎｄｌｅｒ  ４０４６が完了したことを知らせる。
Ｈａｒｖｅｓｔｅｒ  ４０４１は、未処理のメッセージ５０６に関してＡｃｔｉｏｎＨａｎｄｌｅｒ  ４０４６に問い合わせもする。
ＡｃｔｉｏｎＨａｎｄｌｅｒ  ４０４６は、未処理のメッセージ５０６のリストをＨａｒｖｅｓｔｅｒ  ４０４１に返す。
次に、Ｈａｒｖｅｓｔｅｒ  ４０４１はすべての未処理のメッセージ５０６をＥｖｅｎｔＳｅｒｖｉｃｅ  ４０４９に送る。
【００４１】
図６は、本発明の一実施形態によるＨａｒｖｅｓｔｅｒ  ４０４１、少なくとも１つのＤｉｒｅｃｔｏｒ  ４０４５、少なくとも１つのＢｕｉｌｄｅｒ（ビルダ）４０５０の間の相互作用を示したシーケンス図である。
【００４２】
Ｈａｒｖｅｓｔｅｒ  ４０４１が適切なＡｃｔｉｏｎＨａｎｄｌｅｒ  ４０４６を決定できるように、Ｈａｒｖｅｓｔｅｒ  ４０４１はすべての関連付けられたＤｉｒｅｃｔｏｒ  ４０４５に問い合わせる。
Ｈａｒｖｅｓｔｅｒ  ４０４１は、まずＤｉｒｅｃｔｏｒ  ４０４５を検査して所与のメッセージが対象のものであるかどうかを調べる（６０２）ことができる。
所与のメッセージが対象のものである場合、Ｈａｒｖｅｓｔｅｒ  ４０４１は、メッセージ５０２に対するすべてのＡｃｔｉｏｎＨａｎｄｌｅｒ  ４０４６を取得しようと試みる。
Ｄｉｒｅｃｔｏｒ  ４０４５は、必要に応じて、関連付けられたＢｕｉｌｄｅｒ  ４０５０を使用してＡｃｔｉｏｎＨａｎｄｌｅｒ  ４０４６を構築する。
【００４３】
図６に示すように、Ｈａｒｖｅｓｔｅｒ  ４０４１は、Ｍｅｓｓｅｎｇｅｒ  ４０４２から受け取ったメッセージをＤｉｒｅｃｔｏｒ  ４０４５に転送して、メッセージがＤｉｒｅｃｔｏｒ  ４０４５の対象かどうかを確認する。
Ｄｉｒｅｃｔｏｒ  ４０４５は、すべての存在するＢｕｉｌｄｅｒ  ４０５０に問い合わせ、Ｂｕｉｌｄｅｒ  ４０５０がメッセージを処理可能であることを示す対象該当情報６０４をＢｕｉｌｄｅｒ  ４０５０が返した場合、Ｄｉｒｅｃｔｏｒ  ４０４５はかかる情報をＨａｒｖｅｓｔｅｒ  ４０４１に転送する。
次に、Ｂｕｉｌｄｅｒ  ４０５０が対象の場合、Ｈａｒｖｅｓｔｅｒ  ４０４１は、Ｄｉｒｅｃｔｏｒ  ４０４５にＡｃｔｉｏｎＨａｎｄｌｅｒ  ４０４６を要求する。
Ｄｉｒｅｃｔｏｒ  ４０４５は、ＡｃｔｉｏｎＨａｎｄｌｅｒ  ４０４６をＢｕｉｌｄｅｒ  ４０５０から取得し、Ｂｕｉｌｄｅｒ  ４０５０はＡｃｔｉｏｎＨａｎｄｌｅｒ  ４０４６を蓄積し、ＡｃｔｉｏｎＨａｎｄｌｅｒ  ４０４６からの結果をＤｉｒｅｃｔｏｒ  ４０５０に返す。
次に、Ｄｉｒｅｃｔｏｒ  ４０４５はＡｃｔｉｏｎＨａｎｄｌｅｒ  ４０４６の戻りリストをＨａｒｖｅｓｔｅｒ  ４０４１に転送する。
【００４４】
さらに、Ｈａｒｖｅｓｔｅｒ  ４０４１が複数のＤｉｒｅｃｔｏｒ  ４０４５と各Ｄｉｒｅｃｔｏｒ  ４０４５に関連付けられた複数のＢｕｉｌｄｅｒ  ４０５０を含むことができるため、単一のメッセージ５０２により複数のＡｃｔｉｏｎＨａｎｄｌｅｒ  ４０４６を作成することもできる。
次に各ＡｃｔｉｏｎＨａｎｄｌｅｒ  ４０４６が実行される。
実際には、単一のＡｃｔｉｏｎＨａｎｄｌｅｒ  ４０４６だけが実行されるが、別の振舞いを得るために別のＤｉｒｅｃｔｏｒ  ４０４５が組み込まれている。
【００４５】
Ｈａｒｖｅｓｔｅｒ  ４０４１フレームワークは、ＳＡＭ  ２０１、３０１上に存在するサーバコンポーネントとすることで標準のＪＣＯＲＥフレームワークやＪＩＮＩフレームワークに適合している。
サーバコンポーネントは、標準ＳＣＰファイル（ＣＳＨａｒｖｅｓｔｅｒＣｏｍｐｏｎｅｎｔ（ＣＳハーベスタコンポーネント）用のＣＳＨａｒｖｅｓｔｅｒ．ｓｃｐとＣＰＨａｒｖｅｓｔｅｒＣｏｍｐｏｎｅｎｔ（ＣＰハーベスタコンポーネント）用のＣＰＨａｒｖｅｓｔｅｒ．ｓｃｐ）により初期化される。
基本ＨａｒｖｅｓｔｅｒＣｏｍｐｏｎｅｎｔ（ハーベスタコンポーネント）は、すべての標準の初期化を行うことが可能で、ｉｎｉｔｉａｌｉｚｅＨａｒｖｅｓｔｅｒルーチンを呼び出してＨａｒｖｅｓｔｅｒＣｏｍｐｏｎｅｎｔ実施に固有の初期化を行う。
各ＳＡＭ  ２０１、３０１は、１つまたは複数の別個のまたはグループ化されたＨａｒｖｅｓｔｅｒ  ４０４１のインスタンスを有することができる。
Ｈａｒｖｅｓｔｅｒ  ４０４１は、他の一切のインスタンスに影響を与えず有効化、無効化、シャットダウンすることが可能である。
Ｈａｒｖｅｓｔｅｒ  ４０４１のすべてのインスタンスは、共通のＨａｒｖｅｓｔｅｒ  ４０４１処理キューの集合を共有することができる。
ＨａｒｖｅｓｔｅｒＣｏｍｐｏｎｅｎｔにより使用されるリモートインタフェースは、図４に示したＨａｒｖｅｓｔｅｒＭａｎａｇｅｍｅｎｔ  ４０４８である。
これにより、このコンポーネントに関連付けられたＨａｒｖｅｓｔｅｒ  ４０４１のインスタンスとの相互作用に使用可能なリモート化可能なオブジェクトが提供される。
【００４６】
図７は、ＣＰＨａｒｖｅｓｔｅｒＣｏｍｐｏｎｅｎｔ、ＣＳＨａｒｖｅｓｔｅｒＣｏｍｐｏｎｅｎｔ、ＨａｒｖｅｓｔｅｒＣｏｍｐｏｎｅｎｔ、ＳｅｒｖｅｒＣｏｍｐｏｎｅｎｅｔ（サーバコンポーネント）、ＵｎｉｃａｓｅＲｅｍｏｔｅＯｂｊｅｃｔ（単一事例リモートオブジェクト）、ＨａｒｖｅｓｔｅｒＭａｎａｇｅｍｅｎｔ  ４０４８、およびＨａｒｖｅｓｔｅｒＭａｎａｇｅｍｅｎｔＩＦ（ハーベスタ管理インタフェース）間のクラス相関を示した相関図である。
【００４７】
前述のように、Ｈａｒｖｅｓｔｅｒ  ４０４１の機能性は、Ｈａｒｖｅｓｔｅｒ  ４０４１に配信されるメッセージ５０２、Ｈａｒｖｅｓｔｅｒ  ４０４１が処理可能なメッセージ５０２、特定の種類のメッセージ５０２が処理される方法として定義される。
これらの特徴は、Ｈａｒｖｅｓｔｅｒ  ４０４１のインスタンスに関連付けられたＭｏｄｕｌｅ（モジュール）により定義される。
Ｈａｒｖｅｓｔｅｒ  ４０４１に関連付けられたすべてのＭｏｄｕｌｅは、少なくとも１つのＤｉｒｅｃｔｏｒ  ４０４５により管理される。
Ｄｉｒｅｃｔｏｒ  ４０４５は、Ｈａｒｖｅｓｔｅｒ  ４０４１が必要に応じて有効化、無効化、シャットダウンする機能性を可能にし、さらには、メッセージ５０２を処理できるＡｃｔｉｏｎＨａｎｄｌｅｒ  ４０４６を検出する。
図７に示すように、「＋」はパブリックメソッドを示し、「−」はプライベートメソッドを示す。
一実施形態では、パブリックメソッドは、外部インタフェースの一部と見なされ、プライベートメソッドは機能を行うために使用される内部メソッドであるが、通常は外部インタフェースの一部とは見なされない。
【００４８】
図８は、Ｍｏｄｕｌｅ、ＭｅｓｓａｇｅＨａｎｄｌｅｒ（メッセージハンドラ）、Ｍｅｓｓｅｎｇｅｒ  ４０４２、少なくとも１つのＤｉｒｅｃｔｏｒ  ４０４５、少なくとも１つのＢｕｉｌｄｅｒ  ４０５０間のクラス相関を示した相関図である。
【００４９】
Ｍｏｄｕｌｅは、Ｈａｒｖｅｓｔｅｒ  ４０４１に関連付けられた任意の種類の機能性とすることができる。
Ｍｏｄｕｌｅはすべて、有効化、無効化、シャットダウンすることが可能である。
Ｍｏｄｕｌｅは、定義上、作成時にはすべて無効化されている。
【００５０】
Ｂｕｉｌｄｅｒ  ４０５０は、所与のメッセージ５０２を処理可能なＡｃｔｉｏｎＨａｎｄｌｅｒ  ４０４６を生成するＭｏｄｕｌｅである。
各Ｂｕｉｌｄｅｒ  ４０５０は、メッセージ５０２を受け取り、メッセージ５０２を処理する適切なＡｃｔｉｏｎＨａｎｄｌｅｒ  ４０４６を構築する単純なｆａｃｔｏｒｙクラスとすることができる。
【００５１】
Ｄｉｒｅｃｔｏｒ  ４０４５は、他のＭｏｄｕｌｅの集合を制御するＭｏｄｕｌｅである。
Ｄｉｒｅｃｔｏｒ  ４０４５は、ＡｃｔｉｏｎＨａｎｄｌｅｒ  ４０６０の生成のためのＢｕｉｌｄｅｒ（複数可）  ４０５０との相互作用のためにＨａｒｖｅｓｔｅｒ  ４０４１が使用するインタフェースを提供する。
ＭｅｓｓａｇｅＨａｎｄｌｅｒは、メッセージ５０２を受け取り、処理することができるＭｏｄｕｌｅである。
Ｈａｒｖｅｓｔｅｒ  ４０４１それ自体が、ＭｅｓｓａｇｅＨａｎｄｌｅｒである。
【００５２】
Ｍｅｓｓｅｎｇｅｒ  ４０４２は、イベントサービスからのイベントに応答して、イベントの発生をＭｅｓｓａｇｅＨａｎｄｌｅｒが対象とするメッセージ５０２に変換することが可能なＭｏｄｕｌｅである。
【００５３】
図９は、少なくとも１つのＤｉｒｅｃｔｏｒ  ４０４５、少なくとも１つのＢｕｉｌｄｅｒ  ４０５０、少なくとも１つのＭｅｓｓｅｎｇｅｒ  ４０４２、ＭｅｓｓａｇｅＨａｎｄｌｅｒ、少なくとも１つのＴａｓｋＱｕｅｕｅ  ４０４３、少なくとも１つのＴｒａｎｓａｃｔｉｏｎＱｕｅｕｅ  ４０４４、少なくとも１つのＨａｒｖｅｓｔｅｒ  ４０４１間のクラス相関をＨａｒｖｅｓｔｅｒ  ４０４１の観点から示した相関図である。
【００５４】
前述のように、Ｈａｒｖｅｓｔｅｒ  ４０４１はメッセージ／応答処理システムである。
メッセージ５０２はＭｅｓｓｅｎｇｅｒ  ４０４２から受け取られ、ＭｅｓｓａｇｅＨａｎｄｌｅｒ（Ｈａｒｖｅｓｔｅｒ  ４０４１）に処理のために渡される。
Ｈａｒｖｅｓｔｅｒ  ４０４１は、自身のＤｉｒｅｃｔｏｒ  ４０４５の集合に問い合わせて、メッセージ５０２がＤｉｒｅｃｔｏｒ  ４０４５の集合のいずれかの対象かどうかを判断する。
対象の場合、Ｄｉｒｅｃｔｏｒ  ４０４５はメッセージ５０２に対してＡｃｔｉｏｎＨａｎｄｌｅｒ  ４０４６を生成するように指示される。
Ｄｉｒｅｃｔｏｒ  ４０４５は、それ自身のＢｕｉｌｄｅｒ  ４０５０の集合を調べることでこれを達成する。
次に、すべての生成されたＡｃｔｉｏｎＨａｎｄｌｅｒ  ４０４６は、Ｈａｒｖｅｓｔｅｒ  ４０４１に関連付けられたＴｒａｎｓａｃｔｉｏｎＱｕｅｕｅ  ４０４４またはＴａｓｋＱｕｅｕｅ  ４０４３のいずれかを使用してＨａｒｖｅｓｔｅｒ  ４０４１により実行され、受け取ったメッセージ５０２を処理可能である。
【００５５】
図１０は、ＤｅｌａｙｅｄＭｏｄｅｌＥｖｅｎｔＤｉｓｐａｔｃｈｅｒ（遅延モデルイベントディスパッチャ）、ＭｏｄｅｌＭｅｓｓｅｎｇｅｒ（モデルメッセンジャ）、ＬｏｃａｌＥｖｅｎｔＬｉｓｔｅｎｅｒ（ローカルイベントリスナ）、ＤｏｍａｉｎＣａｐａｃｉｔｙＭｅｓｓｅｎｇｅｒ（ドメイン容量メッセンジャ）、ＯｒｇａｎｉｚａｔｉｏｎＣａｐａｃｉｔｙＭｅｓｓｅｎｇｅｒ（組織容量メッセンジャ）、ＪＣｏｒｅＭｅｓｓｅｎｇｅｒ（Ｊｃｏｒｅメッセンジャ）、ＧａｔｈｅｒｅｒＭｅｓｓｅｎｇｅｒ（ギャザラメッセンジャ）間のクラス相関をＪＣｏｒｅＭｅｓｓｅｎｇｅｒの観点から示した相関図である。
【００５６】
Ｍｅｓｓｅｎｇｅｒ  ４０４２は、様々なイベントシステムからイベントを受け取り、Ｈａｒｖｅｓｔｅｒ  ４０４１で使用するために、それらをメッセージ５０２に変換する。
メッセージ５０２を取得し、それらを適切に処理するＭｅｓｓａｇｅＨａｎｄｌｅｒ（通常はＨａｒｖｅｓｔｅｒ  ４０４１のインスタンス）は、各Ｍｅｓｓｅｎｇｅｒ  ４０４２に関連付けられている。
【００５７】
図１１は、ＡｂｓｔｒａｃｔＡｂｏｒｔａｂｌｅ（抽象中断可能）、ＡｂｓｔｒａｃｔＡｃｔｉｏｎＨａｎｄｌｅｒ（抽象アクションハンドラ）、ＡｃｔｉｏｎＨａｎｄｌｅｒ  ４０４６、ＣｏｎｔｅｎｔＡｃｔｉｏｎＨａｎｄｌｅｒ（コンテンツアクションハンドラ）、ＤａｔａＣｏｎｔｅｎｔＡｃｔｉｏｎＨａｎｄｌｅｒ（データコンテンツアクションハンドラ）、ＴｒａｎｓａｃｔｉｏｎＡｃｔｉｏｎＨａｎｄｌｅｒ（トランザクションアクションハンドラ）、ＤａｔａＳｅｔＡｃｔｉｏｎＨａｎｄｌｅｒ（データセットアクションハンドラ）間のクラス相関を示した相関図である。
【００５８】
ＡｃｔｉｏｎＨａｎｄｌｅｒ  ４０４６は、メッセージ５０２を処理するために作成されたプロセッサとすることもできる。
プロセッサの典型的なタスクには、Ｇａｔｈｅｒｅｒ  ２０４１やアーカイブファイルのデータを探索したり、データベース２１８、３１８を更新したり、レポートを作成することなどがある。
ＡｃｔｉｏｎＨａｎｄｌｅｒ  ４０４６は、実行可能でかつ中止可能であり、処理中に検出された処理不能な状態を報告する機構を提供する。
【００５９】
ＡｃｔｉｏｎＨａｎｄｌｅｒ  ４０４６は、データベース更新以外のアクションも行うことが可能である。
行われる具体的なアクションは、ＡｃｔｉｏｎＨａｎｄｌｅｒ  ４０４６がどのように構築されているかに依存する。
ＳＡＭ  ２０１、３０１では、ＸＭＬレポートが生成され、ホストに連絡してそれらのレポートが登録されてイベントが中央管理サーバに送られ、他のコンポーネントや中央管理サーバに状態の変化が通知される場合がある。
【００６０】
ＡｃｔｉｏｎＨａｎｄｌｅｒ  ４０４６は、継承ではなく合成を使用して、ＡｃｔｉｏｎＨａｎｄｌｅｒ  ４０４６のレベルのマルチユースを達成している。
図９のＡｃｔｉｏｎＨａｎｄｌｅｒインタフェースは、ＡｃｔｉｏｎＨａｎｄｌｅｒ  ４０４６の一般的な属性を定義していて、汎用のＡｃｔｉｏｎＨａｎｄｌｅｒ  ４０４６の集合が存在する。
ＤａｔａＳｅｔＣｏｎｔｅｎｔＡｃｔｉｏｎＨａｎｄｌｅｒとＣｏｎｔｅｎｔＡｃｔｉｏｎＨａｎｄｌｅｒは、汎用ＡｃｔｉｏｎＨａｎｄｌｅｒ  ４０４６の２つの例である。
ＤａｔａＳｅｔＡｃｔｉｏｎＨａｎｄｌｅｒとＣｏｎｔｅｎｔＡｃｔｉｏｎＨａｎｄｌｅｒは、どちらも関連付けられたＣｏｎｔｅｎｔＨａｎｄｌｅｒの集合を使用してそれらの個別の機能性を確定する。
まず、ＣｏｎｔｅｎｔＡｃｔｉｏｎＨａｎｄｌｅｒが作成され、次に、所望の動作を行うためにＣｏｎｔｅｎＨａｎｄｌｅｒがそれに追加される。
何らかのメトリックに対する履歴計測値を生成するＣｏｎｔｅｎｔＨａｎｄｌｅｒと、ボリューム容量情報を更新するＣｏｎｔｅｎｔＨａｎｄｌｅｒが存在する場合、両方をＣｏｎｔｅｎｔＡｃｔｉｏｎＨａｎｄｌｅｒに追加して、履歴計測値の生成と、ボリューム容量の更新の両方を実行するＡｃｔｉｏｎＨａｎｄｌｅｒ  ４０４６を得ることができる。
ユーザアカウント消費を更新するＣｏｎｔｅｎｔＨａｎｄｌｅｒに同一の履歴計測値ＣｏｎｔｅｎｔＨａｎｄｌｅｒを追加することもできる。
その結果、少なくとも何らかの共通部分（ＣｏｎｔｅｎｔＨａｎｄｌｅｒ）を持つ２つの異なるＡｃｔｉｏｎＨａｎｄｌｅｒ  ４０４６を作成することができる。
【００６１】
図１１を再度参照すると、ＡｂｓｔｒａｃｔＡｃｔｉｏｎＨａｎｄｌｅｒは、ほとんどのＡｃｔｉｏｎＨａｎｄｌｅｒ  ４０４６に共通の基本的なＡｃｔｉｏｎＨａｎｄｌｅｒ  ４０４６機能性を提供するベースクラスである。
ａｄｄＭｅｓｓａｇｅ（メッセージ追加）メソッドは、ｕｎｈａｎｄｌｅｄＭｅｓｓａｇｅ（未処理メッセージ）メソッドにより報告される未処理のメッセージを追加するために派生クラスが使用可能な機構を提供する。
【００６２】
図１２は、ＣｏｎｔｅｎｔＡｃｔｉｏｎＨａｎｄｌｅｒ、ＤａｔａＣｏｎｔｅｎｔＡｃｔｉｏｎＨａｎｄｌｅｒ、ＣｏｎｔｅｎｔＨａｎｄｌｅｒ、ＤａｔａＣｏｎｔｅｎｔＨａｎｄｌｅｒ（データコンテンツハンドラ）、ＡｂｓｔｒａｃｔＣｏｎｔｅｎｔＨａｎｄｌｅｒ（抽象コンテンツハンドラ）、ＦｉｌｅＤａｔａＣｏｎｔｅｎｔＨａｎｄｌｅｒ（ファイルデータコンテンツハンドラ）、ＵｓｅｒＡｃｃｏｕｎｔＤａｔａＣｏｎｔｅｎｔＨａｎｄｌｅｒ（ユーザアカウントデータコンテンツハンドラ）、ＵｓｅｒＤａｔａＣｏｎｔｅｎｔＨａｎｄｌｅｒ（ユーザデータコンテンツハンドラ）、ＶｏｌｕｍｅＤａｔａＣｏｎｔｅｎｔＨａｎｄｌｅｒ（ボリュームデータコンテンツハンドラ）、ＤｏｍａｉｎＵｐｄａｔｅＣｏｎｔｅｎｔＨａｎｄｌｅｒ（ドメイン更新コンテンツハンドラ）、ＭｅａｓｕｒｅｍｅｎｔＣｏｎｔｅｎｔＨａｎｄｌｅｒ（計測値コンテンツハンドラ）間のクラス相関を示した相関図である。
【００６３】
図１２に示したように、ＣｏｎｔｅｎｔＡｃｔｉｏｎＨａｎｄｌｅｒは、それに関連付けられたＣｏｎｔｅｎｔＨａｎｄｌｅｒに基づいてアクションを行うＡｃｔｉｏｎＨａｎｄｌｅｒ  ４０４６である。
ＤａｔａＣｏｎｔｅｎｔＨａｎｄｌｅｒは、それに関連付けられたＤａｔａＣｏｎｔｅｎｔＨａｎｄｌｅｒに基づいてアクションを行うＡｃｔｉｏｎＨａｎｄｌｅｒ  ４０４６である。
ＤａｔａＳｅｔＡｃｔｉｏｎＨａｎｄｌｅｒは、読み取り元のデータセットからのデータ読み取りに基づいてアクションを行うＡｃｔｉｏｎＨａｎｄｌｅｒ  ４０４６である。
ＴｒａｎｓａｃｔｉｏｎＡｃｔｉｏｎＨａｎｄｌｅｒ（トランザクションアクションハンドラ）は、任意の標準ＡｃｔｉｏｎＨａｎｄｌｅｒ  ４０４６を包含して、標準ＡｃｔｉｏｎＨａｎｄｌｅｒ  ４０４６を標準のＴｒａｎｓａｃｔｉｏｎＱｕｅｕｅ  ４０４４にすることが可能なＡｃｔｉｏｎＨａｎｄｌｅｒ  ４０４６である。
【００６４】
ＣｏｎｔｅｎｔＡｃｔｉｏｎＨａｎｄｌｅｒは、関連付けられたＣｏｎｔｅｎｔＨａｎｄｌｅｒとＤａｔａＣｏｎｔｅｎｔＨａｎｄｌｅｒの集合に基づいてアクションを行う。
ＣｏｎｔｅｎｔＨａｎｄｌｅｒは、１種類のアクションが可能である。
１種類のアクションとしては、１種類のデータベースの更新、レポートの生成などがあり得る。
ＤａｔａＣｏｎｔｅｎｔＨａｎｄｌｅｒは、データオブジェクトを取得して、そのオブジェクトの更新を行うＣｏｎｔｅｎｔＨａｎｄｌｅｒである。
【００６５】
Ｄａｔａ（データ）は、データの処理の支援に使用される単純なユーティリティクラスである。
図１３は、データ構造を示す。
【００６６】
ＤａｔａＳｅｔＡｃｔｉｏｎＨａｎｄｌｅｒは、図１３に示すように、読み取り元のデータセットから探索されたデータに基づいて更新を行う。
読み取り元のデータセットは、ＤａｔａＳｅｔＡｃｔｉｏｎＨａｎｄｌｅｒのＤａｔａＳｅｔＲｅａｄｅｒ（データセットリーダ）により読み取られる。
次に、この読み取り元から読み取られたデータセットのデータが、データセット名に従って、関連付けられたＳｔｒｅａｍＰａｒｓｅｒ（ストリームパーサ）によりパースされる。
データセット名ごとに１つのＳｔｒｅａｍＰａｓｅｒが存在することもある。
パース時には、そのデータセット名に対する処理を行うように登録されたＤａｔａＣｏｎｔｅｎｔＨａｎｄｌｅｒをパーサに関連付けることができる。
次に、パーサがデータをパースする時に、これらのコンテンツハンドラを呼び出すことができる。
【００６７】
図１４は、ＳｔｒｅａｍＰａｒｓｅｒ、ＡｂｓｔｒａｃｔＳｔｒｅａｍＰａｒｓｅｒ（抽象ストリームパーサ）、ＣＳＶＳｔｒｅａｍＰａｒｓｅｒ（ＣＳＶストリームパーサ）、ＦｉｌｅＤａｔａＣＳＶＳｔｒｅａｍＰａｒｓｅｒ（ファイルデータＣＳＶストリームパーサ）、ＵｓｅｒＤａｔａＳＣＶＳｔｒｅａｍＰａｒｓｅｒ（ユーザデータＳＣＶストリームパーサ）、ＶｏｌｕｍｅＤａｔａＣＳＶＳｔｒｅａｍＰａｒｓｅｒ（ボリュームデータＣＳＶストリームパーサ）、ＤａｔａＳｅｔＡｃｔｉｏｎＨａｎｄｌｅｒ、ＤａｔａＳｅｔＲｅａｄｅｒ、ＡｒｃｈｉｖｅＲｅａｄｅｒ（アーカイブリーダ）、ＧａｔｈｅｒｅｒＲｅａｄｅｒ（ギャザラリーダ）間のクラス相関を示した相関図である。
【００６８】
Ｈａｒｖｅｓｔｅｒ  ４０４１と他のシステム間の通信は、サービスインタフェースの集合を介して達成することができる。
各サービスは、Ｈａｒｖｅｓｔｅｒ  ４０４１により使用されるフレームワークレベルのサービスの種類を抽象化することができる。
【００６９】
ＣｏｎｎｅｃｔｉｏｎＳｅｒｖｉｃｅ（接続サービス）は、ＳＡＮ  ２００、３００やリモートシステム上の共通に知られているオブジェクトへの参照を取得するサービスの抽象化を提供する。
ＬｏｇｇｉｎｇＳｅｒｖｉｃｅ（記録サービス）は、メッセージを記録するサービスを抽象化する。
ＥｖｅｎｔＳｅｒｖｉｃｅは、対象のリスナにメッセージを送ることを可能にするサービスを抽象化する。
【００７０】
図１５は、ＣｏｎｎｅｃｔｉｏｎＳｅｒｖｉｃｅ、ＪＣｏｒｅＣｏｎｎｅｃｔｉｏｎＳｅｒｖｉｃｅＢｒｉｄｇｅ（ＪＣｏｒｅ接続サービスブリッジ）、ＪｃｏｒｅＣｏｎｎｅｃｔｉｏｎＳｅｒｖｉｃｅＢｒｉｄｇｅ（ＪＣｏｒｅ接続サービスブリッジ）間のクラス相関を示した相関図である。
図１６は、ＬｏｇｇｉｎｇＳｅｒｖｉｃｅ（記録サービス）、ＪＣｏｒｅＬｏｇｇｉｎｇＳｅｒｖｉｃｅＢｒｉｄｇｅ（ＪＣｏｒｅ記録サービスブリッジ）、ＥｖｅｎｔＳｅｒｖｉｃｅ、ＪＣｏｒｅＥｖｅｎｔＳｅｒｖｉｃｅＢｒｉｄｇｅ（ＪＣｏｒｅイベントサービスブリッジ）間のクラス相関を示した相関図である。
【００７１】
図４ないし図６と併せて示した前述の本発明の実施形態では、１つのＨａｒｖｅｓｔｅｒ  ４０４１を示しているが、上述したように、ＳＡＭ  ２０１、３０１のストレージビルダ４０４は、任意の時刻に任意所与の個別のＳＡＭ  ２０１、３０１上で、１つまたは複数のＨａｒｖｅｓｔｅｒ  ４０４１のインスタンスを含むかつ／または実行することができる。
さらに、これも前述のように、ＳＡＮ  ２００、３００は、複数のＳＡＭ  ２０１、３０１を含むことができる。
さらに前述のように、少なくとも１つのＤｉｒｅｃｔｏｒ  ４０４５と関連付けられた少なくとも１つのＢｕｉｌｄｅｒ  ４０５０の集合が、各Ｈａｒｖｅｓｔｅｒ  ４０４１インスタンスの機能性を定義する。
Ｄｉｒｅｃｔｏｒ  ４０４５とＢｕｉｌｄｅｒ  ４０５０の同一の集合を有するＨａｒｖｅｓｔｅｒ  ４０４１の複数のインスタンスを有するストレージビルダ４０４を定義することにより、ストレージビルダ４０４が簡単に拡張できるようになる。
同様に、１つまたは複数のＨａｒｖｅｓｔｅｒ  ４０１が存在することは、同一のメッセージ５０２の受け取りが繰り返し発生する場合など共通のタスクに再使用可能である。
さらに、Ｈａｒｖｅｓｔｅｒ  ４０４１の機能性を、１つまたは複数のＳＡＭ  ２０１、３０１の代わりに、またはそれに加えて、１つまたは複数のデバイスコンシューマ２０４上でホストしたり、あるいは、デバイス２０１、３０１、２０４の任意の組み合わせにより分担することもできる。
【００７２】
図１ないし図４に示した機能ブロックは、ハードウェアおよびまたはソフトウェアに実装可能なことに留意されたい。
ハードウェア／ソフトウェアによる実施は、プロセッサ（複数可）と製造元の部品（複数可）の組み合わせを含むこともできる。
製造元の部品はさらに、記憶媒体と実行可能なコンピュータプログラム（複数可）を含むこともできる。
実行可能なコンピュータプログラム（複数可）は、前述の動作を行う命令を含むこともできる。
コンピュータ実行可能プログラム（複数可）は、搬送波による、または搬送波なしの外部から供給される伝搬信号（複数可）の一部として提供することもできる。
【００７３】
図１ないし図１６と併せて前述したアーキテクチャは、対象を実際に処理するモジュールのその対象を抽象化することで、いくつかのレベルの抽象化を達成可能である。
たとえば、ＳＡＭ  ２０１、３０１によりメッセージが受け取られると、実際のＨａｒｖｅｓｔｅｒ  ４０４１を具体的に特定して所望のメッセージを処理する必要はない。
本発明のアーキテクチャは、Ｈａｒｖｅｓｔｅｒ  ４０４１のインスタンスと、関連付けられたＤｉｒｅｃｔｏｒ  ４０４５およびＢｕｉｌｄｅｒ  ４０５０との間のレベルの抽象化も実現することができる。
その場合、所望のメッセージの処理が可能な任意のＤｉｒｅｃｔｏｒ  ４０４５またはＢｉｕｌｄｅｒ  ４０５０をメッセージの処理に割り当てることができる。
第３のレベルの抽象化は、割り当てられたＤｉｒｅｃｔｏｒ  ４０４５および関連付けられたＢｕｉｌｄｅｒ  ４０５０と実際にメッセージを処理するために特定されたＡｃｔｉｏｎＨａｎｄｌｅｒ  ４０４６との間で実現することができる。
【００７４】
これらの３つのレベルの抽象化の１つまたは複数により、受け取ったメッセージ５０２を、メッセージを処理する実際のモジュール（複数可）から分離することができる。
これらの少なくとも３つのレベルの抽象化により、ＳＡＭ  ２０１、３０１のモジュールを共通のタスクに容易に再使用し、ＳＡＭ  ２０１、３０１の機能性を容易に拡張可能および／または増減可能にして処理するメッセージを増減し、ＳＡＭ  ２０１、３０１の機能性について柔軟性のレベルを向上することができる。
【００７５】
本発明についてこれまで説明したが、本発明がさまざまに変更可能なことは明らかであろう。
そのような変更は、本発明の精神および範囲から逸脱するものと見なされるべきではなく、当業者に明らかなそのような修正はすべて添付の特許請求の範囲内に含めることを意図している。
【産業上の利用可能性】
【００７６】
本発明はコンピュータデバイスの管理のために利用可能である。
【図面の簡単な説明】
【００７７】
【図１】本発明の一実施形態によるハードウェアのブロック図である。
【図２】本発明の別の実施形態によるハードウェアのブロック図である。
【図３】本発明の一実施形態によるストレージエリアマネージャ（ＳＡＭ）ハードウェアのブロック図である。
【図４】本発明の一実施形態によるストレージビルダのハードウェアのブロック図である。
【図５】本発明の一実施形態によるメッセージ処理シーケンスを示したシーケンス図である。
【図６】本発明の一実施形態によるＨａｒｖｅｓｔｅｒ、少なくとも１つのＤｉｒｅｃｔｏｒ、少なくとも１つのＢｕｉｌｄｅｒ間の相互作用を示したシーケンス図である。図５および図６は統一モデリング言語（ＵＭＬ）の原則によるシーケンス図である。メッセージは、異なる様式の矢印で示されている。矢印→は、応答メッセージを期待するメッセージを示している。矢印←−−−−は、応答メッセージを示している。矢印−−−→は、応答がほのめかされているメッセージを示している。矢印→は、応答が期待されていないメッセージを示している。
【図７】本発明の一実施形態によるＣＰＨａｒｖｅｓｔｅｒＣｏｍｐｏｎｅｎｔ、ＣＳＨａｒｖｅｓｔｅｒＣｏｍｐｏｎｅｎｔ、ＨａｒｖｅｓｔｅｒＣｏｍｐｏｎｅｎｔ、ＳｅｒｖｅｒＣｏｍｐｏｎｅｎｅｔ、ＵｎｉｃａｓｅＲｅｍｏｔｅＯｂｊｅｃｔ、ＨａｒｖｅｓｔｅｒＭａｎａｇｅｍｅｎｔ、ＨａｒｖｅｓｔｅｒＭａｎａｇｅｍｅｎｔＩＦ間のクラス相関を示した相関図である。
【図８】本発明の一実施形態によるＭｏｄｕｌｅ、ＭｅｓｓａｇｅＨａｎｄｌｅｒ、Ｍｅｓｓｅｎｇｅｒ、Ｄｉｒｅｃｔｏｒ、Ｂｕｉｌｄｅｒ間のクラス相関を示した相関図である。
【図９】本発明の一実施形態によるＤｉｒｅｃｔｏｒ  ４０５０、少なくとも１つのＢｕｉｌｄｅｒ  ４０５０、少なくとも１つのＭｅｓｓｅｎｇｅｒ  ４０４２、ＭｅｓｓａｇｅＨａｎｄｌｅｒ、少なくとも１つのＴａｓｋＱｕｅｕｅ  ４０４３、少なくとも１つのＴｒａｎｓａｃｔｉｏｎＱｕｅｕｅ  ４０４４、少なくとも１つのＨａｒｖｅｓｔｅｒ  ４０４１間のクラス相関をＨａｒｖｅｓｔｅｒ  ４０４１の観点から示した相関図である。
【図１０】本発明の一実施形態によるＤｅｌａｙｅｄＭｏｄｅｌＥｖｅｎｔＤｉｓｐａｔｃｈｅｒ、ＭｏｄｅｌＭｅｓｓｅｎｇｅｒ、ＬｏｃａｌＥｖｅｎｔＬｉｓｔｅｎｅｒ、ＤｏｍａｉｎＣａｐａｃｉｔｙＭｅｓｓｅｎｇｅｒ、ＯｒｇａｎｉｚａｔｉｏｎＣａｐａｃｉｔｙＭｅｓｓｅｎｇｅｒ、ＪＣｏｒｅＭｅｓｓｅｎｇｅｒ、ＧａｔｈｅｒｅｒＭｅｓｓｅｎｇｅｒ間のクラス相関をＪＣｏｒｅＭｅｓｓｅｎｇｅｒの観点から示した相関図である。
【図１１】本発明の一実施形態によるＡｂｓｔｒａｃｔＡｂｏｒｔａｂｌｅ、ＡｂｓｔｒａｃｔＡｃｔｉｏｎＨａｎｄｌｅｒ、ＡｃｔｉｏｎＨａｎｄｌｅｒ  ４０４６、ＣｏｎｔｅｎｔＡｃｔｉｏｎＨａｎｄｌｅｒ、ＤａｔａＣｏｎｔｅｎｔＡｃｔｉｏｎＨａｎｄｌｅｒ、ＴｒａｎｓａｃｔｉｏｎＡｃｔｉｏｎＨａｎｄｌｅｒ、ＤａｔａＳｅｔＡｃｔｉｏｎＨａｎｄｌｅｒ間のクラス相関を示した相関図である。
【図１２】本発明の一実施形態によるＣｏｎｔｅｎｔＡｃｔｉｏｎＨａｎｄｌｅｒ、ＤａｔａＣｏｎｔｅｎｔＡｃｔｉｏｎＨａｎｄｌｅｒ、ＣｏｎｔｅｎｔＨａｎｄｌｅｒ、ＤａｔａＣｏｎｔｅｎｔＨａｎｄｌｅｒ、ＡｂｓｔｒａｃｔＣｏｎｔｅｎｔＨａｎｄｌｅｒ、ＦｉｌｅＤａｔａＣｏｎｔｅｎｔＨａｎｄｌｅｒ、ＵｓｅｒＡｃｃｏｕｎｔＤａｔａＣｏｎｔｅｎｔＨａｎｄｌｅｒ、ＵｓｅｒＤａｔａＣｏｎｔｅｎｔＨａｎｄｌｅｒ、ＶｏｌｕｍｅＤａｔａＣｏｎｔｅｎｔＨａｎｄｌｅｒ、ＤｏｍａｉｎＵｐｄａｔｅＣｏｎｔｅｎｔＨａｎｄｌｅｒ、ＭｅａｓｕｒｅｍｅｎｔＣｏｎｔｅｎｔＨａｎｄｌｅｒ間のクラス相関を示した相関図である。
【図１３】本発明の一実施形態によるデータ構造を示す図である。
【図１４】本発明の一実施形態によるＳｔｒｅａｍＰａｒｓｅｒ、ＡｂｓｔｒａｃｔＳｔｒｅａｍＰａｒｓｅｒ、ＣＳＶＳｔｒｅａｍＰａｒｓｅｒ、ＦｉｌｅＤａｔａＣＳＶＳｔｒｅａｍＰａｒｓｅｒ、ＵｓｅｒＤａｔａＳＣＶＳｔｒｅａｍｐａｒｓｅｒ、ＶｏｌｕｍｅＤａｔａＣＳＶＳｔｒｅａｍＰａｒｓｅｒ、ＤａｔａＳｅｔＡｃｔｉｏｎＨａｎｄｌｅｒ、ＤａｔａＳｅｔＲｅａｄｅｒ、ＡｒｃｈｉｖｅＲｅａｄｅｒ、ＧａｔｈｅｒｅｒＲｅａｄｅｒ間のクラス相関を示した相関図である。
【図１５】本発明の一実施形態によるＣｏｎｎｅｃｔｉｏｎＳｅｒｖｉｃｅ、ＪＣｏｒｅＣｏｎｎｅｃｔｉｏｎＳｅｒｖｉｃｅＢｒｉｄｇｅ、ＪｃｏｒｅＣｏｎｎｅｃｔｉｏｎＳｅｒｖｉｃｅＢｒｉｄｇｅ間のクラス相関を示した相関図である。
【図１６】本発明の一実施形態によるＬｏｇｇｉｎｇＳｅｒｖｉｃｅ、ＪＣｏｒｅＬｏｇｇｉｎｇＳｅｒｖｉｃｅＢｒｉｄｇｅ、ＥｖｅｎｔＳｅｒｖｉｃｅ、ＪＣｏｒｅＥｖｅｎｔＳｅｒｖｉｃｅＢｒｉｄｇｅ間のクラス相関を示した相関図である。
【符号の説明】
【００７８】
２０１・・・ストレージエリアマネージャ、
２０２・・・バス、
２０６・・・ホストバスアダプタ、
２０４・・・デバイスコンシューマ、
２１０、２１８・・・デバイス、
２１２、２１４、２１６、２２０、２２４・・・ポート、
３２０・・・論理ユニット、
３１０・・・ストレージデバイス、
４０８・・・ストレージノードマネージャ、
４０２・・・ストレージアロケータ、
４０４・・・ストレージビルダ、
４１０・・・ストレージオプティマイザ
４０６・・・ストレージアカウンタント、
２０４、３０４・・・デバイスコンシューマ、
５０２・・・メッセージ、
【図１】
2004164610.tif 000003
【図２】
2004164610.tif 000004
【図３】
2004164610.tif 000005
【図４】
2004164610.tif 000006
【図５】
2004164610.tif 000007
【図６】
2004164610.tif 000008
【図７】
2004164610.tif 000009
【図８】
2004164610.tif 000010
【図９】
2004164610.tif 000011
【図１０】
2004164610.tif 000012
【図１１】
2004164610.tif 000013
【図１２】
2004164610.tif 000014
【図１３】
2004164610.tif 000015
【図１４】
2004164610.tif 000016
【図１５】
2004164610.tif 000017
【図１６】
2004164610.tif 000018