JP2005182419A - コンポーネント処理システム及びコンポーネント処理方法 - Google Patents

Abstract

【課題】複数のアプリケーションがそれぞれ利用するコンポーネントを一元管理して、コンポーネントの変更に効率的に対応できるコンポーネント処理システム及びコンポーネント処理方法を提供する。
【解決手段】個々のアプリケーションが利用するコンポーネントの配置場所を公開するコンポーネント環境定義情報を、コンポーネントの配置場所を定義するコンポーネント配置定義情報、利用コンポーネントを定義したコンポーネント利用定義情報、個々のアプリケーションに対応するコンポーネント利用定義情報を指定する情報を含むアプリケーション配置定義情報とで構成する。フレームワーク上のコンポーネント管理部はアプリケーションからの要求で、このアプリケーションが利用するコンポーネントの配置場所の取得をミドルウェアに要求し、ミドルウェアはコンポーネント環境定義情報を読み込んで応答する。
【選択図】図１

Description

本発明は、コンポーネントを利用してアプリケーションを動作させるためのコンポーネント処理システム及びコンポーネント処理方法に関する。

コンポーネントとは、アプリケーションを構築するためのビジネスロジックなどを実装したソフトウェア部品である。例として、米国Ｓｕｎ Ｍｉｃｒｏｓｙｓｔｅｍｓ社が提唱している規約であるＥＪＢ（Ｅｎｔｅｒｐｒｉｓｅ Ｊａｖａ Ｂｅａｎｓ（登録商標））などがある。ＥＪＢは、Ｊａｖａ（登録商標）プログラム言語で分散オブジェクト指向の業務アプリケーションを構築するための標準コンポーネントアーキテクチャであり、異なるベンダのツールを使用して開発したコンポーネントを組み合わせることで分散アプリケーションの構築を可能とするものである。ＥＪＢを利用することによって、開発者は、アプリケーション開発時にビジネスロジックの開発だけに専念でき、効率的なアプリケーション開発が可能になる。

ＥＪＢアーキテクチャにおいては、ＥＪＢコンポーネントの実行環境をコンテナが提供するようになっている。通常、このコンテナはＥＪＢサーバによって管理される。ＥＪＢクライアント（アプリケーション）が、コンテナが提供する標準化されたインターフェイスを介してコンテナにＥＪＢのオブジェクト生成を要求すると、コンテナは、Ｄｅｐｌｏｙｍｅｎｔ Ｄｅｓｃｒｉｐｔｏｒと呼ばれる、コンポーネントの動作条件（トランザクション管理、セキュリティ管理などの属性値）を定義する記述を読み込み、この動作条件に基づいてコンポーネントの組み込み、実体生成を行う。これにより実行可能なコンポーネントが生成される（たとえば、特許公報１参照）。
特開２００２−４９４９６号公報

図１２は、一般的なコンポーネント処理システムの構成を示す図である。コンポーネント環境定義情報７１は、アプリケーション７２（７２Ａ、７２Ｂ）が利用するコンポーネント７３（７３Ａ、７３Ｂ、７３Ｃ）の配置場所などを定義したものである。ミドルウェア７６は、アプリケーション７２からのコンポーネント７３の利用の要求を受けて、コンポーネント環境定義情報７１を読み込み、アプリケーション７２が利用するコンポーネント７３の配置場所を認識する。このことにより、アプリケーション７２は、ミドルウェア７６により実体化されたコンポーネント７３を利用している。

また、コンポーネント環境定義情報７１はアプリケーション７２ごとの配置定義情報７４（アプリケーションＡ配置定義情報７４Ａ、アプリケーションＢ配置定義情報７４Ｂ）で構成されている。それぞれのアプリケーション配置定義情報７４には、各々のアプリケーション７２が利用するコンポーネント７３を定義する情報７５（コンポーネントＣ１定義情報７５Ａ、コンポーネントＣ２定義情報７５Ｂ、コンポーネントＣ３定義情報７５Ｃ）が共通に記述されており、この情報７５に基づいて、該当するコンポーネント７３の配置場所が記述されたコンポーネント配置定義情報７７（コンポーネントＣ１配置定義情報７７Ａ、コンポーネントＣ２配置定義情報７７Ｂ、コンポーネントＣ３配置定義情報７７Ｃ）を取得することで、コンポーネント７３の配置場所が分かるようになっている。

しかしながら、上記のように、各々のアプリケーション配置定義情報７４には、アプリケーション７２が利用するコンポーネント７３を定義する情報７５が含まれる構成となっているので、各アプリケーション７２が共通に利用するコンポーネント７３の変更が発生した場合に、各アプリケーション配置定義情報７４に同様の変更を加える必要があり、コンポーネントの管理が煩雑になるという問題があった。また、複数のアプリケーション７２のアプリケーション配置定義情報７４を新たに設定する際にも、コンポーネント７３を定義する情報７５を共通に記述する必要があり、多大な作業時間を要することになり面倒であっただけでなく、コンポーネントの一元管理をミドルウェアに任せていたため、ミドルウェアに要する処理負担が非常に多かった。

また、ＥＪＢアーキテクチャでは、前述したように、コンテナがコンポーネントの振る舞い定義情報を読み込むことによって実行可能なコンポーネントを生成しているが、振る舞い定義情報の置き場所はコンテナベンダーによって決められ、コンテナにその場所情報にアクセスする機能が実装されている。また、振る舞い定義情報の形式もコンテナに依存している。すなわち、ＥＪＢアーキテクチャでは、定義情報の場所、その記述形式、定義内容について多くの制約が課せられており、このことがシステムの設計の自由度を損ね、開発効率の向上を阻んでいた。

したがって、従来の技術においては、前述したように、アプリケーションに利用されるコンポーネントの変更が発生した場合に、このコンポーネントを利用するすべてのアプリケーションのコンポーネント環境定義情報に同様の変更を加えなければならず、管理コストの増大、開発効率の低下を招くという課題があった。また、コンポーネントの一元管理をミドルウェアが実行していたため、ミドルウェアによる処理負担が非常に大きい課題もあった。さらに、コンポーネント振る舞い定義情報の場所、記述形式、定義内容に課せられた制約により、システム設計の自由度が損なわれ、開発効率の低下を招いていた。

本発明はこれらの課題を解決するためになされたもので、複数のアプリケーションがそれぞれ利用するコンポーネントを一元管理して、アプリケーションに利用されるコンポーネントの変更に効率的に対応することのできるコンポーネント処理システム及びコンポーネント処理方法を提供することを目的とする。

また、本発明は、コンポーネントの振る舞いを高い自由度で変更でき、システム設計の自由度を高めることのできるコンポーネント処理システム及びコンポーネント処理方法を提供することを目的とする。

かかる目的を達成するために、本発明のコンポーネント処理システムは、オペレーティング・システム上で動作するミドルウェアと、このミドルウェア上で動作するフレームワークと、フレームワーク上で動作する少なくとも一つのアプリケーションと、アプリケーションによって選択的に利用可能な複数のコンポーネントと、個々のコンポーネントの配置場所が定義されたコンポーネント配置定義情報、利用されるコンポーネントが定義されたコンポーネント利用定義情報、及びアプリケーションに対応するコンポーネント利用定義情報を指定する情報を含むアプリケーション配置定義情報を有するコンポーネント環境定義情報と、フレームワークに設けられ、アプリケーションからの要求により、アプリケーションにより利用されるコンポーネントの配置場所の取得をミドルウェアに要求し、その応答として取得した配置場所にあるコンポーネントに対して実体化を要求するコンポーネント管理部と、ミドルウェアに設けられ、コンポーネント管理部からの要求を受け、コンポーネント環境定義情報から、アプリケーションにより利用されるコンポーネントの配置場所を取得してコンポーネント管理部に応答するコンポーネント環境定義情報読込部とを有することを特徴とする。

この発明によれば、フレームワークに設けたコンポーネント管理部が個々のアプリケーションにより利用されるコンポーネントをコンポーネント環境定義情報で一元管理することになり、管理コストの低減、開発効率の向上を図ることができ、さらに、従来コンポーネントの実体化を一元管理させていたミドルウェアの処理負担を軽減することができるという効果を奏する。

また、本発明のコンポーネント処理システムは、オペレーティング・システム上で動作するミドルウェアと、ミドルウェア上で動作するフレームワークと、フレームワーク上で動作する少なくとも一つのアプリケーションと、アプリケーションによって選択的に利用可能な複数のコンポーネントと、個々のコンポーネントの振る舞いがそれぞれ定義された複数の振る舞い定義情報と、個々のコンポーネントの配置場所が定義されたコンポーネント配置定義情報、利用されるコンポーネントが定義されたコンポーネント利用定義情報、及びアプリケーションに対応するコンポーネント利用定義情報を指定する情報を含むアプリケーション配置定義情報を有するコンポーネント環境定義情報と、フレームワークに設けられ、アプリケーションからの要求により、アプリケーションにより利用されるコンポーネントの配置場所の取得をミドルウェアに要求し、その応答として取得した配置場所にあるコンポーネントに対して振る舞い定義情報に基づく動作条件を与えて実体化を要求するコンポーネント管理部と、ミドルウェアに設けられ、コンポーネント管理部からの要求を受け、コンポーネント環境定義情報から、アプリケーションに利用されるコンポーネントの配置場所を取得してコンポーネント管理部に応答するコンポーネント環境定義情報読込部とを有することを特徴とする。

この発明によれば、フレームワークに設けたコンポーネント管理部が個々のアプリケーションにより利用されるコンポーネントをコンポーネント環境定義情報で一元管理することになり、コンポーネントの開発時や設計時において振る舞い定義情報を自由に変更することによりコンポーネントの振る舞いを高い自由度でカスタマイズすることができ、システム設計の自由度や他システムへの流用性を高めることができる。さらに、従来コンポーネントの実体化を一元管理させていたミドルウェアの処理負担を軽減することができるという効果を奏する。

本発明のコンポーネント処理システム及びコンポーネント処理方法によれば、個々のアプリケーションにより利用されるコンポーネントをコンポーネント環境定義情報で一元管理することができ、管理コストの低減、開発効率の向上を図ることができる。また、コンポーネントの振る舞いを、高い自由度で変更することができ、システム設計の自由度を高めることができる。

以下、図面を参照して本発明の実施の形態について説明する。

図１は、本発明の第１の実施形態に係るコンポーネント処理システム１００の構成を示す図面である。

同図に示すように、このコンポーネント処理システム１００は、ＣＰＵ１、メモリ２、外部記憶装置３、バス４などの一般的なコンピュータアーキテクチャを有するコンピュータ１０上に構築されている。このコンピュータ１０はインターネットやＬＡＮなどのネットワーク５にネットワーク接続装置６を通じて接続されている。

このコンポーネント処理システム１００のソフトウェア要素としては、オペレーティング・システム１１（以下「ＯＳ１１」という。）と、ＯＳ１１上で動作するミドルウェア１２と、ミドルウェア１２上で動作するフレームワーク１３と、フレームワーク１３上で動作するアプリケーション１４（１４Ａ、１４Ｂ）と、アプリケーション１４が利用するロジックを実装したコンポーネント１５（１５Ａ、１５Ｂ、１５Ｃ）と、コンポーネント環境定義情報１８と、フレームワーク１３に設けられ、アプリケーション１４からの要求により、当該アプリケーション１４が利用するコンポーネント１５の配置場所の取得をミドルウェア１２に依頼してアプリケーション１４に応答するコンポーネント管理部２０とがある。ここでアプリケーション１４の数は２、コンポーネント１５の数は３としたが、これらの数に特に限定や制限はない。コンポーネント管理部２０は、フレームワーク１３にプラグインして構成されたものである。

ミドルウェア１２はアプリケーション・サーバと同義であり、トランザクション処理、負荷分散処理、データベース処理を実行する。さらに、ミドルウェア１２には、そしてコンポーネント管理部２０からの依頼を受け、コンポーネント環境定義情報１８から当該アプリケーション１４が利用するコンポーネント１５の配置場所を取得してコンポーネント管理部２０に応答する機能を有するコンポーネント環境定義情報読込部１２ａが組み込まれている。

コンポーネント環境定義情報１８は、個々のアプリケーション１４が利用するコンポーネント１５の配置場所をコンポーネント管理部２０に公開する定義文である。すなわち、図２に示すように、コンポーネント環境定義情報１８は、個々のコンポーネント１５（コンポーネントＣ１、コンポーネントＣ２、コンポーネントＣ３）の配置場所を定義した複数のコンポーネント配置定義情報１６（コンポーネントＣ１配置定義情報１６Ａ、コンポーネントＣ２配置定義情報１６Ｂ、コンポーネントＣ３配置定義情報１６Ｃ）と、アプリケーション１４によって利用されるコンポーネントを定義したコンポーネント利用定義情報１７と、個々のアプリケーション１４に対応するコンポーネント利用定義情報１７を指定する情報２１（２１Ａ、２１Ｂ）を含むアプリケーション配置定義情報１９（アプリケーションＡ配置定義情報１９Ａ、アプリケーションＢ配置定義情報１９Ｂ）とを有するものである。

図２の例では、アプリケーションＡとアプリケーションＢが、３つのコンポーネントＣ１、コンポーネントＣ２、コンポーネントＣ３を使用するものとなっており、コンポーネント利用定義情報１７には、その３つのコンポーネントＣ１、Ｃ２、Ｃ３を各々指定する情報（コンポーネントＣ１指定情報１７Ａ、コンポーネントＣ２指定情報１７Ｂ、コンポーネントＣ３指定情報１７Ｃ）が記述されている。したがって、アプリケーションＡ配置定義情報１９Ａ、アプリケーションＢ配置定義情報１９Ｂの中の指定情報２１Ａ、２１Ｂは、それぞれ同一のコンポーネント利用定義情報１７を指定するものとなっている。もちろん、個々のアプリケーションＡ、Ｂが、異なるコンポーネントの組み合わせを使用する場合には、異なるコンポーネントの組み合わせを記述したコンポーネント利用定義情報１７を複数用意し、アプリケーションＡ配置定義情報１９Ａ、アプリケーションＢ配置定義情報１９Ｂの中のコンポーネント利用定義情報の指定情報２１Ａ、コンポーネント利用定義情報の指定情報２１Ｂにより、別々のコンポーネント利用定義情報１７を指定するようにすればよい。このコンポーネント環境定義情報１８はミドルウェア１２による読み込みを前提としているので、その場所や、記述の形式、定義内容はミドルウェア１２による制約の範囲で決められる。

図３は、アプリケーションＡとアプリケーションＢが、３つのコンポーネントＣ１、コンポーネントＣ２、コンポーネントＣ３を共通に使用する場合のコンポーネント環境定義情報１８のＸＭＬ（ｅＸｔｅｎｓｉｂｌｅ Ｍａｒｋ−ｕｐ Ｌａｎｇｕａｇｅ）による記述例である。

このように、個々のアプリケーション１４が利用するコンポーネント１５をコンポーネント環境定義情報１８によって一元管理することができる。これにより、コンポーネント環境定義情報１８の中のコンポーネント利用定義情報１７の内容を変更するだけで、アプリケーション１４とコンポーネント１５との関係を変更することができる。これにより、管理コストの低減、開発効率の向上を図れる。

それに関連して、従来の方法に倣って、個々のアプリケーション配置定義情報１９Ａ、１９Ｂに、アプリケーションＡ、Ｂが利用するコンポーネントを指定する情報２３Ａ、２３Ｂを記述した場合は図４のようになる。同図に示すように、各々のアプリケーション配置定義情報１９Ａ、１９Ｂに、自アプリケーションが利用するコンポーネントの同一情報２３Ａ、２３Ｂを別々に記述しなければならないため、アプリケーションが利用するコンポーネントに変更が生じた場合、各アプリケーション配置定義情報１９Ａ、１９Ｂそれぞれを別々に書き換えて再度変更しなければならない。

次に、このコンポーネント処理システム１００の動作手順を、図５を参照して説明する。

まず、クライアント１１０からの、アプリケーション利用のリクエストが、ミドルウェア１２、フレームワーク１３を通じて目的のアプリケーション１４に与えられる（１．リクエスト〜３．リクエスト）。利用のリクエストを受けたアプリケーション１４は、コンポーネント管理部２０に対してコンポーネント１５の要求を行う（４．コンポーネント要求）。コンポーネント管理部２０は、この要求を受けると、当該アプリケーション１４が利用するコンポーネント１５の配置場所をミドルウェア１２に要求する（５．コンポーネント要求）。

ミドルウェア１２は、コンポーネント管理部２０からの要求により、コンポーネント環境定義情報１８から当該アプリケーション１４が利用するコンポーネントの配置場所を読み込み（６．コンポーネントの配置場所取得）、目的のコンポーネントの情報、具体的にはそのコンポーネントを生成するためのインターフェース（たとえばＥＪＢのＨｏｍｅＩｎｔｅｒｆａｃｅ））をコンポーネント管理部２０に応答する（７．コンポーネント応答）。

コンポーネント環境定義情報１８からのコンポーネント配置場所の読み込みは次のようにして行われる。コンポーネント環境定義情報１８の中の、要求元であるアプリケーション１４に対応するアプリケーション配置定義情報１９の中の指定情報２１を読み込み、この指定情報２１に基づいてコンポーネント利用定義情報１７を読み込む。コンポーネント利用定義情報１７には、コンポーネントを指定するコンポーネントＣ１指定情報１７Ａ、コンポーネントＣ２指定情報１７Ｂ、コンポーネントＣ３指定情報１７Ｃが記述されているので、この記述に従って該当するコンポーネントのコンポーネント配置定義情報１６（１６Ａ、１６Ｂ、１６Ｃ）をそれぞれ読み込んでコンポーネントの配置場所を取得する。

コンポーネント管理部２０は、コンポーネントの応答を受けると、該当するコンポーネント１５に対して所定の動作条件を与えるとともに、実体の生成を要求する（８．実体生成要求）。コンポーネント１５は、渡された動作条件に基づいて自らを実体化し（９．実体生成）、この実体への参照情報（たとえばＥＪＢのＲｅｍｏｔｅＩｎｔｅｒｆａｃｅ）をコンポーネント管理部２０へ返す（１０．実体参照応答）。

なお、実体生成の要求の度にコンポーネントの実体を生成することはハードウェア資源の利用効率の低下を招くので、一度生成された実体への参照情報（たとえばＥＪＢのＲｅｍｏｔｅＩｎｔｅｒｆａｃｅ）をプールしておき、次回以降の実体生成の要求に対しては、このプールされた実体への参照情報をコンポーネント管理部２０へ返すようにしてもよい。これにより、ユーザからの指示により発生するリクエストの後に、コンポーネントを生成することがなくなり、コンポーネント管理部２０の負担が軽減することになる。

コンポーネント管理部２０は、コンポーネント１５から渡された実体への参照情報を、要求元のアプリケーション１４に返す（１１．実体参照応答）。この後、アプリケーション１４は、実体化されたコンポーネントを利用した処理の要求を行う（１２．コンポーネント利用）。この処理要求を受けたコンポーネント１５は、自らの実体に基づいて処理を実行し、その結果をアプリケーション１４に返却する（１３．処理結果応答）。アプリケーション１４は、受け取った処理結果を利用して、自らの実装に基づいた処理を行い、その結果をフレームワーク１３を通じてミドルウェア１２へ返却する（１４．処理結果応答）。そしてミドルウェア１２は、自らの実装に基づき処理結果をクライアント１１０に返却する（１５．処理結果応答）。

したがって、この実施形態のコンポーネント処理システム１００によれば、個々のアプリケーション１４が利用するコンポーネント１５をコンポーネント環境定義情報１８によって一元管理することができる。より具体的には、コンポーネント環境定義情報１８の中のコンポーネント利用定義情報１７の内容を変更するだけで、アプリケーション１４とコンポーネント１５との関係を煩雑なく変更することができる。これにより、管理コストの低減、開発効率の向上を図れる。

次に、本実施形態の変形例として、初期化時に、ミドルウェア１２で作成された、コンポーネントを生成するためのインターフェース（たとえばＥＪＢのＨｏｍｅＩｎｔｅｒｆａｃｅ）をコンポーネント管理部２０にてプールする場合の、コンポーネント処理システム２００の動作を図６を用いて説明する。

まず、ミドルウェア１２は、フレームワーク１３の初期化を行い（１．初期化）、フレームワーク１３は自らの初期化において、アプリケーション１４及びコンポーネント管理部２０の初期化を実行する（２．初期化、３．初期化）。

コンポーネント管理部２０は、初期化された後、コンポーネント要求をミドルウェア１２に対して行う（４．コンポーネント要求）。ミドルウェア１２は、コンポーネント要求に対して、コンポーネント環境定義情報１８からアプリケーション１４が利用するコンポーネントの配置場所を読み込み（５．コンポーネントの配置場所取得）、目的のコンポーネントの情報、具体的にはコンポーネントを生成するためのインターフェース（たとえばＥＪＢのＨｏｍｅＩｎｔｅｒｆａｃｅ）を生成してコンポーネント管理部２０に応答する（６．コンポーネント応答）。

コンポーネント管理部２０は、ミドルウェア１２から応答されたコンポーネントの情報（コンポーネントを生成するためのインターフェース）をプールする（７．コンポーネント応答プール）。この後、コンポーネント管理部２０から初期化完了をフレームワーク１３に通知する（８．初期化応答）。フレームワーク１３は、続いてミドルウェア１２に初期化完了を通知する（９．初期化応答）。

続いて、クライアント１１０からアプリケーション利用のリクエストが、ミドルウェア１２、フレームワーク１３を通じて目的のアプリケーション１４に与えられる（１０．リクエスト〜１２．リクエスト）。利用のリクエストを受けたアプリケーション１４は、コンポーネント管理部２０に対してコンポーネント１５の要求を行う（１３．コンポーネント要求）。コンポーネント管理部２０は、この要求を受けると、自身にプールしているコンポーネントの情報を取得し（１４．プールからコンポーネント応答取得）、このコンポーネントの情報に基づいて該当するコンポーネント１５に対して実体の生成を要求するとともに動作条件を渡す（１５．実体生成要求）。コンポーネント１５は、渡された動作条件に基づいて自らを実体化し（１６．実体生成）、この実体への参照情報（たとえばＥＪＢのＲｅｍｏｔｅＩｎｔｅｒｆａｃｅ）をコンポーネント管理部２０へ返す（１７．実体参照応答）。

コンポーネント管理部２０は、コンポーネント１５から渡された実体への参照情報を、要求元のアプリケーション１４に返す（１８．実体参照応答）。この後、アプリケーション１４は、実体化されたコンポーネントを利用した処理の要求を行う（１９．コンポーネント利用）。この処理要求を受けたコンポーネント１５は、自らの実体に基づいて処理を実行し、その結果をアプリケーション１４に返却する（２０．処理結果応答）。アプリケーション１４は、受け取った処理結果を利用して、自らの実装に基づいた処理を行い、その結果をフレームワーク１３を通じてミドルウェア１２へ返却する（２１．処理結果応答、２２．処理結果応答）。そしてミドルウェア１２は、自らの実装に基づき処理結果をクライアント１１０に返却する（２３．処理結果応答）。

このようにコンポーネント管理部２０にコンポーネントの情報をプールしておくことで、リクエストの度にコンポーネントの情報を生成することがなくなり、リクエストに対する応答が早くなる。

次に、本発明の他の実施形態を説明する。

図７は、本発明の第２の実施形態に係るコンポーネント処理システム２００の構成を示す図である。
同図に示すように、このコンポーネント処理システム２００は、図１に示した先の実施形態のコンポーネント処理システム１００に、フレームワーク１３に設けられたコンポーネント管理部２０によって直接読み込みが可能なコンポーネント振る舞い定義情報２２（コンポーネントＣ１振る舞い定義２２Ａ、コンポーネントＣ２振る舞い定義２２Ｂ、コンポーネントＣ振る舞い定義２２Ｃ）を付加して構成されたものである。

なお、この図の例では、コンポーネント振る舞い定義情報２２がコンポーネントの種類ごとに１つずつ設けられているが、１つのコンポーネントに複数のコンポーネント振る舞い定義情報２２を用意してもよい。

どのコンポーネント振る舞い定義情報２２を読み込むかは、アプリケーション配置定義情報１９の中で定義しておけばよい。たとえば、図２に示したアプリケーション配置定義情報１９の中やコンポーネント利用定義情報１７の中で定義したり、コンポーネント振る舞い定義情報２２を指定するための定義情報を別途用意してもよい。いずれの場合においても、コンポーネント振る舞い定義情報２２を指定する情報として、コンポーネント振る舞い定義情報２２の配置場所を記述しておくことで、コンポーネントの開発時や設計時において振る舞い定義情報を自由に変更することによりコンポーネントの振る舞いを高い自由度でカスタマイズすることができ、システム設計の自由度や他システムへの流用性を高めることができる。さらに、これまでのミドルウェアに依存するコンポーネント振る舞い定義情報の場所や、形式、定義内容に課せられていた制約が無くなり、コンポーネント型ソフトウェア開発の自由度、開発効率の向上を図ることができる。

次に、このコンポーネント処理システム２００の動作手順を、図８を参照して説明する。

まず、クライアント１１０からの、アプリケーション利用のリクエストが、ミドルウェア１２、フレームワーク１３を通じて目的のアプリケーション１４に与えられる（１．リクエスト〜３．リクエスト）。利用のリクエストを受けたアプリケーション１４は、コンポーネント管理部２０に対してコンポーネント１５の要求を行う（４．コンポーネント要求）。コンポーネント管理部２０は、この要求を受けると、当該アプリケーション１４が利用するコンポーネント１５の配置場所をミドルウェア１２に要求する（５．コンポーネント要求）。

ミドルウェア１２は、コンポーネント管理部２０からの要求により、コンポーネント環境定義情報１８から当該アプリケーション１４が利用するコンポーネント１５の配置場所を読み込み（６．コンポーネントの配置場所取得）、コンポーネントを生成するためのインターフェース（たとえばＥＪＢのＨｏｍｅＩｎｔｅｒｆａｃｅ）を生成してコンポーネント管理部２０に応答する。また、このとき、コンポーネント環境定義情報１８から、当該利用コンポーネントの振る舞いを定義するコンポーネント振る舞い定義情報２２の配置場所を読み込み、コンポーネントの配置場所とともにコンポーネント管理部２０に応答する（７．コンポーネント応答）

コンポーネント管理部２０は、この応答を受けると、該当するコンポーネント１５に対するコンポーネント振る舞い定義情報２２を読み込み（８．振る舞い定義情報取得）、このコンポーネント振る舞い定義情報２２の内容に基づく動作条件を当該コンポーネント１５に対して与えるとともに、実体の生成を要求する（９．実体生成要求）。コンポーネント１５は、渡された動作条件を加味しつつ自らを実体化し（１０．実体生成）、この実体への参照情報（たとえばＥＪＢのＲｅｍｏｔｅＩｎｔｅｒｆａｃｅ）をコンポーネント管理部２０へ返す（１１ ．実体参照応答）。

なお、実体生成の要求の度にコンポーネントの実体を生成することはハードウェア資源の利用効率の低下を招くので、一度生成された実体への参照情報をプールしておき、次回以降の実体生成の要求に対しては、このプールされた実体への参照情報をコンポーネント管理部２０へ返すようにしてもよい。

コンポーネント管理部２０は、コンポーネント１５から渡された実体への参照情報を、要求元のアプリケーション１４に返す（１２．実体参照応答）。この後、アプリケーション１４は、実体化されたコンポーネントを利用した処理の要求を行う（１３．コンポーネント利用）。この処理要求を受けたコンポーネント１５は、自らの実体に基づいて処理を実行し、その結果をアプリケーション１４に返却する（１４．処理結果応答）。アプリケーション１４は、受け取った処理結果を利用して、自らの実装に基づいた処理を行い、その結果をフレームワーク１３を通じてミドルウェア１２へ返却する（１５．処理結果応答）。そしてミドルウェア１２は、自らの実装に基づき処理結果をクライアント１１０に返却する（１６．処理結果応答）。

したがって、この実施形態のコンポーネント処理システム２００によれば、これまでのミドルウェア１２に依存していたコンポーネント動作条件定義情報の配置場所や、形式、定義内容に課せられていた制約が無くなり、コンポーネントの振る舞いを、高い自由度で変更することができ、システム設計の自由度を高めることができる。

図９は、コンピュータ３０のミドルウェア３１上で実体化されて実行されるコンポーネント３２を、他の複数のコンピュータ４０、５０上で動作される異なるアプリケーション４１、５１によって共用する形態を示している。ここで、それぞれのアプリケーション４１、５１側のコンポーネント振る舞い定義情報４２、５２に異なる内容を定義しておくことで、コンポーネント３２は、それぞれのアプリケーション４１、５１において異なった振る舞いをすることになる。

次に、本発明の第３の実施形態として、分散環境におけるコンポーネント処理システム３００について説明する。分散環境におけるコンポーネント処理システム３００とは、複数のコンピュータに分散して配置されたコンポーネントを処理する機構である。

図１０は、この分散環境におけるコンポーネント処理システム３００の例を示す図である。

同図に示すように、このコンポーネント処理システム３００は、コンポーネント利用のリクエストを処理する側のコンピュータ４００と、リクエストに対してコンポーネントを提供する側の１以上のコンピュータ５００、６００とで構成される。

コンポーネントを提供する一方のコンピュータ５００において、フレームワークＢ（５１３）には、ビジネスロジックを実装したコンポーネントＢ（５１５）を管理するためのコンポーネント管理部Ｂ（５２０）がコンポーネントとして実装されている。コンポーネント管理部Ｂ（５２０）は、自らによって直接読み込み可能なコンポーネントＢ振る舞い定義５２７に基づいてコンポーネントＢ（５１５）の振る舞いを定義する。ミドルウェアＢ（５１２）は、コンポーネント環境定義情報５１８からコンポーネントＢ（５１５）の配置場所を取得できるようになっている。

同様に、コンポーネントを提供する他方のコンピュータ６００において、フレームワークＢ（６１３）には、ビジネスロジックを実装したコンポーネントＣ（６１５）を管理するコンポーネント管理部Ｃ（６２０）がコンポーネントとして実装されている。コンポーネント管理部Ｃ（６２０）は、自らによって直接読み込み可能なコンポーネントＣ振る舞い定義情報６２７に基づいてコンポーネントＣ（６１５）の振る舞いを定義する。ミドルウェアＣ（６１２）は、コンポーネント環境定義情報６１８からコンポーネント管理部Ｃ（６２０）が利用するコンポーネントＣ２（６１５）の配置場所を取得できるようになっている。

一方、コンポーネントをリクエストする側のコンピュータ４００のフレームワークＡ（４１３）には、コンポーネントを提供する側のコンピュータ５００、６００にコンポーネントとして組み込まれたコンポーネント管理部Ｂ（５２０）、Ｃ（６２０）を管理するコンポーネント管理部Ａ（４２０）が実装されている。ミドルウェアＡ（４１２）によって直接読み込み可能なコンポーネント環境定義情報４１８には、コンポーネント管理部Ａ（４２０）の管理対象であるコンポーネント管理部の情報が記述されている。すなわち、この例では、コンポーネント管理部Ｂ（５２０）及びコンポーネント管理部Ｃ（６２０）がコンポーネント管理部Ａ（４２０）の管理対象であることが記述されている。

コンポーネント管理部Ｂアドレス定義情報４２７Ｂには、コンポーネント管理部Ａ（４２０）の管理対象であるコンポーネント管理部Ｂ（５２０）のアドレス情報が記述されている。コンポーネント管理部Ｃアドレス定義情報４２７Ｃには、コンポーネント管理部Ａ（４２０）の別の管理対象であるコンポーネント管理部Ｃ（６２０）のアドレス情報が記述されている。

次に、この分散環境におけるコンポーネント処理システム３００において、コンポーネントをリクエストする側のコンピュータ４００上のアプリケーション４１４から別のコンピュータ５００上のコンポーネントＢ（５１５）を利用する場合の動作を図１１を用いて説明する。

まず、ミドルウェアＡ（４１２）は、フレームワークＡ（４１３）の初期化を行い（１．初期化）、フレームワークＡ（４１３）は自らの初期化において、アプリケーション４１４及びコンポーネント管理部Ａ（４２０）の初期化を実行する（２．初期化、３．初期化）。

コンポーネント管理部Ａ（４２０）は、初期化された後、コンポーネント管理部Ｂアドレス定義情報４２７Ｂを読み込んで、コンポーネント管理部Ａ（４２０）の管理対象の一つであるコンポーネント管理部Ｂ（５２０）のアドレス情報を取得した後（４．コンポーネント管理部Ｂアドレス情報取得）、ミドルウェアＡ（４１２）に対してコンポーネント管理部Ｂ（５２０）の要求を行う（５．コンポーネント管理部Ｂ要求）。

この要求を受けたミドルウェアＡ（４１２）は、コンポーネント環境定義情報４１８から、コンポーネント管理部Ｂ（５２０）がコンポーネント管理部Ａ（４２０）の管理対象であることを判断し（６．コンポーネント管理部Ｂ定義取得）、コンピュータ５００上のミドルウェアＢ（５１２）に対してコンポーネント管理部Ｂ（５２０）の要求を行う（７．コンポーネント管理部Ｂ要求）。

コンピュータ５００上のミドルウェアＢ（５１２）は、この要求を受けると、コンポーネント管理部Ｂ（５２０）の配置場所を取得（８．コンポーネント管理部Ｂ配置場所取得）、このコンポーネント管理部Ｂのコンポーネントを生成するためのインターフェース（たとえばＥＪＢのＨｏｍｅＩｎｔｅｒｆａｃｅ）を生成して、コンピュータ４００上のミドルウェアＡ（４１２）に応答する（９．コンポーネント管理部Ｂ応答）。

コンピュータ４００上のミドルウェアＡ（４１２）は、この応答を受信するとコンポーネント管理部Ａ（４２０）に渡す（１０．コンポーネント管理部Ｂ応答）。コンポーネント管理部Ａ（４２０）は、受け取った応答に基づいて、コンポーネント管理部Ｂ（５２０）に対して実体の生成を要求する（１１．実体生成要求）。

コンポーネント管理部Ｂ（５２０）は、この要求に応じて自らを実体化し（１２．実体生成）、この実体への参照情報（たとえばＥＪＢのＲｅｍｏｔｅＩｎｔｅｒｆａｃｅ）をコンポーネント管理部Ａ（４２０）へ返す（１３．実体参照応答）。

この後、コンポーネント管理部Ａ（４２０）は、実体化されたコンポーネント管理部Ｂ（５２０）に対して初期化を指示する（１４．コンポーネント初期化指示）。コンポーネント管理部Ｂ（５２０）は、自らの初期化において、コンポーネントＢ（５１５）の要求をミドルウェアＢ（５１２）に対して行う（１５．コンポーネント要求）。

ミドルウェアＢ（５１２）は、このコンポーネント要求に応じて、コンポーネント環境定義情報５１８からコンポーネントＢ（５１５）の配置場所を取得し（１６．コンポーネント配置場所取得）、コンポーネントＢ（５１５）の情報、具体的には、コンポーネントＢ（５１５）を生成するためのインターフェース（たとえばＥＪＢのＨｏｍｅＩｎｔｅｒｆａｃｅ）をコンポーネント管理部Ｂ（５２０）に応答する（１７．コンポーネント応答）。

コンポーネント管理部Ｂ（５２０）は、応答されたコンポーネントＢ（５１５）の情報をプールし（１８．コンポーネント応答プール）、この後、初期化完了をコンポーネント管理部Ａ（４２０）に通知する（１９．初期化応答）。コンポーネント管理部Ａ（４２０）は、続いてミドルウェアＡ（４１２）に初期化完了を通知する（２０．初期化応答）。

続いて、クライアント１１０からアプリケーション利用のリクエストが、ミドルウェアミドルウェアＡ（４１２）、フレームワークＡ（４１３）を通じてアプリケーション４１４に与えられる（２１．リクエスト〜２３．リクエスト）。利用のリクエストを受けたアプリケーション４１４は、コンポーネント管理部Ａ（４２０）に対してコンポーネントＢ（５１５）の要求を行う（２４．コンポーネント要求）。

コンポーネント管理部Ａ（４２０）は、この要求を受けると、コンポーネント管理部Ｂ（５２０）に対してコンポーネントＢ（５１５）の要求を行う（２５．コンポーネント要求）。コンポーネント管理部Ｂ（５２０）は、自身にプールしているコンポーネントの情報を取得し（２６．プールからコンポーネント応答取得）、このコンポーネントの情報に基づいてコンポーネントＢ（５１５）に対して実体の生成を要求するとともに、コンポーネントＢ振る舞い定義情報５２７を読み込み、このコンポーネントＢ振る舞い定義情報５２７の内容に基づく動作条件を当該コンポーネント１５に対して与える（２７．実体生成要求）。

この要求に応じてコンポーネントＢ（５１５）は動作条件を加味しつつ自らを実体化し（２８．実体生成）、この実体への参照情報（たとえばＥＪＢのRemotoInteface）をコンポーネント管理部Ｂ（５２０）へ返す（２９．実体参照応答）。続いて、コンポーネント管理部Ｂ（５２０）からコンポーネント管理部Ａ（４２０）へ実体への参照情報が応答され（３０．実体参照応答）、さらに、コンポーネント管理部Ａ（４２０）からアプリケーション４１４に実体への参照情報が送られる（３１．実体参照応答）。

アプリケーション４１４は、実体化されたコンポーネントＢ（５１５）を利用した処理の要求を行う（３２．コンポーネント利用）。この処理要求を受けたコンポーネントＢ（５１５）は、自らの実体に基づいて処理を実行し、その結果をアプリケーション４１４に返却する（３３．処理結果応答）。アプリケーション４１４は、受け取った処理結果を利用して、自らの実装に基づいた処理を行い、その結果をフレームワークＡ（４１３）を通じてミドルウェアＡ（４１２）へ返却する（３４．処理結果応答、３５．処理結果応答）。そしてミドルウェアＡ（４１２）は、自らの実装に基づき処理結果をクライアント１１０に返却する（３６．処理結果応答）。

また、別のコンピュータ６００上のコンポーネントＣ（６１５）についても、同様の手順でアプリケーション４１４から利用できる。

このように、本実施形態のコンポーネント処理システム３００によれば、分散環境に配置された個々のコンポーネントＢ（５１５）、コンポーネントＣ（６１５）の振る舞いを定義する記述の配置場所や、形式、定義内容に課せられていた制約が無くなり、コンポーネントの振る舞いを、高い自由度で変更することができ、システム設計の自由度を高めることができる。

以上本発明の実施形態を説明したが、本発明は、上述の実施形態にのみ限定されるものではなく、本発明の要旨を逸脱しない範囲内において種々変更を加え得ることは勿論である。

本発明の第１の実施形態に係るコンポーネント処理システムの構成を示す図である。 コンポーネント環境定義情報の構成を示す図である。 コンポーネント環境定義情報の例を示す図である。 従来のアプリケーション配置定義情報の例を示す図である。 図１のコンポーネント処理システムの動作手順を示す図である。 第１の実施形態に係るコンポーネント処理システムの他の動作手順を示す図である。 本発明の第２の実施形態に係るコンポーネント処理システムの構成を示す図である。 図７のコンポーネント処理システムの動作手順を示す図である。 第２の実施形態に係るコンポーネント処理システムの変形例を示す図である。 本発明の第３の実施形態に係る分散環境でのコンポーネント処理システムの構成を示す図である。 図１０の分散環境でのコンポーネント処理システムの動作手順を示す図である。 一般的なコンポーネント処理システムの構成を示す図である。

符号の説明

１…ＣＰＵ、２…メモリ、３…外部記憶装置、４…バス、５…ネットワーク、６…ネットワーク接続装置、１０…コンピュータ、１１…オペレーティング・システム、１２…ミドルウェア、１２ａ…コンポーネント環境定義情報読込部、１３…フレームワーク、１４（１４Ａ，１４Ｂ）…アプリケーション、１５（１５Ａ，１５Ｂ，１５Ｃ）…コンポーネント、１６…コンポーネント配置定義情報、１６Ａ…コンポーネントＣ１配置定義情報、１６Ｂ…コンポーネントＣ２配置定義情報、１６Ｃ…コンポーネントＣ３配置定義情報、１７…コンポーネント利用定義情報、１７Ａ…コンポーネントＣ１指定情報、１７Ｂ…コンポーネントＣ２指定情報、１７Ｃ…コンポーネントＣ３指定情報、１８…コンポーネント環境定義情報、１９…アプリケーション配置定義情報、１９Ａ…アプリケーションＡ配置定義情報、１９Ｂ…アプリケーションＢ配置定義情報、２０…コンポーネント管理部、２１（２１Ａ，２１Ｂ）…コンポーネント利用定義情報の指定情報、２２…コンポーネント振る舞い定義情報、２２Ａ…コンポーネントＣ１振る舞い定義、２２Ｂ…コンポーネントＣ２振る舞い定義、２２Ｃ…コンポーネントＣ振る舞い定義、３０，４０，５０…コンピュータ、３１…ミドルウェア、３２…コンポーネントＡ、４１…アプリケーションＡ、４２，５２…コンポーネント振る舞い定義情報、５１…アプリケーションＢ、１００，２００，３００…コンポーネント処理システム、１１０…クライアント、４００，５００，６００…コンピュータ、４１２…ミドルウェアＡ、４１３…フレームワークＡ、４１４…アプリケーション、４１８…コンポーネント環境定義情報、４２０…コンポーネント管理部Ａ、４２７Ｂ…コンポーネント管理部Ｂアドレス定義情報、４２７Ｃ…コンポーネント管理部Ｃアドレス定義情報、５１２…ミドルウェアＢ、５１３…フレームワークＢ、５１５…コンポーネントＢ、５１８…コンポーネント環境定義情報、５２０…コンポーネント管理部Ｂ、５２７…コンポーネントＢ振る舞い定義情報、６１２…ミドルウェアＣ、６１３…フレームワークＣ、６１５…コンポーネントＣ、６１８…コンポーネント環境定義情報、６２０…コンポーネント管理部Ｃ、６２７…コンポーネントＣ振る舞い定義情報。

Claims (5)

1. オペレーティング・システム上で動作するミドルウェアと、
   前記ミドルウェア上で動作するフレームワークと、
   前記フレームワーク上で動作する少なくとも一つのアプリケーションと、
   前記アプリケーションによって選択的に利用可能な複数のコンポーネントと、
   個々の前記コンポーネントの配置場所が定義されたコンポーネント配置定義情報、前記利用されるコンポーネントが定義されたコンポーネント利用定義情報、及び前記アプリケーションに対応する前記コンポーネント利用定義情報を指定する情報を含むアプリケーション配置定義情報を有するコンポーネント環境定義情報と、
   前記フレームワークに設けられ、前記アプリケーションからの要求により、当該アプリケーションにより利用されるコンポーネントの配置場所の取得を前記ミドルウェアに要求し、その応答として取得した配置場所にあるコンポーネントに対して実体化を要求するコンポーネント管理部と、
   前記ミドルウェアに設けられ、前記コンポーネント管理部からの要求を受け、前記コンポーネント環境定義情報から、前記アプリケーションにより利用されるコンポーネントの配置場所を取得して前記コンポーネント管理部に応答するコンポーネント環境定義情報読込部とを有することを特徴とするコンポーネント処理システム。
2. オペレーティング・システム上で動作するミドルウェアと、
   前記ミドルウェア上で動作するフレームワークと、
   前記フレームワーク上で動作する少なくとも一つのアプリケーションと、
   前記アプリケーションによって選択的に利用可能な複数のコンポーネントと、
   個々の前記コンポーネントの振る舞いがそれぞれ定義された複数の振る舞い定義情報と、
   個々の前記コンポーネントの配置場所が定義されたコンポーネント配置定義情報、利用されるコンポーネントが定義されたコンポーネント利用定義情報、及び前記アプリケーションに対応する前記コンポーネント利用定義情報を指定する情報を含むアプリケーション配置定義情報を有するコンポーネント環境定義情報と、
   前記フレームワークに設けられ、前記アプリケーションからの要求により、当該アプリケーションにより利用されるコンポーネントの配置場所の取得を前記ミドルウェアに要求し、その応答として取得した配置場所にあるコンポーネントに対して前記振る舞い定義情報に基づく動作条件を与えて実体化を要求するコンポーネント管理部と、
   前記ミドルウェアに設けられ、前記コンポーネント管理部からの要求を受け、前記コンポーネント環境定義情報から、前記アプリケーションにより利用されるコンポーネントの配置場所を取得して前記コンポーネント管理部に応答するコンポーネント環境定義情報読込部とを有することを特徴とするコンポーネント処理システム。
3. オペレーティングシステム上で動作するミドルウェアと、前記ミドルウェア上で動作するフレームワークと、前記フレームワーク上で動作する少なくとも一つのアプリケーションと、前記アプリケーションによって選択的に利用可能な複数のコンポーネントと、個々の前記コンポーネントの配置場所が定義されたコンポーネント配置定義情報、利用されるコンポーネントが定義されたコンポーネント利用定義情報、及び前記アプリケーションに対応する前記コンポーネント利用定義情報を指定する情報を含むアプリケーション配置定義情報を有するコンポーネント環境定義情報とが配置されたコンピュータシステムにおけるコンポーネント処理方法であって、
   前記アプリケーションからの要求により、前記アプリケーションにより利用されるコンポーネントの配置場所の取得を前記ミドルウェアに要求するステップと、
   前記コンポーネント環境定義情報から前記アプリケーションにより利用されるコンポーネントの配置場所を取得するステップと、
   前記取得されたコンポーネントの配置場所を前記フレームワークに応答するステップと、
   前記配置場所にある前記コンポーネントに対して、所定の動作条件を与えて前記コンポーネントの実体化を要求するステップと、
   前記実体化されたコンポーネントの実体への参照情報を前記アプリケーションに応答するステップとを具備することを特徴とするコンポーネント処理方法。
4. オペレーティングシステム上で動作するミドルウェアと、前記ミドルウェア上で動作するフレームワークと、前記フレームワーク上で動作する少なくとも一つのアプリケーションと、前記アプリケーションによって選択的に利用可能な複数のコンポーネントと、個々の前記コンポーネントの振舞いがそれぞれ定義された複数の振舞い定義情報と、個々の前記コンポーネントの配置場所が定義されたコンポーネント配置定義情報、前記利用されるコンポーネントが定義されたコンポーネント利用定義情報、及び前記アプリケーションに対応する前記コンポーネント利用定義情報を指定する情報を含むアプリケーション配置定義情報を有するコンポーネント環境定義情報とが配置されたコンピュータシステムにおけるコンポーネント処理方法であって、
   前記アプリケーションからの要求により、前記アプリケーションにより利用されるコンポーネントの配置場所の取得を前記ミドルウェアに要求するステップと、
   前記コンポーネント環境定義情報から前記アプリケーションにより利用されるコンポーネントの配置場所を取得するステップと、
   前記取得されたコンポーネントの配置場所を前記フレームワークに応答するステップと、
   前記配置場所にある前記コンポーネントに対し、前記振舞い定義情報に基づいて前記コンポーネントの実体化を要求するステップと、
   前記実体化されたコンポーネントの実体への参照情報を前記アプリケーションに応答するステップとを具備することを特徴とするコンポーネント処理方法。
5. 前記応答されたコンポーネントの情報を前記フレームワークにプールするステップとをさらに具備し、
   前記コンポーネントの実体化を要求するステップは、前記コンポーネントの実体化の要求を受けた場合、前記フレームワークにプールされたコンポーネントの情報を参照することにより、前記コンポーネントの実体化を要求することを特徴とする請求項３又は４に記載のコンポーネント処理方法。

Images