分散システムにおけるシステム間連携装置
【課題】アプリケーション開発の生産性を向上させることが可能な分散システムにおけるシステム間連携装置を提供する。
【解決手段】他のシステム１０２０にアクセスして所定のアプリケーションを実行させるためのアプリケーション処理部１０２と、アプリケーション処理部１０２が所定のアプリケーションの実行指示を受けた場合に、所定のアプリケーションからの要求に応じて、プロトコル定義に含まれる通信プロトコル形態およびシステム構成およびネットワーク構成に基づいて定められるシステム１０１０と他のシステム１０２０との間の処理を行うために必要な要件値と非機能要件との組み合わせに基づいて、複数のモジュールの中からアプリケーションによる処理を実行させるために必要なモジュールを選択する組合せ処理部１１３と、を備える。
【解決手段】他のシステム１０２０にアクセスして所定のアプリケーションを実行させるためのアプリケーション処理部１０２と、アプリケーション処理部１０２が所定のアプリケーションの実行指示を受けた場合に、所定のアプリケーションからの要求に応じて、プロトコル定義に含まれる通信プロトコル形態およびシステム構成およびネットワーク構成に基づいて定められるシステム１０１０と他のシステム１０２０との間の処理を行うために必要な要件値と非機能要件との組み合わせに基づいて、複数のモジュールの中からアプリケーションによる処理を実行させるために必要なモジュールを選択する組合せ処理部１１３と、を備える。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、例えば、ネットワークを介して接続された複数の分散システム間におけるシステムの連携装置に関するものである。
【背景技術】
【０００２】
電力分野システムなどにおいては、電源の多様化、地域・家庭等のエネルギーマネジメントの拡大等から、制御・監視対象の拡大、データ利用範囲の拡大、異なるシステム間での連携、異なる業務間での連携などが進展している。一方で、海外では、システム仕様やアプリケーションインターフェース、データモデル等の国際標準規格を整備することで上記に対応する動きが広がっており、ＩＥＣ（The International Electrotechnical Commission）などで個々の標準規格の整備が進められている。ただし、基本的には分野や業務種別、レイヤなど毎に標準規格が整備されており、前記の特に異なるシステム間での連携、異なる業務間での連携などを想定する場合には、複数の標準規格を跨ったアプリケーション開発が必要となる場合も多い。また、標準規格が未整備な分野、業務種別等では、システム開発に参加しているベンダーが個別の仕様に従ってシステム開発を実施する場合も多く、この場合は、標準規格というよりも、異なる複数の仕様を跨ったアプリケーション開発が必要となる。
【０００３】
このような異なる複数の仕様を跨ったアプリケーション開発への対応として、例えば、特許文献１には、管理装置と設備装置との間でデータフォーマットが異なる場合、両装置の間の通信を行う通信ドライバにてデータ変換を実施し、設備の属性、機能オブジェクト等をマークアップ言語で記述し、設備毎の機能クラス情報とコンフィグレーション情報を用いて各々変換する方式が提案されている。
【０００４】
また、特許文献２には、異なるインタフェースを持った１個以上のソフトウェアコンポーネントを再利用する場合、各インタフェース記述からメソッド及び引数の順序による差違を吸収し、メソッド及び引数の対応関係を抽出し、再利用コンポーネントを集約しクライアント側インタフェースを実装するコードを自動生成する方式が提案されている。
【０００５】
さらに、特許文献３には、システム毎にシステム間連携装置を配置し、各システムでの通信プロトコルにより送信されたデータを上記システム間連携装置が他システムに転送し、受信したシステム間連携装置にて、受信データより共通データ、自システムにて必要なデータを抽出し、自システムの通信プロトコルを用いて自システム内に改めて送信する方式が提案されている。
【先行技術文献】
【特許文献】
【０００６】
【特許文献１】特開２００７−５１４３３５号公報
【特許文献２】特開平１１−３５３１６８号公報
【特許文献３】特開２０１０−６７１８１号公報
【発明の概要】
【発明が解決しようとする課題】
【０００７】
しかしながら、上述した特許文献１〜３に開示されている技術では、システム間の相互接続の際に、データモデル、インタフェースまたは通信プロトコルのいずれか１つの変換のみを実施している。このためデータモデル、インタフェース、プロトコルのうち２つ以上が異なる場合には対応できず、接続の際に不具合が生じ得る。また、相互接続する異なる２つのシステム毎に個別に変換及び接続のための処理を全て作り込む必要があり、接続先・対応規格の数が増えるとこれらの処理を作り込む負荷が増大する。
【０００８】
さらに、個々のアプリケーションが要求する要件である非機能要件を満たすための処理を、各アプリケーション側で作り込む必要がある。このため、接続先の追加・変更に伴うアプリケーションの改修負荷が増大する。また、特許文献３では、システム間連携装置にて固定の手続きを連携用の固定の通信プロトコル上で実現しているのみである。このためインタフェース実行に伴う手続きの形態と接続先システムにて使用する通信プロトコルの形態に差異が有る場合、接続及び手続き実施ができない。
【０００９】
このように、異なる規格や仕様に準拠したシステムが複数混在運用される環境においては、個々の異なるシステム間を接続・連携するための処理を、本来の個々のアプリケーション処理自体とは別に、接続・連携毎に個別に開発する必要がある。混在運用される異なるシステムが多数になればなるほど、開発する必要のある、システム間の接続・連携処理が増えるとともに、処理自体も複雑化し、開発の労力や工数が肥大化することになる。また、接続・連携対象となるシステムの規格や仕様の詳細を把握した上で接続・連携処理を開発する必要があるため、アプリケーション開発者の負担が増大することになる。
【００１０】
このような状況に鑑み、本発明は、異なる規格や仕様に準拠する複数の異なるシステム間の相互接続および連携を行う際に、アプリケーション処理としての作りこみは排除した上で、アプリケーション開発者からは意識されないミドルウェアにて相互接続のための処理（規格・仕様間の相互変換）および実際の接続・連携時に必要となる非機能要件を充足するための処理を実施し、その上で、ミドルウェア機能としての個々の接続・連携処理の開発を容易化し、アプリケーション開発の生産性を向上させることが可能な分散システムにおけるシステム間連携装置を提供することを目的とする。
【課題を解決するための手段】
【００１１】
上述した課題を解決し、目的を達成するために、本発明にかかるシステム間連携装置は、所定の規格あるいは仕様に準拠して作成されたシステムから前記システムとは異なる規格あるいは仕様に準拠して作成された他のシステムへのアクセスが可能な分散システムにおけるシステム間連携装置であって、前記システムと前記他のシステムとの間における通信プロトコルの形態と前記システムおよび前記他のシステムのシステム構成およびネットワーク構成とを対応付けたプロトコル定義と前記システムが所定のアプリケーションにより前記他のシステムにアクセスするための前記所定のアプリケーションに固有の要件である非機能要件と、前記プロトコル定義および前記非機能要件に応じた前記アプリケーションを実行させるための複数のモジュールと、を記憶する記憶部と、前記他のシステムにアクセスして前記所定のアプリケーションを実行させるためのアプリケーション処理部と、前記アプリケーション処理部が前記所定のアプリケーションの実行指示を受けた場合に、前記所定のアプリケーションからの要求に応じて、前記プロトコル定義に含まれる前記通信プロトコル形態および前記システム構成および前記ネットワーク構成に基づいて定められる前記システムと前記他のシステムとの間の処理を行うために必要な要件値と前記非機能要件との組み合わせに基づいて、前記複数のモジュールの中から前記アプリケーションによる処理を実行させるために必要なモジュールを選択する組合せ処理部と、を備えることを特徴とする。
【発明の効果】
【００１２】
本発明によれば、アプリケーション開発の生産性を向上させることが可能な分散システムにおけるシステム間連携装置を提供することができるという効果を奏する。
【図面の簡単な説明】
【００１３】
【図１】第１の実施の形態における分散システムの構成例を示す図である。
【図２】外部定義される項目（データモデル外部定義、インタフェース外部定義、プロトコル外部定義）の例を示す図である。
【図３】第１の実施の形態におけるリクエスト／リプライ型の手続きパターンの概略を示す図である。
【図４】第１の実施の形態におけるパブリッシュ／サブスクライブ型の手続きパターンの概略を示す図である。
【図５】第１の実施の形態における一方向型の手続きパターンの概略を示す図である。
【図６】第１の実施の形態におけるシステム間連携方法の手順を示すフローチャートである。
【図７】組み合わせ処理部が行う組み合わせ処理の処理手順を示すフローチャートである。
【図８】第１の実施の形態における各処理モジュールの動作概要を示す図である。
【図９】第２の実施の形態における分散システムの構成例を示す図である。
【図１０】第３の実施の形態における分散システムの構成例を示す図である。
【発明を実施するための形態】
【００１４】
以下に添付図面を参照して、本発明にかかる分散システムにおけるシステム間連携装置の実施の形態を詳細に説明する。
【実施例１】
【００１５】
図１は、第１の実施の形態における分散システム１０００の構成例を示す図である。図１に示すように、分散システム１０００は、内部システム１０１０と外部システム１０２０とを含んで構成されている。なお、内部システム１０１０と外部システム１０２０とは、例えば、インターネット等の一般的なネットワークＮによって接続されているものとする。
【００１６】
内部システム１０１０は、利用者によって使用される所定のアプリケーションを有した外部システム１０２０とは異なるシステムであり、サーバ１０１（システム間連携装置）の内部記憶装置１１５に組み込まれているものである。内部記憶装置１１５には、内部システム１０１０にアクセス可能な利用者が使用する複数のアプリケーションを実行するアプリケーション処理部１０２と、それらのアプリケーション処理部１０２を一意に識別するための識別情報１０５とが対応付けて記憶されている。
【００１７】
また、内部記憶装置１１５には、ミドルウェア１０６が記憶されている。ミドルウェア１０６は、データモデル変換処理部１０７と、インタフェース変換処理部１０８と、プロトコル変換処理部１０９とを有している。
【００１８】
データモデル変換処理部１０７は、内部システム１０１０と外部システム１０２０との間で共有するデータの共通的な意味付けを行う（例えば、各システムで用いられるデータをいずれもＣＩＭ（common information model）に従ったデータモデルにする）ものであり、内部システム１０１０で用いられるデータモデルを外部システム１０２０で用いられるデータモデルに変換する。また、図１に示すように、データモデル変換処理部１０７は、データモデル外部定義１１０にアクセス可能となっている。データモデル外部定義１１０は、外部システム１０２０が有しているデータモデルとの間の変換を行うためのデータモデルに関する各種の対応付けを定義した情報であり、図２を用いて後述する。
【００１９】
インタフェース変換処理部１０８は、内部システム１０１０が有するアプリケーション１０２が要求する処理の指定方法を定める（例えば、内部システム１０１０で用いられているインタフェースを外部システム１０２０で用いられているオープン規格のインタフェースにする）ものであり、データモデル変換処理部１０７と同様に、内部システム１０１０で用いられるインタフェースを外部システム１０２０で用いられるインタフェースに変換する。また、図１に示すように、インタフェース変換処理部１０８は、インタフェース外部定義１１１にアクセス可能となっている。インタフェース外部定義１１１は、データモデル外部定義１１０と同様に、外部システム１０２０が有しているインタフェースとの間の変換を行うためのインタフェースに関する各種の対応付けを定義した情報であり、図２を用いて後述する。
【００２０】
プロトコル変換処理部１０９は、内部システム１０１０と外部システム１０２０との間でデータをやり取りするための手続き、通信の様式を定めるものであり、データモデル変換処理部１０７等と同様に、内部システム１０１０で用いられるプロトコルを外部システム１０２０で用いられるプロトコルに変換する。また、図１に示すように、プロトコル変換処理部１０９は、プロトコル外部定義１１２にアクセス可能となっている。プロトコル外部定義１１２は、データモデル外部定義１１０等と同様に、外部システム１０２０が有しているプロトコルとの間の変換を行うためのプロトコルに関する各種の対応付けを定義した情報であり、図２を用いて後述する。
【００２１】
ネットワークアクセス部１１６は、内部システム１０１０と外部システム１０２０との間の通信を司るものである。
【００２２】
このような構成において、サーバ１０１上で動作している個々のアプリケーション処理部１０２が、内部システム１０１０で用いられる規格や仕様とは異なる規格や仕様に準拠した外部システム１０２０に含まれるサーバ１０３上のデータ（例えば、データベース１０４に格納されているデータ）に対してアクセスする際について考える。この場合、まずアプリケーション処理部１０２が存在する内部システム１０１０が有する規格や仕様に準拠した形式でデータモデルやインタフェースが指定される。内部システム１０１０は、複数のアプリケーションを有しており、上述した識別情報１０５を指定することによってアプリケーションが使用可能となる。
【００２３】
さらに、指定されたアプリケーションの下層で動作するミドルウェア１０６は、アプリケーション処理部１０２からの指定を受けて、外部システム１０２０にアクセスするための種々の規格や仕様に関する変換処理を行う。変換処理では、外部システム１０２０の規格や仕様に準拠したデータモデルへの変換、インタフェースの変換、プロトコルの変換の３階層によって変換処理が行われる。このとき、内部システム１０１０が有するデータモデルと外部システム１０２０が有するデータモデルとの間の変換を実際に行うためのデータモデル間の対応付けや変換定義は、外部定義化して上述したデータモデル外部定義１１０に保持され、データモデル変換処理部１０７が必要に応じて随時この外部定義を参照することによりデータモデル変換の処理を実行する。
【００２４】
これと同様に、インタフェース変換およびプロトコル変換についても、それぞれ、インタフェース変換処理部１０８がインタフェース外部定義１１１を参照することによりインタフェース変換の処理を実行し、プロトコル変換処理部１０９がプロトコル外部定義１１２を参照することによりプロトコル変換の処理を実行する。
【００２５】
また、プロトコル変換処理部１０９は、組み合わせ処理部１１３と、非機能要件達成処理部１１４によって構成されており、後述するように、アプリケーション開発者による要件の選択、およびシステム設計・開発者によって定義されるシステム構成情報や、都度検証されるシステム性能情報等から、どのような処理モジュールによってプロトコル変換が構成されるかを自動的に決定する手段を提供する。
【００２６】
サーバ１０１が有する上述した各部は、データモデル変換処理部１０７、インタフェース変換処理部１０８、プロトコル変換処理部１０９の各機能を実現するためのソフトウェアプログラムにより実行される。これらのソフトウェアプログラムは、例えば、上述した各部を含むモジュール構成となっており、実際のハードウェアとしては、ＣＰＵ等の制御部がＨＤＤ等の記録装置からこれらのソフトウェアプログラムを読み出して実行することにより、上記各部が主記憶装置上にロードされ、データモデル変換処理部１０７、インタフェース変換処理部１０８、プロトコル変換処理部１０９の各部が主記憶装置上に生成されるようになっている。
【００２７】
また、上述したソフトウェアプログラムは、インストール可能な形式又は実行可能な形式のファイルでＣＤ−ＲＯＭ、フレキシブルディスク（ＦＤ）、ＣＤ−Ｒ、ＤＶＤ（Digital Versatile Disc）等のコンピュータで読み取り可能な記録媒体に記録されて提供することも可能である。さらに、これらのソフトウェアプログラムを、ネットワーク経由でダウンロードさせて提供または配布するように構成してもよい。
【００２８】
続いて、外部定義される項目の例を図２に示す。図２は、外部定義される項目（データモデル外部定義１１０、インタフェース外部定義１１１、プロトコル外部定義１１２）の例を示す図である。なお、図２では、データモデル外部定義１１０と、インタフェース外部定義１１１と、プロトコル外部定義１１２とを１つのテーブルとして示しているが、これらのぞれぞれは、図１に示したように、データモデル変換処理部１０７、インタフェース変換処理部１０８、プロトコル変換処理部１０９に、それぞれアクセス可能なように対応付けられている。
【００２９】
図２に示すように、データモデル外部定義１１０は、内部システム１０１０のアプリケーション処理部１０２で用いられるデータモデルと、外部システム１０２０のアプリケーションやデータベース１０４で用いられるデータモデルとの対応関係を記憶するものである。データモデル外部定義１１０では、アプリケーション１０２で用いられるデータごとに、所定の規格に従って定められた形式のデータをどの形式のデータに変換させるかを定めている。
【００３０】
また、インタフェース外部定義１１１は、データモデル外部定義１１０と同様に、内部システム１０１０のアプリケーション処理部１０２で用いられるインタフェースと、外部システム１０２０のアプリケーションやデータベース１０４で用いられるインタフェースとの対応関係を記憶するものである。インタフェース外部定義１１１では、アプリケーション１０２で用いられるインタフェースごとに、所定の規格に従って定められた形式のインタフェースをどの形式のデータに変換させるかを定めている。
【００３１】
さらに、プロトコル外部定義１１２は、インタフェース手続きパターンと、通信プロトコル形態と、通信定義と、システム構成・ネットワーク形態と、ネットワーク性能と、非機能要件とが定義されている。ここで、非機能要件とは、上述したインタフェース手続きパターン、通信プロトコル形態、通信定義、システム構成・ネットワーク形態、ネットワーク性能の各機能要件以外の要件を指すものである。非機能要件は、個々のアプリケーションに応じて定義が必要となるもの（アプリケーションに共通に定義できないもの）であり、アプリケーション固有の要件項目、条件、組み込み関数、追加定義が定義されている。
【００３２】
インタフェース手続きパターンは、アプリケーションで用いられるインタフェースごとに定められたアプリケーション実行時の手続きのパターンであり、「リクエスト／リプライ型」、「パブリッシュ／サブスクライブ型」、「一方向型」の３つのパターンのいずれかが設定される。
【００３３】
ここで、「リクエスト／リプライ型」とは、図３に示すように、アクセスを行う要求側システムの要求（例えば、内部システム１０１０からの要求）に同期して、被要求側システム（例えば、外部システム１０２０）が応答を返す形態である。このパターンの場合、インタフェース手続きパターンとしては、「データモデル変換」、「インタフェース変換」、「プロトコル変換」、「データモデル変換」の順に変換処理が行われることとなる。
【００３４】
また、「パブリッシュ／サブスクライブ型」とは、図４に示すように、アクセスの要求側システム（例えば、内部システム１０１０）が、応答間隔等の所定の条件を被要求側システム（例えば、外部システム１０２０）に登録しておくことにより、条件に応じた形で被要求側システムから要求側へ応答が返される形態である。このパターンの場合、「データモデル変換」、「インタフェース変換」、「プロトコル変換」、「データモデル変換」、「プロトコル変換」の順に変換処理が行われることとなる。
【００３５】
さらに、「一方向／待受け型（データ送信）」とは、図５に示すように、片方のシステム（例えば、内部システム１０１０）からのデータ送信等が、送信先のシステム（例えば、外部システム１０２０）の要求等に関係無く一方的に送られる形態である。このパターンの場合、「データモデル変換」、「プロトコル変換」の順に変換処理が行われることとなる。このように、インタフェース手続きパターンには、システム間でどのような順序の手続きによってアプリケーションを実行するかが定められている。
【００３６】
通信プロトコル形態は、上述した「リクエスト／リプライ型」、「パブリッシュ／サブスクライブ型」「一方向型」の各パターンで用いられる通信プロトコルの形態であり、「リクエスト／リプライ型」、「パブリッシュ／サブスクライブ型」「一方向型」のいずれかが設定される。
【００３７】
通信定義は、上述した通信プロトコル形態による通信プロトコルおよびその通信プロトコルにより通信を行うミドルウェアにおける処理で用いられる種々の定義が設定される。
【００３８】
システム構成・ネットワーク形態は、内部システム１０１０および外部システム１０２０とのシステム構成及びネットワーク形態に関する情報が設定される。
【００３９】
ネットワーク性能は、ネットワークＮにおいて保証される通信速度等、通信に関する性能情報が設定される。
【００４０】
非機能要件（要件項目）は、上述したネットワーク性能以外の性能、例えば、内部システム１０１０や外部システム１０２０等の個々のシステムの性能、データの信頼性、システムのセキュリティレベル（例えば、セキュリティ性能、セキュリティ仕様）等、非機能要件として設定可能な項目が設定される。
【００４１】
非機能要件（条件）は、上述した要件項目において設定された非機能要件に関して達成するべき条件、例えば、システムレスポンスの下限値等、要件項目に関する条件が設定される。
【００４２】
非機能要件（組み込み関数）は、内部システム１０１０の開発者が個別に作成した組み込み関数の定義、例えば、プロトコル変換する関数の定義等、組み込み関数に関する定義が設定される。
【００４３】
非機能要件（追加定義）は、上述した非機能要件以外の要件、例えば、プロトコル変換処理を実行させるために必要な上述した非機能要件以外の定義等が設定される。
【００４４】
続いて、内部システム１０１０が外部システム１０２０に接続してこれらのシステム間を連携させるためのミドルウェアを構築する際の手順の例について述べる。図６は、上述したシステム間連携方法の手順を示すフローチャートである。
【００４５】
図６に示すように、まず、サーバ１０１は、システム構築者により決定された、接続先となる外部システムの指定、および対応が必要な規格・仕様の指定を受け付けた後（ステップＳ６０１）、システム構築者から、接続・連携対象となる外部システム１０２０毎に、図２に示した外部定義される項目１〜１１の設定を受け付け、アプリケーション処理部１０２から外部システム１０２０への接続・連携を行うため、受け付けられた上記１〜１１までの定義・情報を参照し、データモデル変換処理部１０７、インタフェース変換処理部１０８、プロトコル変換処理部１０９は、各々必要な変換処理を実行する（ステップＳ６０２）。
【００４６】
そして、プロトコル変換処理部１０９は、プロトコルの変換処理において、上記項目３〜５は、手続きの形態と使用する通信プロトコルの組み合わせに対する処理実施形態を選定するための定義・情報であるため、図７に示す手続き・通信プロトコルの組み合わせ実施形態・処理モジュールを選定する処理（組み合わせ処理）を行う（ステップＳ６０３）。
【００４７】
図７は、組み合わせ処理部１１３が行う組み合わせ処理の処理手順を示すフローチャートである。
【００４８】
図７に示すように、まず、組み合わせ処理部１１３は、アプリケーション処理部１０２が要求するインタフェース手続きパターンが、「リクエスト／リプライ型」、「パブリッシュ／サブスクライブ型」、「一方向型」のいずれであるかを判別する（ステップＳ７０１）。
【００４９】
そして、組み合わせ処理部１１３は、アプリケーション処理部１０２が要求するインタフェース手続きパターンが、「リクエスト／リプライ型」であると判定した場合、さらに、外部システム１０２０と内部システム１０１０のサーバ１０１と間で実施される通信プロトコルのパターンが、「リクエスト／リプライ型」、「パブリッシュ／サブスクライブ型」、「一方向型」のいずれであるかを判別し、適用する手続き・通信プロトコルの組み合わせ実施形態・処理モジュールを選定する（ステップＳ７０２−１）。
【００５０】
通信プロトコルのパターンが「リクエスト／リプライ型」であると判別した場合、アプリケーション処理部１０２が要求するインタフェース手続きパターンが「リクエスト／リプライ型」であり、実際の外部システム１０２０と内部システム１０１０のサーバ１０１間で行われる通信のプロトコルが「リクエスト／リプライ型」の場合、選定されたモジュールは、そのまま、そのアプリケーションと外部システム１０２０との間で、リクエスト／リプライ型によるアクセスを行う（ステップＳ７０３、図８（Ａ））。
【００５１】
一方、通信プロトコルのパターンが「パブリッシュ／サブスクライブ型」であると判別した場合、アプリケーション処理部１０２が要求するインタフェース手続きパターンが「リクエスト／リプライ型」であり、実際の外部システム１０２０と内部システム１０１０のサーバ１０１間で行われる通信のプロトコルが「パブリッシュ／サブスクライブ型」の場合、選定されたモジュールは、そのアプリケーションと外部システム１０２０との間に、そのアプリケーションからのアクセスを受け付けるキャッシュデータベースを用意し、外部システム１０２０からのパブリッシュ／サブスクライブを受けてそのキャッシュデータベースを更新しながら、そのアプリケーションからのリクエストに対してリプライを返す処理をキャッシュデータベースで行う（ステップＳ７０４、図８（Ｄ））。
【００５２】
さらに、アプリケーション処理部１０２が要求するインタフェース手続きパターンが「リクエスト／リプライ型」であり、実際の外部システム１０２０と内部システム１０１０のサーバ１０１間で行われる通信のプロトコルが「一方向型」の場合、これに対応するためには外部システム１０２０側でそのプロトコルに対応する機能の作りこみが必須となるため、ここでは対象外とする（ステップＳ７０５）。
【００５３】
一方、組み合わせ処理部１１３は、ステップＳ７０１において、アプリケーション処理部１０２が要求するインタフェース手続きパターンが、「パブリッシュ／サブスクライブ型」であると判定した場合、さらに、外部システム１０２０と内部システム１０１０のサーバ１０１と間で実施される通信プロトコルのパターンが、「パブリッシュ／サブスクライブ型」、「リクエスト／リプライ型」、「一方向型」のいずれであるかを判別し、適用する手続き・通信プロトコルの組み合わせ実施形態・処理モジュールを選定する（ステップＳ７０２−２）。
【００５４】
アプリケーション処理部１０２が要求するインタフェース手続きパターンが「パブリッシュ／サブスクライブ型」であり、実際の外部システム１０２０と内部システム１０１０のサーバ１０１間で行われる通信のプロトコルが「パブリッシュ／サブスクライブ型」の場合、選定されたモジュールは、そのまま、そのアプリケーションと外部システム１０２０との間でパブリッシュ／サブスクライブ型によるアクセスを行う（ステップＳ７０６、図８（Ｂ））。
【００５５】
一方、アプリケーション処理部１０２が要求するインタフェース手続きパターンが「パブリッシュ／サブスクライブ型」であり、実際の外部システム１０２０と内部システム１０１０のサーバ１０１間で行われる通信のプロトコルが「リクエスト／リプライ型」の場合、選定されたモジュールは、そのアプリケーションと外部システム１０２０との間に、そのアプリケーションからのアクセスを受け付けるキャッシュデータベースを用意し、外部システム１０２０に対して随時リクエスト／リプライを実行してキャッシュデータベースを更新しながら、そのアプリケーションからのサブスクライブに対してパブリッシュを返す処理をキャッシュデータベースで行う（ステップＳ７０７、図８（Ｅ））。
【００５６】
さらに、アプリケーション処理部１０２が要求するインタフェース手続きパターンが「パブリッシュ／サブスクライブ型」であり、実際の外部システム１０２０と内部システム１０１０のサーバ１０１間で行われる通信のプロトコルが「一方向型」の場合、これに対応するためには外部システム１０２０側でそのプロトコルに対応する機能の作りこみが必須となるため、ここでは対象外とする（ステップＳ７０８）。
【００５７】
さらに、組み合わせ処理部１１３は、ステップＳ７０１において、アプリケーション処理部１０２が要求するインタフェース手続きパターンが、「一方向型」であると判定した場合、さらに、外部システム１０２０と内部システム１０１０のサーバ１０１と間で実施される通信プロトコルのパターンが、「リクエスト／リプライ型」、「パブリッシュ／サブスクライブ型」、「一方向型」のいずれであるかを判別し、適用する手続き・通信プロトコルの組み合わせ実施形態・処理モジュールを選定する（ステップＳ７０２−３）。
【００５８】
アプリケーション処理部１０２が要求するインタフェース手続きパターンが「一方向型」であり、実際の外部システム１０２０と内部システム１０１０のサーバ１０１間で行われる通信のプロトコルが「リクエスト／リプライ型」の場合、選定されたモジュールは、そのアプリケーションと外部システム１０２０の間に、そのアプリケーションに対する一方向のデータ送信を実行するキャッシュデータベースを用意し、外部システム１０２０に対して随時リクエスト／リプライを実行してキャッシュデータベースを更新しながら、そのアプリケーションに対して一方向のデータ送信を実行する処理をキャッシュデータベースで行う（ステップＳ７０９、図８（Ｆ））。
【００５９】
一方、アプリケーション処理部１０２が要求するインタフェース手続きパターンが「一方向型」であり、実際の外部システム１０２０とのサーバ間で行われる通信のプロトコルが「パブリッシュ／サブスクライブ型」の場合、選定されたモジュールは、そのアプリケーションと外部システム１０２０の間に、そのアプリケーションに対する一方向のデータ送信を実行するキャッシュデータベースを用意し、外部システム１０２０からのパブリッシュ／サブスクライブを受けてキャッシュデータベースを更新しながら、そのアプリケーションに対して一方向のデータ送信を実行する処理をキャッシュデータベースで行う（ステップＳ７１０、図８（Ｇ））。
【００６０】
さらに、アプリケーション処理部１０２が要求するインタフェース手続きパターンが「一方向型」であり、実際の外部システム１０２０と内部システム１０１０のサーバ１０１間で行われる通信のプロトコルが「一方向型」の場合、選定されたモジュールは、そのまま、そのアプリケーションと外部システム１０２０との間で一方向型のアクセスを行う（ステップＳ７１１、図８（Ｃ））。続いて、図６に戻り、ステップＳ６０４以降の処理について説明する。
【００６１】
そして、非機能要件処理部１１４は、非機能要件を充足するために必要な処理実施の形態を選定するための定義・情報である項目８〜１１を設定するために、内部システム１０１０の開発者等によってあらかじめ用意された非機能要件達成処理モジュールの中から、外部システム１０２０との接続に適用する非機能要件達成処理モジュールを選定する（ステップＳ６０４）。
【００６２】
具体的には、非機能要件処理部１１４は、非機能要件（要件項目）のうちの「性能」に関する非機能要件については、事前にアプリケーション開発者あるいはシステム開発者・管理者によって設定された、個々のアプリケーションあるいはシステムにおいて必要とする性能要件値（例えば、プロトコル変換の速度）を参照し、そのアプリケーションあるいは内部システム１０１０との間で変換対象となる外部システム１０２０について、アクセス手続きの形態と使用する通信プロトコルの組み合わせを選択し、これに対する処理実施形態を選定する。
【００６３】
また、非機能要件処理部１１４は、内部システム１０１０およびネットワーク性能に関して、あらかじめ計測・調査され定義されている性能情報や、随時のパフォーマンステストによって得られる情報より取得する。このパフォーマンステストは、新しい外部システム１０２０との接続・連携が必要になった際にその都度実施しても良いし、すべての外部システム１０２０との接続・連携の発生時にその都度実施しても良い。
【００６４】
さらに、非機能要件処理部１１４は、これらの性能要件値と、内部システム１０１０およびネットワーク性能との比較、および設定された通信プロトコルを用いた処理を行うことにより、それらの性能要件値を満たすか否かという観点から、利用する非機能要件達成処理モジュールを選定する。具体的には、非機能要件処理部１１４は、それらの性能要件値を達成するためにネットワーク性能が大幅に不足すると判断した場合は、アクセス要求先からアクセス要求元のサーバ上にデータのレプリケーションを生成し、そのアプリケーション処理がこのレプリケーションに対してアクセスを実行する非機能要件達成処理モジュールを選択する。あるいは、非機能要件処理部１１４は、それらの性能要件値を達成するためにネットワーク性能が理論上は十分であるものの、トラフィックの状況等により不十分になる可能性がある程度の性能であると判断した場合は、アクセス要求元とアクセス要求先の間で通信コネクションを生成し、常時、一定の性能での通信を確保する非機能要件達成処理モジュールを選択する。このように、非機能要件処理部１１４は、アプリケーション１０２に適したモジュールを選択し、アプリケーション１０２と外部システム１０２０との間の処理を適切な状態で実行させることを可能としている。
【００６５】
また、非機能要件処理部１１４は、非機能要件（要件項目）のうちの「データの信頼性」に関する非機能要件については、アプリケーション開発者あるいはシステム開発者・管理者によって設定された、個々のアプリケーションあるいはシステムにおいて必要とするデータの信頼性要件値を参照し、そのアプリケーションあるいは内部システム１０１０との間で変換対象となる外部システム１０２０について、手続きの形態と使用する通信プロトコルの組み合わせを選択し、これに対する処理実施形態を選定する。
【００６６】
また、非機能要件処理部１１４は、ネットワーク形態をあらかじめ定義されている情報より取得する。また、必要に応じて信頼性を検証するテストを実施する。この信頼性検証は、新しい外部システム１０２０との接続・連携が必要になった際にその都度実施しても良いし、すべての外部システム１０２０との接続・連携の発生時にその都度実施しても良い。これらの設定値および情報から、信頼性要件値に対するプロトコルおよびネットワークの品質の比較、および通信プロトコル・ネットワーク形態に対して実施すべき項目の要否から、利用する非機能要件達成処理モジュールを選定する。具体的には、非機能要件処理部１１４は、ネットワーク性能上の余裕が十分あり、アプリケーション処理自体も高速に行う必要があり、かつ信頼性要求が非常に高い場合は、通信自体を多重化する非機能要件達成処理モジュールを選定する。あるいは、非機能要件処理部１１４は、ネットワーク性能は十分に余裕があるとは言えず、アプリケーション処理自体にはそれほど高速処理を処理されていないが、信頼性要求が高い場合には、必要に応じてデータの再送要求を行う非機能要件達成処理モジュールを選定する。ＣＲＣ（Cyclic Redundancy Check）等の一般的なデータ完全性チェックに対応可能な機能を対象外部システムが有している場合などでは、それらの機能を利用してデータ完全性をチェックする非機能要件達成処理モジュールを選定する。
【００６７】
さらに、非機能要件処理部１１４は、非機能要件（要件項目）のうちの「セキュリティ」に関する非機能要件については、アプリケーション開発者あるいはシステム開発者・管理者によって設定された、個々のアプリケーションあるいはシステムにおいて必要とするセキュリティ要件値を設定し、そのアプリケーションあるいは内部システム１０１０との間で変換対象となる外部システム１０２０について、手続きの形態と使用する通信プロトコルの組み合わせを選択し、これに対する処理実施形態を選定する。
【００６８】
また、非機能要件処理部１１４は、システム構成をあらかじめ定義されている情報から取得し、また、対象となる外部システム１０２０のセキュリティ仕様・性能の判定を、あらかじめ定義されている情報か、あるいは随時のアクセステストによって得られる情報より取得する。このセキュリティテストは、新しい外部システム１０２０との接続・連携が必要になった際にその都度実施しても良いし、すべての外部システム１０２０との接続・連携の発生時にその都度実施しても良い。これらの設定値および情報から、対象となる外部システム１０２０が必要となるセキュリティレベルを有しているか等の判定を行い、また、通信プロトコル・システム構成に対して必要なセキュリティ処理が実施可能か否かの判定を行った上で、利用する非機能要件達成処理モジュールを選定する。具体的には、非機能要件処理部１１４は、対象となる外部システム１０２０が、必要なセキュリティ要件に対応できないと判定した場合には、その外部システムへのアクセスを遮断したり、あるいは、データ取得は許容するがデータ更新は許容しない等といった部分的にアクセスをフィルタリングする非機能要件達成処理モジュールを選定する。あるいは、非機能要件処理部１１４は、共通の認証基盤を利用可能な外部システム１０２０が対象であれば、この認証基盤を利用して内部システム１０１０と外部システム１０２０の認証を行う非機能要件達成処理モジュールを選定する。あるいは、所定の暗号・複合化機能に対応した外部システム１０２０であれば、この暗号・複合化機能を利用する非機能要件達成処理モジュールを選定する。
【００６９】
そして、プロトコル変換処理部１１３は、以上により非機能要件処理部１１４によって選択された処理モジュールによって構成されたミドルウェアを生成し（ステップＳ６０５）、生成したミドルウェアを内部システム１０１０が有しているアプリケーションが動作しているサーバ１０１に組み込む（ステップＳ６０６）。このようなミドルウェアをサーバ１０１に組み込むことにより、例えば、ネットワークを介して相互接続した複数の独立したノードにより構成される分散システムにおいて、同一の規格や仕様に準拠したデータ管理及びデータアクセス処理を行う、１つ以上のノードを含むシステムおよびそのシステムとは異なるシステムとの間の相互接続および連携させることが可能となる。
【００７０】
より具体的には、システム間の相互接続・連携の際に、各々異なるシステムが準拠する規格等に基づくデータモデル、インタフェース、プロトコルの３階層にて、異なるシステム間の相互変換を実施し、プロトコルの階層では、手続きの形態のパターン、手続きの形態と使用する通信プロトコルの形態の組み合わせに対して変換の実施パターンおよび非機能要件を充足するための処理パターンを用意し、これらを共通部品とする一方、接続・連携する相手システム毎に相互接続・連携のための前記各階層での変換処理を、各々の共通部品の組み合わせにより実現し、これらの共通備品の組み合わせは、接続・連携する相手システム毎に外部定義として指定する。このようなプロトコルの階層にて、異なる規格・仕様のシステムと相互接続するための処理を実行するプログラム（処理モジュール）およびシステム構成等に応じてアプリケーションが要求する非機能要件を充足するための処理モジュールを、外部定義にしたがって選出し、構成しているので、異なる規格や仕様のシステムとの接続・連携が必要となるアプリケーションの開発において、個々の接続・連携処理の開発がアプリケーション自体の開発と分割され、アプリケーション開発者が直接考慮する必要がなくなった上で、個々の接続・連携処理の開発自体も容易化され、全体としてのシステム、アプリケーション開発の生産性を向上させることができる。
【実施例２】
【００７１】
上述した実施例１においては、アプリケーション処理部が外部システムに対してアクセスする際に必要な処理をミドルウェアが行うことにより、アプリケーション開発者等が外部システムとの間の変換処理を考慮することなく適切なモジュールの組み合わせを選択し、両者のデータの受け渡し等を可能とした。しかし、図９に示すように、実施例２においては、複数のサーバ９０７が有する個々のアプリケーション処理部９０１から外部システム１０２０にアクセスする際に必要な処理を、通信経路上のゲートウェイサーバ９０５が有する内部記憶装置１１５に記憶されたミドルウェア９０２で行うこととする。
【００７２】
この場合、各々のサーバ９０７のアプリケーション処理部９０１を一意に識別するために、ミドルウェア９０２に対応付けて識別情報９０４があらかじめ設定され、個々のアプリケーション処理部９０１の識別情報９０３とミドルウェアの識別情報９０４の組み合わせを、アプリケーション処理／ミドルウェア組み合わせ管理ＤＢ（Data Base）９０６により管理する。
【００７３】
その上で、ミドルウェア９０２を、アプリケーション処理部９０１が動作しているサーバ９０７上ではなく、別のサーバ、例えば、外部システム１０２０と内部システム１０１０との間に設置されたゲートウェイサーバ９０５上に組み込む。そして、アプリケーション処理部９０１が外部システム１０２０にアクセスする際、アプリケーション処理部９０１の識別情報９０３と、ミドルウェアの識別情報９０４とを照合し、アプリケーション処理部９０１の識別情報９０３とミドルウェア９０２の識別情報９０４の組み合わせを管理しているアプリケーション処理／ミドルウェア組み合わせ管理ＤＢ９０６を参照して、アプリケーション処理−ミドルウェア組合せ制御部９０８により、アプリケーションに対応するミドルウェアを自動的に選択してゲートウェイサーバ９０５上で動作させる。
【００７４】
このように構成することで、実施例１の場合と同様に、外部システムに対するアクセスを実現する。この方式によると、アプリケーション処理部９０１が動作しているサーバ９０７には新規のミドルウェア等の組み込み等、手を加える必要が一切無くなり、既設システム等をそのまま利用した上で外部システム１０２０と接続・連携することが可能となる。また、新しいアプリケーションがシステム内に導入された際に、そのアプリケーションの識別情報９０３を参照して、上述した実施例１に記載の方法により、その都度ミドルウェア９０２を自動的に生成して利用してもよい。
【実施例３】
【００７５】
上述した実施例１においては、アプリケーション処理部１０２が外部システムに対してアクセスする際に必要な処理をミドルウェアが行うことにより、アプリケーション開発者等が外部システムとの間の変換処理を考慮することなく適切なモジュールの組み合わせを選択し、両者のデータの受け渡し等を可能となり、また、上述した実施例２においては、データアクセスを実施するアプリケーション処理自体と切り離して、別のサーバ上にこの機能を配置することを可能とした。しかし、外部システムからの要求に応じて内部システムが種々の処理を行う場合もある。そこで、図１０に示すように、実施例３においては、このようなミドルウェア機能を、例えば、内部システム１２１０で利用されているデータが格納されているデータベース１００４が配置されているデータベースサーバ１００１上に配置する。このとき、外部システム１２２０から内部システム１２１０にアクセスする際に、規格あるいは仕様を選択し、実施例１に記載の手順でミドルウェア９０２を構築し、そのミドルウェア９０２によってデータモデル変換、インタフェース変換、プロトコル変換を行った上でデータベース１００４にアクセスして、外部システム１２２０が要求する処理を行う。
【００７６】
また、外部システム１２２０上のアプリケーション処理部１００２の識別情報は取得不可能である場合が多いため、アプリケーション処理の識別情報とミドルウェアの識別情報との対応付けではなく、要求種別／ミドルウェア組合せ選択部１００６が、外部システム１２２０からの要求がどのような種別であるかを要求メッセージ等のプロトコルから抽出し、この要求の種別とミドルウェア９０２の識別情報１００３の対応付け情報を要求種別／ミドルウェア組み合わせ管理ＤＢ１００５により管理することによって、実施例２の場合と同様に、対応するミドルウェアを自動的に選択する処理をデータベースサーバ１００１上で動作させる。これにより、外部システム１２２０から内部システム１２１０のデータへのアクセスに対応可能となる。
【００７７】
なお、本発明は、上記実施の形態そのままに限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で構成要素を変形して具体化することができる。また、上記実施の形態に開示されている複数の構成要素の適宜な組み合わせにより、種々の発明を形成することができる。例えば、実施の形態に示される全構成要素からいくつかの構成要素を削除してもよい。さらに、異なる実施の形態にわたる構成要素を適宜組み合わせても良い。
【符号の説明】
【００７８】
１０００、２０００、３０００ 分散システム
１０１０、１１１０、１２１０ 内部システム
１０２０、１２２０ 外部システム
１０１ サーバ（内部システム）
１０２ アプリケーション処理部
１０３ サーバ（外部システム）
１０４ データベース
１０５、９０３ 識別情報
１０６ ミドルウェア
１０７ データモデル変換部
１０８ インタフェース変換部
１０９ プロトコル変換部
１１０ データモデル外部定義
１１１ インタフェース外部定義
１１２ プロトコル外部定義
１１３ 組合せ処理部
１１４ 非機能要件達成処理部
１１５ 内部記憶装置
１１６ ネットワークアクセス部
Ｎ ネットワーク。
【技術分野】
【０００１】
本発明は、例えば、ネットワークを介して接続された複数の分散システム間におけるシステムの連携装置に関するものである。
【背景技術】
【０００２】
電力分野システムなどにおいては、電源の多様化、地域・家庭等のエネルギーマネジメントの拡大等から、制御・監視対象の拡大、データ利用範囲の拡大、異なるシステム間での連携、異なる業務間での連携などが進展している。一方で、海外では、システム仕様やアプリケーションインターフェース、データモデル等の国際標準規格を整備することで上記に対応する動きが広がっており、ＩＥＣ（The International Electrotechnical Commission）などで個々の標準規格の整備が進められている。ただし、基本的には分野や業務種別、レイヤなど毎に標準規格が整備されており、前記の特に異なるシステム間での連携、異なる業務間での連携などを想定する場合には、複数の標準規格を跨ったアプリケーション開発が必要となる場合も多い。また、標準規格が未整備な分野、業務種別等では、システム開発に参加しているベンダーが個別の仕様に従ってシステム開発を実施する場合も多く、この場合は、標準規格というよりも、異なる複数の仕様を跨ったアプリケーション開発が必要となる。
【０００３】
このような異なる複数の仕様を跨ったアプリケーション開発への対応として、例えば、特許文献１には、管理装置と設備装置との間でデータフォーマットが異なる場合、両装置の間の通信を行う通信ドライバにてデータ変換を実施し、設備の属性、機能オブジェクト等をマークアップ言語で記述し、設備毎の機能クラス情報とコンフィグレーション情報を用いて各々変換する方式が提案されている。
【０００４】
また、特許文献２には、異なるインタフェースを持った１個以上のソフトウェアコンポーネントを再利用する場合、各インタフェース記述からメソッド及び引数の順序による差違を吸収し、メソッド及び引数の対応関係を抽出し、再利用コンポーネントを集約しクライアント側インタフェースを実装するコードを自動生成する方式が提案されている。
【０００５】
さらに、特許文献３には、システム毎にシステム間連携装置を配置し、各システムでの通信プロトコルにより送信されたデータを上記システム間連携装置が他システムに転送し、受信したシステム間連携装置にて、受信データより共通データ、自システムにて必要なデータを抽出し、自システムの通信プロトコルを用いて自システム内に改めて送信する方式が提案されている。
【先行技術文献】
【特許文献】
【０００６】
【特許文献１】特開２００７−５１４３３５号公報
【特許文献２】特開平１１−３５３１６８号公報
【特許文献３】特開２０１０−６７１８１号公報
【発明の概要】
【発明が解決しようとする課題】
【０００７】
しかしながら、上述した特許文献１〜３に開示されている技術では、システム間の相互接続の際に、データモデル、インタフェースまたは通信プロトコルのいずれか１つの変換のみを実施している。このためデータモデル、インタフェース、プロトコルのうち２つ以上が異なる場合には対応できず、接続の際に不具合が生じ得る。また、相互接続する異なる２つのシステム毎に個別に変換及び接続のための処理を全て作り込む必要があり、接続先・対応規格の数が増えるとこれらの処理を作り込む負荷が増大する。
【０００８】
さらに、個々のアプリケーションが要求する要件である非機能要件を満たすための処理を、各アプリケーション側で作り込む必要がある。このため、接続先の追加・変更に伴うアプリケーションの改修負荷が増大する。また、特許文献３では、システム間連携装置にて固定の手続きを連携用の固定の通信プロトコル上で実現しているのみである。このためインタフェース実行に伴う手続きの形態と接続先システムにて使用する通信プロトコルの形態に差異が有る場合、接続及び手続き実施ができない。
【０００９】
このように、異なる規格や仕様に準拠したシステムが複数混在運用される環境においては、個々の異なるシステム間を接続・連携するための処理を、本来の個々のアプリケーション処理自体とは別に、接続・連携毎に個別に開発する必要がある。混在運用される異なるシステムが多数になればなるほど、開発する必要のある、システム間の接続・連携処理が増えるとともに、処理自体も複雑化し、開発の労力や工数が肥大化することになる。また、接続・連携対象となるシステムの規格や仕様の詳細を把握した上で接続・連携処理を開発する必要があるため、アプリケーション開発者の負担が増大することになる。
【００１０】
このような状況に鑑み、本発明は、異なる規格や仕様に準拠する複数の異なるシステム間の相互接続および連携を行う際に、アプリケーション処理としての作りこみは排除した上で、アプリケーション開発者からは意識されないミドルウェアにて相互接続のための処理（規格・仕様間の相互変換）および実際の接続・連携時に必要となる非機能要件を充足するための処理を実施し、その上で、ミドルウェア機能としての個々の接続・連携処理の開発を容易化し、アプリケーション開発の生産性を向上させることが可能な分散システムにおけるシステム間連携装置を提供することを目的とする。
【課題を解決するための手段】
【００１１】
上述した課題を解決し、目的を達成するために、本発明にかかるシステム間連携装置は、所定の規格あるいは仕様に準拠して作成されたシステムから前記システムとは異なる規格あるいは仕様に準拠して作成された他のシステムへのアクセスが可能な分散システムにおけるシステム間連携装置であって、前記システムと前記他のシステムとの間における通信プロトコルの形態と前記システムおよび前記他のシステムのシステム構成およびネットワーク構成とを対応付けたプロトコル定義と前記システムが所定のアプリケーションにより前記他のシステムにアクセスするための前記所定のアプリケーションに固有の要件である非機能要件と、前記プロトコル定義および前記非機能要件に応じた前記アプリケーションを実行させるための複数のモジュールと、を記憶する記憶部と、前記他のシステムにアクセスして前記所定のアプリケーションを実行させるためのアプリケーション処理部と、前記アプリケーション処理部が前記所定のアプリケーションの実行指示を受けた場合に、前記所定のアプリケーションからの要求に応じて、前記プロトコル定義に含まれる前記通信プロトコル形態および前記システム構成および前記ネットワーク構成に基づいて定められる前記システムと前記他のシステムとの間の処理を行うために必要な要件値と前記非機能要件との組み合わせに基づいて、前記複数のモジュールの中から前記アプリケーションによる処理を実行させるために必要なモジュールを選択する組合せ処理部と、を備えることを特徴とする。
【発明の効果】
【００１２】
本発明によれば、アプリケーション開発の生産性を向上させることが可能な分散システムにおけるシステム間連携装置を提供することができるという効果を奏する。
【図面の簡単な説明】
【００１３】
【図１】第１の実施の形態における分散システムの構成例を示す図である。
【図２】外部定義される項目（データモデル外部定義、インタフェース外部定義、プロトコル外部定義）の例を示す図である。
【図３】第１の実施の形態におけるリクエスト／リプライ型の手続きパターンの概略を示す図である。
【図４】第１の実施の形態におけるパブリッシュ／サブスクライブ型の手続きパターンの概略を示す図である。
【図５】第１の実施の形態における一方向型の手続きパターンの概略を示す図である。
【図６】第１の実施の形態におけるシステム間連携方法の手順を示すフローチャートである。
【図７】組み合わせ処理部が行う組み合わせ処理の処理手順を示すフローチャートである。
【図８】第１の実施の形態における各処理モジュールの動作概要を示す図である。
【図９】第２の実施の形態における分散システムの構成例を示す図である。
【図１０】第３の実施の形態における分散システムの構成例を示す図である。
【発明を実施するための形態】
【００１４】
以下に添付図面を参照して、本発明にかかる分散システムにおけるシステム間連携装置の実施の形態を詳細に説明する。
【実施例１】
【００１５】
図１は、第１の実施の形態における分散システム１０００の構成例を示す図である。図１に示すように、分散システム１０００は、内部システム１０１０と外部システム１０２０とを含んで構成されている。なお、内部システム１０１０と外部システム１０２０とは、例えば、インターネット等の一般的なネットワークＮによって接続されているものとする。
【００１６】
内部システム１０１０は、利用者によって使用される所定のアプリケーションを有した外部システム１０２０とは異なるシステムであり、サーバ１０１（システム間連携装置）の内部記憶装置１１５に組み込まれているものである。内部記憶装置１１５には、内部システム１０１０にアクセス可能な利用者が使用する複数のアプリケーションを実行するアプリケーション処理部１０２と、それらのアプリケーション処理部１０２を一意に識別するための識別情報１０５とが対応付けて記憶されている。
【００１７】
また、内部記憶装置１１５には、ミドルウェア１０６が記憶されている。ミドルウェア１０６は、データモデル変換処理部１０７と、インタフェース変換処理部１０８と、プロトコル変換処理部１０９とを有している。
【００１８】
データモデル変換処理部１０７は、内部システム１０１０と外部システム１０２０との間で共有するデータの共通的な意味付けを行う（例えば、各システムで用いられるデータをいずれもＣＩＭ（common information model）に従ったデータモデルにする）ものであり、内部システム１０１０で用いられるデータモデルを外部システム１０２０で用いられるデータモデルに変換する。また、図１に示すように、データモデル変換処理部１０７は、データモデル外部定義１１０にアクセス可能となっている。データモデル外部定義１１０は、外部システム１０２０が有しているデータモデルとの間の変換を行うためのデータモデルに関する各種の対応付けを定義した情報であり、図２を用いて後述する。
【００１９】
インタフェース変換処理部１０８は、内部システム１０１０が有するアプリケーション１０２が要求する処理の指定方法を定める（例えば、内部システム１０１０で用いられているインタフェースを外部システム１０２０で用いられているオープン規格のインタフェースにする）ものであり、データモデル変換処理部１０７と同様に、内部システム１０１０で用いられるインタフェースを外部システム１０２０で用いられるインタフェースに変換する。また、図１に示すように、インタフェース変換処理部１０８は、インタフェース外部定義１１１にアクセス可能となっている。インタフェース外部定義１１１は、データモデル外部定義１１０と同様に、外部システム１０２０が有しているインタフェースとの間の変換を行うためのインタフェースに関する各種の対応付けを定義した情報であり、図２を用いて後述する。
【００２０】
プロトコル変換処理部１０９は、内部システム１０１０と外部システム１０２０との間でデータをやり取りするための手続き、通信の様式を定めるものであり、データモデル変換処理部１０７等と同様に、内部システム１０１０で用いられるプロトコルを外部システム１０２０で用いられるプロトコルに変換する。また、図１に示すように、プロトコル変換処理部１０９は、プロトコル外部定義１１２にアクセス可能となっている。プロトコル外部定義１１２は、データモデル外部定義１１０等と同様に、外部システム１０２０が有しているプロトコルとの間の変換を行うためのプロトコルに関する各種の対応付けを定義した情報であり、図２を用いて後述する。
【００２１】
ネットワークアクセス部１１６は、内部システム１０１０と外部システム１０２０との間の通信を司るものである。
【００２２】
このような構成において、サーバ１０１上で動作している個々のアプリケーション処理部１０２が、内部システム１０１０で用いられる規格や仕様とは異なる規格や仕様に準拠した外部システム１０２０に含まれるサーバ１０３上のデータ（例えば、データベース１０４に格納されているデータ）に対してアクセスする際について考える。この場合、まずアプリケーション処理部１０２が存在する内部システム１０１０が有する規格や仕様に準拠した形式でデータモデルやインタフェースが指定される。内部システム１０１０は、複数のアプリケーションを有しており、上述した識別情報１０５を指定することによってアプリケーションが使用可能となる。
【００２３】
さらに、指定されたアプリケーションの下層で動作するミドルウェア１０６は、アプリケーション処理部１０２からの指定を受けて、外部システム１０２０にアクセスするための種々の規格や仕様に関する変換処理を行う。変換処理では、外部システム１０２０の規格や仕様に準拠したデータモデルへの変換、インタフェースの変換、プロトコルの変換の３階層によって変換処理が行われる。このとき、内部システム１０１０が有するデータモデルと外部システム１０２０が有するデータモデルとの間の変換を実際に行うためのデータモデル間の対応付けや変換定義は、外部定義化して上述したデータモデル外部定義１１０に保持され、データモデル変換処理部１０７が必要に応じて随時この外部定義を参照することによりデータモデル変換の処理を実行する。
【００２４】
これと同様に、インタフェース変換およびプロトコル変換についても、それぞれ、インタフェース変換処理部１０８がインタフェース外部定義１１１を参照することによりインタフェース変換の処理を実行し、プロトコル変換処理部１０９がプロトコル外部定義１１２を参照することによりプロトコル変換の処理を実行する。
【００２５】
また、プロトコル変換処理部１０９は、組み合わせ処理部１１３と、非機能要件達成処理部１１４によって構成されており、後述するように、アプリケーション開発者による要件の選択、およびシステム設計・開発者によって定義されるシステム構成情報や、都度検証されるシステム性能情報等から、どのような処理モジュールによってプロトコル変換が構成されるかを自動的に決定する手段を提供する。
【００２６】
サーバ１０１が有する上述した各部は、データモデル変換処理部１０７、インタフェース変換処理部１０８、プロトコル変換処理部１０９の各機能を実現するためのソフトウェアプログラムにより実行される。これらのソフトウェアプログラムは、例えば、上述した各部を含むモジュール構成となっており、実際のハードウェアとしては、ＣＰＵ等の制御部がＨＤＤ等の記録装置からこれらのソフトウェアプログラムを読み出して実行することにより、上記各部が主記憶装置上にロードされ、データモデル変換処理部１０７、インタフェース変換処理部１０８、プロトコル変換処理部１０９の各部が主記憶装置上に生成されるようになっている。
【００２７】
また、上述したソフトウェアプログラムは、インストール可能な形式又は実行可能な形式のファイルでＣＤ−ＲＯＭ、フレキシブルディスク（ＦＤ）、ＣＤ−Ｒ、ＤＶＤ（Digital Versatile Disc）等のコンピュータで読み取り可能な記録媒体に記録されて提供することも可能である。さらに、これらのソフトウェアプログラムを、ネットワーク経由でダウンロードさせて提供または配布するように構成してもよい。
【００２８】
続いて、外部定義される項目の例を図２に示す。図２は、外部定義される項目（データモデル外部定義１１０、インタフェース外部定義１１１、プロトコル外部定義１１２）の例を示す図である。なお、図２では、データモデル外部定義１１０と、インタフェース外部定義１１１と、プロトコル外部定義１１２とを１つのテーブルとして示しているが、これらのぞれぞれは、図１に示したように、データモデル変換処理部１０７、インタフェース変換処理部１０８、プロトコル変換処理部１０９に、それぞれアクセス可能なように対応付けられている。
【００２９】
図２に示すように、データモデル外部定義１１０は、内部システム１０１０のアプリケーション処理部１０２で用いられるデータモデルと、外部システム１０２０のアプリケーションやデータベース１０４で用いられるデータモデルとの対応関係を記憶するものである。データモデル外部定義１１０では、アプリケーション１０２で用いられるデータごとに、所定の規格に従って定められた形式のデータをどの形式のデータに変換させるかを定めている。
【００３０】
また、インタフェース外部定義１１１は、データモデル外部定義１１０と同様に、内部システム１０１０のアプリケーション処理部１０２で用いられるインタフェースと、外部システム１０２０のアプリケーションやデータベース１０４で用いられるインタフェースとの対応関係を記憶するものである。インタフェース外部定義１１１では、アプリケーション１０２で用いられるインタフェースごとに、所定の規格に従って定められた形式のインタフェースをどの形式のデータに変換させるかを定めている。
【００３１】
さらに、プロトコル外部定義１１２は、インタフェース手続きパターンと、通信プロトコル形態と、通信定義と、システム構成・ネットワーク形態と、ネットワーク性能と、非機能要件とが定義されている。ここで、非機能要件とは、上述したインタフェース手続きパターン、通信プロトコル形態、通信定義、システム構成・ネットワーク形態、ネットワーク性能の各機能要件以外の要件を指すものである。非機能要件は、個々のアプリケーションに応じて定義が必要となるもの（アプリケーションに共通に定義できないもの）であり、アプリケーション固有の要件項目、条件、組み込み関数、追加定義が定義されている。
【００３２】
インタフェース手続きパターンは、アプリケーションで用いられるインタフェースごとに定められたアプリケーション実行時の手続きのパターンであり、「リクエスト／リプライ型」、「パブリッシュ／サブスクライブ型」、「一方向型」の３つのパターンのいずれかが設定される。
【００３３】
ここで、「リクエスト／リプライ型」とは、図３に示すように、アクセスを行う要求側システムの要求（例えば、内部システム１０１０からの要求）に同期して、被要求側システム（例えば、外部システム１０２０）が応答を返す形態である。このパターンの場合、インタフェース手続きパターンとしては、「データモデル変換」、「インタフェース変換」、「プロトコル変換」、「データモデル変換」の順に変換処理が行われることとなる。
【００３４】
また、「パブリッシュ／サブスクライブ型」とは、図４に示すように、アクセスの要求側システム（例えば、内部システム１０１０）が、応答間隔等の所定の条件を被要求側システム（例えば、外部システム１０２０）に登録しておくことにより、条件に応じた形で被要求側システムから要求側へ応答が返される形態である。このパターンの場合、「データモデル変換」、「インタフェース変換」、「プロトコル変換」、「データモデル変換」、「プロトコル変換」の順に変換処理が行われることとなる。
【００３５】
さらに、「一方向／待受け型（データ送信）」とは、図５に示すように、片方のシステム（例えば、内部システム１０１０）からのデータ送信等が、送信先のシステム（例えば、外部システム１０２０）の要求等に関係無く一方的に送られる形態である。このパターンの場合、「データモデル変換」、「プロトコル変換」の順に変換処理が行われることとなる。このように、インタフェース手続きパターンには、システム間でどのような順序の手続きによってアプリケーションを実行するかが定められている。
【００３６】
通信プロトコル形態は、上述した「リクエスト／リプライ型」、「パブリッシュ／サブスクライブ型」「一方向型」の各パターンで用いられる通信プロトコルの形態であり、「リクエスト／リプライ型」、「パブリッシュ／サブスクライブ型」「一方向型」のいずれかが設定される。
【００３７】
通信定義は、上述した通信プロトコル形態による通信プロトコルおよびその通信プロトコルにより通信を行うミドルウェアにおける処理で用いられる種々の定義が設定される。
【００３８】
システム構成・ネットワーク形態は、内部システム１０１０および外部システム１０２０とのシステム構成及びネットワーク形態に関する情報が設定される。
【００３９】
ネットワーク性能は、ネットワークＮにおいて保証される通信速度等、通信に関する性能情報が設定される。
【００４０】
非機能要件（要件項目）は、上述したネットワーク性能以外の性能、例えば、内部システム１０１０や外部システム１０２０等の個々のシステムの性能、データの信頼性、システムのセキュリティレベル（例えば、セキュリティ性能、セキュリティ仕様）等、非機能要件として設定可能な項目が設定される。
【００４１】
非機能要件（条件）は、上述した要件項目において設定された非機能要件に関して達成するべき条件、例えば、システムレスポンスの下限値等、要件項目に関する条件が設定される。
【００４２】
非機能要件（組み込み関数）は、内部システム１０１０の開発者が個別に作成した組み込み関数の定義、例えば、プロトコル変換する関数の定義等、組み込み関数に関する定義が設定される。
【００４３】
非機能要件（追加定義）は、上述した非機能要件以外の要件、例えば、プロトコル変換処理を実行させるために必要な上述した非機能要件以外の定義等が設定される。
【００４４】
続いて、内部システム１０１０が外部システム１０２０に接続してこれらのシステム間を連携させるためのミドルウェアを構築する際の手順の例について述べる。図６は、上述したシステム間連携方法の手順を示すフローチャートである。
【００４５】
図６に示すように、まず、サーバ１０１は、システム構築者により決定された、接続先となる外部システムの指定、および対応が必要な規格・仕様の指定を受け付けた後（ステップＳ６０１）、システム構築者から、接続・連携対象となる外部システム１０２０毎に、図２に示した外部定義される項目１〜１１の設定を受け付け、アプリケーション処理部１０２から外部システム１０２０への接続・連携を行うため、受け付けられた上記１〜１１までの定義・情報を参照し、データモデル変換処理部１０７、インタフェース変換処理部１０８、プロトコル変換処理部１０９は、各々必要な変換処理を実行する（ステップＳ６０２）。
【００４６】
そして、プロトコル変換処理部１０９は、プロトコルの変換処理において、上記項目３〜５は、手続きの形態と使用する通信プロトコルの組み合わせに対する処理実施形態を選定するための定義・情報であるため、図７に示す手続き・通信プロトコルの組み合わせ実施形態・処理モジュールを選定する処理（組み合わせ処理）を行う（ステップＳ６０３）。
【００４７】
図７は、組み合わせ処理部１１３が行う組み合わせ処理の処理手順を示すフローチャートである。
【００４８】
図７に示すように、まず、組み合わせ処理部１１３は、アプリケーション処理部１０２が要求するインタフェース手続きパターンが、「リクエスト／リプライ型」、「パブリッシュ／サブスクライブ型」、「一方向型」のいずれであるかを判別する（ステップＳ７０１）。
【００４９】
そして、組み合わせ処理部１１３は、アプリケーション処理部１０２が要求するインタフェース手続きパターンが、「リクエスト／リプライ型」であると判定した場合、さらに、外部システム１０２０と内部システム１０１０のサーバ１０１と間で実施される通信プロトコルのパターンが、「リクエスト／リプライ型」、「パブリッシュ／サブスクライブ型」、「一方向型」のいずれであるかを判別し、適用する手続き・通信プロトコルの組み合わせ実施形態・処理モジュールを選定する（ステップＳ７０２−１）。
【００５０】
通信プロトコルのパターンが「リクエスト／リプライ型」であると判別した場合、アプリケーション処理部１０２が要求するインタフェース手続きパターンが「リクエスト／リプライ型」であり、実際の外部システム１０２０と内部システム１０１０のサーバ１０１間で行われる通信のプロトコルが「リクエスト／リプライ型」の場合、選定されたモジュールは、そのまま、そのアプリケーションと外部システム１０２０との間で、リクエスト／リプライ型によるアクセスを行う（ステップＳ７０３、図８（Ａ））。
【００５１】
一方、通信プロトコルのパターンが「パブリッシュ／サブスクライブ型」であると判別した場合、アプリケーション処理部１０２が要求するインタフェース手続きパターンが「リクエスト／リプライ型」であり、実際の外部システム１０２０と内部システム１０１０のサーバ１０１間で行われる通信のプロトコルが「パブリッシュ／サブスクライブ型」の場合、選定されたモジュールは、そのアプリケーションと外部システム１０２０との間に、そのアプリケーションからのアクセスを受け付けるキャッシュデータベースを用意し、外部システム１０２０からのパブリッシュ／サブスクライブを受けてそのキャッシュデータベースを更新しながら、そのアプリケーションからのリクエストに対してリプライを返す処理をキャッシュデータベースで行う（ステップＳ７０４、図８（Ｄ））。
【００５２】
さらに、アプリケーション処理部１０２が要求するインタフェース手続きパターンが「リクエスト／リプライ型」であり、実際の外部システム１０２０と内部システム１０１０のサーバ１０１間で行われる通信のプロトコルが「一方向型」の場合、これに対応するためには外部システム１０２０側でそのプロトコルに対応する機能の作りこみが必須となるため、ここでは対象外とする（ステップＳ７０５）。
【００５３】
一方、組み合わせ処理部１１３は、ステップＳ７０１において、アプリケーション処理部１０２が要求するインタフェース手続きパターンが、「パブリッシュ／サブスクライブ型」であると判定した場合、さらに、外部システム１０２０と内部システム１０１０のサーバ１０１と間で実施される通信プロトコルのパターンが、「パブリッシュ／サブスクライブ型」、「リクエスト／リプライ型」、「一方向型」のいずれであるかを判別し、適用する手続き・通信プロトコルの組み合わせ実施形態・処理モジュールを選定する（ステップＳ７０２−２）。
【００５４】
アプリケーション処理部１０２が要求するインタフェース手続きパターンが「パブリッシュ／サブスクライブ型」であり、実際の外部システム１０２０と内部システム１０１０のサーバ１０１間で行われる通信のプロトコルが「パブリッシュ／サブスクライブ型」の場合、選定されたモジュールは、そのまま、そのアプリケーションと外部システム１０２０との間でパブリッシュ／サブスクライブ型によるアクセスを行う（ステップＳ７０６、図８（Ｂ））。
【００５５】
一方、アプリケーション処理部１０２が要求するインタフェース手続きパターンが「パブリッシュ／サブスクライブ型」であり、実際の外部システム１０２０と内部システム１０１０のサーバ１０１間で行われる通信のプロトコルが「リクエスト／リプライ型」の場合、選定されたモジュールは、そのアプリケーションと外部システム１０２０との間に、そのアプリケーションからのアクセスを受け付けるキャッシュデータベースを用意し、外部システム１０２０に対して随時リクエスト／リプライを実行してキャッシュデータベースを更新しながら、そのアプリケーションからのサブスクライブに対してパブリッシュを返す処理をキャッシュデータベースで行う（ステップＳ７０７、図８（Ｅ））。
【００５６】
さらに、アプリケーション処理部１０２が要求するインタフェース手続きパターンが「パブリッシュ／サブスクライブ型」であり、実際の外部システム１０２０と内部システム１０１０のサーバ１０１間で行われる通信のプロトコルが「一方向型」の場合、これに対応するためには外部システム１０２０側でそのプロトコルに対応する機能の作りこみが必須となるため、ここでは対象外とする（ステップＳ７０８）。
【００５７】
さらに、組み合わせ処理部１１３は、ステップＳ７０１において、アプリケーション処理部１０２が要求するインタフェース手続きパターンが、「一方向型」であると判定した場合、さらに、外部システム１０２０と内部システム１０１０のサーバ１０１と間で実施される通信プロトコルのパターンが、「リクエスト／リプライ型」、「パブリッシュ／サブスクライブ型」、「一方向型」のいずれであるかを判別し、適用する手続き・通信プロトコルの組み合わせ実施形態・処理モジュールを選定する（ステップＳ７０２−３）。
【００５８】
アプリケーション処理部１０２が要求するインタフェース手続きパターンが「一方向型」であり、実際の外部システム１０２０と内部システム１０１０のサーバ１０１間で行われる通信のプロトコルが「リクエスト／リプライ型」の場合、選定されたモジュールは、そのアプリケーションと外部システム１０２０の間に、そのアプリケーションに対する一方向のデータ送信を実行するキャッシュデータベースを用意し、外部システム１０２０に対して随時リクエスト／リプライを実行してキャッシュデータベースを更新しながら、そのアプリケーションに対して一方向のデータ送信を実行する処理をキャッシュデータベースで行う（ステップＳ７０９、図８（Ｆ））。
【００５９】
一方、アプリケーション処理部１０２が要求するインタフェース手続きパターンが「一方向型」であり、実際の外部システム１０２０とのサーバ間で行われる通信のプロトコルが「パブリッシュ／サブスクライブ型」の場合、選定されたモジュールは、そのアプリケーションと外部システム１０２０の間に、そのアプリケーションに対する一方向のデータ送信を実行するキャッシュデータベースを用意し、外部システム１０２０からのパブリッシュ／サブスクライブを受けてキャッシュデータベースを更新しながら、そのアプリケーションに対して一方向のデータ送信を実行する処理をキャッシュデータベースで行う（ステップＳ７１０、図８（Ｇ））。
【００６０】
さらに、アプリケーション処理部１０２が要求するインタフェース手続きパターンが「一方向型」であり、実際の外部システム１０２０と内部システム１０１０のサーバ１０１間で行われる通信のプロトコルが「一方向型」の場合、選定されたモジュールは、そのまま、そのアプリケーションと外部システム１０２０との間で一方向型のアクセスを行う（ステップＳ７１１、図８（Ｃ））。続いて、図６に戻り、ステップＳ６０４以降の処理について説明する。
【００６１】
そして、非機能要件処理部１１４は、非機能要件を充足するために必要な処理実施の形態を選定するための定義・情報である項目８〜１１を設定するために、内部システム１０１０の開発者等によってあらかじめ用意された非機能要件達成処理モジュールの中から、外部システム１０２０との接続に適用する非機能要件達成処理モジュールを選定する（ステップＳ６０４）。
【００６２】
具体的には、非機能要件処理部１１４は、非機能要件（要件項目）のうちの「性能」に関する非機能要件については、事前にアプリケーション開発者あるいはシステム開発者・管理者によって設定された、個々のアプリケーションあるいはシステムにおいて必要とする性能要件値（例えば、プロトコル変換の速度）を参照し、そのアプリケーションあるいは内部システム１０１０との間で変換対象となる外部システム１０２０について、アクセス手続きの形態と使用する通信プロトコルの組み合わせを選択し、これに対する処理実施形態を選定する。
【００６３】
また、非機能要件処理部１１４は、内部システム１０１０およびネットワーク性能に関して、あらかじめ計測・調査され定義されている性能情報や、随時のパフォーマンステストによって得られる情報より取得する。このパフォーマンステストは、新しい外部システム１０２０との接続・連携が必要になった際にその都度実施しても良いし、すべての外部システム１０２０との接続・連携の発生時にその都度実施しても良い。
【００６４】
さらに、非機能要件処理部１１４は、これらの性能要件値と、内部システム１０１０およびネットワーク性能との比較、および設定された通信プロトコルを用いた処理を行うことにより、それらの性能要件値を満たすか否かという観点から、利用する非機能要件達成処理モジュールを選定する。具体的には、非機能要件処理部１１４は、それらの性能要件値を達成するためにネットワーク性能が大幅に不足すると判断した場合は、アクセス要求先からアクセス要求元のサーバ上にデータのレプリケーションを生成し、そのアプリケーション処理がこのレプリケーションに対してアクセスを実行する非機能要件達成処理モジュールを選択する。あるいは、非機能要件処理部１１４は、それらの性能要件値を達成するためにネットワーク性能が理論上は十分であるものの、トラフィックの状況等により不十分になる可能性がある程度の性能であると判断した場合は、アクセス要求元とアクセス要求先の間で通信コネクションを生成し、常時、一定の性能での通信を確保する非機能要件達成処理モジュールを選択する。このように、非機能要件処理部１１４は、アプリケーション１０２に適したモジュールを選択し、アプリケーション１０２と外部システム１０２０との間の処理を適切な状態で実行させることを可能としている。
【００６５】
また、非機能要件処理部１１４は、非機能要件（要件項目）のうちの「データの信頼性」に関する非機能要件については、アプリケーション開発者あるいはシステム開発者・管理者によって設定された、個々のアプリケーションあるいはシステムにおいて必要とするデータの信頼性要件値を参照し、そのアプリケーションあるいは内部システム１０１０との間で変換対象となる外部システム１０２０について、手続きの形態と使用する通信プロトコルの組み合わせを選択し、これに対する処理実施形態を選定する。
【００６６】
また、非機能要件処理部１１４は、ネットワーク形態をあらかじめ定義されている情報より取得する。また、必要に応じて信頼性を検証するテストを実施する。この信頼性検証は、新しい外部システム１０２０との接続・連携が必要になった際にその都度実施しても良いし、すべての外部システム１０２０との接続・連携の発生時にその都度実施しても良い。これらの設定値および情報から、信頼性要件値に対するプロトコルおよびネットワークの品質の比較、および通信プロトコル・ネットワーク形態に対して実施すべき項目の要否から、利用する非機能要件達成処理モジュールを選定する。具体的には、非機能要件処理部１１４は、ネットワーク性能上の余裕が十分あり、アプリケーション処理自体も高速に行う必要があり、かつ信頼性要求が非常に高い場合は、通信自体を多重化する非機能要件達成処理モジュールを選定する。あるいは、非機能要件処理部１１４は、ネットワーク性能は十分に余裕があるとは言えず、アプリケーション処理自体にはそれほど高速処理を処理されていないが、信頼性要求が高い場合には、必要に応じてデータの再送要求を行う非機能要件達成処理モジュールを選定する。ＣＲＣ（Cyclic Redundancy Check）等の一般的なデータ完全性チェックに対応可能な機能を対象外部システムが有している場合などでは、それらの機能を利用してデータ完全性をチェックする非機能要件達成処理モジュールを選定する。
【００６７】
さらに、非機能要件処理部１１４は、非機能要件（要件項目）のうちの「セキュリティ」に関する非機能要件については、アプリケーション開発者あるいはシステム開発者・管理者によって設定された、個々のアプリケーションあるいはシステムにおいて必要とするセキュリティ要件値を設定し、そのアプリケーションあるいは内部システム１０１０との間で変換対象となる外部システム１０２０について、手続きの形態と使用する通信プロトコルの組み合わせを選択し、これに対する処理実施形態を選定する。
【００６８】
また、非機能要件処理部１１４は、システム構成をあらかじめ定義されている情報から取得し、また、対象となる外部システム１０２０のセキュリティ仕様・性能の判定を、あらかじめ定義されている情報か、あるいは随時のアクセステストによって得られる情報より取得する。このセキュリティテストは、新しい外部システム１０２０との接続・連携が必要になった際にその都度実施しても良いし、すべての外部システム１０２０との接続・連携の発生時にその都度実施しても良い。これらの設定値および情報から、対象となる外部システム１０２０が必要となるセキュリティレベルを有しているか等の判定を行い、また、通信プロトコル・システム構成に対して必要なセキュリティ処理が実施可能か否かの判定を行った上で、利用する非機能要件達成処理モジュールを選定する。具体的には、非機能要件処理部１１４は、対象となる外部システム１０２０が、必要なセキュリティ要件に対応できないと判定した場合には、その外部システムへのアクセスを遮断したり、あるいは、データ取得は許容するがデータ更新は許容しない等といった部分的にアクセスをフィルタリングする非機能要件達成処理モジュールを選定する。あるいは、非機能要件処理部１１４は、共通の認証基盤を利用可能な外部システム１０２０が対象であれば、この認証基盤を利用して内部システム１０１０と外部システム１０２０の認証を行う非機能要件達成処理モジュールを選定する。あるいは、所定の暗号・複合化機能に対応した外部システム１０２０であれば、この暗号・複合化機能を利用する非機能要件達成処理モジュールを選定する。
【００６９】
そして、プロトコル変換処理部１１３は、以上により非機能要件処理部１１４によって選択された処理モジュールによって構成されたミドルウェアを生成し（ステップＳ６０５）、生成したミドルウェアを内部システム１０１０が有しているアプリケーションが動作しているサーバ１０１に組み込む（ステップＳ６０６）。このようなミドルウェアをサーバ１０１に組み込むことにより、例えば、ネットワークを介して相互接続した複数の独立したノードにより構成される分散システムにおいて、同一の規格や仕様に準拠したデータ管理及びデータアクセス処理を行う、１つ以上のノードを含むシステムおよびそのシステムとは異なるシステムとの間の相互接続および連携させることが可能となる。
【００７０】
より具体的には、システム間の相互接続・連携の際に、各々異なるシステムが準拠する規格等に基づくデータモデル、インタフェース、プロトコルの３階層にて、異なるシステム間の相互変換を実施し、プロトコルの階層では、手続きの形態のパターン、手続きの形態と使用する通信プロトコルの形態の組み合わせに対して変換の実施パターンおよび非機能要件を充足するための処理パターンを用意し、これらを共通部品とする一方、接続・連携する相手システム毎に相互接続・連携のための前記各階層での変換処理を、各々の共通部品の組み合わせにより実現し、これらの共通備品の組み合わせは、接続・連携する相手システム毎に外部定義として指定する。このようなプロトコルの階層にて、異なる規格・仕様のシステムと相互接続するための処理を実行するプログラム（処理モジュール）およびシステム構成等に応じてアプリケーションが要求する非機能要件を充足するための処理モジュールを、外部定義にしたがって選出し、構成しているので、異なる規格や仕様のシステムとの接続・連携が必要となるアプリケーションの開発において、個々の接続・連携処理の開発がアプリケーション自体の開発と分割され、アプリケーション開発者が直接考慮する必要がなくなった上で、個々の接続・連携処理の開発自体も容易化され、全体としてのシステム、アプリケーション開発の生産性を向上させることができる。
【実施例２】
【００７１】
上述した実施例１においては、アプリケーション処理部が外部システムに対してアクセスする際に必要な処理をミドルウェアが行うことにより、アプリケーション開発者等が外部システムとの間の変換処理を考慮することなく適切なモジュールの組み合わせを選択し、両者のデータの受け渡し等を可能とした。しかし、図９に示すように、実施例２においては、複数のサーバ９０７が有する個々のアプリケーション処理部９０１から外部システム１０２０にアクセスする際に必要な処理を、通信経路上のゲートウェイサーバ９０５が有する内部記憶装置１１５に記憶されたミドルウェア９０２で行うこととする。
【００７２】
この場合、各々のサーバ９０７のアプリケーション処理部９０１を一意に識別するために、ミドルウェア９０２に対応付けて識別情報９０４があらかじめ設定され、個々のアプリケーション処理部９０１の識別情報９０３とミドルウェアの識別情報９０４の組み合わせを、アプリケーション処理／ミドルウェア組み合わせ管理ＤＢ（Data Base）９０６により管理する。
【００７３】
その上で、ミドルウェア９０２を、アプリケーション処理部９０１が動作しているサーバ９０７上ではなく、別のサーバ、例えば、外部システム１０２０と内部システム１０１０との間に設置されたゲートウェイサーバ９０５上に組み込む。そして、アプリケーション処理部９０１が外部システム１０２０にアクセスする際、アプリケーション処理部９０１の識別情報９０３と、ミドルウェアの識別情報９０４とを照合し、アプリケーション処理部９０１の識別情報９０３とミドルウェア９０２の識別情報９０４の組み合わせを管理しているアプリケーション処理／ミドルウェア組み合わせ管理ＤＢ９０６を参照して、アプリケーション処理−ミドルウェア組合せ制御部９０８により、アプリケーションに対応するミドルウェアを自動的に選択してゲートウェイサーバ９０５上で動作させる。
【００７４】
このように構成することで、実施例１の場合と同様に、外部システムに対するアクセスを実現する。この方式によると、アプリケーション処理部９０１が動作しているサーバ９０７には新規のミドルウェア等の組み込み等、手を加える必要が一切無くなり、既設システム等をそのまま利用した上で外部システム１０２０と接続・連携することが可能となる。また、新しいアプリケーションがシステム内に導入された際に、そのアプリケーションの識別情報９０３を参照して、上述した実施例１に記載の方法により、その都度ミドルウェア９０２を自動的に生成して利用してもよい。
【実施例３】
【００７５】
上述した実施例１においては、アプリケーション処理部１０２が外部システムに対してアクセスする際に必要な処理をミドルウェアが行うことにより、アプリケーション開発者等が外部システムとの間の変換処理を考慮することなく適切なモジュールの組み合わせを選択し、両者のデータの受け渡し等を可能となり、また、上述した実施例２においては、データアクセスを実施するアプリケーション処理自体と切り離して、別のサーバ上にこの機能を配置することを可能とした。しかし、外部システムからの要求に応じて内部システムが種々の処理を行う場合もある。そこで、図１０に示すように、実施例３においては、このようなミドルウェア機能を、例えば、内部システム１２１０で利用されているデータが格納されているデータベース１００４が配置されているデータベースサーバ１００１上に配置する。このとき、外部システム１２２０から内部システム１２１０にアクセスする際に、規格あるいは仕様を選択し、実施例１に記載の手順でミドルウェア９０２を構築し、そのミドルウェア９０２によってデータモデル変換、インタフェース変換、プロトコル変換を行った上でデータベース１００４にアクセスして、外部システム１２２０が要求する処理を行う。
【００７６】
また、外部システム１２２０上のアプリケーション処理部１００２の識別情報は取得不可能である場合が多いため、アプリケーション処理の識別情報とミドルウェアの識別情報との対応付けではなく、要求種別／ミドルウェア組合せ選択部１００６が、外部システム１２２０からの要求がどのような種別であるかを要求メッセージ等のプロトコルから抽出し、この要求の種別とミドルウェア９０２の識別情報１００３の対応付け情報を要求種別／ミドルウェア組み合わせ管理ＤＢ１００５により管理することによって、実施例２の場合と同様に、対応するミドルウェアを自動的に選択する処理をデータベースサーバ１００１上で動作させる。これにより、外部システム１２２０から内部システム１２１０のデータへのアクセスに対応可能となる。
【００７７】
なお、本発明は、上記実施の形態そのままに限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で構成要素を変形して具体化することができる。また、上記実施の形態に開示されている複数の構成要素の適宜な組み合わせにより、種々の発明を形成することができる。例えば、実施の形態に示される全構成要素からいくつかの構成要素を削除してもよい。さらに、異なる実施の形態にわたる構成要素を適宜組み合わせても良い。
【符号の説明】
【００７８】
１０００、２０００、３０００ 分散システム
１０１０、１１１０、１２１０ 内部システム
１０２０、１２２０ 外部システム
１０１ サーバ（内部システム）
１０２ アプリケーション処理部
１０３ サーバ（外部システム）
１０４ データベース
１０５、９０３ 識別情報
１０６ ミドルウェア
１０７ データモデル変換部
１０８ インタフェース変換部
１０９ プロトコル変換部
１１０ データモデル外部定義
１１１ インタフェース外部定義
１１２ プロトコル外部定義
１１３ 組合せ処理部
１１４ 非機能要件達成処理部
１１５ 内部記憶装置
１１６ ネットワークアクセス部
Ｎ ネットワーク。
【特許請求の範囲】
【請求項１】
所定の規格あるいは仕様に準拠して作成されたシステムから前記システムとは異なる規格あるいは仕様に準拠して作成された他のシステムへのアクセスが可能な分散システムにおけるシステム間連携装置であって、
前記システムと前記他のシステムとの間における通信プロトコルの形態と前記システムおよび前記他のシステムのシステム構成およびネットワーク構成とを対応付けたプロトコル定義と前記システムが所定のアプリケーションにより前記他のシステムにアクセスするための前記所定のアプリケーションに固有の要件である非機能要件と、前記プロトコル定義および前記非機能要件に応じた前記アプリケーションを実行させるための複数のモジュールと、を記憶する記憶部と、
前記他のシステムにアクセスして前記所定のアプリケーションを実行させるためのアプリケーション処理部と、
前記アプリケーション処理部が前記所定のアプリケーションの実行指示を受けた場合に、前記所定のアプリケーションからの要求に応じて、前記プロトコル定義に含まれる前記通信プロトコル形態および前記システム構成および前記ネットワーク構成に基づいて定められる前記システムと前記他のシステムとの間の処理を行うために必要な要件値と前記非機能要件との組み合わせに基づいて、前記複数のモジュールの中から前記アプリケーションによる処理を実行させるために必要なモジュールを選択する組合せ処理部と、
を備えることを特徴とするシステム間連携装置。
【請求項２】
前記組合せ処理部は、前記システムが有する前記アプリケーションからの要求を実行するための処理の手続きがリクエスト／リプライ型であって、前記通信プロトコルの形態がパブリッシュ／サブスクライブ型である場合には、前記他のシステムと前記システムとの間に設けられた前記アプリケーションからのアクセスを受け付けるための一時蓄積用データベースを、前記他のシステムから受け付けたパブリッシュ／サブスクライブを受けて更新するとともに、前記アプリケーションからのリクエストに対してリプライを返す処理を前記モジュールとして組み込む、
ことを特徴とする請求項１に記載のシステム間連携装置。
【請求項３】
前記組合せ処理部は、前記システムが有する前記アプリケーションからの要求を実行するための処理の手続きがパブリッシュ／サブスクライブ型であって、前記通信プロトコルの形態がリクエスト／リプライ型である場合には、前記他のシステムと前記システムとの間に設けられた前記アプリケーションからのアクセスを受け付けるための一時蓄積用データベースを、前記他のシステムに対し随時リクエスト／リプライを実行して更新するとともに、前記アプリケーションからのサブスクライブに対してパブリッシュを返す処理前記モジュールとして組み込む、
ことを特徴とする請求項１に記載のシステム間連携装置。
【請求項４】
前記組合せ処理部は、前記システムが有する前記アプリケーションからの要求を実行するための処理の手続きが一方向型であって、前記通信プロトコルの形態がリクエスト／リプライ型である場合には、前記他のシステムと前記システムとの間に設けられた一方的なデータ送信を実行する一時蓄積用データベースを、前記他のシステムに対し随時リクエスト／リプライを実行して更新するとともに、前記アプリケーションに対して一方的なデータ送信を行う処理を前記モジュールとして組み込む、
ことを特徴とする請求項１に記載のシステム間連携装置。
【請求項５】
前記組合せ処理部は、前記システムが有する前記アプリケーションからの要求を実行するための処理の手続きが一方向型であって、前記通信プロトコルの形態がパブリッシュ／サブスクライブ型である場合には、前記他のシステムと前記システムとの間に設けられた一方的なデータ送信を実行する一時蓄積用データベースを、前記他のシステムに対し随時パブリッシュ／サブスクライブを実行して更新するとともに、前記アプリケーションに対して一方的なデータ送信を行う処理を前記モジュールとして組み込む、
ことを特徴とする請求項１に記載のシステム間連携装置。
【請求項６】
前記要件値には、あらかじめ定められた前記システムまたは前記他のシステムの性能を満たすための性能要件値を含み、
前記組合せ処理部は、前記システムと前記他のシステムとの間における通信プロトコルの形態と前記システムおよび前記他のシステムのシステム構成およびネットワーク構成との組合せと、前記性能要件値とに基づいて、前記複数のモジュールの中から前記アプリケーションによる処理を実行させるために必要なモジュールを選択する、
ことを特徴とする請求項１〜５に記載のシステム間連携装置。
【請求項７】
前記組合せ処理部は、前記性能要件値を満たすために前記システムと前記他のシステムとの間のネットワーク性能が低下する場合には、前記他のシステムで用いられるデータを前記アプリケーションが動作する前記システムを有したサーバに前記データを複製し、前記複製されたデータに対してアクセスすることにより前記アプリケーションに前記処理を実行させる処理を前記モジュールとして組み込む、
ことを特徴とする請求項６に記載のシステム間連携装置。
【請求項８】
前記組合せ処理部は、前記性能要件値を満たすために前記システムと前記他のシステムとの間のネットワーク性能がトラフィックの状況により不十分になる可能性がある場合には、前記システムと前記他のシステムとの間で通信コネクションを生成し、前記性能要件値を満たす一定の性能での通信を確保させる処理を前記モジュールとして組み込む、
ことを特徴とする請求項６に記載のシステム間連携装置。
【請求項９】
前記要件値には、あらかじめ定められた前記システムと前記他のシステムとの間でやりとりされるデータの信頼性を満たすための信頼性要件値を含み、
前記組合せ処理部は、前記システムと前記他のシステムとの間における通信プロトコルの形態と前記システムおよび前記他のシステムのシステム構成およびネットワーク構成との組合せと、前記信頼性要件値とに基づいて、前記複数のモジュールの中から前記アプリケーションによる処理を実行させるために必要なモジュールを選択する、
ことを特徴とする請求項１〜８に記載のシステム間連携装置。
【請求項１０】
前記組合せ処理部は、前記システムと前記他のシステムとの間のネットワークが多重化され、かつ前記データの信頼性が高い場合には、前記ネットワークにおける通信を多重化させる処理を前記モジュールとして組み込む、
ことを特徴とする請求項９に記載のシステム間連携装置。
【請求項１１】
前記組合せ処理部は、前記ネットワークが多重化されていない場合であって、通信プロトコルが前記データの再送をサポートしており、かつ前記データの信頼性が高い場合には、前記データの再送要求を行う処理を前記モジュールとして組み込む、
ことを特徴とする請求項９に記載のシステム間連携装置。
【請求項１２】
前記組合せ処理部は、前記ネットワークが多重化されていない場合であって、前記他のシステムが前記データの完全性をチェックするためのチェック処理部を有している場合には、前記チェック処理部による前記データのチェックを行わせる処理を前記モジュールとして組み込む、
ことを特徴とする請求項９に記載のシステム間連携装置。
【請求項１３】
前記要件値には、あらかじめ定められた前記システムおよび前記他のシステムのセキュリティレベルを満たすためのセキュリティ要件値を含み、
前記組合せ処理部は、前記システムおよび前記他のシステムとの間における通信プロトコルの形態と前記システムおよび前記他のシステムのシステム構成およびネットワーク構成との組合せと、前記セキュリティ要件値とに基づいて、前記複数のモジュールの中から前記アプリケーションによる処理を実行させるために必要なモジュールを選択する、
ことを特徴とする請求項１〜１２に記載のシステム間連携装置。
【請求項１４】
前記組合せ処理部は、前記他のシステムが前記セキュリティ要件値を満たしていない判定した場合には、前記他のシステムへのアクセスを遮断し、または部分的にアクセスをフィルタリングする処理を前記モジュールとして組み込む、
ことを特徴とする請求項１３に記載のシステム間連携装置。
【請求項１５】
前記組合せ処理部は、前記他のシステムが前記システムと共通の認証基盤を利用可能なシステムである場合には前記共通の認証基盤に基づいて前記システムと前記他のシステム間の認証を行う処理を前記モジュールとして組み込む、
ことを特徴とする請求項１３に記載のシステム間連携装置。
【請求項１６】
前記組合せ処理部は、前記他のシステムが所定の暗号／複合化機能に対応したシステムである場合には前記所定の暗号／複合化機能に基づいて前記システムと前記他のシステム間の認証を行う処理を前記モジュールとして組み込む、
ことを特徴とする請求項１３に記載のシステム間連携装置。
【請求項１７】
前記組合せ処理部が行う機能を、前記システムおよび前記他のシステムとの間の通信経路に配置したサーバに保持させる、
ことを特徴とする請求項１〜１６に記載のシステム間連携装置。
【請求項１８】
前記組合せ処理部は、前記アプリケーションが実行される際に、その都度、前記他のシステムが、あらかじめ定められた前記システムまたは前記他のシステムの性能を満たすための性能要件値、あらかじめ定められた前記システムと前記他のシステムとの間でやりとりされるデータの信頼性を満たすための信頼性要件値、またはあらかじめ定められた前記システムおよび前記他のシステムのセキュリティレベルを満たすためのセキュリティ要件値を満たしているかを判定し、前記モジュールを選択する、
ことを特徴とする請求項６〜１７に記載のシステム間連携装置。
【請求項１】
所定の規格あるいは仕様に準拠して作成されたシステムから前記システムとは異なる規格あるいは仕様に準拠して作成された他のシステムへのアクセスが可能な分散システムにおけるシステム間連携装置であって、
前記システムと前記他のシステムとの間における通信プロトコルの形態と前記システムおよび前記他のシステムのシステム構成およびネットワーク構成とを対応付けたプロトコル定義と前記システムが所定のアプリケーションにより前記他のシステムにアクセスするための前記所定のアプリケーションに固有の要件である非機能要件と、前記プロトコル定義および前記非機能要件に応じた前記アプリケーションを実行させるための複数のモジュールと、を記憶する記憶部と、
前記他のシステムにアクセスして前記所定のアプリケーションを実行させるためのアプリケーション処理部と、
前記アプリケーション処理部が前記所定のアプリケーションの実行指示を受けた場合に、前記所定のアプリケーションからの要求に応じて、前記プロトコル定義に含まれる前記通信プロトコル形態および前記システム構成および前記ネットワーク構成に基づいて定められる前記システムと前記他のシステムとの間の処理を行うために必要な要件値と前記非機能要件との組み合わせに基づいて、前記複数のモジュールの中から前記アプリケーションによる処理を実行させるために必要なモジュールを選択する組合せ処理部と、
を備えることを特徴とするシステム間連携装置。
【請求項２】
前記組合せ処理部は、前記システムが有する前記アプリケーションからの要求を実行するための処理の手続きがリクエスト／リプライ型であって、前記通信プロトコルの形態がパブリッシュ／サブスクライブ型である場合には、前記他のシステムと前記システムとの間に設けられた前記アプリケーションからのアクセスを受け付けるための一時蓄積用データベースを、前記他のシステムから受け付けたパブリッシュ／サブスクライブを受けて更新するとともに、前記アプリケーションからのリクエストに対してリプライを返す処理を前記モジュールとして組み込む、
ことを特徴とする請求項１に記載のシステム間連携装置。
【請求項３】
前記組合せ処理部は、前記システムが有する前記アプリケーションからの要求を実行するための処理の手続きがパブリッシュ／サブスクライブ型であって、前記通信プロトコルの形態がリクエスト／リプライ型である場合には、前記他のシステムと前記システムとの間に設けられた前記アプリケーションからのアクセスを受け付けるための一時蓄積用データベースを、前記他のシステムに対し随時リクエスト／リプライを実行して更新するとともに、前記アプリケーションからのサブスクライブに対してパブリッシュを返す処理前記モジュールとして組み込む、
ことを特徴とする請求項１に記載のシステム間連携装置。
【請求項４】
前記組合せ処理部は、前記システムが有する前記アプリケーションからの要求を実行するための処理の手続きが一方向型であって、前記通信プロトコルの形態がリクエスト／リプライ型である場合には、前記他のシステムと前記システムとの間に設けられた一方的なデータ送信を実行する一時蓄積用データベースを、前記他のシステムに対し随時リクエスト／リプライを実行して更新するとともに、前記アプリケーションに対して一方的なデータ送信を行う処理を前記モジュールとして組み込む、
ことを特徴とする請求項１に記載のシステム間連携装置。
【請求項５】
前記組合せ処理部は、前記システムが有する前記アプリケーションからの要求を実行するための処理の手続きが一方向型であって、前記通信プロトコルの形態がパブリッシュ／サブスクライブ型である場合には、前記他のシステムと前記システムとの間に設けられた一方的なデータ送信を実行する一時蓄積用データベースを、前記他のシステムに対し随時パブリッシュ／サブスクライブを実行して更新するとともに、前記アプリケーションに対して一方的なデータ送信を行う処理を前記モジュールとして組み込む、
ことを特徴とする請求項１に記載のシステム間連携装置。
【請求項６】
前記要件値には、あらかじめ定められた前記システムまたは前記他のシステムの性能を満たすための性能要件値を含み、
前記組合せ処理部は、前記システムと前記他のシステムとの間における通信プロトコルの形態と前記システムおよび前記他のシステムのシステム構成およびネットワーク構成との組合せと、前記性能要件値とに基づいて、前記複数のモジュールの中から前記アプリケーションによる処理を実行させるために必要なモジュールを選択する、
ことを特徴とする請求項１〜５に記載のシステム間連携装置。
【請求項７】
前記組合せ処理部は、前記性能要件値を満たすために前記システムと前記他のシステムとの間のネットワーク性能が低下する場合には、前記他のシステムで用いられるデータを前記アプリケーションが動作する前記システムを有したサーバに前記データを複製し、前記複製されたデータに対してアクセスすることにより前記アプリケーションに前記処理を実行させる処理を前記モジュールとして組み込む、
ことを特徴とする請求項６に記載のシステム間連携装置。
【請求項８】
前記組合せ処理部は、前記性能要件値を満たすために前記システムと前記他のシステムとの間のネットワーク性能がトラフィックの状況により不十分になる可能性がある場合には、前記システムと前記他のシステムとの間で通信コネクションを生成し、前記性能要件値を満たす一定の性能での通信を確保させる処理を前記モジュールとして組み込む、
ことを特徴とする請求項６に記載のシステム間連携装置。
【請求項９】
前記要件値には、あらかじめ定められた前記システムと前記他のシステムとの間でやりとりされるデータの信頼性を満たすための信頼性要件値を含み、
前記組合せ処理部は、前記システムと前記他のシステムとの間における通信プロトコルの形態と前記システムおよび前記他のシステムのシステム構成およびネットワーク構成との組合せと、前記信頼性要件値とに基づいて、前記複数のモジュールの中から前記アプリケーションによる処理を実行させるために必要なモジュールを選択する、
ことを特徴とする請求項１〜８に記載のシステム間連携装置。
【請求項１０】
前記組合せ処理部は、前記システムと前記他のシステムとの間のネットワークが多重化され、かつ前記データの信頼性が高い場合には、前記ネットワークにおける通信を多重化させる処理を前記モジュールとして組み込む、
ことを特徴とする請求項９に記載のシステム間連携装置。
【請求項１１】
前記組合せ処理部は、前記ネットワークが多重化されていない場合であって、通信プロトコルが前記データの再送をサポートしており、かつ前記データの信頼性が高い場合には、前記データの再送要求を行う処理を前記モジュールとして組み込む、
ことを特徴とする請求項９に記載のシステム間連携装置。
【請求項１２】
前記組合せ処理部は、前記ネットワークが多重化されていない場合であって、前記他のシステムが前記データの完全性をチェックするためのチェック処理部を有している場合には、前記チェック処理部による前記データのチェックを行わせる処理を前記モジュールとして組み込む、
ことを特徴とする請求項９に記載のシステム間連携装置。
【請求項１３】
前記要件値には、あらかじめ定められた前記システムおよび前記他のシステムのセキュリティレベルを満たすためのセキュリティ要件値を含み、
前記組合せ処理部は、前記システムおよび前記他のシステムとの間における通信プロトコルの形態と前記システムおよび前記他のシステムのシステム構成およびネットワーク構成との組合せと、前記セキュリティ要件値とに基づいて、前記複数のモジュールの中から前記アプリケーションによる処理を実行させるために必要なモジュールを選択する、
ことを特徴とする請求項１〜１２に記載のシステム間連携装置。
【請求項１４】
前記組合せ処理部は、前記他のシステムが前記セキュリティ要件値を満たしていない判定した場合には、前記他のシステムへのアクセスを遮断し、または部分的にアクセスをフィルタリングする処理を前記モジュールとして組み込む、
ことを特徴とする請求項１３に記載のシステム間連携装置。
【請求項１５】
前記組合せ処理部は、前記他のシステムが前記システムと共通の認証基盤を利用可能なシステムである場合には前記共通の認証基盤に基づいて前記システムと前記他のシステム間の認証を行う処理を前記モジュールとして組み込む、
ことを特徴とする請求項１３に記載のシステム間連携装置。
【請求項１６】
前記組合せ処理部は、前記他のシステムが所定の暗号／複合化機能に対応したシステムである場合には前記所定の暗号／複合化機能に基づいて前記システムと前記他のシステム間の認証を行う処理を前記モジュールとして組み込む、
ことを特徴とする請求項１３に記載のシステム間連携装置。
【請求項１７】
前記組合せ処理部が行う機能を、前記システムおよび前記他のシステムとの間の通信経路に配置したサーバに保持させる、
ことを特徴とする請求項１〜１６に記載のシステム間連携装置。
【請求項１８】
前記組合せ処理部は、前記アプリケーションが実行される際に、その都度、前記他のシステムが、あらかじめ定められた前記システムまたは前記他のシステムの性能を満たすための性能要件値、あらかじめ定められた前記システムと前記他のシステムとの間でやりとりされるデータの信頼性を満たすための信頼性要件値、またはあらかじめ定められた前記システムおよび前記他のシステムのセキュリティレベルを満たすためのセキュリティ要件値を満たしているかを判定し、前記モジュールを選択する、
ことを特徴とする請求項６〜１７に記載のシステム間連携装置。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【公開番号】特開２０１３−６１７６２（Ｐ２０１３−６１７６２Ａ）
【公開日】平成２５年４月４日（２０１３．４．４）
【国際特許分類】
【出願番号】特願２０１１−１９９２０５（Ｐ２０１１−１９９２０５）
【出願日】平成２３年９月１３日（２０１１．９．１３）
【出願人】（０００００５１０８）株式会社日立製作所 (27,607)
【Ｆターム（参考）】
【公開日】平成２５年４月４日（２０１３．４．４）
【国際特許分類】
【出願日】平成２３年９月１３日（２０１１．９．１３）
【出願人】（０００００５１０８）株式会社日立製作所 (27,607)
【Ｆターム（参考）】
[ Back to top ]