(57)【要約】【課題】  １つのオペレーティングシステムが動作する計算機システムにおいて、通信方式・アプリケーション制御体系の異なるアプリケーション実行基盤間で、正しい情報の確実・高速な受け渡しを実現する。【解決手段】実行環境基盤の異なるアプリケーションプログラム110、210の間で情報の登録・参照を行うためのインタフェースを提供する通信プログラムを作成し、情報を登録・参照する機能および、情報伝達対象となる業務プログラムがある場所を記憶する機能を備える。通信プログラムは一方の業務プログラムが情報を登録したときは、他方の業務プログラムへ情報が参照されるべきことを通知する。このような通信プログラムにより、アプリケーション間連携を行う。【選択図】  図１
2006031491.tif 000002
【特許請求の範囲】
【請求項１】
所定の処理を実行じ、実行環境基盤の異なる２以上のアプリケーションプログラムを連携するアプリケーションプログラム間連携システムにおいて、
複数のアプリケーションプログラム間の通信を行う通信プログラムを有する記憶装置と、
前記記憶装置と接続され、前記通信プログラムを実行する処理装置であって、所定のアプリケーションプログラムから他のアプリケーションプログラムに対するリクエスト内容を記して発行したメッセージを受け取り、当該リクエスト内容を実行するアプリケーションプログラムを特定し、特定されたアプリケーションプログラムに対して、当該リクエスト内容を記したメッセージを通知する処理装置を有することを特徴とするアプリケーションプログラム間連携システム。
【請求項２】
請求項１に記載のアプリケーションプログラム間連携システムにおいて、
前記記憶装置は、当該アプリケーションプログラム間連携システムを動作させるためのオペレーティングシステムを保存し、前記通信プログラムは前記オペレーティングシステムに含まれることを特徴とするアプリケーションプログラム間連携システム。
【請求項３】
請求項１または２のいずれかに記載のアプリケーションプログラム間連携システムにおいて、
前記処理装置は、前記特定されたアプリケーションプログラムの実行基盤が採用している通信プロトコルを特定し、特定された通信プロトコルに従って、前記メッセージを通知することを特徴とするアプリケーションプログラム間連携システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、２以上の異なるアプリケーションを連携させて、業務サービスを行う技術に関する。その中も特に、異なる通信基盤上で動作するアプリケーションを連携させて、１つの業務サービスを提供するためのアプリケーション間連携システム、アプリケーション間の連携方法およびそれを実現するプログラムに関する。
【背景技術】
【０００２】
従来、２以上のアプリケーション、特に、異なる通信基盤上で動作するアプリケーション間の連携を行うためには、それぞれのアプリケーション間で送受信されるメッセージの経路制御や通信基盤に対応するプロトコルの変換を行う機能をもつコアとなるシステムに接続し、このコアとなるシステムを介してアプリケーション間を連携させる方式（ハブ・アンド・スポーク）が提案されている。
【０００３】
上述の複数アプリケーションは、ハブに接続することにより、お互いの通信基盤を意識することなく連携できる。各通信基盤間の差違をハブが吸収するので、各通信基盤はハブと接続すれば連携が可能になる。新たなサービスを構築する場合、各アプリケーションは無変更（あるいはユーザインターフェースなどに関する少ない変更）で、ハブ内に各アプリケーションを連携させる処理手順を定義することにより、各システムの連携を実現する。この一例として特許文献１がある。
【０００４】
【特許文献１】特開２００３−６７３５６号公報
【発明の開示】
【発明が解決しようとする課題】
【０００５】
異なる複数のアプリケーションプログラムを連携させてサービスを提供する場合に、アプリケーションプログラムは同一のプラットフォーム上であっても、同一の通信基盤上で開発されているものではなく、独自色の強い通信基盤上での動作が必要であり、任意の異なるアプリケーション間の連携は困難である。
【０００６】
この場合、任意の異なるアプリケーションプログラム間の連携を行う手段として、ハブ・アンド・スポーク方式の構成が提案されているが、同一のプラットフォーム上の異なる通信基盤上で動作するアプリケーションプログラムでは、メッセージのフロー制御、プロトコル変換を行う手段を構築する必要があり、アプリケーション間連携の実現は困難である。
また、前述のハブに相当する部分に、トラフィック及び、トランザクションが集中し、さらにメッセージのフロー制御や、プロトコル変換もハブに相当する部分に集中して存在するため、大規模なアプリケーション間連携システムを構築した場合、ハブに相当する部分にボトルネックが発生し、連携処理の高速化が困難となる問題がある。
【０００７】
さらに、異なる複数のアプリケーションプログラムのメッセージ送達に関するステータスは、それぞれのアプリケーションプログラムが動作する通信基盤上で保有管理しているため、アプリケーション間連携システムにおける送達確認は、各通信基盤上で情報を収集し、同期を取らざるを得ないという問題点がある。
【課題を解決するための手段】
【０００８】
本発明のアプリケーション間連携システムは、送受信されるメッセージを格納するＤＢキューと、ＤＢキューにメッセージを格納するためのＤＢキューアクセス部を備え、送信するメッセージをＤＢキューへ登録する機能、および、ＤＢキューに登録されているメッセージを参照する機能を提供する。また、メッセージの送信要求に対しイベントを発生させるイベント部を備え、ＤＢキューにメッセージが登録されたことをトリガとしてメッセージ送信先となるアプリケーションプログラムを起動する機能を提供する。これにより、送信側と受信側のアプリケーションプログラム間で、ＤＢキューを介して非同期に通信することが可能となる。
【０００９】
あるいは、ハブシステムを介した既存システムとの接続用に専用アダプタを準備し、メッセージ読み出し要求にもとづき、ＤＢキューからメッセージを参照し、既存のアダプタにメッセージを転送する機能を提供する。これにより既存システムとの通信が可能となる。
さらにメッセージの登録トランザクション、および参照トランザクションと同期させ、データの整合性を保証する機能を提供する。これにより、メッセージの送達情報をＤＢキュー上で一元管理することが可能となる。
【００１０】
また、登録されているアプリケーションプログラムやアダプタの生死状態と負荷状態を管理し、受信側のアプリケーションプログラムにメッセージを振り分ける機能を提供する。
【発明の効果】
【００１１】
本発明では、同一プラットフォーム上で動作する、異なる通信基盤に依存せず、かつ連携処理の高速化を図ることに加え、メッセージの送達情報を一元管理することを可能とする。さらに、異なる計算機システム上のプラットフォーム上で動作する、異なる通信基盤の連携処理の高速化を図る。
【発明を実施するための最良の形態】
【００１２】
本発明の実施の形態について、図面を用いて説明する。本実施の形態は、業務間の連携をする場合の処理実行制御の仕組みを例に説明するが、本発明はそれに限定されるものではない。
【００１３】
まず、本実施の形態における処理実行制御の仕組みの概念図を図1に示す。300は通信プログラム、100/200は特定の通信基盤、110/210はそれぞれの通信基盤上で実行される業務である。通信基盤100/200、業務110/210は１つ、または複数存在する。通信プログラムの中には、ＤＢキュー（メッセージ格納領域）310、ｎａｍｅ制御部320、ＤＢキューアクセス部330、イベント制御部360が存在する。通信基盤上には通信プログラムが提供するメッセージ送信部130/230、メッセージ受信部140/240、業務の中にはメッセージ処理を行うコンポーネント120/220が存在する。
【００１４】
ｎａｍｅ制御部320は、送受信されるメッセージを処理するコンポーネント120/220に対し、それぞれのコンポーネントが送信先として送信可能状態にあるかどうか、および送信可能なコンポーネントについてはコンポーネントが存在するノードの負荷状態をコンポーネントのステータスとして保持する（340/350）。メッセージ送信プロセスからの送信先情報の検索要求に対し送信先情報を応答する(420)。
【００１５】
ＤＢキューアクセス部330は、メッセージ送信部130/230、メッセージ受信部140/240からの書き込み要求、読み出し要求にしたがって、ＤＢキュー（メッセージ格納領域）310に対して操作を行う。（440/490）
コンポーネント120は通信プログラムが提供する送信インタフェースをプログラム中に記述することによって、メッセージ送信部130に対し、送信要求を発行する（410）。さらに送信要求を含むトランザクション処理が正常終了したこと（トランザクションのコミット指示）を、メッセージ送信部通知する（450）。
メッセージ送信部130は、コンポーネント120からの送信要求を受け、ｎａｍｅ制御部に対し、送信先情報の検索要求を行った後(420)、コンポーネント120からの通知を待つ。コンポーネント120からの処理正常終了通知を受け（450）、ＤＢキューアクセス部330に対し、メッセージの書き込み指示を行うとともに（430）、イベント制御部に送信先のコンポーネント220起動のためのトリガを通知する（460）。
【００１６】
メッセージ受信部240は、イベント制御部360からの起動通知をトリガとし、ＤＢキューアクセス部にメッセージの読み出しを要求する（480）。さらにコンポーネント220を起動し（500）、読み出したメッセージをコンポーネント220に受け渡す（510）。また、コンポーネント220からトランザクション処理が正常に終了したことの通知を受け（520）、ＤＢキューアクセス部330にステータスの更新を要求する（530）。
【００１７】
コンポーネント220はメッセージ受信部からの起動指示により起動され、受信したメッセージを含む処理を行った後、トランザクションが終了したことをメッセージ受信部に通知する（520）。
【００１８】
既存システムと連携する場合、通信プログラムの処理実行制御の仕組みを図２に示す。800は既存システム上で動作する業務プログラムであり、業務110が存在する通信基盤100とは異なるプロトコルで業務110とメッセージのやり取りを行う。700は既存アダプタであり、ハブシステム上に存在する。600は通信プログラムが提供する専用アダプタであり、ハブシステム上に存在し、メッセージ送信部610、メッセージ受信部620を有する。ハブシステム上に存在する、専用アダプタ600と既存アダプタ700を用いて、業務110と業務800の間でのメッセージ変換、および通信基盤100と業務800が使用する通信基盤とのプロトコル変換を行う。
【００１９】
メッセージ受信部620は、イベント制御部360からのメッセージ転送指示をトリガとし（470）、ＤＢキューアクセス部にメッセージの読み出しを要求する（480）。読み出したメッセージを指定した定義に基づき、既存アダプタ700に受け渡す（630）。また、既存アダプタ700からメッセージが正常に転送されたことの通知を受け（520）、ＤＢキューアクセス部330にステータスの更新を要求する（530）。
【００２０】
ｎａｍｅ制御部が保持する情報の構成例を図３に示す。メッセージの送信先を規定するフィールド71、メッセージデータを格納するキューを指定するフィールド72、メッセージが処理されるコンポーネント/通信プログラム専用アダプタの名称を示すフィールド73、フィールド73が存在するノード名称を示すフィールド74、フィールド74に存在するコンポーネント/通信プログラム専用アダプタが稼動中か、停止中かといった稼動状態を示すフィールド75、フィールド74に存在するコンポーネント/通信プログラム専用アダプタの負荷が高いか低いかといった負荷状態を示すフィールド76からなる。フィールド74、75、76はフィールド73に記述したコンポーネント/ハブ専用アダプタが配置されているノードの数だけ存在する。
【００２１】
図４は、ＤＢキューに格納する情報の構成例である。メッセージの送信先を規定するフィールド81、格納したメッセージが送信先のコンポーネント/通信プログラム専用アダプタで処理されたのか、未処理かと言った処理状態を示すフィールド82、メッセージを一意に特定するための情報を示すフィールド83、送信するメッセージを格納するフィールド84からなる。
【００２２】
以下、本実施の形態の処理内容について、フローチャートに従って、説明する。図５に、通信プログラムを利用した場合のメッセージ送信、および受信のフローチャートを示す。
【００２３】
１．コンポーネント120から、通信プログラム300が提供するインタフェースを利用し、送信先業務（業務210）と送信データを指定して、メッセージの送信要求を行う。（処理11）
２．メッセージ送信部130は指定された送信先業務（業務210）をキーに、送信先のコンポーネント220がメッセージ送信可能な状態かどうかｎａｍｅ制御部に問合せを行う（処理12）。
【００２４】
３．ｎａｍｅ制御部は、メッセージ送信部からの検索要求が発生すると、保持しているステータスデータをもとに、業務210に送信するメッセージを格納するＤＢキューの情報（キューＩＤ72）、メッセージを処理するメッセージ送信先名称73を検索し、また、データ（75、76）を元に、送信可能なコンポーネント、およびハブ専用アダプタの中から、負荷分散情報に基づき送信先の情報を作成し、メッセージ送信部130に対し、キューＩＤ72、コンポーネント情報（メッセージ送信先名称73、動作するノード名称74、ステータス75、負荷情報76）を提供する（処理13）。送信可能なコンポーネントがなかった場合、メッセージ送信部130に対し、送信不可能を応答する。
【００２５】
４．メッセージ送信部は、応答データが送信不可能であった場合、コンポーネント120にエラー応答する（処理25、26）。
【００２６】
５．メッセージ送信部130は、通信基盤上のプロトコルにしたがって該当するＤＢキュー310にメッセージ書き込み指示を行う。この時メッセージＩＤ83とメッセージステータス82を取得し、ＤＢキューに格納する（処理15）。
【００２７】
６．メッセージ送信部130はメッセージの書き込みを含む処理が正常に終了したことを確認した後（コミットを契機）、ｎａｍｅ機能より取得した送信先ノード情報にもとづき、イベント制御部360を介し（処理17）、送信先のメッセージ受信部240に、業務210に該当するメッセージが格納されているキュー（キューＩＤ72）とメッセージＩＤ83、およびメッセージを処理するコンポーネント名称73を通知する（処理18）。また、キューＩＤ72、メッセージＩＤ83をメッセージ送信部のログ情報として保持する。
【００２８】
７．コンポーネント120でのメッセージの書き込みを含む処理が、正常に終了しなかった場合（ロールバック）、ＤＢキュー310のメッセージを削除する。このときイベント制御部360への通知は起動しない。（処理27、28）
８．イベント制御部360は、通知されたメッセージ送信先名称73を元に、メッセージ送信先がコンポーネントであれば、メッセージ受信部240にコンポーネント220の起動指示を通知し、専用アダプタであればメッセージ受信部620にメッセージ転送指示を通知する（処理19）。
【００２９】
９．メッセージ受信部240/620は通知された情報（ＤＢキューＩＤ72、メッセージＩＤ83）を元に、通信基盤上のプロトコルにしたがってＤＢキュー310よりメッセージを読み出す。（処理20）
１０．メッセージ受信部240は、通知されたコンポーネント名称73を元に、コンポーネント220を起動し、コンポーネント220にメッセージを渡す。（処理21）
１１．メッセージ受信部240は、読み込んだメッセージを含んだ処理が正常に終了したことを確認した後（コミット契機）（処理22）、ＤＢキュー310のメッセージのステータス82を読み出し済み（処理済）とする。（処理23）
１２．読み込んだメッセージを含んだ処理が正常に終了しなかった場合（ロールバック）、ＤＢキューのメッセージステータス82は読み出し済みとしない。（処理31、32）
１３．メッセージ受信部620は、通知された転送指示を元に、ハブのフロー制御に従い既存アダプタ700にメッセージを渡す。（処理29）
１４．メッセージ受信部620は、メッセージが正常に転送されたことを確認した後（処理30）、ＤＢキュー310のメッセージのステータス82を読み出し済み（処理済）とする。（処理23）
１５．読み込んだメッセージが正常に転送されなかった場合（ロールバック）、ＤＢキューのメッセージステータス82は読み出し済みとしない。（処理31、32）
図６に、ｎａｍｅ制御部320におけるコンポーネント120/220とハブ専用アダプタ700の生死確認情報、負荷情報の取得処理のフローチャートを示す。
【００３０】
１．ｎａｍｅ制御部は登録してあるコンポーネントに対し、特定の通信手段を用いてコンポーネントの生死状態（送信可能な状態かどうか）を監視する。（処理32）
２．ｎａｍｅ制御部は同一業務を実施するコンポーネントが複数存在する場合、および送信先のハブ専用アダプタが複数存在する場合、コンポーネントの負荷状態を特定の通信手段を用いて判断し、コンポーネント負荷状態を監視する。（処理33）
３．処理32の結果をコンポーネントステータス75へ、処理33の結果をコンポーネント負荷状態76へ書き込む。
【００３１】
図７に、DBキュー内の未処理メッセージを再実行する処理のフローチャートを示す。
１．読み込んだメッセージを再度実行させるためにコマンドを準備する。コマンドは、キューＩＤ72とメッセージＩＤ83を引数として実行され、メッセージ受信部240に通知する。この時、通知対象となるコンポーネント情報を、メッセージＩＤ83から業務名称取得し、検索キーとしてｎａｍｅ制御に問合せ、起動するコンポーネントを特定する。（処理41）
２．コマンド実行時には、メッセージステータス82を参照し（処理42）、未処理であった場合はメッセージ受信部に通知し（処理43）、処理済であった場合はコマンドの実行はしない（処理44,45）。
【産業上の利用可能性】
【００３２】
本発明は、異なる通信基盤上のアプリケーション間を連携させた1つの業務サービスを容易・高速にすることが可能となる。
【図面の簡単な説明】
【００３３】
【図１】本発明により、コンポーネント間の連携をする場合の、通信プログラムの処理実行制御の概念図である。
【図２】本発明により、既存システムと連携する場合の、通信プログラムの処理実行制御の概念図である。
【図３】ｎａｍｅ制御部が保持する情報の構成例である。
【図４】ＤＢキューに格納する情報の構成例である。
【図５】通信プログラムを利用した場合のメッセージ送信、および受信のフローチャートである。
【図６】ｎａｍｅ制御部320におけるコンポーネント120/220とハブ専用アダプタ700の生死確認情報、負荷情報の取得処理のフローチャートである。
【図７】ＤＢキュー内の未処理メッセージの、再実行処理のフローチャートである。
【符号の説明】
【００３４】
100  通信基盤
110  業務
120  コンポーネント
130  メッセージ送信部
140  メッセージ受信部
200  通信基盤
210  業務
220  コンポーネント
230  メッセージ送信部
240  メッセージ受信部
300  通信プログラム
310  ＤＢキュー
320  ｎａｍｅ制御部
330  ＤＢキューアクセス部
340  生死監視
350  負荷状態確認
360  イベント制御部
410  送信要求
420  検索応答
430  メッセージ書込み指示
440  書込み
450  正常終了通知
460  起動指示
470  起動指示
480  メッセージ読出し指示
490  読出し
500  コンポーネント起動
510  メッセージ渡し
520  正常終了通知
530  ステータス更新指示
600  専用アダプタ
610  メッセージ送信部
620  メッセージ受信部
630  メッセージ転送
700  既存アダプタ
800  業務
【図１】
2006031491.tif 000003
【図２】
2006031491.tif 000004
【図３】
2006031491.tif 000005
【図４】
2006031491.tif 000006
【図５】
2006031491.tif 000007
【図６】
2006031491.tif 000008
【図７】
2006031491.tif 000009