(57)【要約】【課題】各レガシ・アプリケーションをEnterprise Java(R) Beans（ＥＪＢ）インターフェース仕様に従う新しいアプリケーションにカプセル化することによって、既存ソフトウェア・アプリケーションまたはレガシ・ソフトウェア・アプリケーションを分散データ処理環境に組み込むシステムおよび方法を提供すること。【解決手段】ＥＪＢインターフェースを有する新しいアプリケーションを用いると、イントラネットなどの仮想プライベート・ネットワークまたはインターネットなどの分散処理環境でのアプリケーションの使用が可能になる。
2004529412.tif 000002
【特許請求の範囲】
【請求項１】
レガシ・アプリケーションを分散データ処理環境に統合するシステムであって、
ネットワークに結合されたサーバに配置されたレガシ・アプリケーションと、
前記レガシ・アプリケーションを囲むポータブル・マシンに非依存のインターフェース・ラッパーであって、前記ラッパーが、前記ネットワークを介する前記アプリケーションの分散処理を可能にするインターフェースを含み、これによって、前記インターフェースが、分散処理を可能にし、前記レガシ・アプリケーションが、その通常の処理を保つ、ポータブル・マシンに非依存のインターフェース・ラッパーと
を含むシステム。
【請求項２】
前記ポータブル・マシンに非依存のラッパーがEnterprise Java(R)Bean（ＥＪＢ）ラッパーである請求項１に記載のシステム。
【請求項３】
さらに、データが参照によるのではなく値によって渡されるのを容易にするためのコンポーネント・シーケンス構造を含む、請求項１または２に記載のシステム。
【請求項４】
レガシ・アプリケーションを分散データ処理環境に統合する方法であって、
レガシ・アプリケーションの機能をコンポーネントに分離するために前記レガシ・アプリケーションを分析するステップと、
前記コンポーネントを異なるサーバに分散するステップと、
各コンポーネントにポータブル・マシンに非依存のインターフェースを設けるステップと、
前記コンポーネントおよび前記インターフェースへのインデックスを提供するステップと
を含む方法。
【請求項５】
ポータブル・マシンに非依存のインターフェースがEnterprise Java(R)Beanインターフェースである、請求項４に記載の方法。
【請求項６】
さらに、データのシーケンスのリスティングを提供するステップを含み、その結果、データをコンポーネント間で参照によるのではなく値によって渡せるようになる、請求項４または５に記載の方法。
【請求項７】
さらに、component beanにアクセスする共用ライブラリおよびエクスポート・シンボルのライブラリを使用するステップを含む、請求項４に記載の方法。
【請求項８】
分散データ処理環境で使用されるようにレガシ・プログラムを適合させる、記憶媒体に保管されたプログラムであって、
ポータブル・マシンに非依存のコンポーネントを提供する第１プログラム・モジュールと、
前記レガシ・アプリケーションからの機能を提供する第２プログラム・モジュールと、
前記コンポーネントおよび前記機能へのインデックスを提供する第３プログラム・モジュールと
を含むプログラム。
【請求項９】
前記ポータブル・マシンに非依存のコンポーネントがEnterprise Java(R)Beanである、請求項８に記載のプログラム。
【請求項１０】
さらに、アプリケーションの共通シーケンス構造を提供する第４プログラム・モジュールを含み、これによって、データを、値によって渡すことができ、参照によって渡す必要がない、請求項８または９に記載のプログラム。
【請求項１１】
さらに、アプリケーション用の共用ライブラリを提供する追加プログラム・モジュールを含み、前記共用ライブラリが、component beanにアクセスし、エクスポート・シンボルのリストにアクセスする要素を含む、請求項９に記載のプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は下記の特許に関連する。
（ｉ）本願の譲受人に譲渡された、「Method and System forDatabase Management for Supply Chain Management」と称する２０００年１月２６日にＢｉａｌｉｋ他によって出願された係属米国特許出願第０９／４９１８３４号（整理番号ＣＨＡ９−９９−０１４）。
（ｉｉ）本願の譲受人に譲渡された、「Method and System forAutomated Session Resource Clean-up in a Distributed Client-Server Environment」と称するＩｗａｏ  Ｈａｔａｎａｋａによって同時に出願された米国特許出願（割当て予定）（整理番号ＣＨＡ９−９９−０１５）。
【０００２】
本発明は、１つまたは複数のレガシ・ソフトウェア・アプリケーションを、クライアント／サーバ環境で見られるものなどの分散データ処理システムに組み込むシステムおよび方法に関する。
【背景技術】
【０００３】
多数の大組織が、収集されたデータを処理し、中央データ処理施設から組織を管理するのに使用してきたが、この中央データ処理施設には、少なくとも１つのメインフレーム・コンピュータが、アプリケーション・プログラムおよびデータベースと共に設けられ、中央施設から組織を管理するのに必要な情報を生成した。このデータ処理には、大型のローカル・コンピュータ・システムで稼動する、大規模でしばしばカスタム・メードのソフトウェア・プログラムの使用が伴う。そのようなシステムを、エンタープライズ・コンピューティングまたはメインフレーム・ワールドと称することがしばしばである。
【０００４】
しかし、近年、大規模なアプリケーションが単一のメインフレームで稼動するメインフレーム・ワールドから、分散データ処理システムまたは、アプリケーションおよびデータベースが別個の位置に配置され、処理が、複数のデータ処理システムを相互接続するデータ処理ネットワークを使用する複数の（多数であるが小型で安価な）データ処理システム上で行われるシステムに、データ処理を変化させる多数の要因が生じた。
【０００５】
クライアント／サーバ環境では、ローカル端末（時々クライアントとも称する）が、分散環境で情報を処理するためにサーバに接続される。しばしば、クライアント自体が、サーバと通信するデータ処理システムであり、このサーバは、一般に、クライアント位置で使用可能でないアプリケーションおよびデータを含む、クライアントと比較してリソースが増やされたデータ処理システムである。そのようなシステムが、「Framework for Dynamic Hierarchical Grouping and Calculation based onMultidimensional Characteristics」と称するＣｅｓｓａｎａ他によって１９９９年９月３０日に出願された係属米国特許出願第０９／４０９３４５号（整理番号ＣＨＡ９−１９９９−０００４）に詳細に記載されている。
【０００６】
クライアントは、しばしば、サーバから離れて配置され、たとえば、単独もしくは衛星通信またはマイクロ波通信などの他の通信システムとの組合せのいずれかで、電話回線を使用して提供することができるものなどの電話サービスを介して動作するハードウェアおよびソフトウェアを含む、通信機構を使用してサーバと通信する。
【０００７】
中央コンピューティングまたはエンタープライズ・コンピューティングから分散コンピューティングまたはクライアント／サーバ・コンピューティングへのデータ処理の変化に伴う問題は、新しいシステムが、中央コンピューティングまたはエンタープライズ・コンピューティングに関連していたアプリケーションの組と置換されるアプリケーションの完全な組を備えて登場したのではなく、エンタープライズまたは中央に配置された単一のアプリケーション（時々「レガシ」アプリケーションとも称する）から、データ処理ネットワークを介する分散処理を使用するクライアント／サーバ・アプリケーションへ移行する便利な方法がないことである。
【０００８】
クライアント・サーバ・アプリケーションまたは分散アプリケーションは、データ伝送ネットワークおよび他のアプリケーションとのインターフェースに関して、かなり厳格なルールまたはガイドラインの組に従わなければならない。レガシ・アプリケーションは、それほど制限されず、実際に、内部的に一貫性を有することだけが必要なので、レガシ・アプリケーションには、メインフレーム・アプリケーションのよいプログラミング技法（推奨されるドキュメンテーションおよびインターフェース情報）に従うものと、そうでないものがある。レガシ・アプリケーションが新しいコンピューティング環境に「フィット」するようにレガシ・アプリケーションを書き直すことは、長い時間とリソースを必要とする可能性があり、そのような時間およびリソースは、コストが高く、エラーを導入する可能性がある。
【発明の開示】
【発明が解決しようとする課題】
【０００９】
したがって、従来技術のシステムは、望ましくない短所および制限を有する。
【課題を解決するための手段】
【００１０】
本発明は、レガシ・アプリケーションを分散クライアント／サーバ環境に統合するシステムおよび方法を提供することによって、従来技術のシステムの制限および短所のすべてを克服しようとする。本発明の一態様によれば、レガシ・アプリケーションを分散データ処理環境に統合する方法であって、レガシ・アプリケーションの機能を複数のコンポーネントに分離するためにレガシ・アプリケーションを分析するステップと、これらのコンポーネントを異なるサーバに分散するステップと、各コンポーネントにポータブル・マシンに非依存のインターフェースを提供するステップと、コンポーネントとインターフェースへのインデックスを提供するステップとを含む方法が提供される。本発明の好ましい方法では、ポータブル・マシンに非依存のインターフェースはEnterprise Java(R) Beanインターフェースである。
【００１１】
本発明の第２の態様によれば、レガシ・アプリケーションを分散データ処理環境に統合するシステムであって、ネットワークに結合されたサーバに位置するレガシ・アプリケーションと、レガシ・アプリケーションをサラウンドするポータブル・マシンに非依存のラッパーとを備え、ラッパーは、ネットワーク上のアプリケーションの分散処理が可能なインターフェースを含み、それによりインターフェースは分散処理が可能であり、レガシ・アプリケーションはそれの従来の処理を保持する。好ましくは、ポータブル・マシンに非依存のラッパーはEnterprise Java(R) Bean（ＥＪＢ）ラッパーである。
【００１２】
本発明は、実施が単純かつ簡単であって、クライアントからのリモート呼出しを用いてレガシ・アプリケーションを分散データ処理環境で使用できるようになるという長所を有する。さらに、本発明を用いると、レガシ・アプリケーションを変更し、分散データ処理環境で使用することが可能になる。
【００１３】
本発明には、複数のアプリケーションにまたがって一様に使用される共通の変数セットのセット・アップが含まれる。
【００１４】
本発明には、レガシ・アプリケーションを採ることと、EnterpriseJava(R) Beans（ＥＪＢ）インターフェース仕様を使用し、既存のレガシ・アプリケーションの機能を分散可能なコンポーネント内にカプセル化する、コンポーネント・ベースのフロント・エンドまたはインターフェースをそのレガシ・アプリケーションに提供することが含まれる。このインターフェースでは、用語の共通のディクショナリを使用し、他のアプリケーション（特に分散処理環境のアプリケーション）とインターフェースできるようにする。
【００１５】
本発明のシステムは、アプリケーション内の変数を識別するテーブルも考慮に入れ、これらの変数の均一な使用を考慮に入れる。本発明は、変数をアプリケーションに通信するための所定の手順を確立することも可能にし、クライアントとサーバの間のより効率的な通信も可能にする。
【００１６】
本発明の他の目的および長所は、添付図面および請求項と共に考慮される、好ましい実施形態の以下の説明に鑑みて当業者に明白になる。
【発明を実施するための最良の形態】
【００１７】
好ましい実施形態の以下の説明では、発明人に現在既知の本発明を実践する最善の実施形態を、多少詳細に説明する。しかし、この説明は、特定の実施形態での本発明の概念の広範囲の一般的な教示として意図されており、特に、当業者が、これらの図に関して図示され説明される特定の構造および動作に対する多数の変形形態および変更を諒解するので、図示のこの実施形態に本発明を制限することは意図されていない。
【００１８】
図１に、中央コンピュータまたは中央データ処理システム１１０に、必要なデータ処理アプリケーションおよびデータベースなどの関連情報が含まれる、エンタープライズのデータ処理システムの１形態を示す。図１からわかるように、４つのアプリケーション（他のアプリケーション・コンポーネント）および２つのデータベースが、単一の中央コンピュータまたは中央データ処理システム１１０に図示されている。
【００１９】
図１に示された中央データ処理システム１１０を、しばしば、メインフレームまたはエンタープライズ・システムまたは中央プロセッサと称される。そのようなシステムのアプリケーションは、一般に、ＣＯＢＯＬなどの高水準コンピュータ・プログラミング言語で記述され、独立的でないとしても、主に、同一のグループのプログラマによって記述され、同一のコンピュータまたは付近に配置された類似する構成のコンピュータ・システムで稼動する他のアプリケーションとインターフェースする。そのようなエンタープライズ・データ処理システムのこれらのアプリケーションの一部は、時々、異なる組織によって記述されるが、多くの場合に、これらのアプリケーションは、単一の組織から生じ、その顧客のためにプログラムがインストールされた特定の顧客に会わせてカスタマイズされている場合がある。大組織の一部は、内製システムを使用してそれ自体のアプリケーションを作成し、数年にわたってそのシステムをカスタマイズし、修正し、その結果、そのシステムが、真に独自であり、それを使用する単一の顧客の特定のデータ処理の必要に適するようになっている場合がある。そのようなシステムは、大会社のデータ処理事業部に存在することがしばしばであり、そのようなシステムに簡易床およびガラスの壁が含まれた時代から、時々、「ガラス・ハウス」データ処理システムおよびアプリケーションと称される。そのようなシステムは、中央のデータ処理スタッフまたは情報技術スタッフによって集中化された形で運営されることがしばしばであり、この場合、データのすべてが、単一のロケーションに送られ、処理され、最終レポートの形で使用ロケーションに返される。
【００２０】
この図１からわかるように、そのような中央データ処理システム１１０には、符号１１２によって表される第１のアプリケーション（またはアプリケーション・コンポーネント）ＡＰＰＬＮ１、符号１１４によって表される第２のアプリケーションＡＰＰＬＮ２、符号１１６によって表される第３のアプリケーションＡＰＰＬＮ３、符号１１８によって表される第４のアプリケーションＡＰＰＬＮ４、符号１２０によって表される第１のデータベースＤＢ１、および符号１２２によって表される第２のデータベースＤＢ２を含めることができる。この図からわかるように、このデータ処理システムは、サプライ・チェーン・マネジメントおよび在庫管理に使用され、第１のアプリケーションＡＰＰＬＮ１が、在庫アプリケーションであり、第２のアプリケーションＡＰＰＬＮ２が、販売促進アプリケーションであり、第３のアプリケーションＡＰＰＬＮ３が、販売アプリケーションであり、第４のアプリケーションＡＰＰＬＮ４が、発注アプリケーションである。第１データベースＤＢ１には、手持ちの商品の詳細が格納され、第２データベースＤＢ２には、店舗売上記録の詳細、またはどの商品が過去にどの店で販売されたかが格納される。
【００２１】
これらのさまざまなアプリケーションは、関連するデータベースと共に、単一の統合されたアプリケーションの一部としても良く、また、図１の集中処理環境に示された単一の中央データ処理システム１１０で稼動する別々のアプリケーション・モジュールとして記述することもできる。
【００２２】
しかし、最近、使用可能なシステムの変化と、ネットワークおよびより小型のプロセッサの能力の向上とに起因して、分散プロセッサ・システムが、生まれ、速度の向上および相対コストの減少に伴って、多くのデータ処理システムの魅力的なモデルになってきた。データ処理のタイプの変化と共に、Ｃ＋＋およびAdaなどのオブジェクト指向プログラミング言語を含むデータ処理言語タイプの変化が到来した。そのようなプログラミング言語では、定義されたインターフェースを介するデータの交換を考慮に入れたインターフェース仕様が使用される。残念ながら、そのような分散データ処理環境および新しいプログラミング言語の出現は、分散データ処理を利用するすべての範囲のアプリケーションが作成されたことを意味するものではなく、中央サーバまたはエンタープライズ・サーバのために記述され、それらにインストールされたアプリケーションを、分散データ処理環境での処理に適するアプリケーションにする便利な方法もない。
【００２３】
図２に、分散データ処理システムで見られるタイプのデータ処理システムのコンポーネントを示す。この図２からわかるように、多数の個々のプロセッサが、データ伝送ネットワーク２０２に結合され、分散環境またはクライアント／サーバ環境でさまざまな動作を実行する。例示のためにこの図２に示されているように、PROCESSOR1  ２０３、PROCESSOR2  ２０４、PROCESSOR3  ２０５、PROCESSOR4  ２０６、PROCESSOR5  ２０７、およびPROCESSOR6  ２０８と称する６つのプロセッサが、データ伝送ネットワーク２０２に結合される。PROCESSOR1  ２０３には、第１のアプリケーションＡＰ１  ２１２が含まれ、PROCESSOR2  ２０４には、第２のアプリケーションＡＰ２  ２１４が含まれる。PROCESSOR3  ２０５には、２つのアプリケーション、ＡＰ３  ２１６およびＡＰ４  ２１８が含まれる。PROCESSOR4  ２０６は、第１のデータベースＤＢ１  ２２０を有し、PROCESSOR5には、第２のデータベースＤＢ２  ２２２がマウントされている。これらのアプリケーションのそれぞれを、本明細書で後に説明する変換を介して図１の関連するアプリケーションに関係させて、エンタープライズ・アプリケーションまたは中央アプリケーションを、クライアント／サーバ・データ処理を使用する本発明の分散データ処理環境での使用に適するアプリケーションに変換することができる。
【００２４】
図３に、図２の分散データ処理システムで使用される、変換された図１のアプリケーションを概念的に示す。レガシ・アプリケーションは、ＥＪＢインターフェース仕様に従うコンポーネント・ベースのフロント・エンドまたはインターフェース３２０と共に、符号３１０によって表され、このインターフェース３２０は、レガシ・アプリケーション３１０が、矢印３３０によって示されるように分散データ処理システム内で通信できるようにする。
【００２５】
図４に、図１のレガシ・アプリケーションから図２のシステムへのアプリケーション（またはアプリケーションのコンポーネント）の変換の流れ図を示す。この方法のステップには、以下のステップが含まれる。ブロック４０２で、アプリケーションを分析し、アプリケーションの機能を、複数の論理的なコンポーネントにグループ化する。その論理的コンポーネントを物理的に表すのに適する属性およびメソッドを有するEnterprise Java(R) Bean（ＥＪＢ）を、ブロック４０４で作成する。各コンポーネントのEnterpriseJava(R) Beanインターフェースが、Component Remote Interface（ＣＲＩ）と称するインターフェースを作成することによって作成され、インターフェース定義言語（ＩＤＬ）で定義される。
【００２６】
ブロック４０６で、Component Home Interface（ＣＨＩ）を構成して、ComponentRemote Interface（ＣＲＩ）を作成する標準的な方法を提供するＥＪＢ仕様に従う。Component Home Interface（ＣＨＩ）を、ブロック４０８で標準的なネーミング・サービス（ＮＳ）に登録し、分散アプリケーションが、ComponentHome Interface（ＣＨＩ）への参照を得られるようにする。Component Home Interfaceは、インターフェース定義言語（ＩＤＬ）で定義される。
【００２７】
次に、ブロック４１０で、Component Structure Sequence（ＣＳＳ）を作成し、保管し、その結果、アプリケーションのデータを、「参照によって」渡すのではなく、「値によって」渡すことができるようにする。これによって、アプリケーションの間で複数の呼出しを使用せずに、順序付けられたシーケンスでデータを渡せるようになる。ComponentStructure Sequence（ＣＳＳ）は、ＩＤＬで定義される。
【００２８】
その後、Component Home Interface（ＣＨＩ）およびComponentRemote InterfaceのJava(R)実装ファイルを、ブロック４１２で作成する。この処理を、図５の例に関してさらに説明する。
【００２９】
ブロック４１４で、ＩＤＬファイルをコンパイルして、新しいアプリケーションに対応するJava(R)コードを生成し、ブロック４１６で、Java(R)Native Interface（Java(R)コマンド）を使用して、レガシ・アプリケーションに組み込むためのJava(R) Native Interfaceヘッダ・ファイル（ＪＮＩヘッダ）を生成する。
【００３０】
その後、ブロック４１８で、新しいＪＮＩメソッド名を、レガシ共用ライブラリのエクスポート・リストに追加する。既存のレガシ・アプリケーションの言語のComponent Beanファイルを、ブロック４２０で作成する。このファイルには、上のブロック４１６で作成されたＪＮＩヘッダ・ファイルが含まれる。そのComponentBeanファイルを、コンパイルし、エクスポート・リストと共に共用ライブラリにリンクする。
【００３１】
サーバ・コードをブロック４２２で更新して、分散アプリケーションへの使用可能性を宣言するためにネーミング・サービスにComponent Home Interface（ＣＨＩ）を登録する。
【００３２】
クライアント・コードをブロック４２４で更新して、Component HomeInterfaceへの参照を入手し、レガシ機能をカプセル化する属性およびメソッドを使用するために、Component Remote Interfaceインスタンスを作成する。
【００３３】
図５に、本発明の原理、特に図４に示された方法ステップを、レガシ・アプリケーションの例、この場合ではMakoroと称する、数年前からＩＢＭ社から市販されているプログラムである在庫管理用アプリケーションに関して説明する。図５からわかるように、このアプリケーションには、mp.ejb.user.serverからのUserComponentHomeImplを含むベース部分５１０と、部分５２０へのインターフェース、そこから部分５３０へのインターフェース、および部分５４０へのインターフェースが含まれる。コンポーネントは、各部分に存在し、その出所が、この図に示されている。
【００３４】
図６に、本発明の実践に有用なシステムのコンポーネントを示す。この図からわかるように、複数のコンポーネント６１０、６１２、６１４、６１６、６１８、６２０、６２２、および６２４が、図の中央に示されている。それぞれが、Enterprise Java(R) Bean（ＥＪＢ）からなり、分散処理環境で通信することができるレガシ・アプリケーションのコンポーネントを表す。各コンポーネント（たとえば６１０）は、ＥＪＢサーバ６３０（システムのネーミング・サービスとしてサービスするサーバ・プロセス６３２に結合される）および共用ライブラリlibstd.a６３６に結合され、共用ライブラリlibstd.a６３６は、ファイルComponentBean６３７およびエクスポート・リストlibstd.exp６３８に結合される。ＥＪＢサーバ６３０は、各Component Home Interface（ＣＨＩ）をサーバ・プロセス６３２に登録するJava(R)アプリケーション・サーバである。レガシ・アプリケーション・データ・リソース６７０と他のレガシ・プロセス６６２および６６４は、共用ライブラリlibstd.a６３６を介してアクセスされる。
【００３５】
個々のMakoro Merchandise Plannerクライアント（ＭＭＰクライアント）６４０は、IBMJava(R) Object Resource Broker６５０ａを使用する分散処理ネットワークへの接続を介してコンポーネントに結合される。ＭＭＰクライアント６４０は、ネーミング・サービス機能を含み、Java(R)  ＯＲＢ６５０を使用する、サーバ・プロセス６３２にも結合される。ＭＭＰクライアント６４０が、コンポーネントの１つ（６１０、６１２、６１４、６１６、６１８、６２０、６２２、または６２４）のインスタンスに対してメソッドを呼び出す時に、その要求が、共用ライブラリlibstd.a６３６内のファイルComponentBean６３７へのＪＮＩを介して処理され、対応するレガシ・プロセス／リソースにルーティングされる。したがって、ＭＭＰクライアント６４０は、共用ライブラリlibstd.a６３６内の非標準アプリケーション・プログラミング・インターフェース（ＡＰＩ）に直接にアクセスするのではなく、標準ＥＪＢコンポーネント・インターフェースを介してレガシ・アプリケーションのサービスを使用することができる。
【００３６】
本発明は、ハードウェア、ソフトウェア、またはハードウェアとソフトウェアの組合せで実現することができる。本発明によるデータ処理ツールは、１つのコンピュータ・システム内で集中化された形で、または異なる要素が複数の相互接続されたコンピュータ・システムにまたがって分配される分散式で、実現することができる。あらゆる種類のコンピュータ・システム、または本明細書に記載の方法を実行するように適合された他の装置が、適する。ハードウェアおよびソフトウェアの通常の組合せは、ロードされ実行される時にコンピュータ・システムが本明細書に記載の方法を実行するようにコンピュータ・システムを制御するコンピュータ・プログラムを有する汎用コンピュータ・システムとすることができる。本発明は、本明細書に記載の方法の実施形態を可能にするすべての特徴を含み、コンピュータ・システムにロードされた時にこれらの方法を実行することができる、コンピュータ・プログラム製品に組み込むこともできる。
【００３７】
この文脈での「コンピュータ・プログラム手段」または「コンピュータ・プログラム」は、ａ）別の言語、コード、または表記への変換、またはｂ）異なるマテリアルフォームでの複製の一方または両方のいずれかの後または直接にのいずれかで、情報処理機能を有するシステムに特定の機能を実行させることを意図された命令の組の、あらゆる言語、コード、または表記でのすべての表現を意味する。
【００３８】
本発明を、リソース管理を提供する装置および方法に関して説明したが、本発明は、情報の収集、保守、および処理が、サーバと離れて配置され、情報が必要に応じてサーバに通信される、サービスの形で実施することができる。
【００３９】
もちろん、添付図面と共に考慮される、本発明の前述の説明に鑑みて、本発明の多数の修正形態が、当業者に明白であろう。たとえば、説明を簡単にするために、Java(R)およびEnterprise Java(R) Beansに関するインターフェースの説明を使用したが、実際には、分散プログラミング・コンポーネント間の共通インターフェースの使用を生成する他のシステムを、本発明で有利に使用することができる。さらに、セッションに関して維持される情報の位置およびタイプを、アプリケーションに合わせて修正することができる。分散データ処理システムおよびそれらを接続するネットワークの数、タイプ、および位置は、ユーザの設計および実装の判断基準の対象であり、本発明の一体化された部分ではない。ファイルの名前も、設計選択およびシステムの考慮事項の問題である。さらに、本発明のいくつかの特徴は、本発明の趣旨から逸脱せずに、他の特徴の対応する使用なしで有用になる可能性がある。たとえば、参照によるのではなく値による変数渡しの使用によって、不要な呼出しがなくなり、一般に望ましい可能性があるが、あるシステムで、値によるデータ渡しを使用せずに本発明の概念を使用することができる。したがって、好ましい実施形態の前述の説明は、単に本発明の原理の例示とみなされなければならず、本発明の制限とみなされてはならない。
【図面の簡単な説明】
【００４０】
【図１】大きいレガシ・データ処理アプリケーションが、組織のデータを処理するための単一のコンピュータにインストールされる、従来技術のデータ処理システムを示す図である。
【図２】複数のより小さい分散データ処理システムがデータ伝送ネットワークに結合される、本発明の好ましい実施形態を表す通信システムを示す図である。
【図３】図２に示された分散システムで使用されるアプリケーションを示す図である。
【図４】本発明の好ましい実施形態の流れ図である。
【図５】本発明を使用するアプリケーションを示す図である。
【図６】本発明を使用するためにオブジェクト・ブローカ・ネーミング・サービスを使用する処理を示す図である。
【図１】
2004529412.tif 000003
【図２】
2004529412.tif 000004
【図３】
2004529412.tif 000005
【図４】
2004529412.tif 000006
【図５】
2004529412.tif 000007
【図６】
2004529412.tif 000008
【国際公開パンフレット】
2004529412.tif 000009
2004529412.tif 000010
2004529412.tif 000011
2004529412.tif 000012
2004529412.tif 000013
2004529412.tif 000014
2004529412.tif 000015
2004529412.tif 000016
2004529412.tif 000017
2004529412.tif 000018
2004529412.tif 000019
2004529412.tif 000020
2004529412.tif 000021
2004529412.tif 000022
2004529412.tif 000023
2004529412.tif 000024
2004529412.tif 000025
2004529412.tif 000026
【国際公開パンフレット（コレクトバージョン）】
2004529412.tif 000027
2004529412.tif 000028
【国際調査報告】
2004529412.tif 000029
2004529412.tif 000030
2004529412.tif 000031