JP4102354B2 - アプリケーションフロー制御装置 - Google Patents
アプリケーションフロー制御装置 Download PDFInfo
- Publication number
- JP4102354B2 JP4102354B2 JP2004319620A JP2004319620A JP4102354B2 JP 4102354 B2 JP4102354 B2 JP 4102354B2 JP 2004319620 A JP2004319620 A JP 2004319620A JP 2004319620 A JP2004319620 A JP 2004319620A JP 4102354 B2 JP4102354 B2 JP 4102354B2
- Authority
- JP
- Japan
- Prior art keywords
- message
- application
- flow
- database
- flow definition
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/10—Flow control; Congestion control
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Computer And Data Communications (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Description
本発明は、業務処理を行う複数のアプリケーションの実行順序を制御するアプリケーションフロー制御装置に関する。
アプリケーションは、業務処理を行うソフトウェアモジュールである。情報システムの高度な統合のため、複数のアプリケーションを連携させてサービスを提供する企業の基幹システム等の分野においては、アプリケーションを連携させる仕組みが重要となる。
例えば、図１８に示すように、Ｗｅｂブラウザ等のクライアント１０１からの要求に応じて、サーバ１１１〜１１３上のアプリケーション１２１〜１２３を連携させる場合を考える。クライアント１０１およびサーバ１１１〜１１３は、通信ネットワークを介して接続されている。
アプリケーション１２１〜１２３は、それぞれ業務処理１〜３のためのアプリケーションであり、アプリケーション１２３は、業務用データベース１０２を更新する。クライアント１０１からの要求としては、例えば、以下の２つが挙げられる。
要求Ａ：業務処理１→業務処理３
要求Ｂ：業務処理１→業務処理２→業務処理３
要求Ａに対しては、最初にアプリケーション１２１、次にアプリケーション１２３が呼び出され、要求Ｂに対しては、アプリケーション１２１、アプリケーション１２２、アプリケーション１２３の順に呼び出される。この場合、アプリケーション１２１の次に呼び出される連携先のアプリケーションが不定であり、将来的に変わることも予想される。
要求Ａ：業務処理１→業務処理３
要求Ｂ：業務処理１→業務処理２→業務処理３
要求Ａに対しては、最初にアプリケーション１２１、次にアプリケーション１２３が呼び出され、要求Ｂに対しては、アプリケーション１２１、アプリケーション１２２、アプリケーション１２３の順に呼び出される。この場合、アプリケーション１２１の次に呼び出される連携先のアプリケーションが不定であり、将来的に変わることも予想される。
アプリケーション自体に連携先となるアプリケーションの情報をコーディングすると、アプリケーションの追加、削除等の変更があった場合に、その都度アプリケーションの呼び出し順序（関係）の修正が必要になる。
これに対して、アプリケーションの連携フローを作成し、それに基づいてアプリケーションを順次呼び出す仕組みがあると、前述のようなアプリケーション自体の修正が不要となるため、アプリケーションの可搬性が向上し、様々な業務に流用することが可能となる。このため、企業の基幹システムの分野においては、アプリケーションの統合方法としてフローの技術が利用されている。
また、基幹システムの特性上、アプリケーション間で転送されるメッセージ（データ）自体の保証、およびデータベース処理の一意性の保証（二重更新不可）といった信頼性が、併せて要求される。
図１９は、集中型のフロー制御システムを示している。このシステムでは、特定の管理サーバ１３１内にフロー制御部１３２が設けられる。フロー制御部１３２は、フロー１３３に記述されたアプリケーションの実行順序に従って、各アプリケーション１２１〜１２３を呼び出し、結果を状態管理データベース１３４に格納する。これにより、フロー１３３に従って業務処理が実行される。
特許文献１は、集中型のワークフロー支援実行システムに関し、特許文献２は、回覧物を回覧するワークフロー管理システムに関する。
特開２０００−２０７４７４号公報
特開２０００−２２２３０５号公報
しかしながら、上述した従来のアプリケーション連携の仕組みには、次のような問題がある。
集中型のフロー制御システムでは、フローの実行がフロー制御部の管理の下に１つの管理サーバで実行される。その結果、処理能力が管理サーバと通信ネットワークの能力によって限定されていた。
集中型のフロー制御システムでは、フローの実行がフロー制御部の管理の下に１つの管理サーバで実行される。その結果、処理能力が管理サーバと通信ネットワークの能力によって限定されていた。
また、集中型のフロー制御システムでは、フロー制御部から呼び出されるアプリケーションが停止していた場合は、その時点でフローが停止し、再開するためにはコマンドの実行や、一定間隔でのポーリング制御が必要であった。
これに対して、図２０に示すように、非同期通信にフロー制御を追加することも考えられる。図２０のシステムでは、アプリケーション１２１〜１２３に対して、フロー制御部１４１〜１４３およびメッセージキュー１５１〜１５３がそれぞれ設けられる。各フロー制御部は、アプリケーションを呼び出すとともに、次のアプリケーションのキューにメッセージを送信する。
しかし、一般的な非同期通信機能の上にフロー制御を構築しただけでは、メッセージ処理とアプリケーションのデータベース更新は別々のトランザクションで実行され、メッセージの保証はできても、メッセージとアプリケーションが扱う業務データの一貫性は保証されない。メッセージと業務データの整合性をとるためには、グローバルトランザクションを管理するトランザクションマネージャ１６１が必要となり、リカバリやパフォーマンスの観点でコストが高くなるという問題がある。
本発明の第１の課題は、特定の管理サーバを経由することなく、フローに基づいたアプリケーションの連携処理を実現することである。
本発明の第２の課題は、アプリケーション間のメッセージによりフロー制御を実現する場合に、メッセージとアプリケーションが扱う業務データの整合性をとることである。
本発明の第２の課題は、アプリケーション間のメッセージによりフロー制御を実現する場合に、メッセージとアプリケーションが扱う業務データの整合性をとることである。
図１は、本発明のアプリケーションフロー制御装置の原理図である。本発明の第１の局面におけるアプリケーションフロー制御装置は、連携処理を行う複数のアプリケーションの一部を有する装置であって、キュー手段１７１およびメッセージ処理手段１７２を備える。
キュー手段１７１は、複数のアプリケーションの実行順序を指定するフロー定義情報を含む第１のメッセージが送信されたことを示す送信トリガを受信する。メッセージ処理手段１７２は、その送信トリガに基づいて第１のメッセージを受信し、第１のメッセージに含まれるフロー定義情報に従って、実行すべきアプリケーション１７３を呼び出し、フロー定義情報と呼び出されたアプリケーション１７３の実行結果を含む第２のメッセージを、次のアプリケーションを実行する送信先に送信する。
送信元からアプリケーションフロー制御装置宛てに第１のメッセージが送信されると、その旨を通知する送信トリガがキュー手段１７１に送信される。メッセージ処理手段１７２は、その送信トリガに基づいて第１のメッセージが送信されたことを検知し、そのメッセージを取得する。そして、メッセージに含まれるフロー定義情報に従って、実行すべきアプリケーション１７３を特定する。呼び出されたアプリケーション１７３は、業務処理を実行し、実行結果をメッセージ処理手段１７２に返す。これを受けて、メッセージ処理手段１７２は、第２のメッセージを生成して送信先に送信する。
複数のアプリケーションが複数のアプリケーションフロー制御装置に分散配置された場合、１つのアプリケーションを有する装置から次のアプリケーションを有する装置に、直接、フロー制御のためのメッセージが送信される。
本発明の第２の局面において、第１の局面における第１のメッセージは、呼び出されたアプリケーション１７３により更新されるデータと同じデータベースに格納され、メッセージ処理手段１７２は、呼び出されたアプリケーション１７３がデータの更新に用いるトランザクションと同じトランザクションを用いて、第１のメッセージを第２のメッセージに更新し、第２のメッセージが送信されたことを示す送信トリガを送信先に送信する。
本発明によれば、アプリケーションを有する装置間でフロー制御のためのメッセージが転送されるため、特定の管理サーバを経由することなく、フローに基づいたアプリケーションの連携処理が実現される。また、アプリケーションが停止していた場合でも、管理サーバによる再開コマンドの実行やポーリング制御は不要である。
また、メッセージとアプリケーションデータを１つのトランザクションで更新することで、メッセージとアプリケーションが扱うデータの整合性をとることが可能になる。
以下、図面を参照しながら、本発明を実施するための最良の形態を詳細に説明する。
図２は、本実施形態のアプリケーションフロー制御システムの一例を示す構成図である。図２のシステムは、フロー定義作成ツール２０１、フロー定義データベース２０２、業務用データベース２０３、クライアント２０４、およびサーバ２０５−１〜２０５−３を備える。クライアント２０４は、フロー開始ＡＰＩ（Application Program Interface ）２１４を備え、サーバ２０５−ｉ（ｉ＝１，２，３）は、ｉ番目の業務処理を実行するアプリケーション２２１−ｉ、メッセージ処理部２２２−ｉ、およびキュー２２３−ｉを備える。
図２は、本実施形態のアプリケーションフロー制御システムの一例を示す構成図である。図２のシステムは、フロー定義作成ツール２０１、フロー定義データベース２０２、業務用データベース２０３、クライアント２０４、およびサーバ２０５−１〜２０５−３を備える。クライアント２０４は、フロー開始ＡＰＩ（Application Program Interface ）２１４を備え、サーバ２０５−ｉ（ｉ＝１，２，３）は、ｉ番目の業務処理を実行するアプリケーション２２１−ｉ、メッセージ処理部２２２−ｉ、およびキュー２２３−ｉを備える。
図２のシステムは、以下のような特徴を有する。
１．各サーバ２０５−ｉにメッセージ処理部２２２−ｉが設けられ、メッセージ中には、アプリケーションの実行順序に関するフロー定義２１１の情報が含まれる。
２．メッセージ処理部２２２−ｉは、メッセージを受け取ってアプリケーション２２１−ｉを呼び出し、その実行結果を次のメッセージ処理部に送ることで、フローを実行する。
３．メッセージ処理部２２２−ｉが受け取るメッセージは、メモリ上に設けられたキュー２２３−ｉを経由して処理され、アプリケーション２２１−ｉが停止している場合は、キュー２２３−ｉにメッセージを蓄積し、アプリケーション２２１−ｉが起動した契機で、メッセージ受信が可能になる。
４．メッセージには、フローの状態（現在位置）に関する情報が含まれており、メッセージ処理部２２２−ｉは、フロー定義２１１とフローの状態から、呼び出すべきアプリケーションを特定する。
５．メッセージには、フローの実行情報が含まれており、メッセージを参照することで、処理がどこまで進んだか、およびどのようなルートを経由したかを判別することができる。
６．メッセージデータ２１３は業務データ２１２と同じ業務用データベース２０３に格納され、業務用データベース２０３のトランザクションを使用することで、メッセージデータ２１３と業務データ２１２の整合性をとることができ、トランザクションマネージャが不要となる。
７．フローを実現するメッセージ処理部２２２−ｉ間の通信と、上記６の処理の一貫性を保証することで、業務処理の一意性が保証される。
１．各サーバ２０５−ｉにメッセージ処理部２２２−ｉが設けられ、メッセージ中には、アプリケーションの実行順序に関するフロー定義２１１の情報が含まれる。
２．メッセージ処理部２２２−ｉは、メッセージを受け取ってアプリケーション２２１−ｉを呼び出し、その実行結果を次のメッセージ処理部に送ることで、フローを実行する。
３．メッセージ処理部２２２−ｉが受け取るメッセージは、メモリ上に設けられたキュー２２３−ｉを経由して処理され、アプリケーション２２１−ｉが停止している場合は、キュー２２３−ｉにメッセージを蓄積し、アプリケーション２２１−ｉが起動した契機で、メッセージ受信が可能になる。
４．メッセージには、フローの状態（現在位置）に関する情報が含まれており、メッセージ処理部２２２−ｉは、フロー定義２１１とフローの状態から、呼び出すべきアプリケーションを特定する。
５．メッセージには、フローの実行情報が含まれており、メッセージを参照することで、処理がどこまで進んだか、およびどのようなルートを経由したかを判別することができる。
６．メッセージデータ２１３は業務データ２１２と同じ業務用データベース２０３に格納され、業務用データベース２０３のトランザクションを使用することで、メッセージデータ２１３と業務データ２１２の整合性をとることができ、トランザクションマネージャが不要となる。
７．フローを実現するメッセージ処理部２２２−ｉ間の通信と、上記６の処理の一貫性を保証することで、業務処理の一意性が保証される。
まず、フロー実行のための事前作業として、ユーザは、フロー定義作成ツール２０１によりフロー定義２１１を作成し、フロー定義データベース２０２に格納する。フロー定義２１１は、アプリケーション２２１−１、アプリケーション２２１−２、アプリケーション２２１−３の順に３つのアプリケーションが実行されることを表す。
次に、フロー実行時には、クライアント２０４がフロー開始ＡＰＩ２１４を実行する。フロー開始ＡＰＩ２１４は、フロー定義データベース２０２のフロー定義２１１を参照し、その情報をメッセージに設定して、最初に呼び出すべきアプリケーション２２１−１のメッセージ処理部２２２−１に、メッセージ２１５を送信する。
メッセージ処理部２２２−１は、メッセージ２１５に含まれるフロー定義２１１とフローの状態に基づいて、該当するアプリケーション２２１−１を呼び出す。アプリケーション２２１−１は１番目の業務処理を実行し、それが終了すると、サーバ２０５−１はメッセージ処理部２２２−１の処理に復帰する。そして、メッセージ処理部２２２−１は、次に呼び出すべきアプリケーション２２１−２のメッセージ処理部２２２−２にメッセージを送信する。
メッセージ処理部２２２−２は、メッセージ処理部２２２−１と同様にして、アプリケーション２２１−２を呼び出し、アプリケーション２２１−２は、２番目の業務処理を実行する。そして、メッセージ処理部２２２−２は、次に呼び出すべきアプリケーション２２１−３のメッセージ処理部２２２−３にメッセージを送信する。
メッセージ処理部２２２−３は、メッセージ処理部２２２−１と同様にして、アプリケーション２２１−３を呼び出し、アプリケーション２２１−３は、３番目の業務処理を実行して、業務用データベース２０３の業務データ２１２を更新する。そして、メッセージ処理部２２２−３は、フローの処理結果をクライアント２０４に通知する。
メッセージ処理部２２２−１および２２２−２は、フロー定義２１１および／または実行されたアプリケーションの処理結果に応じて、次に呼び出すべきアプリケーションを特定する。
なお、この例では、各サーバに１つのアプリケーションが実装されており、３つのサーバの３つのアプリケーションが連携して実行されているが、実際には、各サーバに複数のアプリケーションが実装され、多数のサーバの多数のアプリケーションを連携させることが可能である。
図３は、Ｊ２ＥＥ（商標）（Java（登録商標） 2 Enterprise Edition ）を用いたメッセージ処理部２２２−ｉの構成例を示している。図３のメッセージ処理部２２２−ｉは、ＪＭＳ（Java （登録商標）Message Service）３１１、およびＥＪＢ（登録商標）（Enterprise Java（登録商標）Beans）コンテナ３１２、およびフレームワーク３１３からなる。
業務用データベース２０３には、メッセージ領域３２１および業務用テーブル３２２が設けられ、メッセージ領域３２１にはレコード３３１〜３３５が格納され、業務用テーブル３２２には業務データ３４１および３４２が格納される。
この場合、メッセージ処理部２２２−ｉおよびアプリケーション２２１−ｉは、以下のような処理を行う。
＜送信処理＞
（Ｐ１）フレームワーク３１３がアプリケーション２２１−ｉを呼び出す。
（Ｐ２）アプリケーション２２１−ｉが業務用データベース２０３のコネクション３０３を使用して、業務用テーブル３２２の業務データ３４１を更新し、フレームワーク３１３の処理に復帰する。
（Ｐ３）フレームワーク３１３は、メッセージ領域３２１のレコード３３４を、Ｐ２と同じコネクション３０３を使用した更新処理によってロックする。レコード３３４は、メッセージ受信側が受信待ちを行うための受信待ちレコードである。このレコード３３４には、メッセージ本文の情報を保持するレコード３３２のレコード番号が設定される。
（Ｐ４）フレームワーク３１３は、メッセージを送信したことを示す送信トリガ（ＪＭＳメッセージ）を送信先のキューであるイベントチャネル３０２に送信し、ＪＭＳコミット処理を行う。送信トリガには、Ｐ３でロックされた受信待ちレコード３３４のレコード番号が設定される。
（Ｐ５）フレームワーク３１３は、送信するメッセージ本文の情報をメッセージ領域３２１のレコード３３２に格納する。
（Ｐ６）コンテナ３１２は、データベース処理をコミットする。これにより、コネクション３０３を使用したデータベース操作がコミットされ、受信待ちレコード３３４のロックが解除される。こうして、メッセージ送信と業務データの更新は１つのトランザクションで処理される。メッセージ受信側がレコードロック解除待ち状態になっている場合は、コミットにより待ちが解除され、受信処理が続行される。また、フレームワーク３１３は、メッセージ領域３２１のレコード３３１〜３３４を管理するためのレコード３３５を更新する。
＜受信処理＞
（Ｐ１１）コンテナ３１２は、同じサーバ内のキューであるイベントチャネル３０１から受信したメッセージを取り出す。そして、そのメッセージに格納されている、送信側がロックした受信待ちレコード３３３のレコード番号を取得して、フレームワーク３１３に渡す。フレームワーク３１３は、コネクション３０３を使用して、受信待ちレコード３３３に対して更新処理を行う。送信側のデータベース操作がコミットまたはロールバックされていない場合は、いずれかの操作が行われるまでロック解除待ち状態となる。
（Ｐ１２）フレームワーク３１３は、受信待ちレコード３３３のロックが解除され、更新処理が成功した後、レコード３３３に設定されている、メッセージ本文のレコード３３１のレコード番号を取得し、レコード３３１からメッセージ本文を取得する。
（Ｐ１３）フレームワーク３１３は、アプリケーション２２１−ｉを呼び出し、アプリケーション２２１−ｉは、Ｐ１１と同じコネクション３０３を使用して、業務用テーブル３２２の業務データ３４１を更新する。
（Ｐ１４）フレームワーク３１３は、取得したメッセージ本文のレコード３３１を削除する。
（Ｐ１５）コンテナ３１２は、データベース処理をコミットする。これにより、コネクション３０３を使用したデータベース操作がコミットされ、メッセージ受信と業務データの更新は１つのトランザクションで処理される。
（Ｐ１６）コンテナ３１２は、イベントチャネル３０１からのメッセージ受信処理をコミットする。
＜異常発生時にデータの一貫性を保証する処理＞
業務用データベース２０３の更新を通信を用いて通知先となるプロセスに連絡することは、一般的に考えられる。しかし、この場合、送信元でトランザクションのロールバック、プロセスダウン、サーバのダウン等の異常が発生すると、更新通知が届かなかったり、誤った情報を元に受信側の処理が実行されてしまう可能性がある。
＜送信処理＞
（Ｐ１）フレームワーク３１３がアプリケーション２２１−ｉを呼び出す。
（Ｐ２）アプリケーション２２１−ｉが業務用データベース２０３のコネクション３０３を使用して、業務用テーブル３２２の業務データ３４１を更新し、フレームワーク３１３の処理に復帰する。
（Ｐ３）フレームワーク３１３は、メッセージ領域３２１のレコード３３４を、Ｐ２と同じコネクション３０３を使用した更新処理によってロックする。レコード３３４は、メッセージ受信側が受信待ちを行うための受信待ちレコードである。このレコード３３４には、メッセージ本文の情報を保持するレコード３３２のレコード番号が設定される。
（Ｐ４）フレームワーク３１３は、メッセージを送信したことを示す送信トリガ（ＪＭＳメッセージ）を送信先のキューであるイベントチャネル３０２に送信し、ＪＭＳコミット処理を行う。送信トリガには、Ｐ３でロックされた受信待ちレコード３３４のレコード番号が設定される。
（Ｐ５）フレームワーク３１３は、送信するメッセージ本文の情報をメッセージ領域３２１のレコード３３２に格納する。
（Ｐ６）コンテナ３１２は、データベース処理をコミットする。これにより、コネクション３０３を使用したデータベース操作がコミットされ、受信待ちレコード３３４のロックが解除される。こうして、メッセージ送信と業務データの更新は１つのトランザクションで処理される。メッセージ受信側がレコードロック解除待ち状態になっている場合は、コミットにより待ちが解除され、受信処理が続行される。また、フレームワーク３１３は、メッセージ領域３２１のレコード３３１〜３３４を管理するためのレコード３３５を更新する。
＜受信処理＞
（Ｐ１１）コンテナ３１２は、同じサーバ内のキューであるイベントチャネル３０１から受信したメッセージを取り出す。そして、そのメッセージに格納されている、送信側がロックした受信待ちレコード３３３のレコード番号を取得して、フレームワーク３１３に渡す。フレームワーク３１３は、コネクション３０３を使用して、受信待ちレコード３３３に対して更新処理を行う。送信側のデータベース操作がコミットまたはロールバックされていない場合は、いずれかの操作が行われるまでロック解除待ち状態となる。
（Ｐ１２）フレームワーク３１３は、受信待ちレコード３３３のロックが解除され、更新処理が成功した後、レコード３３３に設定されている、メッセージ本文のレコード３３１のレコード番号を取得し、レコード３３１からメッセージ本文を取得する。
（Ｐ１３）フレームワーク３１３は、アプリケーション２２１−ｉを呼び出し、アプリケーション２２１−ｉは、Ｐ１１と同じコネクション３０３を使用して、業務用テーブル３２２の業務データ３４１を更新する。
（Ｐ１４）フレームワーク３１３は、取得したメッセージ本文のレコード３３１を削除する。
（Ｐ１５）コンテナ３１２は、データベース処理をコミットする。これにより、コネクション３０３を使用したデータベース操作がコミットされ、メッセージ受信と業務データの更新は１つのトランザクションで処理される。
（Ｐ１６）コンテナ３１２は、イベントチャネル３０１からのメッセージ受信処理をコミットする。
＜異常発生時にデータの一貫性を保証する処理＞
業務用データベース２０３の更新を通信を用いて通知先となるプロセスに連絡することは、一般的に考えられる。しかし、この場合、送信元でトランザクションのロールバック、プロセスダウン、サーバのダウン等の異常が発生すると、更新通知が届かなかったり、誤った情報を元に受信側の処理が実行されてしまう可能性がある。
例えば、以下の場合において、キューには送信トリガが格納されているが、対応するデータベースレコードが存在しない状態が発生する可能性がある。
（１）送信側でデータベース処理がコミットされた後、送信メッセージのロールバック、プロセスダウン等の異常が発生した場合
（２）受信側で送信メッセージがコミットされた後、データベース処理のコミットが失敗した場合
これらの場合には、メッセージ処理部２２２−ｉは、キュー内の送信トリガを無視することで対処する。具体的には、受信メッセージをコミットして受信処理を完了し、次の受信メッセージの受信処理を開始する。このような対処を行うことで、前述の異常が発生してもデータの一貫性を確保したフロー処理を実現することができる。
（１）送信側でデータベース処理がコミットされた後、送信メッセージのロールバック、プロセスダウン等の異常が発生した場合
（２）受信側で送信メッセージがコミットされた後、データベース処理のコミットが失敗した場合
これらの場合には、メッセージ処理部２２２−ｉは、キュー内の送信トリガを無視することで対処する。具体的には、受信メッセージをコミットして受信処理を完了し、次の受信メッセージの受信処理を開始する。このような対処を行うことで、前述の異常が発生してもデータの一貫性を確保したフロー処理を実現することができる。
上述したようなアプリケーションフロー制御システムによれば、以下のような効果が得られる。
１．アプリケーションから次のアプリケーションに、直接、フロー制御のためのメッセージが送信されるので、特定の管理サーバを経由することなく、多数のサーバを分散動作させた高速なメッセージ処理が可能となる。
２．集中型のフロー制御のように、フローを制御するプロセスが、呼び出したすべてのアプリケーションの処理完了を待ち合わせる必要がないため、プロセス（スレッド）の占有時間が短くなる。
３．アプリケーションの実行情報を収集することで、分散動作にもかかわらず、どの処理がどこまで進んだかのトラッキングが可能となる。
４．サーバダウン等の問題が発生した時に、中断点から再実行することができるので、高信頼なフロー制御が可能となる。
５．アプリケーションが起動したタイミングでフローの続きを実行できるため、ポーリングによる余計なＣＰＵ（Central Processing Unit ）の消費を防止できる。
６．トランザクションマネージャが不要なため、低コストでデータの整合性をとることができる。
１．アプリケーションから次のアプリケーションに、直接、フロー制御のためのメッセージが送信されるので、特定の管理サーバを経由することなく、多数のサーバを分散動作させた高速なメッセージ処理が可能となる。
２．集中型のフロー制御のように、フローを制御するプロセスが、呼び出したすべてのアプリケーションの処理完了を待ち合わせる必要がないため、プロセス（スレッド）の占有時間が短くなる。
３．アプリケーションの実行情報を収集することで、分散動作にもかかわらず、どの処理がどこまで進んだかのトラッキングが可能となる。
４．サーバダウン等の問題が発生した時に、中断点から再実行することができるので、高信頼なフロー制御が可能となる。
５．アプリケーションが起動したタイミングでフローの続きを実行できるため、ポーリングによる余計なＣＰＵ（Central Processing Unit ）の消費を防止できる。
６．トランザクションマネージャが不要なため、低コストでデータの整合性をとることができる。
次に、図４から図１５までを参照しながら、上述したアプリケーションフロー制御システムの構成および動作について、より詳細に説明する。
図２のフロー定義２１１は、アプリケーションの実行の流れを指定する情報であり、フロー定義作成ツール２０１により作成される。アプリケーションの実行の流れは、図４に示すように、アプリケーションに対応するアクティビティ（ＡＣＴ１〜ＡＣＴ５）を矢印でつなぐことで実現され、分岐部分（点線の矢印）には、例えば、以下のような条件式を記述することができる。
条件１：要素ｎ＞１０のとき、ＡＣＴ３に分岐する。
条件２：要素ｎ≦１０のとき、ＡＣＴ５に分岐する。
図２のフロー定義２１１は、アプリケーションの実行の流れを指定する情報であり、フロー定義作成ツール２０１により作成される。アプリケーションの実行の流れは、図４に示すように、アプリケーションに対応するアクティビティ（ＡＣＴ１〜ＡＣＴ５）を矢印でつなぐことで実現され、分岐部分（点線の矢印）には、例えば、以下のような条件式を記述することができる。
条件１：要素ｎ＞１０のとき、ＡＣＴ３に分岐する。
条件２：要素ｎ≦１０のとき、ＡＣＴ５に分岐する。
また、フロー定義２１１は、一意の識別子であるフロー名により識別され、複数のフロー定義２１１を作成することができる。なお、アクティビティの数や分岐は任意に定義できる。各アクティビティ（ＡＣＴｎ）に定義される情報は、次の通りである。
（ａ）アクティビティ名。
（ｂ）実行するアプリケーション名と、アプリケーションの入力／出力パラメタと、後述するメッセージのユーザデータ部の要素の関係。パラメタとユーザデータ部の要素の関係は、図５に示すような形式で指定される。
（ｃ）アプリケーションに対応するキュー名。
（ｄ）次に実行すべきアクティビティ名。このアクティビティ名は、フロー定義上では、図４の実線の矢印に対応する。
（ｅ）次に実行すべきアクティビティの振り分けを行う場合の条件式［（メッセージの要素ｎ）比較式（値）］と、各条件に対応するアクティビティ名。
（ａ）アクティビティ名。
（ｂ）実行するアプリケーション名と、アプリケーションの入力／出力パラメタと、後述するメッセージのユーザデータ部の要素の関係。パラメタとユーザデータ部の要素の関係は、図５に示すような形式で指定される。
（ｃ）アプリケーションに対応するキュー名。
（ｄ）次に実行すべきアクティビティ名。このアクティビティ名は、フロー定義上では、図４の実線の矢印に対応する。
（ｅ）次に実行すべきアクティビティの振り分けを行う場合の条件式［（メッセージの要素ｎ）比較式（値）］と、各条件に対応するアクティビティ名。
こうして作成されたフロー定義２１１は、フロー定義データベース２０２に保存される。フロー定義データベース２０２には、図６に示すように、フロー単位の情報（フロー名および応答キュー名）とアクティビティ毎に定義された（ａ）〜（ｅ）の情報からなるレコードが、フロー毎に格納される。
図３のメッセージ領域３２１には、メッセージテーブル、受信待ちテーブル、および管理テーブルが、各サーバのキュー毎に設けられる。これらのテーブルは、順序定義（ＣＲＥＡＴＥ ＳＥＱＵＥＮＣＥ）を用いて生成される。注：ＣＲＥＡＴＥ ＳＥＱＵＥＮＣＥは、データベースが提供する連番を発行する採番機能
図７は、メッセージテーブルのデータ構造を示している。図７のメッセージテーブルのレコードは以下の情報を含む。
（１）ＭｓｇＳｅｑＮｏ：メッセージを一意に識別する識別子である。メッセージテーブル用順序定義で生成された値が使用される。
（２）ｍｅｓｓａｇｅ・・・：メッセージ本文である。
図７は、メッセージテーブルのデータ構造を示している。図７のメッセージテーブルのレコードは以下の情報を含む。
（１）ＭｓｇＳｅｑＮｏ：メッセージを一意に識別する識別子である。メッセージテーブル用順序定義で生成された値が使用される。
（２）ｍｅｓｓａｇｅ・・・：メッセージ本文である。
メッセージテーブルの初期レコード数は０である。
図８は、受信待ちテーブルのデータ構造を示している。図８の受信待ちテーブルのレコードは以下の情報を含む。
（１）ＷａｉｔＳｅｑＮｏ：レコード番号（１，２，３，．．．）である。初期値は、受信待ちテーブル用順序定義で生成される値の範囲に設定される。
（２）ＳｅｎｄＭｓｇＳｅｑＮｏ：送信するメッセージのレコードのＭｓｇＳｅｑＮｏが格納される。初期値は０である。
（３）ｆｌａｇ：メッセージが受信済みか否かを示すフラグである。初期値はｏｆｆ（受信済み）である。
図８は、受信待ちテーブルのデータ構造を示している。図８の受信待ちテーブルのレコードは以下の情報を含む。
（１）ＷａｉｔＳｅｑＮｏ：レコード番号（１，２，３，．．．）である。初期値は、受信待ちテーブル用順序定義で生成される値の範囲に設定される。
（２）ＳｅｎｄＭｓｇＳｅｑＮｏ：送信するメッセージのレコードのＭｓｇＳｅｑＮｏが格納される。初期値は０である。
（３）ｆｌａｇ：メッセージが受信済みか否かを示すフラグである。初期値はｏｆｆ（受信済み）である。
受信待ちテーブルの初期レコードとしては、受信待ちに必要となる数のレコードがテーブル作成時に確保され、サイクリックに使用される。
また、管理テーブル（不図示）には、以下の情報が設定される。
（１）メッセージテーブル用順序定義（ＭＳＧＳＥＱ）：メッセージテーブルのＭｓｇＳｅｑＮｏの値を生成するために用いられる。メッセージの順序性保証は、この順序定義で行われる。
（２）受信待ちテーブル用順序定義（ＷＡＩＴＳＥＱ）：受信待ちテーブルのＷａｉｔＳｅｑＮｏの値を生成するために用いられる。ＷＡＩＴＳＥＱの値は、受信待ちテーブルのポインタとして使用され、受信待ちテーブルのレコード数を最大値として、サイクリックにカウントされる。
また、管理テーブル（不図示）には、以下の情報が設定される。
（１）メッセージテーブル用順序定義（ＭＳＧＳＥＱ）：メッセージテーブルのＭｓｇＳｅｑＮｏの値を生成するために用いられる。メッセージの順序性保証は、この順序定義で行われる。
（２）受信待ちテーブル用順序定義（ＷＡＩＴＳＥＱ）：受信待ちテーブルのＷａｉｔＳｅｑＮｏの値を生成するために用いられる。ＷＡＩＴＳＥＱの値は、受信待ちテーブルのポインタとして使用され、受信待ちテーブルのレコード数を最大値として、サイクリックにカウントされる。
アプリケーションの連携を行う際に必要となるデータは、メッセージを利用して伝搬される。メッセージ本文（ｍｅｓｓａｇｅ・・・）は、図９に示すように、以下の３つの部分から構成される。なお、１つのメッセージは、１つのフロー定義と対応する。
（１）フロー定義部９０１
フロー定義データベース２０２に格納された特定のフロー定義の情報を格納する領域である。図１０に示すように、フロー名、アクティビティ情報１〜ｎの定義値（ａ）〜（ｅ）が設定されている。
（２）状態管理部９０２
図１１に示すように、フローの現在位置および通過したアクティビティ名を格納するパラメタで構成される領域である。現在位置には、フローのカレント位置を示すアクティビティ名が設定され、通過アクティビティには、通過したすべてのアクティビティの名前が順番に格納される。
（３）ユーザデータ部９０３
図１２に示すように、任意の数の要素で構成されており、各要素に対応したユーザデータを格納する領域である。
（１）フロー定義部９０１
フロー定義データベース２０２に格納された特定のフロー定義の情報を格納する領域である。図１０に示すように、フロー名、アクティビティ情報１〜ｎの定義値（ａ）〜（ｅ）が設定されている。
（２）状態管理部９０２
図１１に示すように、フローの現在位置および通過したアクティビティ名を格納するパラメタで構成される領域である。現在位置には、フローのカレント位置を示すアクティビティ名が設定され、通過アクティビティには、通過したすべてのアクティビティの名前が順番に格納される。
（３）ユーザデータ部９０３
図１２に示すように、任意の数の要素で構成されており、各要素に対応したユーザデータを格納する領域である。
図１３は、アプリケーションフロー制御システムの処理を示すフローチャートである。まず、フロー定義作成ツール２０１がフロー定義２１１を作成し、フロー定義データベース２０２に格納する（ステップ１３０１）。次に、クライアント２０４がフロー開始ＡＰＩ２１４を実行し（ステップ１３０２）、ＡＰＩ２１４は、以下の処理を行う（ステップ１３０３）。
・実行するフロー名をキーとしてフロー定義データベース２０２を参照し、フロー定義２１１を読み出してメッセージ２１５のフロー定義部９０１に設定する。
・メッセージ２１５の状態管理部９０２の現在位置に、フローの先頭アクティビティであるアクティビティ１の名前を設定する。
・メッセージ２１５のユーザデータ部９０３の要素にデータを設定する。
・現在位置に設定されたアクティビティに対応するキュー２２３−１宛てに、メッセージ２１５を送信する。
・フローの処理結果をフロー定義部９０１で定義された応答キューで待ち合わせる。
・実行するフロー名をキーとしてフロー定義データベース２０２を参照し、フロー定義２１１を読み出してメッセージ２１５のフロー定義部９０１に設定する。
・メッセージ２１５の状態管理部９０２の現在位置に、フローの先頭アクティビティであるアクティビティ１の名前を設定する。
・メッセージ２１５のユーザデータ部９０３の要素にデータを設定する。
・現在位置に設定されたアクティビティに対応するキュー２２３−１宛てに、メッセージ２１５を送信する。
・フローの処理結果をフロー定義部９０１で定義された応答キューで待ち合わせる。
送信先のメッセージ処理部２２２−１は、メッセージ２１５をキュー２２３−１から受信し、以下の手順で、実行するアプリケーション２２１−１を特定して呼び出す（ステップ１３０４）。
・メッセージ２１５の状態管理部９０２の現在位置のアクティビティ名を参照し、実行するアクティビティ（ｎ）を特定する。
・メッセージ２１５のフロー定義部９０１に設定されているアクティビティ（ｎ）の情報（ａ）〜（ｅ）を参照する。
・（ｂ）の情報より、呼び出すアプリケーション名を特定し、同じく（ｂ）の情報より、入力パラメタに対応するメッセージ２１５のユーザデータ部９０３の要素を設定し、アプリケーション２２１−１を実行する。
・メッセージ２１５の状態管理部９０２の現在位置のアクティビティ名を参照し、実行するアクティビティ（ｎ）を特定する。
・メッセージ２１５のフロー定義部９０１に設定されているアクティビティ（ｎ）の情報（ａ）〜（ｅ）を参照する。
・（ｂ）の情報より、呼び出すアプリケーション名を特定し、同じく（ｂ）の情報より、入力パラメタに対応するメッセージ２１５のユーザデータ部９０３の要素を設定し、アプリケーション２２１−１を実行する。
アプリケーション２２１−１は、１番目の業務処理を実行し、終了するとメッセージ処理部２２２−１に出力パラメタを出力する（ステップ１３０５）。
これを受けて、メッセージ処理部２２２−１は、（ｂ）の情報より、アプリケーション２２１−１の出力パラメタに対応するユーザデータ部９０３の要素を特定し、メッセージ２１５の当該要素に出力パラメタを設定する（ステップ１３０６）。
これを受けて、メッセージ処理部２２２−１は、（ｂ）の情報より、アプリケーション２２１−１の出力パラメタに対応するユーザデータ部９０３の要素を特定し、メッセージ２１５の当該要素に出力パラメタを設定する（ステップ１３０６）。
次に、メッセージ処理部２２２−１は、メッセージ２１５の状態管理部９０２の現在位置に設定されているアクティビティ名を、状態管理部９０２の通過アクティビティに追加する（ステップ１３０７）。
次に、メッセージ処理部２２２−１は、次に実行するアクティビティを以下の２つの場合において決定し、いずれかの方法で特定したアクティビティ名をメッセージ２１５の状態管理部９０２の現在位置に設定する（ステップ１３０８）。
・メッセージ２１５のフロー定義部９０１に、実行されたアプリケーション２２１−１に対応するアクティビティの分岐条件（ｅ）が定義されていない場合、フロー定義部９０１の（ｄ）を次に実行するアクティビティとする。
・メッセージ２１５のフロー定義部９０１に、実行されたアプリケーション２２１−１に対応するアクティビティの分岐条件（ｅ）が定義されている場合、（ｅ）の条件式にアプリケーション２２１−１の出力パラメタを代入し、その結果に応じて指定されているアクティビティを次に実行するアクティビティとする。
・メッセージ２１５のフロー定義部９０１に、実行されたアプリケーション２２１−１に対応するアクティビティの分岐条件（ｅ）が定義されていない場合、フロー定義部９０１の（ｄ）を次に実行するアクティビティとする。
・メッセージ２１５のフロー定義部９０１に、実行されたアプリケーション２２１−１に対応するアクティビティの分岐条件（ｅ）が定義されている場合、（ｅ）の条件式にアプリケーション２２１−１の出力パラメタを代入し、その結果に応じて指定されているアクティビティを次に実行するアクティビティとする。
次に、メッセージ処理部２２２−１は、状態管理部９０２の現在位置に設定したアクティビティに対応するアクティビティ情報を、アクティビティ名をキーとしてフロー定義部９０１から検索し、該当するアクティビティの（ｃ）に格納されたキュー名を特定する（ステップ１３０９）。そして、更新されたメッセージ２１５を特定したキュー２２３−２に送信する。
メッセージを受信したメッセージ処理部２２２−２は、フロー定義部９０１の情報に従って同様の処理を実行し、メッセージ処理部２２２−３のキュー２２３−３にメッセージを送信する。メッセージ処理部２２２−３も同様の処理を実行し、フローが終了すると、フロー定義部９０１に指定された応答キューにメッセージを送信することで、処理結果を通知する（ステップ１３１０）。
図１４は、送信側メッセージ処理部１４０１と受信側メッセージ処理１４０２が行う通常時のメッセージ処理を示している。送信側メッセージ処理部１４０１の処理シーケンスは、以下の通りである。
（１）管理テーブルのメッセージテーブル用順序定義から送信メッセージレコードのＭｓｇＳｅｑＮｏ（例：６２３３０）を取得し、メッセージ本文（例：ＡＢＣＤ）をメッセージテーブル１４０３のレコードに挿入する。
（２）管理テーブルの受信待ちテーブル用順序定義から受信待ちテーブルレコードのＷａｉｔＳｅｑＮｏ（例：３）を取得し、対象レコードのＳｅｎｄＭｓｇＳｅｑＮｏに送信メッセージのＭｓｇＳｅｑＮｏを設定し、ｆｌａｇにｏｎを設定して、レコードを更新する。ｆｌａｇがｏｎの場合は、当該レコードがまだ使用中であるため、受信待ちテーブル用順序定義から受信待ちテーブルレコードのＷａｉｔＳｅｑＮｏを再取得する。
（３）更新された受信待ちテーブル１４０４のレコードのＷａｉｔＳｅｑＮｏを、送信トリガとして受信側のキュー１４０５に送信する。このとき、メッセージ本文はキュー１４０５には送信されない。
（４）送信メッセージに対するＪＭＳコミットを発行する。
（５）データベースコミットを発行する。
（１）管理テーブルのメッセージテーブル用順序定義から送信メッセージレコードのＭｓｇＳｅｑＮｏ（例：６２３３０）を取得し、メッセージ本文（例：ＡＢＣＤ）をメッセージテーブル１４０３のレコードに挿入する。
（２）管理テーブルの受信待ちテーブル用順序定義から受信待ちテーブルレコードのＷａｉｔＳｅｑＮｏ（例：３）を取得し、対象レコードのＳｅｎｄＭｓｇＳｅｑＮｏに送信メッセージのＭｓｇＳｅｑＮｏを設定し、ｆｌａｇにｏｎを設定して、レコードを更新する。ｆｌａｇがｏｎの場合は、当該レコードがまだ使用中であるため、受信待ちテーブル用順序定義から受信待ちテーブルレコードのＷａｉｔＳｅｑＮｏを再取得する。
（３）更新された受信待ちテーブル１４０４のレコードのＷａｉｔＳｅｑＮｏを、送信トリガとして受信側のキュー１４０５に送信する。このとき、メッセージ本文はキュー１４０５には送信されない。
（４）送信メッセージに対するＪＭＳコミットを発行する。
（５）データベースコミットを発行する。
ＪＭＳコミットにより、受信側メッセージ処理部１４０２は、送信トリガを受けて処理を開始する。メッセージ処理部１４０２の処理シーケンスは、以下の通りである。
（１）キュー１４０５からメッセージ（ＷａｉｔＳｅｑＮｏ）を取り出す。
（２）受信待ちテーブル１４０４に対する更新処理を行い、取り出したメッセージに格納されたＷａｉｔＳｅｑＮｏのレコードのｆｌａｇをｏｆｆに設定する。これにより、受信済み設定が完了する。送信側のデータベースコミットが完了していない場合は、それが完了するまで待ち状態となる。
（３）待ち状態が解除された受信待ちテーブルレコードのＳｅｎｄＭｓｇＳｅｑＮｏを取得して、取得した番号と一致するＭｓｇＳｅｑＮｏのレコードをメッセージテーブル１４０３から取得する。そして、受信待ちテーブルレコードのＳｅｎｄＭｓｇＳｅｑＮｏを０に更新する。
（４）取得したメッセージテーブル１４０３のレコードを削除する。
（５）データベースコミットを発行する。
（６）受信メッセージに対するＪＭＳコミットを発行する。
（１）キュー１４０５からメッセージ（ＷａｉｔＳｅｑＮｏ）を取り出す。
（２）受信待ちテーブル１４０４に対する更新処理を行い、取り出したメッセージに格納されたＷａｉｔＳｅｑＮｏのレコードのｆｌａｇをｏｆｆに設定する。これにより、受信済み設定が完了する。送信側のデータベースコミットが完了していない場合は、それが完了するまで待ち状態となる。
（３）待ち状態が解除された受信待ちテーブルレコードのＳｅｎｄＭｓｇＳｅｑＮｏを取得して、取得した番号と一致するＭｓｇＳｅｑＮｏのレコードをメッセージテーブル１４０３から取得する。そして、受信待ちテーブルレコードのＳｅｎｄＭｓｇＳｅｑＮｏを０に更新する。
（４）取得したメッセージテーブル１４０３のレコードを削除する。
（５）データベースコミットを発行する。
（６）受信メッセージに対するＪＭＳコミットを発行する。
このようなメッセージ処理をメッセージテーブル１４０３のみで制御すると、送信側の（５）のデータベースコミットが完了する前に受信側の（３）の処理が開始され、メッセージテーブル１４０３がアクセスされる可能性がある。この場合、メッセージテーブル１４０３にレコードが挿入されていなければ、メッセージ受信に失敗する。そこで、本実施形態では、メッセージテーブル１４０３に加えて、受信待ちテーブル１４０４を使用して排他制御を行うことで、受信失敗を防止している。
図１５は、送信側でＪＭＳコミット完了後に異常が発生した場合のメッセージ処理を示している。この場合、送信側メッセージ処理部１４０１の処理（１）〜（４）については、図１４の場合と同様である。
その後、サーバの異常等の原因により、（５）のデータベースコミットが失敗する。この時点で、送信トリガは受信側に正常に通知されているが、データベースはロールバックされてしまい、矛盾した状態になる。データベースがロールバックされることで、（１）および（２）で行ったデータベース操作は取り消され、メッセージテーブル１４０３のレコードが存在せず、受信待ちテーブル１４０４の更新が取り消された状態（ＳｅｎｄＭｓｇＳｅｑＮｏ＝０）になっている。
送信側のＪＭＳコミットにより、受信側メッセージ処理部１４０２は、送信トリガを受けて処理を開始する。この場合、メッセージ処理部１４０２の処理（１）および（２）については、図１４の場合と同様である。
その後、メッセージ処理部１４０２は、受信待ちテーブルレコードのＳｅｎｄＭｓｇＳｅｑＮｏを取得するが、送信側の（２）の操作は取り消されているので、取得したＳｅｎｄＭｓｇＳｅｑＮｏは０となる。そこで、送信トリガの送信後に送信側で異常が発生したものと判断し、ＪＭＳコミットを発行して、受信した送信トリガの無効化を行う。そして、受信側の（２）の更新処理をロールバックする。
これに対して、受信側でデータベースコミット完了後、ＪＭＳコミット前に異常が発生した場合は、送信側メッセージ処理部１４０１の処理（１）〜（５）と受信側メッセージ処理部１４０２の処理（１）〜（５）については、図１４の場合と同様である。
その後、サーバの異常等の原因により、受信側の（６）のＪＭＳコミットが失敗し、送信トリガがロールバックされる。このため、既にデータベースの更新処理は完了しているのに送信トリガが存在する、という矛盾した状態が発生する。このとき、メッセージ処理部１４０２は、以下のシーケンスで送信トリガを無効化する。
（７）キュー１４０５から（１）と同じメッセージを取り出し、送信トリガを受信する。
（８）（２）と同様にして、取り出したメッセージに格納されたＷａｉｔＳｅｑＮｏの受信待ちテーブルレコードの更新処理を行う。
（９）受信待ちテーブルレコードのＳｅｎｄＭｓｇＳｅｑＮｏを取得するが、ＳｅｎｄＭｓｇＳｅｑＮｏは既に０に更新されているため、取得したＳｅｎｄＭｓｇＳｅｑＮｏは０となる。そこで、この送信トリガは処理済みと判断し、ＪＭＳコミットを発行して、受信した送信トリガの無効化を行う。
（７）キュー１４０５から（１）と同じメッセージを取り出し、送信トリガを受信する。
（８）（２）と同様にして、取り出したメッセージに格納されたＷａｉｔＳｅｑＮｏの受信待ちテーブルレコードの更新処理を行う。
（９）受信待ちテーブルレコードのＳｅｎｄＭｓｇＳｅｑＮｏを取得するが、ＳｅｎｄＭｓｇＳｅｑＮｏは既に０に更新されているため、取得したＳｅｎｄＭｓｇＳｅｑＮｏは０となる。そこで、この送信トリガは処理済みと判断し、ＪＭＳコミットを発行して、受信した送信トリガの無効化を行う。
ところで、図２のクライアント２０４およびサーバ２０５−１〜２０５−３は、例えば、図１６に示すような情報処理装置（コンピュータ）を用いて構成される。図１６の情報処理装置は、ＣＰＵ１６０１、メモリ１６０２、入力装置１６０３、出力装置１６０４、外部記憶装置１６０５、媒体駆動装置１６０６、およびネットワーク接続装置１６０７を備え、それらはバス１６０８により互いに接続されている。
メモリ１６０２は、例えば、ＲＯＭ（read only memory）、ＲＡＭ（random access memory）等を含み、処理に用いられるプログラムおよびデータを格納する。ＣＰＵ１６０１は、メモリ１６０２を利用してプログラムを実行することにより、必要な処理を行う。
図２のフロー定義作成ツール２０１、フロー開始ＡＰＩ２１４、アプリケーション２２１−ｉ、メッセージ処理部２２２−ｉ、および図３のＪＭＳ３１１、コンテナ３１２、およびフレームワーク３１３は、メモリ１６０２に格納されたプログラムに対応する。また、図２のキュー２２３−ｉは、メモリ１６０２に格納されたデータに対応する。
入力装置１６０３は、例えば、オペレータからの指示や情報の入力に用いられる。出力装置１６０４は、例えば、ディスプレイ、プリンタ、スピーカ等であり、オペレータへの問い合わせや処理結果等の出力に用いられる。
外部記憶装置１６０５は、例えば、磁気ディスク装置、光ディスク装置、光磁気ディスク装置、テープ装置等である。情報処理装置は、この外部記憶装置１６０５に、プログラムおよびデータを格納しておき、必要に応じて、それらをメモリ１６０２にロードして使用する。外部記憶装置１６０５は、フロー定義データベース２０２および業務用データベース２０３として使用することもできる。
媒体駆動装置１６０６は、可搬記録媒体１６０９を駆動し、その記録内容にアクセスする。可搬記録媒体１６０９は、メモリカード、フレキシブルディスク、光ディスク、光磁気ディスク等の任意のコンピュータ読み取り可能な記録媒体である。オペレータは、この可搬記録媒体１６０９にプログラムおよびデータを格納しておき、必要に応じて、それらをメモリ１６０２にロードして使用する。
ネットワーク接続装置１６０７は、ＬＡＮ（Local Area Network）等の任意の通信ネットワークに接続され、通信に伴うデータ変換を行う。情報処理装置は、必要に応じて、プログラムおよびデータを外部の装置からネットワーク接続装置１６０７を介して受け取り、それらをメモリ１６０２にロードして使用する。
図１７は、図１６の情報処理装置にプログラムおよびデータを提供する方法を示している。可搬記録媒体１６０９やサーバ１７０１のデータベース１７１１に格納されたプログラムおよびデータは、情報処理装置１７０２のメモリ１６０２にロードされる。サーバ１７０１は、そのプログラムおよびデータを搬送する搬送信号を生成し、ネットワーク上の任意の伝送媒体を介して情報処理装置１７０２に送信する。ＣＰＵ１６０１は、そのデータを用いてそのプログラムを実行し、必要な処理を行う。
（付記１） 連携処理を行う複数のアプリケーションの一部を有するアプリケーションフロー制御装置であって、
前記複数のアプリケーションの実行順序を指定するフロー定義情報を含む第１のメッセージが送信されたことを示す送信トリガを受信するキュー手段と、
前記送信トリガに基づいて前記第１のメッセージを受信し、該第１のメッセージに含まれる前記フロー定義情報に従って、実行すべきアプリケーションを呼び出し、該フロー定義情報と呼び出されたアプリケーションの実行結果を含む第２のメッセージを、次のアプリケーションを実行する送信先に送信するメッセージ処理手段と
を備えることを特徴とするアプリケーションフロー制御装置。
前記複数のアプリケーションの実行順序を指定するフロー定義情報を含む第１のメッセージが送信されたことを示す送信トリガを受信するキュー手段と、
前記送信トリガに基づいて前記第１のメッセージを受信し、該第１のメッセージに含まれる前記フロー定義情報に従って、実行すべきアプリケーションを呼び出し、該フロー定義情報と呼び出されたアプリケーションの実行結果を含む第２のメッセージを、次のアプリケーションを実行する送信先に送信するメッセージ処理手段と
を備えることを特徴とするアプリケーションフロー制御装置。
（付記２） 連携処理を行う複数のアプリケーションの一部を有するコンピュータのためのプログラムであって、
前記複数のアプリケーションの実行順序を指定するフロー定義情報を含む第１のメッセージが送信されたことを示す送信トリガをキュー手段が受信したとき、該送信トリガに基づいて前記第１のメッセージを受信し、
前記第１のメッセージに含まれる前記フロー定義情報に従って、実行すべきアプリケーションを呼び出し、
前記フロー定義情報と呼び出されたアプリケーションの実行結果を含む第２のメッセージを、次のアプリケーションを実行する送信先に送信する
処理をコンピュータに実行させることを特徴とするプログラム。
前記複数のアプリケーションの実行順序を指定するフロー定義情報を含む第１のメッセージが送信されたことを示す送信トリガをキュー手段が受信したとき、該送信トリガに基づいて前記第１のメッセージを受信し、
前記第１のメッセージに含まれる前記フロー定義情報に従って、実行すべきアプリケーションを呼び出し、
前記フロー定義情報と呼び出されたアプリケーションの実行結果を含む第２のメッセージを、次のアプリケーションを実行する送信先に送信する
処理をコンピュータに実行させることを特徴とするプログラム。
（付記３） 前記第１のメッセージは、フローの現在位置を示す状態管理情報を含み、前記プログラムは、前記フロー定義情報と該状態管理情報に従って前記実行すべきアプリケーションを特定する処理を、前記コンピュータに実行させることを特徴とする付記２記載のプログラム。
（付記４） 前記状態管理情報は、実行済みのアプリケーションを示す情報を含み、前記プログラムは、前記呼び出されたアプリケーションを該実行済みのアプリケーションに追加して、前記第２のメッセージの状態管理情報を生成する処理を、前記コンピュータに実行させることを特徴とする付記３記載のプログラム。
（付記５） 前記フロー定義情報は、フローの分岐条件を示す情報を含み、前記プログラムは、該分岐条件と前記呼び出されたアプリケーションの実行結果とに応じて、前記実行すべきアプリケーションを特定する処理を、前記コンピュータに実行させることを特徴とする付記２記載のプログラム。
（付記６） 前記第１のメッセージは、前記呼び出されたアプリケーションにより更新されるデータと同じデータベースに格納され、前記プログラムは、該呼び出されたアプリケーションがデータの更新に用いるトランザクションと同じトランザクションを用いて、該第１のメッセージを前記第２のメッセージに更新し、該第２のメッセージが送信されたことを示す送信トリガを前記送信先に送信する処理を、前記コンピュータに実行させることを特徴とする付記２乃至５記載のプログラム。
（付記７） 連携処理を行う複数のアプリケーションの一部を有する装置におけるアプリケーションフロー制御方法であって、
前記複数のアプリケーションの実行順序を指定するフロー定義情報を含む第１のメッセージが送信されたことを示す送信トリガをキュー手段が受信したとき、メッセージ処理手段が、該送信トリガに基づいて前記第１のメッセージを受信し、
前記メッセージ処理手段が、前記第１のメッセージに含まれる前記フロー定義情報に従って、実行すべきアプリケーションを呼び出し、
前記メッセージ処理手段が、前記フロー定義情報と呼び出されたアプリケーションの実行結果を含む第２のメッセージを、次のアプリケーションを実行する送信先に送信する
ことを特徴とするアプリケーションフロー制御方法。
前記複数のアプリケーションの実行順序を指定するフロー定義情報を含む第１のメッセージが送信されたことを示す送信トリガをキュー手段が受信したとき、メッセージ処理手段が、該送信トリガに基づいて前記第１のメッセージを受信し、
前記メッセージ処理手段が、前記第１のメッセージに含まれる前記フロー定義情報に従って、実行すべきアプリケーションを呼び出し、
前記メッセージ処理手段が、前記フロー定義情報と呼び出されたアプリケーションの実行結果を含む第２のメッセージを、次のアプリケーションを実行する送信先に送信する
ことを特徴とするアプリケーションフロー制御方法。
１０１、２０４ クライアント
１０２、２０３ 業務用データベース
１１１、１１２、１１３、２０５−１、２０５−２、２０５−３ サーバ
１２１、１２２、１２３、１７３、２２１−１、２２１−２、２２１−３、２２１−ｉ アプリケーション
１３１ 管理サーバ
１３２、１４１、１４２、１４３ フロー制御部
１３３ フロー
１３４ 状態管理データベース
１５１、１５２、１５３、２２３−１、２２３−２、２２３−３、１４０５ キュー
１６１ トランザクションマネージャ
１７１ キュー手段
１７２ メッセージ処理手段
２０１ フロー定義作成ツール
２０２ フロー定義データベース
２１１ フロー定義
２１２ 業務データ
２１２ メッセージデータ
２１４ フロー開始ＡＰＩ
２１５ メッセージ
２２２−１、２２２−２、２２２−３、２２２−ｉ メッセージ処理部
３０１、３０２ イベントチャネル
３１１ ＪＭＳ
３１２ コンテナ３１２
３１３ フレームワーク
３２１ メッセージ領域
３２２ 業務用テーブル
３３１、３３２、３３３、３３４、３３５ レコード
３４１、３４２ 業務データ
９０１ フロー定義部
９０２ 状態管理部
９０３ ユーザデータ部
１４０１ 送信側メッセージ処理部
１４０２ 受信側メッセージ処理部
１４０３ メッセージテーブル
１４０４ 受信待ちテーブル
１６０１ ＣＰＵ
１６０２ メモリ
１６０３ 入力装置
１６０４ 出力装置
１６０５ 外部記憶装置
１６０６ 媒体駆動装置
１６０７ ネットワーク接続装置
１６０８ バス
１６０９ 可搬記録媒体
１７０１ サーバ
１７０２ 情報処理装置
１７１１ データベース
１０２、２０３ 業務用データベース
１１１、１１２、１１３、２０５−１、２０５−２、２０５−３ サーバ
１２１、１２２、１２３、１７３、２２１−１、２２１−２、２２１−３、２２１−ｉ アプリケーション
１３１ 管理サーバ
１３２、１４１、１４２、１４３ フロー制御部
１３３ フロー
１３４ 状態管理データベース
１５１、１５２、１５３、２２３−１、２２３−２、２２３−３、１４０５ キュー
１６１ トランザクションマネージャ
１７１ キュー手段
１７２ メッセージ処理手段
２０１ フロー定義作成ツール
２０２ フロー定義データベース
２１１ フロー定義
２１２ 業務データ
２１２ メッセージデータ
２１４ フロー開始ＡＰＩ
２１５ メッセージ
２２２−１、２２２−２、２２２−３、２２２−ｉ メッセージ処理部
３０１、３０２ イベントチャネル
３１１ ＪＭＳ
３１２ コンテナ３１２
３１３ フレームワーク
３２１ メッセージ領域
３２２ 業務用テーブル
３３１、３３２、３３３、３３４、３３５ レコード
３４１、３４２ 業務データ
９０１ フロー定義部
９０２ 状態管理部
９０３ ユーザデータ部
１４０１ 送信側メッセージ処理部
１４０２ 受信側メッセージ処理部
１４０３ メッセージテーブル
１４０４ 受信待ちテーブル
１６０１ ＣＰＵ
１６０２ メモリ
１６０３ 入力装置
１６０４ 出力装置
１６０５ 外部記憶装置
１６０６ 媒体駆動装置
１６０７ ネットワーク接続装置
１６０８ バス
１６０９ 可搬記録媒体
１７０１ サーバ
１７０２ 情報処理装置
１７１１ データベース
Claims (2)
- 連携処理を行う複数のアプリケーションの一部を有するアプリケーションフロー制御装置であって、
前記複数のアプリケーションの実行順序を指定するフロー定義情報を含む第１のメッセージが送信されたことを示す送信トリガを受信するキュー手段と、
前記送信トリガに基づいて、前記連携処理の対象データと同じデータベースに格納された前記第１のメッセージを受信し、該第１のメッセージに含まれる前記フロー定義情報に従って、実行すべきアプリケーションを呼び出し、呼び出されたアプリケーションが該データベースに格納されたデータの更新に用いるトランザクションと同じトランザクションを用いて、該データベースに格納された該第１のメッセージを、該フロー定義情報と呼び出されたアプリケーションの実行結果を含む第２のメッセージに更新し、該第２のメッセージを次のアプリケーションを実行する送信先に送信し、該第２のメッセージが送信されたことを示す送信トリガを該送信先に送信するメッセージ処理手段と
を備えることを特徴とするアプリケーションフロー制御装置。 - 連携処理を行う複数のアプリケーションの一部を有するコンピュータのためのプログラムであって、
前記複数のアプリケーションの実行順序を指定するフロー定義情報を含む第１のメッセージが送信されたことを示す送信トリガをキュー手段が受信したとき、該送信トリガに基づいて、前記連携処理の対象データと同じデータベースに格納された前記第１のメッセージを受信し、
前記第１のメッセージに含まれる前記フロー定義情報に従って、実行すべきアプリケーションを呼び出し、
呼び出されたアプリケーションが該データベースに格納されたデータの更新に用いるトランザクションと同じトランザクションを用いて、該データベースに格納された該第１のメッセージを、該フロー定義情報と呼び出されたアプリケーションの実行結果を含む第２のメッセージに更新し、
前記第２のメッセージを次のアプリケーションを実行する送信先に送信し、
前記第２のメッセージが送信されたことを示す送信トリガを該送信先に送信する
処理をコンピュータに実行させることを特徴とするプログラム。
Priority Applications (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2004319620A JP4102354B2 (ja) | 2004-11-02 | 2004-11-02 | アプリケーションフロー制御装置 |
| US11/086,503 US8418191B2 (en) | 2004-11-02 | 2005-03-22 | Application flow control apparatus |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2004319620A JP4102354B2 (ja) | 2004-11-02 | 2004-11-02 | アプリケーションフロー制御装置 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2006133894A JP2006133894A (ja) | 2006-05-25 |
| JP4102354B2 true JP4102354B2 (ja) | 2008-06-18 |
Family
ID=36261712
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2004319620A Active JP4102354B2 (ja) | 2004-11-02 | 2004-11-02 | アプリケーションフロー制御装置 |
Country Status (2)
| Country | Link |
|---|---|
| US (1) | US8418191B2 (ja) |
| JP (1) | JP4102354B2 (ja) |
Families Citing this family (17)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2008149427A1 (ja) * | 2007-06-05 | 2008-12-11 | Fujitsu Limited | メッセージ処理プログラム、メッセージ処理方法および情報処理装置 |
| JP5084355B2 (ja) * | 2007-06-07 | 2012-11-28 | キヤノン株式会社 | フロー処理実行装置、フロー処理実行方法及びプログラム |
| US10419541B2 (en) | 2008-11-26 | 2019-09-17 | Free Stream Media Corp. | Remotely control devices over a network without authentication or registration |
| US9961388B2 (en) | 2008-11-26 | 2018-05-01 | David Harrison | Exposure of public internet protocol addresses in an advertising exchange server to improve relevancy of advertisements |
| US9519772B2 (en) | 2008-11-26 | 2016-12-13 | Free Stream Media Corp. | Relevancy improvement through targeting of information based on data gathered from a networked device associated with a security sandbox of a client device |
| US10977693B2 (en) | 2008-11-26 | 2021-04-13 | Free Stream Media Corp. | Association of content identifier of audio-visual data with additional data through capture infrastructure |
| US9386356B2 (en) | 2008-11-26 | 2016-07-05 | Free Stream Media Corp. | Targeting with television audience data across multiple screens |
| US8180891B1 (en) | 2008-11-26 | 2012-05-15 | Free Stream Media Corp. | Discovery, access control, and communication with networked services from within a security sandbox |
| US10334324B2 (en) | 2008-11-26 | 2019-06-25 | Free Stream Media Corp. | Relevant advertisement generation based on a user operating a client device communicatively coupled with a networked media device |
| US9986279B2 (en) | 2008-11-26 | 2018-05-29 | Free Stream Media Corp. | Discovery, access control, and communication with networked services |
| US9154942B2 (en) | 2008-11-26 | 2015-10-06 | Free Stream Media Corp. | Zero configuration communication between a browser and a networked media device |
| US9026668B2 (en) | 2012-05-26 | 2015-05-05 | Free Stream Media Corp. | Real-time and retargeted advertising on multiple screens of a user watching television |
| US10567823B2 (en) | 2008-11-26 | 2020-02-18 | Free Stream Media Corp. | Relevant advertisement generation based on a user operating a client device communicatively coupled with a networked media device |
| US10631068B2 (en) | 2008-11-26 | 2020-04-21 | Free Stream Media Corp. | Content exposure attribution based on renderings of related content across multiple devices |
| US10880340B2 (en) | 2008-11-26 | 2020-12-29 | Free Stream Media Corp. | Relevancy improvement through targeting of information based on data gathered from a networked device associated with a security sandbox of a client device |
| JP6102264B2 (ja) * | 2013-01-08 | 2017-03-29 | 株式会社リコー | 処理実行システム、情報処理装置、プログラム |
| JP6953703B2 (ja) * | 2016-10-19 | 2021-10-27 | 株式会社リコー | システム、情報処理方法、情報処理装置、プログラム |
Family Cites Families (10)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JPH06282515A (ja) | 1993-03-25 | 1994-10-07 | Hitachi Ltd | データ処理装置 |
| US5504896A (en) * | 1993-12-29 | 1996-04-02 | At&T Corp. | Method and apparatus for controlling program sources in an interactive television system using hierarchies of finite state machines |
| JPH08314872A (ja) | 1995-05-12 | 1996-11-29 | Hitachi Tohoku Software Kk | アプリケーションプログラム間連携処理方法 |
| US6195543B1 (en) * | 1997-06-20 | 2001-02-27 | Telefonaktiebolaget Lm Ericsson (Publ) | Method and apparatus for providing advice of charge parameters for mobile radio telephone calls |
| JP3006610B1 (ja) | 1999-01-11 | 2000-02-07 | ランセプト株式会社 | ワ―クフロ―支援実行システム |
| JP2000222305A (ja) | 1999-02-03 | 2000-08-11 | Nippon Telegr & Teleph Corp <Ntt> | インターワークフロー管理方法とそのシステム及びインターワークフロー管理プログラムを記録した記録媒体 |
| US6377939B1 (en) * | 1999-05-04 | 2002-04-23 | Metratech | Pipelined method and apparatus for processing communication metering data |
| US6904014B1 (en) * | 2000-04-27 | 2005-06-07 | Cisco Technology, Inc. | Method and apparatus for performing high-speed traffic shaping |
| US6971096B1 (en) * | 2000-05-19 | 2005-11-29 | Sun Microsystems, Inc. | Transaction data structure for process communications among network-distributed applications |
| US6976120B2 (en) * | 2002-01-28 | 2005-12-13 | Intel Corporation | Apparatus and method to track flag transitions for DRAM data transfer |
-
2004
- 2004-11-02 JP JP2004319620A patent/JP4102354B2/ja active Active
-
2005
- 2005-03-22 US US11/086,503 patent/US8418191B2/en active Active
Also Published As
| Publication number | Publication date |
|---|---|
| US20060092834A1 (en) | 2006-05-04 |
| US8418191B2 (en) | 2013-04-09 |
| JP2006133894A (ja) | 2006-05-25 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP4102354B2 (ja) | アプリケーションフロー制御装置 | |
| US10942823B2 (en) | Transaction processing system, recovery subsystem and method for operating a recovery subsystem | |
| US6014673A (en) | Simultaneous use of database and durable store in work flow and process flow systems | |
| US6980988B1 (en) | Method of applying changes to a standby database system | |
| US7668878B2 (en) | Replicating data between heterogeneous data systems | |
| EP2335153B1 (en) | Queue manager and method of managing queues in an asynchronous messaging system | |
| US20120221605A1 (en) | Linking framework for information technology management | |
| JP2016541056A (ja) | ビジネスフローをスケジュールするためのコンピュータ装置、方法及び装置 | |
| US6895408B1 (en) | Method and apparatus to facilitate interaction management between loosely coupled applications | |
| US7089564B2 (en) | High-performance memory queue | |
| US20080155140A1 (en) | System and program for buffering work requests | |
| CN101438275B (zh) | 工作项事件处理 | |
| US20090320044A1 (en) | Peek and Lock Using Queue Partitioning | |
| US20210256593A1 (en) | Coordination process restart device and coordination process restart method | |
| US9069632B2 (en) | Message processing | |
| JP2002007182A (ja) | 外部記憶装置の共有ファイル管理方式 | |
| US20100088287A1 (en) | Information system, method and recording medium having program recorded thereon relating to collectively registered data | |
| JP2006338197A (ja) | トランザクション制御プログラム、トランザクション制御方法及びトランザクション処理システム | |
| US20090006763A1 (en) | Arrangement And Method For Update Of Configuration Cache Data | |
| JP5086820B2 (ja) | サービス管理方法とシステムおよびプログラム | |
| US20020040380A1 (en) | Program executing management system, a computer program product and a process executing management method | |
| JP4262932B2 (ja) | トランザクション処理装置、同装置のトランザクション処理方法、トランザクション処理プログラムおよび同プログラムを記録したコンピュータ読み取り可能な記録媒体 | |
| JP2001265614A (ja) | 動的連携情報引継ぎ方法，連携処理システムおよびそのプログラム記録媒体 | |
| Swanson et al. | MVS/ESA coupled-systems considerations | |
| JP2002099510A (ja) | 複数トランザクション処理システム |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20060222 |
|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20070903 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20070911 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20071109 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20080318 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20080321 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110328 Year of fee payment: 3 |
|
| R150 | Certificate of patent or registration of utility model |
Ref document number: 4102354 Country of ref document: JP Free format text: JAPANESE INTERMEDIATE CODE: R150 Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110328 Year of fee payment: 3 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120328 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130328 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20140328 Year of fee payment: 6 |