(57)【要約】  ソフトウェアを編成する方法及び装置について説明する。ある実施形態では、本方法は、要求された機能に関連する複数のアプリケーションコンポーネントを特定するソフトウェア構造データを取得し、アプリケーションコンポーネント間の対話規則を示すソフトウェアロジックデータを取得し、ソフトウェア構造データ及びソフトウェアロジックデータをメモリに記憶し、ソフトウェアロジックデータに基づいてアプリケーションコンポーネントの呼び出しを実行時に調整することを含む。【選択図】  図２Ａ
2008524719.tif 000002
【特許請求の範囲】
【請求項１】
複数のアプリケーションコンポーネント、及び該複数のアプリケーションコンポーネント間の対話規則を指定する情報を取得するローダと、
ソフトリアルタイム保証を実行時に提供するように実行するために、ソフトウェアロジックデータに基づいて、前記複数のアプリケーションコンポーネントの呼び出しを調整するスケジューラと、
を備える装置。
【請求項２】
一以上のアプリケーションコンポーネントから成るグループをスケジュールするための要求を受け取るステップと、
アプリケーションパラメータ及びプロファイルデータに応答して、前記一以上のアプリケーションコンポーネントから成るグループについてリソース利用推定値を取得するステップと、
依存性グラフに従って、且つ、前記リソース利用推定値に基づいて、一以上のアプリケーションコンポーネントから成るグループの実行を周期的にスケジュールするステップと、
ソフトリアルタイム保証を実行時に提供するように一以上のアプリケーションコンポーネントを実行するステップと、
を含む方法。
【請求項３】
命令を記憶する記録可能媒体を有する製造品であって、
該命令が、システムによる実行時に、
複数のアプリケーションコンポーネントの各々によって使用されるリソースに関するプロファイルデータを作成するステップと、
アプリケーションパラメータ及び前記プロファイルデータに応答して、前記複数のアプリケーションコンポーネントの各々についてリソース利用推定値を生成するステップと、
依存性グラフに従って、且つ、リソース利用推定値に基づいて、アプリケーションコンポーネントの実行を周期的にスケジュールするステップと、
を含む方法を前記システムに実行させる製造品。
【発明の詳細な説明】
【優先権】
【０００１】
[0001]本特許出願は、２００４年１２月２１日に出願された「Ｍｅｔｈｏｄ  ａｎｄ  Ａｐｐａｒａｔｕｓ  ｆｏｒ  Ｓｕｐｐｏｒｔｉｎｇ  Ｓｏｆｔ  Ｒｅａｌ−Ｔｉｍｅ  Ｂｅｈａｖｉｏｒ  ｗｉｔｈ  Ｍｉｃｒｏ  Ｂｕｉｌｄｉｎｇ  Ｂｌｏｃｋｓ」と題する対応の特許仮出願第６０／６３８，２９７号の優先権を主張するものである。
【関連出願】
【０００２】
[0002]本願は、「Ｍｅｔｈｏｄ  ａｎｄ  Ａｐｐａｒａｔｕｓ  ｆｏｒ  Ｃｏｍｐｏｓｉｎｇ  Ｓｏｆｔｗａｒｅ」と題して２００４年７月２３日に共に出願された同時係属の出願、即ち、本発明の法人譲受人へ譲渡された米国特許出願第１０／８９８，５２１号、及び、「Ｉｎｄｅｘ−Ｂａｓｅｄ  Ｐａｒａｍｅｔｅｒ  Ａｃｃｅｓｓ  ａｎｄ  Ｓｏｆｔｗａｒｅ  ｆｏｒ  Ｕｓｉｎｇ  ｔｈｅ  Ｓａｍｅ」と題して２００５年４月１８日に共に出願された同時係属の出願、即ち、本発明の法人譲受人へ譲渡された米国特許出願第１１／１０９，２５３号に関連するものである。
【発明の分野】
【０００３】
[0003]本発明はソフトウェアに関するものであり、より詳細には、本発明はソフトウェアのソフトリアルタイム動作（behavior)のサポートに関するものである。
【発明の背景】
【０００４】
[0004]移動電話の機能は、過去数年にわたって著しく発展してきた。初期には、単に音声の伝送のみが存在していた。次いで、ショートメッセージ及びウェブのブラウジングが付加された。後に、自動販売機との対話及びマルチ媒体メッセージングが利用可能になった。最近では、ビデオ会議、インターネットアクセス、及び周囲の物理環境との対話が可能になった。移動電話及び無線可能携帯デバイスの発展、並びに無線ネットワークの一層の普及が、ユーザの従来のコンピュータ理解を変えつつある。デスクトップコンピューティングの概念は、より動的なモデルへ徐々に発展しつつある。移動電話は、無線ネットワークへ接続できるようになり、以前にはサーバ及びワークステーションへ予約されたタスクを実行するに十分な処理能力を有している。したがって、移動電話はユーザのディジタルコンパニオンとなって、個々のユーザの状況で動作して、ユーザの毎日のタスクを助けている。更に、無線伝送の速度の伸びによって、移動電話が分散サービス（例えば、ウェブサービス）と対話し、また、豊富なマルチメディアコンテンツにアクセスしてそれを共有することを可能とするアプリケーションを開発できるようになっている。
【０００５】
[0005]ソフトウェアサービスの関連性が増すと、移動電話デバイス用のより高度なオペレーションシステムが必要となる。これらのオペレーションシステムは、Ｊａｖａ（ＭＩＤＰ  ２．０、ＤｏＪａ、Ｐｅｒｓｏｎａｌ  Ｊａｖａ）、Ｃ＃、Ｃ、Ｃ＋＋といった言語に基づくアプリケーション開発のサポートを提供する。更に、これらのオペレーションシステムは、分散アプリケーションの開発を支援するミドルウェアサービスのサポートを提供する。更なる移動電話の高度化は、デバイス設定の複雑性が増大すること、ソフトウェアエラーの確率が増大すること、及び既存のソフトウェアを実行時に向上する必要があることを意味する。例えば、移動電話は、ディジタルカメラを備え、写真の伝送をサポートし（ＭＭＳとして知られる）、インターネット接続をサポートすることがある。インターネット接続によって、Ｗｅｂ及びＷＡＰベージのブラウズ、ｅメールのダウンロード及び送信、及びインターネット上で実行しているサービスのアクセスが可能になる。しかしながら、これらのサービスを使用する前に、ユーザは自身の端末を設定しなければならない。この設定タスクは、通常は、退屈で間違えやすいプロセスであり、顧客サポートセンターを呼び出して多くの命令に従うことを伴う。その中には、パラメータ、例えば、ホスト名、ＩＰアドレス、ユーザ名、及びパスワードを入力することが含まれる。
【０００６】
[0006]更に、ソフトウェアプラットフォームが大きくなるにつれて、ソフトウェアエラーの確率も大きくなる。最近の研究によれば、移動電話の１０％は、ソフトウェアの問題のために返却される。これは、世界中で１２億を超える加入者が存在する状況では、１億２千万を超える電話が毎年返却されることを意味する。即ち、１億２千万のユーザが顧客サポートセンターへデバイスを持って行き、電話を更新しなければならない。これはキャリヤにとっては非常な費用のかかるものであり、移動電話のユーザには煩わしいものである。
【０００７】
[0007]更に、ソフトウェアのベンダは、既存のモバイルソフトウェアの新しい機能を定期的に提供する。例えば、既存のメールクライアントが追加の添付ファイルをサポートし、ウェブブラウザがスクリプトを操作する追加機能を提供することがある。この場合においても、ソフトウェアを更新するために電話を顧客サポートセンターへ持参するように移動電話のユーザへ要求することは、ユーザにとって不便である。
【０００８】
[0008]これらの問題の幾つかに対処する解決法が存在する。例えば、幾つかの既存の製品は、移動電話のファームウェアを実行時に更新する機能を提供する。この既存の製品は、既存のファームウェアのイメージを新しいファームウェアのイメージと比較し、二つのイメージのバイナリ差を算定し、算定した差で既存のイメージを更新する。しかしながら、このアプローチは、更新を実現するためにユーザの介入を必要とし、ソフトウェアイメージの全体を置換できるだけであり（あるロジック又は構造特性ではなく）、システムが停止されたときに更新を実行できるだけである。
【０００９】
[0009]プロセスを実行時に置換する例示的な手法は、米国特許第４，９５４，９４１号に説明されている。この手法は、信号伝達メカニズムを使用してプロセスを登録することを伴う。信号伝達メカニズムが信号を生成するときに、関連のプロセスが、それ自身を、更新されたバイナリイメージで置換することができる。しかし、米国特許第４，９５４，９４１号に記載の手法は、プロセスの個々の断片の置換を認めておらず、処理されているデータの破損をもたらすことがあり、動的なソフトウェア編成をサポートすることができない。更に、上記の手法は、ソフトウェアアプリケーションの状態、構造、及びロジックを管理するメカニズムを欠いている。
【００１０】
[0010]米国特許第５，１５５，８４７号は、クライアントデバイスの集合に常駐するソフトウェアを置換する例示的手法を説明している。ソフトウェアは、アップデートを記憶しており異なるクライアントデバイス用のパッチを生成する中央ホストを使用して更新される。クライアントエージェントが、ホストへ接続し、最新のパッチを検索し、これらパッチを関連のクライアントデバイスにインストールする。しかしながら、米国特許第５，１５５，８４７号に記載の手法は、影響を受けるアプリケーションが更新プロセス中に停止されることを必要とする。更に、この手法は、遠隔状態設定、動的ソフトウェア編成、並びに、システムの構造及びロジックの検査及び変更をサポートすることができない。
【００１１】
[0011]米国特許第５，９９５，７４５号は、汎用オペレーティングシステムがアプリケーションのリアルタイム要件をサポートすることを可能にする手法を開示している。このシステムは二つの問題、即ち、（１）アプリケーションのリアルタイム要件（例えば、アプリケーションの実行時間）を指定する方法、また、（２）負荷が大きい状況で、システムがリアルタイム保証を提供できない場合に成すべきこと、について取り組んでいない。
【００１２】
[0012]米国特許出願第２００２００７８１２１  Ａ１号は、パフォーマンスカウンタを使用し、中央処理ユニット（ＣＰＵ）のリソースを割り振ることによって、リアルタイムＣＰＵスケジューリングを実行する方法を開示している。より詳細には、説明されているスケジューラは、ＣＰＵリソースのみを考慮し、ＣＰＵを静的リソースとして取り扱い、ＣＰＵリソースの量が時間と共に変化しないようにする。第２に、スケジューラはＣＰＵをスレッドへ割り振る。
【００１３】
[0013]米国特許第５，８２６，０８０号は、従属性のあるタスク用のスケジューリング方法であって、タスクをレイヤにグループ分けし、レイヤごとにタスクを実行することによる方法を説明している。当該特許において説明されているスケジューリング方法には、二つの欠点がある。第１に、この方法は、個々のタスク及びタスクレイヤのリソース要求をどのようにして指定するかに関する問題に対処していない。第２に、この方法は、リソースの利用可能性の変動に応答して、タスクレイヤ（又はタスク）を動的に変更しない。
【発明の概要】
【００１４】
ソフトリアルタイム動作をサポートする方法及び装置について説明する。ある実施形態では、複数のアプリケーションコンポーネント、及び複数のアプリケーションコンポーネントの間の対話規則を指定する情報を取得するローダと、ソフトウェアロジックデータに基づき複数のアプリケーションコンポーネントの呼び出しを調整してソフトリアルタイム保証を実行時に提供するように実行するスケジューラとが、達成される。
【００１５】
[0014]本発明の他の特徴は、添付の図面及び下記の詳細な説明から明らかになる。
【００１６】
[0015]本発明は、下記の詳細な説明から、また、本発明の種々の実施形態の添付の図面から、より完全に理解されるであろう。しかし、これらの実施形態は、本発明を特定の実施形態へ限定するように解釈されるべきものではなく、単なる説明及び理解を目的とするものである。
【発明の詳細な説明】
【００１７】
[0060]ソフトウェアのソフトリアルタイム動作をサポートする方法及び装置について説明する。ある実施形態では、ソフトウェアが複数のマイクロビルディングブロック（ＭＢＢ）から編成される。
【００１８】
[0061]下記の説明では、多数の詳細について述べる。しかしながら、本発明は、これらの特定の詳細がなくとも実施され得ることが、当業者に明らかであろう。他の場合には、周知の構造及びデバイスを、本発明が不明瞭になることを避けるために、詳細に示すことなく、ブロック図で示す。
【００１９】
[0062]下記の詳細な説明の幾つかの部分は、コンピュータメモリにおけるデータビットへの演算アルゴリズム及び記号表現として呈示する。これらのアルゴリズムの記述及び表現は、研究の実体を他の当業者へ最も効果的に伝達するためにデータ処理技術の当業者によって使用される手段である。アルゴリズムとは、本明細書において、また、一般的に、所望の結果へ導くステップの首尾一貫したシーケンスであると考えられる。ステップは、物理量の物理的操作を必要とするステップである。通常、必ずというわけではないが、これらの量は、記憶、転送、結合、比較、及びその他の方法で操作可能な電気又は磁気信号の形態を取る。ときには、主に一般的に使用されていることを理由として、これらの信号をビット、値、要素、記号、文字、項、数等として参照することが便利であることがわかっている。
【００２０】
[0063]しかしながら、これら及び類似の用語の全ては、適切な物理量に関連付けられ、これらの量へ適用される便利なラベルにすぎないことに留意すべきである。下記の説明から明らかであるように、特に他の方法で記述しない限り、説明の全体を通して、「処理」又は「計算」又は「算定」又は「決定」又は「表示」等の用語を使用する説明は、コンピュータシステム又は類似の電子計算デバイスのアクション及びプロセスを意味し、コンピュータシステムのレジスタ及びメモリの中の物理（電子）量として表されたデータを操作し、コンピュータシステムのメモリ又はレジスタ又は他のそのような情報記憶装置、伝送又は表示デバイス中の物理量として同じように表される他のデータへ変換することを指す。
【００２１】
[0064]本発明は、更に、本明細書に説明するオペレーションを実行する装置に関するものである。この装置は、要求された目的のために特別に構築されてもよく、又はコンピュータ中に記憶されたコンピュータプログラムによって選択的に稼動され又は再構成される汎用コンピュータであってもよい。このようなコンピュータプログラムは、コンピュータ読み取り可能記憶媒体、例えば、これらに限定されないが、フロッピーディスク、光ディスク、ＣＤ−ＲＯＭ、及び磁気光ディスクを含む任意のタイプのディスク、読み出し専用メモリ（ＲＯＭ）、ランダムアクセスメモリ（ＲＡＭ）、ＥＰＲＯＭ、ＥＥＰＲＯＭ、磁気又は光学カード、又は電子命令を記憶するのに適した任意のタイプの媒体中に記憶されてもよい。これらの各々はコンピュータシステムバスへ結合される。
【００２２】
[0065]本明細書に提供するアルゴリズム及び表示は、特定のコンピュータ又は他の装置に固有に関連するものではない。様々な汎用システムが、本明細書の教示に従ったプログラムと共に使用されてもよく、又は、より特化した装置を構築して、所要の方法ステップを実行することが便利なこともある。様々なこれらシステムに要求される構造は、下記の説明から明らかになるであろう。更に、本発明は、特定のプログラミング言語を参照しては説明していない。様々なプログラミング言語を使用して、本明細書で説明する発明の教示を実現することができることが理解されるであろう。
【００２３】
[0066]機械読み取り可能媒体は、機械（又はコンピュータ）で読み取ることのできる形式で情報を記憶又は伝送する任意のメカニズムを含むものであり、例えば、機械読み取り可能な媒体は、読み出し専用メモリ（「ＲＯＭ」）、ランダムアクセスメモリ（「ＲＡＭ」）、磁気ディスク記憶媒体、光学記憶媒体、フラッシュメモリデバイス、電気、光、音響、又は他の伝搬信号の形態（例えば、搬送波、赤外線信号、ディジタル信号など）を含む。
【００２４】
＜概説＞
[0067]前述したソフトリアルタイム動作をサポートする手法を説明する前に、実行時にソフトウェアをアセンブルし、再設定し、移行し、順応させるメカニズムを以下に説明する。図１は、再設定可能なソフトウェアの動的構築を容易にするシステム１００の一実施形態のブロック図である。
【００２５】
[0068]以下、図１を参照する。システム１００は、ネットワークサーバ１０６、ネットワーク１０２、及びネットワーク１０２を介してネットワークサーバ１０６へ結合されたクライアントデバイス１０４を備えている。クライアントデバイス１０４は、対話式通信デバイスである。ある実施形態では、ネットワーク１０２は無線ネットワークであり、クライアントデバイス１０４は移動デバイス、例えば、無線電話、パームサイズ計算デバイス、ＰＤＡ、又はインターネット対応機器遠隔コントローラである。かかる通信デバイスは、無線ネットワーク１０２を介して、ネットワークサーバ１０６と通信し、相互に無線で通信することができる。別の実施形態では、ネットワーク１０２は非無線ネットワーク（例えば、インターネット）であり、クライアントデバイス１０４は非無線デバイス、例えば、ＰＣシステム、ＰＤＡ、コンシューマ電子デバイスなどである。当技術分野で知られた広範な通信手法を使用して、クライアントデバイス１０４とネットワークサーバ１０６との間で通信を行わせることができる。
【００２６】
[0069]ソフトウェア構築システム１０８は、任意のクライアントデバイス１０４に存在することができる。また、ソフトウェア構築システムは、ネットワークサーバ１０６に存在することができる。ソフトウェア構築システム１０８は、クライアントデバイス１０４又はネットワークサーバ１０６のユーザによって、若しくは、別のシステム又はデバイスによって要求された機能のために、ソフトウェア（例えば、アプリケーション又はサービス）を編成することを担っている。ソフトウェア構築システム１０８は、要求された機能を実現するアプリケーションコンポーネントの集合を特定するソフトウェア構造データを取得し、アプリケーションコンポーネント間の対話規則を示すソフトウェアロジックデータを取得し、ソフトウェア構造データ及びソフトウェアロジックデータを記憶領域に記憶し、ソフトウェアロジックデータを使用して、ソフトウェア構造データによって指定されたアプリケーションコンポーネントの呼び出しを調整することによってソフトウェアを編成する。
【００２７】
[0070]ある実施形態では、アプリケーションコンポーネント（本明細書ではマイクロビルディングブロック又はＭＢＢとも呼ばれる）は、システム内で最小のアドレス指定可能な機能ユニットである。各ＭＢＢは、入力パラメータの集合を受け取り、その状態に影響を与えるアクションを実行し、出力パラメータの集合を生成する。ある実施形態では、ＭＢＢは他のＭＢＢへの参照情報を記憶しない。故に、ＭＢＢが新しいＭＢＢと置換される場合には、他のＭＢＢは置換に関して通知される必要がない。
【００２８】
[0071]指定された記憶領域に、ソフトウェア構造の全てのコンポーネントに関する情報、及びこれらコンポーネント間の対話規則に関する情報を、保持することによって、ソフトウェア構築システム１０８は、編成されたソフトウェアの構造及びロジックを明示的に外部化する。また、ある実施形態では、ソフトウェア構築システム１０８は、個々のコンポーネントの内部状態属性、内部ソフトウェア実行状態（現在実行しているコンポーネントの状態）、及びソフトウェアの実行に要求される設定パラメータ（例えば、ユーザ選好及び実行ディレクトリ）を記憶領域に保持することによって、編成されたソフトウェアの状態を明示的に外部化する。
【００２９】
[0072]ソフトウェア状態の明示的外部化によって、ソフトウェアの設定機能がサポートされる（即ち、ソフトウェアの内部状態を変更する能力が提供される）。例えば、顧客サポート係員は、ユーザの移動電話に接続してソフトウェアパラメータを変更し、ユーザの介入なしに遠隔から移動電話を設定することができる。設定機能の他の例には、遠隔オブジェクトへの参照情報、バッファサイズ、及びネットワークパラメータの変更がある。ソフトウェア状態の明示的外部化によって、実行時におけるソフトウェア状態の検査が可能になる。この情報を使用して、ユーザがアプリケーションにアクセスしている間に、ソフトウェアを設定することが可能である。
【００３０】
[0073]ある実施形態では、ソフトウェア構築システム１０８はユーザインタフェースを提供して、指定された人がソフトウェア状態をブラウズし、所望の変更を指定できるようにする。
【００３１】
[0074]また、ソフトウェア状態、ロジック、及び構造の外部化によって、ソフトウェアの更新機能がサポートされる（即ち、特定のコンポーネントを置換するか、ソフトウェアの実行ロジックを変更することによって、ソフトウェアの動作を訂正又は改善できるようにする）。特に、状態の外部化によって、システム内の或るパラメータの値（例えば、バッファサイズ）を変更して、間違った動作を訂正することが可能になる。構造の外部化によって、実行時にソフトウェアコンポーネントを置換することが可能となり、ロジックの外部化によって、ソフトウェアコンポーネント間の対話規則を変更する機能が提供される。したがって、システムを再起動する必要なしに、ソフトウェアを更新することができる。これは、任意のタイプのメモリ（例えば、電気的メモリ、磁気メモリ、光メモリなど）を使用するシステムに当てはまる。
【００３２】
[0075]ある実施形態では、ソフトウェア構築システム１０８によって提供されたユーザインタフェースによって、ユーザが、アプリケーションコンポーネントのリスト、アプリケーションコンポーネント間の対話規則、及びソフトウェア状態を観察して、このデータの任意の断片へ所望の変更を指定することが可能となる。
【００３３】
[0076]更に、ソフトウェアのロジック、構造、及び状態の明示的外部化によって、ソフトウェアの自動アップグレードがサポートされる。即ち、アプリケーションロジックは、明示的に外部化されたロジックにアクセスし、（例えば、ユーザインタフェースを介して）変更を導入することによって変更することができる。こうして、ランタイムインフラストラクチャは、新しいロジック規則を更新し、それによってソフトウェアの動作を変更することができる。また、ソフトウェアコンポーネントを、明示的に外部化されたソフトウェア構造を更新し、ソフトウェアのロジックを変更して、削除されたコンポーネントをもはや使用しないように新しいコンポーネント用の新しい対話規則を付加するか、既存の対話規則を編集することによって、変更又は除去することができる。
【００３４】
＜ソフトウェアの動的構築＞
[0077]図２Ａは、ソフトウェアを動的に構築するプロセス２００の一実施形態の流れ図である。プロセスは、処理ロジックによって実行されてもよく、当該処理ロジックは、ハードウェア（例えば、回路、専用ロジック、プログラム可能ロジック、マイクロコードなど）、ソフトウェア（例えば、汎用コンピュータシステム又は専用機械で動作するもの）、又は双方の組み合わせであってもよい。処理ロジックは、ファームウェアであってもよい。ある実施形態では、プロセス２００は、図１のソフトウェア構築システム１０８によって実行される。
【００３５】
[0078]以下、図２Ａを参照する。処理ロジックは、要求された機能に関連するアプリケーションコンポーネントの集合を特定するソフトウェア構造の定義を受け取ることで開始する（処理ブロック２０２）。ある実施形態では、ソフトウェア構造の定義はＸＭＬで提供される。或いは、ソフトウェア構造の定義は、種々の他のコンピュータ言語（例えば、Ｊａｖａ、ＨＴＭＬ、Ｃ＋＋など）で提供されてもよい。ある実施形態では、アプリケーションコンポーネントはユーザによって選択される。或いは、アプリケーションコンポーネントは、所望の機能に従って処理ロジック、又は別のシステムによって選択される。ある実施形態では、アプリケーションコンポーネント（又はＭＢＢ）は、システム内で最小のアドレス指定可能な機能ユニットである。ＭＢＢの例示的構造については、図３Ａ及び図３Ｂと共に以下により詳細に説明する。
【００３６】
[0079]処理ブロック２０４において、処理ロジックは、アプリケーションコンポーネント間の対話規則を示すソフトウェアロジックの定義を受け取る。ある実施形態では、ソフトウェアロジックの定義はＸＭＬで提供される。或いは、ソフトウェア構造の定義は、様々な他のコンピュータ言語（例えば、Ｊａｖａ、ＨＴＭＬ、Ｃ＋＋など）で提供されてもよい。ある実施形態では、ソフトウェアロジックは、ＭＢＢの実行順序を指定するアクションによって定義される。ある実施形態では、ＭＢＢの実行順序はインタプリタ型アクションによって指定される。或いは、ＭＢＢの実行順序はコンパイル型アクションによって指定される。インタプリタ型アクションは決定論的有向グラフ（各々のノードから一つだけの遷移が可能）であり、当該グラフでは、ノードが実行状態を示すＭＢＢであり、辺が遷移順序を定義する。コンパイル型アクションは、ＭＢＢ呼び出し順序を指定するコード断片である。アクションについては、図４Ａ〜図４Ｃと共に、以下により詳細に説明する。
【００３７】
[0080]次に、処理ロジックは、列挙されたＭＢＢの各々を特定する情報をソフトウェア構造の定義から抽出し（処理ブロック２０６）、ある実施形態では、この情報を使用して各ローカルＭＢＢをインスタンス化する（処理ブロック２０８）。ローカルＭＢＢは、ソフトウェア構築システム１０８と同じデバイスに存在するＭＢＢである。
【００３８】
[0081]処理ブロック２１０において、処理ロジックはＭＢＢデータを記憶領域に記憶する。ある実施形態では、ＭＢＢデータは、ＭＢＢ識別子（例えば、ＭＢＢ名）及びＭＢＢ参照情報（ローカル又はリモート）をＭＢＢ毎に含む。ある実施形態では、「ドメイン」との概念を、記憶領域内の関連するＭＢＢの集合を示すために使用し、ＭＢＢデータで特定された各ＭＢＢは、ドメイン内に登録される（即ち、一意的な名前を割り当てられる）。この実施形態では、ローカルオブジェクトは、現在のドメイン内に存在するオブジェクトである。ドメインについては、図５Ａ〜図５Ｄと共に、以下により詳細に説明する。
【００３９】
[0082]次に、処理ロジックは、列挙されたアクションを特定する情報をソフトウェアロジックの定義から抽出し（処理ブロック２１２）、ある実施形態では、この情報を使用して、各ローカルアクションに対するアクションオブジェクトの集合をインスタンス化する（処理ブロック２１４）。ある実施形態では、アクションオブジェクトは有向ブラフを記憶する。この有向グラフでは、ノードがＭＢＢを表し、辺が遷移順序を定義する。ある実施形態では、各々のアクションが、アクション状態オブジェクトに実行時に関連付けられる。アクションは、以下により詳細に説明するように、このオブジェクトを使用して入力及び出力パラメータを記憶する。
【００４０】
[0083]処理ブロック２１６において、処理ロジックはアクションデータを記憶領域に記憶する。ある実施形態では、記憶データは、アクションオブジェクト識別子（例えば、名前）及びアクションオブジェクト参照情報（ローカル及びリモート）をＭＢＢ毎に含む。ある実施形態では、アクションデータで特定された各々のアクションがドメイン内に登録される。
【００４１】
[0084]ある実施形態では、処理ロジックはまた、各々のＭＢＢの内部属性を特定する情報を抽出し（処理ブロック２１８）、この情報を記憶領域に記憶する（処理ブロック２２０）。ある実施形態では、ＭＢＢ属性情報は、各ＭＢＢの処理ロジックよって受け取られた関連のＭＢＢの定義から抽出される。或いは、この情報は、処理ブロック２０２で受け取られたソフトウェア構造の定義から抽出される。ある実施形態では、ＭＢＢ属性情報は、全てのＭＢＢについて各ＭＢＢの識別子及び値を含む。また、ＭＢＢ属性情報は、各ＭＢＢの入力及び出力パラメータを特定する。ある実施形態では、ＭＢＢ属性情報で特定された各々の属性はドメイン内に登録される。
【００４２】
[0085]処理ブロック２２２において、図６と共に以下により詳細に説明するように、処理ロジックは、ソフトウェアロジックに基づいて、列挙されたＭＢＢの呼び出しを調整する。
【００４３】
[0086]図２Ｂは、ソフトウェア構築システム２５０の一実施形態のブロック図である。ある実施形態では、ソフトウェア構築システムは、ローダ２５２、スケジューラ２５４、及びデータ記憶装置２６０を備えている。
【００４４】
[0087]ローダ２５２は、要求された機能を実現するＭＢＢの集合を特定するデータ（ＭＢＢデータ）、これらのＭＢＢ間の対話規則を特定するデータ（ロジックデータ）、及び各ＭＢＢの状態属性を特定するデータ（状態データ）を取得することを担っている。ある実施形態では、ローダ２５２は、ソフトウェア構造の定義、ソフトウェアロジックの定義、及び各々の関連のＭＢＢの定義を解析することによって、このデータの集合を取得する。これらの定義は、ソフトウェア構築システム２５０へ、同じデバイス（例えば、同じ移動デバイス）で動作している異なるアプリケーションから、若しくは、サーバ又は別のデバイス（例えば、他の移動デバイス）から、ダウンロードされてもよい。他の実施形態では、ソフトウェア構造の定義が各ＭＢＢについての状態情報を含み、ＭＢＢの定義は使用されない。
【００４５】
[0088]ある実施形態では、ローダ２５２はまた、取得されたデータの集合に基づいてローカルＭＢＢ及びアクションオブジェクトをインスタンス化し、ＭＢＢデータ、ロジックデータ、及び状態データをデータ記憶装置２６０に記憶することを担っている。ある実施形態では、図５Ａと共に以下により詳細に説明されるように、データ記憶装置２６０は、構造メモリ、論理メモリ、及び状態メモリを有するドメインを表す。ある実施形態では、データはデータ記憶装置２６０に名前及び値のタプルの形式で記憶される。具体的には、ＭＢＢデータはＭＢＢ名／ＭＢＢ参照のタプルを含み、ロジックデータはアクション名／アクション参照情報のタプルを含み、状態データは属性名／属性値のタプルを含む。
【００４６】
[0089]スケジューラ２５４は、ロジックデータに基づいてＭＢＢの呼び出しを調整することを担っている。ある実施形態では、スケジューラ２５４はまた、編成されたソフトウェアの実行状態に関する情報を保持及びエクスポートすることを担っている。この情報は、例えば、現在実行されているアクション、現在実行されているアクションのＭＢＢ、及びそのアクションに関連するパラメータ（例えば、アクションの入力パラメータ及びアクションのＭＢＢによって生成されたパラメータ）を指定する。スケジューラの一実施形態については、以下により詳細に説明する。
【００４７】
[0090]ある実施形態では、スケジューラ２５４はＭＢＢとして実現される。その結果、スケジューラ２５４の状態はアクセス可能であり、他のＭＢＢと同じく実行時に変更可能である。スケジューラ２５４を置換できることによって、開発者が異なる実行セマンティックスを提供することが可能となる。例えば、開発者はトランスペアレントなローカル又はリモートのＭＢＢ呼び出しをサポートするスケジューラを選択し、それによってランタイムのソフトウェア分割を単純化することができる。また、開発者は全てのＭＢＢの後のパラメータ及び状態をチェックポイントするスケジューラを選択し、それによってフォルトトレラントのセマンティクスを提供することができる。更に、開発者は、アクション実行境界を定義し、且つ、アクション実行時間の保証を提供するリアルタイムスケジューラを選択することができる。動的なソフトウェア置換能力と組み合わせて特定のスケジューラを選択できることで、実行条件及び外部要件に従って実行モデルを変更することのできる適応型ソフトウェアの構築が単純化される。
【００４８】
[0091]ある実施形態では、ソフトウェア構築システム２５０はまた、ユーザインタフェースマネージャ２５６及び変更調整器２５８を備えている。ユーザインタフェースマネージャ２５６は、関連のユーザインタフェースを提供し、ユーザインタフェースを介してユーザ入力を受け取ることを担っている。ユーザインタフェースは、ユーザが利用できるアプリケーションのリスト、及び各アプリケーションについてのコンポーネントのリストを指定してもよい。ユーザは、このユーザインタフェースを使用してアプリケーションコンポーネントを選択し、アプリケーションコンポーネントを異なるデバイスへ移動するように要求してもよい。ユーザインタフェースはまた、アプリケーション分割スキームのリストを指定し、ユーザが一つのスキームを選択してアプリケーションを迅速にカスタマイズすることを可能にしてもよい。ユーザインタフェースはまた、ユーザがソフトウェア状態をブラウズし、ソフトウェアを再構成するために所望の変更を指定することを可能にしてもよい。また、ユーザインタフェースは、ユーザがアプリケーションコンポーネント、アプリケーションコンポーネント間の対話規則、及びソフトウェア状態を観察し、ソフトウェアを更新するためにこのデータの任意の断片への所望の変更を指定することを可能としてもよい。更に、ユーザインタフェースは、ユーザがソフトウェアをアップグレードするためにソフトウェアロジック又はアプリケーションコンポーネントへの変更を要求することを可能としてもよい。
【００４９】
[0092]変更調整器２５８は、ソフトウェアの再設定、ソフトウェアの更新、又はソフトウェアのアップグレードの要求を処理し、このような要求に応答してデータ記憶装置２６０内の関連情報を変更することを担っている。ある実施形態では、変更調整器２５８は、スケジューラ２５４と協働して変更を実現する。例えば、変更調整器２５８は、スケジューラ２５４に要求して、変更を要求されたコンポーネントについて安全なコンポーネント交換状態を決定し、データ記憶装置２６０中のコンポーネントを変更してもよい。
【００５０】
[0093]したがって、ソフトウェア構築システム２５０は、ソフトウェアを実行時にアセンブルし、そのロジック、構造、及び状態の実行中での変更をサポートする。具体的には、明示的な実行状態の外部化によってソフトウェア構築システム２５０に詳細な情報を提供し、その詳細な情報を活用して、開発者からのサポートなしに、安全なコンポーネント交換状態を算定することが可能である。ソフトウェア構築システム２５０は、コンポーネントの呼び出しを制御し、したがって変更をいつ導入するのが安全であるかを知っている。また、明示的なソフトウェア状態の外部化によって、状態転送の要件が削除される。新しいコンポーネントが挿入されると、この新しいコンポーネントは前のコンポーネント状態へ自動的に接続される。更に、コンポーネントは他のコンポーネントへの参照情報を記憶しないので、コンポーネントの参照情報を更新する必要性がない。同様に、アプリケーションコンポーネントは、参照情報ではなく名前によってアドレスされるので、コンポーネントはソフトウェアへの変更によって影響を受けない。
【００５１】
[0094]ここで、図３Ａ〜図３Ｃを参照して、アプリケーションコンポーネント又はＭＢＢを更に詳細に説明する。
【００５２】
[0095]図３Ａは、ＭＢＢ３００の例示のオペレーションを示している。ＭＢＢ３００は、入力パラメータ３０２を受け取り、その内部状態パラメータ３０４に影響を与えるアクションを実行し、出力パラメータ３０６を生成する。
【００５３】
[0096]図３Ｂは、ＭＢＢ３２０の構造の一実施形態のブロック図である。図３Ｂを参照すると、ＭＢＢ３２０は、一以上のメソッド３２４の集合、ゼロ個以上の属性３２２の集合、及びデマルチプレクサ３２６から構成されるエンティティである。メソッド３２４は、タスクを実施するアルゴリズムである。メソッド３２４は、ゼロ個以上の入力値の集合を要求し、ゼロ個以上の出力値の集合を生成する。ある実施形態では、デマルチプレクサ３２６はＭＢＢのエントリーポイントであり、入力パラメータ３２８を受け取り、対応するＭＢＢメソッド３２４を抽出する。ある実施形態では、各属性３２２は名前及び値のタプルである。値は変数であり、そのアルゴリズムを実施するためにメソッドによって要求される情報を記憶する。属性３２２は外部記憶領域に記憶され、名前によってアクセスすることができる。
【００５４】
[0097]ある実施形態では、全てのＭＢＢは、アプリケーションコンポーネントの定義内に記述される。この定義は、関連するＭＢＢについて、入力パラメータのリスト、出力パラメータのリスト、状態属性のリスト、及びＭＢＢを実施するエンティティ（例えば、Ｊａｖａのクラスファイル、．ＮＥＴオブジェクト、ＤＬＬなど）を指定するプラットフォーム依存フィールドを指定する。図３Ｃは、ＭＢＢ「ＲｅｇｉｓｔｅｒＯｂｊｅｃｔ」の例示のＸＭＬ記述ファイルを示しており、Ｃｌａｓｓタグは各プラットフォームの実装を表し、ｓｔａｔｅタグは各々の状態属性の名前及びタイプのタプルを指定し、ｉｎｐｕｔタグは名前及びタイプのタプルに関して入力パラメータを記述し、ｏｕｔｐｕｔタグは、ＭＢＢが名前及びタイプのタプルに関して生成するパラメータを表す。
【００５５】
[0098]次に、図４Ａ〜図４Ｃを参照して、アクションを更に詳細に説明する。
【００５６】
[0099]前述したように、アクションはＭＢＢの実行順序を指定し、したがってソフトウェアのロジックを定義する。アクションは、インタプリタ型アクション又はコンパイル型アクションであってもよい。インタプリタ型アクションは、決定論的有向グラフであって、ノードは実行状態を表すＭＢＢであり、辺は遷移順序を定義している。全ての辺は、関連する条件文を有し、当該条件文が実行時に評価されて次の遷移が決定される。条件文は、ＭＢＢによって生成されたパラメータ（出力パラメータ）を参照することができる。複数の出力辺を有するノードについては、辺の一つのみが実行時に真を評価することができる（決定論的グラフ）。デフォルト設定では、この条件文の値は真である。アクショングラフは、典型的には、一つの開始ノード、中間ノード、及び一つの終了ノードを有する。開始ノード及び終了ノード（終了ノードはアクショングラフが終わることを表す）は、全てのグラフ探索の一部となる。中間ノードは、辺へ割り当てられた条件文に従ったグラフ探索に依存する。アクショングラフは、エラーの場合の遷移を指定する追加のノード及び辺を含む。即ち、エラーが検出されなければ、システムはデフォルトのアクショングラフを使用する。しかし、実行エラーが検出されれば、システムはエラーのノード及び辺を使用する。例えば、各ノードは追加の辺を有してよく、この追加の辺は終了状態へ進んで、エラーが検出される場合に、アクションを終了させる。アクショングラフは、更に高度な動作を定義してもよい（例えば、「ｗｈｉｌｅ」、「ｆｏｒ」、及び「ｒｅｐｅａｔ」のようなループ命令文をサポートする）。インタプリタ型アクションの実行は、グラフの探索に対応する。
【００５７】
[00100]図４Ａは例示的なインタプリタ型アクションを示しており、ＭＢＢ１は開始ノードである。アクションはＭＢＢ１の呼び出しによって開始し、ＭＢＢ２の呼び出しに続き、次に「Ｘ」の値に応じてＭＢＢ３又はＭＢＢ４を呼び出し、最後にＭＢＢ５を呼び出す。変数「Ｘ」の値は、アクションを呼び出すクライアントによって提供されるか、ＭＢＢ１又はＭＢＢ２によって生成される出力パラメータである。この値はアクション実行状態の一部分として記憶される。このアクション実行状態については、以下により詳細に説明する。
【００５８】
[00101]インタプリタ型アクションは、現在の実行状態に関する情報をエクスポートすることによって、また、実行時のアクショングラフの変更をサポートすることによって、実行レベルでのリフレクションをもたらす。更に、明示的表現が、システムのロジックに関する推論を簡単にし、静的分析をサポートし、第三者が状態を付加又は除去してグラフを構成することによってシステムの動作を変更することを可能にする。
【００５９】
[00102]コンパイル型アクションは、ＭＢＢの呼び出し順序を指定するコード断片である。図４Ｂは、図４Ａで示したインタプリタ型アクションに対応する例示的なコンパイル型アクションを示している。
【００６０】
[00103]コンパイル型アクションは、指定されたライブラリを使用してＭＢＢを呼び出す。ある実施形態では、指定されたライブラリが、ＭＢＢ名及び入力タプルの集合を受け取り、指定されたＭＢＢを提供された入力パラメータを用いて呼び出す。このメカニズムによって、ソフトウェア構築システムはＭＢＢ呼び出しの制御を行なうことができ、ＭＢＢの安全な置換を可能にする。ある実施形態では、コンパイル型アクションは、ソフトウェア構築システムに登録されたＭＢＢとして提供される。したがって、アクションの呼び出しは、ＭＢＢの呼び出しに対応し、従って、ソフトウェア構築システムはアクション定義を実行時に置換することが可能となる。
【００６１】
[00104]図４Ｃは、例示のＸＭＬ記述ファイルを示しており、このファイルは、インタプリタ型アクション（左）及びコンパイル型アクション（右）である「ｅｘａｍｌｅＡｃｔｉｏｎ」の定義を提供している。
【００６２】
[00105]図４Ｃを参照すると、インタプリタ型アクションの場合、全ての状態は、名前、その状態で呼び出されるＭＢＢの名前、例外が起こら無い場合の次の状態、及び例外が起こる場合の次の状態を有する。条件付き遷移（例えば、状態２）の場合、条件文が各状態名に割り当てられている。エラー状態遷移のために条件付き遷移を使用することもできる。ある実施形態では、ＡｃｔｉｏｎＳｔａｔｅオブジェクトが各アクション用に作成され、アクション状態に関連付けられた情報、即ち、状態名、その状態で呼び出されるＭＢＢの名前、例外が起こらない場合の次の状態、及び例外が起こる場合の次の状態が記憶される。
【００６３】
[00106]コンパイル型アクションの記述は、アクションの名前、及びそのアクションを実現するＭＢＢを含んでいる。
【００６４】
[00107]インタプリタ型アクション及びコンパイル型アクションの双方が、ＭＢＢ置換をサポートする。特に、実行時のＭＢＢ置換を自動化する一つの大きな要件は、システムが安全なコンポーネント交換状態（即ち、ターゲットのコンポーネントが他のコンポーネントによって参照されない実行状態）に到達したことを検出し、交換されるコンポーネントが残りのコンポーネントによってアクセスされないようにすることである。インタプリタ型アクション及びコンパイル型アクションの双方において、安全なコンポーネント交換状態は自動的に決定される。インタプリタ型アクションの場合、インタプリタはＭＢＢを明示的に呼び出す。コンパイル型アクションは、指定されたライブラリを使用してＭＢＢを呼び出す。双方の場合に、システムが、呼び出しを制御しており、したがってＭＢＢを安全に置換することができる。
【００６５】
[00108]更に、インタプリタ型アクション及びコンパイル型アクションの両者は、ソフトウェアの更新機能及びアップグレード機能に貢献する。アクションの更新は、既存のアクションの置換に対応するか、インタプリタ型アクションの場合には、実行グラフの変更に対応する。システムのアップグレードは、新しいアクションの付加を意味するか、インタプリタ型アクションの場合には、アクショングラフを変更して状態を組み込むか変更することを意味する。
【００６６】
[00109]インタプリタ型アクションとコンパイル型アクションとの一つの差異は、実行時の操作の粒度である。コンパイル型アクションは、実行時に変更することができない。即ち、遷移状態を付加、除去、又は変更することはできない。コンパイル型アクションの動作の変更は、コンパイル型アクションの関連するＭＢＢの置換、即ち、アクションコードの置換を必要とする。更に、実行時にコンパイル型アクションを検査することはできず、したがって現在の実行状態を学習すること、又はアクションの動作を学習することはできない。インタプリタ型アクションの場合、グラフが、アクションの動作を学習するのに十分な情報を提供する。しかし、コンパイル型アクションは、インタプリタ型アクションよりも速く動作する。これは、コンパイル型アクションは、実行を駆動するためのインタプリタを必要としないためである。編成されるソフトウェアの必要な機能に応じて、ソフトウェア構築システムはインタプリタ型アクション又はコンパイル型アクションを使用することができる。
【００６７】
[00110]ここで、図５Ａ〜図５Ｃを参照して、ドメインを詳細に説明する。ドメインは、関連したＭＢＢの集合を統合する集約である。ドメインは、ドメインの構造（ＭＢＢのリスト）、ドメインのロジック（アクションのリスト）、及びドメインの状態（ＭＢＢの状態属性及び実行状態の値）を記憶する記憶領域を提供する。ドメインは階層的に編成可能であり、ＭＢＢの集合を単一のユニットとして操作（例えば、移動、一時停止、及び再開）することを容易にする。
【００６８】
[00111]図５Ａは、ドメイン５００の例示的構造を示す。
【００６９】
[00112]図５Ａを参照すると、ドメイン５００は、構造メモリ５０２、論理メモリ５０４、及び状態メモリ５０６を有する。各メモリは名前及び値のタプルを記憶する。構造メモリ５０２は、ドメインに登録されたＭＢＢに対応するタプルの集合を保持する。タプル名はＭＢＢの名前を指し（全てのＭＢＢは登録時に名前を割り当てられる）、値はＭＢＢへの参照情報を記憶する。参照情報は、ローカルポインタ又はリモートＭＢＢへのポインタであってもよい。ある実施形態では、ソフトウェア構築システムは、開発者にトランスペアレントなローカル又はリモートの呼び出しを行う。
【００７０】
[00113]論理メモリ５０４は、ドメインによってエクスポートされたアクションのリストを記憶する。構造メモリと同じく、論理メモリ５０４はアクションを名前で参照し、値はローカルポインタ又はリモート参照情報であってもよい。
【００７１】
[00114]状態メモリ５０６は、ドメインに登録されたＭＢＢについて状態属性を記憶する。状態メモリ５０６は属性を名前で参照し、値はその属性の値である。ＭＢＢの登録中に、システムは状態メモリ５０６へのポインタをＭＢＢに割り当てる。同じドメインに属するＭＢＢは、同じ状態メモリ５０６を共用する。
【００７２】
[00115]ドメインを階層的に編成して、ＭＢＢの大きな集合の構成を単純化することができる。ドメインメモリは、登録されたサブドメインのドメインメモリへの参照情報（名前及び値のタプル）を記憶し、また、ルートドメインメモリへの参照情報を記憶する。図５Ｂは、ドメインの例示的階層編成を示している。
【００７３】
[00116]図５Ｂを参照すると、ルートドメイン５２０は二つのサブドメイン（ドメイン５２２及び５２４２）を有しており、ドメイン５２２は三つのサブドメイン（ドメイン５２６、５２８、及び５３０）を有している。
【００７４】
[00117]ある実施形態では、デフォルトの可視性ポリシーは、ドメインがサブドメインメモリへアクセスできることを定めている。例えば、ルートドメイン５２０はシステムの全てのドメインメモリ（即ち、ドメイン５２２から５３０まで）へアクセスし、ドメイン５３０は自分のドメインメモリだけへアクセスする。この可視性ポリシーは、変更することが可能である（例えば、サブドメインに、それらの親又は兄弟（sibling）のドメインメモリへのアクセスを許す）。
【００７５】
[00118]ある実施形態では、ソフトウェアアーキテクチャの定義を使用して、ソフトウェア構築システムが保持するドメイン階層を記述する。図５Ｃは、ソフトウェアアーキテクチャの定義を提供する例示的なＸＭＬ記述ファイルを示す。
【００７６】
[00119]図５Ｃを参照すると、アーキテクチャ記述内の各々のドメインエントリは、二つの追加のファイル、即ち、構造及びロジックの記述を指し示している。これらはドメイン内に登録されたＭＢＢ及びアクションを指定する。ロジックの記述は、図４Ｃと共に前述した。構造の記述は、単一のドメインについてソフトウェア構造の定義を提供する。図５Ｄは、ドメインについてソフトウェア構造の定義を提供する例示的なＸＭＬ記述ファイルを示す。
【００７７】
[00120]図５Ｄを参照すると、構造の記述は、ドメインに属するＭＢＢのリストを提供している。この記述は、名前のリスト及びＭＢＢの記述を有している。ＭＢＢの記述は、関連のＭＢＢの定義を提供する文書である（例えば、図３Ｃに示したＭＢＢの記述）。ある実施形態では、ＭＢＢの記述は、関連のローカルＭＢＢをインスタンス化するために使用される。全てのＭＢＢは、＜名前、ＭＢＢ参照情報＞のタプルとしてドメイン構造メモリに登録される。ＭＢＢ名は、ＭＢＢにアクセスするためのキーとして使用される。
【００７８】
[00121]次に、アクションの実行について詳細に説明する。インタプリタ型アクションの実行はインタプリタに依存する。コンパイル型アクションの実行はＭＢＢの呼び出しに対応し、したがってインタプリタを必要としない。
【００７９】
[00122]インタプリタ型アクションはシステムのロジックを外部化し、ソフトウェアの機能面を実行するのに必要なＭＢＢ呼び出しシーケンスに関する情報を提供する。ある実施形態では、インタプリタ型アクションの実行は図２Ｂのスケジューラ２５４によって実施され、スケジューラ２５４は、アクションのデータをＭＢＢ呼び出しスケジュールとして使用し、編成されたソフトウェアの実行を駆動する。ある実施形態では、アクションのデータはＭＢＢの呼び出し順序を指定するアクション定義（例えば、決定論的有限状態オートマトン（ＤＦＳＡ））である。スケジューラは、ソフトウェアの実行状態に関する情報を保持及びエクスポートする。この情報は、例えば、現在実行されているアクション、現在実行されているアクションのＭＢＢ、及びそのアクションに関連するパラメータ（例えば、入力パラメータ及びアクションのＭＢＢによって生成されたパラメータ）を指定する。
【００８０】
[00123]ある実施形態では、各アクションは、アクション状態オブジェクトに関連付けられる。アクションは、このオブジェクトを使用して、アクションの実行に関連する入力及び出力パラメータを記憶する。パラメータは、アクションを呼び出すクライアントによって提供され、また、ＭＢＢによって、それらの呼び出しの結果として生成される。ＭＢＢは、アクション状態オブジェクトの中に記憶されたパラメータを使用して、それらのアルゴリズムを実現する。アクションの呼び出し中に生成されたパラメータを保存すること、及び状態属性へのＭＢＢアクセスを同期させることによって、クライアントがアクションを並行して呼び出すことが可能になる。
【００８１】
[00124]図６は、インタプリタ型アクションを実行するプロセスの一実施形態の流れ図である。プロセスは処理ロジックによって実行されてもよい。処理ロジックは、ハードウェア（例えば、回路、専用ロジック、プログラム可能ロジック、マイクロコードなど）、ソフトウェア（例えば、汎用コンピュータシステム又は専用機械上で動作するもの）、又は双方の組み合わせであってもよい。ある実施形態では、プロセス６００は、図２Ｂのスケジューラ２５４によって実行される。
【００８２】
[00125]以下、図６を参照する。処理ロジックは、アクションの実行要求を受け取ることから始まる（処理ブロック６０２）。要求はアクション状態オブジェクトを含み、アクション状態オブジェクトは入力パラメータを含む。
【００８３】
[00126]処理ブロック６０４において、処理ロジックは、アクション名をキーとして使用して、論理メモリ内の要求されたアクションのオブジェクトにアクセスする。
【００８４】
[00127]処理ブロック６０６において、処理ロジックは、アクションオブジェクトから最初のＭＢＢの名前を取得する。
【００８５】
[00128]次に、処理ロジックは、ＭＢＢ名をキーとして使用し、構造メモリから最初のＭＢＢへの参照情報を取得し（処理ブロック６０８）、このＭＢＢを呼び出して、それにアクション状態オブジェクトを入力パラメータとして渡す（処理ブロック６１０）。
【００８６】
[00129]更に、処理ロジックは、アクションオブジェクト内に更なるＭＢＢが存在するか否かを決定する（処理ボックス６１４）。存在するならば、処理ロジックは次のＭＢＢの名前をアクションオブジェクトから取得し（処理ブロック６１６）、処理ブロック６０８へ戻る。存在しなければ、処理ロジックは、出力パラメータを有するアクション状態オブジェクトを要求側へ戻す（処理ブロック６１８）。
【００８７】
[00130]図７は、インタプリタ型アクションの例示的実行を示す。アクションの名前は「ｅｘａｍｌｅＡｃｔｉｏｎ」であり、二つのＭＢＢから成る。説明を簡単にするため、アクションは条件付き遷移又はループを有しないものと仮定されている。
【００８８】
[00131]以下、図７を参照する。スケジューラは「ｅｘａｍｌｅＡｃｔｉｏｎ」と呼ばれるアクションの実行要求を受け取る。要求はアクション状態オブジェクトを含み、このアクション状態オブジェクトは二つのパラメータ、即ちａ及びｃを含む（ステップ１）。スケジューラは、アクション名を使用して論理メモリにアクセスし、アクショングラフの最初のノードへのポインタを取得する。スケジューラはアクショングラフのノードからＭＢＢの名前を取得し、その名前（ＭＢＢ１）を使用して構造メモリからＭＢＢを決定する。
【００８９】
[00132]ＭＢＢ１を決定した後、スケジューラはＭＢＢを呼び出して、アクション状態オブジェクトを渡す。ＭＢＢ１は、ａという名前の入力パラメータを必要とし、これはアクション状態オブジェクトから取得される。ＭＢＢ１はそのアルゴリズムを実行し、出力パラメータｂを生成する。これはアクション状態オブジェクトの中に記憶される（ステップ２）。
【００９０】
[00133]次に、スケジューラは、現在のアクショングラフのノードから次の状態の名前を取得し、そのＭＢＢの名前（ＭＢＢ２）を取得し、構造メモリからＭＢＢ２を決定する。スケジューラはパラメータとしてアクション状態オブジェクトを用いてＭＢＢ２を呼び出す。ＭＢＢ２は二つのパラメータｂ及びｃを必要とし、これらはアクション状態オブジェクトから取得される。ＭＢＢ２は、そのアルゴリズムを実行し、ｄと称する出力パラメータを生成し、そのパラメータをアクション状態オブジェクトの中に記憶する（ステップ３）。
【００９１】
[00134]最後に、スケジューラはアクション状態オブジェクトを要求側へ戻し、当該要求側は、アクションの実行中に生成された出力パラメータを検索することができる。
【００９２】
[00135]前述したアクション実行プロセスは、安全なソフトウェア再構成点を自動的に検出するために使用可能である。具体的には、ソフトウェアは、ＭＢＢの呼び出し間でのみ再設定可能である。ＭＢＢは、外部化された構造、ロジック、及び状態にアクセス及び変更することを認められている。したがって、これらのパラメータを変更することは、ＭＢＢの実行に影響を与え、首尾一貫しないソフトウェア状態を導くことがある。ソフトウェア構築システムは、ＭＢＢがその実行を完了するまで待機し、望ましくない結果を回避する。この動作は、インタプリタ型アクション及びコンパイル型アクションの双方に当てはまる。コンパイル型アクションは、指定されたライブラリを使用してＭＢＢを呼び出し、したがって再設定を実現する制御をシステムへ与える。
【００９３】
＜プロトコル＞
[00136]前述したように、本発明の幾つかの実施形態はドメインを使用して、実行時にソフトウェアの構築をサポートする。図８Ａは、ドメイン８００の一実施形態のブロック図である。
【００９４】
[00137]図８Ａを参照すると、ドメイン８００は、三つのサブコンポーネント、即ち、ドメインメモリ８０２、ドメインローダ８０４、及びドメインスケジューラ８０６を有している。ドメインメモリ８０２はタプルコンテナであり、このタプルコンテナは、エンティティによってホストされるＭＢＢの名前と参照情報、ＭＢＢの属性、及び一以上のアクションの集合を記憶する。
【００９５】
[00138]ドメインローダ８０４は、ＭＢＢを作成し、ＭＢＢを削除し、ＭＢＢのリストを提供し、アクションをロードし、アクションを削除し、アクションのリストを提供し、アクションを変更すること、並びに、ソフトウェア構造の記述、ＭＢＢの記述、及びソフトウェアロジックの記述を構文解析することを担っている。
【００９６】
[00139]ドメインスケジューラ８０６は、アクション定義（例えば、アクションのＤＦＳＡ）を構文解析し、アクション定義によって指定された順序でＭＢＢアクションを呼び出すことを担っている。
【００９７】
[00140]図８Ｂは、例示的なタプルコンテナを示す。タプルコンテナは、情報が名前及び値のペアとして記憶される記憶領域である。タプルコンテナは、情報タプルを記憶し、名前を探索キーとして使用して情報タプルを検索する機能を、提供する。
【００９８】
[00141]ある実施形態では、プロトコルの集合を使用してソフトウェアの動的編成が実行される。プロトコルの集合は、ドメイン初期化プロトコル、ＭＢＢ作成プロトコル、ＭＢＢ削除プロトコル、ＭＢＢリスティングプロトコル、ソフトウェア構造ローディングプロトコル、アクションローディングプロトコル、アクション削除プロトコル、アクションリスティングプロトコル、アクション変更プロトコル、ソフトウェアロジック構文解析プロトコル、ＭＢＢ呼び出しプロトコル、リモートＭＢＢ呼び出しプロトコル、及びアクション呼び出しプロトコルを含む。
【００９９】
[00142]図９は、ドメイン初期化プロトコルを示している。図９を参照すると、ドメインオブジェクトが作成されると、当該ドメインオブジェクトは、ドメインスケジューラ、ドメインメモリオブジェクト（タプルコンテナ）、及びドメインローダオブジェクトをインスタンス化する。次に、ドメインオブジェクトは、ドメインスケジューラをリモートオブジェクトとしてエクスポートし、アクションをドメイン内でリモートに呼び出すことを可能にする。
【０１００】
[00143]図１０は、ＭＢＢ作成プロトコルを示している。図１０を参照すると、ドメインローダは、マイクロビルディングブロックを作成及び初期化する機能を実現する。ある実施形態では、ドメインローダは、ＭＢＢ名及びＭＢＢクラス名を受け取るＣｒｅａｔｅＭＢＢと呼ばれるメソッドを実施する。このメソッドは、指定されたクラスのオブジェクトをインスタンス化し、ＭＢＢを初期化し、ＭＢＢの名前及びオブジェクトへの参照情報と共にドメインメモリの中にタプルを記憶する。更に、ＣｒｅａｔｅＭＢＢメソッドは、タプルの参照カウンタ値を０へ設定して、如何なるアクションにおいてもＭＢＢが使用されていないことを示す。
【０１０１】
[00144]図１１は、ＭＢＢ削除プロトコルを示す。図１１を参照すると、ドメインローダは、マイクロビルディングブロックを削除する機能を実現する。ある実施形態では、ドメインローダは、ＤｅｌｅｔｅＭＢＢと呼ばれるメソッドを実施する。このメソッドはＭＢＢ名を受け取り、ＭＢＢ参照カウンタをチェックし、参照カウンタが０に等しければＭＢＢを削除する。等しくなければ、ドメインローダはエラーメッセージを返却する。
【０１０２】
[00145]図１２は、ＭＢＢリスティングプロトコルを示す。図１２を参照すると、ドメインローダは、マイクロビルディングブロックを列挙する機能を実施する。ある実施形態では、ドメインローダはＬｉｓｔＭＢＢｓと呼ばれるメソッドを実施する。このメソッドはドメインメモリに記憶された全てのＭＢＢのリストを返却する。
【０１０３】
[00146]図１３はソフトウェア構造ローディングプロトコルを示す。図１３を参照すると、ソフトウェア構造のローディングは、指定されたソフトウェアに要求される全てのマイクロビルディングブロックを作成及び初期化することを意味する。ある実施形態では、プロトコルは、ドメインローダがソフトウェア構造の記述、及びこの記述をロードする要求を受け取ったときに開始する。ドメインローダは、この記述を構文解析し、当該記述中の各エントリに対して一つのＭＢＢを作成する。ＭＢＢを作成するために、ドメインローダはＭＢＢ作成プロトコルを利用する。
【０１０４】
[00147]図１４は、ソフトウェアアクションのローディングプロトコルを示す。図１４を参照すると、ドメインローダは、ソフトウェアアクションをロードするプロトコルを実施する。ある実施形態では、ドメインローダはソフトウェアロジックの記述を構文解析し、当該記述の中に含まれる各々の状態について、アクション状態情報オブジェクトを作成し、状態の名前及びアクション状態オブジェクトへの参照情報を含むタプルをドメインメモリに記憶する。更に、ドメインローダは、状態の中で参照された各ＭＢＢについて、ＭＢＢの参照カウンタを増加する。
【０１０５】
[00148]図１５は、アクション削除プロトコルを示す。図１５を参照すると、ドメインローダは、アクションを削除する機能を実施する。ある実施形態では、ドメインローダは、ＤｅｌｅｔｅＡｃｔｉｏｎと呼ばれるメソッドを実施する。このメソッドはアクションの名前を受け取り、ドメインメモリからそのアクションを検索し、関連する各ＭＢＢについて、参照カウンタを減少してＭＢＢを削除する。
【０１０６】
[00149]図１６は、アクションリスティングプロトコルを示す。図１６を参照すると、ドメインローダは、アクションを列挙する機能を実施する。ある実施形態では、ドメインローダは、ＬｉｓｔＡｃｔｉｏｎｓと呼ばれるメソッドを実施する。このメソッドは、ドメインメモリに記憶された全てのアクションのリストを返却する。
【０１０７】
[00150]図１７は、アクション変更プロトコルを示す。図１７を参照すると、ドメインローダはアクションを変更する機能を実施する。ある実施形態では、ドメインローダはＭｏｄｉｆｙＡｃｔｉｏｎと呼ばれるメソッドを実施する。このメソッドは、アクション状態の名前、及び新しい状態を含むオブジェクトを受け取る。このメソッドは、ドメインメモリからそのアクション状態を検索し、既存及び新しい状態のＭＢＢの名前を比較し、異なる場合には、ＭＢＢ参照カウンタを減少する。このメソッドはまた、状態情報を新しい状態情報で置換する。
【０１０８】
[00151]図１８は、ローカルＭＢＢ呼び出しプロトコルを示す。図１８を参照すると、プロトコルは、ローカルＭＢＢ、即ち、ドメインスケジューラと同じドメインに含まれるＭＢＢの呼び出し方法を指定する。ある実施形態では、プロトコルは、ｉｎｖｏｋｅＭＢＢメソッドで始まる。このメソッドは二つのパラメータを必要とする。即ち、ＭＢＢの名前とアクション状態オブジェクトである。ドメインローダは、ＭＢＢの名前を使用して、ドメインメモリからタプルを検索する。このタプルはＭＢＢへの参照情報を含む。次に、ドメインローダは、ＭＢＢを呼び出してアクション状態オブジェクトから必要なパラメータを抽出し、また、ドメインメモリから状態に対応する属性を抽出する。次に、アクションを実行した後、ＭＢＢは、変更した全ての属性でドメインメモリを更新し、出力パラメータをアクション状態オブジェクトの中に記憶し、アクション状態オブジェクトをドメインローダへ返却する。
【０１０９】
[00152]図１９は、リモートＭＢＢ呼び出しプロトコルを示す。図１９を参照すると、プロトコルは、リモートドメインに存在するＭＢＢを呼び出すためのサポートを行なう。この機能は、アクションの実行に影響を与えることなくＭＢＢの移行を簡単にする。ある実施形態では、ドメインスケジューラは、ＭＢＢがローカルであるかリモートであるかを自動的に検出して、適切なプロトコルを使用する。ある実施形態では、プロトコルは、ドメインローダがＭＢＢにおけるアクションを呼び出す要求を受け取ることから開始する。この要求は、二つのパラメータ、即ち、ＭＢＢの名前及びアクション状態オブジェクトを含む。ドメインローダは、ドメインメモリからＭＢＢ名を決定する。結果は、リモートＭＢＢへの参照情報である。ドメインローダは、アクションを呼び出して、リモートプロシージャコールを発行する。アクションの集合が、要求を送信及び受信するために提供される。これらのアクション及びそれらの関連のＭＢＢは、デフォルト設定でロードされる。アクションはＳｅｎｄＲｅｍｏｔｅＲｅｑｕｅｓｔと呼ばれるものであり、ＭＢＢの参照情報、名前、リモート呼び出し用のメソッド、及びアクション状態オブジェクトを必要とする。このアクションはリモート要求を発行し、更新されたアクション状態オブジェクトを受け取る。
【０１１０】
[00153]図２０は、ＭＢＢ置換プロトコルを示す。図２０を参照すると、プロトコルは、動作しているシステムを停止することなく、既存のＭＢＢを新しいＭＢＢで置換することを可能とする。ある実施形態では、プロトコルはＭＢＢを置換するコマンドで開始し、安全な再設定状態を待機して、新しいＭＢＢを作成する。新しいＭＢＢは同じタプル名を有するが、異なる実装クラスを有する。
【０１１１】
[00154]図２１は、アクション呼び出しプロトコルを示す。図２１を参照すると、アクション呼び出しプロトコルは、アクションを実行するのに必要な全てのステップを定義する。ステップの中には、ＤＦＳＡの構文解析、及び影響を受けるＭＢＢの呼び出しが含まれる。ある実施形態では、ドメインオブジェクトは、アクション呼び出しプロトコルを実施するメソッド（ｉｎｖｏｋｅＡｃｔｉｏｎ）をエクスポートする。このメソッドは、アクション名及びパラメータを、名前及び値のタプルの集合として受け取る。ドメインオブジェクトはアクション状態オブジェクトを作成し、パラメータタプル、及びアクションの名前をもつａｃｔｉｏｎＮａｍｅという名前のタプルを記憶する。次に、ｉｎｖｏｋｅＡｃｔｉｏｎメソッドは、ドメインスケジューラ上にプロセスメソッドを呼び出し、アクション状態オブジェクトを渡す。ドメインスケジューラは、アクション状態オブジェクトからａｃｔｉｏｎＮａｍｅタプルを決定し、その値を使用して最初のＤＦＳＡ状態情報オブジェクトを決定する。ドメインスケジューラは、ＤＦＳＡ状態に関連するＭＢＢの名前、及びＭＢＢ上で呼び出すアクションの名前を検索する。次に、ドメインスケジューラはＭＢＢアクション名をアクション状態オブジェクトの中に記憶し、ドメインローダのｉｎｖｏｋｅＭＢＢプロトコルを呼び出す。ＭＢＢ呼び出しプロトコルが終了するとき、ドメインスケジューラはアクション状態情報オブジェクトから次のアクション状態名を検索し（エラー状態の場合、ドメインスケジューラは次のエラー状態を検索する）、その名前を使用して、関連するアクション状態情報オブジェクトを決定し、ブロックＡに含まれる全てのステップを反復する。プロトコルは、最後のアクション状態に達するまで、ＭＢＢの呼び出しを維持する。最後のアクション状態に達した時点で、ドメインスケジューラは、更新されたアクション状態オブジェクトをドメインオブジェクトへ返却し、当該ドメインオブジェクトが更新されたアクション状態オブジェクトを要求側へ返却する。
【０１１２】
＜プログラムの再構成可能なソフトウェアへの変換＞
[00155]幾つかの実施形態では、従来の方法を使用して作成された既存のプログラムを、前述したように後に再設定、更新、又はアップグレードし得るソフトウェアへ変換可能である。ある実施形態では、変換を、一以上のタスクの集合として定義されるプログラムに適用することができる。タスクは、オブジェクト（例えば、Ｊａｖａオブジェクト）の集合から成り、オブジェクトのパブリック属性の共用体であるタスク状態、及び、呼び出し順序を定義するオブジェクト間の対話規則の集合を有する。
【０１１３】
[00156]図２２〜図２４は、プログラムを再設定可能なソフトウェアへ変換するプロセス２２００の一実施形態の流れ図である。プロセスは処理ロジックによって実行されてもよい。処理ロジックは、ハードウェア（例えば、回路、専用ロジック、プログラム可能ロジック、マイクロコードなど）、ソフトウェア（例えば、汎用コンピュータシステム又は専用機械の上で動作するもの）、又は双方の組み合わせを含んでもよい。ある実施形態では、プロセス２２００は図１のソフトウェア構築システム１０８によって実行される。
【０１１４】
[00157]図２２を参照すると、処理ロジックは、タスクの構造を外部化することから開始する（処理ブロック２２０２）。ある実施形態では、処理ロジックは、タスクの構造を、（ａ）各タスク、及びそのタスクに属する各オブジェクトについて、オブジェクトの名前及びオブジェクトへの参照情報を有するタプルを作成し、（ｂ）各々の作成されたタプルをドメインメモリに記憶し、（ｃ）プログラムＰに属する全てのオブジェクトの名前を有するリストを値として有するｓｏｆｔｗａｒｅＡｒｃｈｉｔｅｃｔｕｒｅという名前のタプルを作成し、（ｄ）ｓｏｆｔｗａｒｅＡｒｃｈｉｔｅｃｔｕｒｅというタプルをドメインメモリに記憶することによって、外部化する。
【０１１５】
[00158]処理ブロック２２０４において、処理ロジックはタスクの状態を外部化する。ある実施形態では、処理ロジックは、状態を、（ａ）タスク内の各オブジェクト、及びそのオブジェクト内の各パブリック属性について、タプルを作成し、ここでタプルの名前は属性の名前であり、値は変数の値への参照であり、（ｂ）各々の作成されたタプルをドメインメモリに記憶することによって、外部化する。
【０１１６】
[00159]処理ブロック２２０６において、処理ロジックはタスク内の各オブジェクトをＭＢＢへ変換する。タスク内のオブジェクトをＭＢＢへ変換するプロセスの一実施形態を、図２３と共に以下により詳細に説明する。
【０１１７】
[00160]処理ブロック２２０８において、処理ロジックはタスクのロジックを外部化する。タスクのロジックを外部化するプロセスの一実施形態を、図２４と共に以下により詳細に説明する。
【０１１８】
[00161]図２３Ａは、タスク内のオブジェクトをＭＢＢへ変換するプロセスの一実施形態の流れ図である。
【０１１９】
[00162]図２３Ａを参照すると、処理ロジックは、オブジェクトに関連付けられた全てのパブリックメソッドの名前を有するリストを作成することから開始する（処理ブロック２３０２）。パブリックメソッドは、オブジェクトの外側から（例えば、クライアントによって）呼び出すことができる関数である。
【０１２０】
[00163]処理ブロック２３０４において、処理ロジックは全てのパブリックメソッドをプライベートメソッドへ変換する。プライベートメソッドは、内部的に（例えば、そのオブジェクトの他のメソッドによって）呼び出し可能な関数である。
【０１２１】
[00164]処理ブロック２３０６において、処理ロジックはオブジェクトコードを変更して、属性が、ドメインメモリに記憶され、当該ドメインメモリにおいて名前及び値のタプルとしてアクセスされるようにする。
【０１２２】
[00165]処理ブロック２３０７において、処理ロジックは、タプルの名前及びリストを受け取るメソッドをオブジェクトコードへ付加し、プライベートメソッドのリストからプライベートメソッドの一つを呼び出す。
【０１２３】
[00166]図２３Ｂは、ＭＢＢを呼び出すプロセスの一実施形態の流れ図である。
【０１２４】
[00167]図２３Ｂを参照すると、処理ロジックは、アクション状態オブジェクトからアクション名（ａｃｔｉｏｎＮａｍｅ）値を抽出し、どのアクションがクライアントによって要求されているかを決定することから開始する（処理ブロック２３０７）。アクション状態オブジェクトは、アクションの実行中に要求及び生成された入力及び出力パラメータの集合を記憶する。ある実施形態では、入力及び出力パラメータはタプルとして記憶される。
【０１２５】
[00168]処理ブロック２３１０において、処理ロジックは、要求されたアクションの名前が、パブリックメソッドのリストの中に記憶されたメソッドの一つに対応するか否かを検証する。対応しなければ、処理ロジックは例外を引き起こす。
【０１２６】
[00169]処理ブロック２３１２において、処理ロジックは、アクションによって必要とされる入力パラメータをアクション状態オブジェクトから抽出する。
【０１２７】
[00170]処理ブロック２３１４において、処理ロジックは、抽出されたパラメータを使用して、ａｃｔｉｏｎＮａｍｅ値によって指定されたメソッドを呼び出す。
【０１２８】
[00171]次に、処理ロジックは、呼び出しによって生じた結果をアクション状態オブジェクトの中へ記憶し（処理ブロック２３１６）、アクション状態オブジェクトを返却する（処理ブロック２３１８）。
【０１２９】
[00172]図２４は、タスクのロジックを外部化するプロセスの一実施形態の流れ図である。
【０１３０】
[00173]図２４を参照すると、処理ロジックは、タスクの呼び出しフローを分析して有向グラフを生成することから開始する。有向グラフでは、ノードの名前が呼び出し番号に対応する（処理ブロック２４０２）。
【０１３１】
[00174]処理ブロック２４０４において、処理ロジックは、各グラフノードについて、その名前がグラフノードの名前であり、且つ、その値がノードに関する情報を記憶するオブジェクトであるタプルを作成することによって、有向グラフからＤＦＳＡを生成することで開始する。
【０１３２】
[00175]処理ブロック２４０６において、処理ロジックは上記のタプルをドメインメモリに記憶する。
【０１３３】
[00176]処理ブロック２４０８において、処理ロジックは、その名前がアクションの名前であり、且つ、その値が最初のグラフノードをもつ文字列である追加のタプルを記憶する。
【０１３４】
＜インデックスに基づくオブジェクトアクセス＞
[00177]図３Ａに示すように、ある実施形態では、ＭＢＢインフラストラクチャはハッシュテーブルを使用して情報を記憶及びアクセスする。これは開発者に便利である。なぜならば、開発者は名前によってオブジェクト又はパラメータに直接アクセスできるからである。別の実施形態では、ハッシュテーブルは、インデックスによってアクセスされるポインタ配列で置換される。こうして、マイクロビルディングブロック（ＭＢＢ）は、インデックスに基づくパラメータアクセス手法を使用して、様々なパラメータへのアクセスを可能にする。
【０１３５】
[00178]図２５は、本明細書で説明するパラメータアクセス手法を示す。本手法は、入力、出力、及び状態パラメータにアクセスするのに必要な時間を、整数インデックス配列、及び動的に生成されるインデックスの集合で、前述したハッシュテーブルを置換することによって、低減する。ある実施形態では、インフラストラクチャはＭＢＢ及び構造ＸＭＬ記述ファイルを使用してインデックスを自動的に生成し、パラメータ名とそれらの関連のインデックスとの間のマッピングを保持し、初期化中にＭＢＢ用のインデックスへ値を割り当てる機能をエクスポートする。
【０１３６】
[00179]図２６は、最適化機能を実現するビルディングブロックの集合の一実施形態のブロック図である。図２６を参照すると、ＭＢＢパラメータインデックス生成器２６０１が、ＭＢＢ  ＸＭＬ記述ファイルを構文解析し、パラメータへ関連付けられた一意のインデックスを生成する。ある実施形態では、各々の入力、出力、及び状態オブジェクトについてインデックスが存在する。
【０１３７】
[00180]ある実施形態では、インデックスは数値インデックスである。数値インデックスによって、メモリに記憶されたオブジェクトへ直接アクセスすることが可能になる。ＭＢＢラッパー生成器２６０２は、ＭＢＢ  ＸＭＬ記述を構文解析し、パラメータを表す定数のリスト、定数値を初期化するメソッド、及びＭＢＢによって実現されるアクションについて開発者が書き込む（ｆｉｌｌ  ｉｎ）空のメソッドを有するＭＢＢコードスケルトンを生成する。
【０１３８】
[00181]ある実施形態では、ＭＢＢラッパー生成器２６０２はＸＭＬパーサを使用して構文解析を実行する。このパーはファイルを開き、内容を読み取り、ファイルに含まれる様々なキーワードを分析し、ＭＢＢに関する情報を抽出する。パーサは、この情報を使用してコードを自動的に生成する。
【０１３９】
[00182]ある実施形態では、代表的なメソッドは次のものを含む。
【０１４０】
（１）ＭＢＢに関連付けられた定数に値を割り当てるコードを含む定数初期化メソッド。ＭＢＢインフラストラクチャは、最初にＭＢＢをロードするときに、このメソッドを自動的に呼び出す。
【０１４１】
[00183]（２）ＭＢＢの機能をエクスポートするＭＢＢメソッド。ある実施形態では、これらのメソッドはユーザによって元のＸＭＬファイルの中で定義され、インフラストラクチャによって呼び出されて、指定された機能を提供する。
【０１４２】
[00184]パラメータマッピング２６０３は、パラメータ及び関連のインデックスのリストを記憶するハッシュテーブルである。パラメータマッピング２６０３（即ち、インデックス関連付けへの名前）はパラメータマッピングを記憶し、システムが、パラメータマッピングを後に参照できるようにする。これらのマッピングを保存する多くの方法、例えば、リンクリスト、静的配列などが存在するが、他のデータ構造よりも情報を速く検索する速度を理由として、ハッシュテーブルが一実施形態では使用されている。ある実施形態では、パラメータマッピング２６０３は静的メモリに記憶される。
【０１４３】
[00185]ＭＢＢパラメータインデックス生成器２６０１は、パラメータインデックスを管理することを担っている。図２７によれば、パラメータインデックス生成器２６０１は、パラメータマッピング２７１０（状態メモリ２７０３の中に記憶される）及びＭＢＢ  ＸＭＬ記述ファイル２７０２を受け取り、パラメータマッピング２７１０を更新し、そのマッピングを状態メモリ２７０１の中に記憶する。ある実施形態では、パラメータインデックス生成器２６０１は、二つの関数、即ち、パラメータ付加関数及びパラメータ除去関数を提供する。パラメータ付加関数はパラメータ（入力、出力、又は状態）のために新しいインデックスを生成し、パラメータ除去関数はパラメータを削除し、パラメータを使用するＭＢＢの数に基づいて関連インデックスを更新する。
【０１４４】
[00186]インデックスの使用は性能を向上するが、これらのインデックスを使用してパラメータにアクセスすることをプログラマに要求する。パラメータアクセスを簡単にするために、ある実施形態では、ＭＢＢラッパー生成器２６０２は、元のパラメータの名前と整合するパラメータ定数のリストを生成する。更に、ラッパー生成器２６０２は、ＭＢＢ初期化の間にインデックスで定数の値を自動的に初期化するメソッドを作成する。
【０１４５】
[00187]ある実施形態では、ラッパー生成器は、メソッドの定義を有するコードを含む新しいファイルを生成することによって、メソッドを作成する。このコードは、自動的に生成されてもよい。
【０１４６】
[00188]図２８は、ＭＢＢラッパー生成器２６０２の一実施形態を示す。図２８を参照すると、ＭＢＢラッパー生成器２６０２はＭＢＢ  ＸＭＬ記述ファイル２８０１を受け取って、ＭＢＢラッパー２８０２を特定の言語で生成する。図２９はＪａｖａ  ＭＢＢラッパーの例を示す。
【０１４７】
[00189]ある実施形態では、ＭＢＢは三つの異なるタイプのパラメータ、即ち、入力、出力、及び状態パラメータを使用する。入力パラメータは、呼び出されたときにＭＢＢへ渡され、出力パラメータはＭＢＢによって生成される。ＭＢＢスケジューラは、これらの出力パラメータを受け取り、後続のＭＢＢへ渡す。最後に、状態パラメータはＭＢＢの内部値を記憶する。これらの状態パラメータは、状態メモリに記憶され、ＭＢＢがシステムの中に存在する限り保存される。ある実施形態では、これらの三つのタイプのパラメータは、キー値のタプルとして記憶される。キーについて名前を使用するのではなく、インデックスが使用される。ユーザがパラメータに対応する文字列を単純に書く名前とは異なり、インデックスの場合、ユーザはインデックスを取得した後で、このインデックスを使用して値を検索することができる。このタスクを簡単にするため、ラッパー生成器はパラメータの各々について変数を自動的に作成する。変数の名前はパラメータの名前に対応する。ある実施形態では、変数の型は整数であり、その変数は、パラメータに関連付けられたインデックスの値を記憶する。ラッパー生成器は、これらのパラメータの値を自動的に初期化するメソッドを作成する。
【０１４８】
[00190]図３０は、例示的なＭＢＢ  ＸＭＬ記述ファイルを呈示している。ＭＢＢクラスは「ｅｘａｍｐｌｅ」であり、一つの状態パラメータ（ｓｔａｔｅ１）、一つの入力パラメータ（ｉｎｐｕｔ１）、及び一つの出力パラメータ（ｏｕｔｐｕｔ１）を有する。図２９はＭＢＢラッパーを示している。このラッパーは、ＸＭＬファイルが構文解析された後、ＭＢＢラッパー生成器２６０２によって生成される。結果は、三つの内部属性、即ち、ｓｔａｔｅ１、ｉｎｐｕｔ１、及びｏｕｔｐｕｔ１を有するＪａｖａクラスである。これらの三つの整数は、ｉｎｉｔＩｎｄｉｃｅｓメソッドによって、ＭＢＢの作成中に初期化される。ｉｎｉｔＩｎｄｉｃｅｓメソッドは、パラメータマッピングハッシュテーブルを取得し、三つのパラメータを名前で決定し、インデックス値を取得し、このインデックス値をＭＢＢラッパークラスの属性へ割り当てる。この整数の属性は、パラメータ配列をインデックスするために使用されることがある。
【０１４９】
[00191]図３１は、三つのパラメータにアクセスする例示的コードを示す。図３１を参照すると、自動的に生成された変数、即ち、ｓｔａｔｅ１、ｉｎｐｕｔ１、及びｏｕｔｐｕｔ１は、配列をインデックスして適切な値を取得するために使用される。このコードの例では、ユーザはこれらの変数を利用して適切な値を検索する。例えば、行３では、ＩｎｐｕｔＰａｒａｍｓ．ｇｅｔＰａｒａｍｅｔｅｒ（ｉｎｐｕｔ１）を使用して、入力パラメータ値を検索する。これらの変数（ｉｎｐｕｔ１、ｏｕｔｐｕｔ１、及びｓｔａｔｅ１）の各々は、実パラメータへのインデックスを記憶する。同じことが、出力及び状態パラメータに当てはまる。
【０１５０】
[00192]ある実施形態では、パラメータマッピングオブジェクトは、パラメータマッピングアイテムを記憶するハッシュテーブルである。図３２は、パラメータマッピングアイテムの例である。パラメータマッピングアイテムは、二つのフィールド、即ち、パラメータインデックス及びパラメータ参照情報を有する構造体である。パラメータインデックスは、パラメータに関連付けられた数値インデックスを表す整数を記憶する。パラメータ参照情報は、パラメータを参照するＭＢＢの数を記憶するカウンタである。即ち、パラメータ「ｘ」は、ＭＢＢ「Ａ」及びＭＢＢ「Ｂ」の中で入力パラメータとして列挙され、またＭＢＢ「Ｃ」の中で出力パラメータとして列挙可能である。ある実施形態では、システムは参照の数を保持し、いつマッピングのリストからパラメータを削除するのが安全かを決定する。
【０１５１】
＜インデックスに基づくパラメータアクセスをサポートするプロトコル及びパラメータラッパー生成の例＞
[00193]図３３Ａ及び図３３Ｂは、新しいパラメータを登録してインデックスを取得するプロトコルの一実施形態の流れ図である。図３３Ａは、パラメータが存在しないときのシナリオを示し、図３３Ｂは、パラメータが既に存在するときのシナリオを示す。
【０１５２】
[00194]図３３Ａを参照すると、ＭＢＢパラメータインデックス生成器２６０１は、ＭＢＢ  ＸＭＬ記述を構文解析し（３３０９）、全ての入力、出力、及び状態パラメータについてパラメータマッピング２６０３を調べる（３３１０）。パラメータが存在しなければ（３３１１）、ＭＢＢパラメータインデックス生成器２６０１は新しいパラメータマッピングアイテムを作成し（３３１２）、この新しいパラメータマッピングアイテムに新しいインデックスを割り当て（３３１３）、パラメータマッピング２６０３の中に記憶する（３３１４）。最後に、ＭＢＢパラメータインデックス生成器２６０１は、新しいインデックス値を生成する（３３１５）。
【０１５３】
[00195]図３３Ｂを参照すると、ＭＢＢパラメータインデックス生成器２６０１は、ＭＢＢ  ＸＭＬ記述を構文解析し（３３２０）、全ての入力、出力、及び状態パラメータについて、ＭＢＢパラメータインデックス生成器２６０１はパラメータマッピング２６０３を調べる。パラメータが存在すれば（３３２２）、ＭＢＢパラメータインデックス生成器２６０１は、パラメータマッピングアイテムの中に記憶された参照カウンタを１だけ増加する（３３２３）。
【０１５４】
[00196]図３４は、パラメータ除去プロトコルの一実施形態の流れ図である。図３４を参照すると、ＭＢＢパラメータインデックス生成器２６０１は、パラメータマッピング２６０２を見て、パラメータマッピングからパラメータマッピングアイテムを取得することから開始する（３３１１）。次に、ＭＢＢパラメータインデックス生成器２６０１は、パラメータマッピングアイテムの中に記憶された参照カウンタを減少する（３３１２）。カウンタ値が０に達した場合に、ＭＢＢパラメータインデックス生成器２６０１はマッピングからアイテムを除去し（３３１３）、達しない場合には、ＭＢＢパラメータインデックス生成器２６０１はアイテムをマッピングから除去しない。なぜなら、そのアイテムは他のＭＢＢによって使用されるからである。
【０１５５】
[00197]図３５は、ＭＢＢラッパーを自動的に生成するプロトコルの一実施形態の流れ図である。ＭＢＢラッパー生成器２６０２は、ＭＢＢ  ＸＭＬ記述を構文解析し（３５１０）、ユーザによって指定されたプログラミング言語を使用してＭＢＢラッパーを作成する（３５１１）。Ｊａｖａでは、例えば、ＭＢＢラッパーはＭｉｃｒｏＢｕｉｌｄｉｎｇＢｌｏｃｋから継承するクラスであり、空の終了及び処理メソッドを有する。ある実施形態では、開発者がコードを提供する。ラッパー生成器２６０２は、パラメータの名前を有する定数（整数）のリストを作成する。ある実施形態では、これらの定数はパラメータをインデックスするために使用される。ラッパー生成器２６０２は、これらの定数の値を初期化するメソッドを作成する。このメソッドはＭＢＢラッパー３５２１のｉｎｉｔメソッドから自動的に呼び出される。ｉｎｉｔメソッドもＭＢＢラッパー３５２１によって自動的に作成される。
【０１５６】
[00198]図３６は、パラメータインデックスを初期化するプロセスの一実施形態の流れ図である。図３６を参照すると、ＭＢＢローダ３６０１が新しいＭＢＢを作成する場合、この新しいＭＢＢはｉｎｉｔメソッドを呼び出す（３６１０）。このメソッドはパラメータ初期化メソッドを呼び出し（３６１１）、当該パラメータ初期化メソッドはパラメータマッピングを取得し、各ＭＢＢパラメータについてインデックスの値を検索し（３６１２及び３６１３）、これらのインデックスをパラメータ定数へ割り当てる（３６１４）。
【０１５７】
＜例示的な通信ミドルウェアサービス＞
[00199]ここで、ＭＢＢを使用して構築されたマルチプロトコルオブジェクト要求プローカ（ＯＲＢ）通信ミドルウェアサービスを、説明する。このサービスは、有線プロトコルから独立して、クライアント及びサーバ機能を提供する。即ち、サーバオブジェクトのメソッドは、異なるプロトコル、例えば、ＩＩＯＰ、ＳＯＡＰ、又はＸＭＬ−ＲＰＣで呼び出し可能である。同様に、クライアント要求は、下層にあるプロトコルに関係なく、同じインタフェース及びセマンティクスを使用する。この実装方法は、ＩＩＯＰ及びＸＭＬ−ＲＰＣのサポートを提供する。しかしながら、実行時に追加のＭＢＢを開発及び配置することによって、追加のプロトコルを付加することができる。ＥｘＯＲＢのアーキテクチャ（状態、構造、及びロジック）が外部化されるので、実行時にＥｘＯＲＢのアーキテクチャを検査及び操作することができる。
【０１５８】
[00200]ＥｘＯＲＢは、２８個のマイクロビルディングブロックから編成され、これらのマイクロビルディングブロックは、１１個のドメインへグループ化されている。図３７はＥｘＯＲＢの構造を示している。
【０１５９】
[00201]図３７を参照すると、ＣＤＲパラメータ管理ドメインは、共通データ表現（ＣＤＲ）フォーマット（ＣＯＲＢＡデフォルト表現）に従って、パラメータをマーシャリング及びデマーシャリングする機能を提供する。ＣＤＲマーシャリングパラメータマイクロビルディングブロックは、パラメータ及びＣＤＲバッファ符号化オブジェクトを受け取り、パラメータのＣＤＲ表現を含むバイト配列を返却する。ＣＤＲデマーシャリングパラメータマイクロビルディングブロックは、バイトバッファ、バッファから抽出するためのパラメータタイプのリストを有する配列、及びＣＤＲバッファ復号オブジェクトを受け取り、オブジェクトの値を有する配列を返却する。
【０１６０】
[00202]ＸＭＬＲＰＣパラメータ管理ドメインは、ＣＤＲパラメータ管理ドメインと類似しているが、ＸＭＬＲＰＣプロトコルに従って符号化されたパラメータをマーシャリング及びデマーシャリングする機能を提供する。
【０１６１】
[00203]ＩＩＯＰプロトコル処理ドメインは、ＩＩＯＰプロトコルに従うメッセージを符号化及び復号する機能をエクスポートするマイクロビルディングブロックを集約する。ＩＩＯＰ要求符号化マイクロビルディングブロックは、マーシャリングされたパラメータ、及び要求フィールドの集合（例えば、リモートのオペレーション名、期待される応答、及び要求ｉｄ）のリストを受け取り、ＩＩＯＰに従ってフォーマットされたバイトバッファを生成する。ＩＩＯＰ要求復号マイクロビルディングブロックは、要求メッセージを記述するフィールド（例えば、長さ）の集合、及びＩＩＯＰフォーマットの着信要求をもつバイトバッファを受け取り、要求を構文解析し、要求に関する情報を有する属性の集合を生成する。かかる情報には、要求のｉｄ、ターゲットオブジェクト、ターゲットメソッド、及びパラメータを有するバイトバッファが含まれている。ＩＩＯＰ応答符号化及びＩＩＯＰ応答復号は、ＩＩＯＰ応答メッセージを生成し、着信ＩＩＯＰ応答メッセージを復号する機能を提供する。最後に、ＩＩＯＰヘッダ復号は、ネットワークから元の着信要求を受け取り（バイトバッファ）、ＧＩＯＰヘッダを構成する１２の初期バイトを構文解析する。このヘッダは、残りのメッセージの長さ及びメッセージのタイプに関する情報を含む。
【０１６２】
[00204]ＸＭＬＲＰＣプロトコル処理ドメインは、ＩＩＯＰプロトコル処理ドメインと同じであり、ＸＭＬＲＰＣ要求及び応答を取り扱う機能を提供する。
【０１６３】
[00205]ネットワークデータ管理ドメインは、着信及び発信のネットワークトラフィックの取り扱いを担っている。このドメインは三つのマイクロビルディングブロック、即ち、データ送信、データ受信、及びデータピークから構成されている。データ送信マイクロビルディングブロックは、バッファ、その長さ、及び通信ポイントオブジェクト（例えば、ＴＣＰソケット）を受け取り、通信ポイントを使用してネットワーク上にデータを送信する。データ受信マイクロビルディングブロックは、バッファ、受け取るデータの長さ、及び通信ポイントオブジェクトを受け取り、通信ポイントオブジェクトを使用してデータをバッファの中に記憶し、データを取得する。データピークマイクロビルディングブロックは、データ受信マイクロビルディングブロックと類似するが、ネットワークバッファから読み取るデータを除去しない。
【０１６４】
[00206]オブジェクト呼び出しドメインは、Ｊａｖａ言語リフレクション機能を使用してサーバメソッドの呼び出しを自動化する二つのマイクロビルディングブロックを含む。この機能の結果として、開発者はサーバオブジェクトのためにスケルトンを構築する必要はなく、単に登録するだけでよく、システムは、必要とする情報の全てを自動的に取得する。メソッド呼び出し準備マイクロビルディングブロックは、オブジェクトへのポインタ及び呼び出すメソッドの名前を受け取る。このマイクロビルディングブロックはＪａｖａリフレクションを使用して、メソッドのシグニチャを検査し、メソッドの呼び出しに必要なパラメータタイプを有する配列を作成し、その配列を出力パラメータとして返却する。メソッド呼び出しマイクロビルディングブロックは、パラメータ値を有する配列を受け取り、オブジェクトメソッドを呼び出し、そのメソッドによって生成されたパラメータを有する配列を返却する。
【０１６５】
[00207]ＴＣＰ着信接続管理ドメインは、着信ＴＣＰネットワーク接続を取り扱う機能を提供する。初期化マイクロビルディングブロックは整数を受け取る。この整数はポートを指定し、ＥｘＯＲＢは、このポートを使用して要求を待ち受ける。受け入れマイクロビルディングブロックは、着信ＴＣＰ要求を待ち受けて、当該受け入れマイクロビルディングブロックが入力パラメータを受け取らない場合には、ネットワーク接続をカプセル化するＴＣＰ通信ポイントオブジェクトを返却する。
【０１６６】
[00208]ＴＣＰ発信接続管理ドメインは、リモートピアとのＴＣＰ接続確立を取り扱う。このドメインは、二つのマイクロビルディングブロックを有する。接続マイクロビルディングブロックは、ホスト名及びポートを受け取り、ホストへ接続し、ネットワーク接続をカプセル化するＴＣＰ通信ポイントを返却する。通信ポイント返却マイクロビルディングブロックは、ＴＣＰ通信ポイントオブジェクトを受け取り、そのキャッシングアルゴリズムに従って、そのオブジェクトを閉じるか、又は、キャッシュする。
【０１６７】
[00209]オブジェクト登録ドメインは、サーバオブジェクトを管理することを担っている。オブジェクト登録マイクロビルディングブロックは、オブジェクトｉｄ及びオブジェクト参照情報を受け取り、オブジェクトをテーブルの中に記憶する。このテーブルは、ドメインの状態メモリに記憶される状態属性である。オブジェクト除去マイクロビルディングブロックは、オブジェクトｉｄを受け取り、関連のオブジェクトをテーブルから除去する。オブジェクト獲得マイクロビルディングブロックは、オブジェクトｉｄを受け取り、参照情報をその関連のオブジェクトへ返却する。
【０１６８】
[00210]プロトコル検出ドメインは、着信要求の通信ミドルウェアプロトコルを特定する機能をエクスポートする。この機能は、ＥｘＯＲＢのマルチプロトコル動作をサポートするために必要である。プロトコル検出マイクロビルディングブロックは、バイトバッファを受け取り、このバッファを構文解析し、ミドルウェアプロトコルの名前を有する文字列を返却する。ＭＢＢの現在の実装方法は、二つのタイプのプロトコル、即ち、ＸＭＬＰＲＣ及びＩＩＯＰを検出する。
【０１６９】
[00211]ＵＲＩオブジェクト参照管理ドメインは、リモートオブジェクトＵＲＩ参照情報を構文解析して全ての必要な情報を抽出し、要求をリモートオブジェクトへ送る機能を提供する。このドメインは、オブジェクト参照と呼ばれる単一のマイクロビルディングブロックを有し、このマイクロビルディングブロックは、ＵＲＩ及びプロトコルタイプを受け取って、ホスト名、ポート番号、及びオブジェクトｉｄを返却する。
【０１７０】
[00212]表１は、各々のＥｘＯＲＢドメイン（Ｊａｖａバージョン）のサイズを列挙する。デバッグ情報を除く全サイズは７０ＫＢである。
【表１】
2008524719.tif 000003
【０１７１】
[00213]ＥｘＯＲＢは、四つのアクション、即ち、要求送信、要求受信、初期化、及びオブジェクト登録をエクスポートする。最初のアクションは、クライアント側の機能を目的としており、残りの三つ（要求受信、初期化、及びオブジェクト登録）はサーバ側の機能を目的としている。オブジェクト初期化及びオブジェクト登録は、初期化ＭＢＢ及びオブジェクト登録ＭＢＢを呼び出す単一ノードのアクションである。
【０１７２】
[00214]図３８は、要求送信アクションのアクショングラフを示している。簡単にするため、エラー状態は除去されている。クライアントオブジェクトがアクションを呼び出すときに、当該クライアントオブジェクトはアクション状態オブジェクト（アクションの実行中に生成されるパラメータを記憶するオブジェクト）を提供する。このアクション状態オブジェクトは、アクションの名前、リモートオブジェクトの参照情報、呼び出すメソッド、必要なパラメータ、及び使用するプロトコル（即ち、ＸＭＬＲＰＣ又はＩＩＯＰ）を含む。アクションは、オブジェクト参照ＭＢＢを呼び出すことから開始する。オブジェクト参照ＭＢＢは、リモートオブジェクトの参照情報を構文解析し、ホスト名、オブジェクトｉｄ、及びポートを抽出する。これらのパラメータはアクション状態オブジェクトの中に記憶される。
【０１７３】
[00215]次に、アクションは接続を呼び出す。接続は、アクション状態オブジェクトからホスト名及びポートを取得し、リモートホストとの接続を確立し（又は既存の接続を再使用し）、ＴＣＰソケット（ＴＣＰ通信ポイント）をカプセル化するオブジェクトをアクション状態オブジェクトの中に記憶する。次の状態への遷移は条件文であり、アクション状態オブジェクトの中に記憶された「プロトコル」変数の値に依存する。この変数の値が「ｉｉｏｐ」であれば、アクションはＣＤＲパラメータマーシャリングを呼び出してパラメータをマーシャリングし、次にＩＩＯＰ要求符号化ＭＢＢを呼び出して要求メッセージを作成する。変数の値が「ｘｍｌｒｐｃ」であれば、アクションはＸＭＬＲＰＣパラメータマーシャリングを呼び出し、次にＸＭＬＲＰＣ要求符号化を呼び出す。ＩＩＯＰ要求符号化及びＸＭＬＲＰＣ要求符号化の両ＭＢＢは、適切なプロトコルに従ってフォーマットされた要求を有するバイトバッファを生成する。アクショングラフの次の状態はデータ送信であり、当該データ送信は、アクション状態オブジェクトからバッファを検索し、このバッファを、アクション状態オブジェクトの中に記憶されたＴＣＰ通信ポイントオブジェクトを使用して、リモートオブジェクトへ送信する。データ送信を呼び出した後、アクションはアクション状態オブジェクトから「oneway」という名前のタプルを検索する。その値が「真」であれば、アクションは通信ポイント返却を呼び出す。通信ポイント返却はアクション状態オブジェクトからＴＣＰ通信ポイントオブジェクトを処分して終了し、アクション状態オブジェクトをアクションの呼び出し側へ返却する。
【０１７４】
[00216]「oneway」の値が「偽」であれば、アクションは応答復号へ継続する。最初に、「プロトコル」タプルの値に依存して、アクションはＩＩＯＰヘッダ又はＸＭＬＲＰＣヘッダを復号する。両ＭＢＢはメッセージヘッダを構文解析し、要求に関する情報をアクション状態オブジェクトの中に記憶する。両ＭＢＢに必須の一つのフィールドは、応答の残りの部分の長さである。次いで、アクションは、データ受信を呼び出す。このデータ受信は、ネットワークから読み取らねばならないデータの量を決定するために長さタプルを必要とする。次に、アクションは応答の復号及びパラメータのデマーシャリングへ進む。この場合にも、アクションインタプリタは「プロトコル」の値を使用して、グラフ中でどのパスをたどるべきかを決定する。次いで、アクションは、通信ポイント返却ＭＢＢ（ＴＣＰ通信ポイントを処分する）を呼び出して終了し、アクション状態オブジェクトをアクションの呼び出し側へ返却する。アクション状態オブジェクトは結果パラメータを含む。
【０１７５】
[00217]図３９は、要求受信のアクショングラフである。アクションは、受け入れを呼び出すことで開始する。この受け入れは、着信ネットワーク要求を検出するまでブロックし、ネットワーク接続をカプセル化するＴＣＰ通信ポイントを生成する。次に、アクションは、データピークを呼び出す。データピークは、着信データバッファの中をピークし、初期バイトを構文解析してプロトコルのタイプを検出する。プロトコルタイプがＩＩＯＰであれば、データピークＭＢＢは、名前「プロトコル」を用いて登録された値「ｉｉｏｐ」を有するタプルを記憶する。プロトコルタイプがＸＭＬＲＰＣであれば、ＭＢＢは同じ名前で値「ｘｍｌｒｐｃ」を記憶する。次に、アクションは「プロトコル」値を使用して、ＩＩＯＰヘッダ復号へジャンプするかＸＭＬＲＰＣヘッダ復号へジャンプするかを決定する。これらの二つのＭＢＢは、ヘッダを構文解析し、アクション状態オブジェクトの中に記憶する情報を抽出する。両ＭＢＢは、残りのデータの長さを指定する「長さ」という名前の必須タプルを記憶しなければならない。この値は、ネットワークバッファから残りの要求データを取得するためデータ受信ＭＢＢによって使用される。
【０１７６】
[00218]次いで、アクションは、アクション状態オブジェクトの中に記憶された「プロトコル」タプルの値に依存して、ＩＩＯＰ要求復号又はＸＭＬＲＰＣ要求復号を呼び出す。両ＭＢＢは、複数のフィールドを生成する。これらフィールドには、ターゲットオブジェクトのｉｄ及びメソッドの名前が含まれる。次に、アクションは、オブジェクト獲得を呼び出す。オブジェクト獲得は、オブジェクトｉｄを使用してターゲットオブジェクトを検出し、その参照情報をアクション状態オブジェクトの中に記憶する。次に、メソッド呼び出し準備が、ターゲットメソッドの名前を使用し、Ｊａｖａリフレクションを使用してメソッドを呼び出すために必要なパラメータを検査する。このＭＢＢはパラメータタイプの配列を生成する。次に、「プロトコル」の値に依存して、アクションは、ＣＤＲパラメータデマーシャリング又はＸＭＬＲＰＣパラメータデマーシャリングを呼び出す。これらは、前に生成されたタイプ配列を使用して、着信要求からの値をデマーシャリングする。これらの二つのＭＢＢはパラメータ値の配列を生成する。次に、メソッド呼び出しＭＢＢが、この値の配列を使用して、ターゲットオブジェクトのメソッドを呼び出す。これはアクション状態オブジェクトの中に記憶される。メソッド呼び出しＭＢＢは、出力パラメータの値を有する配列を生成する。次に、アクションは、「プロトコル」値を使用して出力パラメータをマーシャリングし、ＩＩＯＰ又はＸＭＬＲＰＣのいずれかで応答メッセージを生成する。ＩＩＯＰ応答符号化及びＸＭＬＲＰＣ応答符号化ＭＢＢは、応答を有するバイトバッファを生成する。次いで、データ送信マイクロビルディングブロックが、アクション状態オブジェクトの中に記憶されたＴＣＰ通信オブジェクト（これは、受け入れマイクロビルディングブロックで生成された）を使用して、クライアントホストへ応答を送る。そして、データを送信した後、アクションは通信ポイント返却を呼び出す。通信ポイント返却はキャッシングアルゴリズムに依存して、ＴＣＰ通信ポイントを処分するかキャッシュの中に記憶する。
【０１７７】
[00219]前述したように、設定可能なソフトウェアの重要な特徴は、ソフトウェア状態を第１クラスのオブジェクトとして操作するためのサポートである。ある実施形態では、全てのＭＢＢは、名前及び値のペアに関して定義されたその状態依存性を明示的に指定する。これらのタプルは、ＭＢＢドメインによって提供された記憶領域に記憶される。ソフトウェアの状態は、全てのＭＢＢの状態属性の共用体である。したがって、ＥｘＯＲＢの状態は、２８個のマイクロビルディングブロックによって定義される全ての状態属性から成る。
【０１７８】
[00220]表２は、ＥｘＯＲＢに関連付けられた状態属性を列挙する。表は、属性の名前、その目的、及び属性を記憶するドメインの名前を含む。
【表２】
2008524719.tif 000004
【０１７９】
＜ソフトリアルタイム動作のサポート＞
[00221]ソフトリアルタイム動作は、統計的に平均時間量のデッドラインを満足する実行に対応する。ある実施形態では、スケジューラが、特定の時間量内で実行するようにタスクをスケジュールする。タスクの各部分を実行するのに必要な時間を知ることによって、スケジューラはタスクを正確にスケジュールすることができる。
【０１８０】
[00222]図４０は、ソフトリアルタイムスケジューリングシステムの一実施形態のブロック図である。図４０を参照すると、スケジューリングシステムは、六つの新しいコンポーネント（ＭＢＢソフトリアルタイムスケジューラ４００１、ＭＢＢ実行プロファイラ４００６、アクションスケジューラ４００２、アクションリソース使用推定ユニット４００３、動的リソースモニタ４００５、及び、動的アクション再設定ユニット４００４）と、アクション用の依存性グラフ４００７を記憶する新しい記述を有している。これらユニットの各々は、ハードウェア（例えば、回路、専用ロジックなど）、ソフトウェア（例えば、汎用コンピュータシステム又は専用機械の上で動作するもの）、又は双方の組み合わせであってもよい。これらユニットは、ファームウェア又はマイクロコード化ＲＯＭで指示されてもよい。
【０１８１】
[00223]ＭＢＢソフトリアルタイムスケジューラ４００１は、限られた時間内で実行して、アクションの実行時間オーバヘッドに上限を算出することを可能にする。ＭＢＢ実行プロファイラ４００６は、ＭＢＢによって使用されるリソース（例えば、実行時間、メモリ、ネットワーク帯域幅、ＣＰＵ使用）に関する情報を算出及び記憶する機能を提供する。アクションリソース使用推定ユニット４００３は、アプリケーションによって提供されたパラメータと共にＭＢＢ実行プロファイラ４００６によって生成された情報を使用して、アクションのリソース利用を推定する。アクションスケジューラ４００２は、期間又はデッドライン、それらの総実行時間、及びそれらの推定リソース利用に従って、アクションを定期的に実行する機能を提供する。動的リソースモニタ４００５は、定期的に実行して、リソース、例えば、ネットワーク帯域幅、メモリ、記憶装置、及びＣＰＵの利用可能性の標本を取る。動的アクション再設定ユニット４００４は、代替のアクション設定を作成する。ユーザは代替のＭＢＢ（異なるリソース要件を有する）に関する情報を提供し、実行時に、再設定ユニット４００４は、利用可能なリソースに整合する異なるアクション設定を探し出す。アクション依存性グラフ４００７は、アクションスケジューラ４００２によって要求されるアクションの実行順序を定義する。
【０１８２】
[00224]より具体的には、ＭＢＢソフトリアルタイムスケジューラ４００１は、アクションを構文解析し、適切な順序でＭＢＢを実行することを担っている。ある実施形態では、ソフトリアルタイム保証を提供するために、スケジューラ４００１の実行時間は限界を設けられており、システムは、アクションの全体的実行時間（即ち、各々のアクションのＭＢＢ実行時間にスケジューラオーバヘッドを加えた合計）を推定することができる。スケジューラ４００１は、ＭＢＢ実行プロファイラ４００６と対話し、ＭＢＢのリソース利用に関する情報を記憶する。この情報は、アクションのリソース要件を推定するためにアクションスケジューラ４００２によって要求される。
【０１８３】
[00225]ＭＢＢ実行プロファイラ４００６は、個々のＭＢＢリソース消費に関する情報を記憶する。これらは、限定するものではないが、ＣＰＵ、メモリ、及び帯域幅に含むことができる。ＭＢＢが実行される度に、ＭＢＢ実行プロファイラ４００６は、ＭＢＢが実行に要する時間を算出し、その情報を記憶する。別の実施形態では、ＭＢＢ実行プロファイラ４００６は、アクション（即ち、アクションを構成する全ＭＢＢ）が要する時間を算出し、その情報を代わりに記憶する。これはトレーニングデータとして働き、利用可能なデータが多くなれば、それだけ過去の実行に基づく推定値（推定ユニット４００３による）が正確になる。ある実施形態では、標本の数は設定可能であり、ドメインメモリに記憶され、したがって他のコンポーネントがアクセスすることができる。別の実施形態では、確信度を使用して、過去に起こったＭＢＢ（又はアクション）の実行時間に関連する信頼のレベルを示すことができる。ある実施形態では、ＭＢＢ実行プロファイラ４００６を、ＭＢＢとして実施し、したがって実行時に異なるプロファイリング機能を提供するために置換することができる。
【０１８４】
[00226]アクションリソース利用推定ユニット４００３は、プロファイラ４００６によって生成されたデータ及びアプリケーションによって提供されたパラメータを使用して、アクションのリソース利用を推定することを担っている。利用できるデータが多くなれば、それだけリソース推定値は良くなることが期待される。リソースは、時間、ＣＰＵ利用、メモリ、帯域幅消費、その他であってもよいことに注意されたい。プロファイラ４００６は、データを提供するときに、どれが推定されているかを知る必要がある。リソース推定値は、アクションを適切にスケジュールするためにアクションスケジューラ４００２によって使用される。
【０１８５】
[00227]図４１は、入力及び出力パラメータを伴うアクションリソース利用推定ユニット４００３を示している。図４１を参照すると、アクションリソース利用推定ユニット４００３は、四つの入力パラメータを受け取って出力パラメータを生成する。入力パラメータは、アクション名４１０２、リソース使用推定信頼値４１０１、ＭＢＢプロファイリングデータ４１０３、及びアクション名４１０２に関連のアクショングラフに対応するアクション記述４１０５である。出力パラメータは、アクションリソース使用推定値４１０４である。
【０１８６】
[00228]アクション名４１０２は、リソース利用の推定が成されるアクションを指定する。推定信頼値４１０１は確率パラメータである。この確率パラメータは、当技術分野で周知の方法であって推定値の確度を定義するような方法で、アプリケーションによって提供される。ある実施形態では、値は０から１までの範囲である。例えば、ある実施形態では、０．７５の値は、アプリケーションが時間の少なくとも７５％について提供値以下の推定結果を必要とすることを意味する。ある実施形態では、プログラマ又はユーザが、この値を選択する責任を有する。値が高ければ、それだけ品質は良くなるが、機能を獲得することは困難になり、スケジューラが指定値を満足することができなければ、スケジューラは要求を拒絶する。拒絶されると、ユーザは低い値を選択し、低い品質がもたらされる。
【０１８７】
[00229]ＭＢＢプロファイリングデータ４１０３は、前のＭＢＢリソース利用値を含む。アクションリソース使用推定ユニット４００３は、この利用値を使用して推定値を算出する。推定ユニット４００３は、個々のＭＢＢリソース利用値を使用し、したがって、個々の値を加算して全体的なアクションリソース利用を提供するためにアクション記述４１０５を必要とする。より具体的には、アクション記述４１０５は、アクションに含まれるＭＢＢのリストを有し、推定ユニット４００３は全てのＭＢＢを調べ、ＭＢＢプロファイリングデータを使用して総コストを算出する（例えば、各々の個々のＭＢＢのコストを加算するコストによって）。
【０１８８】
[00230]スケジューリングシステムはまた、全体的なアクションリソース利用を測定し、個々のＭＢＢ値ではなく、これらの標本を記憶するように構成可能である。ある実施形態では、アクションリソース利用推定ユニット４００３は、前のＭＢＢ実行値に基づく累積分布関数を使用して、その推定値を生成する。累積関数は、各ＭＢＢ用の値を加算したものである。しかし、追加の推定関数を構成することができる。追加の関数は、異なるＭＢＢに重みを割り当てることができ（例えば、ＭＢＢの関連性に依存して）、したがって、この関数は異なる推定を比例配分する。
【０１８９】
[00231]ある実施形態では、推定ユニット４００３からのアクションリソース使用推定値４１０４は、特定のパーセンテージ（例えば、９５％）の時間に対して、アクションが完了するのに要する時間を示す指標である。ある実施形態では、リソース使用推定ユニット４００３は、次のアプリケーションプログラミングインタフェースを使用する。
floatgetResourceUtilizationEstimationUnit(string actionName, float 
confidenceValue, stringresourceName)
このメソッドは、アクションの名前、要求される信頼値、推定値が要求されるリソースの名前を受け取り、利用推定を返却する。
【０１９０】
[00232]アクションスケジューラ４００２は、ソフトリアルタイム保証で周期的アクションをスケジュールすることを担っている。図４２は、アクションスケジューラの一実施形態を示す。図４２を参照すると、アクションスケジューラ４００２は四つの入力パラメータを有し、提供された要件及び残りの登録されたアクションと整合するスケジュールを生成する。第１の入力パラメータはアクションの名前４１０２であり、第２のパラメータはアクションデッドライン又は期間４２０１であり、第３のパラメータはアクション依存性グラフ４００７であり、第４のパラメータは総実行時間を含むアクションリソース要件である。最初の三つのパラメータはアプリケーション開発者によって提供されてもよく、４番目のパラメータはアクションリソース利用推定ユニット４００３によって提供される。デッドラインは、それらの開始時間と相対的に指定される。ある実施形態では、アクションスケジューラ４００２は、標準レートモノトニック及びＥＤＦスケジューリングアルゴリズムを使用して、アクションをスケジュールする。これらのアルゴリズムは、リアルタイム技術で非常によく知られている。例えば、Ｒｅａｌ−Ｔｉｍｅ  Ｓｙｓｔｅｍｓ，  Ｊａｎｅ  Ｗ．Ｓ．Ｌｉｕ，Ｐｒｅｎｔｉｃｅ  Ｈａｌｌ，ＩＳＢＮ：０−１３−０９９６５１−３を参照されたい。
【０１９１】
[00233]ある実施形態では、アクションスケジューラ４００２は二つのメソッドをエクスポートする。即ち、一つのメソッドはデッドラインを使用してアクションをスケジュールし、他の一つのメソッドは期間によってアクションをスケジュールする。これらは、次のアプリケーションプログラミングインタフェースを使用してアクセス可能である。
void scheduleActionByDeadline(stringactionName, float deadlineMilliseconds,
GraphactionDependencyGraph)
throws NonSchedulable
void scheduleActionByPeriod(stringactionName, float period, Graph
actionDependencyGraph)
throws NonSchedulable
【０１９２】
[00234]ある実施形態では、両メソッドは、三つの入力パラメータを必要とし、パラメータを返却せず、アクションをスケジュールできなければ、例外を発生する。第１のメソッドは、アクション名（スケジュールするアクション）、アクションのミリ秒でのデッドライン、及びアクション依存性グラフ４００７を受け取る。第２のメソッドは類似しているが、２番目のパラメータがアクションの実行期間である。アクションを完了できないことを、アクションスケジューラ４００２がリソース推定値に基づいて決定する場合、例外が発生する。
【０１９３】
[00235]動的リソースモニタ４００５は、リソースの利用可能性を周期的に測定し、その情報をドメインメモリに保存する。即ち、動的リソースモニタ４００５は、リソース及びそれらが割り振られている量を追跡する。ある実施形態では、動的リソースモニタ４００５がパラメータを監視する頻度、及び監視するパラメータ（例えば、帯域幅、メモリ、及びＣＰＵ負荷）は設定可能である。
【０１９４】
[00236]動的リソースモニタ４００５によってドメインメモリに記憶された情報は、アクションに供給する十分なリソースが存在するか否かを決定するために、許可制御の間に、アクションスケジューラ４００２によって使用される。即ち、アクションスケジューラ４００２は、過去におけるリソース使用の情報を使用して、将来どのように動作するかを決定することができる。
【０１９５】
[00237]動的アクション再設定ユニット４００４は、異なるリソース要件で類似の機能を提供する代替のアクション設定を生成する。動的アクション再設定ユニット４００４は、機能的に等しいＭＢＢのグループに関する情報を記憶し、様々なリソース要件を満足させるためにＭＢＢを異なるように結合するアクションを生成する。例えば、ビデオ符号化アクションは、１秒当たりの異なるフレーム数又は異なる解像度を有するビデオストリームを生成することができ、それによって品質とリソース利用との引き替えを行ない、異なるデバイスリソース利用可能性に対処する。アクションスケジューラ４００２が、例えば必要なリソースの欠乏により、アクションをスケジュールできないことを決定する場合に、動的アクション再設定ユニット４００４は、スケジュールし得る別のアクション又はアクショングループを指定してもよい。条件が変更されたこと、又はリソースの制約によって元のアクションが利用不可能であることを示す通知が、ユーザへ送られてもよい。ユーザはまた、例えば、同一又は類似の機能を有するが低性能のアクション、又は一以上のアクションを含むグループを停止する選択肢を与えられてもよい。異なる品質レベル及び／又は交換条件を有する複数のオプションが、ユーザへ呈示されてもよい。
【０１９６】
[00238]アクション再設定ユニット４００４は、アクション状態について代替のＭＢＢを登録できるようにする一つのメソッドをエクスポートする。ある実施形態では、これは次のアプリケーションプログラミングインタフェースを使用して実行される。
voidregisterReconfigurableAction(string actionName, ActionStateAlternativesalternateMBBs)
【０１９７】
[00239]第１のパラメータは、ターゲットアクションの名前を含む文字列である。第２のパラメータは、代替のＭＢＢを有するアクション状態のリストである。ある実施形態では、リスト中のエントリは、なるリソース要件で等しい機能を提供するＭＢＢのリストへのポインタ、及び名前（状態名）をもつタプルを含む。動的アクション再設定ユニット４００４は、この情報を使用して、異なるリソース要件を有するアクションを生成し、異なるＭＢＢの設定を試みる。
【０１９８】
[00240] アクション依存性グラフ４００７は、アクションの先行要素及び後続要素に関する情報を記憶する。即ち、アクション依存性グラフ４００７は、アクションの依存性を指定する。アクションの各々は、一以上のＭＢＢの集合である。アクションスケジューラ４００２は、この情報を使用してソフトリアルタイムスケジュールを生成する。
【０１９９】
[00241]図４０のコンポーネントは、協働動作してスケジューリングシステムを形成する。アクションスケジューラ４００７は、許可制御（例えば、アルゴリズム）を使用して、特定の期間又はデッドラインを有するアクション及びその依存性グラフを選択する。許可制御はリソース使用推定ユニット４００３と通信して、利用推定値を取得する。リソース使用推定ユニット４００３は、アクションが要する時間を指示する。この情報を使用して、アクションスケジューラ４００２の許可制御は、アクションをスケジュールできるか否かを決定する。アクションスケジューラ４００２がアクションをスケジュールできるものと判定すると、アクションがスケジュールされる。アクションスケジューラ４００２がアクションをスケジュールできないものと判定すると、許可制御はアクション再設定ユニット４００４と連絡して、代替のアクション設定を要求する。次に、許可制御は、もしあれば、代替のアクション設定をスケジュールできるか否かを決定する。なければ、許可制御は例外を起こす。こうして、個々のＭＢＢを監視する能力を使用することによって、ソフトリアルタイムスケジューリングが実行される。
【０２００】
＜プロトコルの例＞
[00242]図４３は、呼び出しシーケンスを有するソフトリアルタイムスケジューラ４００１の一実施形態のブロック図及び呼び出しシーケンスである。図４３を参照すると、スケジューラ４００１は最初にＭＢＢ事前呼び出しコード（４０１）を呼び出す。このコードはアクション依存性グラフ４００７を構文解析し、現在のアクショングラフノードを取得し、アクションノードに指定された各ＭＢＢの名前を取得し、ドメインメモリから各ＭＢＢを決定する。これは、ノード内の全てのＭＢＢについて起こる。次に、ＭＢＢスケジューラ４００１はプロファイラ４００６を呼び出す。プロファイラ４００６はＭＢＢを呼び出し（４３０２）、このＭＢＢによって消費されたリソースに関する情報を保存する。その後、ＭＢＢスケジューラ４００１はＭＢＢ事後呼び出しコード４３０３を呼び出す。事後呼び出しコード４３０３は次のアクショングラフノードを取得し、あるとすれば、ＭＢＢ呼び出しの間に生成されたエラーを処理する。プロセスは、スケジューラ４００１がアクション依存性グラフ４００７の最後のノードに達するまで反復される。
【０２０１】
[00243]アクション依存性グラフ４００７の中の各々のノードを構文解析し、ＭＢＢプロファイラを使用してＭＢＢの実行時間をプロファイリングするために、ＭＢＢスケジューラ４００１によって導入されるオーバヘッドは一定である。この時間は、ハッシュテーブル又はオブジェクト参照配列（双方の場合に、一定のアクセス時間）として実施されるドメインメモリからアクションノード及びその関連のＭＢＢを取得すること、及びリソース利用を測定すること（同様に、一定の時間）に対応する。したがって、ＭＢＢスケジューラ４００１によって導入されたオーパーヘッドを算出することができる。
【０２０２】
[00244]図４４は、アクションの実行時間を推定するアクションリソース利用推定アルゴリズムの一実施形態を示す。行１は、指定されたアクション記述を構文解析し、ＭＢＢのリストを取得する。行３は、現在のＭＢＢについてプロファイルデータを取得し、行４〜５は、前のプロファイルデータ及び提供された信頼値を使用し、累積分布関数を使用してＭＢＢリソース利用を算出する。信頼値（例えば、９０％）を使用して、リソース推定値が取得される（即ち、これらの場合の９０％で要求されるリソース推定値）。アクションに関する各ＭＢＢについての値が取得され、共通リソース（ＣＰＵ使用、メモリ消費など）についての値が加算される。
【０２０３】
[00245]行６は、前のアクションリソース使用及びスケジューラオーバヘッド（各ＭＢＢの呼び出しについて一定）を加算することによって、全体のアクションリソース使用量を更新する。行３〜７は、ＭＢＢがアクションの中に存在するだけ反復される。最後に、行９はアクション実行時間推定値を返却する。
【０２０４】
[00246]図４５は、ソフトリアルタイム保証と共にアクションをスケジュールするプロトコルの一実施形態を示す。図４５を参照すると、アクションをスケジュールする要求を受け取ると（４５０１）、アクションスケジューラ４００２は、アクションの名前、期間又はデッドライン、及びアクション依存性グラフ４００７（あれば）を有する許可制御アルゴリズム４５００を呼び出す。許可制御４５００は、リソース利用推定ユニット４００３と対話し、アクションのリソース利用について推定値を取得する（４５０２、４５０３）。この情報を使用して、許可制御アルゴリズム４５００は、初めに、標準手法、例えば、レートモノトニック分析又はＥＤＦ（earliestdeadline first）を使用して、アクションをスケジュールするように試みる。アクションをスケジュールできる場合に、許可制御４５００は成功メッセージをユーザへ返却する。そうでなければ、許可制御４５００は動的アクション再設定ユニット４００４と対話し、リソース要件（存在しないかも知れない）を満足する代替のアクション設定を取得し、アクションをスケジュールするように試みる（４５０８）。アクションをスケジュールできる場合に、許可制御４５００は成功メッセージを返却し（４５１０）、そうでなければエラーを通知する（４５０９）。
【０２０５】
＜代替の実施形態＞
[00247]本明細書で説明したスケジューリングシステムは、ソフトリアルタイムシステムを、きめ細かく管理するメカニズムを示している。システムの二つの代替の実装モデルは、プロセス当たりの実装モデル及びデバイス当たりの実装モデルを含む。
【０２０６】
[00248]「デバイス当たりの」モデルでは、アクションをスケジュールすることを担うインフラストラクチャの一つのインスタンスが存在する。このインスタンスは、別々のプロセスで動作し、プロセス間通信メカニズムを使用して、別々のプロセスで動作しているアクションと対話する。ある実施形態では、共通のスケジューリングインスタンスは、次のコンポーネントを含む。即ち、ＭＢＢソフトリアルタイムスケジューラ４００１、アクションリソース使用推定ユニット４００３、動的アクション再設定ユニット４００４、及びアクションスケジューラ４００２である。デバイス内で実行している全ての残りのプロセスは、次のコンポーネントを含む。即ち、ＭＢＢソフトリアルタイムスケジューラ４００１及びＭＢＢ実行プロファイラ４００６である。図４６は「デバイス当たりの」モデルを示す。
【０２０７】
[00249]「プロセス当たりの」モデルは、全てのプロセスが全体のインフラストラクチャを動作させるものと仮定する。全てのプロセスは、オペレーティングシステムから多数のリソースを割り振られ、これらのリソースが、ソフトリアルタイム制約に従ってプロセスのアクションへ割り振られるようにする。このモデルは、通常、マルチスレッド環境で使用され、プロセスのスコープの内部で、きめの細かい制御を与える。図４７は「プロセス当たりの」モデルを示す。
【０２０８】
[00250]本明細書で説明する二つのアプローチのほかに、ハイブリッド実装方法を提供することができる。ハイブリッド実装方法では、デバイス全体のインスタンスが、各々のプロセスで動作している個々のインスタンスと対話する。
【０２０９】
[00251]利用の例として、図４８に示すシナリオを考える。図４８を参照すると、この設定では、同じアドレス空間（プロセス１）で同時に動作している三つのタスク（例えば、ビデオ復号、オーディオ復号、ネットワークストリームバッファリング）が存在する。全てのタスクはソフトリアルタイム制約を有し、したがってランタイムインフラストラクチャは、実行デッドライン保証を提供できなければならない。全てのタスクはアクションに対応し、図４６に示すように、全てのアクションは多数のＭＢＢから編成される。本明細書に提示する手法を利用して、三つのタスクはソフトリアルタイム保証付きで並行して動作可能である。動的アクション再設定ユニット４００４は実行時にＭＢＢを置換することができ、それによって利用可能なリソースに関する変化にアクションを適応させ、これは、即ち、既存のデッドラインを維持する（適切な代替が利用可能であれば）。この能力は従来のソフトリアルタイムシステムと対照的である。従来のソフトリアルタイムシステムでは、プロセスが最小のスケジュール可能ユニットであり、内部的に再設定され得ない。更に、代替の設定を利用できなければ、アクションスケジューラ４００２は個々のアクションを削除することができ、したがって残りのアクションは依然としてデッドラインを満足することができる。
【０２１０】
[00252]小さい実行ユニット（マイクロビルディングユニット）を実行時に動的にアセンブルして設定するソフトウェア構築方法及び装置について説明した。本発明の実施形態は、実行要素、例えば、状態、構造、及びロジックの外部化を使用することができる。本発明の実施形態は、言語及びプラットフォームから独立であり、ソフトウェアコンポーネントの実行時の設定機能、更新機能、及びアップグレード機能、ソフトウェアコンポーネントのシームレスな移動機能、及び構築されたソフトウェアのさらに高い信頼性を提供する。
【０２１１】
＜例示的なコンピュータシステム＞
[00253]図４９は、本明細書で説明した一以上のオペレーションを実行するために使用できる例示的なコンピュータシステム２８００のブロック図である。別の実施形態では、マシーンは、ネットワークルータ、ネットワークスイッチ、ネットワークブリッジ、パーソナルディジタルアシスタント（ＰＤＡ）、携帯電話、ウェブ機器、又は、取るべきアクションを指定する命令シーケンスを実行することのできる任意のマシーンであってもよい。
【０２１２】
[00254]コンピュータシステム４９００は、プロセッサ４９０２、メインメモリ４９０４、及び静的メモリ４９０６を備えている。これらはバス４９０８を介して相互に通信する。コンピュータシステム４９００は、更に、ビデオディスプレイユニット４９１０（例えば、液晶ディスプレイ（ＬＣＤ）又は陰極線管（ＣＲＴ））を備えていてもよい。コンピュータシステム４９００は、更に、英数字入力デバイス４９１２（例えば、キーボード）、カーソル制御デバイス４９１４（例えば、マウス）、ディスクドライブユニット４９１６、信号生成デバイス４９２０（例えば、スピーカ）、及びネットワークインタフェースデバイス４９２２を備えている。
【０２１３】
[00255]ディスクドライブユニット４９１６は、コンピュータ読み取り可能媒体４９２４を有し、当該媒体４９２４には、上に説明した方法の一つ又は全てを具現化した命令セット（即ち、ソフトウェア）４９２６が記憶される。ソフトウェア４９２６は、更に、メインメモリ４９０４及び／又はプロセッサ４９０２中に、全部又は少なくとも部分的に存在するように示してある。ソフトウェア４９２６は、更に、ネットワークインタフェースデバイス４９２２を介して送信又は受信されてもよい。本明細書の意図では、「コンピュータ読み取り可能媒体」との用語は、コンピュータによって実行される命令シーケンスを記憶又は符号化することができ、また本発明の方法の任意の一つをコンピュータに実行させる任意の媒体を含むものと解釈されるべきである。したがって、「コンピュータ読み取り可能媒体」との用語は、これらに限定されないが、ソリッドステートメモリ、光及び磁気ディスク、及び搬送波信号を含むものと解釈されるべきである。
【０２１４】
[00256]以上の説明を読んだ後には、当業者には、本発明の多くの代替及び変更が明らかになるであろうが、例示のために図示及び説明した特定の実施形態は、限定するものと考えられることを決して意図したものではないことを理解されたい。したがって、様々な実施形態の詳細部分への言及は、特許請求の範囲を限定するように意図したものではない。特許請求の範囲は、それら自身、発明に必須であると考えられる特徴のみを列挙している。
【図面の簡単な説明】
【０２１５】
【図１】再設定可能ソフトウェアの動的構築を容易にするシステムの一実施形態のブロック図である。
【図２Ａ】ソフトウェアを動的に構築するプロセスの一実施形態の流れ図である。
【図２Ｂ】ソフトウェア構築システムの一実施形態のブロック図である。
【図３Ａ】マイクロビルディングブロック（ＭＢＢ）の例示のオペレーションを示す図である。
【図３Ｂ】ＭＢＢの構造の一実施形態のブロック図である。
【図３Ｃ】ＭＢＢ用の例示的なＸＭＬ記述ファイルを示す図である。
【図４Ａ】例示的なインタプリタ型アクションを示す図である。
【図４Ｂ】例示的なコンパイル型アクションを示す図である。
【図４Ｃ】インタプリタ型アクション及びコンパイル型アクションの定義を提供する例示的なＸＭＬ記述ファイルを示す図である。
【図５Ａ】ドメインの例示的な構造を示す図である。
【図５Ｂ】ドメインの例示的な階層編成を示す図である。
【図５Ｃ】ソフトウェアアーキテクチャの定義を提供する例示的なＸＭＬ記述ファイルを示す図である。
【図５Ｄ】ドメイン用のソフトウェア構造の定義を提供する例示的なＸＭＬ記述ファイルを示す図である。
【図６】インタプリタ型アクションを実行するプロセスの一実施形態の流れ図である。
【図７】インタプリタ型アクションの例示的な実行を示す図である。
【図８Ａ】ドメインの一実施形態のブロック図である。
【図８Ｂ】例示的なタプルコンテナを示す図である。
【図９】ドメインで使用されるプロトコルの集合を示す図である。
【図１０】ドメインで使用されるプロトコルの集合を示す図である。
【図１１】ドメインで使用されるプロトコルの集合を示す図である。
【図１２】ドメインで使用されるプロトコルの集合を示す図である。
【図１３】ドメインで使用されるプロトコルの集合を示す図である。
【図１４】ドメインで使用されるプロトコルの集合を示す図である。
【図１５】ドメインで使用されるプロトコルの集合を示す図である。
【図１６】ドメインで使用されるプロトコルの集合を示す図である。
【図１７】ドメインで使用されるプロトコルの集合を示す図である。
【図１８】ドメインで使用されるプロトコルの集合を示す図である。
【図１９】ドメインで使用されるプロトコルの集合を示す図である。
【図２０】ドメインで使用されるプロトコルの集合を示す図である。
【図２１】ドメインで使用されるプロトコルの集合を示す図である。
【図２２】プログラムを再設定可能なソフトウェアへ変換するプロセスの一実施形態の流れ図である。
【図２３Ａ】プログラムを再設定可能なソフトウェアへ変換するプロセスの一実施形態の流れ図である。
【図２３Ｂ】プログラムを再設定可能なソフトウェアへ変換するプロセスの一実施形態の流れ図である。
【図２４】プログラムを再設定可能なソフトウェアへ変換するプロセスの一実施形態の流れ図である。
【図２５】パラメータアクセスを示す図である。
【図２６】最適化機能を実装するビルディングブロックのセットの一実施形態のブロック図である。
【図２７】パラメータインデックス生成器の一実施形態についてのデータフローを示す図である。
【図２８】ラッパー生成器の一実施形態を示す図である。
【図２９】Ｊａｖａマイクロビルディングブロック（ＭＢＢ）ラッパーの例を示す図である。
【図３０】ＭＢＢ  ＸＭＬ記述ファイルの例を示す図である。
【図３１】三つのパラメータにアクセスする例示的なコードを示す図である。
【図３２】パラメータマッピングアイテムの例を示す図である。
【図３３Ａ】新しいパラメータを登録してインデックスを取得するプロトコルの一実施形態の流れ図である。
【図３３Ｂ】新しいパラメータを登録してインデックスを取得するプロトコルの一実施形態の流れ図である。
【図３４】パラメータ除去プロトコルの一実施形態の流れ図である。
【図３５】ＭＢＢラッパーを自動的に生成するプロトコルの一実施形態の流れ図である。
【図３６】パラメータインデックスを初期化するプロセスの一実施形態の流れ図である。
【図３７】例示的な再設定可能通信ミドルウェアサービスの構築を示す図である。
【図３８】例示的な再設定可能通信ミドルウェアサービスの構築を示す図である。
【図３９】例示的な再設定可能通信ミドルウェアサービスの構築を示す図である。
【図４０】ソフトリアルタイムスケジューリングシステムの一実施形態のブロック図である。
【図４１】入力及び出力パラメータを有するアクションリソース利用推定ユニットの一実施形態を示す図である。
【図４２】アクションスケジューラの一実施形態を示す図である。
【図４３】ソフトリアルタイムスケジューラの一実施形態についてのブロック図及び呼び出しシーケンスである。
【図４４】アクションの実行時間を推定するアクションリソース利用推定アルゴリズムの一実施形態を示す図である。
【図４５】ソフトリアルタイム保証を有するようにアクションをスケジュールするプロトコルの一実施形態を示す図である。
【図４６】「デバイス当たりの」モデルを示す図である。
【図４７】「プロセス当たりの」モデルを示す図である。
【図４８】利用の例のシナリオを示す図である。
【図４９】コンピュータシステムの実施形態のブロック図である。
【図１】
2008524719.tif 000005
【図２Ａ】
2008524719.tif 000006
【図２Ｂ】
2008524719.tif 000007
【図３Ａ】
2008524719.tif 000008
【図３Ｂ】
2008524719.tif 000009
【図３Ｃ】
2008524719.tif 000010
【図４Ａ】
2008524719.tif 000011
【図４Ｂ】
2008524719.tif 000012
【図４Ｃ】
2008524719.tif 000013
【図５Ａ】
2008524719.tif 000014
【図５Ｂ】
2008524719.tif 000015
【図５Ｃ】
2008524719.tif 000016
【図５Ｄ】
2008524719.tif 000017
【図６】
2008524719.tif 000018
【図７】
2008524719.tif 000019
【図８Ａ】
2008524719.tif 000020
【図８Ｂ】
2008524719.tif 000021
【図９】
2008524719.tif 000022
【図１０】
2008524719.tif 000023
【図１１】
2008524719.tif 000024
【図１２】
2008524719.tif 000025
【図１３】
2008524719.tif 000026
【図１４】
2008524719.tif 000027
【図１５】
2008524719.tif 000028
【図１６】
2008524719.tif 000029
【図１７】
2008524719.tif 000030
【図１８】
2008524719.tif 000031
【図１９】
2008524719.tif 000032
【図２０】
2008524719.tif 000033
【図２１】
2008524719.tif 000034
【図２２】
2008524719.tif 000035
【図２３Ａ】
2008524719.tif 000036
【図２３Ｂ】
2008524719.tif 000037
【図２４】
2008524719.tif 000038
【図２５】
2008524719.tif 000039
【図２６】
2008524719.tif 000040
【図２７】
2008524719.tif 000041
【図２８】
2008524719.tif 000042
【図２９】
2008524719.tif 000043
【図３０】
2008524719.tif 000044
【図３１】
2008524719.tif 000045
【図３２】
2008524719.tif 000046
【図３３Ａ】
2008524719.tif 000047
【図３３Ｂ】
2008524719.tif 000048
【図３４】
2008524719.tif 000049
【図３５】
2008524719.tif 000050
【図３６】
2008524719.tif 000051
【図３７】
2008524719.tif 000052
【図３８】
2008524719.tif 000053
【図３９】
2008524719.tif 000054
【図４０】
2008524719.tif 000055
【図４１】
2008524719.tif 000056
【図４２】
2008524719.tif 000057
【図４３】
2008524719.tif 000058
【図４４】
2008524719.tif 000059
【図４５】
2008524719.tif 000060
【図４６】
2008524719.tif 000061
【図４７】
2008524719.tif 000062
【図４８】
2008524719.tif 000063
【図４９】
2008524719.tif 000064
【手続補正書】
【提出日】平成19年7月25日(2007.7.25)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
複数のアプリケーションコンポーネント、及び該複数のアプリケーションコンポーネント間の対話規則を指定する情報を取得するローダと、
ソフトリアルタイム保証を実行時に提供するように実行するために、ソフトウェアロジックデータに基づいて、前記複数のアプリケーションコンポーネントの呼び出しを調整するスケジューラと、
を備える装置。
【請求項２】
前記スケジューラが、前記複数のアプリケーションコンポーネントに関連する実行時間の上限を算出する、請求項１に記載の装置。
【請求項３】
前記スケジューラが、更に、リソース使用推定ユニットを含み、該リソース使用推定ユニットが、アプリケーションパラメータ及びプロファイルデータに応答して、前記複数のアプリケーションコンポーネントの各々のリソース利用推定値を生成する、請求項１に記載の装置。
【請求項４】
前記リソース使用推定ユニットが、リソース使用推定信頼値に応答して前記推定値を生成する、請求項３に記載の装置。
【請求項５】
前記プロファイルデータを作成する実行プロファイラを更に備え、
前記プロファイルデータが、前記複数のアプリケーションコンポーネントの各々によって使用されるリソースに対応する、
請求項４に記載の装置。
【請求項６】
前記実行プロファイラが、前記複数のアプリケーションコンポーネントの各々のリソース消費量を算出及び記憶することによって、プロファイルデータを作成する、請求項４に記載の装置。
【請求項７】
前記リソース消費量が、実行時間、プロセッサ利用量、メモリ、及び帯域幅のうち一つ以上を含む、請求項６に記載の装置。
【請求項８】
前記実行プロファイルがアプリケーションコンポーネントである、請求項４に記載の装置。
【請求項９】
アクションスケジューラを更に備え、該アクションスケジューラが、依存性グラフに従って、且つ、入力時間フレーム及びリソース利用量の推定値に基づいて、アプリケーションコンポーネントの実行を周期的にスケジュールする、請求項１に記載の装置。
【請求項１０】
前記推定値が、リソース使用推定ユニットから得られる、請求項９に記載の装置。
【請求項１１】
前記時間フレームが、デッドライン及び期間から成る群から選択される一つである、請求項９に記載の装置。
【請求項１２】
前記複数のコンポーネントの前記入力時間フレーム内での実行を可能とするのに十分なリソースが存在する場合に、前記スケジューラが前記複数のコンポーネントの実行をスケジュールする、請求項９に記載の装置。
【請求項１３】
前記複数のコンポーネントの前記入力時間フレーム内での実行を可能とするのに十分なリソースが存在しない場合に、前記スケジュールが例外を発生する、請求項１２に記載の装置。
【請求項１４】
一以上のアプリケーションコンポーネントの別の集合を指示するユニットを更に備え、
該一以上のアプリケーションコンポーネントの他の集合は、前記複数のコンポーネントの前記入力時間フレーム内での実行を可能とするのに十分なリソースが存在しない場合に、実行時に前記複数のコンポーネントによって提供される機能と類似した機能を提供する、
請求項１２に記載の装置。
【請求項１５】
一以上のアプリケーションコンポーネントから成るグループをスケジュールするための要求を受け取るステップと、
アプリケーションパラメータ及びプロファイルデータに応答して、前記一以上のアプリケーションコンポーネントから成るグループについてリソース利用推定値を取得するステップと、
依存性グラフに従って、且つ、前記リソース利用推定値に基づいて、一以上のアプリケーションコンポーネントから成るグループの実行を周期的にスケジュールするステップと、
ソフトリアルタイム保証を実行時に提供するように一以上のアプリケーションコンポーネントを実行するステップと、
を含む方法。
【請求項１６】
アプリケーションパラメータ及びプロファイルデータに応答して、前記複数のアプリケーションコンポーネントの各々についてリソース利用推定値を生成するステップを更に含む、請求項１５に記載の方法。
【請求項１７】
前記推定値を生成するステップが、リソース使用推定信頼値に応答して実行される、請求項１６に記載の方法。
【請求項１８】
前記複数のアプリケーションコンポーネントの各々のリソース消費量を算出及び記憶することによって、プロファイルデータを作成するステップを更に含む、請求項１６に記載の方法。
【請求項１９】
前記リソース消費量が、実行時間、プロセッサの利用量、メモリ、及び帯域幅のうち一つ以上を含む、請求項１８に記載の方法。
【請求項２０】
前記一以上のアプリケーションコンポーネントから成るグループの実行をスケジュールするステップが、依存性グラフに従って、且つ、入力時間フレーム及びリソース利用量の推定値に基づいて、アプリケーションコンポーネントの実行を周期的にスケジュールするステップを含む、請求項１５に記載の方法。
【請求項２１】
前記時間フレームが、デッドライン及び期間から成る群から選択された一つである、請求項２０に記載の方法。
【請求項２２】
一以上のアプリケーションコンポーネントから成るグループの実行をスケジュールするステップが、前記入力時間フレーム中の実行を可能とするのに十分なソースが存在する場合に、前記複数のコンポーネントの実行をスケジュールすることを含む、請求項２０に記載の装置。
【請求項２３】
前記複数のコンポーネントの前記入力時間フレーム内での実行を可能とするのに十分なリソースが存在しない場合に、例外を発生するステップを更に含む、請求項２２に記載の方法。
【請求項２４】
一以上のアプリケーションコンポーネントの他の集合を特定するステップを更に含み、該集合は、前記複数のコンポーネントの前記入力時間フレーム内での実行を可能とするのに十分なリソースが存在しない場合に、実行時に前記複数のコンポーネントによって提供される機能と類似した機能を提供する、請求項２３に記載の方法。
【請求項２５】
命令を記憶する記録可能媒体を有する製造品であって、
該命令が、システムによる実行時に、
複数のアプリケーションコンポーネントの各々によって使用されるリソースに関するプロファイルデータを作成するステップと、
アプリケーションパラメータ及び前記プロファイルデータに応答して、前記複数のアプリケーションコンポーネントの各々についてリソース利用推定値を生成するステップと、
依存性グラフに従って、且つ、リソース利用推定値に基づいて、アプリケーションコンポーネントの実行を周期的にスケジュールするステップと、
を含む方法を前記システムに実行させる製造品。
【国際調査報告】
2008524719.tif 000065
2008524719.tif 000066
2008524719.tif 000067