(57)【要約】【課題】分散ネットワーク環境を用いたソフトウェア開発において、プログラム間のインタフェースの複雑化（ストーブパイプ構造化現象）を抑え、システムの開発効率及び再利用性を向上させる。【解決手段】サーバとクライアントとの間のインタフェースの粒度を大きくしてインタフェースの数を低減する。さらに、サーバは、サーバ自身が公開する役割に基づいて、クライアントに依存することなく、サーバ主導でインタフェース定義を行う。このインタフェースは、特定のクライアント用に用意されるものではなく、すべてのクライアントに対するインタフェースであり、プログラムが新規追加される場合などにおいて、新規追加プログラムも、このインタフェースを利用することによって、インタフェース増加数を抑制できるようにする。また、例えば、インタフェース粒度を、１業務処理（プロトコルシーケンス）内の複数のプロセスを１つのインタフェースとする。【選択図】図１
2008234535.tif 000002
【特許請求の範囲】
【請求項１】
分散ネットワーク環境を前提とするソフトウェアシステムのプログラム間連携の仕組みであって、
クライアントとサーバとの間のインタフェースの粒度を大きくして前記インタフェースの数を低減するとともに、サーバ主導で前記サーバの役割に基づいてインタフェース定義を行うプログラムインタフェースフレームワーク実現方法。
【請求項２】
前記クライアントと前記サーバとの間における複数の非同期メッセージの通信を含む複数のプログラム呼び出し手順をまとめて、１つの前記インタフェースとして定義する請求項１に記載のプログラムインタフェースフレームワーク実現方法。
【請求項３】
１業務処理単位に含まれる前記複数のプログラム呼び出し手順をまとめて、１つの前記インタフェースとして定義する請求項２に記載のプログラムインタフェースフレームワーク実現方法。
【請求項４】
プログラムインタフェース構造でトランザクションの定義を行う請求項１から３のいずれか１つに記載のプログラムインタフェースフレームワーク実現方法。
【請求項５】
前記クライアントは、プロトコルシーケンス上の呼び出し口として機能するＡＰＩが提供されるとともに、前記呼び出し口の応答を受ける戻り口として機能するイベントハンドラＡＰＩが提供され、
前記サーバは、前記クライアント側の前記呼び出し口からの要求を受ける要求受け付け口として機能するＡＰＩが提供されるとともに、前記要求受け付け口で受けた前記要求に対して応答を行う応答口としてイベントハンドラＡＰＩが提供される請求項１から４のいずれか１つに記載のプログラムインタフェースフレームワーク実現方法。
【請求項６】
前記クライアント及び前記サーバに対して、実装を必須とする手続きに関しては、具体的な実装を派生クラスに任せる純粋仮想関数によって明示し、実装を任意とする手続きに関しては、仮想関数によって明示するとともに前記仮想関数に関するデフォルト実装を提供する請求項５に記載のプログラムインタフェースフレームワーク実現方法。
【請求項７】
前記インタフェースの定義に基づいて、前記クライアント用のスタブ及び前記サーバ用のスケルトンが自動生成される請求項１から６のいずれか１つに記載のプログラムインタフェースフレームワーク実現方法。
【請求項８】
前記クライアント用の前記スタブと前記サーバ用の前記スケルトンとの間の通信方式を隠蔽して任意の通信方式を採用する請求項７に記載のプログラムインタフェースフレームワーク実現方法。
【請求項９】
前記クライアントによって前記インタフェースの呼び出し処理が行われた場合、所定のタスクアロケータが、前記呼び出し処理に応じたビヘイビアを読み出して、読み出された前記ビヘイビアを実行するための規約を前記インタフェースに動的に設定する請求項１から８のいずれか１つに記載のプログラムインタフェースフレームワーク実現方法。
【請求項１０】
所定の状態マシンが、動的に設定された前記ビヘイビアを把握することによって、前記クライアント及び前記サーバの状態を管理する請求項９に記載のプログラムインタフェースフレームワーク実現方法。
【請求項１１】
分散ネットワーク環境を前提とし、クライアントとサーバとの間における複数の非同期メッセージの通信を含む複数のプログラム呼び出し手順をまとめて、サーバ主導で前記サーバの役割に基づいて１つのインタフェースとして定義が行われているソフトウェアシステムにおけるインタフェース動的割り当て方法であって、
前記クライアントによって前記インタフェースの呼び出し処理が行われた場合、所定のタスクアロケータが、前記呼び出し処理に応じたビヘイビアを読み出して、読み出された前記ビヘイビアを実行するための規約を前記インタフェースに動的に設定するインタフェース動的割り当て方法。
【請求項１２】
所定の状態マシンが、動的に設定された前記ビヘイビアを把握することによって、前記クライアント及び前記サーバの状態を管理する請求項１１に記載のインタフェース動的割り当て方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、分散ネットワーク環境を前提とするソフトウェアシステムのプログラミング技術に係るプログラムインタフェースフレームワーク実現方法及びインタフェース動的割り当て方法に関し、特に、一般のネットワーク環境上で駆動するソフトウェアシステムのためのプログラミング技術（ネットワークプログラミング技術）、及び上記のプログラムの保守、管理の向上や、プログラムの再利用性の向上に係るプログラム保守性向上技術に関する。
【背景技術】
【０００２】
（エージェント指向技術）
エージェント指向技術は、プログラムの振る舞いの特性として、分散性、協調性、自律性、擬人性、適応性(知的性)、移動性のいずれかを備えたソフトウェア開発アプローチのことである。
【０００３】
（状態マシン）
また、状態マシンとは、プログラムモジュールの内部構成が状態遷移型で実現（実装）され、プログラムは自分のプログラム状態を掌握しながら、任意状態に対する適切なアクション（振る舞い）を発動させることができるものである。なお、ＵＭＬ（Unified Modeling Language）仕様で状態マシン型のプログラムを表記することが可能である。
【０００４】
（ＣＯＲＢＡ−ＩＤＬ）
また、ＣＯＲＢＡ（Common Object Request Broker Architecture）−ＩＤＬ（Interface Definition Language）は、分散ネットワーク上の異種システム間の通信言語であり、オブジェクトのインタフェース（Ｉ／Ｆ）定義からプログラム実装まで、インタフェース仕様の一貫性を提供する仕組み（ＭＤＡ：Model Driven Architecture）を持ったものである。
【０００５】
ただし、これはオブジェクト単体に限ったものであり、クライアント・サーバ間の１業務処理が複数のオブジェクトにまたがってインタラクションする場合、プロトコルシーケンス的にもオブジェクト間をまたがることになる。なお、ＣＯＲＢＡ−ＩＤＬ及びＭＤＡでは、このオブジェクト間をまたがった依存関係を明示する仕組みは実現されていない。
【０００６】
（手続き型インタフェース）
また、構造化設計手法、オブジェクト指向技術設計手法、分散オブジェクト指向技術設計手法などの従来のソフトウェア開発アプローチは、マルチプロセス（タスク）プログラミングを実装することが可能である。こうしたソフトウェア開発アプローチでは、マルチプロセスプログラミングを実施する際、クライアント・サーバ間のデータ通信（情報処理）に非同期メッセージ通信が使用されることがほとんどである。また、ほとんどの場合、この非同期メッセージ通信の手法として、手続き型インタフェースが採用される。
【０００７】
上記のようなソフトウェア開発アプローチでは、大規模ソフトウェアなどのシステム拡張として、機能追加するなどのバージョンアップが施行される。この際、追加する機能などの能力は新規追加プログラムとして実装され、既存プログラム群と連携することで処理実行能力が装備される。このとき、新規追加プログラムは既存プログラム群にインタフェースを提供し、既存プログラムは、このインタフェースを呼び出すようにプログラムロジックが改造される。また、新規追加プログラムがインタフェースを提供する際には、インタフェース定義が行なわれる。このインタフェース定義では、新規追加プログラム側が各既存プログラムに向けて外部インタフェースを定義し、これを提供することが通例である。
【０００８】
例えば、図６に図示されているように、従来の手続き型インタフェースは、非同期メッセージ通信を最小単位とする手続きフェーズが複数組み合わされて構成され、各手続きフェーズの手順を追って、手続きインタフェースが呼び出される必要がある。なお、従来のソフトウェア開発アプローチでは、例えば、非同期メッセージ単位でプログラムを分散化して、インタフェースを用意する方法が取られる。
【０００９】
図６に図示されているシーケンスチャートでは、手続きフェーズは、例えば１往復の非同期メッセージ通信によって構成されている。なお、図６には、前（準備）処理の手続きフェーズ、本処理の手続きフェーズ、後（片付け）処理の手続きフェーズの３段階の手続きフェーズが図示されている。一例として、図６に図示されているシーケンスチャートをクライアント（ホテルの予約を行うエンドユーザ）がサーバ（ホテル予約管理サーバ）に対してホテルの宿泊を予約するホテル予約シーケンスとみなした場合、前処理の手続きフェーズ、本処理の手続きフェーズ、後処理の手続きフェーズのそれぞれをホテル予約に係る典型的な業務処理に対応させて、空室のチェックを行う予約受け付けフェーズ、顧客の個人情報入力及び部屋の仮予約を行う予約入力フェーズ、決済及び部屋の本予約を行う予約完了フェーズとみなすことができる。
【００１０】
例えば、予約受け付けフェーズでは、エンドユーザがホテルの予約サイト（サーバ）にアクセスして、予約に必要な情報を取得する。また、予約入力フェーズでは、予約サイト側が、エンドユーザの条件や空室をチェックをして、空室があればその部屋を仮予約する。また、予約完了フェーズでは、予約サイト側が、決済方法の確認を行うとともに部屋の本予約を実行して、部屋の予約が完了となる。
【発明の開示】
【発明が解決しようとする課題】
【００１１】
（ストーブパイプ構造化現象）
しかしながら、従来の手続き型インタフェースを採用した場合、機能追加するなどのバージョンアップを続けていくうちに、プログラム間の依存関係（インタフェース）が複雑化していく傾向がある。このような傾向は、ストーブパイプ構造化現象（若しくはスパゲッティ構造化現象）と呼ばれる。
【００１２】
例えば、図６のホテル予約シーケンスにおいて、新たにクレジットカードによる決済機能を追加する場合を考える。この場合、例えば、予約入力フェーズと予約完了フェーズとの間に複数の非同期メッセージ通信を含むクレジット決済フェーズが追加される必要があり、その結果、増加する非同期メッセージ通信の分だけのインタフェースが新たに追加、定義されることになる。
【００１３】
また、図７は、従来の技術において発生するストーブパイプ構造化現象の一例を模式的に示す図である。図７に図示されているように、例えば、既存プログラムＡ〜Ｃが存在するシステムにおいて、新規追加プログラムＤが実装される場合、新規追加プログラムＤは既存プログラムＡ〜Ｃのそれぞれに対してインタフェースを提供し、各既存プログラムＡ〜Ｃは、このインタフェースを呼び出すようにプログラムロジックが改造される。その結果、このシステムでは、新規追加プログラムＤの実装によって、各既存プログラムＡ〜Ｃの数だけインタフェースが増加し、各プログラムの依存関係が複雑化してしまうことになる。なお、１システムにＮ個のプログラムが存在する場合には、最悪の場合、インタフェース数はＮ（Ｎ−１）となってしまう可能性がある。
【００１４】
ストーブパイプ構造化現象が発生した状況下では、
・冗長的にメッセージパッシングする回数が増加するという課題（第１の課題）
・メッセージ転送コストが高くなるという課題（第２の課題）
・インタフェース保守コストが高くなるという課題（第３の課題）
・インタフェース再利用性が低くなるという課題（第４の課題）
・システム全体の開発効率が低下するという課題（第５の課題）
などの弊害が発生する。そして、最悪の場合には、システム拡張性が失われ、システムは現状以上の拡張が不可能となって終焉を迎えてしまうことになる。
【００１５】
（第１の課題：冗長的にメッセージパッシングする回数が増加するという課題）
従来、再利用性を高める１つの手段として、インタフェースを抽象化するのではなく、汎用的でかつ普遍である単位（再利用性が保つことができる単位）にするために、インタフェースの粒度を細かくする手法（最小化）が採用されてきた。しかしながら、インタフェースの再利用性を高めるつもりでインタフェースの粒度（単位）を冗長的に細かくする結果、この冗長性の影響で、本質的な情報処理の単位である１業務処理のプロトコルシーケンスが複数手続き手順になってしまい、メッセージパッシング回数が増加してしまうということがある。
【００１６】
（第２の課題：メッセージ転送コストが高くなるという課題）
システムがマルチプロセス（タスク）プログラムの場合には、例えば、プログラム間のインタフェースに非同期通信インタフェースを採用する手段が採用される。しかしながら、ストーブパイプ構造化現象が発生しているシステムは、多数のインタフェースを所有し、これらのインタフェースが頻繁にメッセージ通信を行う場合には、メッセージ通信におけるトラフィックジャムが発生し、メッセージ転送コストが高くなる。なお、上記のトラフィックジャムとは、ネットワークプログラムにおける通信過多のことであり、通信回線のデータ転送キャパシティを実データ転送量が超える（つまりデータ転送率が１００％を超える）状況のことである。この状況となった場合、システム内の各プログラムはＣＰＵ（Central Processing Unit：中央演算処理装置）パフォーマンスを十分に使用できない状況となり、システムのトータル処理速度が低下する。また、メッセージパッシング回数が多くなった場合に、メッセージ転送コストが高くなる課題が特に顕著となり、したがって、メッセージ転送コストが高くなる課題は、冗長的にメッセージパッシングする回数が増加する課題と密接に関係している。
【００１７】
（第３の課題：インタフェース保守コストが高くなるという課題）
インタフェースの粒度が細かく、クライアント依存（主導）でインタフェースの定義・仕様化が行われると、インタフェース数の増加係数が高くなる。その結果、システムは、多数のインタフェースを所有することとなり、これらのインタフェースの保守コストが高くなってしまう。
【００１８】
例えば、大規模ソフトウェアで構成されるシステムの開発部署の体制は、システムをサブシステム分割し、このサブシステム単位にチーム化することが通例である。また、これらのチーム間でプログラム間のインタフェースを外部インタフェース仕様として公開し、部署全体又はチームごとに外部インタフェース仕様を管理することが通例である。
【００１９】
しかしながら、大規模ソフトウェアで、かつストーブパイプ構造化現象が発生するほどの多くのインタフェース数が存在する場合には、既存のインタフェース仕様の管理コストが非常に大きくなってしまう。
【００２０】
またさらに、手続き型インタフェースでは、再利用性を向上させる技術として、インタフェースの粒度を小さくする手法（最小化）がしばしば採用される。その結果、インタフェース粒度が最小化されてインタフェース数が増加することで、開発者のインタフェースのメンテナンスコストがさらに増加してしまう。
【００２１】
また、例えば、既存のインタフェースを改良（リファクタリング）しようと思った場合には、膨大なインタフェース仕様群から、当該リファクタリングに関係のあるインタフェースをピックアップしなければならないが、これは非常に困難な作業を伴う。
【００２２】
また、機能追加するなどのバージョンアップによる新規追加プログラムは、外部と接続するインタフェースを提供するが、このインタフェースを定義する際、既存のインタフェース定義を自インタフェースに再利用することが可能である。しかしながら、もはや管理が不可能な状態にある膨大なインタフェース仕様群から再利用可能なインタフェースを探索することは困難であるため、結果的に、既存のインタフェース定義が再利用可能であるにもかかわらず、新規インタフェースとして重複定義してしまうことになる。その結果、この重複定義が、更なるシステムの膨大化に拍車をかけてしまうことになる。
【００２３】
また、情報処理（プログラムに情報を入力し、プログラムが処理した結果を得る行為）を行うために複数のプログラム間でインタフェースを持つということは、プログラム間の呼び出し関係における依存関係をもつということである。プログラム間の依存関係は、基本的に単一方向依存であることが望ましいが、双方向依存の場合には、このプログラム間の依存関係の維持には多大な保守コストが必要となる。
【００２４】
（第４の課題：インタフェース再利用性が低くなるという課題）
手続き型インタフェースでは、インタフェースの粒度を小さくして、インタフェース再利用性の向上を試みるものであるが、必ずしもインタフェースの再利用性が向上するとは限らない場合もある。例えば、インタフェースはクライアント依存（主導）で定義・仕様化されるため、機能追加などのバージョンアップ時にはインタフェース再利用性が低い傾向にある。なお、このインタフェース再利用性が低くなる課題は、既存のインタフェース定義が再利用可能であるにもかかわらず、新規追加プログラムのインタフェースが重複定義されてしまい、既存のインタフェース定義の再利用が行われないというインタフェース保守コストが高くなる課題と密接に関連している。
【００２５】
（第５の課題：システム全体の開発効率が低下するという課題）
また、１業務処理が、複数個のインタフェースを呼び出す手順を必要とする場合があるが、従来の手続き型インタフェースでは、呼び出し手順の前後依存関係が仕様書に明記されているだけでシステム化されておらず、各手続き型インタフェースのプログラムが孤立して存在している。また、劣悪な開発環境や管理体制では、各手続き型インタフェースのプログラムが乱立してしまうこともある。その結果、開発者は、仕様書から手順の前後依存関係を理解する手間を必要としたり、実際のインタフェースプログラム間の手順の前後依存関係と、仕様書に記載されている内容との相違があった場合に、これに困惑したりすることになる。すなわち、開発者に必要以上の労力を課すことになり、システム全体の開発効率が低下する。
【００２６】
また、ＣＯＲＢＡ−ＩＤＬは、ターゲット（サーバント）オブジェクトの外部インタフェースを定義するものであるとともに、ＩＤＬ定義を用いて、クライアントにはスタブプログラム（インタフェース呼び出し口）を自動生成し、ターゲットにはスケルトンプログラム（サーバントプロセスのフレームワーク）を自動生成する機構を持っている。したがって、ＣＯＲＢＡ−ＩＤＬでは、手続き型インタフェースの各エントリはシステム化されているが、呼び出しシーケンスを明確にするわけではない。そのため、呼び出し手順誤りが発生する可能性があり、この場合、ユーザに対して、インタフェース定義を参照する手間を強いることになる。
【００２７】
また、モバイルエージェント技術におけるプログラムの強い移送は、プログラムをダウンロードするインタフェースのみであり、クライアントとサーバの関係における通信インタフェース数は疎である。しかし、モバイルエージェント技術によれば、プログラムコードを転送するため、メッセージトラフィックコストは非常に大きくなってしまう。また、モバイルエージェント技術は、クライアント側リソースにプログラムインスタンス空間を必要とするため、少リソースのクライアントでは利用不可能な技術である。
【００２８】
本発明は、上記の問題に鑑み、インタフェース数を削減してプログラム間のインタフェースの複雑化によるストーブパイプ構造化現象の発生確率を低減するとともに、システムの開発効率及び再利用性の向上を実現することを目的とする。
【課題を解決するための手段】
【００２９】
上記目的を達成するため、本発明によれば、分散ネットワーク環境を前提とするソフトウェアシステムのプログラム間連携の仕組みであって、
クライアントとサーバとの間のインタフェースの粒度を大きくして前記インタフェースの数を低減するとともに、サーバ主導で前記サーバの役割に基づいてインタフェース定義を行うプログラムインタフェースフレームワーク実現方法が提供される。
【００３０】
また、本発明によれば、上記のプログラムインタフェースフレームワーク実現方法に加えて、前記クライアントと前記サーバとの間における複数の非同期メッセージの通信を含む複数のプログラム呼び出し手順をまとめて、１つの前記インタフェースとして定義するプログラムインタフェースフレームワーク実現方法が提供される。
【００３１】
また、本発明によれば、上記のプログラムインタフェースフレームワーク実現方法に加えて、１業務処理単位（トランザクション）に含まれる前記複数のプログラム呼び出し手順をまとめて、１つの前記インタフェースとして定義するプログラムインタフェースフレームワーク実現方法が提供される。
【００３２】
また、本発明によれば、上記のプログラムインタフェースフレームワーク実現方法に加えて、プログラムインタフェース構造でトランザクションの定義を行うプログラムインタフェースフレームワーク実現方法が提供される。
【００３３】
また、本発明によれば、上記のプログラムインタフェースフレームワーク実現方法に加えて、前記クライアントは、プロトコルシーケンス上の呼び出し口として機能するＡＰＩ（アプリケーションプログラムインタフェース）が提供されるとともに、前記呼び出し口の応答を受ける戻り口として機能するイベントハンドラＡＰＩが提供され、
前記サーバは、前記クライアント側の前記呼び出し口からの要求を受ける要求受け付け口として機能するＡＰＩが提供されるとともに、前記要求受け付け口で受けた前記要求に対して応答を行う応答口としてイベントハンドラＡＰＩが提供されるプログラムインタフェースフレームワーク実現方法が提供される。
【００３４】
また、本発明によれば、上記のプログラムインタフェースフレームワーク実現方法に加えて、前記クライアント及び前記サーバに対して、実装を必須とする手続きに関しては、具体的な実装を派生クラスに任せる純粋仮想関数によって明示し、実装を任意とする手続きに関しては、仮想関数によって明示するとともに前記仮想関数に関するデフォルト実装を提供するプログラムインタフェースフレームワーク実現方法が提供される。
【００３５】
また、本発明によれば、上記のプログラムインタフェースフレームワーク実現方法に加えて、前記インタフェースの定義に基づいて、前記クライアント用のスタブ及び前記サーバ用のスケルトンが自動生成されるプログラムインタフェースフレームワーク実現方法が提供される。
【００３６】
また、本発明によれば、上記のプログラムインタフェースフレームワーク実現方法に加えて、前記クライアント用の前記スタブと前記サーバ用の前記スケルトンとの間の通信方式を隠蔽して任意の通信方式を採用するプログラムインタフェースフレームワーク実現方法が提供される。
【００３７】
また、本発明によれば、上記のプログラムインタフェースフレームワーク実現方法に加えて、前記クライアントによって前記インタフェースの呼び出し処理が行われた場合、所定のタスクアロケータが、前記呼び出し処理に応じたビヘイビアを読み出して、読み出された前記ビヘイビアを実行するための規約を前記インタフェースに動的に設定するプログラムインタフェースフレームワーク実現方法が提供される。
【００３８】
また、本発明によれば、上記のプログラムインタフェースフレームワーク実現方法に加えて、所定の状態マシンが、動的に設定された前記ビヘイビアを把握することによって、前記クライアント及び前記サーバの状態を管理するプログラムインタフェースフレームワーク実現方法が提供される。
【００３９】
また、上記の目的を達成するため、本発明によれば、分散ネットワーク環境を前提とし、クライアントとサーバとの間における複数の非同期メッセージの通信を含む複数のプログラム呼び出し手順をまとめて、サーバ主導で前記サーバの役割に基づいて１つのインタフェースとして定義が行われているソフトウェアシステムにおけるインタフェース動的割り当て方法であって、
前記クライアントによって前記インタフェースの呼び出し処理が行われた場合、所定のタスクアロケータが、前記呼び出し処理に応じたビヘイビア（実体処理）を読み出して、読み出された前記ビヘイビアを実行するための規約を前記インタフェースに動的に設定するインタフェース動的割り当て方法が提供される。
【００４０】
また、本発明によれば、上記のインタフェース動的割り当て方法に加えて、所定の状態マシンが、動的に設定された前記ビヘイビアを把握することによって、前記クライアント及び前記サーバの状態を管理するインタフェース動的割り当て方法が提供される。
【発明の効果】
【００４１】
本発明は、上記の構成を有しており、インタフェース数を削減してプログラム間のインタフェースの複雑化によるストーブパイプ構造化現象の発生確率を低減することができるとともに、システムの開発効率及び再利用性の向上を実現することができる。また、本発明は、特に上記の第１〜第５の課題を解決することができる。
【発明を実施するための最良の形態】
【００４２】
以下、図面を参照しながら、本発明の実施の形態について説明する。
【００４３】
図１は、本発明の実施の形態におけるプログラム間のインタフェースの構造の一例を示す図である。なお、図１の下段には、本発明の実施の形態におけるプログラム間のインタフェースの構造の一例が図示されており、図１の上段には、本発明との比較対照として、従来の手続き型インタフェースに係るストーブパイプ構造（図７の下段に図示されている構造に対応）が図示されている。
【００４４】
本発明の実施の形態では、プログラム間のインタフェースの粒度の抽象化を行うとともに、サーバが、サーバ自身の本質的な役割に基づいて（サーバ主導で）、インタフェースの定義を行うようにする。すなわち、インタフェースは、クライアントに依存せずにサーバ自身の都合で提供される。具体的には、サーバとなるプログラムが、サーバ自身の役割に基づいてインタフェースの定義を行うことによって、サーバ対クライアントが１対多で接続できるようにする。これにより、プログラム間のインタフェースの粒度の抽象化が行われるようにして、インタフェースの数を抑えたシンプルな構成が実現される。なお、以降、従来の手続き型Ｉ／Ｆに対して、本発明に係るインタフェースの構成を、サーバ役割型Ｉ／Ｆと呼ぶこともある。
【００４５】
基本的に、インタフェースの粒度の抽象化が行われることによって、上述の第１〜第５の課題はすべて解決される。すなわち、プログラム間のインタフェースの粒度の抽象化を行うことによって、冗長なインタフェースがなくなり（あるいは少なくなり）、冗長的にメッセージパッシングする回数が増加するという課題（第１の課題）が解決される。また、プログラム間のインタフェースの粒度の抽象化を行うことによって、インタフェースの数が低減されて、特にトラフィックジャムの発生時においてメッセージ転送コストが高くなるという課題（第２の課題）が解決される。また、プログラム間のインタフェースの粒度の抽象化を行うことによって、管理対象となるインタフェースの数が低減されて、インタフェース保守コストが高くなるという課題（第３の課題）や、インタフェース再利用性が低くなるという課題（第４の課題）が解決される。また、プログラム間のインタフェースの粒度の抽象化を行うことによって、各プログラムに係るインタフェースの乱立やプログラムの孤立が抑制されて、システム全体の開発効率が低下するという課題（第５の課題）が解決される。
【００４６】
また、図２は、本発明のサーバ役割型Ｉ／Ｆに係る時間に依存したインタフェース増加傾向と、従来の手続き型Ｉ／Ｆに係る時間に依存したインタフェース増加傾向との差異を説明するためのグラフを示す図である。図２には、本発明に係るサーバ役割型Ｉ／Ｆ及び従来の手続き型Ｉ／Ｆに関して、時間（すなわち、機能追加やバージョンアップ回数）に依存したインタフェース増加数の傾向が模式的に図示されている。
【００４７】
図２に図示されているように、機能追加やバージョンアップが行われるたびに、従来の手続き型Ｉ／Ｆではインタフェースが飛躍的に増加（最悪の場合には、毎回、既存プログラムの数だけ増加）し、その結果、手続き型Ｉ／Ｆでは、ソフトウェア開発における管理可能限界点を超えるストーブパイプ構造化現象が発生してしまう。一方、本発明のサーバ役割型Ｉ／Ｆでは、従来の手続き型Ｉ／Ｆに比べてインタフェースの増加数が抑えられる（例えば、プログラムが新規追加されるたびに１つずつインタフェースが増加）。すなわち、本発明のサーバ役割型Ｉ／Ｆでは、従来の手続き型Ｉ／Ｆに比べて新規インタフェースの発生率が低減され、その結果、本発明のサーバ役割型Ｉ／Ｆでは、インタフェースの管理コスト（保守コスト）が低減される。なお、図２では、従来の手続き型Ｉ／Ｆ及び本発明のサーバ役割型Ｉ／Ｆの両方のインタフェース増加数は、時間に依存して線形的に増加するように図示されているが、実際には、従来の手続き型Ｉ／Ｆのインタフェース増加数はＮ2のオーダで増加し、本発明のサーバ役割型Ｉ／Ｆのインタフェース増加数はＮのオーダで増加することが予想される。
【００４８】
また、図３は、本発明の実施の形態において、サーバ役割型Ｉ／Ｆにおけるサーバ主導でサーバの役割に基づいた業務処理をインタフェース粒度単位とする方法を説明するための図である。なお、図３の下段には、本発明の実施の形態におけるサーバ主導のサーバ役割型Ｉ／Ｆにおけるインタフェース定義の一例が図示されており、図３の上段には、本発明との比較対照として、従来の手続き型Ｉ／Ｆに係るインタフェース定義の一例が図示されている。
【００４９】
図３には、プログラムＤをサーバとし、プログラムＡ〜Ｃをクライアントとした場合のインタフェース定義方法の一例が図示されている。図３に図示されているように、従来のクライアント主導の手続き型Ｉ／Ｆでは、プログラムＤ（サーバ）は、プログラムＡ〜Ｃ（クライアント）のそれぞれのためにＩ／Ｆを用意する。各プログラムＡ〜Ｃ（クライアント）のためにプログラムＤから提供されるＩ／Ｆは、それぞれ各クライアント専用に作られているため専門化（具体的かつ詳細な定義付け）が行われており、当の開発者（当事者）にとっては非常に便利なＩ／Ｆであると言える。しかしながら一方で、各プログラムＡ〜Ｃ（クライアント）のためにプログラムＤから提供されるＩ／Ｆは細かな定義付けがなされており、他の開発者にとって（さらには、ある程度の時間が経った後の当の開発者にとっても）の再利用性は低い。
【００５０】
一方で、図３に図示されているように、本発明のサーバ主導のサーバ役割型Ｉ／Ｆでは、プログラムＤ（サーバ）は、プログラムＡ〜Ｃ（クライアント）に依存せずに、プログラムＤ（サーバ自身）が公開する役割に基づいてＩ／Ｆを用意する。このサーバ主導によって用意されたＩ／Ｆは、すべての各プログラムＡ〜Ｃ（クライアント）に共通して提供されるものであり、すべてのプログラム（クライアント）用に作られる。その結果、例えばプログラムＤ（サーバ）は新たなクライアントが追加される場合でも新規Ｉ／Ｆを用意する必要はなく、新たなクライアントは、事前にサーバＤによって提供されているＩ／Ｆを利用する。すなわち、本発明の実施の形態において、サーバ主導で提供されるサーバ役割型Ｉ／Ｆは、再利用性が高いと言える。
【００５１】
上述のように、従来のクライアント主導の手続き型Ｉ／Ｆは、各クライアント専用若しくは特定クライアントに対して低汎用的なインタフェースを提供するものであり、最悪の場合、サーバに接続するクライアント数分のインタフェースが存在してしまうことになる。これに対して、本発明のサーバ主導のサーバ役割型Ｉ／Ｆでは、サーバの本質的な役割に基づいて、各クライアントに依存しないインタフェースを提供するものであり、インタフェース数をサーバの数に依存した数に抑えるとともに、インタフェースの再利用性が向上する。
【００５２】
このように、本発明のサーバ役割型Ｉ／Ｆでは、従来の手続き型Ｉ／Ｆにおけるクライアント主導によるインタフェースの定義をパラダイムシフトして、サーバ主導によるインタフェースの定義が行われるようにする。
【００５３】
また、本発明のサーバ役割型Ｉ／Ｆでは、例えば、プロトコルシーケンス全体を１つのインタフェースとすることが可能である。例えば図６に図示されているような１業務処理フローに対して、従来のクライアント主導の手続き型Ｉ／Ｆでは、非同期メッセージ通信を最小単位として、非同期メッセージ通信ごとにインタフェースが用意される必要がある。しかしながら、本発明のサーバ役割型Ｉ／Ｆは、本質的な情報処理の単位（すなわち、この情報処理によって達成しようとする１つの目的）である１業務処理に鑑みて、複数のプロトコルシーケンスをまとめた役割インタフェースを定義する。なお、このとき、トランザクション処理単位でインタフェースの定義を行うことも可能であり、また、１業務処理そのものに対して１つのインタフェース定義を行うことも可能である。これは、細かな各非同期メッセージ通信単位でインタフェースの定義を行うというインタフェース定義の方針を、１業務処理単位の役割インタフェースによるインタフェース定義を行うという方針に根本的に転換するものである。
【００５４】
例えば、先に説明したホテル予約シーケンスの場合には、上述のように、クレジット決済フェーズの追加以外にも、異常時（エラー時）の対応シーケンスや割り込み（ユーザ割り込み）シーケンスの追加、あるいは既存のシーケンスの変更や削除など、様々なバージョンアップが行われることがあるが、こうしたバージョンアップに係るシーケンスは基本的に１業務処理単位や１つのトランザクション処理単位で定義されている役割インタフェースに接続されることになる。これによって、トランザクション処理は、１つ又は少数のインタフェース単位で管理可能となり、コミットやロールバックにおいて呼び出されるプログラム呼び出し手順の変更などの管理が容易となる。
【００５５】
また、インタフェースを接続単位（すなわちセッション単位）で定義することも可能であり、これによって、インタフェース単位でセッション管理を行うことも可能となる。また、従来の手続き型Ｉ／Ｆでは、管理が複雑かつ容易ではなくなるネストしたトランザクションや分散トランザクションなどに関しても、これらを包括（カプセル化）したインタフェースで管理することが可能となり、管理が容易となる。また、従来の手続き型Ｉ／Ｆでは、それぞれ独立していたメッセージシーケンスを粒度の粗いインタフェースでまとめることにより、メッセージの最適化を行って、冗長なメッセージパッシングを抑制することも可能となる。また、本発明のサーバ役割型Ｉ／Ｆでは、例えば１業務処理を１つのインタフェースとみなすことで、システム全体の完成形であるプロトタイプの制作及び評価を行うことが容易となる。したがって、システムの開発手法としては、ＲＡＤ（Rapid Application Development）を採用することが好適である。
【００５６】
また、図４は、本発明のサーバ役割型Ｉ／Ｆにおけるサーバとクライアントとの接続において提供される情報を模式的に示す図である。図４に図示されているように、クライアントとサーバとがインタフェースによって接続された場合、クライアント側にはスタブ１００が生成され、サーバ側にはスケルトン２００が生成される。なお、クライアント側のスタブ１００及びサーバ側のスケルトン２００は、プロトコルシーケンス上におけるインタフェース定義に基づいて、自動生成されることが望ましい。
【００５７】
また、本発明のサーバ役割型Ｉ／Ｆでは、インタフェース単位（例えば、１業務処理単位）でフレームワーク化を行うことが可能である。これによって、メッセージシーケンスを通信方式に依存せずに規定することが可能となる。例えば、クライアントとサーバとの間の通信方式は、ＴＣＰ／ＩＰ（Transmission Control Protocol/Internet Protocol）、ＵＤＰ（User Datagram Protocol）、ＨＴＴＰ（HyperText Transfer Protocol）などを始めとする任意の通信方式を採用することが可能であり、さらには、クライアントとサーバとの間で動作が行われている最中であっても、この通信方式を動的に変更することが可能である。
【００５８】
クライアント側で使用されるスタブ１００には、プロトコルシーケンス上の呼び出し口（スケルトン２００の要求受付口につながる）となるＡＰＩ（Application Program Interface（アプリケーションプログラムインタフェース）：使用可能な命令や関数を利用するためのプログラム上の手続きを定めた規約の集合）が明示的に提供されるとともに、正常、異常、割り込み（ユーザ例外）などの特定のイベントに対して処理を行うイベントハンドラＡＰＩが戻り口として明示的に提供される。一方、サーバ側で使用されるスケルトン２００には、プロトコルシーケンス上の要求受け付け口（上記のクライアントの呼び出し口からイベント発火するもの）となるＡＰＩが明示的に提供されるとともに、このクライアント側からの要求に対して応答を行う応答口（上記のクライアントの戻り口につながる）として正常、異常、割り込み（ユーザ例外）のイベント発火ＡＰＩが明示的に提供される。また、クライアント側のスタブ１００及びサーバ側のスケルトン２００に対して、取り扱うデータ型も明示的に提供される。
【００５９】
また、クライアント及びサーバにおいて、実装を必須とする手続きに関しては、具体的な実装を派生クラス自身に任せる純粋仮想関数（PureVirtualFunction）によって明示し、任意（必須ではない）とする手続きに関しては、そのデフォルト実装を提供する仮想関数（VirtualFunction）によって明示する。これによって、実装を必須とする手続きに関しては、最低限の定義のみによって抽象化された基底クラスを設けるとともに、具体的な手続きに関しては、その派生クラスにおけるデフォルト実装によって定義できるようになり、例えば追加や変更が行われる場合においても、インタフェース数を増やすことなく、仮想関数として取り扱うことが可能となる。その結果、プログラム開発者は、インタフェースの定義が記載されている仕様書を詳細に理解しなくても呼び出し手順の追加や変更を行うことが可能となり、インタフェースの再利用性が向上するとともに、開発効率の高いシステムが構築されることになる。
【００６０】
また、従来の手続き型Ｉ／Ｆでは、非同期メッセージ通信ごとにインタフェースが設けられているため、仕様書を参照しながら、一連のシーケンスにおいて次に呼び出される（あるいは前に呼び出された）手順を常に考慮しなければならなかったが、本発明のサーバ役割型Ｉ／Ｆでは、サーバ側で各プログラムに共通する最低限の実装のみがインタフェースに定義されるため、仕様書を参照せずに派生クラスレベルにおいてデフォルト実装の指定を行えばよく、サーバ側及びクライアント側において、開発者が内部の固有プロトコルシーケンスの前後依存関係を意識する必要が少なくなるという効果が期待できる。なお、特に、既存のプログラム（クライアント）に対して新たなプログラム（サーバ）を追加する場合に、クライアント側における改変が抑えられ、その結果、プロトコルシーケンス上で実装を必要とする部位を容易に把握できるようになる。そして、サーバ側において、共通（必須）の実装のみが設定されたインタフェースをサーバ主導で定義するとともに、任意の実装に関してはデフォルト実装によって指定することで、インタフェースの粒度を粗くして、各プログラム（クライアント）が共通して利用できるインタフェースを定義することが可能となる。
【００６１】
また、本発明のサーバ役割型Ｉ／Ｆでは、サーバ主導で抽象化されたインタフェースが設定されることにより、インタフェースが内包している性能（すなわち、仕様書における定義の量に対応）が、従来の手続き型Ｉ／Ｆに比べて落ちる可能性があるが、これを補完するために、各手続きを規定する情報（ある呼び出しに対して発火するイベントを規定したビヘイビア）に基づくインタフェースの動的なバインディング機構を有することが望ましい。
【００６２】
図５には、本発明のサーバ役割型Ｉ／Ｆにおけるインタフェースの動的なバインディング機構の一例が模式的に図示されている。例えば、クライアントプロセスにおいて、あるＩ／Ｆに対して任意のシーケンスにおける呼び出し処理が行われた場合（図５の（１）呼び出し（ただし、図５では丸囲み数字、以下（２）〜（６）も同じ））、この呼び出しに対して規定されている振る舞いが実行されるように、ハブアンドスポーク（ＤＦ：Directory Facilitator）からタスクアロケータ（ＡＭＳ：Agent Management System）に対して探索要求が行われる（図５の（２）探索）。ＡＭＳは、この探索要求に応じて、例えばクライアントによる呼び出しに対応したすべてのビヘイビアを保持しているビヘイビアライブラリに対して問い合わせを行い、クライアントの今回の呼び出しに対応したビヘイビアを特定して、サーバントプロセスに割り当てる（図５の（３）アロケート）。
【００６３】
サーバントプロセスは、タスクアロケータから割り当てられたビヘイビアをクライアントプロセスが使用しているＩ／Ｆにバインドする（図５の（４）バインド）。これにより、クライアントの呼び出しに応じたビヘイビアを実行するための定義がＩ／Ｆに動的に設定されることになる。また、サーバントプロセスはこのビヘイビアに基づいてイベントを発火する（図５の（５）実行）とともに、クライアントに対してイベント発火による応答を行う（図５の（６）応答）ことによって、メッセージシーケンスが実現される。
【００６４】
また、ＡＭＳは、このシステムにおける管理権限を有しており、状態マシンとして機能することも可能である。例えば、タスクアロケータは、ビヘイビアの割り当てを行う際に、割り当てたビヘイビアに対応する状態を保持、管理することが可能である。すなわち、タスクアロケータは、割り当てたビヘイビアから、クライアントプロセス及びサーバントプロセスにおいて現在どのような処理が行われているのか（どのような処理状態にあるのか）を把握することが可能である。これにより、何らかの障害が発生した場合でも、例えば最後に割り当てたビヘイビアから現在の状態を把握して、この現在の状態を基準としたロールバックやロールフォワードなどのフォールトトレランス処理を迅速かつ確実に行うことが可能となる。
【００６５】
次に、図８を参照しながら、本発明において、少ない（あるいは１つの）インタフェースを用いて複数の派生パターンがサポートされる旨について説明する。図８は、本発明のサーバ役割型Ｉ／Ｆにおいて複数の派生パターンがサポートされる状態の一例を模式的に示すシーケンスチャートである。
【００６６】
本発明では、サーバがクライアントに対して提供するインタフェースは、大局的な見地（例えば、１業務処理単位）に基づいて作成される。このとき、従来の技術におけるインタフェースでは、例えば非同期メッセージの種類やその処理方法に応じてインタフェースが個別に設定されるが、本発明では、例えば単に非同期メッセージの受け口や送り口としてインタフェースが大まかに定義される。
【００６７】
すなわち、本発明で定義されるインタフェースにおいては、例えば、メッセージの種類や使用されているプロトコルに関しては特に規定されず、多義化されたメッセージあるいはプロトコルの使用を許容できるように構成されている。これは、本発明に係るインタフェースが、任意の種類のメッセージや任意のプロトコルをカプセル化できるように大ざっぱに定義されることによる。
【００６８】
例えば、図８に図示されているように、あるタイミングにおいて、サーバはクライアントから、数種類のメッセージのうちのいずれかの要求メッセージ（図８では、Ｒｅｑ（Ａ）〜（Ｄ）の４種類のメッセージのうちのいずれかのメッセージ）を受信し、それぞれの受信したメッセージに応じた処理を行って、応答メッセージ（図８では、Ｒｅｑ（Ａ）〜（Ｃ）に対してはＲｅｓ（Ａ，Ｂ，Ｃ）、Ｒｅｑ（Ｄ）に対してはＲｅｓ（Ｄ））を返信することが可能である。
【００６９】
図８において、本発明に係るインタフェースは、Ｒｅｑ（Ａ）〜（Ｄ）のどの種類のメッセージでも受けることが可能であり、また、各メッセージに応じた返信メッセージを送出することが可能である。このように、本発明に係るインタフェースは、多義化された派生パターンの詳細によらず、全体をカプセル化する構成を有しているので、さらに、従来のインタフェースと比較して、拡張性に優れた構成を有している。すなわち、本発明に係るインタフェースは、処理の詳細に関して固定的に定めるものではなく、例えば、インタフェースの初期設定時において想定されていなかったメッセージ交換の追加やメッセージの種類の変更、あるいは使用プロトコルの変更などに関して、単なる１つの派生パターンの増加として取り扱うことが可能である。
【００７０】
一方、本発明におけるインタフェースの大まかな定義を補完するように、詳細な処理（各種類のメッセージや各種プロトコルに応じた詳細な処理）があらかじめビヘイビアによって定義され、ビヘイビアライブラリに保持される（前述の図５を参照）。そして、例えばあるメッセージの受信というイベントが発生したとき、この受信メッセージに対して適切なビヘイビアが読み出され、インタフェースにバインドされることによって、適切なタスク（応答）が実行される。このように、本発明では、ビヘイビアライブラリに多義化された様々な派生パターンに適切に対応できるビヘイビアを設定（あるいは追加）することで、インタフェースの再利用性及び拡張性を向上させることが可能となる。
【００７１】
さらに本発明では、インタフェースが業務処理単位やトランザクション単位などによって大局的に定義されているため、状態マシン（あるいは、タスクアロケータ）による俯瞰的な状態管理が重要となる。従来のプログラムインタフェース構造（プログラムインタフェースフレームワーク）では、インタフェースが細かく分けられており、例えば所定の段階を経た後にあるインタフェースの呼び出しが行われるようになっている。すなわち、従来のプログラムインタフェース構造では、現在使用されているインタフェースを特定することによって、現在の状態を特定することが可能であり、設計段階において、状態とインタフェースとの関係が密接に関連付けられる。
【００７２】
一方、本発明では、インタフェースが粗くなっており、インタフェース数が少なくなっているので、タスクの割り当てやタスク再構成の際に、現在どの状態に位置しているかを確実に管理できるようにする必要がある。本発明では、状態マシンによって俯瞰的な状態管理が行われ、管理されている現在の状態と、発生したイベント（例えば、メッセージの受信など）とを参照して、適切なビヘイビアの割り当てが行われる。
【００７３】
また、本発明によれば、以下に示すように、効率的なマルチタスクスケジュールを実現することが可能である。本発明では、ある役割を達成するまでの対極的な処理を１まとめにした役割インタフェースが実装されるとともに、大まかなインタフェースの定義を補完するように、詳細な状態管理及びビヘイビアの割り当てを行うことが可能な状態マシンプログラムと、様々な派生パターンに対応する詳細な処理を定義するビヘイビアとが用意される。
【００７４】
このとき、タスクコントローラ（例えば、状態管理マシンやタスクアロケータにより実現可能）は、実行されるビヘイビアを把握することが可能であり、例えば、実行されるビヘイビアの集合から、ビヘイビアを実行するために必要なスロット数を計算し、必要スロットを生成して空スロットにビヘイビアを割り当てることが可能である。タスクコントローラは、業務全体の流れの観点から、スロットに対するビヘイビアの割り当てを行うことが可能であり、同時期に処理可能な複数のタスクを並行して処理できるように管理することが可能となる。
【００７５】
また、図９は、本発明のサーバ役割型Ｉ／Ｆにおいて使用される状態マシンのクラス図である。本発明は、例えば、図８に図示されているクラス図に係る状態マシンを使用することで、複数手続きの各段階を状態として表現し、管理することが可能となる。
【産業上の利用可能性】
【００７６】
本発明は、インタフェース数を削減してプログラム間のインタフェースの複雑化によるストーブパイプ構造化現象の発生確率を低減することができるという効果や、システムの開発効率及び再利用性の向上を実現することができるという効果を有しており、分散ネットワーク環境を前提とするソフトウェアシステムのプログラミング技術分野や、一般のネットワーク環境上で駆動するソフトウェアシステムのためのプログラミング技術（ネットワークプログラミング技術）、及び上記のプログラムの保守、管理の向上や、プログラムの再利用性の向上に係るプログラム保守性向上技術に適用可能である。
【図面の簡単な説明】
【００７７】
【図１】本発明の実施の形態におけるプログラム間のインタフェースの構造の一例を示す図である。
【図２】本発明のサーバ役割型Ｉ／Ｆに係る時間に依存したインタフェース増加傾向と、従来の手続き型Ｉ／Ｆに係る時間に依存したインタフェース増加傾向との差異を説明するためのグラフを示す図である。
【図３】本発明のサーバ役割型Ｉ／Ｆにおけるサーバ主導でサーバの役割に基づいた業務処理をインタフェース粒度単位とする方法を説明するための図である。
【図４】本発明のサーバ役割型Ｉ／Ｆにおけるサーバとクライアントとの接続において提供される情報を模式的に示す図である。
【図５】本発明のサーバ役割型Ｉ／Ｆにおけるインタフェースの動的なバインディング機構の一例を模式的に示す図である。
【図６】従来の技術における手続き型インタフェースを用いたシーケンスチャートの一例を示す図である。
【図７】従来の技術において発生するストーブパイプ構造化現象の一例を示す図である。
【図８】本発明のサーバ役割型Ｉ／Ｆにおいて複数の派生パターンがサポートされる状態の一例を模式的に示すシーケンスチャートである。
【図９】本発明のサーバ役割型Ｉ／Ｆにおいて使用される状態マシンのクラス図である。
【符号の説明】
【００７８】
１００  スタブ
２００  スケルトン
【図１】
2008234535.tif 000003
【図２】
2008234535.tif 000004
【図３】
2008234535.tif 000005
【図４】
2008234535.tif 000006
【図５】
2008234535.tif 000007
【図６】
2008234535.tif 000008
【図７】
2008234535.tif 000009
【図８】
2008234535.tif 000010
【図９】
2008234535.tif 000011