(57)【要約】      （修正有）【課題】コンピュータシステムにおけるアプリケーションソフトウェアの開発をより効率的にする。【解決手段】アプリケーションソフトウェアを構築する複数のコンポーネントの共有すべき情報を管理するコンポーネント間の共有情報管理方法において、共有情報管理手段が、上記複数のコンポーネントのうち処理を実行するコンポーネントから登録要求を受けて、予め設定された種類の情報を当該コンポーネントから受け取り、その取得した情報を共有情報として管理する。【選択図】図１
2006127470.tif 000002
【特許請求の範囲】
【請求項１】
アプリケーションソフトウェアを構築する複数のコンポーネントの共有すべき情報を管理するコンポーネント間の共有情報管理プログラムであって、
コンピュータに、
上記複数のコンポーネントのうち処理を実行するコンポーネントから登録要求を受けて、予め設定された種類の情報を当該コンポーネントから受け取り、その取得した情報を共有情報として管理する共有情報管理手段
として機能させるためのコンポーネント間の共有情報管理プログラム。
【請求項２】
上記共有情報管理手段が、
上記登録要求に応じて上記共有情報の登録処理を制御するセッション制御部と、
上記登録要求してきた上記コンポーネントに対するセッション毎に上記共有情報を保持するセッションデータ保持部と
を有することを特徴とする請求項１に記載のコンポーネント間の共有情報管理プログラム。
【請求項３】
上記セッション制御部は、同一セッション中で連携処理がなされる他のコンポーネントから共有情報取得要求に応じて、上記セッションデータ保持部が保持する同一セッションの共有情報を読み出して上記他のコンポーネントに与えることを特徴とする請求項２に記載のコンポーネント間の共有情報管理プログラム。
【請求項４】
上記共有情報管理手段が、上記複数のコンポーネントのうちいずれかのコンポーネントに例外が生じたときに、指定された１又は複数のコンポーネントに対して例外が発生した旨を通知する例外通知部を有することを特徴とする請求項１〜３のいずれかに記載のコンポーネント間の共有情報管理プログラム。
【請求項５】
上記例外通知部が通知するコンポーネントの指定は、上記各コンポーネントからの登録要求によりなされることを特徴とする請求項４に記載のコンポーネント間の共有情報管理プログラム。
【請求項６】
上記共有情報管理手段が、上記各コンポーネントが構築するアプリケーションの種類に応じて、上記共有情報の登録処理を仲介するアダプタ部を有することを特徴とする請求項１〜５のいずれかに記載のコンポーネント間の共有情報管理プログラム。
【請求項７】
請求項１〜請求項６に記載のコンポーネント間の共有情報管理プログラムを記録したコンピュータに読み取り可能な記録媒体。
【請求項８】
アプリケーションソフトウェアを構築する複数のコンポーネントの共有すべき情報を管理するコンポーネント間の共有情報管理方法であって、
共有情報管理手段が、上記複数のコンポーネントのうち処理を実行するコンポーネントから登録要求を受けて、予め設定された種類の情報を当該コンポーネントから受け取り、その取得した情報を共有情報として管理することを特徴とするコンポーネント間の共有情報管理方法。
【請求項９】
アプリケーションソフトウェアを構築する複数のコンポーネントの共有すべき情報を管理するコンポーネント間の共有情報管理装置であって、
上記複数のコンポーネントのうち処理を実行するコンポーネントから登録要求を受けて、予め設定された種類の情報を当該コンポーネントから受け取り、その取得した情報を共有情報として管理する共有情報管理手段を備えることを特徴とするコンポーネント間の共有情報管理装置。
【請求項１０】
１又は複数の通信網と１又は複数の通信端末との間に介在し、上記通信端末の情報通信を行なう通信装置において、
請求項９に記載のコンポーネント間の共有情報管理装置を備えることを特徴とする通信装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、コンポーネント間の共有情報管理プログラム、方法及び装置、記録媒体、および通信装置に関し、例えば、コンピュータシステムのアプリケーションソフトウェアの効率的な開発を可能とするものである。
【背景技術】
【０００２】
従来、コンピュータシステムにおいてアプリケーションソフトウェア（以下、アプリケーション）を開発、設計する際、複数のコンポーネントを組み合わせることで構築している。このコンポーネントは、アプリケーションの処理単位毎に分割されたものであり、処理単位毎に個別に設計されるものである。
【０００３】
そして、複数のコンポーネント間で処理を連携させる場合、各コンポーネントは、それぞれ独立して設計されるため他のコンポーネントとの間で親密でなく、そのまま実行させても連携させることはできないので、コンポーネント間で個別に所定の取り決めを定義することが必要である。これにより、連携させるコンポーネント間に定義した取り決めに従って各コンポーネント間で接続させ、複数のコンポーネント間を連携させている。
【発明の開示】
【発明が解決しようとする課題】
【０００４】
上述したように、従来のアプリケーション開発においては、複数のコンポーネント間で連携させるための取り決めが必要である。これは、従来のアプリケーション開発では、複数のコンポーネント間の連携性の効率化という概念が充分考慮されていなかったからである。
【０００５】
そのため、複数のコンポーネント間に共通の情報を共有しようとする場合も、コンポーネント間で連携させるたびに、個別の取り決めを設計することが必要である。従って、各コンポーネントを設計する際、相手のコンポーネントとの連携をも考慮して設計する必要があり、連携させるコンポーネントの数が増えると連携のための仕様が複雑になるという問題がある。その結果、アプリケーション開発の生産性が悪くなるという悪影響を与えるおそれもある。
【０００６】
そこで、コンピュータシステムにおけるアプリケーション開発の際に、連携させる複数のコンポーネント間の連携処理を制御することができ、複数のコンポーネント間で共有する情報を管理することができるコンポーネント間の共有情報管理プログラム、方法及び装置、記録媒体、および通信装置を提供する。
【課題を解決するための手段】
【０００７】
かかる課題を解決するために、第１の本発明のコンポーネント間の共有情報管理プログラムは、アプリケーションソフトウェアを構築する複数のコンポーネントの共有すべき情報を管理するコンポーネント間の共有情報管理プログラムであって、コンピュータに、複数のコンポーネントのうち処理を実行するコンポーネントから登録要求を受けて、予め設定された種類の情報を当該コンポーネントから受け取り、その取得した情報を共有情報として管理する共有情報管理手段として機能させるためのものである。
【０００８】
また、第２の本発明の記録媒体は、第１の本発明のコンポーネント間の共有情報管理プログラムを記録したコンピュータに読み取り可能な記録媒体である。
【０００９】
さらに、第３の本発明のコンポーネント間の共有情報管理方法は、アプリケーションソフトウェアを構築する複数のコンポーネントの共有すべき情報を管理するコンポーネント間の共有情報管理方法であって、共有情報管理手段が、複数のコンポーネントのうち処理を実行するコンポーネントから登録要求を受けて、予め設定された種類の情報を当該コンポーネントから受け取り、その取得した情報を共有情報として管理することを特徴とする。
【００１０】
さらにまた、第４の本発明のコンポーネント間の共有情報管理装置は、アプリケーションソフトウェアを構築する複数のコンポーネントの共有すべき情報を管理するコンポーネント間の共有情報管理装置であって、複数のコンポーネントのうち処理を実行するコンポーネントから登録要求を受けて、予め設定された種類の情報を当該コンポーネントから受け取り、その取得した情報を共有情報として管理する共有情報管理手段を備えることを特徴とする。
【００１１】
また、第５の本発明の通信装置は、１又は複数の通信網と１又は複数の通信端末との間に介在し、通信端末の情報通信を行なう通信装置において、第４の本発明の共有情報管理装置を備えることを特徴とする。
【発明の効果】
【００１２】
本発明によれば、アプロケーションソフトウェアを構築する複数のコンポーネント間の処理に必要な部分のうち共通する部分を管理することができるので、より効率的な開発を図ることができ、生産性を高めることができる。
【発明を実施するための最良の形態】
【００１３】
以下、本発明のコンポーネント間の共有情報管理プログラム、コンポーネント間の共有情報管理方法は、コンピュータシステムのアプリケーションソフトウェア開発において、組み込まれる複数のコンポーネント間の処理で必要な部分を共通部分として管理できるようするものである。
【００１４】
（Ａ）第１の実施形態
まず、本実施形態は、複数のコンポーネントを備えるシステムに適用し、各コンポーネント間で共有する情報を管理する場合について説明する。
【００１５】
（Ａ−１）第１の実施形態の構成
図１は、本実施形態に係るシステムの概略的な機能構成を示すと共に、セッション管理手段の内部機能を示す図である。図１に示すように、システム１０は、２つのコンポーネント１、２を有し、セッション管理手段３Ａを備える。
【００１６】
ここで、システム１０は、図示しない制御装置により実行されるソフトウェアであり、例えば、コンピュータに読み取り可能な記録媒体に記録されたり、サーバやコンピュータ等が備える記憶装置に記憶されたりするものである。
【００１７】
コンポーネント１、２は、当該システム１０が提供するアプリケーションを構成する実行機能単位である。図１では、それぞれ処理内容が異なるコンポーネントＡ、Ｂを備え、その数を２つとする場合について説明するが、システム１０が実装するコンポーネントの数は特に限定されない。また、コンポーネント１、２は、同時に複数の処理を実行させることができるものである。
【００１８】
また、コンポーネント１、２は、セッション管理手段３Ａと接続しており、機能実行の際に、セッション管理手段３Ａに処理要求を行なうものである。
【００１９】
セッション管理手段３Ａは、コンポーネント１、２間での連携処理を制御すると共に、コンポーネント１、２が共に処理実行に必要な共有情報（セッションデータ）を保持するものである。図１に示すように、セッション管理手段３Ａは、その機能として、セッション制御部４Ａ、セッションデータ保持部５Ａを有する。
【００２０】
セッション制御部４Ａは、セッション管理手段３Ａの機能を制御するものである。セッション制御部４Ａは、コンポーネント１、２から処理要求を受け取ると、セッションデータ保持部５Ａに対して、コンポーネント１、２が実行しているセッションに係る共有情報を格納するための格納域を確保するように指令するものである。また、セッション制御部４Ａは、コンポーネント１、２が実行しているセッションを一意に識別するためのセッションＩＤを生成する。そして、セッション制御部４Ａは、生成したセッションＩＤをセッション保持部５に与えて、このセッションＩＤを用いて共有情報を管理させるものである。
【００２１】
セッションデータ保持部５Ａは、セッション制御部４Ａから指令を受けて、各セッション毎の格納域を確保し、その確保した格納域に各セッションに係る共有情報を保持するものである。また、セッションデータ保持部５Ａは、セッション制御部４Ａからの要求に応じて、格納している共有情報をセッション制御部４Ａに与えるものである。
【００２２】
（Ａ−２）第１の実施形態の動作
次に、本実施形態に係るシステム１０の動作について図面を参照して説明する。以下では、図２に示すようなシステム構成例１１を挙げて説明する。
【００２３】
図２では、システム１０が、ＳＩＰ（Session  Initiation  Protocol）を採用して音声通信を制御する交換機２（ＳＩＰコンポーネント）と、ＨＴＴＰを採用して予め登録されている利用者及び電話番号の情報（電話帳情報）を提供するＷｅｂ電話帳１（ＨＴＴＰコンポーネント）とを有し、利用者Ａが、Ｗｅｂ電話帳１が提供する電話帳情報から選択した相手（利用者Ｂ）と通話を要求する際の動作を例とする。なお、図２において、６は例えばパーソナルコンピュータ等の利用者Ａの端末、７、８は利用者Ａ及びＢのＶｏＩＰ電話機である。
【００２４】
まず、図２に示す例おいて、セッション制御部４Ａは、コンポーネント１、２からの処理要求を受け付けている。
【００２５】
図２において、利用者Ａの操作により、端末６はＷｅｂ電話帳１に対して予め登録された利用者及びその電話番号の情報を要求する（Ｓ１）。Ｗｅｂ電話帳１は、端末６からの要求に応じて、利用者及びその電話番号の情報を端末６に与え（Ｓ２）、端末６は、利用者及び電話番号の情報を表示する。
【００２６】
利用者及び電話番号の情報が端末６に表示されると、利用者Ａの操作により、所望通話相手（この場合、利用者Ｂとする）に関する情報が選択され、相手（利用者Ｂ）との呼接続の要求がＷｅｂ電話帳１に与えられる（Ｓ３）。
【００２７】
呼接続要求がＷｅｂ電話帳１に与えられると、Ｗｅｂ電話帳１は、利用者１と利用者Ｂとの間で呼を成立させることが必要であるため、セッション制御部４Ａに対して処理要求を与える（Ｓ４、図３のＳ１１）。
【００２８】
セッション制御部４Ａから処理要求が与えられると、セッション制御部４Ａは、Ｗｅｂ電話帳１というコンポーネントと、交換機２というコンポーネントとの間で連携が必要であると判断し、交換機２に対して処理要求を与える（Ｓ５、図３のＳ１２）。これにより、Ｗｅｂ電話帳１と交換機２との間で連携処理を開始させることができる。なお、従来のコンポーネント間で連携させる場合には、Ｗｅｂ電話帳１と交換機２との間に連携させるための取り決めを予め設定することが必要であったが、セッション制御部４Ａを設けることにより、コンポーネント間を接続させるための取り決めを予め設定することなく連携処理をさせることができる。
【００２９】
また、Ｗｅｂ電話帳１から処理要求が与えられると、セッション制御部４Ａは、セッションＩＤを作成すると共に（図３のＳ１３）、セッションデータ保持部５Ａに対して格納域を確保するように指令を与える（Ｓ６、図３のＳ１４）。これにより、各コンポーネント間で共有すべき情報を保持させる記憶領域を用意させることができる。
【００３０】
また、セッションデータ保持部５Ａは、セッション制御部４Ａからの指令を受けて、当該セッションにおいてＷｅｂ電話帳１及び交換機２の間で共有する情報を保持するための格納域を確保する（図３のＳ１５）。
【００３１】
ここで、セッションＩＤは、各コンポーネントからの処理要求のたびにセッション制御部４Ａが作成するものであって、その処理が一意に識別することができる情報である。生成したセッションＩＤは、セッションデータ保持部５Ａで保持される情報に対応付けて管理される。また、セッションＩＤは、各コンポーネントとセッション制御部４Ａとの間のデータ授受の際に必ずデータに付与されるものである。つまり、連携させるコンポーネント１、２は共に、セッション制御部４Ａが生成したセッションＩＤを持つことになる。
【００３２】
これにより、各コンポーネントとセッション制御部４Ａとの間の授受されるデータがどのセッションのものであるかを特定することができ、又セッションＩＤをキーとしてセッションデータ保持部５Ａで保持される情報を特定することができる。
【００３３】
その後、各コンポーネント（Ｗｅｂ電話帳１又は交換機２）は、セッション制御部４Ａに対して共有情報の保持要求をする（図３のＳ１６）。このとき、Ｗｅｂ電話帳１は、セッションＩＤ、共有情報の種類を示す情報名、及び保持させる情報を少なくともセッション制御部４Ａに与える。
【００３４】
ここで、共有情報は、各コンポーネント１、２間で処理をするために必要な情報のうち両者コンポーネント１、２間で共有すべき情報である。この共有情報は、連携すべきコンポーネント間で予め共有すべき情報種類を設定することができる。
【００３５】
各コンポーネント１、２から保持要求が与えられると、セッション制御部４Ａは、各コンポーネント１、２から受け取ったセッションＩＤ、情報名及び情報をセッションデータ保持部５Ａに与えて、これら情報をセッションデータ保持部５Ａに保持させる（図３のＳ１７）。そして、セッション保持部５は、セッションＩＤに基づいて対応する格納域を特定し、その格納域に受け取った情報を共有情報として格納して保持する（図３のＳ１８）。
【００３６】
ここで、セッションデータ保持部５Ａで保持される共有情報の管理例について図４を参照して説明する。
【００３７】
図４に示すように、本実施形態の例において、セッションデータ保持部５Ａが保持する管理項目例は、セッションＩＤ、発呼者電話番号、着呼者電話番号、接続状態情報などが考えられる。
【００３８】
セッションＩＤは、セッション制御部４Ａが生成した識別情報であり、図４では、セッションＩＤの例として「０００１」とした場合である。発呼者及び着呼者電話番号は、図２の例のおける利用者Ａ（発呼者）及び利用者Ｂ（着呼者）の電話番号である。
【００３９】
また、接続状態情報とは、交換機２により呼接続処理の状況情報であり、例えば、Ｗｅｂ電話帳１が、交換機２の呼接続処理による接続状況（例えば、呼出中である旨や接続中である旨）を端末６に表示する機能があるときなどに、Ｗｅｂ電話帳１と交換機２との間で共有すべき情報と考えられる。なお、接続状態情報の管理する方法として、例えば、接続状態情報を示すフラグ（例えば数ビット）の記憶領域を備え、フラグを変化させることで管理する方法が考えられる。
【００４０】
このようにして、セッションデータ保持部５Ａに、コンポーネント１、２間で処理に必要な共有情報を共通に保持させることができる。
【００４１】
次に、セッションデータ保持部５Ａに保持させた情報を読み出す動作について図３を参照して説明する。
【００４２】
各コンポーネント（Ｗｅｂ電話帳１又は交換機２）は、当該コンポーネントが過去に保存した情報、あるいは連携する他のコンポーネントが保存した情報を取得したい場合、各コンポーネント１、２は、情報取得要求をセッション制御部４Ａに与える（Ｓ１９）。
【００４３】
例えば、図３では、交換機２がセッション制御部４Ａに対して情報取得要求を行なう場合とする。このとき、交換機２は情報取得要求と同時にセッションＩＤもセッション制御部４Ａに与える。
【００４４】
情報取得要求が各コンポーネント１、２から与えられると、セッション制御部４Ａは、セッションデータ保持部５Ａに対してセッションＩＤを与え、当該セッションＩＤに対応する情報を読み出すように指令する（Ｓ２０）。
【００４５】
セッションデータ保持部５Ａは、セッション制御部４Ａから与えられたセッションＩＤに対応する格納域に保存されている共有情報を読み出し（Ｓ２１）、その読み出した共有情報を、セッション制御部４Ａを通して（Ｓ２２）、コンポーネントに与える（Ｓ２３）。
【００４６】
このようにして、セッションデータ保持部５Ａは、セッションＩＤに対応させて共有情報を保持し、情報取得の際には、そのセッションＩＤをキーとして保持している情報を読み出すことができる。
【００４７】
なお、この場合、該当する情報が存在しなかった場合、セッションデータ保持部５Ａはセッション制御部４Ａに情報が存在しないことを通知する。そして、セッション制御部４Ａは、コンポーネントＡ１、Ａ２に対して空の情報（例えば、オールゼロ）を返却することで、情報が存在しなかった旨を通知することができる。ここで、空の情報とは、情報が存在しないことを明示する記号である。
【００４８】
最後に、コンポーネント１、２（Ｗｅｂ電話帳１及び交換機２）の連携処理が終了すると、各コンポーネント１、２は、セッション制御部４Ａに終了通知をする（Ｓ２４）。このとき、各コンポーネント１、２は、セッションＩＤも同時にセッション制御部４Ａに与える。
【００４９】
セッション制御部４Ａは、当該セッションに係るすべてのコンポーネント１、２から終了通知が到達したことを確認した場合、当該セッションに係る複数のコンポーネント１、２の連携処理は終了したものと判断し、当該セッションＩＤに対応付けられた共有情報を廃棄するように、セッションデータ保持部５Ａに指令する（Ｓ２５）。そして、セッション制御部４Ａから廃棄指令を受け取ると、セッションデータ保持部５Ａは、当該セッションＩＤに対応する共有情報を廃棄する（Ｓ２６）。これにより、既に処理が終了したセッションに係る共有情報を消去することができるので、必要な共有情報のみをセッションデータ保持部５Ａに保持させることができる。
【００５０】
（Ａ−３）第１の実施形態の効果
以上、本実施形態によれば、セッション制御部４Ａを備えることにより、複数のコンポーネント１、２間の連携処理を制御することができるので、各コンポーネントの設計の際に、連携すべきコンポーネントとの仕組みを考慮することなく設計することができる。その結果、各コンポーネント間の取り決めを予め設定する必要がないので、アプリケーションソフトウェアの開発効率を上げることができる。
【００５１】
（Ｂ）第２の実施形態
本実施形態は、システムのコンポーネントに例外が生じた場合に、その例外を連携する他のコンポーネントに通知する場合の実施形態である。
【００５２】
（Ｂ−１）第２の実施形態の構成
図５は、本実施形態に係るシステムの概略的な機能構成を示すと共に、セッション管理手段の内部機能を示す図である。図５に示すように、本実施形態のシステム２０は、３つのコンポーネント１、２、９と、セッション管理手段３Ｂを備える。
【００５３】
第２の実施形態のシステム２０の構成が、第１の実施形態で説明したシステム１０の構成と異なる点は、セッション管理手段３Ｂの機能構成である。従って、以下では、第１の実施形態で説明していない機能構成について詳細に説明し、第１の実施形態で既に説明した機能構成については省略する。
【００５４】
また、図５では、システム２０がコンポーネント９を新たに有するものとして示すが、これは第１の実施形態と同様に、複数のコンポーネントを有する場合を示すものであり、説明便宜上、３つのコンポーネント１、２、９を図５に示した。
【００５５】
図５において、セッション管理手段３Ｂは、セッション制御部４Ｂ、セッションデータ保持部５Ｂのほかに、例外通知部２１を備える。
【００５６】
セッション制御部４Ｂは、第１の実施形態で説明したセッション制御部４Ａの機能のほかに、各コンポーネント１、２、９からの例外通知要求に応じて、当該セッションを連携する複数のコンポーネント１、２、９のうちいずれかのコンポーネントに例外が生じた場合に、例外通知をすることを登録するものである。このセッション制御部４Ｂによる例外通知の登録する方法は、例えば、セッションデータ保持部５Ｂが保持するセッションＩＤ毎の格納域に、例外通知要求したコンポーネントを記録する方法が考えられる。また、セッション制御部４Ｂは、例外が発生した各コンポーネント１、２、９から例外発生通知を受け取り、セッションデータ保持部５Ｂの記録を参照して、例外通知が必要なコンポーネント１、２、９を特定するものである。
【００５７】
ここで、例外とは、各コンポーネント１、２、９が設定された処理を実行して正しく行なわれずに生じた事象をいい、例えば、交換機による呼接続の不成立（例えば、相手が電話にでなかった場合など）や、プログラムエラーなどが考えられる。
【００５８】
セッションデータ保持部５Ｂは、第１の実施形態で説明したセッションデータ保持部５Ａの機能のほかに、セッション制御部４Ｂの指令に応じて、例外通知を必要とするコンポーネントを記録するものである。
【００５９】
例外通知部２１は、例外を発生したコンポーネントから例外発生通知を受け取った際に、例外通知が必要なコンポーネントに対して例外通知を行なうものである。
【００６０】
（Ｂ−２）第２の実施形態の動作
次に、本実施形態に係るシステム２０の動作について図面を参照して説明する。以下では、図６に示すようなシステム構成例２１を挙げて説明する。また、図７は、システム２１を例とする本実施形態の動作フローチャートである。
【００６１】
図６では、システム２０が、Ｗｅｂ電話帳１（ＨＴＴＰコンポーネント）と、交換機２（ＳＩＰコンポーネント）と、課金サーバ９（ＨＴＴＰコンポーネント）とを有する場合について説明する。なお、図６の構成について、図２に対応する構成についてはそれぞれ対応する符号を示して説明する。
【００６２】
まず、各コンポーネント１、２、９は、セッション制御部４Ｂに対して、それぞれの同一セッションのコンポーネント処理中に、他のコンポーネントの例外の通知を必要とした段階で、例外を通知させるようにする例外通知の登録を要求する（Ｓ３１、図７のＳ４１）。
【００６３】
各コンポーネント１、２、９から例外通知の登録要求が与えられると、セッション制御部４Ｂは、セッションデータ保持部５Ｂに対して例外通知の登録をするよう指令する（Ｓ３２、図７のＳ４２）。そして、セッション制御部４Ｂの指令に応じて、セッションデータ保持部５Ｂは例外通知の対象コンポーネントを登録する（図７のＳ４３）。
【００６４】
このとき、セッションデータ保持部５Ｂで管理する例外通知の登録例について図８を参照して説明する。図８に示す登録例は、図４で説明した管理項目例のほかに、例外通知対象という項目を新たに設けた。これにより、各セッション毎に例外通知を必要とするコンポーネント１、２、９を特定することができる。また、例外通知の対象を登録する際、各コンポーネント１、２、９に識別番号を割り当て、その識別番号を用いて例外通知対象を一覧として登録するようにしてもよい。
【００６５】
その後、例えば、図６及び図７において課金サーバ９に例外が生じたものとする（図７のＳ４４）。この発生した例外は、種々考えられるが、例えば、今回の利用者Ａの通話により、通話請求額が課金サーバ９に預金しておいた預金額を超えた場合とする。
【００６６】
つまり、通話請求額が預金額を超えることで、課金サーバ９に例外が生じる。これにより、課金サーバ９は、例外発生通知を例外通知部２１に与える（Ｓ３３、図７のＳ４５）。
【００６７】
例外発生通知が例外通知部２１に与えられると、セッション制御部４Ｂが、セッションデータ保持部５Ｂに登録されている登録情報を参照して、例外通知を通知する対象を特定し（図７のＳ４６）、例外通知部２１が、特定された通知対象のコンポーネント（Ｗｅｂ電話帳１、交換機２）に対して、例外通知を与える（Ｓ３４、図７のＳ４７）。
【００６８】
このように、組み込まれているコンポーネントが例外を発生したことを他のコンポーネントに通知することにより、一般に親密でない他のコンポーネントに対しても例外を通知することができる。
【００６９】
（Ｂ−３）第２の実施形態の効果
以上、本実施形態によれば、各コンポーネント１、２、９は、例外通知部２１に対してのみ例外の通知を送信及び受け取りの依頼を行なえばよく、どのコンポーネント群から通知されるか、どのコンポーネント群に通知しなければならないかを決めておく必要がない。その分、コードの複雑さ、相互依存性が低くなり、結果として開発効率を上げることができる。
【００７０】
（Ｃ）第３の実施形態
本実施形態は、コンポーネントが本システムを利用して他のコンポーネントと連携処理する際に、連携処理を行なう他のコンポーネントのサービスを呼び出すまでの手続について図面を参照して説明する。
【００７１】
（Ｃ−１）第３の実施形態の構成
図９は、本実施形態に係るシステムの概略的な機能構成を示す機能ブロック図である。
【００７２】
図９に示すように、本実施形態のシステム３０は、２つのコンポーネント１、２を有し、セッション管理手段３Ｃを備える。なお、コンポーネント１、２の種類及び数は特に限定されない。
【００７３】
第３の実施形態のシステム３０では、セッション管理手段３Ｃがコンポーネント１、２からの要求に応じて連携処理の手続を実現するアダプタ部３１を備える。そのため、以下では、アダプタ部３１の機能構成について詳細に説明し、第１及び第２の実施形態で説明した機能構成の詳細については省略する。
【００７４】
図９に示すように、本実施形態のセッション管理手段３Ｃは、アダプタ部３１、セッション制御部４Ｃ、セッションデータ保持部５Ｃ、例外通知部２１Ｃを少なくとも有する。
【００７５】
アダプタ部３１は、コンポーネント１、２からセッション管理手段３Ｃに対して連携処理の要求を受けた場合、若しくは、連携処理の要求に応じて他のコンポーネント２、１を利用する場合に、それらコンポーネント１、２のアプリケーション（及びサービス）の差異を埋めるものである。すなわち、アダプタ部３１は、各コンポーネント１、２のアプリケーションから要求を受け、その要求に応答することができ、また要求に応じたメッセージを作成するものである。
【００７６】
図１０は、アダプタ部３１が実行する機能を示す。図１０に示すように、アダプタ部１０は、ＡＰアダプタ設定機能部３１ａ、サービス設定機能部３１ｂ、サービスディスパッチ機能部３１ｃ、セッションＩＤ取得機能部３１ｄ、セッション管理取得機能部３１ｅ、全アプリケーション名一覧取得機能部３１ｆ、サービス名一覧取得機能部３１ｇ、サーブレット内容取得機能部３１ｈを少なくとも有する。
【００７７】
ＡＰアダプタ設定機能３１ａは、コンポーネント１、２から連携処理の要求を受けると、そのコンポーネント１、２のアプリケーションに対応する専用のアダプタ（ソフトウェア的なインタフェース）を生成し、その生成したアダプタを本実施形態ではＡＰアダプタという。
【００７８】
サービス設定機能部３１ｂは、サービスディスパッチ機能部３１ｃからサービス名が指定された時点で、サービスを実行させるためのサービスインタフェース（ソフトウェア的なインタフェース）を生成する。ここで、サービスとは、あるアプリケーションが他のアプリケーションに対して提供するものをいう。
【００７９】
サービスディスパッチ機能部３１ｃは、ＡＰアダプタを通じて依頼されたサービスのディスパッチ処理を図るものである。
【００８０】
セッションＩＤ取得機能部３１ｄは、あるコンポーネント１、２のアプリケーションから他のサービスにディスパッチ依頼があると、セッション制御部４ＣからセッションＩＤを取得するものである。なお、他のアプリケーションとセッションする際には同一のセッションＩＤを用いて一意に関連づけることが必要である。セッション管理取得機能部３１ｅは、他のアプリケーションとのセッションデータを共有する際に、セッション管理をセッション制御部４Ｃに依頼するものである。
【００８１】
ここで、ＡＰアダプタは、アプリケーションの種類に応じて設定される専用のアダプタであり、アプリケーションがＡＰアダプタ設定機能部３１ａを利用して生成する。
【００８２】
アプリケーションに対応するＡＰアダプタの種類として、例えば、Ｗｅｂアダプタ、ＳＩＰアダプタ、Ｃｏｏｐｅｒａｔｉｏｎアダプタ、統合プラットフォーム対応アダプタ、フロントエンド・ポータル開発プラットフォーム対応アダプタなどがある。
【００８３】
Ｗｅｂアダプタは、例えば、ＨＴＴＰコンポーネント１のＷｅｂアプリケーションからの要求により生成されるＷｅｂアプリケーション対応のアダプタである。
【００８４】
ＳＩＰアダプタは、例えば、ＳＩＰコンポーネントからの要求によって生成されるＳＩＰアダプタ対応のアダプタである。
【００８５】
Ｃｏｏｐｅｒａｔｉｏｎアダプタは、セッション管理手段３Ｃが提供する所定のアプリケーションに専用のアダプタである。
【００８６】
統合プラットフォーム対応アダプタは、ビジネスプロセス管理・アプリケーション統合のプラットフォームに対応するアダプタである。
【００８７】
フロントエンド・ポータル開発プラットフォーム対応アダプタは、フロントエンド・ポータル開発するプラットフォームに対応するアダプタである。
【００８８】
また、これらのＡＰアダプタは、アダプタ部３１が実行する機能（基本機能）のほかに、対応するアプリケーション毎に特有の機能を設けるようにしてもよい。
【００８９】
例えば、上記Ｗｅｂアダプタは、上述したアダプタ部３１の機能のほかに、Ｗｅｂアプリケーションから共有情報を管理するセッションの要求があった場合に、Ｗｅｂアプリケーションからのリクエスト（例えばＨｔｔｐＳｅｒｖｌｅｔＲｅｑｕｅｓｔ）の属性にセッションＩＤをセットするセッション・トラッキング機能や、例えばロードバランサ等を使って複数のサーバによる処理の負荷分散を行なう場合に、同じコンテキストの処理（すなわち同じセッションＩＤを持つ処理）を常に同じサーバに対して振り分けるロードバランス機能等を設けるようにしてもよい。
【００９０】
ここで、セッション・トラッキング機能の動作例を説明する。
【００９１】
（ａ）まず、Ｗｅｂアプリケーションのリクエスト（例えばＨｔｔｐＳｅｒｖｌｅｔＲｅｑｕｅｓｔ）からセッションＩＤを探索する。
【００９２】
この探索方法例として、例えば、ＣｏｏｋｉｅからセッションＩＤを検出する。ここで、セッションＩＤが検出できれば終了する。
【００９３】
Ｃｏｏｋｉｅになければ、リクエストＵＲＬのクエリ・ストリング部からセッションＩＤを検出する。ここで、セッションＩＤが検出できれば終了する。
【００９４】
リクエストＵＲＬにもなければ、リクエスト・パラメータからセッションＩＤを検出する。ここで、セッションＩＤが検出できれば終了する。
【００９５】
そして、これらの部分からセッションＩＤを検出できない場合には、新たなセッションＩＤを生成させるようにする。
【００９６】
（ｂ）次に、リクエストのリクエスト属性にセッションＩＤをセットする。これにより、ＷｅｂアダプタはこのセッションＩＤを利用することができる。
【００９７】
（ｃ）そして、レスポンス（例えばＨｔｔｐＳｅｒｖｌｅｔＲｅｓｐｏｎｓｅ）に、セッションＩＤをセットする
【００９８】
このレスポンスにセッションＩＤをセットする方法例は、例えば、ＣｏｏｋｉｅからセッションＩＤを検出した場合には、何もしない。すなわち、Ｃｏｏｋｉｅによるセッションのトラッキングを行なうようにする。
【００９９】
リクエストＵＲＬのクエリ・ストリング部からセッションＩＤを検出した場合には、セッションＩＤのＵＲＬ  Ｒｅｗｒｉｔｉｎｇ機能を持つＨｔｔｐＳｅｒｖｌｅｔＲｅｓｐｏｎｓｅラッパをレスポンスに利用してセットする。
【０１００】
セッションＩＤが検出できなかった場合には、Ｃｏｏｋｉｅ、ＵＲＬ  Ｒｅｗｒｉｔｉｎｇ機能の両方を利用してセットする。
【０１０１】
このように、セッション管理手段３Ｃ側のアダプタ部３１がこれらの機能を備えることにより、Ｗｅｂアプリケーション側がトラッキングできない環境でもトラッキングを行なうことができる。
【０１０２】
また、Ｗｅｂアダプタのロードバランシング機能の動作例について説明する。例えば、ロードバランサがＨＴＴＰリクエストを振り分ける場合、次のような順序で振り分け先を決定する。
【０１０３】
（ａ）すでにＨＴＴＰセッションが開始されている場合は、リクエストヘッダに含まれているＨＴＴＰセッションＩＤに基づいて振り分け先を決定する。
【０１０４】
（ｂ）すでに共有情報を共有するセッションが開始されている場合は、リクエストヘッダに含まれているセッションＩＤに基づいて振り分け先を決定する。
【０１０５】
（ｃ）ロードバランサの判断（例えば、ランダム又はラウンドロビン等）によって振り分け先を決定する。
【０１０６】
（Ｃ−２）第３の実施形態の動作
次に、本実施形態のシステム３０の動作について図面を参照して説明する。図１１は、本実施形態のシステム３０の構成例を挙げて説明する。図１１に示す例では、アプリケーション１ａがセッション管理手段３Ｃを利用してアプリケーション２ａのサービスにディスパッチする場合を示す。
【０１０７】
また、図１２及び図１３は、本システム３０におけるディスパッチ処理のシーケンス図である。なお、図１１におけるベースアダプタ３１１は、アダプタ部３１の各種機能が実装されたパッケージである。
【０１０８】
まず、図１２において、アプリケーション１ａはセッション管理手段３Ｃに対して処理要求する。このとき、アプリケーション１ａが処理要求を行なうと、ＡＰアダプタ設定機能部３１ａにより当該アプリケーション１ａに対応する専用のＡＰアダプタ３１２が生成される（Ｓ６１及びＳ６２）。
【０１０９】
ＡＰアダプタ３１２が生成されると、アプリケーション１ａは、ＡＰアダプタ３１２をインタフェースとして利用し、セッション管理に必要なセッションＩＤを取得する（Ｓ６３）。なお、セッションＩＤ作成に係る動作は第１の実施形態で説明した動作に対応する。
【０１１０】
セッションＩＤが作成されると、アプリケーション１ａは、アプリケーション２ａとの連携処理に係る共有情報の保持要求をＡＰアダプタ３１２を介してセッション制御部４ｃに行なう（Ｓ６４）。このとき、アプリケーション１ａはセッションＩＤを含むリクエストをＡＰアダプタ３１２に与え、またＡＰアダプタ３１２はセッションＩＤとアプリケーション１ａのアプリケーション名を与える。
【０１１１】
そして、セッション制御部４Ｃでは、第１の実施形態と同様にして、セッションＩＤと対応付けた格納域が確保され、その後、アプリケーション１ａからの要求に応じて連携処理に係る共有情報の格納や読み出しがなされる（Ｓ６５）。
【０１１２】
また、アプリケーション１ａは、第２の実施形態と同様にして、同一セッションの処理中に生じた例外を通知するよう例外通知の登録要求を行なう（Ｓ６６）。
【０１１３】
アプリケーション１ａは、ディスパッチ先のサービスで必要なパラメタ・マップを作成する（Ｓ６７）。ここで、パラメタ・マップは、他のアプリケーション２ａとの間で情報を共有する場合、その共有情報を他のアプリケーションに渡すために必要な情報である。
【０１１４】
次に、アプリケーション１ａは、ＡＰアダプタ３１２に対して他のアプリケーション２ａのサービスへディスパッチを要求する（Ｓ６８、図１１のＳ５１）。このとき、アプリケーション１ａは、セッションＩＤ、アプリケーション名、サービス名及びサービスに必要なパラメタをＡＰアダプタ３１２に与える。
【０１１５】
アプリケーション１ａからの要求を受けると、ＡＰアダプタ３１２は、サービスディスパッチ機能部３１ｃに対してディスパッチ処理を依頼する（Ｓ６９、図１１のＳ５２）。このとき、ＡＰアダプタ３１２は、セッションＩＤ、アプリケーション名、サービス名及びサービスに必要なパラメタをサービスディスパッチ機能部３１ｃに与える。
【０１１６】
続いて、図１３を参照してアプリケーション２ａのサービスを実行するまでの動作を説明する。
【０１１７】
図１２のＳ６９において、ディスパッチ処理の依頼を受けると、サービスディスパッチ機能部３１ｃはディスパッチ処理が要求されたアプリケーション名をＡＰアダプタ設定機能部３１ａに与える（Ｓ７１）。
【０１１８】
そして、ＡＰアダプタ機能部３１ａによりサービスを提供するアプリケーション２ａに係るＡＰアダプタ３１３が生成される（Ｓ７２）。
【０１１９】
ＡＰアダプタ３１３が生成されると、サービスディスパッチ機能部３１ｃは、ＡＰアダプタ３１３に対してサービスの実行処理を依頼をする（Ｓ７３、図１１のＳ５３）。このとき、サービスディスパッチ機能部３１ｃは、セッションＩＤ、サービス名及びパラメタをＡＰアダプタ３１３に与える。
【０１２０】
サービスディスパッチ機能部３１ｃからサービス実行処理の依頼を受けると、ＡＰアダプタ３１３は、実際のサービスが実行される前に、サービスに必要な必須パラメタをチェックする（Ｓ７４）。すなわち、予め設けられた設定ファイルに登録されているサービスのパラメタのうち必須であるパラメタがサービス実行時に渡されたパラメタ・マップにセットされているかどうかをチェックする。なお、必須パラメタがセットされていない場合にはサービス実行時に例外を発生させるようにしても良い。
【０１２１】
ＡＰアダプタ３１３は、アプリケーション名とサービス名とをサービス設定機能部３１ｂに与え（Ｓ７５）、サービス設定機能部３１ｂはサービスインタフェース３１４を生成する（Ｓ７６）。
【０１２２】
サービスインタフェース３１４が生成すると、ＡＰアダプタ３１３は、サー日の実行処理をサービスインタフェース３１４に依頼する（Ｓ７７、図１１）。
【０１２３】
（Ｃ−３）第３の実施形態の効果
以上のように、本実施形態によれば、第１及び第２の実施形態と同様の効果を得ることができる。
【０１２４】
（Ｄ）他の実施形態
（Ｄ−１）上述したように、本発明のコンポーネント間の共有情報管理プログラム、コンポーネント間の共有情報管理方法は、コンピュータシステムのアプリケーション開発の際に適用するものである。
【０１２５】
従って、第１〜第３の実施形態では、ＳＩＰコンポーネントとＨＴＴＰコンポーネントとの間で連携するシステムに適用した場合について説明したが、これらに限定されず、アプリケーション開発全般に広く適用できる。
【０１２６】
（Ｄ−２）第１〜第３の実施形態で説明したシステム１０及び２０は、種々の装置内に組み込む事ができるが、例えば、ＳＩＰコンポーネントとＨＴＴＰコンポーネントを有するＰＢＸ装置に搭載し、ＳＩＰコンポーネントとＨＴＴＰコンポーネントとの連携処理の際に、ＰＢＸ装置が共有情報を管理させるようにしてもよい。勿論、ＰＢＸ装置に限定されず、収容端末の情報通信を行なう通信装置に広く適用可能である。
【図面の簡単な説明】
【０１２７】
【図１】第１の実施形態のシステムの機能構成を示す図である。
【図２】第１の実施形態のセッション管理手段の動作を説明するためのシステム例を示す図である。
【図３】第１の実施形態のセッション管理手段の動作を説明するためのフローチャートである。
【図４】第１の実施形態のセッションデータ保持部の管理項目例である。
【図５】第２の実施形態のシステムの機能構成を示す図である。
【図６】第２の実施形態のセッション管理手段の動作を説明するためのシステム例を示す図である。
【図７】第２の実施形態のセッション管理手段の動作を説明するためのフローチャートである。
【図８】第２の実施形態のセッションデータ保持部の管理項目例である。
【図９】第３の実施形態のシステムの機能構成を示す図である。
【図１０】第３の実施形態のアダプタ部の機能構成を示す図である。
【図１１】第３の実施形態のセッション管理手段の動作を説明するためのシステム例を示す図である。
【図１２】第３の実施形態のセッション管理手段の動作を説明するためのフローチャートである。
【図１３】第３の実施形態のセッション管理手段の動作を説明するためのフローチャートである。
【符号の説明】
【０１２８】
１０、２０、３０…システム、１…コンポーネントＡ、２…コンポーネントＢ、
９…コンポーネントＣ、３（３Ａ、３Ｂ、３Ｃ）…セッション管理手段、
４（４Ａ、４Ｂ、４Ｃ）・・・セッション制御部、
５（５Ａ、５Ｂ、５Ｃ）…セッションデータ保持部、２１…例外通知部、３１…アダプタ部。
【図１】
2006127470.tif 000003
【図２】
2006127470.tif 000004
【図３】
2006127470.tif 000005
【図４】
2006127470.tif 000006
【図５】
2006127470.tif 000007
【図６】
2006127470.tif 000008
【図７】
2006127470.tif 000009
【図８】
2006127470.tif 000010
【図９】
2006127470.tif 000011
【図１０】
2006127470.tif 000012
【図１１】
2006127470.tif 000013
【図１２】
2006127470.tif 000014
【図１３】
2006127470.tif 000015