JP2011242941A - 部品結合装置及びその処理方法 - Google Patents

Abstract

【課題】 ソフトウェア部品を組み合わせて構築したアプリケーションにおいて、ソフトウェア部品のデータを永続化できる装置及び方法を提供する。
【解決手段】 ソフトウェアとして実装される部品を結合して構成されたアプリケーションを実行する部品結合装置において、部品を動作させる前に部品結合定義に従って部品を結合する。部品のインスタンスのプロパティデータを永続化させるべく保存し、部品のインスタンス作成時に、保存されたプロパティデータをインスタンスに設定する。
【選択図】 図１

Description

本発明は、ソフトウェアとして実装される部品を結合して構成されたアプリケーションを実行する部品結合装置及びその処理方法に関する。

従来、ソフトウェア部品（以下、「部品」と称す）を組み合わせてアプリケーションを構築する多様な技術が存在する。この技術の一つに、Open SOA Collaborationが仕様策定したサービスコンポーネントアーキテクチャー仕様（以下、「ＳＣＡ」と称す）がある。部品やコンポーネント（部品のＳＣＡ用語）のインタフェースを、サービス、リファレンス、プロパティに単純化し、異言語部品や多様な通信プロトコル等の組み合わせを容易にしたところに特徴がある。その組み合わせ仕様は下記の非特許文献１に詳細に記載されている。

ここで、ＳＣＡ仕様では、部品の結合はＸＭＬ言語で記述された定義ファイルを用いて行う。ある部品が別の部品を利用する場合、それらの部品は定義ファイルが定める方法によって結合される。部品が結合される時、結合の具体的な方法は部品からは不可視になる。実際には結合される二つの部品は異なるコンピュータ上に存在し、部品間の呼び出しはネットワーク通信を通じて行われるかもしれない。そのような場合にも利用する側の部品は結合の具体的な方法を意識することなく、利用される側の部品の機能を利用することができる。

定義ファイルの読み出しや解析、部品の結合を行うのは、一般的にはＳＣＡランタイムと呼ばれるプログラムである。ＳＣＡランタイムは、定義ファイルの解析結果に基づき、部品の結合を行う。

定義ファイルでは、部品に設定すべきプロパティ値を記述することができる。この場合、個々の部品に対して、プロパティ名とプロパティ値が記述される。また、部品は複数のプロパティを持つことができるので、プロパティ名とプロパティ値の組も複数個記述することができる。

部品のインスタンスを作成時、定義ファイルに記述されたプロパティ値がインスタンスに設定される。設定を行うのはＳＣＡランタイムである。プロパティ値がインスタンスにどのように設定されるかは、部品を実現するプログラミング言語によって異なる。例えば、Ｊａｖａ（登録商標）言語の場合、その仕様は非特許文献２に記述されている。同文献の1.2.3.1項Property Injectionによれば、Ｊａｖａ（登録商標）アノテーションを、部品を実装するクラスのソースコードのセッターメソッドやフィールド、コンストラクタに記述することができる。ＳＣＡランタイムはこれを解釈し、定義ファイルに記述されたプロパティ名からプロパティ値設定を実行すべきセッターメソッドやフィールド、コンストラクタを特定する。そして、定義ファイルに記述されたプロパティ値と、特定された手法を用いて設定を実行する。

一方、データの永続化に関する従来技術を説明する。ここで「永続化」とは、データ（例えばオブジェクトの中身）をハードディスク等の不揮発性記憶装置に退避し、後で退避データから元のデータ（オブジェクト）を復元する処理のことである。一般的には、不揮発性記憶装置への退避処理を永続化と呼ぶ場合もあるが、後で復元することが退避処理の目的であることが多いため、ここでは両者をまとめて永続化処理と呼ぶことにする。

シリアライズ処理は永続化処理と類似の概念である。Ｊａｖａ（登録商標）オブジェクトの中身を、ネットワークを隔てた場所に送る場合、シリアライズ化（直列化とも呼ぶ）が行われる。尚、用途はネットワーク送信に限定されておらず、データの蓄積時に用いても良い。このシリアライズ処理では、標準的な方法でデータの変換、通信、蓄積が行われる。

従って、シリアライズ処理の具体的な方法が明らかであれば、他の異なるシステムともデータをやり取りできる。復元する処理はデシリアライズ処理である。退避、復元用途に使えるので永続化の手法としても使える。

永続化やシリアライズ化の技術として、例えば特許文献１には、完全なアイテムの復元を達成するため、アイテム及びその関連エンティティをシリアライゼーション、デシリアライゼーションするシステム及び方法が開示されている。

また、標準シリアライゼーションプロバイダではカバーできないカスタムオブジェクトタイプ用のカスタムシリアライゼーションプロバイダをロードし、シリアライゼーションマネージャを拡張できる（例えば、特許文献２参照）。

また、例えば特許文献３には、ユーザの要求やシステムの構造等に応じて、システムやオブジェクトの動作を変更できるオブジェクト指向データベースシステムが開示されている。各オブジェクトに対応して、オブジェクトの構造や動作に関するメタデータと、オブジェクトに関する操作を行うメタ手続きを有するメタオブジェクトを記憶する。本システムは、メタ手続きを変更し、オブジェクトの生成時、データの書き込み前後、入出力手続き呼出し前後の各処理をカスタマイズ可能にする。これにより、オブジェクトのデータの値や構造を変更した場合にディスクへの記憶を行う。

特開２００６−２３６３２８号公報 特開２００５−１１３６２号公報 特開平８−２７２８１５号公報

SCA Service Component Architecuture Assembly Model Specification Version 1.00, March 15 2007 SCA Service Component Architecuture Java Component Implementation Specification Version 1.00, 15 February 2007

部品を組み合わせて構築したアプリケーションにおいて、部品のデータを永続化しようとする場合、次のような課題が生じる。即ち、従来の永続化方法を適用しようとすれば、アプリケーションが永続化対象を決定し、それに対して永続化する処理を実装する必要がある。つまり何を永続化するのか、どの記憶装置に対して、どのように永続化するのかをアプリケーション側で実装しなければならない。

また、従来のＳＣＡ仕様では、部品のプロパティの永続化というコンセプトを取り入れていない。従って、ＳＣＡランタイムが動作する装置又はアプリケーションを再起動した場合、部品のプロパティの値は定義ファイルに書かれた初期値に戻り、再起動前の最後に設定した値は失われてしまう。

また、部品側で永続化コードを書くこともできない。部品は複数のアプリケーションから共通に使用され得る。その際、アプリケーション毎に異なる部品インスタンスを使用することはよく行われる。固定された１箇所の記憶場所に部品がそのデータを退避したとすると、データが衝突するため異なるアプリケーションから異なる部品インスタンスデータを永続化させることができない。

この問題を回避する方法として、部品がどのアプリケーションから使われているのかを部品側で識別することも考えられる。そうすれば、部品がアプリケーション毎に記憶場所を分けてデータを退避することも可能である。しかし、それを実現するためには、部品がアプリケーションを識別するためのインタフェースを設けなければならない。

そもそもあらゆるアプリケーションが永続化を必要としている訳ではない。部品側では永続化が必要とされるかどうかは不明であるのに、永続化処理を実装しておかなければならないのは煩わしい。

本発明は、ソフトウェア部品を組み合わせて構築したアプリケーションにおいて、ソフトウェア部品のデータを永続化できる装置及び方法を提供することを目的とする。

本発明は、ソフトウェアとして実装される部品を結合して構成されたアプリケーションを実行する部品結合装置であって、
前記部品を動作させる前に部品結合定義に従って部品を結合する結合手段と、
前記部品のインスタンスのプロパティデータを永続化させるべく保存する保存手段と、
前記部品のインスタンスを作成する時に、保存されたプロパティデータを前記インスタンスに設定する設定手段と、
を備えることを特徴とする。

本発明によれば、ソフトウェア部品を組み合わせて構築したアプリケーションにおいて、ソフトウェア部品のデータを永続化することができる。

また、部品に対して最後に設定した値を、装置もしくはアプリケーションの再起動後に用いることができる。また、異なるアプリケーションが同一部品を使用していた場合でもデータの衝突は発生しない。また、永続化処理のための実装をアプリケーションや部品が行う必要がない。

第１の実施形態における部品結合装置の構成を示すブロック図。 （Ａ）は、第１の実施形態の部品永続化データ関連付けテーブルの例を示す図、（Ｂ）は第２の実施形態の部品永続化データ関連付けテーブルの例を示す図。 部品結合定義の例を示す図。 アプリケーションの実行手順を示すフローチャート。 ドメイン生成手順を示すフローチャート。 サービス取得手順を示すフローチャート。 ハンドラメソッド実行の詳細な手順を示すフローチャート。 インスタンス初期化手順の詳細を示すフローチャート。 第２の実施形態のサービス取得手順を示すフローチャート。 第２の実施形態のハンドラメソッド実行の詳細な手順を示すフローチャート。 第２の実施形態のインスタンス初期化手順の詳細を示すフローチャート。 第３の実施形態のインスタンス終了手順を示すフローチャート。

以下、図面を参照しながら発明を実施するための形態について詳細に説明する。

［第１の実施形態］
図１は、第１の実施形態における部品結合装置の構成を示すブロック図である。図１に示すように、部品結合装置１００には、ＣＰＵ１０１、ＨＤＤ１０２、ネットワークＩ／Ｆ１０３、ＲＯＭ１０４、ＲＡＭ１０５、ＦｌａｓｈＲＯＭ１０６、ディスプレイ１０７、操作部１０８が含まれる。

ＣＰＵ１０１は部品結合装置１００全体を制御し、後述する部品結合処理、保存処理、プロパティ設定処理を実行する。ＨＤＤ１０２はハードディスクドライブであり、不揮発性大容量記憶装置である。ネットワークＩ／Ｆ１０３は部品結合装置１００の外部に存在するネットワーク１５０を接続するインタフェースである。ＲＯＭ１０４には、各種動作プログラムが読み取り可能な形式で格納されている。ＲＡＭ１０５はプログラム動作中の一時的な値の保存に用いる。

ＦｌａｓｈＲＯＭ１０６は、各種設定データファイルを保存しておくための不揮発性のメモリである。尚、不揮発性という性質がＨＤＤ１０２に近いことからＦｌａｓｈＲＯＭ１０６を記憶装置として用いることも可能である。

ディスプレイ１０７は、各種情報をユーザに対して表示する。操作部１０８は具体的にはキーボード、マウス、タッチディスプレイ等で構成され、ユーザが操作を指示するものである。

図１に示すように、ＲＡＭ１０５にはアプリケーション１２０が格納されている。この図１ではアプリケーション実行時の状態を示している。尚、アプリケーション１２０は、最初ＨＤＤ１０２にインストールされていても良い。その場合、アプリケーションを実行する際に、ＣＰＵ１０１がＨＤＤ１０２からアプリケーション１２０を読み出し、ＲＡＭ１０５に格納する。また、図１では、ＲＡＭ１０５の中にアプリケーション１２０が一つだけ存在するが、異なるアプリケーションが共存していても良い。

また、アプリケーション１２０は、１以上のソフトウェア部品（以下、部品）１２１で構成される。部品１２１はプロパティ１２４を含む。プロパティ１２４は、部品１２１が有するデータの一部であり、部品１２１の状態を示すためのデータ、或いは部品１２１を外部から制御するためのデータである。例えば、Ｊａｖａ（登録商標）言語の場合、クラスの中で定義されたフィールドがプロパティとなり得る。プロパティ１２４は型（或いはクラス）及び名前（プロパティ名）を指すものであり、プロパティ値が格納される場所ではない。このプロパティ値が格納されるのは後述するプロパティデータ１３１である。

尚、第１の実施形態では、Ｊａｖａ（登録商標）言語を用いて説明するが、本発明は特定のプログラミング言語に依存したものではなく、Ｊａｖａ（登録商標）言語以外のプログラミング言語を用いても実現可能である。

また、部品１２１には、不図示であるが、ソフトウェアとしての機能を実現するためのプログラムコード、型或いはクラス情報、リソースも含まれる。また、アプリケーション１２０は、それが有する部品１２１の結合方法が記述された部品結合定義１２２を含む。また、部品として提供されるソフトウェア以外のソフトウェア、つまりアプリケーションコード１２３もアプリケーション１２０に含まれる。アプリケーションコード１２３は、部品１２１を利用することにより、所定の機能を提供する。

ＲＡＭ１０５には更に、１以上の部品インスタンス１３０が格納される。この部品インスタンス１３０は、部品１２１がインスタンス化されたものである。各部品インスタンス１３０はプロパティデータ１３１を有する。ここで、プロパティデータ１３１は、上述の部品１２１に含まれるプロパティ１２４に対する実体データ（プロパティ値）である。

ＲＯＭ１０４には、部品結合ランタイム１６０が含まれる。部品結合ランタイム１６０は、ＳＣＡ仕様でのＳＣＡランタイムとして機能し、部品結合定義１２２の解釈や部品インスタンス１３０の生成等の処理を行う。また、部品結合ランタイム１６０はプログラムである。このプログラムをＣＰＵ１０１がＲＯＭ１０４から読み出し実行することにより処理が行われる。

ＨＤＤ１０２には、部品永続化データ１４０と部品永続化データ関連付けテーブル１４１とが格納される。部品永続化データ１４０は、プロパティデータ１３１がＨＤＤ１０２に格納されたものである。プロパティデータ１３１がＨＤＤ１０２に格納されるとき、データは適宜変換される。例えば、部品インスタンス１３０がＪａｖａ（登録商標）言語のオブジェクトインスタンスであれば、一般的なシリアライゼーションを用いた変換方法が利用可能である。また、プロパティデータ１３１をＸＭＬ言語形式に変換するためのデータバインディングも利用可能である。例えば、Ｊａｖａ（登録商標）オブジェクトインスタンスをＸＭＬ言語形式に変換するために、ＪＡＸＢ（Java Architecture for XML Binding）仕様を実装したプログラムが使える。また、Ｊａｖａ（登録商標）以外の言語もデータバインディングのための各種ＡＰＩ（Application Programming Interface）を提供している。

部品永続化データ関連付けテーブル１４１は、アプリケーション１２０、部品１２１、プロパティ１２４、及び部品永続化データ１４０のそれぞれの格納場所を関連付けた関連付けテーブルである。

図２の（Ａ）に、部品永続化データ関連付けテーブル１４１の例を示す。（Ａ）に示す部品永続化データ関連付けテーブル１４１は、アプリケーション列２０１、部品列２０２、プロパティ列２０３、及び永続化データ格納場所列２０４で構成される。この例では、２つのアプリケーション１２０（ＡＰＰ＿ＡとＡＰＰ＿Ｂ）に関連するデータが格納されている。アプリケーションＡＰＰ＿Ａは永続化対象の部品１２１としてＣＯＭＰＯ＿ＡとＣＯＭＰＯ＿Ｂを有する。更に、ＣＯＭＰＯ＿Ａは永続化対象のプロパティ１２４としてＰＲＯＰ＿ＡとＰＲＯＰ＿Ｂを有し、ＣＯＭＰＯ＿Ｂは永続化対象のプロパティ１２４としてＰＲＯＰ＿Ｃを有する。

図２に示す（Ａ）のテーブルの１行を例にとると、アプリケーションＡＰＰ＿Ａ、部品ＣＯＭＰＯ＿Ａ、プロパティＰＲＯＰ＿Ａに対応するプロパティデータ１３１が部品永続化データ１４０に格納される。これと同時に、その格納場所を示すデータが永続化データ格納場所列２０４に格納される。尚、永続化データ格納場所に格納する場所データは格納場所が特定されればどのようなものでも良い。例えば、部品永続化データ１４０がＨＤＤ１０２上の１個のファイルとして存在するならば、そのファイル中のオフセットデータであっても良い。また、部品永続化データ１４０がＨＤＤ１０２上の不図示のデータベースの中に置かれるならば、所望の永続化データがデータベースから取得できるように、場所データがデータベースのキーデータであっても良い。

部品永続化データ関連付けテーブル１４１は、ＣＰＵ１０１による部品結合定義１２２の解析結果に基づいて作成される。図３に、部品永続化データ関連付けテーブル１４１を作成したときの部品結合定義１２２の例を示す。尚、部品結合定義１２２はＳＣＡ仕様に則って記述したものであり、説明のために行番号が付与されているが、本来はＸＭＬ言語形式で記述されるものである。

図３に示す部品結合定義１２２はアプリケーションＡＰＰ＿Ａの部品結合定義であり、部品ＣＯＰＯ＿Ａと部品ＣＯＭＰＯ＿Ｂに関する定義を含む。部品ＣＯＭＰＯ＿Ａはプロパティ１２４として、プロパティＰＲＯＰ＿Ａ、ＰＲＯＰ＿Ｂ、ＰＲＯＰ＿Ｄを含む。このＰＲＯＰ＿Ａ、ＰＲＯＰ＿Ｂ、ＰＲＯＰ＿Ｄは、name属性の値として示されていることから分かるように、これらはプロパティ名を示す。それらのデフォルトのプロパティ値はプロパティ要素のコンテンツとして示される通り、それぞれ、ＡＡＡ、ＢＢＢ、ＤＤＤである。

プロパティＰＲＯＰ＿ＡとＰＲＯＰ＿Ｂに関してはpersistent属性がｔｒｕｅとなっている。このことは、それらのプロパティ１２４が永続化対象であることを示す。尚、部品ＣＯＭＰＯ＿Ｂの記述に関しても上述と同様に解釈される。

以上の構成を有する部品結合装置１００において、アプリケーション１２０を実行する際に、永続化対象である部品１２１のプロパティ１２４を永続化させる処理を説明する。まず、アプリケーション１２０の実行手順を、図４を用いて説明する。尚、動作の主体は明記した場合を除き、制御主体であるＣＰＵ１０１である。但し、ハードウエアとしての動作主体はＣＰＵ１０１であっても、ソフトウェア階層から見た動作主体は様々に変わり得るので、それについては明記する。

最初に、アプリケーションコード１２３がドメインを生成する（Ｓ４０１）。ドメインとはＳＣＡ用語であり、部品結合定義１２２を解釈して得られる、そのアプリケーション１２０における部品結合情報全体を指すものである。アプリケーションコード１２３は、部品結合ランタイム１６０が提供するドメイン生成のためのＡＰＩを呼び出す。

ここで、部品結合ランタイム１６０により実行されるドメイン生成手順を、図５を用いて説明する。まず、部品結合ランタイム１６０はドメインを生成する（Ｓ５０１）。典型的には、ドメインクラスのインスタンスを生成する。次に、部品結合ランタイム１６０はドメインを生成しようとしているアプリケーション１２０を識別するためのアプリケーション識別子を取得する（Ｓ５０２）。

このアプリケーション識別子は、部品結合装置１００が複数のアプリケーションを同時に実行可能なので、どのアプリケーションかを識別するために必要である。このアプリケーション識別子を取得する具体的な方法はいくつか存在する。

一つ目は、部品結合ランタイム１６０が新たな識別子を生成し、解釈しようとしている部品結合定義１２２に生成した識別子を関連付けるというものである。アプリケーション１２０が部品結合定義１２２を一つだけ有するのであれば有効な方法である。この場合、アプリケーション１２０の再起動後に、同じアプリケーション１２０に対して異なるアプリケーション識別子を関連付ける懸念があるが、それは防止できる。解釈しようとしている部品結合定義１２２に既に関連付けられたアプリケーション識別子があるか否かを確認すれば良い。

二つ目は、ドメイン生成ＡＰＩの呼び出し時、或いはその前にアプリケーション１２０からアプリケーション識別子を渡してもらう方法である。アプリケーション１２０が複数の部品結合定義１２２を有する場合も、この方法は有効である。この方法の場合、アプリケーション識別子は任意でも良いが、異なるアプリケーション１２０の間で同じ識別子を使ってしまう心配がある。

上述の同一識別子の使用を防止するためには、例えばＯＳＧｉ（Open Gateway Service Initiative）フレームワークを使用すれば良い。ＯＳＧｉ規格は、複数のソフトウェアモジュールを管理する手法の一つであり、ソフトウェアモジュールをインストール、開始、停止、アンインストールする、いわゆるライフサイクル管理の仕様を定めている。ここで、ソフトウェアモジュールの管理単位はバンドルと呼ばれ、ＯＳＧｉフレームワークは各バンドルに対してバンドルコンテキストを割り当てる。

アプリケーション１２０がバンドルとして実装されていれば、ＯＳＧｉフレームワークがアプリケーション１２０に対してバンドルコンテキストを割り当てることになり、これをアプリケーション識別子として利用することができる。また、バンドルコンテキストの割り当てはアプリケーション１２０の起動時に行われるので、ドメイン生成ＡＰＩの呼び出し時にアプリケーション識別子として使うことに問題はない。

尚、上述した一つ目と二つ目を組み合せることも可能である。アプリケーション１２０からアプリケーション識別子を取得できない場合には一つ目の方法を使えば良い。また、アプリケーション１２０が部品結合定義１２２を一つだけ有する場合、アプリケーション１２０がアプリケーション識別子の作成を行う必要がなくなる。

次に、部品結合ランタイム１６０は部品結合定義１２２を解釈する（Ｓ５０３）。解釈すべき部品結合定義１２２は、ドメイン生成ＡＰＩ呼び出し時、或いはその前にアプリケーション１２０から渡してもらう。また、アプリケーション識別子からアプリケーション１２０を特定し、その中に含まれる部品結合定義１２２を解釈対象と見なす。この解釈は、図３を用いて説明したように行われる。

次に、部品結合ランタイム１６０は生成したドメインの中にアプリケーション識別子と部品結合定義１２２の解釈結果とを格納する（Ｓ５０４）。そして、部品結合ランタイム１６０は部品永続化データ関連付けテーブル１４１にプロパティ解析結果を追加する（Ｓ５０５）。例えば、アプリケーションＡＰＰ＿Ａの部品結合定義１２２を解釈した場合、部品永続化データ関連付けテーブル１４１にアプリケーションＡＰＰ＿Ａに関するデータが存在するか否かに応じて、以下のように処理する。

部品永続化データ関連付けテーブル１４１にアプリケーションＡＰＰ＿Ａに関するデータが存在しなければ、アプリケーションＡＰＰ＿Ａのデータを部品永続化データ関連付けテーブル１４１に追加する。ここでアプリケーションＡＰＰ＿Ａのデータとは、アプリケーションＡＰＰ＿Ａが含む部品１２１と、部品１２１が含むプロパティ１２４のデータとを含む。即ち、アプリケーションＡＰＰ＿Ａが含む、部品ＣＯＭＰＯ＿ＡとＣＯＭＰＯ＿Ｂのデータ、及び部品ＣＯＭＰＯ＿Ａが含むプロパティＰＲＯＰ＿ＡとＰＲＯＰ＿Ｂ、部品ＣＯＭＰＯ＿Ｂが含むプロパティＰＲＯＰ＿Ｃのデータを含む。

一方、部品永続化データ関連付けテーブル１４１にアプリケーションＡＰＰ＿Ａに関するデータが存在すれば、解釈したアプリケーションＡＰＰ＿Ａのデータがテーブル上のデータと一致するか否かを判定する。アプリケーションＡＰＰ＿Ａが更新、再インストールされていた場合、一致しない可能性があるので、それに備える。一致すれば追加する必要はない。一致しなければ、テーブル上のアプリケーションＡＰＰ＿Ａのデータが解釈結果に置き換えられる。

尚、部品永続化データ関連付けテーブル１４１にプロパティ解析結果を追加するのは、永続化対象となっているプロパティ１２４が存在する場合である。部品１２１にプロパティ１２４が存在しても、何れも永続化対象となっていない場合、追加は行わない。

最後に、部品結合ランタイム１６０はドメインへの参照をアプリケーション１２０に返す（Ｓ５０６）。

ここで図４に戻り、ドメイン参照を得たアプリケーションコード１２３はドメイン参照からサービスを取得する（Ｓ４０２）。サービスとは、ＳＣＡ仕様における用語であり、部品１２１が外部に対して公開している、機能のアクセスポイントである。典型的な例で言えば、部品１２１がＪａｖａ（登録商標）クラスとして実現されている場合、部品１２１のクラスが提供する、公開目的のメソッドである。但し、サービスを通じてこのメソッドが呼び出せるからといっても、取得したサービスは部品１２１のインスタンスへの参照そのものではない。これについては、後述するサービス取得手順で更に詳述する。サービス取得は部品結合ランタイム１６０が提供するＡＰＩを通じて行う。

次に、アプリケーションコード１２３は取得したサービスを用いてサービスメソッドを実行する（Ｓ４０３〜Ｓ４０５）。尚、一つのサービスにつき１個以上のメソッドが実行可能であり、サービスメソッドを実行する順序と回数はアプリケーションコード１２３に任されている。そこで、図４では、このサービスメソッドの実行をループで表現したものである。

次に、サービスメソッドの実行が終了すると、最後にアプリケーションコード１２３はドメインをクローズして終了する（Ｓ４０６）。尚、部品結合装置１００が再起動された時も、上述した図４に示すシーケンスが実行される。

次に、部品結合ランタイム１６０によるサービス取得手順を、図６を用いて説明する。上述のＳ４０２で、アプリケーションコード１２３がサービス取得ＡＰＩを呼び出す際にアプリケーションコード１２３はサービスを取得する対象となる部品１２１を指定する。ここでは図３の部品結合定義１２２における部品ＣＯＭＰＯ＿Ａを指定したとする。

部品結合ランタイム１６０は、指定された部品１２１の情報から部品１２１を実装しているクラスの情報を得る（Ｓ６０１）。この例では、部品結合定義１２２における６行目のimplementation.java要素のclass属性が実装クラスを示している。尚、ドメイン生成時に部品結合定義１２２を解釈済みなので、実装クラス情報の取得は簡単に行える。

この実装クラスを用いて部品結合ランタイム１６０は、部品インスタンス１３０を生成する（Ｓ６０２）。ここで、生成した部品インスタンス１３０への参照をドメインに登録しておく。上述のＳ４０２で説明したように、サービス取得ＡＰＩはドメイン参照から呼ばれているので、登録は可能である。このようにしておくと、ドメイン内に存在する部品インスタンス１３０を把握できる。

次に、生成したインスタンスを初期化する（Ｓ６０３）。このインスタンス初期化手順については後で詳細に説明する。

次に、部品結合ランタイム１６０は不図示のハンドラクラスのインスタンスを生成する（Ｓ６０４）。このハンドラクラスとは、動的代理クラスから呼ばれるハンドラメソッドを実装したクラスである。また代理クラスとは、あるクラスの操作（メソッド呼び出し）をする際に仲立ちとなるクラスのことであり、プロキシクラスとも呼ばれる。代理クラスは静的に実装することも、或いは動的に生成することも可能である。Ｊａｖａ（登録商標）言語では、java.lang.reflect.Proxyクラスを用いて動的代理クラスの生成が可能である。

動的生成の場合、あるクラスのインタフェースに基づいて、代理クラスは生成される。この時、代理クラスは当該インタフェース条件を満たす、１個以上のメソッドを備える。つまり、代理クラスは当該インタフェースを実装したものと見なすことができ、当該インタフェースのメソッドの何れも実行可能となる。

次に、生成したハンドラクラスのインスタンスの中に、Ｓ６０２で生成した部品インスタンス１３０への参照を設定する（Ｓ６０５）。次に、生成したハンドラクラスのインスタンスの中に、アプリケーション識別子を設定する（Ｓ６０６）。上述したＳ４０２で、サービス取得ＡＰＩはドメイン参照から呼ばれており、またＳ５０４で、ドメインの中にはアプリケーション識別子が格納されているので、アプリケーション識別子を取得し、これを設定することは可能である。

次に、生成したハンドラクラスのインスタンスの中に部品識別子を設定する（Ｓ６０７）。この部品識別子は、この例では部品ＣＯＭＰＯ＿Ａを識別するための識別子である。部品結合ランタイム１６０は部品結合定義１２２を解釈時に、各部品に対して部品識別子を割り当てる。

尚、上述した、生成したハンドラクラスインスタンス中への部品インスタンス１３０への参照とアプリケーション識別子、部品識別子の設定は、これらをコンストラクタ引数に指定することで、Ｓ６０４と同時に行うことも可能である。

説明の都合上、図２に示す（Ａ）の部品永続化データ関連付けテーブル１４１において、テーブルのセルにＡＰＰ＿ＡやＣＯＭＰＯ＿Ａと言った、アプリケーション名や部品名が格納されている様子を示した。しかし、もちろんアプリケーション名や部品名の代わりにアプリケーション識別子や部品識別子がセルに格納されていても良い。逆に、アプリケーション名や部品名を識別子として利用することも可能である。また、プロパティ１２４についても同様である。

また、Ｓ６０２で作成した部品インスタンス１３０への参照と、アプリケーション識別子、部品識別子の間の関連付け情報をＲＡＭ１０５に格納しておく。このようにしておくことにより、部品インスタンス１３０の参照から、それを使用しているアプリケーション１２０の情報と部品１２１の情報とを後で取得することができる。

次に、部品結合ランタイム１６０はハンドラクラスインスタンスへの参照と部品１２１のインタフェースとを入力とし、動的代理クラスのインスタンスたる代理クラスインスタンスを生成する（Ｓ６０８）。これにより、代理クラスインスタンスからハンドラクラスインスタンスへのアクセスが可能となる。また、代理クラスインスタンスが部品１２１のインタフェースを備える。

最後に、部品結合ランタイム１６０は生成した代理クラスインスタンスへの参照をアプリケーションコード１２３に返す（Ｓ６０９）。従って、アプリケーションコード１２３は、代理クラスインスタンス参照をサービスとして利用することになる。

次に、アプリケーションコード１２３によるプロパティデータ１３１の変更手順を説明する。プロパティデータ１３１を変更するためには、部品１２１が提供する種々の方法が利用できる。例えば、部品インスタンス１３０のフィールドに直接アクセスする方法もある。しかし、典型的には部品１２１が提供するセッターメソッドを用いる。

フィールド直接アクセスの方式では、アプリケーションコード１２３が部品インスタンス１３０を直接扱うことが必要である。第１の実施形態では、アプリケーションコード１２３は部品インスタンス１３０を直接有しておらず、代理クラスインスタンスを通して間接的に部品インスタンス１３０にアクセスしている。従って、プロパティデータ１３１の変更にセッターメソッドを使用する。このセッターメソッドはプロパティ毎に部品１２１が用意する。

プロパティデータ１３１を変更するために、Ｓ４０４においてアプリケーションコード１２３はプロパティデータ１３１変更用のサービスメソッドたるセッターメソッドを呼び出す。ここでは、セッターメソッドが、部品１２１が提供するサービスのインタフェースに含まれていることを仮定している。

プロパティデータ１３１の設定値は、セッターメソッドの引数として渡される。アプリケーションコード１２３は代理クラスインスタンスを有しているので、セッターメソッド呼び出しは代理クラスインスタンスに対するセッターメソッド呼び出しとなる。

代理クラスインスタンスのセッターメソッドは、ハンドラクラスインスタンスのハンドラメソッドを呼び出す。Ｓ６０８で代理クラスインスタンス生成時に、ハンドラクラスインスタンスがハンドラメソッドの中で部品インスタンス１３０のプロパティデータ１３１の変更が行われる。

ここで、ハンドラメソッド実行の詳細な手順を、図７を用いて説明する。ハンドラメソッドは上述のセッターメソッドだけでなく、様々な代理クラスインスタンスメソッドから呼び出され得る。従って、まず、どの代理クラスインスタンスメソッドから呼び出されたのかを判別する（Ｓ７０１）。判別したメソッドがセッターメソッドの一つであれば（Ｓ７０２、Ｙｅｓ）、Ｓ７０３以降を実行する。一方、セッターメソッドでなければ（Ｎｏ）、部品インスタンス１３０における対応メソッドを呼び出す（Ｓ７０８）。代理クラスインスタンスは、部品１２１のインタフェースに基づいて作成されているので、同一名、同一引数を持つ対応メソッドを部品１２１は必ず持つ。

次に、Ｓ７０３では、ハンドラメソッドは現在実行中のアプリケーション識別子を取得する。ハンドラクラスインスタンスにアプリケーション識別子を設定済みなので、これは可能である。次に、ハンドラメソッドは部品識別子を取得する（Ｓ７０４）。ハンドラクラスインスタンスに部品識別子を設定済みなので、これは可能である。

次に、ハンドラメソッドはセッターメソッドが設定対象とするプロパティ１２４が永続化対象か否かを判定する（Ｓ７０５）。ここで、セッターメソッド名から設定対象のプロパティ名を識別する。Ｊａｖａ（登録商標）言語の場合、例えばプロパティ名がpropaであれば、セッターメソッド名がsetPropaになるので、セッターメソッド名の先頭からsetを取り除き、頭文字Ｐを小文字化するか大文字そのままとして、該当するプロパティ１２４を探す。

プロパティ名を識別した後、ハンドラメソッドは、部品永続化データ関連付けテーブル１４１において、取得したアプリケーション識別子と部品識別子に対応する行の中に識別したプロパティ１２４が存在するか否かを判定する。判定の結果、存在すれば永続化対象と見なすことができる。

尚、ハンドラメソッドが部品永続化データ関連付けテーブル１４１を取得する方法はいくつか考えられる。テーブルを管理している部品結合ランタイム１６０に対して取得要求を行う方法が一つある。予めドメインインスタンスに部品永続化データ関連付けテーブル１４１を関連付けておき、アプリケーション識別子からドメインインスタンスを関連付けておき、アプリケーション識別子から部品永続化データ関連付けテーブル１４１を取得する方法もある。

プロパティ１２４が永続化対象であれば、セッターメソッドの引数として渡された設定値を部品永続化データ１４０に書き込み、永続化する（Ｓ７０６）。プロパティ１２４に対して初めての永続化であれば、まだ部品永続化データ関連付けテーブル１４１の永続化データ格納場所列２０４が空欄であるので、書き込みを行った場所の情報を永続化データ格納場所列２０４に格納する。

また、永続化データ格納場所列２０４が空欄でない場合は、そこが前回の書き込み場所を示しているので、可能ならば同じ場所に書き込む。この時、必ず前回とは異なる新たな書き込み場所を見つけ、そこに書き込みを行い、永続化データ格納場所列２０４に格納するようにしても良い。書き込み方法によっては、書き込む容量が前回の書き込んだデータのサイズに制限されてしまう恐れもあるが、必ず新たな場所に書き込む方法だとその心配もない。

また、Ｓ７０５でプロパティ１２４が永続化対象でなければ、Ｓ７０６をスキップし、ハンドラメソッドは、部品インスタンス１３０のセッターメソッドを呼ぶ（Ｓ７０７）。尚、セッターメソッドは、上述した対応するメソッドであるので、これを呼ぶことは可能である。また、ハンドラクラスインスタンスに設定されている部品インスタンス１３０を取得することも容易である。このセッターメソッドによりプロパティデータ１３１の変更がなされる。

次に、Ｓ６０３におけるインスタンス初期化手順の詳細を図８を用いて説明する。尚、この処理は、部品結合ランタイム１６０が初期化対象である部品１２１のそれぞれのプロパティ１２４に対して実行する処理である。従って、個々のプロパティに対するループとなる（Ｓ８０１、Ｓ８０８）。

まず、部品結合ランタイム１６０はアプリケーション識別子を取得する（Ｓ８０２）。Ｓ６０６におけるアプリケーション識別子の取得方法と同様の方法で取得が可能である。次に、部品結合ランタイム１６０は部品識別子を取得する（Ｓ８０３）。これもＳ６０７と同様に可能である。

次に、部品結合ランタイム１６０はプロパティ１２４が永続化対象か否かを判定する（Ｓ８０４）。ここでは、部品結合ランタイム１６０は部品永続化データ関連付けテーブル１４１において、取得したアプリケーション識別子と部品識別子が指す部品の中に、処理対象のプロパティ１２４が存在するか否かを判定する。判定の結果、存在すれば、永続化対象と見なすことができる。

Ｓ８０４でプロパティ１２４が永続化対象であれば、部品結合ランタイム１６０は永続化されたデータが存在するか否かを調べる（Ｓ８０５）。部品永続化データ関連付けテーブル１４１において、処理対象プロパティ１２４に対する永続化データ格納場所列２０４が空欄でなければ、存在すると見なせる。

Ｓ８０５で永続化されたデータが存在する場合、永続化データ格納場所列２０４が示す場所から永続化されたデータを取得する（Ｓ８０６）。そして、取得したデータを用いて部品インスタンス１３０のセッターメソッドを呼び、プロパティデータ１３１を設定する（Ｓ８０７）。この呼び出し対象セッターメソッドは処理対象プロパティ１２４から特定できる。

一方、Ｓ８０４でプロパティ１２４が永続化対象でなければ、部品結合ランタイム１６０は部品結合定義１２２中に処理対象プロパティ１２４のデフォルト値が記述されているか否かを調べる（Ｓ８０９）。ここで、デフォルト値が記述されていれば、部品結合ランタイム１６０はそのデフォルト値を取得する（Ｓ８１０）。そして、取得したデフォルト値でもってＳ８０７を実行する。また、Ｓ８０９でデフォルト値が記述されていなければ、そのプロパティ１２４に対してはセッターメソッドを呼ぶ必要はないので、次のプロパティ１２４の処理に移る。

上述のＳ８０５で永続化されたデータが存在しない場合、Ｓ８０９の処理に移り、上述した処理を行う。この処理は、アプリケーション１２０の初回起動時、プロパティ１２４が永続化対象であるにも関わらず、永続化されたデータが存在しない場合があり得るからである。

第１の実施形態によれば、永続化対象となるプロパティ１２４の指示を部品結合定義１２２で行える。つまり、永続化したいプロパティを選択できる。永続化したいプロパティが部品中の一部のデータだけである場合、全体を永続化するのは記憶領域とＣＰＵの無駄であるので、プロパティを選択できるのは効率的である。

また、部品結合定義１２２を作成するのはアプリケーションの開発者であるが、永続化処理を行うのは部品結合ランタイム１６０であり、アプリケーションコード１２３や部品１２１で永続化のためのコードを実装する必要はない。

尚、第１の実施形態では、部品永続化データ１４０をＨＤＤ１０２に格納したが、これをＦｌａｓｈＲＯＭ１０６に格納しても良い。更に言えば部品永続化データ１４０は部品結合装置１００内に置かなくても良い。例えば、ネットワーク１５０に接続された不図示の記憶装置に格納することも可能である。また部品永続化データ関連付けテーブル１４１に関しても同様である。

また、部品永続化データ関連付けテーブル１４１からデータを削除する処理は説明していないが、アプリケーション１２０をアンインストールする時に実行すれば良い。例えば、アプリケーションＡＰＰ＿Ａをアンインストールした時に、アプリケーションＡＰＰ＿Ａに関する行を削除すれば良い。

［第２の実施形態］
次に、図面を参照しながら本発明に係る第２の実施形態を詳細に説明する。尚、第２の実施形態における部品結合装置の構成は、第１の実施形態で説明した図１に示す部品結合装置１００の構成と同様であり、その説明は省略する。

第１の実施形態では、アプリケーション１２０と部品１２１、プロパティ１２４の組み合わせに永続化データを関連付けた場合を説明した。第２の実施形態では、アプリケーション１２０と部品１２１、部品インスタンス１３０、プロパティ１２４の組み合わせに永続化データを関連付けた場合を説明する。

アプリケーションコード１２３が部品１２１に対する部品インスタンス１３０を１個しか使用しない場合、その１個の部品インスタンス１３０のプロパティデータ１３１を永続化すれば良い。

しかし、アプリケーションコード１２３が部品１２１に対する部品インスタンス１３０を複数個使用する場合、問題が生じる。どの部品インスタンス１３０のプロパティデータ１３１を永続化すべきか、部品インスタンス１３０を初期化する場合に、どの永続化データをどのプロパティデータ１３１に設定すべきか決定できないからである。第２の実施形態はこの問題を解決するものである。

図２に示す（Ｂ）に、第２の実施形態における部品永続化データ関連付けテーブルの例を示す。第１の実施形態における部品永続化データ関連付けテーブル１４１との違いは、インスタンス列２０５が追加されていることである。インスタンス列２０５には、後述する部品インスタンス識別子が格納される。アプリケーションＡＰＰ＿Ａに関する１行目と２行目のデータを見ると、部品列２０２はＣＯＭＰＯ＿Ａ、プロパティ列２０３はＰＲＯＰ＿Ａであり、同じであるが、インスタンス列２０５のデータは、ＩＮＳ＿ＡとＩＮＳ＿Ｂで異なる。部品永続化データ関連付けテーブルが図２の（Ｂ）に示すような構造を持つので、異なった部品インスタンス１３０に対して、異なった永続化データ格納場所を持つことができる。

部品永続化データ関連付けテーブルへのプロパティ解析結果の追加は、Ｓ５０５の処理と同様に、ドメインを生成時に行っても良い。但し、この場合、アプリケーションコード１２３がまだ部品インスタンス識別子を生成していない可能性がある。また、ドメインは複数のサービスから共通に使用され得るものなので、ドメイン生成時に特定の部品インスタンス識別子を指定することはできない。

従って、部品永続化データ関連付けテーブルへのプロパティ解析結果の追加をドメイン生成時に行うのであれば、アプリケーション列２０１、部品列２０２、プロパティ列２０３に対してのみ解析結果を格納することになる。インスタンス列２０５への格納は、後述するサービス取得時に行われる。

但し、この場合も少し問題がある。ドメイン生成時に、部品永続化データ関連付けテーブルにおいて、あるプロパティ１２４に対応する行が一行追加されたとする。サービス取得がなされ、その一行におけるインスタンス列２０５への格納がなされると、同じ部品１２１に対する他のサービス取得時に、インスタンス列２０５のみが空欄となっている行が見つからなくなってしまう。

この問題を回避するためには、同一アプリケーション、同一部品、同一プロパティの行をコピーした新たな行を追加し、そのインスタンス列２０５に対して格納を行う必要がある。例えば、図２に示す（Ｂ）の部品永続化データ関連付けテーブルにおいて部品インスタンスＩＮＳ＿Ａに対する１行目と３行目のデータが存在し、部品インスタンスＩＮＳ＿Ｂに対する２行目と４行目のデータはまだ存在しないものとする。部品インスタンスＩＮＳ＿Ｂに対するデータを部品永続化データ関連付けテーブル１４１Ｂに格納するとき、異なるプロパティ１２４を持つ１行目と３行目が２行目と４行目にそれぞれコピーされる。次に、２行目と４行目のインスタンス列２０５に対して部品インスタンスＩＮＳ＿Ｂの識別子が格納される処理が行われる。

上述した手順でも良いが、サービス取得手順において、ドメイン生成手順で行っていた部品永続化データ関連付けテーブルへのプロパティ行の追加を行っても良い。以下の手順ではそれを行った場合について説明する。

第２の実施形態における部品結合ランタイム１６０によるサービス取得手順を、図９を用いて説明する。Ｓ４０２でアプリケーションコード１２３がサービス取得ＡＰＩを呼び出す時、アプリケーションコード１２３はサービスを取得する対象となる部品１２１を指定すると共に、部品インスタンス１３０を識別するための部品インスタンス識別子を指定する。

アプリケーションコード１２３は取得したサービスの使い方を知っているので、サービスを複数取得する時もその区別はつく。従って、異なるサービス取得呼び出しに対して、異なる部品インスタンス識別子を指定することができる。尚、部品インスタンス識別子の形式は任意である。アプリケーション１２０内で一意であれば良い。

尚、Ｓ９０１〜Ｓ９０７での処理は、第１の実施形態で説明した図６に示すＳ６０１〜Ｓ６０７での処理と同じであり、その説明は省略する。

次に、部品結合ランタイム１６０は、生成したハンドラクラスのインスタンスの中に、サービス取得ＡＰＩ呼び出し時に指定された部品インスタンス識別子を設定する（Ｓ９０８）。

次に、部品結合ランタイム１６０は、アプリケーション名、部品名、部品インスタンス識別子、その部品１２１が有する永続化対象のプロパティ名の組み合わせを、図２に示す（Ｂ）の部品永続化データ関連付けテーブルに追加する（Ｓ９０９）。その部品１２１が有する永続化対象のプロパティの個数分、行が追加される。アプリケーション名はアプリケーション識別子から取得される。部品名は部品識別子から取得される。

図２に示す（Ｂ）の部品永続化データ関連付けテーブルに指定された部品インスタンス識別子を持つ行が既にあれば、Ｓ５０５の処理と同様に、一致確認処理が行われる。また、Ｓ９０２で作成した部品インスタンス１３０への参照と、アプリケーション識別子、部品識別子、部品インスタンス識別子の間の関連付け情報をＲＡＭ１０５に格納しておく。このようにしておけば、部品インスタンス１３０の参照から、それを使用しているアプリケーション１２０の情報と、部品１２１の情報、部品インスタンス識別子情報を後で取得することができる。Ｓ９１０〜Ｓ９１１での処理は、Ｓ６０８〜Ｓ６０９と同様である。

次に、第２の実施形態におけるハンドラメソッド実行の詳細な手順を、図１０を用いて説明する。尚、Ｓ１００１〜Ｓ１００４での処理は、第１の実施形態で説明した図７に示すＳ７０１〜Ｓ７０４での処理と同様である。

次に、ハンドラメソッドは部品インスタンス識別子を取得する（Ｓ１００５）。上述のＳ９０７で、ハンドラクラスインスタンスに部品インスタンス識別子を設定済みなので、これは可能である。

次に、ハンドラメソッドはセッターメソッドが設定対象とするプロパティ１２４に対応するプロパティデータ１３１が永続化対象か否かを判定する（Ｓ１００６）。ここでは、図２に示す（Ｂ）の部品永続化データ関連付けテーブルにおいて、取得したアプリケーション識別子と部品識別子、部品インスタンス識別子に対応する行の中に、識別したプロパティ１２４が存在するか否かを判定する。判定の結果、存在すれば、プロパティ１２４に対応するプロパティデータ１３１を永続化対象と見なすことができる。

Ｓ１００６でプロパティデータ１３１が永続化対象であれば、セッターメソッドの引数として渡された設定値を部品永続化データ１４０に書き込み、永続化する（Ｓ１００７）。そのプロパティデータ１３１に対して初めての永続化であれば、まだ部品永続化データ関連付けテーブルの永続化データ格納場所列２０４が空欄であるので、書き込みを行った場所の情報を永続化データ格納場所列２０４に格納する。また、永続化データ格納場所列２０４が空欄でない場合は、そこが前回の書き込み場所を示しているので、可能であれば同じ場所に書き込む。

一方、Ｓ１００６でプロパティデータ１３１が永続化対象でなければ、Ｓ１００７をスキップする。尚、Ｓ１００８での処理は、Ｓ７０７での処理と同様であり、Ｓ１００９での処理はＳ７０８での処理と同様である。

次に、第２の実施形態におけるインスタンス初期化手順の詳細を、図１１を用いて説明する。尚、Ｓ１１０１〜Ｓ１１０３での処理は、第１の実施形態で説明した図８に示すＳ８０１〜Ｓ８０３と同様である。

次に、部品結合ランタイム１６０は、部品インスタンス識別子を取得する（Ｓ１１０４）。サービス取得ＡＰＩ呼び出しにおいて、部品インスタンス識別子がアプリケーションコード１２３から渡されているので、部品インスタンス識別子の取得は可能である。

部品結合ランタイム１６０は、処理対象のプロパティ１２４に対応するプロパティデータ１３１が永続化対象か否かを判定する（Ｓ１１０５）。部品結合ランタイム１６０は、図２に示す（Ｂ）の部品永続化データ関連付けテーブルにおいて、取得したアプリケーション識別子と部品識別子、部品インスタンス識別子の組み合わせが指す行の中に、処理対象のプロパティ１２４が存在するか否かを判定する。判定の結果、存在すれば、永続化対象と見なすことができる。尚、これ以降のＳ１１０６〜Ｓ１１１１での処理は、Ｓ８０５〜Ｓ８１０と同様である。

［第３の実施形態］
次に、図面を参照しながら本発明に係る第３の実施形態を詳細に説明する。尚、第３の実施形態における部品結合装置の構成は、第１の実施形態で説明した図１に示す部品結合装置１００の構成と同様であり、その説明は省略する。

第１及び第２の実施形態では、セッターメソッド実行時に永続化処理を行う例について述べてきた。第３の実施形態では、インスタンスを終了する処理を実行時に永続化処理を行う例を説明する。

アプリケーション実行手順のＳ４０６のドメインクローズ時に、そのアプリケーションコード１２３が作成した部品インスタンス１３０の終了処理を行う。Ｓ６０２で説明したように、ドメイン内の部品インスタンス１３０の情報が把握されているので、ドメイン内に持つ全ての部品インスタンス１３０に対して、終了処理を呼び出す。ドメインクローズのためのＡＰＩは部品結合ランタイム１６０が提供する。

第３の実施形態におけるインスタンス終了手順を、図１２を用いて説明する。まず部品結合ランタイム１６０は、処理対象の部品インスタンス１３０への参照から、アプリケーション識別子を取得する（Ｓ１２０１）。尚、図９のサービス取得手順で説明したように、部品インスタンス１３０への参照と、アプリケーション識別子の関連付け情報を持っているので取得が可能である。また、部品識別子と部品インスタンス識別子についても同様である。

次に、部品識別子を取得する（Ｓ１２０２）。そして、部品インスタンス識別子を取得する（Ｓ１２０３）。尚、ここでは第２の実施形態のように、部品インスタンス識別子を使用する場合について考えている。また、第１の実施形態のように、使用しない場合は、この処理はスキップされる。

次に、部品インスタンス１３０が有するプロパティデータ１３１を永続化する（Ｓ１２０４）。即ち、ここで取得した識別子を用いて部品永続化データ関連付けテーブル１４１から永続化データ格納場所情報を取得し、その格納場所に部品インスタンス１３０が有するプロパティデータ１３１を格納する。

最後に、部品結合ランタイム１６０は、部品インスタンス１３０の終了処理メソッドを呼び出す（Ｓ１２０５）。これは、部品１２１の終了時に後片付けが必要な場合に、部品１２１が提供するものである。

この第３の実施形態によれば、第１及び第２の実施形態で説明したセッターメソッドでの永続化処理が不要になるので、セッターメソッドの動作が速くなる。また、部品１２１がプロパティ１２４のセッターメソッドを提供しない場合、例えばセッターメソッド以外のメソッドやフィールドアクセスによってプロパティデータ１３１を変更する場合にも、永続化処理が可能である。

［他の実施形態］
また、本発明は、以下の処理を実行することによっても実現される。即ち、上述した実施形態の機能を実現するソフトウェア（プログラム）を、ネットワーク又は各種記憶媒体を介してシステム或いは装置に供給し、そのシステム或いは装置のコンピュータ（又はＣＰＵやＭＰＵ等）がプログラムを読み出して実行する処理である。

Claims (9)

1. ソフトウェアとして実装される部品を結合して構成されたアプリケーションを実行する部品結合装置であって、
   前記部品を動作させる前に部品結合定義に従って部品を結合する結合手段と、
   前記部品のインスタンスのプロパティデータを永続化させるべく保存する保存手段と、
   前記部品のインスタンスを作成する時に、保存されたプロパティデータを前記インスタンスに設定する設定手段と、
   を備えることを特徴とする部品結合装置。
2. 前記保存手段は、前記アプリケーションが前記部品のインスタンスのプロパティデータを変更した時に、前記変更された部品のインスタンスのプロパティデータを、前記部品を使用するアプリケーションに関連付けて保存することを特徴とする請求項１に記載の部品結合装置。
3. 前記保存手段は、前記アプリケーションが前記部品のインスタンスのプロパティデータを変更した時に、前記変更された部品のインスタンスのプロパティデータを、前記部品のインスタンスを作成する時にアプリケーションが指定したインスタンス識別子に関連付けて保存することを特徴とする請求項１に記載の部品結合装置。
4. 前記保存手段は、前記部品のインスタンスを終了した時、前記部品を使用するアプリケーションに関連付けて保存された前記部品のインスタンスのプロパティデータを削除することを特徴とする請求項１に記載の部品結合装置。
5. 前記手段は、前記部品のインスタンスを作成する時に、プロパティデータが保存されている場合、当該プロパティデータを前記インスタンスに設定し、保存されていない場合、前記部品結合定義に記述されているプロパティデータを前記インスタンスに設定することを特徴とする請求項１乃至４の何れか１項に記載の部品結合装置。
6. ソフトウェアとして実装される部品を結合して構成されたアプリケーションを実行する部品結合装置であって、
   前記部品を動作させる前に部品結合定義に従って部品を結合する結合手段と、
   前記部品が提供するサービスにアクセスするための代理のインスタンスを作成する作成手段と、
   前記代理のインスタンスを用いてサービスの実行が要求された場合に、前記サービスが前記部品のインスタンスのプロパティデータを変更するものであるか否かを判別する判別手段と、
   前記要求されたサービスが前記部品のインスタンスのプロパティデータを変更するものであると判別された場合に、前記部品を使用するアプリケーションに関連付けて前記変更された部品のインスタンスのプロパティデータを永続化させるべく保存する保存手段と、
   前記部品のインスタンスを作成する時に、保存されたプロパティデータを前記インスタンスに設定する設定手段と、
   を備えたことを特徴とする部品結合装置。
7. ソフトウェアとして実装される部品を結合して構成されたアプリケーションを実行する部品結合装置の処理方法であって、
   結合手段が、前記部品を動作させる前に部品結合定義に従って部品を結合する結合工程と、
   保存手段が、前記部品のインスタンスのプロパティデータを永続化させるべく保存する保存工程と、
   設定手段が、前記部品のインスタンスを作成する時に、保存されたプロパティデータを前記インスタンスに設定する設定工程と、
   を有することを特徴とする部品結合装置の処理方法。
8. ソフトウェアとして実装される部品を結合して構成されたアプリケーションを実行する部品結合装置の処理方法であって、
   結合手段が、前記部品を動作させる前に部品結合定義に従って部品を結合する結合工程と、
   作成手段が、前記部品が提供するサービスにアクセスするための代理のインスタンスを作成する作成工程と、
   判別手段が、前記代理のインスタンスを用いてサービスの実行が要求された場合に、前記サービスが前記部品のインスタンスのプロパティデータを変更するものであるか否かを判別する判別工程と、
   保存手段が、前記要求されたサービスが前記部品のインスタンスのプロパティデータを変更するものであると判別された場合に、前記部品を使用するアプリケーションに関連付けて前記変更された部品のインスタンスのプロパティデータを永続化させるべく保存する保存工程と、
   設定手段が、前記部品のインスタンスを作成する時に、保存されたプロパティデータを前記インスタンスに設定する設定工程と、
   を有することを特徴とする部品結合装置の処理方法。
9. コンピュータを請求項１乃至６の何れか１項に記載の部品結合装置の各手段として機能させるためのプログラム。

Images