所定の規格あるいは仕様に準拠して作成されたシステムから前記システムとは異なる規格あるいは仕様に準拠して作成された他のシステムへのアクセスが可能な分散システムにおけるシステム間連携装置であって、前記システムと前記他のシステムとの間における通信プロトコルの形態と前記システムおよび前記他のシステムのシステム構成およびネットワーク構成とを対応付けたプロトコル定義と前記システムが所定のアプリケーションにより前記他のシステムにアクセスするための前記所定のアプリケーションに固有の要件である非機能要件と、前記プロトコル定義および前記非機能要件に応じた前記アプリケーションを実行させるための複数のモジュールと、を記憶する記憶部と、前記他のシステムにアクセスして前記所定のアプリケーションを実行させるためのアプリケーション処理部と、前記アプリケーション処理部が前記所定のアプリケーションの実行指示を受けた場合に、前記所定のアプリケーションからの要求に応じて、前記プロトコル定義に含まれる前記通信プロトコル形態および前記システム構成および前記ネットワーク構成に基づいて定められる前記システムと前記他のシステムとの間の処理を行うために必要な要件値と前記非機能要件との組み合わせに基づいて、前記複数のモジュールの中から前記アプリケーションによる処理を実行させるために必要なモジュールを選択する組合せ処理部と、を備えることを特徴とするシステム間連携装置。前記組合せ処理部は、前記システムが有する前記アプリケーションからの要求を実行するための処理の手続きがリクエスト/リプライ型であって、前記通信プロトコルの形態がパブリッシュ/サブスクライブ型である場合には、前記他のシステムと前記システムとの間に設けられた前記アプリケーションからのアクセスを受け付けるための一時蓄積用データベースを、前記他のシステムから受け付けたパブリッシュ/サブスクライブを受けて更新するとともに、前記アプリケーションからのリクエストに対してリプライを返す処理を前記モジュールとして組み込む、ことを特徴とする請求項1に記載のシステム間連携装置。前記組合せ処理部は、前記システムが有する前記アプリケーションからの要求を実行するための処理の手続きがパブリッシュ/サブスクライブ型であって、前記通信プロトコルの形態がリクエスト/リプライ型である場合には、前記他のシステムと前記システムとの間に設けられた前記アプリケーションからのアクセスを受け付けるための一時蓄積用データベースを、前記他のシステムに対し随時リクエスト/リプライを実行して更新するとともに、前記アプリケーションからのサブスクライブに対してパブリッシュを返す処理前記モジュールとして組み込む、ことを特徴とする請求項1に記載のシステム間連携装置。前記組合せ処理部は、前記システムが有する前記アプリケーションからの要求を実行するための処理の手続きが一方向型であって、前記通信プロトコルの形態がリクエスト/リプライ型である場合には、前記他のシステムと前記システムとの間に設けられた一方的なデータ送信を実行する一時蓄積用データベースを、前記他のシステムに対し随時リクエスト/リプライを実行して更新するとともに、前記アプリケーションに対して一方的なデータ送信を行う処理を前記モジュールとして組み込む、ことを特徴とする請求項1に記載のシステム間連携装置。前記組合せ処理部は、前記システムが有する前記アプリケーションからの要求を実行するための処理の手続きが一方向型であって、前記通信プロトコルの形態がパブリッシュ/サブスクライブ型である場合には、前記他のシステムと前記システムとの間に設けられた一方的なデータ送信を実行する一時蓄積用データベースを、前記他のシステムに対し随時パブリッシュ/サブスクライブを実行して更新するとともに、前記アプリケーションに対して一方的なデータ送信を行う処理を前記モジュールとして組み込む、ことを特徴とする請求項1に記載のシステム間連携装置。前記要件値には、あらかじめ定められた前記システムまたは前記他のシステムの性能を満たすための性能要件値を含み、前記組合せ処理部は、前記システムと前記他のシステムとの間における通信プロトコルの形態と前記システムおよび前記他のシステムのシステム構成およびネットワーク構成との組合せと、前記性能要件値とに基づいて、前記複数のモジュールの中から前記アプリケーションによる処理を実行させるために必要なモジュールを選択する、ことを特徴とする請求項1~5に記載のシステム間連携装置。前記組合せ処理部は、前記性能要件値を満たすために前記システムと前記他のシステムとの間のネットワーク性能が低下する場合には、前記他のシステムで用いられるデータを前記アプリケーションが動作する前記システムを有したサーバに前記データを複製し、前記複製されたデータに対してアクセスすることにより前記アプリケーションに前記処理を実行させる処理を前記モジュールとして組み込む、ことを特徴とする請求項6に記載のシステム間連携装置。前記組合せ処理部は、前記性能要件値を満たすために前記システムと前記他のシステムとの間のネットワーク性能がトラフィックの状況により不十分になる可能性がある場合には、前記システムと前記他のシステムとの間で通信コネクションを生成し、前記性能要件値を満たす一定の性能での通信を確保させる処理を前記モジュールとして組み込む、ことを特徴とする請求項6に記載のシステム間連携装置。前記要件値には、あらかじめ定められた前記システムと前記他のシステムとの間でやりとりされるデータの信頼性を満たすための信頼性要件値を含み、前記組合せ処理部は、前記システムと前記他のシステムとの間における通信プロトコルの形態と前記システムおよび前記他のシステムのシステム構成およびネットワーク構成との組合せと、前記信頼性要件値とに基づいて、前記複数のモジュールの中から前記アプリケーションによる処理を実行させるために必要なモジュールを選択する、ことを特徴とする請求項1~8に記載のシステム間連携装置。前記組合せ処理部は、前記システムと前記他のシステムとの間のネットワークが多重化され、かつ前記データの信頼性が高い場合には、前記ネットワークにおける通信を多重化させる処理を前記モジュールとして組み込む、ことを特徴とする請求項9に記載のシステム間連携装置。前記組合せ処理部は、前記ネットワークが多重化されていない場合であって、通信プロトコルが前記データの再送をサポートしており、かつ前記データの信頼性が高い場合には、前記データの再送要求を行う処理を前記モジュールとして組み込む、ことを特徴とする請求項9に記載のシステム間連携装置。前記組合せ処理部は、前記ネットワークが多重化されていない場合であって、前記他のシステムが前記データの完全性をチェックするためのチェック処理部を有している場合には、前記チェック処理部による前記データのチェックを行わせる処理を前記モジュールとして組み込む、ことを特徴とする請求項9に記載のシステム間連携装置。前記要件値には、あらかじめ定められた前記システムおよび前記他のシステムのセキュリティレベルを満たすためのセキュリティ要件値を含み、前記組合せ処理部は、前記システムおよび前記他のシステムとの間における通信プロトコルの形態と前記システムおよび前記他のシステムのシステム構成およびネットワーク構成との組合せと、前記セキュリティ要件値とに基づいて、前記複数のモジュールの中から前記アプリケーションによる処理を実行させるために必要なモジュールを選択する、ことを特徴とする請求項1~12に記載のシステム間連携装置。前記組合せ処理部は、前記他のシステムが前記セキュリティ要件値を満たしていない判定した場合には、前記他のシステムへのアクセスを遮断し、または部分的にアクセスをフィルタリングする処理を前記モジュールとして組み込む、ことを特徴とする請求項13に記載のシステム間連携装置。前記組合せ処理部は、前記他のシステムが前記システムと共通の認証基盤を利用可能なシステムである場合には前記共通の認証基盤に基づいて前記システムと前記他のシステム間の認証を行う処理を前記モジュールとして組み込む、ことを特徴とする請求項13に記載のシステム間連携装置。前記組合せ処理部は、前記他のシステムが所定の暗号/複合化機能に対応したシステムである場合には前記所定の暗号/複合化機能に基づいて前記システムと前記他のシステム間の認証を行う処理を前記モジュールとして組み込む、ことを特徴とする請求項13に記載のシステム間連携装置。前記組合せ処理部が行う機能を、前記システムおよび前記他のシステムとの間の通信経路に配置したサーバに保持させる、ことを特徴とする請求項1~16に記載のシステム間連携装置。前記組合せ処理部は、前記アプリケーションが実行される際に、その都度、前記他のシステムが、あらかじめ定められた前記システムまたは前記他のシステムの性能を満たすための性能要件値、あらかじめ定められた前記システムと前記他のシステムとの間でやりとりされるデータの信頼性を満たすための信頼性要件値、またはあらかじめ定められた前記システムおよび前記他のシステムのセキュリティレベルを満たすためのセキュリティ要件値を満たしているかを判定し、前記モジュールを選択する、ことを特徴とする請求項6~17に記載のシステム間連携装置。しかしながら、上述した特許文献1~3に開示されている技術では、システム間の相互接続の際に、データモデル、インタフェースまたは通信プロトコルのいずれか1つの変換のみを実施している。このためデータモデル、インタフェース、プロトコルのうち2つ以上が異なる場合には対応できず、接続の際に不具合が生じ得る。また、相互接続する異なる2つのシステム毎に個別に変換及び接続のための処理を全て作り込む必要があり、接続先対応規格の数が増えるとこれらの処理を作り込む負荷が増大する。さらに、個々のアプリケーションが要求する要件である非機能要件を満たすための処理を、各アプリケーション側で作り込む必要がある。このため、接続先の追加変更に伴うアプリケーションの改修負荷が増大する。また、特許文献3では、システム間連携装置にて固定の手続きを連携用の固定の通信プロトコル上で実現しているのみである。このためインタフェース実行に伴う手続きの形態と接続先システムにて使用する通信プロトコルの形態に差異が有る場合、接続及び手続き実施ができない。このように、異なる規格や仕様に準拠したシステムが複数混在運用される環境においては、個々の異なるシステム間を接続連携するための処理を、本来の個々のアプリケーション処理自体とは別に、接続連携毎に個別に開発する必要がある。混在運用される異なるシステムが多数になればなるほど、開発する必要のある、システム間の接続連携処理が増えるとともに、処理自体も複雑化し、開発の労力や工数が肥大化することになる。また、接続連携対象となるシステムの規格や仕様の詳細を把握した上で接続連携処理を開発する必要があるため、アプリケーション開発者の負担が増大することになる。このような状況に鑑み、本発明は、異なる規格や仕様に準拠する複数の異なるシステム間の相互接続および連携を行う際に、アプリケーション処理としての作りこみは排除した上で、アプリケーション開発者からは意識されないミドルウェアにて相互接続のための処理規格仕様間の相互変換および実際の接続連携時に必要となる非機能要件を充足するための処理を実施し、その上で、ミドルウェア機能としての個々の接続連携処理の開発を容易化し、アプリケーション開発の生産性を向上させることが可能な分散システムにおけるシステム間連携装置を提供することを目的とする。上述した課題を解決し、目的を達成するために、本発明にかかるシステム間連携装置は、所定の規格あるいは仕様に準拠して作成されたシステムから前記システムとは異なる規格あるいは仕様に準拠して作成された他のシステムへのアクセスが可能な分散システムにおけるシステム間連携装置であって、前記システムと前記他のシステムとの間における通信プロトコルの形態と前記システムおよび前記他のシステムのシステム構成およびネットワーク構成とを対応付けたプロトコル定義と前記システムが所定のアプリケーションにより前記他のシステムにアクセスするための前記所定のアプリケーションに固有の要件である非機能要件と、前記プロトコル定義および前記非機能要件に応じた前記アプリケーションを実行させるための複数のモジュールと、を記憶する記憶部と、前記他のシステムにアクセスして前記所定のアプリケーションを実行させるためのアプリケーション処理部と、前記アプリケーション処理部が前記所定のアプリケーションの実行指示を受けた場合に、前記所定のアプリケーションからの要求に応じて、前記プロトコル定義に含まれる前記通信プロトコル形態および前記システム構成および前記ネットワーク構成に基づいて定められる前記システムと前記他のシステムとの間の処理を行うために必要な要件値と前記非機能要件との組み合わせに基づいて、前記複数のモジュールの中から前記アプリケーションによる処理を実行させるために必要なモジュールを選択する組合せ処理部と、を備えることを特徴とする。本発明によれば、アプリケーション開発の生産性を向上させることが可能な分散システムにおけるシステム間連携装置を提供することができるという効果を奏する。以下に添付図面を参照して、本発明にかかる分散システムにおけるシステム間連携装置の実施の形態を詳細に説明する。図1は、第1の実施の形態における分散システム1000の構成例を示す図である。図1に示すように、分散システム1000は、内部システム1010と外部システム1020とを含んで構成されている。なお、内部システム1010と外部システム1020とは、例えば、インターネット等の一般的なネットワークNによって接続されているものとする。内部システム1010は、利用者によって使用される所定のアプリケーションを有した外部システム1020とは異なるシステムであり、サーバ101システム間連携装置の内部記憶装置115に組み込まれているものである。内部記憶装置115には、内部システム1010にアクセス可能な利用者が使用する複数のアプリケーションを実行するアプリケーション処理部102と、それらのアプリケーション処理部102を一意に識別するための識別情報105とが対応付けて記憶されている。また、内部記憶装置115には、ミドルウェア106が記憶されている。ミドルウェア106は、データモデル変換処理部107と、インタフェース変換処理部108と、プロトコル変換処理部109とを有している。データモデル変換処理部107は、内部システム1010と外部システム1020との間で共有するデータの共通的な意味付けを行う例えば、各システムで用いられるデータをいずれもCIMcommoninformationmodelに従ったデータモデルにするものであり、内部システム1010で用いられるデータモデルを外部システム1020で用いられるデータモデルに変換する。また、図1に示すように、データモデル変換処理部107は、データモデル外部定義110にアクセス可能となっている。データモデル外部定義110は、外部システム1020が有しているデータモデルとの間の変換を行うためのデータモデルに関する各種の対応付けを定義した情報であり、図2を用いて後述する。インタフェース変換処理部108は、内部システム1010が有するアプリケーション102が要求する処理の指定方法を定める例えば、内部システム1010で用いられているインタフェースを外部システム1020で用いられているオープン規格のインタフェースにするものであり、データモデル変換処理部107と同様に、内部システム1010で用いられるインタフェースを外部システム1020で用いられるインタフェースに変換する。また、図1に示すように、インタフェース変換処理部108は、インタフェース外部定義111にアクセス可能となっている。インタフェース外部定義111は、データモデル外部定義110と同様に、外部システム1020が有しているインタフェースとの間の変換を行うためのインタフェースに関する各種の対応付けを定義した情報であり、図2を用いて後述する。プロトコル変換処理部109は、内部システム1010と外部システム1020との間でデータをやり取りするための手続き、通信の様式を定めるものであり、データモデル変換処理部107等と同様に、内部システム1010で用いられるプロトコルを外部システム1020で用いられるプロトコルに変換する。また、図1に示すように、プロトコル変換処理部109は、プロトコル外部定義112にアクセス可能となっている。プロトコル外部定義112は、データモデル外部定義110等と同様に、外部システム1020が有しているプロトコルとの間の変換を行うためのプロトコルに関する各種の対応付けを定義した情報であり、図2を用いて後述する。ネットワークアクセス部116は、内部システム1010と外部システム1020との間の通信を司るものである。このような構成において、サーバ101上で動作している個々のアプリケーション処理部102が、内部システム1010で用いられる規格や仕様とは異なる規格や仕様に準拠した外部システム1020に含まれるサーバ103上のデータ例えば、データベース104に格納されているデータに対してアクセスする際について考える。この場合、まずアプリケーション処理部102が存在する内部システム1010が有する規格や仕様に準拠した形式でデータモデルやインタフェースが指定される。内部システム1010は、複数のアプリケーションを有しており、上述した識別情報105を指定することによってアプリケーションが使用可能となる。さらに、指定されたアプリケーションの下層で動作するミドルウェア106は、アプリケーション処理部102からの指定を受けて、外部システム1020にアクセスするための種々の規格や仕様に関する変換処理を行う。変換処理では、外部システム1020の規格や仕様に準拠したデータモデルへの変換、インタフェースの変換、プロトコルの変換の3階層によって変換処理が行われる。このとき、内部システム1010が有するデータモデルと外部システム1020が有するデータモデルとの間の変換を実際に行うためのデータモデル間の対応付けや変換定義は、外部定義化して上述したデータモデル外部定義110に保持され、データモデル変換処理部107が必要に応じて随時この外部定義を参照することによりデータモデル変換の処理を実行する。これと同様に、インタフェース変換およびプロトコル変換についても、それぞれ、インタフェース変換処理部108がインタフェース外部定義111を参照することによりインタフェース変換の処理を実行し、プロトコル変換処理部109がプロトコル外部定義112を参照することによりプロトコル変換の処理を実行する。また、プロトコル変換処理部109は、組み合わせ処理部113と、非機能要件達成処理部114によって構成されており、後述するように、アプリケーション開発者による要件の選択、およびシステム設計開発者によって定義されるシステム構成情報や、都度検証されるシステム性能情報等から、どのような処理モジュールによってプロトコル変換が構成されるかを自動的に決定する手段を提供する。サーバ101が有する上述した各部は、データモデル変換処理部107、インタフェース変換処理部108、プロトコル変換処理部109の各機能を実現するためのソフトウェアプログラムにより実行される。これらのソフトウェアプログラムは、例えば、上述した各部を含むモジュール構成となっており、実際のハードウェアとしては、CPU等の制御部がHDD等の記録装置からこれらのソフトウェアプログラムを読み出して実行することにより、上記各部が主記憶装置上にロードされ、データモデル変換処理部107、インタフェース変換処理部108、プロトコル変換処理部109の各部が主記憶装置上に生成されるようになっている。また、上述したソフトウェアプログラムは、インストール可能な形式又は実行可能な形式のファイルでCD-ROM、フレキシブルディスクFD、CD-R、DVDDigitalVersatileDisc等のコンピュータで読み取り可能な記録媒体に記録されて提供することも可能である。さらに、これらのソフトウェアプログラムを、ネットワーク経由でダウンロードさせて提供または配布するように構成してもよい。続いて、外部定義される項目の例を図2に示す。図2は、外部定義される項目データモデル外部定義110、インタフェース外部定義111、プロトコル外部定義112の例を示す図である。なお、図2では、データモデル外部定義110と、インタフェース外部定義111と、プロトコル外部定義112とを1つのテーブルとして示しているが、これらのぞれぞれは、図1に示したように、データモデル変換処理部107、インタフェース変換処理部108、プロトコル変換処理部109に、それぞれアクセス可能なように対応付けられている。図2に示すように、データモデル外部定義110は、内部システム1010のアプリケーション処理部102で用いられるデータモデルと、外部システム1020のアプリケーションやデータベース104で用いられるデータモデルとの対応関係を記憶するものである。データモデル外部定義110では、アプリケーション102で用いられるデータごとに、所定の規格に従って定められた形式のデータをどの形式のデータに変換させるかを定めている。また、インタフェース外部定義111は、データモデル外部定義110と同様に、内部システム1010のアプリケーション処理部102で用いられるインタフェースと、外部システム1020のアプリケーションやデータベース104で用いられるインタフェースとの対応関係を記憶するものである。インタフェース外部定義111では、アプリケーション102で用いられるインタフェースごとに、所定の規格に従って定められた形式のインタフェースをどの形式のデータに変換させるかを定めている。さらに、プロトコル外部定義112は、インタフェース手続きパターンと、通信プロトコル形態と、通信定義と、システム構成ネットワーク形態と、ネットワーク性能と、非機能要件とが定義されている。ここで、非機能要件とは、上述したインタフェース手続きパターン、通信プロトコル形態、通信定義、システム構成ネットワーク形態、ネットワーク性能の各機能要件以外の要件を指すものである。非機能要件は、個々のアプリケーションに応じて定義が必要となるものアプリケーションに共通に定義できないものであり、アプリケーション固有の要件項目、条件、組み込み関数、追加定義が定義されている。インタフェース手続きパターンは、アプリケーションで用いられるインタフェースごとに定められたアプリケーション実行時の手続きのパターンであり、リクエスト/リプライ型、パブリッシュ/サブスクライブ型、一方向型の3つのパターンのいずれかが設定される。ここで、リクエスト/リプライ型とは、図3に示すように、アクセスを行う要求側システムの要求例えば、内部システム1010からの要求に同期して、被要求側システム例えば、外部システム1020が応答を返す形態である。このパターンの場合、インタフェース手続きパターンとしては、データモデル変換、インタフェース変換、プロトコル変換、データモデル変換の順に変換処理が行われることとなる。また、パブリッシュ/サブスクライブ型とは、図4に示すように、アクセスの要求側システム例えば、内部システム1010が、応答間隔等の所定の条件を被要求側システム例えば、外部システム1020に登録しておくことにより、条件に応じた形で被要求側システムから要求側へ応答が返される形態である。このパターンの場合、データモデル変換、インタフェース変換、プロトコル変換、データモデル変換、プロトコル変換の順に変換処理が行われることとなる。さらに、一方向/待受け型データ送信とは、図5に示すように、片方のシステム例えば、内部システム1010からのデータ送信等が、送信先のシステム例えば、外部システム1020の要求等に関係無く一方的に送られる形態である。このパターンの場合、データモデル変換、プロトコル変換の順に変換処理が行われることとなる。このように、インタフェース手続きパターンには、システム間でどのような順序の手続きによってアプリケーションを実行するかが定められている。通信プロトコル形態は、上述したリクエスト/リプライ型、パブリッシュ/サブスクライブ型一方向型の各パターンで用いられる通信プロトコルの形態であり、リクエスト/リプライ型、パブリッシュ/サブスクライブ型一方向型のいずれかが設定される。通信定義は、上述した通信プロトコル形態による通信プロトコルおよびその通信プロトコルにより通信を行うミドルウェアにおける処理で用いられる種々の定義が設定される。システム構成ネットワーク形態は、内部システム1010および外部システム1020とのシステム構成及びネットワーク形態に関する情報が設定される。ネットワーク性能は、ネットワークNにおいて保証される通信速度等、通信に関する性能情報が設定される。非機能要件要件項目は、上述したネットワーク性能以外の性能、例えば、内部システム1010や外部システム1020等の個々のシステムの性能、データの信頼性、システムのセキュリティレベル例えば、セキュリティ性能、セキュリティ仕様等、非機能要件として設定可能な項目が設定される。非機能要件条件は、上述した要件項目において設定された非機能要件に関して達成するべき条件、例えば、システムレスポンスの下限値等、要件項目に関する条件が設定される。非機能要件組み込み関数は、内部システム1010の開発者が個別に作成した組み込み関数の定義、例えば、プロトコル変換する関数の定義等、組み込み関数に関する定義が設定される。非機能要件追加定義は、上述した非機能要件以外の要件、例えば、プロトコル変換処理を実行させるために必要な上述した非機能要件以外の定義等が設定される。続いて、内部システム1010が外部システム1020に接続してこれらのシステム間を連携させるためのミドルウェアを構築する際の手順の例について述べる。図6は、上述したシステム間連携方法の手順を示すフローチャートである。図6に示すように、まず、サーバ101は、システム構築者により決定された、接続先となる外部システムの指定、および対応が必要な規格仕様の指定を受け付けた後ステップS601、システム構築者から、接続連携対象となる外部システム1020毎に、図2に示した外部定義される項目1~11の設定を受け付け、アプリケーション処理部102から外部システム1020への接続連携を行うため、受け付けられた上記1~11までの定義情報を参照し、データモデル変換処理部107、インタフェース変換処理部108、プロトコル変換処理部109は、各々必要な変換処理を実行するステップS602。そして、プロトコル変換処理部109は、プロトコルの変換処理において、上記項目3~5は、手続きの形態と使用する通信プロトコルの組み合わせに対する処理実施形態を選定するための定義情報であるため、図7に示す手続き通信プロトコルの組み合わせ実施形態処理モジュールを選定する処理組み合わせ処理を行うステップS603。図7は、組み合わせ処理部113が行う組み合わせ処理の処理手順を示すフローチャートである。図7に示すように、まず、組み合わせ処理部113は、アプリケーション処理部102が要求するインタフェース手続きパターンが、リクエスト/リプライ型、パブリッシュ/サブスクライブ型、一方向型のいずれであるかを判別するステップS701。そして、組み合わせ処理部113は、アプリケーション処理部102が要求するインタフェース手続きパターンが、リクエスト/リプライ型であると判定した場合、さらに、外部システム1020と内部システム1010のサーバ101と間で実施される通信プロトコルのパターンが、リクエスト/リプライ型、パブリッシュ/サブスクライブ型、一方向型のいずれであるかを判別し、適用する手続き通信プロトコルの組み合わせ実施形態処理モジュールを選定するステップS702-1。通信プロトコルのパターンがリクエスト/リプライ型であると判別した場合、アプリケーション処理部102が要求するインタフェース手続きパターンがリクエスト/リプライ型であり、実際の外部システム1020と内部システム1010のサーバ101間で行われる通信のプロトコルがリクエスト/リプライ型の場合、選定されたモジュールは、そのまま、そのアプリケーションと外部システム1020との間で、リクエスト/リプライ型によるアクセスを行うステップS703、図8A。一方、通信プロトコルのパターンがパブリッシュ/サブスクライブ型であると判別した場合、アプリケーション処理部102が要求するインタフェース手続きパターンがリクエスト/リプライ型であり、実際の外部システム1020と内部システム1010のサーバ101間で行われる通信のプロトコルがパブリッシュ/サブスクライブ型の場合、選定されたモジュールは、そのアプリケーションと外部システム1020との間に、そのアプリケーションからのアクセスを受け付けるキャッシュデータベースを用意し、外部システム1020からのパブリッシュ/サブスクライブを受けてそのキャッシュデータベースを更新しながら、そのアプリケーションからのリクエストに対してリプライを返す処理をキャッシュデータベースで行うステップS704、図8D。さらに、アプリケーション処理部102が要求するインタフェース手続きパターンがリクエスト/リプライ型であり、実際の外部システム1020と内部システム1010のサーバ101間で行われる通信のプロトコルが一方向型の場合、これに対応するためには外部システム1020側でそのプロトコルに対応する機能の作りこみが必須となるため、ここでは対象外とするステップS705。一方、組み合わせ処理部113は、ステップS701において、アプリケーション処理部102が要求するインタフェース手続きパターンが、パブリッシュ/サブスクライブ型であると判定した場合、さらに、外部システム1020と内部システム1010のサーバ101と間で実施される通信プロトコルのパターンが、パブリッシュ/サブスクライブ型、リクエスト/リプライ型、一方向型のいずれであるかを判別し、適用する手続き通信プロトコルの組み合わせ実施形態処理モジュールを選定するステップS702-2。アプリケーション処理部102が要求するインタフェース手続きパターンがパブリッシュ/サブスクライブ型であり、実際の外部システム1020と内部システム1010のサーバ101間で行われる通信のプロトコルがパブリッシュ/サブスクライブ型の場合、選定されたモジュールは、そのまま、そのアプリケーションと外部システム1020との間でパブリッシュ/サブスクライブ型によるアクセスを行うステップS706、図8B。一方、アプリケーション処理部102が要求するインタフェース手続きパターンがパブリッシュ/サブスクライブ型であり、実際の外部システム1020と内部システム1010のサーバ101間で行われる通信のプロトコルがリクエスト/リプライ型の場合、選定されたモジュールは、そのアプリケーションと外部システム1020との間に、そのアプリケーションからのアクセスを受け付けるキャッシュデータベースを用意し、外部システム1020に対して随時リクエスト/リプライを実行してキャッシュデータベースを更新しながら、そのアプリケーションからのサブスクライブに対してパブリッシュを返す処理をキャッシュデータベースで行うステップS707、図8E。さらに、アプリケーション処理部102が要求するインタフェース手続きパターンがパブリッシュ/サブスクライブ型であり、実際の外部システム1020と内部システム1010のサーバ101間で行われる通信のプロトコルが一方向型の場合、これに対応するためには外部システム1020側でそのプロトコルに対応する機能の作りこみが必須となるため、ここでは対象外とするステップS708。さらに、組み合わせ処理部113は、ステップS701において、アプリケーション処理部102が要求するインタフェース手続きパターンが、一方向型であると判定した場合、さらに、外部システム1020と内部システム1010のサーバ101と間で実施される通信プロトコルのパターンが、リクエスト/リプライ型、パブリッシュ/サブスクライブ型、一方向型のいずれであるかを判別し、適用する手続き通信プロトコルの組み合わせ実施形態処理モジュールを選定するステップS702-3。アプリケーション処理部102が要求するインタフェース手続きパターンが一方向型であり、実際の外部システム1020と内部システム1010のサーバ101間で行われる通信のプロトコルがリクエスト/リプライ型の場合、選定されたモジュールは、そのアプリケーションと外部システム1020の間に、そのアプリケーションに対する一方向のデータ送信を実行するキャッシュデータベースを用意し、外部システム1020に対して随時リクエスト/リプライを実行してキャッシュデータベースを更新しながら、そのアプリケーションに対して一方向のデータ送信を実行する処理をキャッシュデータベースで行うステップS709、図8F。一方、アプリケーション処理部102が要求するインタフェース手続きパターンが一方向型であり、実際の外部システム1020とのサーバ間で行われる通信のプロトコルがパブリッシュ/サブスクライブ型の場合、選定されたモジュールは、そのアプリケーションと外部システム1020の間に、そのアプリケーションに対する一方向のデータ送信を実行するキャッシュデータベースを用意し、外部システム1020からのパブリッシュ/サブスクライブを受けてキャッシュデータベースを更新しながら、そのアプリケーションに対して一方向のデータ送信を実行する処理をキャッシュデータベースで行うステップS710、図8G。さらに、アプリケーション処理部102が要求するインタフェース手続きパターンが一方向型であり、実際の外部システム1020と内部システム1010のサーバ101間で行われる通信のプロトコルが一方向型の場合、選定されたモジュールは、そのまま、そのアプリケーションと外部システム1020との間で一方向型のアクセスを行うステップS711、図8C。続いて、図6に戻り、ステップS604以降の処理について説明する。そして、非機能要件処理部114は、非機能要件を充足するために必要な処理実施の形態を選定するための定義情報である項目8~11を設定するために、内部システム1010の開発者等によってあらかじめ用意された非機能要件達成処理モジュールの中から、外部システム1020との接続に適用する非機能要件達成処理モジュールを選定するステップS604。具体的には、非機能要件処理部114は、非機能要件要件項目のうちの性能に関する非機能要件については、事前にアプリケーション開発者あるいはシステム開発者管理者によって設定された、個々のアプリケーションあるいはシステムにおいて必要とする性能要件値例えば、プロトコル変換の速度を参照し、そのアプリケーションあるいは内部システム1010との間で変換対象となる外部システム1020について、アクセス手続きの形態と使用する通信プロトコルの組み合わせを選択し、これに対する処理実施形態を選定する。また、非機能要件処理部114は、内部システム1010およびネットワーク性能に関して、あらかじめ計測調査され定義されている性能情報や、随時のパフォーマンステストによって得られる情報より取得する。このパフォーマンステストは、新しい外部システム1020との接続連携が必要になった際にその都度実施しても良いし、すべての外部システム1020との接続連携の発生時にその都度実施しても良い。さらに、非機能要件処理部114は、これらの性能要件値と、内部システム1010およびネットワーク性能との比較、および設定された通信プロトコルを用いた処理を行うことにより、それらの性能要件値を満たすか否かという観点から、利用する非機能要件達成処理モジュールを選定する。具体的には、非機能要件処理部114は、それらの性能要件値を達成するためにネットワーク性能が大幅に不足すると判断した場合は、アクセス要求先からアクセス要求元のサーバ上にデータのレプリケーションを生成し、そのアプリケーション処理がこのレプリケーションに対してアクセスを実行する非機能要件達成処理モジュールを選択する。あるいは、非機能要件処理部114は、それらの性能要件値を達成するためにネットワーク性能が理論上は十分であるものの、トラフィックの状況等により不十分になる可能性がある程度の性能であると判断した場合は、アクセス要求元とアクセス要求先の間で通信コネクションを生成し、常時、一定の性能での通信を確保する非機能要件達成処理モジュールを選択する。このように、非機能要件処理部114は、アプリケーション102に適したモジュールを選択し、アプリケーション102と外部システム1020との間の処理を適切な状態で実行させることを可能としている。また、非機能要件処理部114は、非機能要件要件項目のうちのデータの信頼性に関する非機能要件については、アプリケーション開発者あるいはシステム開発者管理者によって設定された、個々のアプリケーションあるいはシステムにおいて必要とするデータの信頼性要件値を参照し、そのアプリケーションあるいは内部システム1010との間で変換対象となる外部システム1020について、手続きの形態と使用する通信プロトコルの組み合わせを選択し、これに対する処理実施形態を選定する。また、非機能要件処理部114は、ネットワーク形態をあらかじめ定義されている情報より取得する。また、必要に応じて信頼性を検証するテストを実施する。この信頼性検証は、新しい外部システム1020との接続連携が必要になった際にその都度実施しても良いし、すべての外部システム1020との接続連携の発生時にその都度実施しても良い。これらの設定値および情報から、信頼性要件値に対するプロトコルおよびネットワークの品質の比較、および通信プロトコルネットワーク形態に対して実施すべき項目の要否から、利用する非機能要件達成処理モジュールを選定する。具体的には、非機能要件処理部114は、ネットワーク性能上の余裕が十分あり、アプリケーション処理自体も高速に行う必要があり、かつ信頼性要求が非常に高い場合は、通信自体を多重化する非機能要件達成処理モジュールを選定する。あるいは、非機能要件処理部114は、ネットワーク性能は十分に余裕があるとは言えず、アプリケーション処理自体にはそれほど高速処理を処理されていないが、信頼性要求が高い場合には、必要に応じてデータの再送要求を行う非機能要件達成処理モジュールを選定する。CRCCyclicRedundancyCheck等の一般的なデータ完全性チェックに対応可能な機能を対象外部システムが有している場合などでは、それらの機能を利用してデータ完全性をチェックする非機能要件達成処理モジュールを選定する。さらに、非機能要件処理部114は、非機能要件要件項目のうちのセキュリティに関する非機能要件については、アプリケーション開発者あるいはシステム開発者管理者によって設定された、個々のアプリケーションあるいはシステムにおいて必要とするセキュリティ要件値を設定し、そのアプリケーションあるいは内部システム1010との間で変換対象となる外部システム1020について、手続きの形態と使用する通信プロトコルの組み合わせを選択し、これに対する処理実施形態を選定する。また、非機能要件処理部114は、システム構成をあらかじめ定義されている情報から取得し、また、対象となる外部システム1020のセキュリティ仕様性能の判定を、あらかじめ定義されている情報か、あるいは随時のアクセステストによって得られる情報より取得する。このセキュリティテストは、新しい外部システム1020との接続連携が必要になった際にその都度実施しても良いし、すべての外部システム1020との接続連携の発生時にその都度実施しても良い。これらの設定値および情報から、対象となる外部システム1020が必要となるセキュリティレベルを有しているか等の判定を行い、また、通信プロトコルシステム構成に対して必要なセキュリティ処理が実施可能か否かの判定を行った上で、利用する非機能要件達成処理モジュールを選定する。具体的には、非機能要件処理部114は、対象となる外部システム1020が、必要なセキュリティ要件に対応できないと判定した場合には、その外部システムへのアクセスを遮断したり、あるいは、データ取得は許容するがデータ更新は許容しない等といった部分的にアクセスをフィルタリングする非機能要件達成処理モジュールを選定する。あるいは、非機能要件処理部114は、共通の認証基盤を利用可能な外部システム1020が対象であれば、この認証基盤を利用して内部システム1010と外部システム1020の認証を行う非機能要件達成処理モジュールを選定する。あるいは、所定の暗号複合化機能に対応した外部システム1020であれば、この暗号複合化機能を利用する非機能要件達成処理モジュールを選定する。そして、プロトコル変換処理部113は、以上により非機能要件処理部114によって選択された処理モジュールによって構成されたミドルウェアを生成しステップS605、生成したミドルウェアを内部システム1010が有しているアプリケーションが動作しているサーバ101に組み込むステップS606。このようなミドルウェアをサーバ101に組み込むことにより、例えば、ネットワークを介して相互接続した複数の独立したノードにより構成される分散システムにおいて、同一の規格や仕様に準拠したデータ管理及びデータアクセス処理を行う、1つ以上のノードを含むシステムおよびそのシステムとは異なるシステムとの間の相互接続および連携させることが可能となる。より具体的には、システム間の相互接続連携の際に、各々異なるシステムが準拠する規格等に基づくデータモデル、インタフェース、プロトコルの3階層にて、異なるシステム間の相互変換を実施し、プロトコルの階層では、手続きの形態のパターン、手続きの形態と使用する通信プロトコルの形態の組み合わせに対して変換の実施パターンおよび非機能要件を充足するための処理パターンを用意し、これらを共通部品とする一方、接続連携する相手システム毎に相互接続連携のための前記各階層での変換処理を、各々の共通部品の組み合わせにより実現し、これらの共通備品の組み合わせは、接続連携する相手システム毎に外部定義として指定する。このようなプロトコルの階層にて、異なる規格仕様のシステムと相互接続するための処理を実行するプログラム処理モジュールおよびシステム構成等に応じてアプリケーションが要求する非機能要件を充足するための処理モジュールを、外部定義にしたがって選出し、構成しているので、異なる規格や仕様のシステムとの接続連携が必要となるアプリケーションの開発において、個々の接続連携処理の開発がアプリケーション自体の開発と分割され、アプリケーション開発者が直接考慮する必要がなくなった上で、個々の接続連携処理の開発自体も容易化され、全体としてのシステム、アプリケーション開発の生産性を向上させることができる。上述した実施例1においては、アプリケーション処理部が外部システムに対してアクセスする際に必要な処理をミドルウェアが行うことにより、アプリケーション開発者等が外部システムとの間の変換処理を考慮することなく適切なモジュールの組み合わせを選択し、両者のデータの受け渡し等を可能とした。しかし、図9に示すように、実施例2においては、複数のサーバ907が有する個々のアプリケーション処理部901から外部システム1020にアクセスする際に必要な処理を、通信経路上のゲートウェイサーバ905が有する内部記憶装置115に記憶されたミドルウェア902で行うこととする。この場合、各々のサーバ907のアプリケーション処理部901を一意に識別するために、ミドルウェア902に対応付けて識別情報904があらかじめ設定され、個々のアプリケーション処理部901の識別情報903とミドルウェアの識別情報904の組み合わせを、アプリケーション処理/ミドルウェア組み合わせ管理DBDataBase906により管理する。その上で、ミドルウェア902を、アプリケーション処理部901が動作しているサーバ907上ではなく、別のサーバ、例えば、外部システム1020と内部システム1010との間に設置されたゲートウェイサーバ905上に組み込む。そして、アプリケーション処理部901が外部システム1020にアクセスする際、アプリケーション処理部901の識別情報903と、ミドルウェアの識別情報904とを照合し、アプリケーション処理部901の識別情報903とミドルウェア902の識別情報904の組み合わせを管理しているアプリケーション処理/ミドルウェア組み合わせ管理DB906を参照して、アプリケーション処理-ミドルウェア組合せ制御部908により、アプリケーションに対応するミドルウェアを自動的に選択してゲートウェイサーバ905上で動作させる。このように構成することで、実施例1の場合と同様に、外部システムに対するアクセスを実現する。この方式によると、アプリケーション処理部901が動作しているサーバ907には新規のミドルウェア等の組み込み等、手を加える必要が一切無くなり、既設システム等をそのまま利用した上で外部システム1020と接続連携することが可能となる。また、新しいアプリケーションがシステム内に導入された際に、そのアプリケーションの識別情報903を参照して、上述した実施例1に記載の方法により、その都度ミドルウェア902を自動的に生成して利用してもよい。上述した実施例1においては、アプリケーション処理部102が外部システムに対してアクセスする際に必要な処理をミドルウェアが行うことにより、アプリケーション開発者等が外部システムとの間の変換処理を考慮することなく適切なモジュールの組み合わせを選択し、両者のデータの受け渡し等を可能となり、また、上述した実施例2においては、データアクセスを実施するアプリケーション処理自体と切り離して、別のサーバ上にこの機能を配置することを可能とした。しかし、外部システムからの要求に応じて内部システムが種々の処理を行う場合もある。そこで、図10に示すように、実施例3においては、このようなミドルウェア機能を、例えば、内部システム1210で利用されているデータが格納されているデータベース1004が配置されているデータベースサーバ1001上に配置する。このとき、外部システム1220から内部システム1210にアクセスする際に、規格あるいは仕様を選択し、実施例1に記載の手順でミドルウェア902を構築し、そのミドルウェア902によってデータモデル変換、インタフェース変換、プロトコル変換を行った上でデータベース1004にアクセスして、外部システム1220が要求する処理を行う。また、外部システム1220上のアプリケーション処理部1002の識別情報は取得不可能である場合が多いため、アプリケーション処理の識別情報とミドルウェアの識別情報との対応付けではなく、要求種別/ミドルウェア組合せ選択部1006が、外部システム1220からの要求がどのような種別であるかを要求メッセージ等のプロトコルから抽出し、この要求の種別とミドルウェア902の識別情報1003の対応付け情報を要求種別/ミドルウェア組み合わせ管理DB1005により管理することによって、実施例2の場合と同様に、対応するミドルウェアを自動的に選択する処理をデータベースサーバ1001上で動作させる。これにより、外部システム1220から内部システム1210のデータへのアクセスに対応可能となる。なお、本発明は、上記実施の形態そのままに限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で構成要素を変形して具体化することができる。また、上記実施の形態に開示されている複数の構成要素の適宜な組み合わせにより、種々の発明を形成することができる。例えば、実施の形態に示される全構成要素からいくつかの構成要素を削除してもよい。さらに、異なる実施の形態にわたる構成要素を適宜組み合わせても良い。