(57)【特許請求の範囲】
【請求項１】
少くとも２種のコンピュータから選ばれた、少くとも２つの相互接続されたコンピュータにおいて実行されるアプリケーションプログラムを設計する方法であって、該方法は、
各々別の種類の第１の複数のコンピュータを含む第一のクラスのコンピュータを選定する工程と、
各々別の種類の第２の複数のコンピュータを含む第２のクラスのコンピュータを選定する工程とを含み、
該第２の複数のコンピュータのどの１つも該第１の複数のコンピュータの任意の１つと接続可能とし、前記方法はさらに、
アプリケーションプログラムのための論理的なアプリケーションの定義を準備する工程を含み、この論理的なアプリケーションの定義は、
第１サービスオブジェクトを定義する工程と、
第２サービスオブジェクトを定義する工程と、
第３サービスオブジェクトを定義する工程とを含み、それにより該第１、第２、第３サービスオブジェクトの各々が他のサービスオブジェクトの少くとも１つと通信しうるようにし、
該第１サービスオブジェクトは、該第１の複数のコンピュータの実質的にどの１つにおいても実行可能とし、該第２のサービスオブジェクトは該第２の複数のコンピュータの実質的にどの１つにおいても実行可能とし、該第３サービスオブジェクトは、該第１の種類のコンピュータの実質的にどの１つにおいても、また該第２の種類のコンピュータの実質的にどの１つにおいても実行可能とするが、
論理的なアプリケーションの定義を作成する際には、前記第１のサービスオブジェクトを実行するべき前記第１の複数のコンピュータの特定の１つ、又は前記第２のサービスオブジェクトを実行するべき前記第２の複数のコンピュータの特定の１つ、又は前記第３のサービスオブジェクトを実行するべき前記第１の複数のコンピュータの特定の１つ又は前記第２の複数のコンピュータの特定の１つは選択しないことを含む、アプリケーションプログラムの設計方法。
【請求項２】
前記第１サービスオブジェクトと前記第２サービスオブジェクトとの間に情報を伝送するためメッセージをパスさせるメッセージ伝送のための第１手段を定義することを更に含む請求の範囲第１項記載のアプリケーションプログラムの設計方法。
【請求項３】
前記第２の複数のコンピュータの実質的にどの１つにおいても実行可能であり、前記第１サービスオブジェクトとの間で通信を中継するために前記第１サービスオブジェクトに接続可能でありまた連通される、第１サービスオブジェクトリクエストブローカーを定義することを更に含む請求の範囲第１項記載のアプリケーションプログラムの設計方法。
【請求項４】
前記第１の複数のコンピュータの実質的にどの１つにおいても実行可能であり、前記第２サービスオブジェクとの間で通信を中継するために前記第２サービスオブジェクトに接続可能でありまた連通される、第２サービスオブジェクトリクエストブローカーを定義することを更に含む請求の範囲第３項記載のアプリケーションプログラムの設計方法。
【請求項５】
前記第１の複数のコンピュータの実質的にどの１つにおいても実行可能であると共に、前記第２の複数のコンピュータの実質的にどの１つにおいても実行可能である第三サービスオブジェクトリクエストブローカーを定義することを更に含み、該第三オブジェクトリクエストブローカーは、前記第３サービスオブジェクトとの間で通信を中継するために前記第３サービスオブジェクトに接続可能でありまた連通される、請求の範囲第４項記載のアプリケーションプログラムの設計方法。
【請求項６】
前記第２又は第３のサービスオブジェクトから前記第１サービスオブジェクトリクエストブローカーに、第１メッセージをパスし、次に第２の対応するメッセージを前記第１サービスオブジェクトに送るための、第２のメッセージ伝送手段を定義することを更に含む請求の範囲第５項記載のアプリケーションプログラムの設計方法。
【請求項７】
メッセージを、前記第２又は第３サービスオブジェクトから前記第１サービスオブジェクトへ、該メッセージを格納する前記第１サービスオブジェクトリクエストブローカーにメッセージを送ることによって、非同期的にパスさせ、次に該メッセージを該第１サービスオブジェクトに送るための手段を定義することを更に含む請求の範囲第５項記載のアプリケーションプログラムの設計方法。
【請求項８】
前記第１、第２及び第３のサービスオブジェクトリクエストブローカーを定義すると共に、前記第１、第２及び第３のサービスオブジェクトが単一の物理的アドレススペースにあるかのように前記アプリケーションプログラムを走らせるのに必要な、前記第１、第２及び第３のサービスオブジェクトの各１つと前記第１、第２及び第３のサービスオブジェクトブローカーとの間の通信を定義することを更に含む請求の範囲第５項記載のアプリケーションプログラムの設計方法。
【請求項９】
前記第１のクラスのコンピュータは、ワークステーション、パーソナルコンピュータ、ラップトップコンピュータ、パートトップコンピュータ及びパーソナルデジタルアシスタントから成る群より選ばれた１以上のコンピュータである請求の範囲第１項記載のアプリケーションプログラムの設計方法。
【請求項１０】
前記第２のクラスのコンピュータは、メインフレーム、ミニコンピュータ、スーパーミニコンピュータ、ワークステーション及びパーソナルコンピュータから成る群より選ばれた１以上のコンピュータを含む請求の範囲第９項記載のアプリケーションプログラムの設計方法。
【請求項１１】
前記第１及び第２のコンピュータがそれぞれ第1CPU及び該第1CPUに強く結合された第2CPUである請求の範囲第１項記載のアプリケーションプログラムの設計方法。
【請求項１２】
前記第１のクラスのコンピュータがユーザーインターフェイスを支援する請求の範囲第１項記載のアプリケーションプログラムの設計方法。
【請求項１３】
前記第２のクラスのコンピュータ中の第１のコンピュータがサーバーを含む請求の範囲第１項記載のアプリケーションプログラムの設計方法。
【請求項１４】
前記第１のコンピュータがクライアントであり、前記第２のコンピュータがサーバーである請求の範囲第１項記載のアプリケーションプログラムの設計方法。
【請求項１５】
前記第１のコンピュータが第１サーバーであり、前記第２のコンピュータが第２サーバーである請求の範囲第１項記載のアプリケーションプログラムの設計方法。
【請求項１６】
アプリケーションプログラムをロードするための方法であって、該方法は請求の範囲第１項に記載の方法を用いてアプリケーションプログラムを設計することを含み、更に、
該アプリケーションが実行され得る異質的な環境を供与する工程を含み、該異質的な環境は、前記第１のクラスのコンピュータから選定された第１のコンピュータと、前記第２のクラスのコンピュータから選定された第２のコンピュータとを有し、該第２のコンピュータは、前記第１のコンピュータと接続され、該第２のコンピュータは、該第１のコンピュータと異なる形式であり、前記方法は更に、
該異質の環境を選定する工程と、
前記第１コンピュータに前記第１サービスオブジェクトをロードする工程と、
前記第２コンピュータに前記第２サービスオブジェクトをロードする工程と、
前記第１コンピュータに前記第３サービスオブジェクトをロードする工程とを含むアプリケーションプログラムをロードするための方法。
【請求項１７】
請求の範囲第16項の方法を用いてアプリケーションプログラムをロードする工程を含み、更に、該アプリケーションプログラムを実行するために、前記第１、第２及び第３のサービスオブジェクトの各々を実行することを含むアプリケーションプログラムの実行方法。
【請求項１８】
該第３サービスオブジェクトを該第１コンピュータから第２コンピュータへ移動させることを更に含む請求の範囲第17項記載のアプリケーションプログラムの実行方法。
【請求項１９】
前記第２コンピュータ上で前記第３サービスオブジェクトを複製することを更に含む請求の範囲第17項記載のアプリケーションプログラムの実行方法。
【請求項２０】
前記第３サービスオブジェクトを複製第３サービスオブジェクトとして複製し、前記第２コンピュータ上で実行するように前記複製第２オブジェクトをロードすることを更に含む請求の範囲第17記載のアプリケーションプログラムの実行方法。
【請求項２１】
前記第３サービスオブジェクトと複製第３サービスオブジェクトとを共に実行してロードを平衡させることを更に含む請求の範囲第20項記載のアプリケーションプログラムの実行方法。
【請求項２２】
前記第３サービスオブジェクト及び複製第３オブジェクトを使用して欠陥の許容（fault tolerance）を供与することを更に含む請求の範囲第20項記載のアプリケーションプログラムの実行方法。
【請求項２３】
前記複製第３サービスオブジェクトの実行開始後に前記第３サービスオブジェクトを不活性にすることを更に含む請求の範囲第20項記載のアプリケーションプログラムの実行方法。
【請求項２４】
アプリケーションプログラムをロードする方法であって、該方法は、請求の範囲第１項記載の方法を用いてアプリケーションプログラムを設計することを含み、更に、
該アプリケーションを実行しうる異質の環境を供与することを含み、該異質の環境は、前記第１のクラスのコンピュータから選択された第１のコンピュータと、前記第２のクラスのコンピュータから選択された第２のコンピュータとを含み、該第２のコンピュータは、該第１のコンピュータと相互接続され、該第２のコンピュータは、該第１のコンピュータと異なった形式であり、更に、
前記異質の環境を選定する工程と、
前記第１サービスオブジェクトを前記第１コンピュータにロードする工程と、
前記第２のサービスオブジェクトを前記第２コンピュータにロードする工程と、
前記第３のサービスオブジェクトを前記第１のコンピュータ又は第２のコンピュータに選択的にロードする工程とを含むアプリケーションプログラムをロードする方法。
【請求項２５】
アプリケーションプログラムを実行する方法であって、該方法は、請求の範囲第24項記載の方法を用いてアプリケーションプログラムをロードすることを含み、更に、
該アプリケーションプログラムを実行するために、前記第１、第２及び第３サービスオブジェクトの各々を実行することを含むアプリケーションプログラムの実行方法。
【請求項２６】
少くとも２つのクラスのコンピュータから選択された、相互接続されたコンピュータ上に、アプリケーションプログラムをロード方法であって、該方法は、
各々異なった形式の、第１の複数のコンピュータを含む、第１のクラスのコンピュータを選定する工程と、
各々異なった形式の、第２の複数のコンピュータを含む、第２のクラスのコンピュータを選定する工程とを含み、該第２の複数のコンピュータのいずれか１つは、該第１の複数のコンピュータのいずれか１つと相互接続可能とし、前記方法はさらに、
アプリケーションプログラムのための、論理的なアプリケーションの定義を準備する工程を含み、この定義が、
第１のサービスオブジェクトと、
第２のサービスオブジェクトと、
第３のサービスオブジェクトとを含み、
該第１、第２及び第３のサービスオブジェクトの各々は、他の前記サービスオブジェクトの少くとも１つと通信可能であり、
前記第１のサービスオブジェクトは、前記第１の複数のコンピュータの実質的にどの１つにおいても実行可能であり、
前記第２のサービスオブジェクトは、前記第２の複数のコンピュータの実質的にどの１つにおいても実行可能であり、
前記第３のサービスオブジェクトは、前記第１の複数のコンピュータの実質的にどの１つにおいても、また前記第２の複数のコンピュータの実質的にどの１つにおいても実行可能であるが、
前記論理的なアプリケーションの定義を準備する時において、前記第１サービスオブジェクトを実行すべき前記第１の複数のコンピュータの特定の１つ、前記第２サービスオブジェクトを実行すべき前記第２の複数のコンピュータの特定の１つ、又は前記第３サービスオブジェクトを実行すべき前記第１の複数のコンピュータの特定の１つ又は前記第２の複数のコンピュータの特定の１つを選択せず、
前記アプリケーションをその各々において独立して実行することのできる複数の異質の複数の環境を提供し、
各々の異質の環境は、
前記第１の複数のコンピュータから選定された、前記異質の環境のための第１のコンピュータと、
前記第２の複数のコンピュータから選択され、前記異質の環境のための前記第１コンピュータと相互接続された、前記異質の環境のための第２のコンピュータとを含み、
前記複数の異質の環境の、第１の異質の環境を選定し、
前記第１の環境の前記第１コンピュータに前記第１サービスオブジェクトをロードし、
前記第１の異質の環境の前記第２のコンピュータ上に、前記第２サービスオブジェクトをロードし、
前記第１の異質の環境の前記第１コンピュータ上又は第２コンピュータ上に、前記第３サービスオブジェクトを選択的にロードし、
前記複数の異質の環境のうちの第２の異質の環境を選定し、
該第２の異質の環境の、前記第１コンピュータ上に、前記第１サービスオブジェクトをロードし、
該第２の異質の環境の、前記第２コンピュータ上に、前記第２サービスオブジェクトをロードし、
前記第１の異質の環境中に第３サービスオブジェクトを選択的にロードすることと独立して、前記第２の異質の環境の前記第１コンピュータ又は第２コンピュータの１つに、前記サービスオブジェクトを選択的にロードすることを含むアプリケーションプログラムをロードする方法。
【請求項２７】
アプリケーションプログラムを実行する方法であって、該方法は、請求の範囲第26項の方法を用いてアプリケーションプログラムをロードすることを含み、更に、
前記第１の異質の環境中において前記アプリケーションプログラムを実行するために、前記第１、第２及び第３のサービスオブジェクトの各々を実行することを含むアプリケーションプログラムを実行する方法。
【請求項２８】
アプリケーションプログラムを実行する方法であって、該方法は、請求の範囲第26項の方法を用いてアプリケーションプログラムをロードすることを含み、更に、
前記第２の異質の環境中において前記アプリケーションプログラムを実行するために、前記第１、第２及び第３のサービスオブジェクトの各々を実行することを含むアプリケーションプログラムの実行方法。
【請求項２９】
前記第１の異質の環境の前記第１のコンピュータに前記第３サービスオブジェクトをロードすることを更に含む、請求の範囲第26項記載のアプリケーションプログラムを実行する方法。
【請求項３０】
前記第１の異質の環境の前記第１のコンピュータから第２のコンピュータに前記第３のサービスオブジェクトを移動させることを更に含む請求の範囲第29項記載のアプリケーションプログラムを実行する方法。
【請求項３１】
前記第１の異質の環境中において前記第１のコンピュータ上において実行するべき前記第３のサービスオブジェクトを選択し、前記第２の異質の環境に比較して前記第１の異質の環境において前記アプリケーションプログラムの全体的な作動を変えることなく、前記異質の環境中において前記第２のコンピュータ上において実行するべき前記第３のサービスオブジェクトを選択することを含む請求の範囲第29項記載のアプリケーションプログラムの実行方法。
【請求項３２】
少くとも２つのクラスのコンピュータから選択された少くとも２つの相互接続されたコンピュータ上においてアプリケーションプログラムを実行する方法であって、該方法は、
各々異なる形式の第１の複数のコンピュータから成る、第１のクラスのコンピュータを選定する工程と、
各々異なる形式の第２の複数のコンピュータから成る第２のクラスのコンピュータを選定する工程とを含み、該第２の複数のコンピュータのどれも前記第１の複数のコンピュータのどれか１つと相互接続可能であり、前記方法はさらに、
アプリケーションプログラムのための論理的なアプリケーションの定義を準備する工程を含み、該論理的なアプリケーションの定義は、
第１のサービスオブジェクトを定義する工程と、
第２のサービスオブジェクトを定義する工程と、
第３のサービスオブジェクトを定義する工程とを含み、
該第１、第２及び第３のサービスオブジェクトは、他の該サービスオブジェクトの少くとも１つと通信可能であり、
前記第１サービスオブジェクトは、前記第１の複数のコンピュータの実質的にいずれか１つにおいて実行でき、
前記第２サービスオブジェクトは、前記第２の複数のコンピュータの実質的にいずれか１つにおいて実行でき、
前記第３サービスオブジェクトは、前記第１の複数のコンピュータの実質的にいずれか１つにおいて、及び前記第２の複数のコンピュータの実質的にいずれか１つにおいて実行できるが、
論理的なアプリケーションの定義を準備する際に、前記第１サービスオブジェクトを実行するべき前記第１の複数のコンピュータの特定の１つ、前記第２サービスオブジェクトを実行するべき前記第２の複数のコンピュータの特定の１つ、又は前記第３サービスオブジェクトを実行するべき前記第１の複数のコンピュータの特定の１つ又は前記第２の複数のコンピュータの特定の１つは選択せず、
前記アプリケーションを実行しうる異質の環境を供与し、
前記異質の環境は、前記第１のクラスのコンピュータから選択された第１のコンピュータと、前記第２のクラスのコンピュータから選択された第２コンピュータとを含み、前記第２のコンピュータは、前記第１のコンピュータに相互接続され、前記第２のコンピュータは、前記第１のコンピュータと異なる形式であり、
前記の異質の環境を選択し、
前記第１サービスオブジェクトを前記第１コンピュータにロードし、
前記第２サービスオブジェクトを前記第２コンピュータにロードし、
前記第３サービスオブジェクトを前記第１コンピュータにロードし、
次に、前記第１、第２及び第３のサービスオブジェクトの各々を実行して前記アプリケーションプログラムを実行することを含むアプリケーションプログラムを実行する方法。
【請求項３３】
前記第３サービスオブジェクトを前記第１コンピュータから前記第２コンピュータに移動させることを更に含む請求の範囲第32項記載のアプリケーションプログラムを実行する方法。
【請求項３４】
前記第３サービスオブジェクトを前記第２コンピュータ上において複製することを更に含む請求の範囲第32項記載のアプリケーションプログラムを実行する方法。
【請求項３５】
前記第３サービスオブジェクトを前記第１コンピュータにロードせず、その代りに、該第３サービスオブジェクトを前記第１コンピュータ又は第２コンピュータのどちらか１つに選択的にロードする請求の範囲第32項記載のアプリケーションプログラムを実行する方法。
【請求項３６】
前記第１のクラスのコンピュータが、ワークステーション、パーソナルコンピュータ、ラップトップコンピュータ、パームトップコンピュータ及びパーソナルデジタルアシスタントから成る群中より選択された１以上のコンピュータを含む請求の範囲第32項記載のアプリケーションプログラムを実行する方法。
【請求項３７】
前記第２のクラスのコンヒュータが、メインフレーム、ミニコンピュータ、スーパーミニコンピュータ、ワークステーション及びパーソナルコンピュータから成る群中から選択された１以上のコンピュータを含む請求の範囲第32項記載のアプリケーションプログラムを実行する方法。
【請求項３８】
前記第１コンピュータがクライアントであり、前記第２のコンピュータがサーバーである請求の範囲第32項記載のアプリケーションプログラムを実行する方法。
【請求項３９】
前記第１サービスオブジェクトと前記第２サービスオブジェクトとの間に情報を伝送するためにメッセージをパスさせるためのメッセージ伝送のための第１手段を更に含む請求の範囲第32項記載のアプリケーションプログラムを実行する方法。
【請求項４０】
前記第２の複数のコンピュータの実質的にどれか１つにおいて実行でき、前記第１サービスオブジェクトとの間の通信の中継のために前記第１サービスオブジェクトと接続可能でまた交信可能な、第１サービスオブジェクトリクエストブローカーを定義することを更に含む請求の範囲第39項記載のアプリケーションプログラムを実行する方法。
【請求項４１】
前記第１サービスオブジェクトリクエストブローカーにメッセージを送り、該メッセージを格納し、次に該メッセージを前記第１サービスオブジェクトに送ることによって、前記第２又は第３サービスオブジェクトから前記第１サービスオブジェクトにメッセージを非同期的にパスさせる手段を更に定義することを含む請求の範囲第40項記載のアプリケーションプログラムを実行する方法。
【請求項４２】
少くとも２つのクラスのコンピュータから選定された少くとも２つの相互接続されたコンピュータ上において、アプリケーションプログラムを実行する方法であって、該方法は、
各々異なった形式の、第１の複数のコンピュータから成る、第１のクラスのコンピュータを選定する工程と、
各々異なった形式の、第２の複数のコンピュータから成る、第２のクラスのコンピュータを選定する工程とを含み、該第２の複数のコンピュータのどの１つも、前記第１の複数のコンピュータのいずれか１つと相互接続可能であり、
第１のサービスオブジェクトを選定し、
第２のサービスオブジェクトを選定し、
第３のサービスオブジェクトを選定し、
該第１、第２及び第３のサービスオブジェクトは、他の前記サービスオブジェクトの少くとも１つと通信可能であり、
前記第１のサービスオブジェクトは、前記第１の複数のコンピュータの実質的にどの１つにおいても実行可能であり、
前記第２のサービスオブジェクトは、前記第２の複数のコンピュータの実質的にどの１つにおいても実行可能であり、
前記第３のサービスオブジェクトは、前記第１の複数のコンピュータの実質的にどの１つにおいても実行可能であり、及び前記第２の複数のコンピュータの実質的にどの１つにおいても実行可能であり、
前記第１のクラスのコンピュータから選択された第１のコンピュータと前記第２のクラスのコンピュータから選択された第２のコンピュータとを含む異質の環境を供与し、該第２のコンピュータは、該第１のコンピュータと相互接続され、該第２のコンピュータは、該第１のコンピュータとは異なった形式のものであり、
前記異質の環境を選択し、
前記第１のサービスオブジェクトを前記第１のコンピュータ上にロードし、
前記第２のサービスオブジェクトを前記第２のコンピュータ上にロードし、
前記第１のコンピュータと第２のコンピュータとのいずれか１つに、前記第３のサービスオブジェクトを選択的にロードし、
次に前記第１、第２及び第３のサービスオブジェクトの各々を実行して前記アプリケーションプログラムを実行することを含むアプリケーションプログラムを実行する方法。
【請求項４３】
前記第３サービスオブジェクトを前記第１コンピュータから前記第２コンピュータに移動させることを更に含む請求の範囲第42項記載のアプリケーションプログラムを実行する方法。
【請求項４４】
前記第２のコンピュータ上において前記第３のサービスオブジェクトを複製することを更に含む請求の範囲第42項記載のアプリケーションプログラムを実行する方法。
【請求項４５】
前記第３サービスオブジェクトを前記第１コンピュータにロードすることを更に含む請求の範囲第42項記載のアプリケーションプログラムを実行する方法。
【請求項４６】
前記第１のクラスのコンピュータが、ワークステーション、パーソナルコンピュータ、ラップトップコンピュータ、パームトップコンピュータ及びパーソナルデジタルアシスタントから成る群中より選ばれた１以上のコンピュータである請求の範囲第42項記載のアプリケーションプログラムを実行する方法。
【請求項４７】
前記第２のクラスのコンピュータが、メインフレーム、ミニコンピュータ、スーパーミニコンピュータ、ワークステーション及びパーソナルコンピュータから成る群中より選ばれた１以上のコンピュータである請求の範囲第42項記載のアプリケーションプログラムを実行する方法。
【請求項４８】
前記第１コンピュータがクライアントであり、第２コンピュータがサーバーである、請求の範囲第42項記載のアプリケーションプログラムを実行する方法。
【請求項４９】
前記第１サービスオブジェクトと第２サービスオブジェクトとの間に情報を伝送するためにメッセージをパスするためのメッセージ伝送のための第１手段を更に定義する請求の範囲第42項記載のアプリケーションプログラムを実行する方法。
【請求項５０】
前記第２の複数のコンピュータの実質的に、どの１つにおいても実行可能であり、前記第１サービスオブジェクトとの間に通信を中継するために前記第１サービスオブジェクトと接続可能及び通信可能な、第１サービスオブジェクトリクエストブローカーを定義することを更に含む請求の範囲第49項記載のアプリケーションプログラムを実行する方法。
【請求項５１】
前記第１サービスオブジェクトリクエストブローカーにメッセージを送り、該メッセージを格納し、次に該メッセージを該第１サービスオブジェクトに送ることによって、前記第２サービスオブジェクトと第３サービスオブジェクトとのどちらか１つから前記第２サービスオブジェクトにメッセージを非同期的にパスさせる手段を更に有する請求の範囲第50項記載のアプリケーションプログラムを実行する方法。
【発明の詳細な説明】
発明の分野
本発明は、リアルタイムモニタリング及びパーティショニングの変更を含めて、オブジェクト指向プログラムのオブジェクトを多重コンピュータデバイスに渡ってパーティショニングする方法及び装置に関する。
発明の背景
コンピュータプログラムは、一般に、少くとも３つの成分、即ち、ユーザーインターフェイスと、アプリケーションプログラムと、メモリないし記憶装置から成っている。初期のコンピュータは、一次的なユーザーインターフェイスとして、テープリーダ又はカードリーダと、プリンタとを備えていた。プログラム又はアプリケーションは、中央処理装置で走るようにロードされ、メモリ又はディスク式記憶装置若しくはその両方によってデータを記憶していた。産業の成熟と共に、コンピュータは、端末装置と対話することができるようになり、別の重要なユーザーインターフェイスを供与した。ワークステーションと呼ばれる小型のコンピュータが利用できるようになり、同一のユニットによってユーザーインターフェイスと計算力とを供与するようになった。パーソナルコンピュータ（PC）の到来によって、多くのコンピュータ設備において廉価なコンピュータが単純な端末装置に代わるものとなった。
初期のコンピュータでは、プログラムは、単一のコンピュータのみに駐在することができた。大きなプログラムは、セグメントに分割し、これらのセグメントを必要に応じて中央処理ユニットのアクティブメモリにロードすることができた。コンピュータがより強力になるにつれて、大きなプログラムを走らせることができるようになったが、単一のコンピュータの能力がコンピュータプログラムのサイズの基本的な制限となっていた。
ワークステーション及びPCが普及するにつれて、利用可能な処理力を論理的な仕方で用いることによって効率を最大にすることを試みるパラダイムが成立した。多くのユーザーは、ワークステーション又はPCを介して大形のコンピュータとインターフェイスを取っていたので、プログラマーは、スクリーン上の再作図、ビデオリフレッシュ、グラフィック発生、ウィンドウ化制御（大きさ、位置、オーバーラップ）及び入力処理（文字、ファンクションキーの取扱い、インタラプトなど）のような、ユーザーインターフェイスの操作に必要な機能は、論理的には、ローカルワークステーションに常駐しているソフトウエアによって取扱われるべきであると認識した。多くのプログラムは、この理由付けに従って、コンピュータの記憶装置への広汎なアクセスを必要とする。この形式の従来のプログラムとしては、特別の記憶エリアに一連の記録を格納するデータベースがある。多くの産業によって利用されるデータベースの一つとしては、インベントリー（在庫）レコードがある。別のデータベースとして、ペイロール又は支払可能な口座が考えられる。一般に、最近のデータベースは、システムの記録エリアに格納された多数のレコードから成っている。複数のユーザーが同時にデータベースを使用することはできるが、同一のレコードを２人のユーザーが同時にアクセスすることを防止する処置が取られるべきである。その理由としては、両者が互に古い情報を更新し、首尾一貫しない変化をもたらしたり記憶させたりすることがあるからである。プログラマーは、情報の読書きやレコードロック、また使用可能なメモリ又は記憶装置が限られている場合、メディアの変更の特定、例えばディスクもしくはテープのような互換性のあるメディアの着脱、のために、レコードのアクセスを制御するサーバー機能を開発した。
ウィンドウ又はメニュー選択、グラフィックオブジェクト等のグラフィック情報の操作は、一般に、特にビットマップを取扱う場合、多量の情報の転送を必要とする。多くのコンピュータ間に分け合われる共通のネットワーク上に情報をパスさせる必要がある場合、ネットワークは、グラフィックイメージを移動させるトラフィックによって容易に占有される。同様に、特定の記憶メディアの選定、メディアの適正な位置への読出しヘッドの移動及びメディアからの情報の取出しに必要な低レベルのコマンドは、ユーザー又はプログラムが実際に必要とする全てが結果、典型的には、必要とされるレコードの内容の一部又は全部である場合に、コントローラと読出しヘッドとの間の相当な量のアクティビティを必要とする。
このパラダイムは、クライアント−サーバーとして知られるようになった。サーバーは、一般に、１以上の共有されるリソースの制御と、それへのアクセスとを供与する。１つの有用なサーバーは、前述したデータベースサーバーである。別の有用なサーバーは、ファイルサーバーであり、ここではサーバーは、プログラム、データ又は他のファイルにアクセスし、また要求によりこの情報にアクセスすることができる。プリントサーバーは、プリントジョブを収納したり、プリンタの集合体にプリントジョブを記憶及び指向けたりし、プリンタの集合体は、このサーバーへの簡単なコールによって、多数のユーザーにとってアクセス可能となる。
クライアント−サーバーの進展
クライアント−サーバーは、データベース運用システム（DBMS）技術時にリレーショナルデータベース運用システム（RDBMS）技術の進歩と共に急成長した。主要なマルチユーザーRDBMSのアーキテクチュアは、アプリケーションプログラムのユーザー特異の仕事とRDBMSエンジンの共有されるデータ運用サービスとの間の分離を供与する。このアーキテクチュアは、単一のRDBMSエンジンが同一のアプリケーションの複数のユーザー及び複数のアプリケーションにサービスすることを許容する。SQL（Structured Query Language）は、RDBMSサービスをリクエストする容易な方法をアプリケーションに与えると共に、データ運用のディテール（例えば、同時性制御、バックアップ及び回復、データアクセスストラテジーなど）からアプリケーションをシールドする。
RDBMSネットワーク生産物の到来と共に、アプリケーション間の通信のプロトコールとしてSQLを使用して、アプリケーションをホストからオフロードし、別の機械上におくことができるようになった。最初は、この技術は、２つのマルチタスクミニコンピュータ、即ちRDBMSエンジンを走らせるバックエンドのものと、ユーザーのダムターミナルを駆動するフロントエンドのものとの間において用いられた。PCが広く受け入れられるようになると、マルチタスクフロントエンド機械を、自分のフロントエンドアプリケーションプログラムのコピーをそれぞれ走らせるPCの集合体に代えることは、論理的なステップであった。
廉価なデスクトップ計算サイクルが、グラフィカルーユーザーインターフェイス（GUI）の多くのディテールをドライブするために使用されうるため、GUIの普及によって、クライアント−サーバーの適切さが更に固定された。
一方、RDBMSサーバーサイドでも、技術の進歩があった。RDBMSベンダーは、高性能及び高信頼性のマルチスレッデッドサーバーを今や供給している。あるベンダーは、予め定義されたSQLクエリーの処理を早めることのできる内蔵プロシージャを提供する。また多くのベンダーは、RDBMSベンダーのSQLダイアレクトをRDBMSに翻訳するゲートウェイ及び他のベンダーからのファイルシステムも提供する。
今日では、クライアント−サーバーは、ネットワークを通じて共有RDBMSにアクセスするアプリケーションプログラムを走らせるPCを意味するようになった。クライアント−サーバーは、フォーチュン1000社に受けいれられており、部局の決定支持アプリケーションのために現用されている。これらの会社は、クライアント−サーバーパラダイムを企業規模のオンラインアプリケーションに拡張することに関心をもっている。
モノリシックなクライアントアプリケーションプログラム
多くのクライアント−サーバーデベロッパは、今日では、クライアントとサーバーとの間の予め設定された計算機能の分割を受けいれている。最も普通に用いられる予め設定された分割を示す図1A,1Bを参照して、クライアントは、RDBMSに入出するデータのユーザーディスプレイ及びアプリケーション処理を取扱うアプリケーションプログラムを走らせる。アプリケーションプログラムは、SQLをRDBMSインターフェイス（クライアント上でも走る）に移行させる。RDBMSインターフェイスは次に、SQLを、ネットワークを横切ってRDBMSサーバーへと移動させる。RDBMSサーバーは、リクエストを処理し、リクエストされたデータ又はステータスメッセージを、RDBMSインターフェイスを経てアプリケーションプログラムに返送する。このモデルによれば、アプリケーションプログラムは、モノリシックであり、全体がクライアント側にのみ存在する。これが、クライアントアプリケーションプログラムである。データベースがアプリケーションプログラムから分離しているので、このモデルは、時に、遠隔データ運用と呼ばれる。クライアントとサーバーとの間に機能性を分割する別のモデルについて以下に説明する。
クライアントアプリケーションプログラムを構成する多くのハイレベルのツールが今日市販されている。これらのツールは、スクリーンデザイナーと、アプリケーションの機能性を定義するためのハイレベル言語（4GL−第４世代言語−と屡々呼ばれる）とを通常備えている。これらのツールの多くは、高速プロトタイピング、即ち、すみやかなプロトタイプを作成して後にそれを仕上げする対話方式のプロセスとしてアプリケーションを構成する能力を支援する。
モノリシックなクライアントアプリケーションプログラムは、単一のRDBMSを含む意志決定支援に非常に良く適合している。しかしクライアント上において全アプリケーションを走らせることには、より複雑なアプリケーションについては、多くの問題を提起する。これらの問題としては、
・複雑なアプリケーションプログラム全体を駆動するには、デスクトップ上の処理動力が適切でないこと、
・ネットワークの過大なトラフィックによって、動作が遅くなること、
・本来のRDBMS及びRDBMSベンダーのゲートウエイによって支援されているもの以外のデータソースとの対話が困難なこと、並びに
・マルチアプリケーション間のアプリケーション成分の再使用の可能性が最小なこと、が挙げられる。
協働処理（cooperative proceesing）
アプリケーションのパーティショニングは、協働処理（ネットワーク化環境においてアプリケーションの機能性を分割することを記述する包括的な用語）というより広い文脈において、最も良く理解される。アプリケーションのパーティショニングを協働処理と同義語として扱うことは不正確であろう。これらの用語の差異の理解は、本発明の思想の説明に役立つと思われる。この差異を明らかにするには、コネチカット州スタンフォードに所在する市場調査会社であるガートナーグループ（Gartner Group）により列挙された協働処理のいろいろのスタイルをチェックすることがひと先ず有用である。
ガートナーの協働処理スタイルの分類は、３つの計算機能−ユーザープレゼンテーションサービス、アプリケーションロジック及びデータ運用、を含むアプリケーションモデルに基づいている。これらの機能を複数のコンピュータの間に分割する方法のうち４つを以下に列挙する。各々は、種々のアプリケーション問題に対処するストラテジーを表わし、各々別の一組のツールによって支援されている。これらは全体として、自立形の、ホストに基づいた環境から、クライアント−サーバー環境に移行する際において、ISマネージャーが当面する選択肢のいくつかを表わしている。
遠隔データ運用  この機能分割は、プレゼンテーションサービス及びアプリケーションロジックをクライアント側におき、サーバーは、データ運用機能を逐行する。SQLはこれらの各部間の通信プロトコルである。図２参照のこと。
遠隔データ運用は、１組のユーザーが共有するリレーショナルデータベース（RDBMS）サーバーにアクセスするデスクトップアプリケーションと対話する主流データベースクライアント−サーバーアプリケーションの、非常に普通のモデルである。このモデルは、キャラクタ指向ユーザーインターフェイス又はグラフィックユーザーインターフェイス（GUI）と共に操作することができる。このモデルを利用するアプリケーション（例えばSQL＊Forms、Powerbuilder、Uniface及び他の4GL）を構成するために、今日多くのツールを使用することができる。
分散プレゼンテーション  屡々「フロントウエア」又は「スクリーンスクレーピング」と呼ばれるこのモデルは、アプリケーションのプレゼンテーション部分内の機能性の部分を支援する。分散プレゼンテーションは、3270スクリーンを駆動する従来のメインフレームアプリケーションを取り、PCデスクトップ上において走るGUIによるプレゼンテーションサービスのデベロッパーが付加することを許容する。図３参照のこと。3270データストリームは、複数の機械間の通信プロトコールとして用いられる。
分散プレゼンテーションは、組織体が、既存のアプリケーションへのユーザーインターフェイスをそのアプリケーションを変更することなくアップグレードすることを許容する。いくつかの市販品はこのアプローチを支援しており、遠隔データ運用を支援するものとは異なった製品である。
分散データ運用  このモデルは、アプリケーションのデータ運用部分内の機能の部分を支援する。このモデルにおいては、データは、１以上のコンピュータに存在することができ、分散データ運用製品は、どこに存在していても、透過性アプリケーションアクセスを保ちながら、データへアクセスを連係化する。図４を参照すると分散データベースは、各々のサーバーにどのテーブルがあるかを知り、それに従ってリクエストを指向させる。
分散データ運用は、クライアント上において走るアプリケーションが一つより多くのRDBMSサーバーに渡って分散されたデータにアクセスすることができる遠隔データ運用と共に使用することができる。RDBMSベンダーのあるものは、分散データ運用製品を提供している。分散データにアクセスするアプリケーションは、従来の4GLツールによって開発することができる。
分散機能  このモデルは、１より多くの機能上に存在するアプリケーションロジックを支援する。通信メカニズムは、遠隔プロシージャコール（RPC）又はより対話型の通信メカニズム（例えばIBMのAPPC又はCPI−Ｃ）。図５を参照のこと。
ガートナーグループは、その報文「クライアント／サーバー及び協働処理−困った人へのガイド（Client/Server and Cooperative Processing;a Guide for the Perplexed）」、1991において、「分散機能スタイルは、高度にユーザー対話形であると共にデータベースI/O集約形である複雑なアプリケーションにとって特に強力である。・・・機能がより適切な（ローカルな）ノードにあるため、Ａ（クライアント）とＢ（サーバー）との間のネットワーク上において送る必要のあるメッセージの数は、最小となり、それにより複雑なワークロードのための比較的高速の応答時間を可能とする」と述べている。ガートナーは、更に、「分散機能アプリケーションは、本来、設計し開発することの最も困難な協働処理アプリケーションである。それは、２つの別々にコンパイルされたアプリケーションが存在するためである。デベロッパーは、各々の機能がどこに存在するか、また２つのプログラムの間においてどんな形式の対話がなされねばならないか、を十分に分析しなければならない」と述べている。
本発明の方法の中心部分であるアプリケーションのパーティショニングは、前述した分散機能モデルを用いてアプリケーションの開発を単純化する技術である。前述した一般的なクライアント−サーバーパラダイムは、あるネットワークにおいて２以上のノードの間に計算機能を分割することに基づいている。コンピュータのタスクの分割によって、クライアント−サーバーは、将来に向かって支配的となるパラダイムとして、従来のホストに基づいた計算に代わる、融通性が高くまたコスト有効性の高い計算モデルを支援する。アプリケーションパーティショニングは、従来のクライアント−サーバー技術を越えて、クライアントとサーバーとの間にアプリケーションの機能性を割当てるアプローチを供与する。
計算機能の割当ては、性能、制御及び／又は融通性のための含蓄を各々に備えた多くのオプションを提示する。アプリケーションのパーティショニングを有効に取扱うには、ネットワーク中の多重プラットフォームに渡る機能の割当てに関連したいくつかの問題を考慮するべきである。最終的なゴールは、出来するビジネス上の問題を解決しうるより有効なクライアント−サーバーアプリケーションを推進することである。
発明の要約
本発明は、アプリケーションプログラムをパーティショニングする装置及び方法を提供する。開発プログラマーは、アプリケーションプログラムの部分として２以上のオブジェクトを定義することによって、アプリケーションプログラムのための、論理的なアプリケーションの定義を与える。この選択は、どんな特定的な機械環境がランタイムにおいて用いられるかを考慮せずに行われる。
オブジェクトがアプリケーションを動作させるに足るように詳細に定義されたら、アプリケーションの管理者は、少くとも２つの相互接続されたコンピュータを含めて、アプリケーションプログラムのための特定の環境を特定する。各々のオブジェクトは、１つのパーティションに割当てられ、各々のパーティションは、ターゲットコンピュータに割振られ、アプリケーションプログラムを走らせうるようにロードされる。このシステムは、最初のパーティショニングにおいてアプリケーションの管理者を助けるようにデフォルトパーティショニング計画を発生させることができる。その結果として、アプリケーションプログラムは、使用可能な計算リソース間の１つのコンピュータに各々割振られた一連のパーティションにパーティショニングされる。コンピュータによって選択された元のパーティショニングは、自動的にか、又はユーザーによって変更することができる。この変更は、１つのパーティションから次のパーティションに、オブジェクトを移動させたり、パーティション全体を複製したりすることを含みうる。本発明は、アプリケーションプログラムを操作するに当り、動作上の障害を自動的に検出し、適切な場合には、スループットを高め、システムの信頼性を高めるために、別の追加のコンピュータ上において走らせるべき１以上のオブジェクトを複製することも含む。
アプリケーションプログラムは、使用可能な装置上において走らせる特定のパーティションを割振ることによって、新しい環境において容易に走らせることができる。単一のアプリケーションプログラムは、特定のリソース及び特定の共通ロケーションにおけるニーズに基づいて、種々の異なったパーティショニング計画において、同一の会社の内部において走らせることもできる。
・クライアント−サーバーは、部局のストラテジーから企業規模のストラテジーに進展するので、アプリケーションのパーティショニングは、キーとなるストラテジーとなろう。
・アプリケーションのパーティショニングは、統合されたアプリケーションを創生し、さらにそれをネットワーク環境において異なるノードに実行する一組のモジュールに分割する能力である。
・アプリケーションのパーティショニングは、性能、制御及び融通性を高めるための重要なストラテジーとなりうる。
・パーティショニングは、企業のアプリケーションの新しい世代を支援するように、クライアント−サーバーモデルをてこ入れする。
・Forte'は、パーティショニングされたアプリケーションを開発し展開させるためのツールとして設計された。
【図面の簡単な説明】
図1A及び図1Bは、従来のモノリシックなクライアントアプリケーションプログラムを示す。
図２は、従来の遠隔データ運用モデルを示す。
図３は、分散プレゼンテーションモデルを示す。
図４は、分散データ運用モデルを示す。
図５は、分散機能モデルを示す。
図6A及び図6Bは、アプリケーションのパーティショニングを示す。
図７は、アプリケーションのパーティショニングの別の特徴を示す。
図８は、並行処理タスクを示す。
図９は、多重形態において単一の理論的なアプリケーションの定義の具体化を示す。
図10は、混合形態において単一の論理的なアプリケーションの定義の具体化を示す。
図11は、顧客サービスアプリケーションの方法の代表的な具体化を示す。
図12は、単一の製造プロセスアプリケーションの方法の代表的な具体化を示す。
図13は、別の製造アプリケーションの方法の代表的な具体化を示す。
図14は、会計サービスアプリケーションの方法の代表的な具体化を示す。
図15は、注文方式の生産物オーダー／入力アプリケーションの方法の代表的な具体化を示す。
図16は、新しい方法を用いたプログラム開発サイクルを示す。
図17A及び図17Bは、従来のプロシージャ及びサービスの集合としてのサンプルアプリケーションプログラムを示す。
図18は、新しい開発環境アーキテクチュアを示す。
図19は、パーティショニングによるサービスオブジェクトの分散を示す。
図20は、デフォルトパーティショニングを示す。
図21は、分散実行を示す。
図22は、分散アプリケーションをモニターするための環境マネージャーの使用を示す。
図23は、再パーティショニングインターフェイスを示す。
好ましい実施態様の説明
いくつかの一般的な定義と、システム全体の記述とが、本発明の理解を助けるであろう。
分散アプリケーション
分散アプリケーションは、単一の一体システムを通した分散された機械及びサービスへのアクセスを供与する。従来のクライアント−サーバーアプリケーションは、只２つの機械即ちデスクトップコンピュータ及びデータベースサーバー上において走るにすぎない。しかし新規な方法を用いたアプリケーションプログラムは、どんな数の異なる機械（只２つの機械でも多数の機械でも良い）上においても走ることができる。
単一のアプリケーションプログラムは、
・（任意の数の別々の機械上の）任意の数のデータベース
・ニューヨーク株式市場へのAPIのような3GLサービス、商業的な統計分析パッケージ、又は社内（in−house）開発による3GLアプリケーション、
・イメージサーバー又は連係化ファシリティのような新しいサービス
を含む、任意の数の分散サービスにアクセスすることができる。
また、新規なアプリケーションプログラムは、バックアップ及びロードシエアリング機械に自動的にアクセスすることによって、欠陥の容認（フォールトトレランス）及びパラレル処理も供与する。
パーティション
Forte'（新しい方法）は、アプリケーションを分散させるために、それを２つ以上の論理的な区画（パーティションと称する）に区分する。各々のパーティションは、それ自身の機械上において走ることのできる１つの独立したコンポーネントである。例えば、代表的エンドユーザアプリケーションは、グラフィカルユーザインタフェイスを提供し、通常デスクトップ上に設備されるクライアントパーティションを備える。他のパーティションは、メインフレーム上において走るDBMSサーバー、特殊化された機械上において走るイメージサーバー、3GLサービス、又は他の特別のサービスを含むことができる。好ましい実施において、本発明の方法は、パーティション間の全てのコミュニケーションを自動的に連係化する。
るパーティションは、１以上のサービスオブジェクトから成る。分散アプリケーションを作成するには、プロジェクトの一部分として、必要とされるすべてのサービスオブジェクトを定義することが必要となる。
サービスオブジェクト
Forte'アプリケーションプログラムは、オブジェクト（複数）から成っている。アプリケーションプログラムとが相互作用する各々の分散サービスは、オブジェクトである。例えば、アプリケーションプログラムからアクセスされるデータベースは、オブジェクトである。同様に、既存の3GLアプリケーションもオブジェクトである。オブジェクトと相互作用するには、ユーザー又は他のオブジェクトは、その上に方法を呼出す（invoke）。これは、アプリケーションプログラム中の他のオブジェクトと相互作用することと基本的に同様である。
分散アプリケーションにおいて、各々のオブジェクトは、単一の固定されたロケーションを有する。オブジェクト上に方法が呼出されると、その方法は、そのオブジェクトが配置されている機械上において実行される。オブジェクトは、通常は、それが作成された機械上に位置されている。各々のサービスオブジェクトは、後述するオブジェクトリクエストブローカーによって、他のパーティション上に表わすことができる。
アプリケーションは、何千個ものオブジェクトから成っていても良いが、ある特別のロケーションにあることが必要とされるのは数個にすぎない。これらには、
・特定の機械上に既に存在している、データベース管理システム又は3GLサービスのような、既存の外部資源を表わすオブジェクト、
・多重ユーザー例えばイメージサーバー（又はオークショニング機能のためのオークションマネージャー）によって分担されようとしているForteサービスを供与するオブジェクト、及び
・フェイルオーバー（failover）又はロードバランシングを与えるように複製されるサービスを表わすオブジェクト
が含まれる。
アプリケーションが複数のパーティションに区分される時、これらの中心サービスは、特定の機械上におかれることを必要としうるオブジェクトである。
アプリケーションプログラマーは、ある選択されたオブジェクトが「サービスオブジェクト」を作成しネーミングすることによって特定のパーティション上に配置されねばならないことを特定化することもできる。アプリケーションプログラマーは、アプリケーションプログラムにおいて他のオブジェクトのロケーションについて心配する必要はない。サービスオブジェクトが他のオブジェクトを生成する場合、これらは、その生成者と同一のパーティション上に位置されるであろう。便宜上、このアプリケーションの残部は、実際のサービスオブジェクトによって生成される関連オブジェクトを、「サービスオブジェクト」が含むことを想定するであろう。
サービスオブジェクトは、アプリケーションプログラム中のある方法から参照することの可能な、ネーミングされたオブジェクトにすぎない。これは、コンパイル時に値を特定しうることを除いては、グローバルな変数と同様である。サービスオブジェクトを生成する場合、それには、ネーム、クラス並びにその属性値が割当てられる。
一旦生成されると、サービスオブジェクトは、他のオブジェクトと同様に使用することができる。ユーザー又は他のオブジェクトが、遠隔した機械上に配置されたサービスオブジェクト上のある方法を呼出す場合、サービスオブジェクトのリクエストは、ローカルな「オブジェクトリクエストブローカー」を介して伝達される。ブローカーは、対応するサービスオブジェクトのインターフェイスを再現するので、サービスオブジェクト上にある方法が呼出される時、ローカルオブジェクトリクエストブローカーによって、全てのリクエストが引込まれ、次いで実際のサービスオブジェクトへ送られ、処理される。返送値及び出力パラメータは、オブジェクトリクエストブローカーを介して、元の呼出しオブジェクトに返送される。このように、遠隔した機械上に位置されたサービスオブジェクト上の方法の呼出しは、完全に透過性である。
１つの特別のサービスオブジェクトは、DBMS資源マネージャーであり、これは既存のデータベース管理システムへのアクセスを与える。新しい資源マネージャーは、既存のシステムを「ラップ」し、既存のシステムに向けて、又はそれから送られる全てのメッセージ、リクエスト又はデータを、必要に応じて中断させ翻訳するための「殻」を与える。DBMS資源マネージャーサービスオブジェクトの定義によって、既存のデータベース管理システムを、他のオブジェクトと同様に扱うことができる。このように、ユーザーは、データベースセッションをスタートさせ、データを検索、更新するなどのために、新しい資源マネージャー上に方法を呼出すことができる。
環境
特定の環境において分散アプリケーションを実施するには、その環境について何らかの情報を供与することが必要となる。環境は、特定の会社のオフィス又は特定の部局のような、特定の場所においての、ハードウエア及びソウトウエアのネーミングされた記述である。任意の数の環境において、分散アプリケーションを実施するために、同一の論理アプリケーションの記述を、変更なしに使用することができる。更に、単一の環境は、一般に、一つ以上の分散アプリケーションを支援することができる。
分散アプリケーションを実施するには、特定の環境のためにアプリケーションを区画する必要がある。これは、アプリケーションの各々のサービスオブジェクトを特定のパーティション（区画）に割当て、どのパーティションがどのノード又は機械上で走るかを特定することを意味する。
パーティショニング
好ましい実施によれば、本方法は、アプリケーションプログラムの各々のオブジェクトを自動的にパーティションにパーティショニングする。これは、各々のサービスオブジェクトを特定し、そのサービスオブジェクトにとって好ましいパーティションに配置することを含む。また、これは、サービスオブジェクトによって作り出された各々のオブジェクトを特定し、サービスオブジェクトと同一のパーティションにそのオブジェクトを配置することを含む。そのサービスオブジェクトに対するオブジェクトリクエストブローカーは、他の任意のパーティションについて作り出すことができ、一般に、そのサービスオブジェクトを呼出すことのできるオブジェクトを含むどのパーティションについても作り出されるべきである。
図6A及び図6Bを参照して、パーティショニングは、各々のパーティションを環境中の特定のノード又は機械に、適切な資源及び能力と共に割当てることを含む。パーティショニングは、例えばあるパーティションを別のノードに再度割当てたり、あるサービスオブジェクトを別のパーティションに移動させたりすることによって、検査したり、変更したりできる。
別の見方として、アプリケーションのパーティショニングは、２以上のコンピュータ上において走るように１つのアプリケーションプログラムを分割する能力である。一方モノリシックなクライアントのアプリケーションモデルは、RDBMSサーバーからのアプリケーションを分割するが、アプリケーションのパーティショニングは、複数のコンピュータに亘ってアプリケーションプログラム自身を分散させる方途を供与する。アプリケーションの一部はクライアント上で、別の部分はRDBMSサーバーも駆動するハードウエア上で、また別の部分は１以上の他のサーバー上で、それぞれ走ることがありうる。
好ましいパーティションは、例えば特定の機械上に既に駐在している既存のアプリケーションをあるサービスオブジェクトがラップする場合などに、予め定義することができる。多くのサービスオブジェクトは、種々の機械上において同様に良く走りうるので、全部の好ましいパーティションを予め定義する必要はない。特定のパーティションの割振りは、特定のサービスオブジェクトと、他のサービスオブジェクト及び使用可能な機械の資源に対してバランスされた他の対応して作り出されたオブジェクトの、ハードウエア及びソフトウエア要求に基づいて行うことができる。
パーティションが、あるノードに割当てられ、全てのサービスオブジェクト、オブジェクト及びそのパーティションのためのオブジェクトリクエストブローカーを含めて、十分特定されたら、特定の機械のために、そのパーティションをコンパイルすることができる。これは単に、特別のノード上において機械語にコンパイルするための適宜の中間ソースコード例えばＣ＋＋を作成することを含みうる。コンパイルされた機械コードは、各々のノードにロードし、アプリケーションプログラムは、走る状態となっている。
パーティションは、どんな時にも、種々の手段によって変更しうる。特定のサービスオブジェクトは、１つのパーティションから別のパーティションへと移動しうる。只２つのノードを備えた最も簡単なシステムの場合、最初のパーティショニングは、各々のノード上において少くとも１つのサービスオブジェクトを実現する。本発明の方法は、第２のパーティションにサービスオブジェクトを複製し、次に本来のサービスオブジェクトを置換し、実際のサービスオブジェクトのロケーションを有効にスワップすることを許容する。以前にブローカーされた第２の機械からのコールが今も直接取扱われ、以前に直接に取扱われた第１の機械からのコールが今やブローカーされていることを除いては、どちらのパーティションの他のどのオブジェクトについても差異は生じない。２つより多くのノードがあれば、同一の一般的な原則によって、サービスオブジェクトを別の異なるパーティションに移動させることが可能となる。
アプリケーションのパーティショニングは、クライアント−サーバー環境についての予め定義された機能性の分割を指示しない。これは、アプリケーションのいろいろの部分をいくつかの可能な仕方で割振ることを可能とする。アプリケーションのパーティショニングは、クライアントとサーバとの間におけるアプリケーション機能の適切な分割が、アプリケーションに非常に依存していることを認識する。ある与えられたアプリケーションについても、最適な分割は、新しいユーザー及びアプリケーションの増設の付加と共に時間がたつにつれ変化するかもしれない。
パーティショニングにおいて、アプリケーションプログラムは、サービスオブジェクトの集合体として構成し、分散アプリケーションとして展開することができる。パーティショニングは、開発プログラマがサーバー及びクライアント上にアプリケーションの機能性を配置することを許容する。パーティショニングは、アプリケーションの別々のパーティション間のコミュニケーションを自動化し、アプリケーションが完全にクライアント上で走るか又はいくつかの機械に対して分配されるかとは係りなく機能するようにする。
アプリケーションのパーティショニングは、種々のアプリケーションのコンポーネントが展開形態のどこで走るかについての決定からアプリケーションの機能性の開発を切離すコンセプトに基づいている。開発プログラマーは、内在する物理的環境から独立した論理的なアプリケーションの定義を作成しうる。開発後、論理的なアプリケーションの定義はパーティショニングされ（即ちネットワークの別々のノードにおいて実行されうる独立したモジュールに分割される）、コミュニケーションが自動的に設定され、開発プログラマーは、アプリケーション定義サイクルの間コミュニケーションに係ることから解放される。図７を参照して、論理的なアプリケーションの定義は、たとえ後に２つ以上のプロセッサーに対し分割されるにしても、単一のアドレス空間内において走るサービスオブジェクトの集合体として構成される。パーティショニング後に、アプリケーションは、統合されたのシステムの概観を示し、アプリケーションの運用者が単一のユーザーインターフェイスからの全ての構成パーティションを管理することを可能とする。
パーティショニングされたアプリケーションは、アプリケーションの機能性の領域を拡張して、改良された性能、信頼性及び制御のいくつかのオプションを導入するための、アプリケーションのアーキテクチュアの基礎を供与する。アプリケーションのパーティショニングは、より多くの機能性を含み、より多くのユーザーを収容し、ビジネスの要求をすみやかに展開させる新しい企業規模のオンラインアプリケーションを作成するために、ユーザー−サーバーモデルを有効に企業体が使用することを助ける。
アプリケーションのパーティショニングの原理
パーティショニングは、有効であるには、次の原理に従わねばならない。
1.パーティショニングの計画は、論理的なアプリケーションの定義を変更せずに変更できる。アプリケーションの機能性の定義は、パーティショニング計画から独立しているべきである。アプリケーションの定義は、環境中立であるべきである。アプリケーションは、その機能性を変更することなく、多くの別々の場所に分割できなければならない。例えば新しいサーバーが既存の環境に付加された場合には、あるアプリケーションに対して、パーティションの数を増すことができなければならない。
2.パーティショニングモデルは、複数の機械上において走る任意の数のパーティションを受入れることができなければならない。パーティショニング計画は、同じ数のノード（例えばクライアント及びデータベースサーバー）上において走るように全てのアプリケーションが分割されると想定すべきではない。全てのクライアントが同一であると想定すべきではない。只１つのサーバー（又は他の任意の数）しかないと想定すべきではなく、またパーティショニングのための基礎として、ある形式の機能性（例えばビジネスのルール）を分割すべきではない。パーティショニング計画は、データベースシステムの存在を予測してはならない。パーティショニング計画は、その代りに、可能なパーティションの数についての制限なしに、非常に融通性のあるパーティショニングモデルを支援すべきである。
3.単一のアプリケーションの定義は、複数の環境を、各々それ自身のパーティショニング計画で支援することができる。アプリケーションの定義は、特定のパーティショニング計画から独立しているので、同一のアプリケーションの定義で別々の環境を支援しえなければならない。例えば各々それ自身のハードウエア形態及びパーティショニング計画で、２つの場所において同一のアプリケーションを展開できなければならない。
4.個々のパーティションは、他のパーティションとのコミュニケーションを開始しそれに応答できなければならない。パーティショニング計画は、複数のサーバーを含みうるので、サーバーは、他のサーバーと直接に対話できなければならない。サーバーは、デスクトップクライアントにメッセージを送ることができなければならず、デスクトップクライエントは、その後、これらのメッセージを処理する。
アプリケーションのパーティショニング
複数の機械に亘ってアプリケーションの機能性をパーティショニングすることには、いくつかの理由が存在する。
性能  単純なRDBMSアプリケーション（例えば、データベースにデータスクリーンを挿入したり、データベースからある記録を選定したりする）は、パーティショニングを伴う性能を改善するための第一の目的ではない。しかし、分析を行い、多重データソースにアクセスし、そして／又は多段ビジネスプロセスを同時に実行するアプリケーションは、パーティショニングによって実質的な性能利益を得ることがある。これらの利益は、以下のストラテジーの１つ以上によって実現されうる。
ネットワークのトラヒックの削減  スターターにとって、パーティショニングは、データソースにより近づくようにデータ分析／削減を移動させることができる。これは、前日以来価格が最も変動した株をユーザーが特定したい場合などに有用でありうる。この株を特定する分析がクライアント上で走る場合、データベースは、ネットワークを経て何千もの記録を分析モジュールに送らねばならないであろう。他方では、サーバー側で分析が行われる場合、只１つの記録を、ネットワークを経て送るだけで良い。
パーティショニングは、１回のネットワーク巡回トリップによっていくつかの別々のビジネスステップを実行するためにも使用しうる。例えば命令入力アプリケーションでは、最初に顧客のクレジットを確認し、ディスカウントを計算し、発送スケジュールをチェックし、最後にオーダーを入力する。パーティショニング時には、オーダー入力プロセス全体が１回のコミュニケーションの巡回トリップで実行されうるように、サーバー上に、これら全ての機能を配置することができる。この実行ストラテジーは、可搬形のコンピュータがモデムを介してサーバーにアクセスする場合のように、クライアントへのネットワークのリンクがおそい場合には、非常に重要となりうる。一般に、アプリケーションが実行すべきステップ数が多いほど、１つ以上のサーバーに機能性を配置することによって実行を最適化する可能性が高くなる。
並行プロセスアプリケーションタスク  前述のオーダー入力の例は、パーティショニングがどのようにして連続的多段アプリケーションの性能を改善することができるかを説明する。例えば経時データに対して提案された株の買いに対する予定利益を分析すると同時に、この株の付加が投資家の個別のポートフォリオストラテジーにどのようにインパクトを与えるかを分析等、独立したタスクをアプリケーションが並行して実行しうる場合、これと別のストラテジーを適用することができる。ビジネスの観点からは、顧客を満足させるために、両者の分析が必要となる。しかし、どちらが最初に完成するかは重要ではないので、両者を同時に実行しうる。技術的な観点からは、両方の分析がクライアント側で走っていると、（ユーザーが対称多重プロセッシング式ワークステーションをもつ場合を除いて）両者を順次走らせることが必要となろう。パーティショニングは、デスクトップ上で走っている第２の分析モジュールと同時実行されうるように、分析モジュールの１つをサーバーに移動させるオプションを提供する。また、パーティショニングにより、各々の分析モジュールを、それ自身のサーバー上に位置させることができる。図８参照のこと。分析モジュールが複雑であったり、及び／又はサーバーの処理能力がデスクトップの機械よりも実質的に高い場合には、性能上の大きな利得が、これによって得られる。多重タスクを並行して走らせることによって、アプリケーション全体を短時間で終了させることができる。
オーバーロードクライアントからのオフロード処理  3GLに可及的に多くのアプリケーションを記録し、RDBMS内で可及的に多くの仕事をするように、記憶されたプロシージャを使用する、及びクライアントのハードウエア形態をアップグレードする等の、慣用の性能救済の後でも、目標のクライアントの機械を単にオーバーロードする点まで増大するアプリケーションもある。パーティショニングは、クライアントからサーバーにアプリケーションの一部を移動させるので、有用となりうる。このストラテジーの結果としてネットワークに余分なコミュニケーションがなされても、アプリケーションの分配によって正味の性能上の利得が供与される。
制御  デスクトップ機械は、費用効率のよい処理能力を提供するが、制御が最も困難な環境である。全部のクライアントに全アプリケーションを配置する代りに、アプリケーションの機能性の重要な部分をサーバーに配置することによって、組織体は、制御の重要な部分を保持しながら、デスクトップの処理能力を利用することができる。
タンパリングに対する保護  法人は、その操作データを、主要な法人資産とみて、このデータを多くの安全対策により保護する。組織体も、そのアプリケーションロジックを、同様の保護を要する法人資産とみる。ある会社は、複雑なモデリングプログラム、いくつかのビジネスステップを自動化するための産業をリードするアプローチ又は資金の増大を承認するアプリケーションを開発しているかも知れない。これらのアプリケーションの主要部分がデスクトップ機械上に配置された場合、不法なアクセス、個人のタンパリングもしくは企業スパイのリスクを生ずる。
サーバーに基づいた制御点  集中環境では安全対策がより取り易いので、サーバーに対して制御点を（例えば出費勘定の再支出の認可などによって）管理することにも意味がある。パーティショニングにすれば、全アプリケーションの一部として、サーバーに基づいた制御点を設定し、後にそれをサーバー上に配置することが可能となる。アプリケーションが進化するにつれて、各々のデスクトップ上に新しいアプリケーションのバージョンをインストールするよりも、サーバーパーティションの機能性を変化させることがより容易となる。
融通性  クライアント−サーバー環境の１つの強みは、クライアントとサーバーとの両者を増分的に加入させる能力である。しかしこれらの進行的な変化は、アプリケーションに問題を生じることがある。追加されたクライアントは、使用パターンを変更すると共に、全体的な処理ロードを増大させることができる。更に多くのサーバーがネットワークに追加された場合、アプリケーションは、どのようにして、追加の処理能力を利用しうるであろうか？パーティショニングは、これらの潜在的な問題も解決することができる。
多重の環境への支援  図９を参照して、ある団体の計算環境は、２層から３層環境へと進化することがありうる。又は、ある団体は、各々別の環境をもった２つの場所で、同一のアプリケーションを支援するように求められるかもしれない。この場合、開発プログラマーは、別の環境に対してアプリケーションを開発する自分自身を発見するかもしれない。アプリケーションのパーティショニングの場合、プログラマーは、各々の目標環境のための個別のパーティショニング計画を支援する単一の論理的なアプリケーション定義を作成し保持することができる。
混合環境の支援  あるアプリケーションの場所が異なったクラスのクライアント機械をもつ場合に、別の問題を生ずる。一例として、昨年５年償却計画である団体が386ベースPCを数百台購入したとする。この団体は、その時以来、何台かのUNIXワークステーションを購入している。理想的には、新しい目標アプリケーションは、両方のクラスのデスクトップ機械を利用しうるが、これは問題を提起する。アプリケーションのうちどの部分がデスクトップ上で走るか？開発プログラマーが最も力の弱い機械を許容しなければならない場合、PCを受けいれるために、UNIXワークステーションを過小利用することになる。図10を参照して、アプリケーションのパーティショニングは、この問題への１つの解決を与える。パーティショニングによれば、アプリケーションのある小さな部分が、PC上において走りその大きな部分がワークステーション上で走ることになる。
パーティショニングされたアプリケーションの例
パーティショニングの力を示すため、このセクションでは、４つの例示的なアプリケーションについて説明する。これらの例は、ある共通の特性を分担している。アプリケーションロジック（即ち、プログラミングのスタッフによって開発された部分）は、各々が自身のパーティションを備えた、いくつかの機械上に分布されている。これらの例は、アプリケーションのパーティショニングの可能性を尽していない。また、アプリケーションは、パーティショニングによる利益を受けるべく、これらの例ほど多面的とする必要はない。
顧客サービス
電力会社の顧客サービス担当者は、最近の請求書についての苦情をある顧客から受けた。サービス担当者は、顧客の計算書の電子コピーを最初に取出さねばならない。顧客の全体的な使用パターンについて、多少の分析を行うことは助けとなろう。今月は、先月との関係において異常を示しているか？その地域に対する全部の請求書は、その地域の多くの人々に影響した寒波、その他の要因を反映して、高目になっているか？
サービス担当者は、これらの情報を知った上で、顧客の事情について論議することができる。担当者は、対話を通じて会社の特別のプログラム（例えば、家電絶縁の補助金又は12か月の延べ払いの可能性）の１つへの参加を示唆するかも知れない。システムは、担当者に潜在的に関係のある質問を行い、次に各々のプログラムの予測される利点を予想することを、勧めることができなければならない。顧客は、これらの特別のプログラムのコーディネーターとの面会を求めるかもしれない。するとシステムは、多分電子メールによって、コーディネーターに通知できなければならない。顧客は、その家宅にエネルギーの漏れあるか否かを点検するための技術者の訪問を求めるかもしれない。するとシステムは、このようなサービス点検の予定を担当者が立てることを許容すべきである。請求書が間違っていることもある（例えば顧客が転居した時に電力が遮断されていなかった等）。するとシステムは、担当者がこの見落しについて（その妥当性を確めた後）訂正することを許容しなければならない。請求が完全な時、システムは、合意された処理を確認する書状を顧客に対して発生させるべきである。
この形式のアプリケーションは、ネットワークを通じて分散される多重のデータソース及びアプリケーションサービスへのアクセスを必要とする。図11を参照して、顧客及び請求データは、RDBMSに保管しうる。サービスアポイントメントスケジュールもRDBMSに保管しうる。使用プロフィル分析及び保存プログラム分析は、異なるサーバー上において走らせることができる。アプリケーションは、電子メールシステム（プログラムコーディネーターへの通知用）及びプリンタ（確認レター発生用）の両者とのインターフェイスを行なうことが必要である。
この例は、わずか２つのパーティション又は５つものパーティションを、いろいろの実施にについて使用することができる。１つのパーティションは、多くのアプリケーション機能の中でナビゲーションを簡略にするために、ユーザーのデスクトップ上で、おそらくはユーザーのグラフィックインターフェイス（GUI）上において走る。顧客の請求及び勘定の情報のフォーマッティングは、デスクトップ上もしくはデータサーバー上で生じうる。分析は、このアプリケーションのために新しく書いてもよく、また以前に書かれてもよく、後者の場合には、新しいアプリケーションを分析とインターフェイスさせる必要がある。これらの分析は、クライアント上又はデータベースサーバー上で走らせることができると考えられるが、別のサーバー上で走らせる方がより好ましい。パーティショニングは、開発プログラマーがどこで走らせるかの決定を延期することを可能とすると共に、最初の展開の後にこれらの再配置を行う自由を開発プログラマーに許容する。
電子メールシステム及びプリンターとのインターフェイスは、それ自身のチャレンジを設定する。この例は、これらの外的システムに命令を送出する簡単なケースを包括する（次の例は、メールを受けてそれを表示する、より複雑なケースを包括する）。インターフェイスは、クライアント上で走りうるが、これは、クライアントの機械とタイアップしうる。その間、電子メール及びプリントサブシステムが呼出されると共に、発生したエラー（例えば誤ったプリンタにレターを送付したり、電子メールシステムが利用可能となるまで電子メールメッセージを待たせておくなど）に対処する。別の方法は、アプリケーションのこれらの部分を電子メールサーバー又はプリントサーバー（又は、両方のインターフェイスが走っているならば、単一のサーバー）に配置することである。
パーティショニングは、このアプリケーション（及び他の例）の構成を、３つの仕方で単純化することができる。第一に、パーティショニングは、いろいろの構成部分がどこで走るかを予め定めることを必要とせずに、開発プログラマーが全アプリケーションを作成することを許容する。第二に、パーティショニングは、クライアント部分の作成に１つのツールを使用し、サーバー成分のために別のツール（又は多重ツール）を使用することとは反対に、開発プログラマーがアプリケーションの全部分のために同一のツールを使用することを許容する。第三に、パーティショニングは、異なった機械上で走るアプリケーションのいろいろの部分間のコミュニケーションを自動化する。
製造
図12を参照して、この例は、ある会社が金属原料ブロックから部品を機械切削する非常に簡単な製造工程を模擬する。この会社は、供給者から原材料ブロックを受領し、旋盤でこれを形削りし、買主の仕様に合せて穿孔する。次にこれらの部品を試験機にセットして、顧客の仕様に合っていることを出荷前に確認する。テストシステムは、不良部品を自動的に廃棄し、不良率が１時間当り所定数を超過している場合は管理者に警告する。この警告は、先制していなければならず、たとえユーザーがその時に別のアプリケーションを走らせていても、新しい窓を開いてメッセージを表示しなければならない。
図13に示した別の例において、このアプリケーションは、多くの部分を作成することを含む。即ち、出荷及び受領システム、所要の測定のために旋盤及びドリルをプロセスエンジニアが設定するためのユーザーインターフェイス、公差許容を設定し不良部品を廃棄するための試験機械のインターフェイス、並びに不良率が過大な場合にプロセスエンジニアに警告する能力である。これらの部分は、一般的なビジネスシステム及び工場のフロア機械のコントローラを含めたいろいろのコンピュータ上において走る。図13に示した好ましい実施例において、機械制御コンピュータは工場のフロア上のフライス盤、ドリル及びコンベヤシステムを制御する。品質制御機械は測定機械を制御し、公差分析を実行し又は監視する。生産計画機械は、製造ステップ及び製造スケジュールをモニタする。ビジネスサービス機械は、受領、インベントリー及び出荷をモニターする。これらの各々の機械は、プロセスエンジニアとのインターフェイスと共に、互いに接続され、各々の機能を実行するのに必要なサービスオブジェクトから成る統合されたアプリケーションを形成する。
アプリケーションのいろいろの部分がどこで走るべきかについての決定は、前述した顧客サービスの例よりも問題が少い。製造機械及び試験機械とのインターフェイスは、これらの機械のためのコントローラー上において多分走るであろう。プロセスエンジニアのためのインターフェイス及び出荷／受領クラークのためのユーザーインターフェイスは、そのデスクトップ上において走らせる必要がある。多分１つ又は２つの一般的なビジネスシステムがある。このアプリケーションのチャレンジは、十分に統合されたシステムとして全くの部分を作成することにある。目標は、プロセスエンジニアのスクリーンから工場のフロアの機械に製造仕様を移し、他のビジネス機能を逐行するのに必要なコード量を最小にすることである。パーティショニングがないと、開発プログラマーは、別々の部品の集合体としてこのアプリケーションを完全に作成することを求められるであろう。開発プログラマーは、いろいろの機械コントローラへのインターフェイス及びGUI部分を作成するために、いろいろのツールを多分使用するであろう。また、開発プログラマーは、彼ら自身のバージョンコントロール及びソフトウエア形態管理を行うことを必要とするであろう。パーティショニングは、全アプリケーションを単一体として作成した後に各パーティションをそれが論理上走るべきノードに割当てることに対する代案を提供する。
このアプリケーションの特別のチャレンジの１つは、不良率が閾値を超過した時にプロセスエンジニアに警告することである。これは、試験機械の連続したポーリング又は試験機械からエンジニアのデスクトップにメッセージを送りうることを含む。メッセージの送付は、作動上の見地から好ましい。このメッセージ能力の形式が開発環境において支援されれば単一の機械上において走るかのように警告を作成した後、警告の開始をユーザーのデスクトップ上のディスプレイから物理的に分離することが、パーティショニングによって可能となる。
財政サービス
証券ブローカーは、多くの異なる形式のデータへのランダムアクセスを一般に必要とする。図14を参照して、顧客がコールした時にブローカーは顧客の口座について情報をチェックすることを必要とするであろう。彼らが新しい証券の購入について議論する際、ブローカーは、現在の価格及び会社の最新のニュースを示す実時間のフィードからのデータを必要とする。また、ブローカーは、証券についての経時データを検討することを望むかもしれない。ブローカーは、購入を推賞する前に、この証券が顧客の全体的な投資戦略に適合するか否かを見るために、ポートフォリオ分析モデルを参照することを求めるかもしれない。また、プローカーは、この潜在的な投資を他の投資と比較する投資分析モデルを参照することも望むかもしれない。顧客が証券を購入することを望む場合、ブローカーは、取引に入り、合意された価格で取引が成功のうちに実行されたことの即時的な確認を得る。市場がその間に高い方に移行したら、ブローカーは、この高い価格で証券を購入することを顧客が望むか否かについてたずねることができる。取引が実行されたら、ブローカーは、顧客に請求書を出し、顧客のポートフォリオリストを更新し、ブローカーのコミッション計画にその取引を含ませるためのプロセスに入らねばならない。
その間、他のユーザーは、別の目的のために同一の情報の大部分にアクセスする別のアプリケーションを走らせている。財政アナリストは、現在の株価をモニターし、新しいニュースを追跡し、経時データ及び毎日の取引量の深度分析を行っているかもしれない。アナリストたちは、株に対する推賞を変え、その特定の株にポジションを持つクライアントをもつブローカーに電子メールを送ることを必要とするかもしれない。同時にオフィスマネージャーは、そのオフィスの取引量をモニターし、種々のブローカーの生産を分析しているかもしれない。
他の例と同様に、このアプリケーションは、クライアント−サーバーアーキテクチュアに非常に有用である。異なる形式のユーザーは異なるデスクトップアプリケーションを走らせているかも知れないが、全て１組の分割されたサービスにアクセスできる。これらのサービスには、粗データ（株価の相場及びフィード、ニュースフィード、口座、経時データ）、予め定義されたレポート（顧客ポートフォリオ、毎日のブローカーの生産性）並びに他のアプリケーションサービス（分析モデル、例えば投資分析及びポートフォリオ分析、為替アルゴリズム、電子メール、並びに取引システム、顧客に対する請求、ブローカーコミッション情報を提供するバックオフィスシステムへのアクセス）が含まれる。クライアント−サーバーは、これらのサービスを開発し、保持し統合するための最大の融通性を、ブローカー会社に与え、デスクトップ上のGUIの使用は、いろいろのサービスのうちエンドユーザーのナビゲーションの仕事を単純化することができる。パーティショニングがなければ、いろいろのアプリケーション部分は、単独に分離して形成されねばならなくなる。パーティショニングによれば、全てのサービスは、単一の開発環境において作成され、後に、クライアント−サーバー環境のいろいろの機械に割当てることができよう。
オーダー／入力
多くの団体は、ビジュアル指向の対話型オーダー入力システムを用いている。これらのシステムは、顧客に、彼らが正に必要とするものを特定し、満足を与え、正しくないオーダーの数を少くし、製品を購入する全プロセスを流線形にすることについてのより多くの制御与える潜在力をもっている。このアプローチは、いくつかの小売商の団体により活発に開発中である。本発明は、商品例えば新車をオーダーする新しい方法を開発するために用いることができる。全ての支援技術は整えられておりパーティショニングは、アプリケーションの開発を単純化する。
ある車の１つ又は２つのフロアモデルを見て、おそらくは運転した後、顧客は、セールスマンと共にPCに着座し、正確な値段を示して取引の契約をする。多くのオーダー入力システムと同様に、アプリケーションは利用可能なサービスにアクセスして、信用状態、銀行の貸借及び雇用状態をチェックし、買主の資格付けをする。買主は、所望のモデルを指示してクリックする（又はいくつかのモデルを同時に見て、所望により一度に一台を見るようにズームインする）。彼は、スクリーン上にフルカラーで表示されるいろいろの色案及び細部のオプションについて実験する。考慮中のモデルは、任意の角度から見るために回転させることができる。外部オプション例えば磁性ホイールは、選択された時に表示される。システムは、ドライバーの視点からそのモデルの運転席から見た視野を示すことができる。システムは、適切な場合に表示されうる常用の全価格を保持しながら、表示不可能なオプション（エンジンサイズ、助手席側エアーバック、延長保証）について顧客の催告をする。仕様が完全になったら、システムは、入手可能性スケジュールをチェックし、買主に目標引渡し日を示す。次に、オーダーを電子的に行って、製造−出荷サイクルを通じて電子的に管理する。
オフィスの家具システム又は家庭用の注文窓セットのデザイン及びオーダーのような他の購入にも同じ方法を用いることができる。第15図を参照して、部分サービス、即ち、イメジングサービス（オンラインカタログ又は注文生産）、分析システム又はサービス（例えば価格付、形態チェック又はスペース要求情報）、データシステム（例えば口座情報を含む顧客データ、クレジットチェック情報、商品割引情報）、生産システムとのインターフェイス（スケジューリング、製造、出荷並びに請求）について、全て同様の要求をもつ。
この形式のアプリケーションは、他の例と同様に、アプリケーション部分が複数の機械上において走っているクライアント−サーバーに適合している。アプリケーションはデータベース、イメージングシステム、クレジットチェックサービスに話しかける必要があり、他方では分析サービス（価格付、形態チェック、全重量、引渡し日）並びにビジネスサービス（オーダー入力、製造、出荷、請求）を供与する。アプリケーションが多面であるほど、開発の複雑さを少くするためのパーティショニングが有用となりうる。
Forte'によるパーティショニングアプリケーションの形成
Forte'は、パーティショニングされたアプリケーションを形成し展開するための高度なアプリケーション開発環境であり、GUIフォームズペインタ、オブジェクト指向4GL及び対話形デバッガと共にー式の、貯蔵所に基づいた開発環境を含む。プログラマーは、特定の物理的環境から独立した所望の機能を特定化する論理的なアプリケーション定義を作成するために、この開発環境を使用する。Forte'は、目標展開環境を特定化して目標環境のためのデフォルトパーティショニング計画を作成するためのツールを含む。さらに、Forte'は一旦パーティションしたアプリケーションを展開したら、これを管理するツールを含む。図16を参照して、これらのツールは、三相開発サイクル、即ち、アプリケーションの定義、システムの発生並びに分散を支援する。アプリケーションの定義は、GUI−4GL情報及びサービスオブジェクトに関する情報の貯蔵を利用してもよい。デバッガーは、プログラムの開発のための相について有用である。システム発生は、形態、パーティショニング及びコード発生を含む。展開はサービスオブジェクトを有効に分散させて利用するために、分散オブジェクトマネージャー及びシステム運用のための作動モニタを使用する。
論理的なアプリケーショの定義の作成
最初のステップは、論理的なアプリケーションの定義である。このステップは、他の4GLツールと共にクライアント駐在アプリケーションの作成に対応している。しかし、Forte'では、論理的なアプリケーションの定義は、開発相の後にパーティショニングすることができる。
物理的開発環境  論理的なアプリケーションの定義は、特定の物理的開環境から独立しており、かくして開発プログラマーに、物理的な開発環境のための相当な融通性を与える。本発明の方法は、下記の、
・デスクトップ/GUI−Windows、Macintosh、Motif、Presentation  Manager
・サーバー−UNIX（IBM、Sequent、HP＆Sparc）、VMS（VAX＆Alpha）
・ネットワーク−TCP/LP.DECnet、Novell、Apple  talk
・RDBMS−Oracle、Sybase、Rdb、Ingres、Informix
・TPモニター−ACMS、Encina、Tuxedo
を含む多くの環境を横切って透過性の移植性を供与する。
開発プログラマーは、論理的なアプリケーションの定義を作成するために、いかなる支援された環境をも使用することができる。アプリケーションは、いろいろのハードウェア及びソフトウェア形態を伴う環境において後に展開させることができる。例えば、開発プログラマーは、開発のためにSparcサーバーに話しかけるためにPCクライアントを使用し、次にVMSサーバーに話しかけるためにMacクライアントを使用する。移植性及びパーティショニングは共に環境の独立性のために必要である。クライアント−サーバー環境が進化するにつれて、新しい機械及び使用パターンの追加には、アプリケーションの再パーティショニングと、いろいろの機械環境へのアプリケーション部分のリホスティングが必要となりうる。
サービスオブジェクトの集合体としてのアプリケーション
前述したようにForte'アプリケーションプログラムは、サービスオブジェクトの集合体として設計されている。サービスオブジェクトは、表示サービス、データベースアクセス、外部サービスとのインターフェイス（レガシーシステム、電子的フィード、電子メール）並びに団体特異ビジネスサービスを含みうるが、これらに限定されない。サービスオブジェクトアプローチは、ユーザーの視点から団体が自身のビジネスをモデル化することを許容する。
例えば、新しいオーダーを処理する場合、団体は、顧客のアドレス及びクレジット等級を確認し、所望の製品が入手可能であることを確かめるためにインベントリーをチェックし、請求サイクルを開始させるように会計に通知し、製品を郵送するための出荷を指示することが必要となりうる。コンピュータ以前には、人は、他の人と取引するか、又は他の人が作製した用紙で取引していた。この過程は面倒であったが、比較的理解し易かった。コンピュータの到来と共に、オーダーを処理する時間が加速されたが、データ下部構造を必要とした。顧客の記録は、口座内容、インベントリー及び出荷データと共にデータベースに格納される。アプリケーションプログラマーの仕事は、ユーザーインターフェイス（おそらくコンピュータスクリーン上の様式）とデータ下部構造との間のマッピングを提供することである。
プロシージャプログラミングによれば、このマッピングは、通常は、アプリケーション特異であり、複雑でありうる。例えばオーダー入力アプリケーションは、顧客データベースから顧客の記録を呼出し、顧客のクレジットデータベースをチェックし、インベントリーデータベースから、入手しうる量をリクエストし、入手可能な量がオーダーを支持しうることを確め、オーダーデータベースを更新し、出荷データベースに新しいエントリーを付加することができる。
サービスオブジェクトアプローチによれば、プログラマーの仕事は、単純化されうる。図17A及び図17Bを参照して、RDBMSデータ下部構造は、所定位置に保たれている。しかし今や開発プログラマーは、データ下部構造をカプセル化する新しいサービスオブジェクトを単に作成する。例えば、開発プログラマーは、インベントリーサービスオブジェクト、オーダー処理サービスオブジェクト、顧客情報サービスオブジェクト、並びに出荷サービスオブジェクトを作成することができる。これらは、接続されたオーダー入力スクリーンサービスオブジェクト及びデータベースサービスオブジェクトを介して制御され案内されることができる。
この形式のサービスオブジェクト下部構造は、開発プログラマーの仕事をいくつかの仕方で単純化できる。第一に、開発プログラマーが既存のサービスオブジェクトを再使用することを許容することによって、新しいアプリケーションの開発を単純化する。オーダー入力アプリケーションのために最初に開発されたインベントリーサービスオブジェクトを使用する新しいインベントリーアプリケーションを作成することができる。第２に、ビジネスルールを制御しうる追加の抽出層を供与すると共に、アプリケーションプログラムを変化に対して絶縁することによって、アプリケーションの保持を簡単にする。会社が、その保持するインベントリー量を少くすることを望んだ場合は、多くの個別のプログラムを変更する代りにインベントリーサービスオブジェクトを変更することができる（Forte'は、コード発生技術を使用することによって、他の抽出層の作動インパクトを最小にする）。第三に、サービスオブジェクトは、会社の組織構造を反映すると共にパーティショニングの基礎を与えうるアプリケーションのモジュール化された視野を表わしている。
Forte'のパーティショニングアプローチは、ビジネスルール又はアプリケーションの機能性の他の予め規定されたカテゴリーを分割することには基づいてはいない。Forte'は、そのアプリケーションを１以上の予め規定された型に適合させるために、開発プログラマーを必要としない。代わりにForte'は開発プログラマーに、彼らにとって最も有意義な仕方で、アプリケーション環境をモデル化することを許容する。Forte'アプリケーションを形成するのには、構造的な方法は必要とされない。
Forte'は、パーティショニングの基礎として開発プログラマー規定サービスオブジェクトを使用する。各々のパーティションは、１つ以上のサービスオブジェクトを含む。全てのサービスオブジェクトは、あるパーティション内において、手つかずに保たれる。どのサービスオブジェクトもパーティション間に分割されない。アプリケーションは３つのサービスオブジェクトをもつこともでき、また30をもつこともできる。サービスオブジェクトの数が多いほど、パーティショニングのための可能な順列の数が多くなる。
Forte'オブジェクト  Forte'は、オブジェクト技術への全コミットメントを必要とせずにオブジェクト指向プログラミングの利点を供与するように設計されている。ユーザーは、オブジェクトデータベース中にそのデータを格納する必要はない。Ｃ＋＋、Smalltalk又は他のオブジェクト指向言語を使用する必要もない。その代りにForte'は、クラスを作成し、その方法を記述するためのプロシージャ指向4GLを作成するためのフォームズ基環境を開発プログラマーに供与する。
実際は、Forte'は、オブジェクト指向されている（これは、Ｃ＋＋で書かれ、オブジェクト指向を、カプセル化、継承及び多形態によって支援する）。Forte'オブジェクトは、アプリケーションに渡って再使用可能であり、開発プログラマーは、オブジェクトを再生成させることなく、方法を追加又は変更しうる。Forte'オブジェクトは、それ自身の間にメッセージを移行させる。Forte'はそれ自身のピア−ピアメッセージシステムを、Forte'のパーティションとの交信のために供与する。また、Forte'は、外部的なオブジェクト及びサービスと交信するために、RPC（遠隔プロシージャコール）又はCORBA（共通オブジェクトリクエストブローカーアーキテクチュア）スタイルのメッセージ伝送を利用しうる。
Forte'は、GUI基オブジェクト及び一般的なアプリケーションオブジェクトの作成及び操作を支援する。多くのGUIツールは、スクリーン上にアイコンとして表示されるGUI基オブジェクトを支援する。しかしアプリケーションロジックサービスであって単なる提示サービスではない、インベントリーサービスのようなアプリケーションオブジェクトの作成は、全てのこれらのツールが支援するわけではない。Forte'は、アプリケーションのパーティショニングにとって肝要なこれらのアプリケーションサービスを支援する。アプリケーションがパーティショニングされると、これらのアプリケーションサービスは、同じアプリケーションの多くのユーザー及び／又は異なるアプリケーションによってアクセスされうるサーバー上に位置させることができる。Forte'は、クライアントアプリケーション及びサーバーアプリケーションを形成するための開発環境である。これは従来のアプリケーション開発ツールからの逸脱である。
Forte'は、サーバーとして機能しうるアプリケーションオブジェクトの開発を支援するために、数個のキー領域にそのオブジェクトモデルを拡張した。クライアントアプリケーションを作成するための多くのツールは、分割可能性の概念をもたない。それはアプリケーションコードが単一のユーザークライアント機械上において走るように設計されているからである。これらのアプリケーションは、これらの多ユーザー問題を同時性制御及びトランザクションとして取扱うために、サーバー例えばRDBMSに依存する。Forte'は、アプリケーションの一部がRDBMSを使用しない場合にもサーバーアプリケーションがRDBMSと同じスタイルの分割可能性を供与しうるように、同時性コントロール及びトランザクションをそのオブジェクトモデル中に形成した。
ソフトウェア開発環境  Forte'は、アプリケーションを作成するために、可視指向の一組のワークショップを供与する。標準ウイジェットタイプのパレットからスクリーンウイジェットを作成するポイント−アンド−クリックスタイルのインターフェイスによってスクリーンをデザインするためのウィンドウズワークショップ（Windows Workshop）がある。アプリケーションクラス及び他のアプリケーション部分を作成するためのフォームを供与するオブジェクトワークショップ（Object Workshop）がある。Forte'の高レベル言語で方法を記述するための方法ワークショップ（Method Workshop）がある。
Forte'言語は、再使用可能なアプリケーションオブジェクトを支援するので、それは、オブジェクトシ指向4GLとして正確に記述することができる。
Forte'言語は、３つの形式の言語からのコンストラクトを組込んでいる。Forte'言語は、Hypercardによって普及され、後に、いくつかの可能な選択のリストから１つのメニュー品目を選択するなどの非逐次的なユーザーアクションの予期に反した到来に対処するためにGUIツールによって利用された、イベントループプログラミングを組込んでいる。Forte'は、ユーザーのスクリーン上に起源をもつ事象を取扱うと共に、システム及びスクリーンに基づかないアプリケーション部分によって開始された事象（製造フロア上の試験機械から工程管理エンジニアのワークステーションに警告を送信するなど）を取扱うために、イベントループプログラミングを使用する。Forte'言語は、制御フロー（もし・・・ならば・・・さもなくば）を取扱うと共に変量及び式（１＋１）を作り出すために、多くの第３世代及び第４世代言語に見出されるプロシージャプログラミングコンストラクトも含む。更に、Forte'は、RDBMSにアクセスするための標準SQLも組込んでいる。Forte'は、多数のSQLダイアレクトにSQLをマッピングし、RDBMS作動の最適化のためにベンダ指向内蔵プロシージャを生成させることによって、標準SQLを開発言語に組込むことによって、RDBMS移植性を供与することができる。Forte'は、対話型4GLデバッガー（Forte'4GLを用いて作成された）も供与する。
図18を参照して、全ての開発ワークは、Forte'貯蔵所に格納されている。（Forte'の開発環境は、新しいアプリケーションのために再使用され、また容易に変更されるように、以前に作成されたクラス、方法及び属性を見るためのブラウザーを含む）。貯蔵所は、環境中立形態において、全てのアプリケーションサービスオブジェクトの定義を格納している。
貯蔵所は、いくつかの機能を供与する。それは、何人かの開発プログラマーが同時にアプリケーションの異なる部分について作業しうるように、チェックアウト／チェックインによりチーム開発を支援する。それは完全なアプリケーションの作成を容易にするためのバージョン作成及び形態運用を支援する。またそれは目標展開環境の定義を格納する。またそれは各々の環境のためのパーティショニング計画も格納する。
パーティショニングアプリケーションの生成
アプリケーションが一度定められたら、開発プログラマーは、開発環境中の展開環境をシミュレートすることによって、どのパーティショニング計画も試験できる。このとき、アプリケーションは、アプリケーションの定義を変更せずに再パーティショニングできる。アプリケーションは、他の時にも再パーティショニングできる。
システム生成相の第一ステップは、目標展開環境の規定である。クライアントは何（Windows、Mac、及び／又はMotif）で、サーバー、ネットワーク、データベースは何か？この情報は、パーティショニングプロセスにおいて使用するべく貯蔵所に格納されている。
第二ステップは、アプリケーションのデフォルトのパーティショニングである。パーティショニングの指令が出されると、Forte'は、目標展開環境の仕様を検索し、アプリケーションの定義のロジックを分析する。Forte'は、各々のサービスオブジェクトを吟味し、分割されるように設計されているか又は１人のユーザーによってのみアクセスされるように設計されているかをチェックする。（提示サービスのセットのように）独占的に使用するように設計されていれば、Forte'はそのオブジェクトをクライアントパーティション中におく。分割使用向けに設計されていれば、それはサーバーに向けて移動される候補者である。サービスオブジェクトには、外部の資源に組合されているものがある。例えば、RDBMSへのアクセスのインターフェイスは、目標RDBMS及びその物理的ロケーションに組合されている。レガシーシステムへのインターフェイスは、そのシステム及び物理的ロケーションに組合されている。他のアクセスサービスは、株式ティッカー又はプロセスモニターフィードのようなリアルタイムフィードを含む。外部サービスへの各々のアクセスの場合に、Forte'は、インターフェイスが位置されたノード上において、パーティションのデフォルト割当てをノード上において、貯蔵所において規定されているように走らせる。外部資源に直接組合されてはいない他の分割サービスオブジェクトが多くありうる。これらは、コンピュータサービス又は分析サービスを含むことができ、更に、団体のポリシーを強制する１組のビジネスルールを含みうる。これらの分割されたビジネスサービスは、他のサービスオブジェクトにアクセスでき、これらの他のサービスオブジェクトは、データベース又はリアルタイムフィードからの粗データを供給する。これらの分割されたサービスは、コーディネーションを目的とした他のサービスにもアクセスできる。前記のオーダ入力の例では、オーダプロセスサービスオブジェクトは、インベントリーサービス及び出荷サービスにアクセスすると共に、直接データベースにもアクセスしていた。図19を参照して、外部資源に直接アクセスしない１組のサービスオブジェクトがあれば、Forte'は、目標形態において定義された全ての使用可能なハードウエアサーバーを均等に横切って、これらのサービスオブジェクトを再割振りしようと試みる。
このデフォルトパーティショニングアプローチは、理想的なパーティショニング計画を生むものではなく、出発点である。Forte'は、デフォルトパーティショニング計画を手動で無視しうるように、作動モニタ及び再パーティショニングするためのツールを提供する。
開発のためのオブジェクトモデルの使用は、パーティショニングのための論理的境界を特定する上に助けとなる。各々のサービスオブジェクトは、ランタイムにある潜在的に多くの数のオブジェクトを各々それ自身の方法で即時化（インスタンシエイト）するので、ディフォルトパーティショニングプロセスは、各々のパーティションにおいて呼出されうる全ての可能な方法を特定化しなければならない。次にこのシステムは、呼ばれた時アクセス可能なように、これらの方法をそのパーティション中に位置せねばならない。パーティショニングは、これらの方法が他のノードからランタイムにおいて呼びこまなければならない場合は、有効に働かない。
アプリケーションパーティションを作成した後、Forte'は、環境中のターゲットサーバーに、サーバーパーティションを移動させる。図20及び図21を参照して、Forte'は、どんなネットワークが利用可能かを知るために、ターゲット形態定義を参照し、各々ノード組間にメッセージを送るために適切なネットワーク通信を設定する。各々のForte'サーバーは、異なるサーバーと交信するために、異なる通信プロトコールを使用することができる。
各々のパーティションは、パーティション間の通信、各々のパーティション内のメッセージトラフィック、並びに遠隔のオブジェクトへのメッセージの送出を管理するForte'システムサービスの集合体によってサービスされる。これらのシステムサービスは、各々のノード上の全てのアプリケーションサービスオブジェクトを管理する。
システム生成相のこの点で、パーティショニングされたアプリケーションは、解釈的（インタプリタティブ）に走らせることができる。市販されている多くの4GLと同様に、Forte'は、Forte'インタプリターを介して実行される擬似コードに、4GLソースコードを変換する。Forte'は、分割されたアプリケーションサービスオブジェクトを生成しうるので、これらのオブジェクトは、貯蔵所に格納され、解釈的な実行は、貯蔵所のルックアップを包含する。また解釈的な実行は、ダイナミックSQLでRDBMSにアクセスすることを含む。大部分の従来の4GLは開発及び展開のために、このアプローチを使用するが、Forte'は、開発のために、解釈的モードしか必要としない。生産アプリケーションのために、Forte'は、性能を改善するためのコード発生オプションを供与する。
各々のForte'パーティションは、解釈されたパーティション又はコンパイルされたパーティションとして生産のために展開させることができる。解釈的なラン又はコンパイルされたランかの決定は、パーティションごとに行いうるので、いくらかのトランザクション処理をも含むより大きなアプリケーションの一部として意志決定支援機能を支援するために、解釈的なパーティション及びコンパイルされたパーティションの混合環境をもつことができる。
Forte'は、コンパイルされたアプリケーションを支援するために２つのコード発生ストラテジーを供与する。第一のものは、Forte'の擬似コードを取り、各々のパーティションのための標準的なＣ＋＋コードを発生させるために、発生器を経て、その擬似コードを走らせる。このＣ＋＋コードは、次は、その特定のノードのためのローカルＣ＋＋コンパイラーによりコンパイルされる。得られた機械コードは、展開の間解釈的に走る4GLによって生成される大部分のアプリケーションに、性能上の利益を供与する。コード発生の間、Forte'は、ランタイムシステムが貯蔵所のルックアップの性能上の不利益を惹起することを必要としないように、貯蔵所への全ての参照を解消する。
第二のコード発生ストラテジーは、各々の支援されたRDBMSへの最適のアクセスを生ずるRDBMS特異発生器の組を含む。一例として、Sybaseのコード発生器はTransact  SQLを、またOracle7のコード発生器は、PL/SQLを発生させる。各々の場合に、コード発生器は、データベースアクセスのRDBMS中立な定義を取り、最適化された性能ストラテジーでRDBMSにアクセスするための適切なストラテジーを発生させる。
パーティショニングアプリケーションの管理
アプリケーションは、システム発生に従って、展開のための準備状態にある。第一ステップは、ターゲットデスクトップ機械上にクライアントの１以上のパーティションをインストールすることである。アプリケーションは、PCとMacとの混合環境を呼出すことができる。その場合Forte'は、クライアントパーティションのPCバージョン及びMacバージョンを発生させるであろう。システム運用者は、その場合、各々のデスクトップの機械上において、適切なパーティションをインストールすることを必要とするであろう。
インストレーションは、複製されたパーティションのための機会を供与する。複製されたパーティションをインストールする２つの理由がある。その第一は、ロードの平衡化である。例えば、SMP（対称マルチ処理）環境において、より大きなロードを支援するために１つ以上のプロセッサーにおいてRDBMSエンジンを走らせることには意味があるかもしれない。この場合RDBMSアクセスパーティションは、RDMBSエンジンの配された各々のノードにおいて走らせるべきである。Forte'は、このRDBMSアクセスパーティションの複製を支援し、多重RDBMSエンジンがアプリケーション待ち行列中の次のRDBMSリクエストにサービスすることを許容するように、ルーター（router）を供与する。複製のもう一つの理由は、ノードの不首尾の場合のバックアップを与えることである。分散された環境は、ある任意の時点でシステム中の１つのノードがダウンする可能性を増大させる。そのノードが特に重要ならば、バックアップノードをもつことが適切である。例えば、ノードは、ユーザーのためのキーとなる分析サービス又はイメージを与える。これらの場合には、第一ノードが利用可能でない場合においてアクセス可能な別のノードとして複製されたパーティションを定義できる。Forte'はまた、このようなバックアップノードにアクセスしうるルーターを与える。
分散ランタイム環境が複製のアプリケーションパーティション間にコミュニケーションを提供しなければならないことについては前述した通りである。このコンセプトは、多くの開発ツールにそぐわない。従来のツールは、クライアントとサーバーとの間の通信リンクを与えるために、RDBMSに依存することによって、RDBMSを、各々のアプリケーションの重要な一部とする。Forte'は、RDBMSがアプリケーションの一部分であるとは想定せず、たとえそうであっても、Forte'は、RDBMSにより供与される通信の可能性を増大させる。これは、非RDBMSサーバーと交信する場合に特に重要となりうる。Forte'は、それ自身の分散メッセージシステムによって、アプリケーションパーティションの間の通信を与える。メッセージシステムは、あるパーティション内のオブジェクト間にメッセージを移行させることができ、また異なるパーティション中に位置されたオブジェクト間にメッセージを移行させることができる。ノード間のメッセージングは、ローカルパーティション中に配されたプロクシオブジェクトの助けをかりて行われる。クライアントパーティション中のオブジェクトがサーバーパーティション中のオブジェクトにメッセージを送ることを必要とする場合、パーティショニングアルゴリズムは、クライアントパーティション中にサーバーオブジェクトのプロクシ（代理）を立てねばならない。このストラテジーは、全てのサーバーオブジェクトがクライアントに位置されたかのように、全てのクライアント駐在オブジェクトが振舞うことを可能とする。クライアントオブジェクトがサーバーオブジェクトにメッセージを送る場合、プロクシは、メッセージを遮断し、物理的サーバーオブジェクトが存在するノードにそのメッセージを再指向させる。プロクシを使用するこのストラテジーは、ネットワーク上に大きなオブジェクトを送る必要を除き、物理的オブジェクトがどこに位置しているかと拘りなしにアプリケーションが同じように振舞うことを許容する。これがアプリケーションのパーティショニングの解決を成功させさせる重要な特徴である。
分散されたアプリケーションを一度展開させると、それを単一体として運用しうることは非常に有用である。これは単一の運用インターフェイスからパーティションを開始しまた停止させうることを意味する。また、これは、作動上の問題を生じた場合の故障の発見に加えて、全体としてのアプリケーションの作動をモニターしうることを意味する。どこで時間が消費されているか？通信においてか、または特定のパーティションにおいてか？この情報は、アプリケーション全体を見ることによって作動の障害個所をシステム運用者が突止めることを許容する。図22を参照して、Forte'は、単一のユーザーインターフェイスから分散アプリケーション全体についてこの情報を与えるように環境マネージャーインターフェイスを与える。
作動モニターは、これと異なったパーティショニング計画を示唆しうる。図23を参照して、Forte'は、このプロセスを単純化するために、ドラッグ−アンド−ドロップスタイルのパーティショニングインターフェイスを供与する。アプリケーション運用者は、現在のパーティション計画の概要図を見て、この略図と直接対話することができる。左側に沿って、全てのパーティションと、各々のパーティションに含まれるサービスオブジェクトのリストが表示される。あるサービスオブジェクトを１つのパーティションから次のパーティションに移すために、運用者は、単にドラッグ−アンド−ドロップ操作することができる。同様に、運用者は、パーティションネームを所望のノードにドラッグ−アンド−ドロップすることによって、あるパーティションを略図中の１つのノードから別のノードに移すことができる。また、このインターフェイスは、複製パーティションを設定するために、略図上において左側のリストから第２のノードへ、パーティションネームをドラッグするためにも使用しうる。
新しいパーティショニング計画が定義されたら、運用者は、同一の展開環境のための新しいパーティショニング計画を発生させるために指令を実行することができる。両方のパーティショニング計画は、最大の融通性のために貯蔵所中に格納される。この新しいパーティショニング計画は、次に、切換えのためにインストールすることが必要とされる。
パーティショニングは、分散アプリケーションを構成し、与えられた展開環境のためのアプリケーションをパーティショニングし、単一体として全てのアプリケーション部分を運用し、問題が生じたり必要条件が形成され続ける場合に、アプリケーションを再パーティショニングするための、容易な方法を供与する。アプリケーションのパーティショニングは、企業規模の、使用にとって重要なアプリケーションの要求に適合するように、クライアント−サーバーアーキテクチュアを進展させるための重要なストラテジーである。
本発明を使用する方法及び装置並び本発明の好ましい実施態様について以上に説明した。当業者たちは、以上に述べた方法及び装置の多くの特徴について、本発明の教示に含まれる変更を含む多くの変更を認識し実行することができよう。本発明の精神及び範囲は、下記の請求の範囲に示された通りである。
【図１Ａ】
0003541039.tif 000002
【図１Ｂ】
0003541039.tif 000003
【図２】
0003541039.tif 000004
【図３】
0003541039.tif 000005
【図４】
0003541039.tif 000006
【図５】
0003541039.tif 000007
【図６Ａ】
0003541039.tif 000008
【図６Ｂ】
0003541039.tif 000009
【図７】
0003541039.tif 000010
【図８】
0003541039.tif 000011
【図９】
0003541039.tif 000012
【図１０】
0003541039.tif 000013
【図１１】
0003541039.tif 000014
【図１２】
0003541039.tif 000015
【図１３】
0003541039.tif 000016
【図１４】
0003541039.tif 000017
【図１５】
0003541039.tif 000018
【図１６】
0003541039.tif 000019
【図１７Ａ】
0003541039.tif 000020
【図１７Ｂ】
0003541039.tif 000021
【図１８】
0003541039.tif 000022
【図１９】
0003541039.tif 000023
【図２０】
0003541039.tif 000024
【図２１】
0003541039.tif 000025
【図２２】
0003541039.tif 000026
【図２３】
0003541039.tif 000027