JP2004252774A - コンポーネント生成実行機構およびプログラム - Google Patents
コンポーネント生成実行機構およびプログラム Download PDFInfo
- Publication number
- JP2004252774A JP2004252774A JP2003043304A JP2003043304A JP2004252774A JP 2004252774 A JP2004252774 A JP 2004252774A JP 2003043304 A JP2003043304 A JP 2003043304A JP 2003043304 A JP2003043304 A JP 2003043304A JP 2004252774 A JP2004252774 A JP 2004252774A
- Authority
- JP
- Japan
- Prior art keywords
- component
- application
- environment
- middleware
- generation
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Images
Landscapes
- Stored Programmes (AREA)
Abstract
【課題】コンポーネントの実体の構造に課せられる制約の軽減、コンポーネント動作条件定義記述の場所、記述形式、定義内容の制約を軽減する。
【解決手段】コンポーネント動作条件定義記述１７Ａ，１７Ｂの読み込みや実体生成の際のコンポーネント１３Ａ，１３Ｂへの提供をミドルウェア１２に代わって行うコンポーネント生成管理部１８を設ける。これによりミドルウェア１２に依存するコンポーネント動作条件定義記述の場所や、形式、定義内容に課せられていた制約が無くなる。また、従来のＥＪＢでは、コンポーネントはミドルウェア用の固有のインタフェースを持っていたが、コンポーネントのインタフェースをコンポーネントＩ／Ｆ適用部１９Ａ，１９Ｂによって高い自由度で提供可能にしたことでコンポーネントの採り得る構造にミドルウェアによる制約が課せられなくなり、汎用性の高いコンポーネント構造にできる。
【選択図】 図１
【解決手段】コンポーネント動作条件定義記述１７Ａ，１７Ｂの読み込みや実体生成の際のコンポーネント１３Ａ，１３Ｂへの提供をミドルウェア１２に代わって行うコンポーネント生成管理部１８を設ける。これによりミドルウェア１２に依存するコンポーネント動作条件定義記述の場所や、形式、定義内容に課せられていた制約が無くなる。また、従来のＥＪＢでは、コンポーネントはミドルウェア用の固有のインタフェースを持っていたが、コンポーネントのインタフェースをコンポーネントＩ／Ｆ適用部１９Ａ，１９Ｂによって高い自由度で提供可能にしたことでコンポーネントの採り得る構造にミドルウェアによる制約が課せられなくなり、汎用性の高いコンポーネント構造にできる。
【選択図】 図１
Description
【０００１】
【発明の属する技術分野】
本発明は、ミドルウェア上でコンポーネントを利用したアプリケーションを動作させるためのコンポーネント生成実行機構およびプログラムに関する。
【０００２】
【従来の技術】
コンポーネントとは、アプリケーションを構築するためのビジネスロジックなどを実装したソフトウェア部品である。例として、米国Ｓｕｎ Ｍｉｃｒｏｓｙｓｔｅｍｓ社が提唱している規約であるＥＪＢ（Ｅｎｔｅｒｐｒｉｓｅ Ｊａｖａ（登録商標） Ｂｅａｎｓ）などがある。ＥＪＢは、Ｊａｖａプログラム言語で分散オブジェクト指向の業務アプリケーションを構築するための標準コンポーネントアーキテクチャであり、異なるベンダのツールを使用し開発したコンポーネントを組み合わせることで分散アプリケーションの構築を可能とするものである。ＥＪＢを利用することによって、開発者は、アプリケーション開発時にビジネスロジックの開発だけに専念でき、効率的なアプリケーション開発が可能になる。
【０００３】
ＥＪＢアーキテクチャにおいては、ＥＪＢコンポーネントの実行環境をコンテナが提供するようになっている。通常、このコンテナはＥＪＢサーバによって管理される。ＥＪＢクライアント（アプリケーション）が、コンテナが提供する標準化されたインターフェイスを介してコンテナにＥＪＢのオブジェクト生成を要求すると、コンテナは、Ｄｅｐｌｏｙｍｅｎｔ Ｄｅｓｃｒｉｐｔｅｒと呼ばれる、コンポーネントの動作条件（トランザクション管理、セキュリティ管理などの属性値）を定義する記述を読み込み、これに基づいてコンポーネントの組み込み、インスタンス生成を行う。これにより実行可能なコンポーネントが生成される（たとえば、特許公報１参照）。
【０００４】
【特許文献１】
特開２００２−４９４９６号公報
【０００５】
さらに、ＥＪＢクライアントがコンテナが提供する標準化されたインターフェイスを介してコンポーネントのビジネスメソッドを呼び出すと、コンテナによってコンポーネントの実体に実装されたビジネスメソッドが呼び出されて、アプリケーションの機能として実行される。
【０００６】
以上のように、ＥＪＢアーキテクチャにおいて、ＥＪＢコンポーネントを動作させるにはその実行環境を提供するＥＪＢコンテナ、さらにこのＥＪＢコンテナを管理するＥＪＢサーバが不可欠である。これはＥＪＢコンポーネントの実体の構造がＥＪＢ固有のものであり、他の動作環境でＥＪＢコンポーネントを動作させることはできないことを意味する。
【０００７】
また、ＥＪＢアーキテクチャでは、前述したように、コンテナがコンポーネントの動作条件定義記述を読み込むことによって実行可能なコンポーネントを生成しているが、動作条件の定義記述の置き場所はコンテナベンダーによって決められ、コンテナにその場所情報にアクセスする機能が実装されている。また、動作条件の定義記述の形式もコンテナに依存している。すなわち、ＥＪＢアーキテクチャでは、定義記述の場所、その記述形式、定義内容について多くの制約が課せられており、このことがシステムの設計の自由度を損ね、開発効率の向上を阻んでいた。
【０００８】
たとえば、Ｄｅｐｌｏｙｍｅｎｔ Ｄｅｓｃｒｉｐｔｅｒでは、コンポーネントの拡張実装などの定義は範疇外とされ、単一階層のキーと値の定義のみに制限され、ツリー構造を持つような複雑な設定情報を記述することはできない。このコンポーネントの拡張実装を実現するには、その拡張のための情報をアプリケーションもしくはコンポーネントの内部にハードコーディング、すなわち特定の動作環境で動作させることを前提とした処理やデータをソースコードの中に書き込んでプログラミングしなければならなかった。
【０００９】
また、アプリケーションとコンポーネントとの間の相互作用をフレームワークで管理する方式は既に存在する（たとえば、特許公報２参照）。フレームワークとは、一般的には、多くの業務（アプリケーション）の共通部分のみを実装した雛形を指し、変更可能な部分についてはコンポーネント（ビジネスロジック）を組み込む（プラグインする）ことによって、個々の要求を満たすアプリケーションを少ない労力で開発することを可能とするものである。この特許公報の発明において、フレームワークは、アプリケーションからサービスの実装の要求、その実装に課せられる制約などを受けて、そのサービス（コンポーネント）の実装を動的に構築するものとして用いられている。
【００１０】
【特許文献２】
特開２００１−２１６１６２号公報
【００１１】
【発明が解決しようとする課題】
本発明が解決しようとする課題としては、前述したように、ＥＪＢアーキテクチャにおけるコンポーネントの実体の構造に課せられた制約と、コンポーネント動作条件の定義記述の場所、記述形式、定義内容に課せられた制約がある。ＥＪＢコンポーネントの実体の構造に課せられた制約は、コンポーネントの実装を特定ミドルウェアに依存しない汎用的なものとすることを妨げ、コンポーネント動作条件の定義記述に関する制約は、コンポーネント型ソフトウェア開発の自由度を損ね、開発効率の向上を阻む一要因となっていた。
【００１２】
本発明はこのような課題を解決するためになされたもので、コンポーネントの実体の構造に課せられる制約を軽減できるコンポーネント生成実行機構およびプログラムの提供を目的とする。
また、本発明は、コンポーネント動作条件定義記述の場所、記述形式、定義内容の制約を軽減できるコンポーネント生成実行機構およびプログラムの提供を目的とする。
【００１３】
【課題を解決するための手段】
かかる目的を達成するために、本発明のコンポーネント生成実行機構は、オペレーティング・システム上で動作するミドルウェアと、前記ミドルウェア上で動作するアプリケーションと、前記アプリケーションによって利用されるコンポーネントと、前記コンポーネントが実体化して動作するのに必要な動作条件を記述したコンポーネント動作条件定義記述と、少なくとも前記コンポーネント動作条件定義記述が存在する任意の場所を含む前記コンポーネントの動作環境が記述され、前記ミドルウェアに読み込み処理が依存するコンポーネント環境定義記述と、前記コンポーネント環境定義記述の読み込みを前記ミドルウェアに依頼し、当該ミドルウェアによって読み込まれた前記コンポーネント環境定義記述に基づいて前記コンポーネントの動作環境を設定、管理するコンポーネント環境管理部と、前記コンポーネントのインタフェースを提供するコンポーネントＩ／Ｆ適用部と、前記コンポーネント環境管理部によって設定された前記動作環境に基づいて前記コンポーネント動作条件定義記述を読み込み、前記コンポーネントＩ／Ｆ適用部を通じて前記コンポーネントに動作条件を与えるとともに実体の生成を要求するコンポーネント生成管理部とを具備する。
【００１４】
この発明によれば、コンポーネント動作条件定義記述の読み込みや実体生成の際のコンポーネントへの提供を、ミドルウェアに代わってコンポーネント生成管理部が行うことで、これまでのミドルウェアに依存するコンポーネント動作条件定義記述の場所や、形式、定義内容に課せられていた制約が無くなり、コンポーネント型ソフトウェア開発の自由度、開発効率の向上を図ることができる。
【００１５】
また、コンポーネントのインタフェースをコンポーネントＩ／Ｆ適用部によって高い自由度で提供できるので、コンポーネントの採り得る構造にミドルウェアによる制約が課せられることがなくなり、汎用性の高いコンポーネント構造とすることが可能になる。
【００１６】
また、本発明において、アプリケーションへの処理要求の発生時、アプリケーションは、コンポーネントＩ／Ｆ適用部にコンポーネントの生成要求を行い、この要求によりコンポーネントＩ／Ｆ適用部はコンポーネント環境管理部に環境情報の取得を要求し、コンポーネント環境管理部はこの要求に応じて環境情報をコンポーネントＩ／Ｆ適用部を介してコンポーネント生成管理部に渡すようにしてもよい。
【００１７】
さらに、本発明において、コンポーネントは取得した動作条件に基づいて自らを実体化し、この実体への参照をコンポーネントＩ／Ｆ適用部を通じてアプリケーションに返し、アプリケーションは実体への参照を取得するとコンポーネントＩ／Ｆ適用部を介してコンポーネントに処理要求を行い、この処理要求によりコンポーネントは自らの実体に基づいて処理を実行し、その結果をコンポーネントＩ／Ｆ適用部を介してアプリケーションに返し、アプリケーションは当該処理結果を利用して自らの実装に基づいた処理を行い、その結果をミドルウェアを介して前記ユーザに返すようにしてもよい。
【００１８】
さらに、本発明は、ミドルウェア上で動作するフレームワークを有し、このフレームワークにコンポーネント環境管理部およびコンポーネント生成管理部の機能がプラグインされた構成とすることも可能である。
【００１９】
【発明の実施の形態】
以下、図面を参照して本発明の実施の形態について説明する。
図１に、本発明のコンポーネント生成実行機構を実施した一形態である情報システム１００の構成を示す図である。
【００２０】
同図に示すように、この情報システム１００は、ＣＰＵ１、メモリ２、外部記憶装置３、バス４などの一般的なコンピュータアーキテクチャを有するサーバコンピュータ１０に構築されている。このサーバコンピュータ１０はインターネットやＬＡＮなどのネットワーク５にネットワーク接続装置６を通じて接続されている。
【００２１】
この情報システム１００のソフトウェア要素としては、オペレーティング・システム１１（以下、ＯＳと呼ぶ。）と、ミドルウェア１２と、アプリケーション１４が利用するロジックを実装した１つ以上のコンポーネント１３Ａ，１３Ｂと、各コンポーネント１３Ａ，１３Ｂを利用するアプリケーション１４と、コンポーネント環境定義記述１５と、コンポーネント環境定義記述１５に基づいて個々のコンポーネント１３Ａ，１３Ｂの動作条件を記述したコンポーネント動作条件定義記述１７Ａ，１７Ｂの場所を管理するコンポーネント環境管理部１６と、コンポーネント動作条件定義記述１７Ａ，１７Ｂに基づいてコンポーネント１３Ａ，１３Ｂの実体生成を行うコンポーネント生成管理部１８と、コンポーネント１３Ａ，１３Ｂごとのインタフェースを提供するコンポーネントＩ／Ｆ適用部１９Ａ，１９Ｂとを備えている。ここでコンポーネントの数は２としたが、その数に特に限定や制限はない。
【００２２】
ミドルウェア１２はＯＳ１１上で動作する。ミドルウェア１２はアプリケーション・サーバと同義であり、トランザクション処理、負荷分散処理、データベース処理、そしてコンポーネント環境管理部１６からの要求によりミドルウェア１２に依存して決められた場所からコンポーネント環境定義記述１５を読み込んでコンポーネント環境管理部１６にその内容（環境情報）を返す処理などを行う。
【００２３】
コンポーネントＩ／Ｆ適用部１９Ａ，１９Ｂは個々のコンポーネント１３Ａ，１３Ｂごとに用意され、それぞれアプリケーション１４からの実体生成や利用の要求を受けて、自身に対応するコンポーネント１３Ａ，１３Ｂにその処理を委譲する。また、コンポーネントＩ／Ｆ適用部１９Ａ，１９Ｂは実体生成をコンポーネントに委譲する時、コンポーネント生成管理部１８によって読み込まれたコンポーネント動作条件定義記述１７Ａ，１７Ｂに基づく動作条件を対応するコンポーネント１３Ａ，１３Ｂに引き渡し、対応するコンポーネント１３Ａ，１３Ｂから渡された実体への参照をアプリケーション１４に返す。
【００２４】
コンポーネント環境定義記述１５は、コンポーネント動作条件定義記述１７Ａ，１７Ｂの場所などをコンポーネント環境管理部１６に公開する定義文であり、たとえばＸＭＬ（Ｅｘｔｅｎｓｉｂｌｅ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）などの言語で記述される。図２に、ＸＭＬによるコンポーネント環境定義記述１５の記述例を示す。２０１はコンポーネントを定義する記述の行、２０２はコンポーネント動作条件定義記述１７Ａ，１７ＢのＸＭＬファイルの場所の記述行である。
【００２５】
コンポーネント動作条件定義記述１７Ａ，１７Ｂは、コンポーネント１３Ａ，１３Ｂを実体化する際のカスタマイズ方法などの動作条件がＸＭＬなどの言語により記述された情報である。図３に、ＸＭＬによるコンポーネント動作条件定義記述の例を示す。ＸＭＬのスキーマはコンポーネント独自のものを利用することができる。このＸＭＬの文書はファイル、あるいはデータベースのレコードとして存在することができる。
【００２６】
この例はメールの送受信を行うコンポーネントのコンポーネント動作条件定義記述の例である。メールコンポーネントの実体はこのコンポーネント動作条件定義記述により指定することができる。メールコンポーネントの実体には、たとえばＪａｖａＭａｉｌと呼ばれる汎用のメールライブラリィやコンポーネントの開発者が独自に作成した実装クラスなどを指定することが可能である。
【００２７】
符号３０１で示す＜ｓｍｔｐ−ｉｎｆｏ＞タグと＜／ｓｍｔｐ−ｉｎｆｏ＞タグとの間はメール送信のための動作条件定義記述の記述、符号３０２で示す＜ｐｏｐ−ｉｎｆｏ＞タグと＜／ｐｏｐ−ｉｎｆｏ＞タグとの間はメール受信のための動作条件定義記述の記述、符号３０３で示す＜ｓｅｎｄｅｒ−ｈａｎｄｌｅｒ＞タグと＜／ｓｅｎｄｅｒ−ｈａｎｄｌｅｒ＞タグとの間はメールを送信する時に実際に用いるクラスの設定、符号３０４で示す＜ｇｅｔｔｅｒ−ｈａｎｄｌｅｒ＞タグと＜／ｇｅｔｔｅｒ−ｈａｎｄｌｅｒ＞タグとの間はメールを受信する時に実際に用いるクラスの設定、符号３０５で示す＜ｓｕｂｊｅｃｔ−ｈａｎｄｌｅｒ＞タグと＜／ｓｕｂｊｅｃｔ−ｈａｎｄｌｅｒ＞タグとの間はメール受信のサブジェクトを条件にして起動するプログラムの設定である。
【００２８】
コンポーネント動作条件定義記述１７Ａ，１７Ｂの場所はミドルウェア１２に依存しない任意の場所とすることができる。一方、コンポーネント環境定義記述１５はミドルウェア１２による読み込みを前提としているので、その場所や、記述の形式、定義内容はミドルウェア１２による制約の範囲で決められる。
【００２９】
次に、このコンポーネント生成実行機構の動作手順を説明する。
【００３０】
１．コンポーネントの実行環境の初期化
図４に示すように、アプリケーション管理者１０１によって初期化の操作が行われる。これは通常、ミドルウェア１２の初期化によって行われる（１．初期化）。ミドルウェア１２は登録されているアプケリーション１４の初期化とコンポーネント環境管理部１６の初期化を行う（２．初期化）。コンポーネント環境管理部１６は、ミドルウェア１２を通じて、ミドルウェア１２に依存した形式で記述されているコンポーネント環境定義記述１５を読み込み（３．読み込み）、その内容に基づく環境情報を設定たとえばメモリ２に格納する（５．コンポーネント環境設定）。
【００３１】
２．コンポーネントの生成
図５に示すように、ユーザ１０２はアプリケーション１４に対する処理要求を行う（１．処理要求）。ミドルウェア１２は処理要求を解釈してアプリケーション１４に対して処理要求を行う（２．処理要求）。アプリケーション１４がコンポーネントＡ（１３Ａ）を利用するように作成されていた場合、処理要求を受けたアプリケーション１４は、コンポーネントＡ（１３Ａ）がアプリケーション１４に公開しているインタフェースであるコンポーネントＩ／Ｆ適用部１９Ａに対して生成要求を行う（３．生成要求）。コンポーネントＩ／Ｆ適用部１９Ａは、アプリケーション１４からの生成要求を受けるとコンポーネント環境管理部１６に対して環境情報の取得を要求する（４．環境情報取得）。コンポーネント環境管理部１６は、この要求に応じて上記の初期化でメモリ２に格納しておいた環境情報をコンポーネントＩ／Ｆ適用部１９Ａに返す（５．返却）。
【００３２】
コンポーネントＩ／Ｆ適用部１９Ａは環境情報を受け取ると、コンポーネント生成管理部１８に対して環境情報を引き渡すとともにコンポーネントＡ（１３Ａ）の生成要求を行う（６．生成要求）。コンポーネント生成管理部１８は、渡された環境情報に基づきコンポーネントＡ（１３Ａ）が実体化して動作するのに必要な動作条件を記述したコンポーネント動作条件定義記述１７Ａを読み込み（７．読み込み）、コンポーネントＩ／Ｆ適用部１９Ａに返す（８．返却）。
【００３３】
コンポーネントＩ／Ｆ適用部１９Ａは、渡されたコンポーネント動作条件定義記述１７Ａに基づいて、汎用的な構造を持つコンポーネントＡ（１３）に対して動作条件を与えるとともに実体の生成を要求する（９．実体生成）。コンポーネントＡ（１３）は、渡された動作条件に基づいて自らを実体化し、この実体への参照をコンポーネントＩ／Ｆ適用部１９Ａへ返す（１０．返却）。
【００３４】
なお、実体生成の要求の度にコンポーネントの実体を生成することはハードウェア資源の利用効率の低下を招くので、一度生成された実体をプールしておき、次回以降の実体生成の要求に対しては、このプールされた実体への参照をコンポーネントＩ／Ｆ適用部１９Ａへ返すようにしてもよい。
【００３５】
コンポーネントＩ／Ｆ適用部１９Ａは、コンポーネントＡ（１３Ａ）から渡された実体への参照をアプリケーション１４に返す（１１．返却）。このときコンポーネントＡの実体はコンポーネントＩ／Ｆ適用部１９Ａに隠蔽されており、アプリケーション１４が直接そのコンポーネントＡの実体についての情報を保持する必要はない。
【００３６】
３．コンポーネントの利用
アプリケーション１４は、コンポーネントＩ／Ｆ適用部１９Ａに対して処理の要求を行う（１２．処理要求）。コンポーネントＩ／Ｆ適用部１９Ａはアプリケーション１４からの処理要求をコンポーネントＡ（１３Ａ）に委譲する（１３．処理要求）。処理要求を委譲されたコンポーネントＡ（１３Ａ）は、自らの実体に基づいて処理を実行し、その結果をコンポーネントＩ／Ｆ適用部１９Ａに返却する（１４．返却）。さらに、コンポーネントＩ／Ｆ適用部１９ＡはコンポーネントＡ（１３Ａ）からの処理結果をアプリケーション１４に返却する（１５．返却）。アプリケーション１４は、受け取った処理結果を利用して、自らの実装に基づいた処理を行い、その結果をミドルウェア１２へ返却する（１６．返却）。そしてミドルウェア１２は、自らの実装に基づき処理結果をユーザに返却する（１７．返却）。
【００３７】
図６は、この実施形態で採用される汎用的なコンポーネントたとえばコンポーネントＡの本体の構造例を示すクラス図である。
【００３８】
コンポーネント生成共通インタフェース２１は、コンポーネントの実体を生成する機能をもつクラスを作成する際に必要な共通部分を抜き出したクラスである。また、コンポーネント生成共通インタフェース２１はコンポーネントの実体を生成するための操作方法をユーザに統一的に提供する。コンポーネントＡ生成クラス２２はコンポーネントＡの実体を生成する機能を持つ、コンポーネント生成共通インタフェース２１のサブクラスであり、コンポーネント生成共通インタフェース２１の差分として定義される。
【００３９】
コンポーネント共通インタフェース２３は、コンポーネントが共通に持つべき機能たとえば設定ファイルの定義内容のキャッシュなどの機能を抜き出したクラスである。また、コンポーネント共通インタフェース２３はコンポーネント実体生成のための操作をコンポーネントＡ生成クラス２２に対して統一的に提供する。コンポーネントＡ実装クラス２４はコンポーネントＡの機能が実装された、コンポーネント共通インタフェース２３のサブクラスである。
【００４０】
動作条件定義記述解釈インタフェース２５は設定ファイルを読み込む際の共通の機能を抜き出したクラスである。コンポーネントＡ動作条件定義記述解釈クラス２６は、個々のコンポーネント毎に異なる設定ファイルの書式を解釈して、コンポーネントの実装クラスに設定可能な形態に変換する、動作条件定義記述解釈インタフェース２５のサブクラスである。
【００４１】
図７は、上記の汎用的なコンポーネントＡをコンポーネントＩ／Ｆ適用部１９ＡによってＥＪＢに適合させた場合の、コンポーネントＩ／Ｆ適用部１９Ａの構成の例を示すクラス図である。
【００４２】
ＥＪＢはその仕様により、ひとつのコンポーネントを作成する場合に２つのインタフェース（Ｈｏｍｅインタフェース、Ｒｅｍｏｔｅインタフェース）と１つのクラス（ＥＪＢ実装クラス）を作成することを義務づけている。ＥＪＢ実装クラスインタフェースはそのうちのＥＪＢ実装クラスを作成するときに利用するインタフェースである。
【００４３】
ＥＪＢＨｏｍｅインタフェース３１とＥＪＢＲｅｍｏｔｅインタフェース３３はＥＪＢの仕様として予め提供されるものである。ＥＪＢＨｏｍｅインタフェース３１は、ＥＪＢコンポーネントを生成する操作を利用側アプリケーション（ＥＪＢクライアントと呼ばれる。）に提供するためのインタフェースが共通に持つ操作を定義した上位インタフェースである。コンポーネントＡＨｏｍｅインタフェース３２は、コンポーネントＡを生成する操作を利用側アプリケーションに提供する機能をもつ、ＥＪＢＨｏｍｅインタフェース３１のサブインタフェースである。
【００４４】
ＥＪＢＲｅｍｏｔｅインタフェース３３は、ＥＪＢコンポーネントが提供する操作をＥＪＢクライアントに提供するためのインタフェースが共通に持つ操作を定義した上位インタフェースである。コンポーネントＡＲｅｍｏｔｅインタフェース３４は、コンポーネントＡが提供する操作を利用側アプリケーションに提供する機能をもつ、ＥＪＢＲｅｍｏｔｅインタフェース３３のサブインタフェースである。ＥＪＢ実装クラスインタフェース３５は、ＥＪＢコンポーネントの実際の処理を定義するクラスが、その性質毎に共通に持つインタフェースである。性質とは、データを永続化するもの、データを永続化しないもの、また、メッセージ駆動により起動するものの違いである。
【００４５】
本来ＥＪＢ実装クラスは、そのＥＪＢがコンポーネントとして持つべき処理を内包しているが、本実施形態では、コンポーネントの処理はＥＪＢという形態に関わり無く、コンポーネントＡ実装クラス２４に定義されている。コンポーネントＡＥＪＢ適合実装クラス３６は、ＥＪＢとしての体裁を整え、かつ、実際の処理をコンポーネントＡ実装クラス２４に委譲する役目を持つ。
【００４６】
以上のように、この実施形態のコンポーネント生成実行機構によれば、以下のような効果を奏し得る。
【００４７】
▲１▼コンポーネント動作条件定義記述１７Ａ，１７Ｂの読み込みや実体生成の際のコンポーネント１３Ａ，１３Ｂへの提供を、ミドルウェア１２に代わってコンポーネント生成管理部１８が行うので、これまでのミドルウェア１２に依存するコンポーネント動作条件定義記述の場所や、形式、定義内容に課せられていた制約が無くなり、コンポーネント型ソフトウェア開発の自由度、開発効率の向上を図ることができる。
【００４８】
▲２▼また、従来のＥＪＢでは、コンポーネントはミドルウェア用の固有のインタフェースを持っていた。ここでコンポーネントのインタフェースとは、そのコンポーネントの特定の役割をコンポーネントが演じるために必要とされる機能や情報を定義したものである。これに対して本実施形態は、コンポーネントのインタフェースをコンポーネントＩ／Ｆ適用部１９Ａ，１９Ｂによって高い自由度で提供できるので、コンポーネントの採り得る構造にミドルウェアによる制約が課せられることがなくなり、汎用性の高いコンポーネント構造とすることが可能になる。
【００４９】
次に、本発明の他の実施形態を説明する。
一般的には、フレームワークは、多くの業務（アプリケーション）の共通部分のみを実装した雛形を指し、変更可能な部分についてはコンポーネント（ビジネスロジック）を組み込む（プラグインする）ことによって、個々の要求を満たすアプリケーションを少ない労力で開発することを可能とするものである。
【００５０】
このフレームワークを本発明に適用して先の実施形態と同様のコンポーネント生成実行機構を実現することが可能である。
【００５１】
図８に、このフレームワークを用いて本発明のコンポーネント生成実行機構を実施した一形態である情報システム１００ａの構成を示す。
【００５２】
同図に示すように、この実施形態では、コンポーネント環境管理部１６およびコンポーネント生成管理部１８の機能をフレームワーク４１にプラグインして構成されたものである。このフレームワーク４１はミドルウェア１２上で動作し、アプリケーション１４はフレームワーク４１の上に構築されている。その他の構成は図１と同様である。
【００５３】
次に、このフレームワーク４１を用いたコンポーネント生成実行機構の動作手順を説明する。
【００５４】
１ａ．コンポーネントの実行環境の初期化
図９に示すように、アプリケーション管理者１０１によって初期化の操作が行われる。これは通常、ミドルウェア１２の初期化によって行われる（１．初期化）。ミドルウェア１２は登録されているアプケリーション１４の初期化とフレームワーク４１の初期化を行う（２．初期化）。続いてフレームワーク４１はコンポーネント環境管理部１６の初期化を行う（３．初期化）。コンポーネント環境管理部１６は、ミドルウェア１２、フレームワーク４１を通じて、ミドルウェア１２に依存した形式で記述されているコンポーネント環境定義記述１５を読み込み（４．読み込み）、その内容に基づく環境情報をメモリ２に格納する（５．コンポーネント環境設定）。
【００５５】
２ａ．コンポーネントの生成
図１０に示すように、ユーザ１０２はアプリケーション１４への処理要求を行う（１．処理要求）。ミドルウェア１２は処理要求を解釈してフレームワーク４１に処理要求を行う（２．処理要求）。フレームワーク４１はこの処理要求をアプリケーション１４に引き渡す（３．処理要求）。アプリケーション１４がコンポーネントＡ（１３Ａ）を利用するように作成されていた場合、処理要求を受けたアプリケーション１４は、コンポーネントＡ（１３Ａ）がアプリケーション１４に公開しているインタフェースであるコンポーネントＩ／Ｆ適用部１９Ａに対して生成要求を行う（４．生成要求）。コンポーネントＩ／Ｆ適用部１９Ａは、アプリケーション１４からの生成要求を受けるとコンポーネント環境管理部１６に対して環境情報の取得を要求する（５．環境情報取得）。コンポーネント環境管理部１６は、この要求に応じて上記の初期化でメモリ２に格納しておいた環境情報をコンポーネントＩ／Ｆ適用部１９Ａに返す（６．返却）。
【００５６】
コンポーネントＩ／Ｆ適用部１９Ａは環境情報を受け取ると、コンポーネント生成管理部１８に対して環境情報を提供するとともにコンポーネントＡ（１３Ａ）の生成要求を行う（７．生成要求）。コンポーネント生成管理部１８は、渡された環境情報に基づきコンポーネントＡ（１３Ａ）が実体化して動作するのに必要な動作条件をコンポーネント動作条件定義記述１７Ａから読み込み（８．読み込み）、コンポーネントＩ／Ｆ適用部１９Ａに返す（９．返却）。
【００５７】
コンポーネントＩ／Ｆ適用部１９Ａは、渡されたコンポーネント動作条件定義記述１７Ａに基づいて、汎用的な構造を持つコンポーネントＡ（１３）に対して動作条件を与えるとともに実体の生成を要求する（１０．実体生成）。コンポーネントＡ（１３）は、渡された動作条件に基づいて自らを実体化し、この実体への参照をコンポーネントＩ／Ｆ適用部１９Ａへ返す（１１．返却）。
【００５８】
コンポーネントＩ／Ｆ適用部１９Ａは、コンポーネントＡ（１３Ａ）から渡された実体への参照をアプリケーション１４に返す（１１．返却）。このときコンポーネントＡの実体はコンポーネントＩ／Ｆ適用部１９Ａに隠蔽されており、アプリケーション１４が直接そのコンポーネントＡの実体についての情報を保持する必要はない。
【００５９】
３ａ．コンポーネントの利用
アプリケーション１４は、コンポーネントＩ／Ｆ適用部１９Ａに対して処理の要求を行う（１３．処理要求）。コンポーネントＩ／Ｆ適用部１９Ａはアプリケーション１４からの処理要求をコンポーネントＡ（１３Ａ）に委譲する（１４．処理要求）。処理要求を委譲されたコンポーネントＡ（１３Ａ）は、自らの実体に基づいて処理を実行し、その結果をコンポーネントＩ／Ｆ適用部１９Ａに返却する（１５．返却）。さらに、コンポーネントＩ／Ｆ適用部１９ＡはコンポーネントＡ（１３Ａ）からの処理結果をアプリケーション１４に返却する（１６．返却）。アプリケーション１４は、受け取った処理結果を利用して、自らの実装に基づいた処理を行い、その結果をフレームワーク４１へ返却する（１７．返却）。さらにフレームワーク４１はその処理結果をミドルウェア１２に引き渡す（１８．返却）。そしてミドルウェア１２は、自らの実装に基づき処理結果をユーザに返却する（１９．返却）。
【００６０】
以上本発明の実施形態を説明したが、本発明は、上述の実施形態にのみ限定されるものではなく、本発明の要旨を逸脱しない範囲内において種々変更を加え得ることは勿論である。
【００６１】
【発明の効果】
以上説明したように、本発明によれば、コンポーネント動作条件定義記述の読み込みや実体生成の際のコンポーネントへの提供を、ミドルウェアに代わってコンポーネント生成管理部が行うことで、これまでのミドルウェアに依存するコンポーネント動作条件定義記述の場所や、形式、定義内容に課せられていた制約が無くなり、コンポーネント型ソフトウェア開発の自由度、開発効率の向上を図ることができる。また、コンポーネントのインタフェースをコンポーネントＩ／Ｆ適用部によって高い自由度で提供できるので、コンポーネントの採り得る構造にミドルウェアによる制約が課せられることがなくなり、汎用性の高いコンポーネント構造とすることが可能になる。
【図面の簡単な説明】
【図１】本発明のコンポーネント生成実行機構を実施した一形態である情報システムの構成を示すブロック図である。
【図２】ＸＭＬによるコンポーネント環境定義記述１５の例を示す図である。
【図３】ＸＭＬによるコンポーネント動作条件定義記述の例を示す図である。
【図４】コンポーネントの実行環境の初期化時の手順を示す図である。
【図５】コンポーネントの生成および利用時の手順を示す図である。
【図６】本実施形態で採用されたコンポーネントの本体の構造例を示すクラス図である。
【図７】図６のコンポーネントをコンポーネントＩ／Ｆ適用部によってＥＪＢに適合させた場合のコンポーネントＩ／Ｆ適用部の構成の例を示すクラス図である。
【図８】フレームワークを用いて本発明のコンポーネント生成実行機構を実施した一形態である情報システムの構成を示すブロック図である。
【図９】図８のコンポーネント生成実行機構でのコンポーネントの実行環境の初期化時の手順を示す図である。
【図１０】図８のコンポーネント生成実行機構でのコンポーネントの生成および利用時の手順を示す図である。
【符号の説明】
１・・・ＣＰＵ、２・・・メモリ、１０・・・サーバコンピュータ、１１・・・オペレーティング・システム、１２・・・ミドルウェア、１３Ａ，１３Ｂ・・・コンポーネント、１４・・・アプリケーション、１５・・・コンポーネント環境定義記述、１６・・・コンポーネント環境管理部、１７Ａ，１７Ｂ・・・コンポーネント動作条件定義記述、１８・・・コンポーネント生成管理部、１９Ａ，１９Ｂ・・・コンポーネントＩ／Ｆ適用部、４１・・・フレームワーク、１００・・・情報システム
【発明の属する技術分野】
本発明は、ミドルウェア上でコンポーネントを利用したアプリケーションを動作させるためのコンポーネント生成実行機構およびプログラムに関する。
【０００２】
【従来の技術】
コンポーネントとは、アプリケーションを構築するためのビジネスロジックなどを実装したソフトウェア部品である。例として、米国Ｓｕｎ Ｍｉｃｒｏｓｙｓｔｅｍｓ社が提唱している規約であるＥＪＢ（Ｅｎｔｅｒｐｒｉｓｅ Ｊａｖａ（登録商標） Ｂｅａｎｓ）などがある。ＥＪＢは、Ｊａｖａプログラム言語で分散オブジェクト指向の業務アプリケーションを構築するための標準コンポーネントアーキテクチャであり、異なるベンダのツールを使用し開発したコンポーネントを組み合わせることで分散アプリケーションの構築を可能とするものである。ＥＪＢを利用することによって、開発者は、アプリケーション開発時にビジネスロジックの開発だけに専念でき、効率的なアプリケーション開発が可能になる。
【０００３】
ＥＪＢアーキテクチャにおいては、ＥＪＢコンポーネントの実行環境をコンテナが提供するようになっている。通常、このコンテナはＥＪＢサーバによって管理される。ＥＪＢクライアント（アプリケーション）が、コンテナが提供する標準化されたインターフェイスを介してコンテナにＥＪＢのオブジェクト生成を要求すると、コンテナは、Ｄｅｐｌｏｙｍｅｎｔ Ｄｅｓｃｒｉｐｔｅｒと呼ばれる、コンポーネントの動作条件（トランザクション管理、セキュリティ管理などの属性値）を定義する記述を読み込み、これに基づいてコンポーネントの組み込み、インスタンス生成を行う。これにより実行可能なコンポーネントが生成される（たとえば、特許公報１参照）。
【０００４】
【特許文献１】
特開２００２−４９４９６号公報
【０００５】
さらに、ＥＪＢクライアントがコンテナが提供する標準化されたインターフェイスを介してコンポーネントのビジネスメソッドを呼び出すと、コンテナによってコンポーネントの実体に実装されたビジネスメソッドが呼び出されて、アプリケーションの機能として実行される。
【０００６】
以上のように、ＥＪＢアーキテクチャにおいて、ＥＪＢコンポーネントを動作させるにはその実行環境を提供するＥＪＢコンテナ、さらにこのＥＪＢコンテナを管理するＥＪＢサーバが不可欠である。これはＥＪＢコンポーネントの実体の構造がＥＪＢ固有のものであり、他の動作環境でＥＪＢコンポーネントを動作させることはできないことを意味する。
【０００７】
また、ＥＪＢアーキテクチャでは、前述したように、コンテナがコンポーネントの動作条件定義記述を読み込むことによって実行可能なコンポーネントを生成しているが、動作条件の定義記述の置き場所はコンテナベンダーによって決められ、コンテナにその場所情報にアクセスする機能が実装されている。また、動作条件の定義記述の形式もコンテナに依存している。すなわち、ＥＪＢアーキテクチャでは、定義記述の場所、その記述形式、定義内容について多くの制約が課せられており、このことがシステムの設計の自由度を損ね、開発効率の向上を阻んでいた。
【０００８】
たとえば、Ｄｅｐｌｏｙｍｅｎｔ Ｄｅｓｃｒｉｐｔｅｒでは、コンポーネントの拡張実装などの定義は範疇外とされ、単一階層のキーと値の定義のみに制限され、ツリー構造を持つような複雑な設定情報を記述することはできない。このコンポーネントの拡張実装を実現するには、その拡張のための情報をアプリケーションもしくはコンポーネントの内部にハードコーディング、すなわち特定の動作環境で動作させることを前提とした処理やデータをソースコードの中に書き込んでプログラミングしなければならなかった。
【０００９】
また、アプリケーションとコンポーネントとの間の相互作用をフレームワークで管理する方式は既に存在する（たとえば、特許公報２参照）。フレームワークとは、一般的には、多くの業務（アプリケーション）の共通部分のみを実装した雛形を指し、変更可能な部分についてはコンポーネント（ビジネスロジック）を組み込む（プラグインする）ことによって、個々の要求を満たすアプリケーションを少ない労力で開発することを可能とするものである。この特許公報の発明において、フレームワークは、アプリケーションからサービスの実装の要求、その実装に課せられる制約などを受けて、そのサービス（コンポーネント）の実装を動的に構築するものとして用いられている。
【００１０】
【特許文献２】
特開２００１−２１６１６２号公報
【００１１】
【発明が解決しようとする課題】
本発明が解決しようとする課題としては、前述したように、ＥＪＢアーキテクチャにおけるコンポーネントの実体の構造に課せられた制約と、コンポーネント動作条件の定義記述の場所、記述形式、定義内容に課せられた制約がある。ＥＪＢコンポーネントの実体の構造に課せられた制約は、コンポーネントの実装を特定ミドルウェアに依存しない汎用的なものとすることを妨げ、コンポーネント動作条件の定義記述に関する制約は、コンポーネント型ソフトウェア開発の自由度を損ね、開発効率の向上を阻む一要因となっていた。
【００１２】
本発明はこのような課題を解決するためになされたもので、コンポーネントの実体の構造に課せられる制約を軽減できるコンポーネント生成実行機構およびプログラムの提供を目的とする。
また、本発明は、コンポーネント動作条件定義記述の場所、記述形式、定義内容の制約を軽減できるコンポーネント生成実行機構およびプログラムの提供を目的とする。
【００１３】
【課題を解決するための手段】
かかる目的を達成するために、本発明のコンポーネント生成実行機構は、オペレーティング・システム上で動作するミドルウェアと、前記ミドルウェア上で動作するアプリケーションと、前記アプリケーションによって利用されるコンポーネントと、前記コンポーネントが実体化して動作するのに必要な動作条件を記述したコンポーネント動作条件定義記述と、少なくとも前記コンポーネント動作条件定義記述が存在する任意の場所を含む前記コンポーネントの動作環境が記述され、前記ミドルウェアに読み込み処理が依存するコンポーネント環境定義記述と、前記コンポーネント環境定義記述の読み込みを前記ミドルウェアに依頼し、当該ミドルウェアによって読み込まれた前記コンポーネント環境定義記述に基づいて前記コンポーネントの動作環境を設定、管理するコンポーネント環境管理部と、前記コンポーネントのインタフェースを提供するコンポーネントＩ／Ｆ適用部と、前記コンポーネント環境管理部によって設定された前記動作環境に基づいて前記コンポーネント動作条件定義記述を読み込み、前記コンポーネントＩ／Ｆ適用部を通じて前記コンポーネントに動作条件を与えるとともに実体の生成を要求するコンポーネント生成管理部とを具備する。
【００１４】
この発明によれば、コンポーネント動作条件定義記述の読み込みや実体生成の際のコンポーネントへの提供を、ミドルウェアに代わってコンポーネント生成管理部が行うことで、これまでのミドルウェアに依存するコンポーネント動作条件定義記述の場所や、形式、定義内容に課せられていた制約が無くなり、コンポーネント型ソフトウェア開発の自由度、開発効率の向上を図ることができる。
【００１５】
また、コンポーネントのインタフェースをコンポーネントＩ／Ｆ適用部によって高い自由度で提供できるので、コンポーネントの採り得る構造にミドルウェアによる制約が課せられることがなくなり、汎用性の高いコンポーネント構造とすることが可能になる。
【００１６】
また、本発明において、アプリケーションへの処理要求の発生時、アプリケーションは、コンポーネントＩ／Ｆ適用部にコンポーネントの生成要求を行い、この要求によりコンポーネントＩ／Ｆ適用部はコンポーネント環境管理部に環境情報の取得を要求し、コンポーネント環境管理部はこの要求に応じて環境情報をコンポーネントＩ／Ｆ適用部を介してコンポーネント生成管理部に渡すようにしてもよい。
【００１７】
さらに、本発明において、コンポーネントは取得した動作条件に基づいて自らを実体化し、この実体への参照をコンポーネントＩ／Ｆ適用部を通じてアプリケーションに返し、アプリケーションは実体への参照を取得するとコンポーネントＩ／Ｆ適用部を介してコンポーネントに処理要求を行い、この処理要求によりコンポーネントは自らの実体に基づいて処理を実行し、その結果をコンポーネントＩ／Ｆ適用部を介してアプリケーションに返し、アプリケーションは当該処理結果を利用して自らの実装に基づいた処理を行い、その結果をミドルウェアを介して前記ユーザに返すようにしてもよい。
【００１８】
さらに、本発明は、ミドルウェア上で動作するフレームワークを有し、このフレームワークにコンポーネント環境管理部およびコンポーネント生成管理部の機能がプラグインされた構成とすることも可能である。
【００１９】
【発明の実施の形態】
以下、図面を参照して本発明の実施の形態について説明する。
図１に、本発明のコンポーネント生成実行機構を実施した一形態である情報システム１００の構成を示す図である。
【００２０】
同図に示すように、この情報システム１００は、ＣＰＵ１、メモリ２、外部記憶装置３、バス４などの一般的なコンピュータアーキテクチャを有するサーバコンピュータ１０に構築されている。このサーバコンピュータ１０はインターネットやＬＡＮなどのネットワーク５にネットワーク接続装置６を通じて接続されている。
【００２１】
この情報システム１００のソフトウェア要素としては、オペレーティング・システム１１（以下、ＯＳと呼ぶ。）と、ミドルウェア１２と、アプリケーション１４が利用するロジックを実装した１つ以上のコンポーネント１３Ａ，１３Ｂと、各コンポーネント１３Ａ，１３Ｂを利用するアプリケーション１４と、コンポーネント環境定義記述１５と、コンポーネント環境定義記述１５に基づいて個々のコンポーネント１３Ａ，１３Ｂの動作条件を記述したコンポーネント動作条件定義記述１７Ａ，１７Ｂの場所を管理するコンポーネント環境管理部１６と、コンポーネント動作条件定義記述１７Ａ，１７Ｂに基づいてコンポーネント１３Ａ，１３Ｂの実体生成を行うコンポーネント生成管理部１８と、コンポーネント１３Ａ，１３Ｂごとのインタフェースを提供するコンポーネントＩ／Ｆ適用部１９Ａ，１９Ｂとを備えている。ここでコンポーネントの数は２としたが、その数に特に限定や制限はない。
【００２２】
ミドルウェア１２はＯＳ１１上で動作する。ミドルウェア１２はアプリケーション・サーバと同義であり、トランザクション処理、負荷分散処理、データベース処理、そしてコンポーネント環境管理部１６からの要求によりミドルウェア１２に依存して決められた場所からコンポーネント環境定義記述１５を読み込んでコンポーネント環境管理部１６にその内容（環境情報）を返す処理などを行う。
【００２３】
コンポーネントＩ／Ｆ適用部１９Ａ，１９Ｂは個々のコンポーネント１３Ａ，１３Ｂごとに用意され、それぞれアプリケーション１４からの実体生成や利用の要求を受けて、自身に対応するコンポーネント１３Ａ，１３Ｂにその処理を委譲する。また、コンポーネントＩ／Ｆ適用部１９Ａ，１９Ｂは実体生成をコンポーネントに委譲する時、コンポーネント生成管理部１８によって読み込まれたコンポーネント動作条件定義記述１７Ａ，１７Ｂに基づく動作条件を対応するコンポーネント１３Ａ，１３Ｂに引き渡し、対応するコンポーネント１３Ａ，１３Ｂから渡された実体への参照をアプリケーション１４に返す。
【００２４】
コンポーネント環境定義記述１５は、コンポーネント動作条件定義記述１７Ａ，１７Ｂの場所などをコンポーネント環境管理部１６に公開する定義文であり、たとえばＸＭＬ（Ｅｘｔｅｎｓｉｂｌｅ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）などの言語で記述される。図２に、ＸＭＬによるコンポーネント環境定義記述１５の記述例を示す。２０１はコンポーネントを定義する記述の行、２０２はコンポーネント動作条件定義記述１７Ａ，１７ＢのＸＭＬファイルの場所の記述行である。
【００２５】
コンポーネント動作条件定義記述１７Ａ，１７Ｂは、コンポーネント１３Ａ，１３Ｂを実体化する際のカスタマイズ方法などの動作条件がＸＭＬなどの言語により記述された情報である。図３に、ＸＭＬによるコンポーネント動作条件定義記述の例を示す。ＸＭＬのスキーマはコンポーネント独自のものを利用することができる。このＸＭＬの文書はファイル、あるいはデータベースのレコードとして存在することができる。
【００２６】
この例はメールの送受信を行うコンポーネントのコンポーネント動作条件定義記述の例である。メールコンポーネントの実体はこのコンポーネント動作条件定義記述により指定することができる。メールコンポーネントの実体には、たとえばＪａｖａＭａｉｌと呼ばれる汎用のメールライブラリィやコンポーネントの開発者が独自に作成した実装クラスなどを指定することが可能である。
【００２７】
符号３０１で示す＜ｓｍｔｐ−ｉｎｆｏ＞タグと＜／ｓｍｔｐ−ｉｎｆｏ＞タグとの間はメール送信のための動作条件定義記述の記述、符号３０２で示す＜ｐｏｐ−ｉｎｆｏ＞タグと＜／ｐｏｐ−ｉｎｆｏ＞タグとの間はメール受信のための動作条件定義記述の記述、符号３０３で示す＜ｓｅｎｄｅｒ−ｈａｎｄｌｅｒ＞タグと＜／ｓｅｎｄｅｒ−ｈａｎｄｌｅｒ＞タグとの間はメールを送信する時に実際に用いるクラスの設定、符号３０４で示す＜ｇｅｔｔｅｒ−ｈａｎｄｌｅｒ＞タグと＜／ｇｅｔｔｅｒ−ｈａｎｄｌｅｒ＞タグとの間はメールを受信する時に実際に用いるクラスの設定、符号３０５で示す＜ｓｕｂｊｅｃｔ−ｈａｎｄｌｅｒ＞タグと＜／ｓｕｂｊｅｃｔ−ｈａｎｄｌｅｒ＞タグとの間はメール受信のサブジェクトを条件にして起動するプログラムの設定である。
【００２８】
コンポーネント動作条件定義記述１７Ａ，１７Ｂの場所はミドルウェア１２に依存しない任意の場所とすることができる。一方、コンポーネント環境定義記述１５はミドルウェア１２による読み込みを前提としているので、その場所や、記述の形式、定義内容はミドルウェア１２による制約の範囲で決められる。
【００２９】
次に、このコンポーネント生成実行機構の動作手順を説明する。
【００３０】
１．コンポーネントの実行環境の初期化
図４に示すように、アプリケーション管理者１０１によって初期化の操作が行われる。これは通常、ミドルウェア１２の初期化によって行われる（１．初期化）。ミドルウェア１２は登録されているアプケリーション１４の初期化とコンポーネント環境管理部１６の初期化を行う（２．初期化）。コンポーネント環境管理部１６は、ミドルウェア１２を通じて、ミドルウェア１２に依存した形式で記述されているコンポーネント環境定義記述１５を読み込み（３．読み込み）、その内容に基づく環境情報を設定たとえばメモリ２に格納する（５．コンポーネント環境設定）。
【００３１】
２．コンポーネントの生成
図５に示すように、ユーザ１０２はアプリケーション１４に対する処理要求を行う（１．処理要求）。ミドルウェア１２は処理要求を解釈してアプリケーション１４に対して処理要求を行う（２．処理要求）。アプリケーション１４がコンポーネントＡ（１３Ａ）を利用するように作成されていた場合、処理要求を受けたアプリケーション１４は、コンポーネントＡ（１３Ａ）がアプリケーション１４に公開しているインタフェースであるコンポーネントＩ／Ｆ適用部１９Ａに対して生成要求を行う（３．生成要求）。コンポーネントＩ／Ｆ適用部１９Ａは、アプリケーション１４からの生成要求を受けるとコンポーネント環境管理部１６に対して環境情報の取得を要求する（４．環境情報取得）。コンポーネント環境管理部１６は、この要求に応じて上記の初期化でメモリ２に格納しておいた環境情報をコンポーネントＩ／Ｆ適用部１９Ａに返す（５．返却）。
【００３２】
コンポーネントＩ／Ｆ適用部１９Ａは環境情報を受け取ると、コンポーネント生成管理部１８に対して環境情報を引き渡すとともにコンポーネントＡ（１３Ａ）の生成要求を行う（６．生成要求）。コンポーネント生成管理部１８は、渡された環境情報に基づきコンポーネントＡ（１３Ａ）が実体化して動作するのに必要な動作条件を記述したコンポーネント動作条件定義記述１７Ａを読み込み（７．読み込み）、コンポーネントＩ／Ｆ適用部１９Ａに返す（８．返却）。
【００３３】
コンポーネントＩ／Ｆ適用部１９Ａは、渡されたコンポーネント動作条件定義記述１７Ａに基づいて、汎用的な構造を持つコンポーネントＡ（１３）に対して動作条件を与えるとともに実体の生成を要求する（９．実体生成）。コンポーネントＡ（１３）は、渡された動作条件に基づいて自らを実体化し、この実体への参照をコンポーネントＩ／Ｆ適用部１９Ａへ返す（１０．返却）。
【００３４】
なお、実体生成の要求の度にコンポーネントの実体を生成することはハードウェア資源の利用効率の低下を招くので、一度生成された実体をプールしておき、次回以降の実体生成の要求に対しては、このプールされた実体への参照をコンポーネントＩ／Ｆ適用部１９Ａへ返すようにしてもよい。
【００３５】
コンポーネントＩ／Ｆ適用部１９Ａは、コンポーネントＡ（１３Ａ）から渡された実体への参照をアプリケーション１４に返す（１１．返却）。このときコンポーネントＡの実体はコンポーネントＩ／Ｆ適用部１９Ａに隠蔽されており、アプリケーション１４が直接そのコンポーネントＡの実体についての情報を保持する必要はない。
【００３６】
３．コンポーネントの利用
アプリケーション１４は、コンポーネントＩ／Ｆ適用部１９Ａに対して処理の要求を行う（１２．処理要求）。コンポーネントＩ／Ｆ適用部１９Ａはアプリケーション１４からの処理要求をコンポーネントＡ（１３Ａ）に委譲する（１３．処理要求）。処理要求を委譲されたコンポーネントＡ（１３Ａ）は、自らの実体に基づいて処理を実行し、その結果をコンポーネントＩ／Ｆ適用部１９Ａに返却する（１４．返却）。さらに、コンポーネントＩ／Ｆ適用部１９ＡはコンポーネントＡ（１３Ａ）からの処理結果をアプリケーション１４に返却する（１５．返却）。アプリケーション１４は、受け取った処理結果を利用して、自らの実装に基づいた処理を行い、その結果をミドルウェア１２へ返却する（１６．返却）。そしてミドルウェア１２は、自らの実装に基づき処理結果をユーザに返却する（１７．返却）。
【００３７】
図６は、この実施形態で採用される汎用的なコンポーネントたとえばコンポーネントＡの本体の構造例を示すクラス図である。
【００３８】
コンポーネント生成共通インタフェース２１は、コンポーネントの実体を生成する機能をもつクラスを作成する際に必要な共通部分を抜き出したクラスである。また、コンポーネント生成共通インタフェース２１はコンポーネントの実体を生成するための操作方法をユーザに統一的に提供する。コンポーネントＡ生成クラス２２はコンポーネントＡの実体を生成する機能を持つ、コンポーネント生成共通インタフェース２１のサブクラスであり、コンポーネント生成共通インタフェース２１の差分として定義される。
【００３９】
コンポーネント共通インタフェース２３は、コンポーネントが共通に持つべき機能たとえば設定ファイルの定義内容のキャッシュなどの機能を抜き出したクラスである。また、コンポーネント共通インタフェース２３はコンポーネント実体生成のための操作をコンポーネントＡ生成クラス２２に対して統一的に提供する。コンポーネントＡ実装クラス２４はコンポーネントＡの機能が実装された、コンポーネント共通インタフェース２３のサブクラスである。
【００４０】
動作条件定義記述解釈インタフェース２５は設定ファイルを読み込む際の共通の機能を抜き出したクラスである。コンポーネントＡ動作条件定義記述解釈クラス２６は、個々のコンポーネント毎に異なる設定ファイルの書式を解釈して、コンポーネントの実装クラスに設定可能な形態に変換する、動作条件定義記述解釈インタフェース２５のサブクラスである。
【００４１】
図７は、上記の汎用的なコンポーネントＡをコンポーネントＩ／Ｆ適用部１９ＡによってＥＪＢに適合させた場合の、コンポーネントＩ／Ｆ適用部１９Ａの構成の例を示すクラス図である。
【００４２】
ＥＪＢはその仕様により、ひとつのコンポーネントを作成する場合に２つのインタフェース（Ｈｏｍｅインタフェース、Ｒｅｍｏｔｅインタフェース）と１つのクラス（ＥＪＢ実装クラス）を作成することを義務づけている。ＥＪＢ実装クラスインタフェースはそのうちのＥＪＢ実装クラスを作成するときに利用するインタフェースである。
【００４３】
ＥＪＢＨｏｍｅインタフェース３１とＥＪＢＲｅｍｏｔｅインタフェース３３はＥＪＢの仕様として予め提供されるものである。ＥＪＢＨｏｍｅインタフェース３１は、ＥＪＢコンポーネントを生成する操作を利用側アプリケーション（ＥＪＢクライアントと呼ばれる。）に提供するためのインタフェースが共通に持つ操作を定義した上位インタフェースである。コンポーネントＡＨｏｍｅインタフェース３２は、コンポーネントＡを生成する操作を利用側アプリケーションに提供する機能をもつ、ＥＪＢＨｏｍｅインタフェース３１のサブインタフェースである。
【００４４】
ＥＪＢＲｅｍｏｔｅインタフェース３３は、ＥＪＢコンポーネントが提供する操作をＥＪＢクライアントに提供するためのインタフェースが共通に持つ操作を定義した上位インタフェースである。コンポーネントＡＲｅｍｏｔｅインタフェース３４は、コンポーネントＡが提供する操作を利用側アプリケーションに提供する機能をもつ、ＥＪＢＲｅｍｏｔｅインタフェース３３のサブインタフェースである。ＥＪＢ実装クラスインタフェース３５は、ＥＪＢコンポーネントの実際の処理を定義するクラスが、その性質毎に共通に持つインタフェースである。性質とは、データを永続化するもの、データを永続化しないもの、また、メッセージ駆動により起動するものの違いである。
【００４５】
本来ＥＪＢ実装クラスは、そのＥＪＢがコンポーネントとして持つべき処理を内包しているが、本実施形態では、コンポーネントの処理はＥＪＢという形態に関わり無く、コンポーネントＡ実装クラス２４に定義されている。コンポーネントＡＥＪＢ適合実装クラス３６は、ＥＪＢとしての体裁を整え、かつ、実際の処理をコンポーネントＡ実装クラス２４に委譲する役目を持つ。
【００４６】
以上のように、この実施形態のコンポーネント生成実行機構によれば、以下のような効果を奏し得る。
【００４７】
▲１▼コンポーネント動作条件定義記述１７Ａ，１７Ｂの読み込みや実体生成の際のコンポーネント１３Ａ，１３Ｂへの提供を、ミドルウェア１２に代わってコンポーネント生成管理部１８が行うので、これまでのミドルウェア１２に依存するコンポーネント動作条件定義記述の場所や、形式、定義内容に課せられていた制約が無くなり、コンポーネント型ソフトウェア開発の自由度、開発効率の向上を図ることができる。
【００４８】
▲２▼また、従来のＥＪＢでは、コンポーネントはミドルウェア用の固有のインタフェースを持っていた。ここでコンポーネントのインタフェースとは、そのコンポーネントの特定の役割をコンポーネントが演じるために必要とされる機能や情報を定義したものである。これに対して本実施形態は、コンポーネントのインタフェースをコンポーネントＩ／Ｆ適用部１９Ａ，１９Ｂによって高い自由度で提供できるので、コンポーネントの採り得る構造にミドルウェアによる制約が課せられることがなくなり、汎用性の高いコンポーネント構造とすることが可能になる。
【００４９】
次に、本発明の他の実施形態を説明する。
一般的には、フレームワークは、多くの業務（アプリケーション）の共通部分のみを実装した雛形を指し、変更可能な部分についてはコンポーネント（ビジネスロジック）を組み込む（プラグインする）ことによって、個々の要求を満たすアプリケーションを少ない労力で開発することを可能とするものである。
【００５０】
このフレームワークを本発明に適用して先の実施形態と同様のコンポーネント生成実行機構を実現することが可能である。
【００５１】
図８に、このフレームワークを用いて本発明のコンポーネント生成実行機構を実施した一形態である情報システム１００ａの構成を示す。
【００５２】
同図に示すように、この実施形態では、コンポーネント環境管理部１６およびコンポーネント生成管理部１８の機能をフレームワーク４１にプラグインして構成されたものである。このフレームワーク４１はミドルウェア１２上で動作し、アプリケーション１４はフレームワーク４１の上に構築されている。その他の構成は図１と同様である。
【００５３】
次に、このフレームワーク４１を用いたコンポーネント生成実行機構の動作手順を説明する。
【００５４】
１ａ．コンポーネントの実行環境の初期化
図９に示すように、アプリケーション管理者１０１によって初期化の操作が行われる。これは通常、ミドルウェア１２の初期化によって行われる（１．初期化）。ミドルウェア１２は登録されているアプケリーション１４の初期化とフレームワーク４１の初期化を行う（２．初期化）。続いてフレームワーク４１はコンポーネント環境管理部１６の初期化を行う（３．初期化）。コンポーネント環境管理部１６は、ミドルウェア１２、フレームワーク４１を通じて、ミドルウェア１２に依存した形式で記述されているコンポーネント環境定義記述１５を読み込み（４．読み込み）、その内容に基づく環境情報をメモリ２に格納する（５．コンポーネント環境設定）。
【００５５】
２ａ．コンポーネントの生成
図１０に示すように、ユーザ１０２はアプリケーション１４への処理要求を行う（１．処理要求）。ミドルウェア１２は処理要求を解釈してフレームワーク４１に処理要求を行う（２．処理要求）。フレームワーク４１はこの処理要求をアプリケーション１４に引き渡す（３．処理要求）。アプリケーション１４がコンポーネントＡ（１３Ａ）を利用するように作成されていた場合、処理要求を受けたアプリケーション１４は、コンポーネントＡ（１３Ａ）がアプリケーション１４に公開しているインタフェースであるコンポーネントＩ／Ｆ適用部１９Ａに対して生成要求を行う（４．生成要求）。コンポーネントＩ／Ｆ適用部１９Ａは、アプリケーション１４からの生成要求を受けるとコンポーネント環境管理部１６に対して環境情報の取得を要求する（５．環境情報取得）。コンポーネント環境管理部１６は、この要求に応じて上記の初期化でメモリ２に格納しておいた環境情報をコンポーネントＩ／Ｆ適用部１９Ａに返す（６．返却）。
【００５６】
コンポーネントＩ／Ｆ適用部１９Ａは環境情報を受け取ると、コンポーネント生成管理部１８に対して環境情報を提供するとともにコンポーネントＡ（１３Ａ）の生成要求を行う（７．生成要求）。コンポーネント生成管理部１８は、渡された環境情報に基づきコンポーネントＡ（１３Ａ）が実体化して動作するのに必要な動作条件をコンポーネント動作条件定義記述１７Ａから読み込み（８．読み込み）、コンポーネントＩ／Ｆ適用部１９Ａに返す（９．返却）。
【００５７】
コンポーネントＩ／Ｆ適用部１９Ａは、渡されたコンポーネント動作条件定義記述１７Ａに基づいて、汎用的な構造を持つコンポーネントＡ（１３）に対して動作条件を与えるとともに実体の生成を要求する（１０．実体生成）。コンポーネントＡ（１３）は、渡された動作条件に基づいて自らを実体化し、この実体への参照をコンポーネントＩ／Ｆ適用部１９Ａへ返す（１１．返却）。
【００５８】
コンポーネントＩ／Ｆ適用部１９Ａは、コンポーネントＡ（１３Ａ）から渡された実体への参照をアプリケーション１４に返す（１１．返却）。このときコンポーネントＡの実体はコンポーネントＩ／Ｆ適用部１９Ａに隠蔽されており、アプリケーション１４が直接そのコンポーネントＡの実体についての情報を保持する必要はない。
【００５９】
３ａ．コンポーネントの利用
アプリケーション１４は、コンポーネントＩ／Ｆ適用部１９Ａに対して処理の要求を行う（１３．処理要求）。コンポーネントＩ／Ｆ適用部１９Ａはアプリケーション１４からの処理要求をコンポーネントＡ（１３Ａ）に委譲する（１４．処理要求）。処理要求を委譲されたコンポーネントＡ（１３Ａ）は、自らの実体に基づいて処理を実行し、その結果をコンポーネントＩ／Ｆ適用部１９Ａに返却する（１５．返却）。さらに、コンポーネントＩ／Ｆ適用部１９ＡはコンポーネントＡ（１３Ａ）からの処理結果をアプリケーション１４に返却する（１６．返却）。アプリケーション１４は、受け取った処理結果を利用して、自らの実装に基づいた処理を行い、その結果をフレームワーク４１へ返却する（１７．返却）。さらにフレームワーク４１はその処理結果をミドルウェア１２に引き渡す（１８．返却）。そしてミドルウェア１２は、自らの実装に基づき処理結果をユーザに返却する（１９．返却）。
【００６０】
以上本発明の実施形態を説明したが、本発明は、上述の実施形態にのみ限定されるものではなく、本発明の要旨を逸脱しない範囲内において種々変更を加え得ることは勿論である。
【００６１】
【発明の効果】
以上説明したように、本発明によれば、コンポーネント動作条件定義記述の読み込みや実体生成の際のコンポーネントへの提供を、ミドルウェアに代わってコンポーネント生成管理部が行うことで、これまでのミドルウェアに依存するコンポーネント動作条件定義記述の場所や、形式、定義内容に課せられていた制約が無くなり、コンポーネント型ソフトウェア開発の自由度、開発効率の向上を図ることができる。また、コンポーネントのインタフェースをコンポーネントＩ／Ｆ適用部によって高い自由度で提供できるので、コンポーネントの採り得る構造にミドルウェアによる制約が課せられることがなくなり、汎用性の高いコンポーネント構造とすることが可能になる。
【図面の簡単な説明】
【図１】本発明のコンポーネント生成実行機構を実施した一形態である情報システムの構成を示すブロック図である。
【図２】ＸＭＬによるコンポーネント環境定義記述１５の例を示す図である。
【図３】ＸＭＬによるコンポーネント動作条件定義記述の例を示す図である。
【図４】コンポーネントの実行環境の初期化時の手順を示す図である。
【図５】コンポーネントの生成および利用時の手順を示す図である。
【図６】本実施形態で採用されたコンポーネントの本体の構造例を示すクラス図である。
【図７】図６のコンポーネントをコンポーネントＩ／Ｆ適用部によってＥＪＢに適合させた場合のコンポーネントＩ／Ｆ適用部の構成の例を示すクラス図である。
【図８】フレームワークを用いて本発明のコンポーネント生成実行機構を実施した一形態である情報システムの構成を示すブロック図である。
【図９】図８のコンポーネント生成実行機構でのコンポーネントの実行環境の初期化時の手順を示す図である。
【図１０】図８のコンポーネント生成実行機構でのコンポーネントの生成および利用時の手順を示す図である。
【符号の説明】
１・・・ＣＰＵ、２・・・メモリ、１０・・・サーバコンピュータ、１１・・・オペレーティング・システム、１２・・・ミドルウェア、１３Ａ，１３Ｂ・・・コンポーネント、１４・・・アプリケーション、１５・・・コンポーネント環境定義記述、１６・・・コンポーネント環境管理部、１７Ａ，１７Ｂ・・・コンポーネント動作条件定義記述、１８・・・コンポーネント生成管理部、１９Ａ，１９Ｂ・・・コンポーネントＩ／Ｆ適用部、４１・・・フレームワーク、１００・・・情報システム
Claims (5)
- ミドルウェア上で動作するアプリケーションと、
前記アプリケーションによって利用されるコンポーネントと、
前記コンポーネントが実体化して動作するのに必要な動作条件を記述したコンポーネント動作条件定義記述と、
少なくとも前記コンポーネント動作条件定義記述が存在する任意の場所を含む前記コンポーネントの動作環境が記述され、前記ミドルウェアに読み込み処理が依存するコンポーネント環境定義記述と、
前記コンポーネント環境定義記述の読み込みを前記ミドルウェアに依頼し、当該ミドルウェアによって読み込まれた前記コンポーネント環境定義記述に基づいて前記コンポーネントの動作環境を設定、管理するコンポーネント環境管理部と、
前記コンポーネントのインタフェースを提供するコンポーネントＩ／Ｆ適用部と、
前記コンポーネント環境管理部によって設定された前記動作環境に基づいて前記コンポーネント動作条件定義記述を読み込み、前記コンポーネントＩ／Ｆ適用部を通じて前記コンポーネントに動作条件を与えるとともに実体の生成を要求するコンポーネント生成管理部と
を具備することを特徴とするコンポーネント生成実行機構。 - 前記アプリケーションへの処理要求の発生時、前記アプリケーションは、前記コンポーネントＩ／Ｆ適用部に前記コンポーネントの生成要求を行い、この要求により前記コンポーネントＩ／Ｆ適用部は前記コンポーネント環境管理部に前記環境情報の取得を要求し、前記コンポーネント環境管理部はこの要求に応じて前記環境情報を前記コンポーネントＩ／Ｆ適用部を介して前記コンポーネント生成管理部に渡すことを特徴とする請求項１に記載のコンポーネント生成実行機構。
- 前記コンポーネントは取得した前記動作条件に基づいて自らを実体化し、この実体への参照をコンポーネントＩ／Ｆ適用部を通じて前記アプリケーションに返し、前記アプリケーションは前記実体への参照を取得すると前記コンポーネントＩ／Ｆ適用部を介して前記コンポーネントに処理要求を行い、この処理要求により前記コンポーネントは自らの実体に基づいて処理を実行し、その結果を前記コンポーネントＩ／Ｆ適用部を介して前記アプリケーションに返し、前記アプリケーションは当該処理結果を利用して自らの実装に基づいた処理を行い、その結果を前記ミドルウェアを介して前記ユーザに返すことを特徴とするコンポーネント生成実行機構。
- 前記ミドルウェア上で動作するフレームワークを有し、このフレームワークに前記コンポーネント環境管理部および前記コンポーネント生成管理部の機能がプラグインされていることを特徴とする請求項１に記載のコンポーネント生成実行機構。
- ミドルウェア上で動作するアプリケーションによって利用されるコンポーネントが実体化して動作するのに必要な動作条件を記述したコンポーネント動作条件定義記述の場所を少なくとも含む前記コンポーネントの動作環境が記述され、前記ミドルウェアに読み込み処理が依存するコンポーネント環境定義記述の読み込みを前記ミドルウェアに依頼し、当該ミドルウェアによって読み込まれた前記コンポーネント環境定義記述に基づいて前記コンポーネントの動作環境を設定、管理するコンポーネント環境管理部と、
前記コンポーネントのインタフェースを提供するコンポーネントＩ／Ｆ適用部と、
前記コンポーネント環境管理部によって設定された前記動作環境に基づいて前記コンポーネント動作条件定義記述を読み込み、前記コンポーネントＩ／Ｆ適用部を通じて前記コンポーネントに動作条件を与えるとともに実体の生成を要求するコンポーネント生成管理部
としてコンピュータを機能させることを特徴とするプログラム。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2003043304A JP2004252774A (ja) | 2003-02-20 | 2003-02-20 | コンポーネント生成実行機構およびプログラム |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2003043304A JP2004252774A (ja) | 2003-02-20 | 2003-02-20 | コンポーネント生成実行機構およびプログラム |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| JP2004252774A true JP2004252774A (ja) | 2004-09-09 |
Family
ID=33026343
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2003043304A Pending JP2004252774A (ja) | 2003-02-20 | 2003-02-20 | コンポーネント生成実行機構およびプログラム |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP2004252774A (ja) |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2010142943A (ja) * | 2008-12-22 | 2010-07-01 | Korea Electronics Telecommun | ロボット応用プログラム実行装置及び方法 |
-
2003
- 2003-02-20 JP JP2003043304A patent/JP2004252774A/ja active Pending
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2010142943A (ja) * | 2008-12-22 | 2010-07-01 | Korea Electronics Telecommun | ロボット応用プログラム実行装置及び方法 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US8473896B2 (en) | Computer software development incorporating core and compound services | |
| Watsen et al. | Bamboo-a portable system for dynamically extensible, real-time, networked, virtual environments | |
| US7627865B2 (en) | Method and apparatus for accessing instrumentation data from within a managed code environment | |
| US5860004A (en) | Code generator for applications in distributed object systems | |
| US7546606B2 (en) | System and method using a connector architecture for application integration | |
| US6721777B1 (en) | Modular and portable deployment of a resource adapter in an application server | |
| US6564377B1 (en) | Self-describing components within a software catalog | |
| Satoshi | HORB: Distributed execution of Java programs | |
| US6597366B1 (en) | Transparent general purpose object isolation for multi-tier distributed object environments | |
| Ben-Shaul et al. | Dynamic adaptation and deployment of distributed components in hadas | |
| US20040172637A1 (en) | Code morphing manager | |
| WO2003044661A1 (en) | System and method for implementing a service adapter | |
| Wang et al. | Evaluating meta-programming mechanisms for ORB middleware | |
| Humphrey et al. | An early evaluation of WSRF and WS-notification via WSRF. NET | |
| US8676842B2 (en) | Creating multiple Mbeans from a factory Mbean | |
| Schaaf et al. | Integrating Java and CORBA: A programmer's perspective | |
| Raptis et al. | Multi-technology distributed objects and their integration | |
| JP2004252774A (ja) | コンポーネント生成実行機構およびプログラム | |
| Little et al. | Building configurable applications in Java | |
| Dilley | Object-oriented distributed computing with C++ and OSF DCE | |
| Lau et al. | Deployment contracts for software components | |
| Mykkänen et al. | Component and Service Technology Families | |
| Román et al. | Unified Object Bus: Providing support for dynamic management of heterogeneous components | |
| Costanza et al. | The Comparand Pattern. | |
| Selamat et al. | Software component models from a technical perspective |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A621 | Written request for application examination |
Effective date: 20060110 Free format text: JAPANESE INTERMEDIATE CODE: A621 |
|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20090127 |
|
| A131 | Notification of reasons for refusal |
Effective date: 20090217 Free format text: JAPANESE INTERMEDIATE CODE: A131 |
|
| A521 | Written amendment |
Effective date: 20090420 Free format text: JAPANESE INTERMEDIATE CODE: A523 |
|
| A02 | Decision of refusal |
Effective date: 20090602 Free format text: JAPANESE INTERMEDIATE CODE: A02 |