Nothing Special   »   [go: up one dir, main page]

JP2006133894A - アプリケーションフロー制御装置 - Google Patents

アプリケーションフロー制御装置 Download PDF

Info

Publication number
JP2006133894A
JP2006133894A JP2004319620A JP2004319620A JP2006133894A JP 2006133894 A JP2006133894 A JP 2006133894A JP 2004319620 A JP2004319620 A JP 2004319620A JP 2004319620 A JP2004319620 A JP 2004319620A JP 2006133894 A JP2006133894 A JP 2006133894A
Authority
JP
Japan
Prior art keywords
message
application
flow
flow definition
processing
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.)
Granted
Application number
JP2004319620A
Other languages
English (en)
Other versions
JP4102354B2 (ja
Inventor
Yoshitaka Honishi
義孝 保西
Toshitaka Nagai
敏隆 永井
Toshiya Hanamori
利弥 花森
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Fujitsu Ltd
Original Assignee
Fujitsu Ltd
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Fujitsu Ltd filed Critical Fujitsu Ltd
Priority to JP2004319620A priority Critical patent/JP4102354B2/ja
Priority to US11/086,503 priority patent/US8418191B2/en
Publication of JP2006133894A publication Critical patent/JP2006133894A/ja
Application granted granted Critical
Publication of JP4102354B2 publication Critical patent/JP4102354B2/ja
Anticipated expiration legal-status Critical
Expired - Lifetime legal-status Critical Current

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00Traffic control in data switching networks
    • H04L47/10Flow 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)

Abstract

【課題】 特定の管理サーバを経由することなく、フローに基づいたアプリケーションの連携処理を実現する。
【解決手段】 連携処理を行うアプリケーションを有するサーバ205−i(i=1,2,3)間で、フロー制御のためのメッセージが転送される。送信トリガがキュー223−iに送信されると、メッセージ処理部222−iは、業務用データベース212からメッセージデータ213を取得し、その中に含まれるフロー定義211に基づいてアプリケーション221−iを呼び出す。そして、フロー定義211とアプリケーション221−iの実行結果を含むメッセージを、次の送信先に送信する。
【選択図】図2

Description

本発明は、業務処理を行う複数のアプリケーションの実行順序を制御するアプリケーションフロー制御装置に関する。
アプリケーションは、業務処理を行うソフトウェアモジュールである。情報システムの高度な統合のため、複数のアプリケーションを連携させてサービスを提供する企業の基幹システム等の分野においては、アプリケーションを連携させる仕組みが重要となる。
例えば、図18に示すように、Webブラウザ等のクライアント101からの要求に応じて、サーバ111〜113上のアプリケーション121〜123を連携させる場合を考える。クライアント101およびサーバ111〜113は、通信ネットワークを介して接続されている。
アプリケーション121〜123は、それぞれ業務処理1〜3のためのアプリケーションであり、アプリケーション123は、業務用データベース102を更新する。クライアント101からの要求としては、例えば、以下の2つが挙げられる。

要求A:業務処理1→業務処理3
要求B:業務処理1→業務処理2→業務処理3

要求Aに対しては、最初にアプリケーション121、次にアプリケーション123が呼び出され、要求Bに対しては、アプリケーション121、アプリケーション122、アプリケーション123の順に呼び出される。この場合、アプリケーション121の次に呼び出される連携先のアプリケーションが不定であり、将来的に変わることも予想される。
アプリケーション自体に連携先となるアプリケーションの情報をコーディングすると、アプリケーションの追加、削除等の変更があった場合に、その都度アプリケーションの呼び出し順序(関係)の修正が必要になる。
これに対して、アプリケーションの連携フローを作成し、それに基づいてアプリケーションを順次呼び出す仕組みがあると、前述のようなアプリケーション自体の修正が不要となるため、アプリケーションの可搬性が向上し、様々な業務に流用することが可能となる。このため、企業の基幹システムの分野においては、アプリケーションの統合方法としてフローの技術が利用されている。
また、基幹システムの特性上、アプリケーション間で転送されるメッセージ(データ)自体の保証、およびデータベース処理の一意性の保証(二重更新不可)といった信頼性が、併せて要求される。
図19は、集中型のフロー制御システムを示している。このシステムでは、特定の管理サーバ131内にフロー制御部132が設けられる。フロー制御部132は、フロー133に記述されたアプリケーションの実行順序に従って、各アプリケーション121〜123を呼び出し、結果を状態管理データベース134に格納する。これにより、フロー133に従って業務処理が実行される。
特許文献1は、集中型のワークフロー支援実行システムに関し、特許文献2は、回覧物を回覧するワークフロー管理システムに関する。
特開2000−207474号公報 特開2000−222305号公報
しかしながら、上述した従来のアプリケーション連携の仕組みには、次のような問題がある。
集中型のフロー制御システムでは、フローの実行がフロー制御部の管理の下に1つの管理サーバで実行される。その結果、処理能力が管理サーバと通信ネットワークの能力によって限定されていた。
また、集中型のフロー制御システムでは、フロー制御部から呼び出されるアプリケーションが停止していた場合は、その時点でフローが停止し、再開するためにはコマンドの実行や、一定間隔でのポーリング制御が必要であった。
これに対して、図20に示すように、非同期通信にフロー制御を追加することも考えられる。図20のシステムでは、アプリケーション121〜123に対して、フロー制御部141〜143およびメッセージキュー151〜153がそれぞれ設けられる。各フロー制御部は、アプリケーションを呼び出すとともに、次のアプリケーションのキューにメッセージを送信する。
しかし、一般的な非同期通信機能の上にフロー制御を構築しただけでは、メッセージ処理とアプリケーションのデータベース更新は別々のトランザクションで実行され、メッセージの保証はできても、メッセージとアプリケーションが扱う業務データの一貫性は保証されない。メッセージと業務データの整合性をとるためには、グローバルトランザクションを管理するトランザクションマネージャ161が必要となり、リカバリやパフォーマンスの観点でコストが高くなるという問題がある。
本発明の第1の課題は、特定の管理サーバを経由することなく、フローに基づいたアプリケーションの連携処理を実現することである。
本発明の第2の課題は、アプリケーション間のメッセージによりフロー制御を実現する場合に、メッセージとアプリケーションが扱う業務データの整合性をとることである。
図1は、本発明のアプリケーションフロー制御装置の原理図である。本発明の第1の局面におけるアプリケーションフロー制御装置は、連携処理を行う複数のアプリケーションの一部を有する装置であって、キュー手段171およびメッセージ処理手段172を備える。
キュー手段171は、複数のアプリケーションの実行順序を指定するフロー定義情報を含む第1のメッセージが送信されたことを示す送信トリガを受信する。メッセージ処理手段172は、その送信トリガに基づいて第1のメッセージを受信し、第1のメッセージに含まれるフロー定義情報に従って、実行すべきアプリケーション173を呼び出し、フロー定義情報と呼び出されたアプリケーション173の実行結果を含む第2のメッセージを、次のアプリケーションを実行する送信先に送信する。
送信元からアプリケーションフロー制御装置宛てに第1のメッセージが送信されると、その旨を通知する送信トリガがキュー手段171に送信される。メッセージ処理手段172は、その送信トリガに基づいて第1のメッセージが送信されたことを検知し、そのメッセージを取得する。そして、メッセージに含まれるフロー定義情報に従って、実行すべきアプリケーション173を特定する。呼び出されたアプリケーション173は、業務処理を実行し、実行結果をメッセージ処理手段172に返す。これを受けて、メッセージ処理手段172は、第2のメッセージを生成して送信先に送信する。
複数のアプリケーションが複数のアプリケーションフロー制御装置に分散配置された場合、1つのアプリケーションを有する装置から次のアプリケーションを有する装置に、直接、フロー制御のためのメッセージが送信される。
本発明の第2の局面において、第1の局面における第1のメッセージは、呼び出されたアプリケーション173により更新されるデータと同じデータベースに格納され、メッセージ処理手段172は、呼び出されたアプリケーション173がデータの更新に用いるトランザクションと同じトランザクションを用いて、第1のメッセージを第2のメッセージに更新し、第2のメッセージが送信されたことを示す送信トリガを送信先に送信する。
本発明によれば、アプリケーションを有する装置間でフロー制御のためのメッセージが転送されるため、特定の管理サーバを経由することなく、フローに基づいたアプリケーションの連携処理が実現される。また、アプリケーションが停止していた場合でも、管理サーバによる再開コマンドの実行やポーリング制御は不要である。
また、メッセージとアプリケーションデータを1つのトランザクションで更新することで、メッセージとアプリケーションが扱うデータの整合性をとることが可能になる。
以下、図面を参照しながら、本発明を実施するための最良の形態を詳細に説明する。
図2は、本実施形態のアプリケーションフロー制御システムの一例を示す構成図である。図2のシステムは、フロー定義作成ツール201、フロー定義データベース202、業務用データベース203、クライアント204、およびサーバ205−1〜205−3を備える。クライアント204は、フロー開始API(Application Program Interface )214を備え、サーバ205−i(i=1,2,3)は、i番目の業務処理を実行するアプリケーション221−i、メッセージ処理部222−i、およびキュー223−iを備える。
図2のシステムは、以下のような特徴を有する。
1.各サーバ205−iにメッセージ処理部222−iが設けられ、メッセージ中には、アプリケーションの実行順序に関するフロー定義211の情報が含まれる。
2.メッセージ処理部222−iは、メッセージを受け取ってアプリケーション221−iを呼び出し、その実行結果を次のメッセージ処理部に送ることで、フローを実行する。
3.メッセージ処理部222−iが受け取るメッセージは、メモリ上に設けられたキュー223−iを経由して処理され、アプリケーション221−iが停止している場合は、キュー223−iにメッセージを蓄積し、アプリケーション221−iが起動した契機で、メッセージ受信が可能になる。
4.メッセージには、フローの状態(現在位置)に関する情報が含まれており、メッセージ処理部222−iは、フロー定義211とフローの状態から、呼び出すべきアプリケーションを特定する。
5.メッセージには、フローの実行情報が含まれており、メッセージを参照することで、処理がどこまで進んだか、およびどのようなルートを経由したかを判別することができる。
6.メッセージデータ213は業務データ212と同じ業務用データベース203に格納され、業務用データベース203のトランザクションを使用することで、メッセージデータ213と業務データ212の整合性をとることができ、トランザクションマネージャが不要となる。
7.フローを実現するメッセージ処理部222−i間の通信と、上記6の処理の一貫性を保証することで、業務処理の一意性が保証される。
まず、フロー実行のための事前作業として、ユーザは、フロー定義作成ツール201によりフロー定義211を作成し、フロー定義データベース202に格納する。フロー定義211は、アプリケーション221−1、アプリケーション221−2、アプリケーション221−3の順に3つのアプリケーションが実行されることを表す。
次に、フロー実行時には、クライアント204がフロー開始API214を実行する。フロー開始API214は、フロー定義データベース202のフロー定義211を参照し、その情報をメッセージに設定して、最初に呼び出すべきアプリケーション221−1のメッセージ処理部222−1に、メッセージ215を送信する。
メッセージ処理部222−1は、メッセージ215に含まれるフロー定義211とフローの状態に基づいて、該当するアプリケーション221−1を呼び出す。アプリケーション221−1は1番目の業務処理を実行し、それが終了すると、サーバ205−1はメッセージ処理部222−1の処理に復帰する。そして、メッセージ処理部222−1は、次に呼び出すべきアプリケーション221−2のメッセージ処理部222−2にメッセージを送信する。
メッセージ処理部222−2は、メッセージ処理部222−1と同様にして、アプリケーション221−2を呼び出し、アプリケーション221−2は、2番目の業務処理を実行する。そして、メッセージ処理部222−2は、次に呼び出すべきアプリケーション221−3のメッセージ処理部222−3にメッセージを送信する。
メッセージ処理部222−3は、メッセージ処理部222−1と同様にして、アプリケーション221−3を呼び出し、アプリケーション221−3は、3番目の業務処理を実行して、業務用データベース203の業務データ212を更新する。そして、メッセージ処理部222−3は、フローの処理結果をクライアント204に通知する。
メッセージ処理部222−1および222−2は、フロー定義211および/または実行されたアプリケーションの処理結果に応じて、次に呼び出すべきアプリケーションを特定する。
なお、この例では、各サーバに1つのアプリケーションが実装されており、3つのサーバの3つのアプリケーションが連携して実行されているが、実際には、各サーバに複数のアプリケーションが実装され、多数のサーバの多数のアプリケーションを連携させることが可能である。
図3は、J2EE(商標)(Java(登録商標) 2 Enterprise Edition )を用いたメッセージ処理部222−iの構成例を示している。図3のメッセージ処理部222−iは、JMS(Java (登録商標)Message Service)311、およびEJB(登録商標)(Enterprise Java(登録商標)Beans)コンテナ312、およびフレームワーク313からなる。
業務用データベース203には、メッセージ領域321および業務用テーブル322が設けられ、メッセージ領域321にはレコード331〜335が格納され、業務用テーブル322には業務データ341および342が格納される。
この場合、メッセージ処理部222−iおよびアプリケーション221−iは、以下のような処理を行う。
<送信処理>
(P1)フレームワーク313がアプリケーション221−iを呼び出す。
(P2)アプリケーション221−iが業務用データベース203のコネクション303を使用して、業務用テーブル322の業務データ341を更新し、フレームワーク313の処理に復帰する。
(P3)フレームワーク313は、メッセージ領域321のレコード334を、P2と同じコネクション303を使用した更新処理によってロックする。レコード334は、メッセージ受信側が受信待ちを行うための受信待ちレコードである。このレコード334には、メッセージ本文の情報を保持するレコード332のレコード番号が設定される。
(P4)フレームワーク313は、メッセージを送信したことを示す送信トリガ(JMSメッセージ)を送信先のキューであるイベントチャネル302に送信し、JMSコミット処理を行う。送信トリガには、P3でロックされた受信待ちレコード334のレコード番号が設定される。
(P5)フレームワーク313は、送信するメッセージ本文の情報をメッセージ領域321のレコード332に格納する。
(P6)コンテナ312は、データベース処理をコミットする。これにより、コネクション303を使用したデータベース操作がコミットされ、受信待ちレコード334のロックが解除される。こうして、メッセージ送信と業務データの更新は1つのトランザクションで処理される。メッセージ受信側がレコードロック解除待ち状態になっている場合は、コミットにより待ちが解除され、受信処理が続行される。また、フレームワーク313は、メッセージ領域321のレコード331〜334を管理するためのレコード335を更新する。
<受信処理>
(P11)コンテナ312は、同じサーバ内のキューであるイベントチャネル301から受信したメッセージを取り出す。そして、そのメッセージに格納されている、送信側がロックした受信待ちレコード333のレコード番号を取得して、フレームワーク313に渡す。フレームワーク313は、コネクション303を使用して、受信待ちレコード333に対して更新処理を行う。送信側のデータベース操作がコミットまたはロールバックされていない場合は、いずれかの操作が行われるまでロック解除待ち状態となる。
(P12)フレームワーク313は、受信待ちレコード333のロックが解除され、更新処理が成功した後、レコード333に設定されている、メッセージ本文のレコード331のレコード番号を取得し、レコード331からメッセージ本文を取得する。
(P13)フレームワーク313は、アプリケーション221−iを呼び出し、アプリケーション221−iは、P11と同じコネクション303を使用して、業務用テーブル322の業務データ341を更新する。
(P14)フレームワーク313は、取得したメッセージ本文のレコード331を削除する。
(P15)コンテナ312は、データベース処理をコミットする。これにより、コネクション303を使用したデータベース操作がコミットされ、メッセージ受信と業務データの更新は1つのトランザクションで処理される。
(P16)コンテナ312は、イベントチャネル301からのメッセージ受信処理をコミットする。
<異常発生時にデータの一貫性を保証する処理>
業務用データベース203の更新を通信を用いて通知先となるプロセスに連絡することは、一般的に考えられる。しかし、この場合、送信元でトランザクションのロールバック、プロセスダウン、サーバのダウン等の異常が発生すると、更新通知が届かなかったり、誤った情報を元に受信側の処理が実行されてしまう可能性がある。
例えば、以下の場合において、キューには送信トリガが格納されているが、対応するデータベースレコードが存在しない状態が発生する可能性がある。
(1)送信側でデータベース処理がコミットされた後、送信メッセージのロールバック、プロセスダウン等の異常が発生した場合
(2)受信側で送信メッセージがコミットされた後、データベース処理のコミットが失敗した場合
これらの場合には、メッセージ処理部222−iは、キュー内の送信トリガを無視することで対処する。具体的には、受信メッセージをコミットして受信処理を完了し、次の受信メッセージの受信処理を開始する。このような対処を行うことで、前述の異常が発生してもデータの一貫性を確保したフロー処理を実現することができる。
上述したようなアプリケーションフロー制御システムによれば、以下のような効果が得られる。
1.アプリケーションから次のアプリケーションに、直接、フロー制御のためのメッセージが送信されるので、特定の管理サーバを経由することなく、多数のサーバを分散動作させた高速なメッセージ処理が可能となる。
2.集中型のフロー制御のように、フローを制御するプロセスが、呼び出したすべてのアプリケーションの処理完了を待ち合わせる必要がないため、プロセス(スレッド)の占有時間が短くなる。
3.アプリケーションの実行情報を収集することで、分散動作にもかかわらず、どの処理がどこまで進んだかのトラッキングが可能となる。
4.サーバダウン等の問題が発生した時に、中断点から再実行することができるので、高信頼なフロー制御が可能となる。
5.アプリケーションが起動したタイミングでフローの続きを実行できるため、ポーリングによる余計なCPU(Central Processing Unit )の消費を防止できる。
6.トランザクションマネージャが不要なため、低コストでデータの整合性をとることができる。
次に、図4から図15までを参照しながら、上述したアプリケーションフロー制御システムの構成および動作について、より詳細に説明する。
図2のフロー定義211は、アプリケーションの実行の流れを指定する情報であり、フロー定義作成ツール201により作成される。アプリケーションの実行の流れは、図4に示すように、アプリケーションに対応するアクティビティ(ACT1〜ACT5)を矢印でつなぐことで実現され、分岐部分(点線の矢印)には、例えば、以下のような条件式を記述することができる。
条件1:要素n>10のとき、ACT3に分岐する。
条件2:要素n≦10のとき、ACT5に分岐する。
また、フロー定義211は、一意の識別子であるフロー名により識別され、複数のフロー定義211を作成することができる。なお、アクティビティの数や分岐は任意に定義できる。各アクティビティ(ACTn)に定義される情報は、次の通りである。
(a)アクティビティ名。
(b)実行するアプリケーション名と、アプリケーションの入力/出力パラメタと、後述するメッセージのユーザデータ部の要素の関係。パラメタとユーザデータ部の要素の関係は、図5に示すような形式で指定される。
(c)アプリケーションに対応するキュー名。
(d)次に実行すべきアクティビティ名。このアクティビティ名は、フロー定義上では、図4の実線の矢印に対応する。
(e)次に実行すべきアクティビティの振り分けを行う場合の条件式[(メッセージの要素n)比較式(値)]と、各条件に対応するアクティビティ名。
こうして作成されたフロー定義211は、フロー定義データベース202に保存される。フロー定義データベース202には、図6に示すように、フロー単位の情報(フロー名および応答キュー名)とアクティビティ毎に定義された(a)〜(e)の情報からなるレコードが、フロー毎に格納される。
図3のメッセージ領域321には、メッセージテーブル、受信待ちテーブル、および管理テーブルが、各サーバのキュー毎に設けられる。これらのテーブルは、順序定義(CREATE SEQUENCE)を用いて生成される。注:CREATE SEQUENCEは、データベースが提供する連番を発行する採番機能
図7は、メッセージテーブルのデータ構造を示している。図7のメッセージテーブルのレコードは以下の情報を含む。
(1)MsgSeqNo:メッセージを一意に識別する識別子である。メッセージテーブル用順序定義で生成された値が使用される。
(2)message・・・:メッセージ本文である。
メッセージテーブルの初期レコード数は0である。
図8は、受信待ちテーブルのデータ構造を示している。図8の受信待ちテーブルのレコードは以下の情報を含む。
(1)WaitSeqNo:レコード番号(1,2,3,...)である。初期値は、受信待ちテーブル用順序定義で生成される値の範囲に設定される。
(2)SendMsgSeqNo:送信するメッセージのレコードのMsgSeqNoが格納される。初期値は0である。
(3)flag:メッセージが受信済みか否かを示すフラグである。初期値はoff(受信済み)である。
受信待ちテーブルの初期レコードとしては、受信待ちに必要となる数のレコードがテーブル作成時に確保され、サイクリックに使用される。
また、管理テーブル(不図示)には、以下の情報が設定される。
(1)メッセージテーブル用順序定義(MSGSEQ):メッセージテーブルのMsgSeqNoの値を生成するために用いられる。メッセージの順序性保証は、この順序定義で行われる。
(2)受信待ちテーブル用順序定義(WAITSEQ):受信待ちテーブルのWaitSeqNoの値を生成するために用いられる。WAITSEQの値は、受信待ちテーブルのポインタとして使用され、受信待ちテーブルのレコード数を最大値として、サイクリックにカウントされる。
アプリケーションの連携を行う際に必要となるデータは、メッセージを利用して伝搬される。メッセージ本文(message・・・)は、図9に示すように、以下の3つの部分から構成される。なお、1つのメッセージは、1つのフロー定義と対応する。
(1)フロー定義部901
フロー定義データベース202に格納された特定のフロー定義の情報を格納する領域である。図10に示すように、フロー名、アクティビティ情報1〜nの定義値(a)〜(e)が設定されている。
(2)状態管理部902
図11に示すように、フローの現在位置および通過したアクティビティ名を格納するパラメタで構成される領域である。現在位置には、フローのカレント位置を示すアクティビティ名が設定され、通過アクティビティには、通過したすべてのアクティビティの名前が順番に格納される。
(3)ユーザデータ部903
図12に示すように、任意の数の要素で構成されており、各要素に対応したユーザデータを格納する領域である。
図13は、アプリケーションフロー制御システムの処理を示すフローチャートである。まず、フロー定義作成ツール201がフロー定義211を作成し、フロー定義データベース202に格納する(ステップ1301)。次に、クライアント204がフロー開始API214を実行し(ステップ1302)、API214は、以下の処理を行う(ステップ1303)。
・実行するフロー名をキーとしてフロー定義データベース202を参照し、フロー定義211を読み出してメッセージ215のフロー定義部901に設定する。
・メッセージ215の状態管理部902の現在位置に、フローの先頭アクティビティであるアクティビティ1の名前を設定する。
・メッセージ215のユーザデータ部903の要素にデータを設定する。
・現在位置に設定されたアクティビティに対応するキュー223−1宛てに、メッセージ215を送信する。
・フローの処理結果をフロー定義部901で定義された応答キューで待ち合わせる。
送信先のメッセージ処理部222−1は、メッセージ215をキュー223−1から受信し、以下の手順で、実行するアプリケーション221−1を特定して呼び出す(ステップ1304)。
・メッセージ215の状態管理部902の現在位置のアクティビティ名を参照し、実行するアクティビティ(n)を特定する。
・メッセージ215のフロー定義部901に設定されているアクティビティ(n)の情報(a)〜(e)を参照する。
・(b)の情報より、呼び出すアプリケーション名を特定し、同じく(b)の情報より、入力パラメタに対応するメッセージ215のユーザデータ部903の要素を設定し、アプリケーション221−1を実行する。
アプリケーション221−1は、1番目の業務処理を実行し、終了するとメッセージ処理部222−1に出力パラメタを出力する(ステップ1305)。
これを受けて、メッセージ処理部222−1は、(b)の情報より、アプリケーション221−1の出力パラメタに対応するユーザデータ部903の要素を特定し、メッセージ215の当該要素に出力パラメタを設定する(ステップ1306)。
次に、メッセージ処理部222−1は、メッセージ215の状態管理部902の現在位置に設定されているアクティビティ名を、状態管理部902の通過アクティビティに追加する(ステップ1307)。
次に、メッセージ処理部222−1は、次に実行するアクティビティを以下の2つの場合において決定し、いずれかの方法で特定したアクティビティ名をメッセージ215の状態管理部902の現在位置に設定する(ステップ1308)。
・メッセージ215のフロー定義部901に、実行されたアプリケーション221−1に対応するアクティビティの分岐条件(e)が定義されていない場合、フロー定義部901の(d)を次に実行するアクティビティとする。
・メッセージ215のフロー定義部901に、実行されたアプリケーション221−1に対応するアクティビティの分岐条件(e)が定義されている場合、(e)の条件式にアプリケーション221−1の出力パラメタを代入し、その結果に応じて指定されているアクティビティを次に実行するアクティビティとする。
次に、メッセージ処理部222−1は、状態管理部902の現在位置に設定したアクティビティに対応するアクティビティ情報を、アクティビティ名をキーとしてフロー定義部901から検索し、該当するアクティビティの(c)に格納されたキュー名を特定する(ステップ1309)。そして、更新されたメッセージ215を特定したキュー223−2に送信する。
メッセージを受信したメッセージ処理部222−2は、フロー定義部901の情報に従って同様の処理を実行し、メッセージ処理部222−3のキュー223−3にメッセージを送信する。メッセージ処理部222−3も同様の処理を実行し、フローが終了すると、フロー定義部901に指定された応答キューにメッセージを送信することで、処理結果を通知する(ステップ1310)。
図14は、送信側メッセージ処理部1401と受信側メッセージ処理1402が行う通常時のメッセージ処理を示している。送信側メッセージ処理部1401の処理シーケンスは、以下の通りである。
(1)管理テーブルのメッセージテーブル用順序定義から送信メッセージレコードのMsgSeqNo(例:62330)を取得し、メッセージ本文(例:ABCD)をメッセージテーブル1403のレコードに挿入する。
(2)管理テーブルの受信待ちテーブル用順序定義から受信待ちテーブルレコードのWaitSeqNo(例:3)を取得し、対象レコードのSendMsgSeqNoに送信メッセージのMsgSeqNoを設定し、flagにonを設定して、レコードを更新する。flagがonの場合は、当該レコードがまだ使用中であるため、受信待ちテーブル用順序定義から受信待ちテーブルレコードのWaitSeqNoを再取得する。
(3)更新された受信待ちテーブル1404のレコードのWaitSeqNoを、送信トリガとして受信側のキュー1405に送信する。このとき、メッセージ本文はキュー1405には送信されない。
(4)送信メッセージに対するJMSコミットを発行する。
(5)データベースコミットを発行する。
JMSコミットにより、受信側メッセージ処理部1402は、送信トリガを受けて処理を開始する。メッセージ処理部1402の処理シーケンスは、以下の通りである。
(1)キュー1405からメッセージ(WaitSeqNo)を取り出す。
(2)受信待ちテーブル1404に対する更新処理を行い、取り出したメッセージに格納されたWaitSeqNoのレコードのflagをoffに設定する。これにより、受信済み設定が完了する。送信側のデータベースコミットが完了していない場合は、それが完了するまで待ち状態となる。
(3)待ち状態が解除された受信待ちテーブルレコードのSendMsgSeqNoを取得して、取得した番号と一致するMsgSeqNoのレコードをメッセージテーブル1403から取得する。そして、受信待ちテーブルレコードのSendMsgSeqNoを0に更新する。
(4)取得したメッセージテーブル1403のレコードを削除する。
(5)データベースコミットを発行する。
(6)受信メッセージに対するJMSコミットを発行する。
このようなメッセージ処理をメッセージテーブル1403のみで制御すると、送信側の(5)のデータベースコミットが完了する前に受信側の(3)の処理が開始され、メッセージテーブル1403がアクセスされる可能性がある。この場合、メッセージテーブル1403にレコードが挿入されていなければ、メッセージ受信に失敗する。そこで、本実施形態では、メッセージテーブル1403に加えて、受信待ちテーブル1404を使用して排他制御を行うことで、受信失敗を防止している。
図15は、送信側でJMSコミット完了後に異常が発生した場合のメッセージ処理を示している。この場合、送信側メッセージ処理部1401の処理(1)〜(4)については、図14の場合と同様である。
その後、サーバの異常等の原因により、(5)のデータベースコミットが失敗する。この時点で、送信トリガは受信側に正常に通知されているが、データベースはロールバックされてしまい、矛盾した状態になる。データベースがロールバックされることで、(1)および(2)で行ったデータベース操作は取り消され、メッセージテーブル1403のレコードが存在せず、受信待ちテーブル1404の更新が取り消された状態(SendMsgSeqNo=0)になっている。
送信側のJMSコミットにより、受信側メッセージ処理部1402は、送信トリガを受けて処理を開始する。この場合、メッセージ処理部1402の処理(1)および(2)については、図14の場合と同様である。
その後、メッセージ処理部1402は、受信待ちテーブルレコードのSendMsgSeqNoを取得するが、送信側の(2)の操作は取り消されているので、取得したSendMsgSeqNoは0となる。そこで、送信トリガの送信後に送信側で異常が発生したものと判断し、JMSコミットを発行して、受信した送信トリガの無効化を行う。そして、受信側の(2)の更新処理をロールバックする。
これに対して、受信側でデータベースコミット完了後、JMSコミット前に異常が発生した場合は、送信側メッセージ処理部1401の処理(1)〜(5)と受信側メッセージ処理部1402の処理(1)〜(5)については、図14の場合と同様である。
その後、サーバの異常等の原因により、受信側の(6)のJMSコミットが失敗し、送信トリガがロールバックされる。このため、既にデータベースの更新処理は完了しているのに送信トリガが存在する、という矛盾した状態が発生する。このとき、メッセージ処理部1402は、以下のシーケンスで送信トリガを無効化する。
(7)キュー1405から(1)と同じメッセージを取り出し、送信トリガを受信する。
(8)(2)と同様にして、取り出したメッセージに格納されたWaitSeqNoの受信待ちテーブルレコードの更新処理を行う。
(9)受信待ちテーブルレコードのSendMsgSeqNoを取得するが、SendMsgSeqNoは既に0に更新されているため、取得したSendMsgSeqNoは0となる。そこで、この送信トリガは処理済みと判断し、JMSコミットを発行して、受信した送信トリガの無効化を行う。
ところで、図2のクライアント204およびサーバ205−1〜205−3は、例えば、図16に示すような情報処理装置(コンピュータ)を用いて構成される。図16の情報処理装置は、CPU1601、メモリ1602、入力装置1603、出力装置1604、外部記憶装置1605、媒体駆動装置1606、およびネットワーク接続装置1607を備え、それらはバス1608により互いに接続されている。
メモリ1602は、例えば、ROM(read only memory)、RAM(random access memory)等を含み、処理に用いられるプログラムおよびデータを格納する。CPU1601は、メモリ1602を利用してプログラムを実行することにより、必要な処理を行う。
図2のフロー定義作成ツール201、フロー開始API214、アプリケーション221−i、メッセージ処理部222−i、および図3のJMS311、コンテナ312、およびフレームワーク313は、メモリ1602に格納されたプログラムに対応する。また、図2のキュー223−iは、メモリ1602に格納されたデータに対応する。
入力装置1603は、例えば、オペレータからの指示や情報の入力に用いられる。出力装置1604は、例えば、ディスプレイ、プリンタ、スピーカ等であり、オペレータへの問い合わせや処理結果等の出力に用いられる。
外部記憶装置1605は、例えば、磁気ディスク装置、光ディスク装置、光磁気ディスク装置、テープ装置等である。情報処理装置は、この外部記憶装置1605に、プログラムおよびデータを格納しておき、必要に応じて、それらをメモリ1602にロードして使用する。外部記憶装置1605は、フロー定義データベース202および業務用データベース203として使用することもできる。
媒体駆動装置1606は、可搬記録媒体1609を駆動し、その記録内容にアクセスする。可搬記録媒体1609は、メモリカード、フレキシブルディスク、光ディスク、光磁気ディスク等の任意のコンピュータ読み取り可能な記録媒体である。オペレータは、この可搬記録媒体1609にプログラムおよびデータを格納しておき、必要に応じて、それらをメモリ1602にロードして使用する。
ネットワーク接続装置1607は、LAN(Local Area Network)等の任意の通信ネットワークに接続され、通信に伴うデータ変換を行う。情報処理装置は、必要に応じて、プログラムおよびデータを外部の装置からネットワーク接続装置1607を介して受け取り、それらをメモリ1602にロードして使用する。
図17は、図16の情報処理装置にプログラムおよびデータを提供する方法を示している。可搬記録媒体1609やサーバ1701のデータベース1711に格納されたプログラムおよびデータは、情報処理装置1702のメモリ1602にロードされる。サーバ1701は、そのプログラムおよびデータを搬送する搬送信号を生成し、ネットワーク上の任意の伝送媒体を介して情報処理装置1702に送信する。CPU1601は、そのデータを用いてそのプログラムを実行し、必要な処理を行う。
(付記1) 連携処理を行う複数のアプリケーションの一部を有するアプリケーションフロー制御装置であって、
前記複数のアプリケーションの実行順序を指定するフロー定義情報を含む第1のメッセージが送信されたことを示す送信トリガを受信するキュー手段と、
前記送信トリガに基づいて前記第1のメッセージを受信し、該第1のメッセージに含まれる前記フロー定義情報に従って、実行すべきアプリケーションを呼び出し、該フロー定義情報と呼び出されたアプリケーションの実行結果を含む第2のメッセージを、次のアプリケーションを実行する送信先に送信するメッセージ処理手段と
を備えることを特徴とするアプリケーションフロー制御装置。
(付記2) 連携処理を行う複数のアプリケーションの一部を有するコンピュータのためのプログラムであって、
前記複数のアプリケーションの実行順序を指定するフロー定義情報を含む第1のメッセージが送信されたことを示す送信トリガをキュー手段が受信したとき、該送信トリガに基づいて前記第1のメッセージを受信し、
前記第1のメッセージに含まれる前記フロー定義情報に従って、実行すべきアプリケーションを呼び出し、
前記フロー定義情報と呼び出されたアプリケーションの実行結果を含む第2のメッセージを、次のアプリケーションを実行する送信先に送信する
処理をコンピュータに実行させることを特徴とするプログラム。
(付記3) 前記第1のメッセージは、フローの現在位置を示す状態管理情報を含み、前記プログラムは、前記フロー定義情報と該状態管理情報に従って前記実行すべきアプリケーションを特定する処理を、前記コンピュータに実行させることを特徴とする付記2記載のプログラム。
(付記4) 前記状態管理情報は、実行済みのアプリケーションを示す情報を含み、前記プログラムは、前記呼び出されたアプリケーションを該実行済みのアプリケーションに追加して、前記第2のメッセージの状態管理情報を生成する処理を、前記コンピュータに実行させることを特徴とする付記3記載のプログラム。
(付記5) 前記フロー定義情報は、フローの分岐条件を示す情報を含み、前記プログラムは、該分岐条件と前記呼び出されたアプリケーションの実行結果とに応じて、前記実行すべきアプリケーションを特定する処理を、前記コンピュータに実行させることを特徴とする付記2記載のプログラム。
(付記6) 前記第1のメッセージは、前記呼び出されたアプリケーションにより更新されるデータと同じデータベースに格納され、前記プログラムは、該呼び出されたアプリケーションがデータの更新に用いるトランザクションと同じトランザクションを用いて、該第1のメッセージを前記第2のメッセージに更新し、該第2のメッセージが送信されたことを示す送信トリガを前記送信先に送信する処理を、前記コンピュータに実行させることを特徴とする付記2乃至5記載のプログラム。
(付記7) 連携処理を行う複数のアプリケーションの一部を有する装置におけるアプリケーションフロー制御方法であって、
前記複数のアプリケーションの実行順序を指定するフロー定義情報を含む第1のメッセージが送信されたことを示す送信トリガをキュー手段が受信したとき、メッセージ処理手段が、該送信トリガに基づいて前記第1のメッセージを受信し、
前記メッセージ処理手段が、前記第1のメッセージに含まれる前記フロー定義情報に従って、実行すべきアプリケーションを呼び出し、
前記メッセージ処理手段が、前記フロー定義情報と呼び出されたアプリケーションの実行結果を含む第2のメッセージを、次のアプリケーションを実行する送信先に送信する
ことを特徴とするアプリケーションフロー制御方法。
本発明のアプリケーションフロー制御装置の原理図である。 アプリケーションフロー制御システムの構成図である。 メッセージ処理部の構成図である。 アプリケーションの実行の流れを示す図である。 パラメタと要素の関係を示す図である。 フロー定義データベースを示す図である。 メッセージテーブルを示す図である。 受信待ちテーブルを示す図である。 メッセージを示す図である。 フロー定義部を示す図である。 状態管理部を示す図である。 ユーザデータ部を示す図である。 アプリケーションフロー制御システムの処理のフローチャートである。 通常時のメッセージ処理を示す図である。 異常発生時のメッセージ処理を示す図である。 情報処理装置の構成図である。 プログラムおよびデータの提供方法を示す図である。 アプリケーションの連携を示す図である。 集中型のフロー制御システムを示す図である。 非同期通信にフロー制御を追加したシステムを示す図である。
符号の説明
101、204 クライアント
102、203 業務用データベース
111、112、113、205−1、205−2、205−3 サーバ
121、122、123、173、221−1、221−2、221−3、221−i アプリケーション
131 管理サーバ
132、141、142、143 フロー制御部
133 フロー
134 状態管理データベース
151、152、153、223−1、223−2、223−3、1405 キュー
161 トランザクションマネージャ
171 キュー手段
172 メッセージ処理手段
201 フロー定義作成ツール
202 フロー定義データベース
211 フロー定義
212 業務データ
212 メッセージデータ
214 フロー開始API
215 メッセージ
222−1、222−2、222−3、222−i メッセージ処理部
301、302 イベントチャネル
311 JMS
312 コンテナ312
313 フレームワーク
321 メッセージ領域
322 業務用テーブル
331、332、333、334、335 レコード
341、342 業務データ
901 フロー定義部
902 状態管理部
903 ユーザデータ部
1401 送信側メッセージ処理部
1402 受信側メッセージ処理部
1403 メッセージテーブル
1404 受信待ちテーブル
1601 CPU
1602 メモリ
1603 入力装置
1604 出力装置
1605 外部記憶装置
1606 媒体駆動装置
1607 ネットワーク接続装置
1608 バス
1609 可搬記録媒体
1701 サーバ
1702 情報処理装置
1711 データベース

Claims (5)

  1. 連携処理を行う複数のアプリケーションの一部を有するアプリケーションフロー制御装置であって、
    前記複数のアプリケーションの実行順序を指定するフロー定義情報を含む第1のメッセージが送信されたことを示す送信トリガを受信するキュー手段と、
    前記送信トリガに基づいて前記第1のメッセージを受信し、該第1のメッセージに含まれる前記フロー定義情報に従って、実行すべきアプリケーションを呼び出し、該フロー定義情報と呼び出されたアプリケーションの実行結果を含む第2のメッセージを、次のアプリケーションを実行する送信先に送信するメッセージ処理手段と
    を備えることを特徴とするアプリケーションフロー制御装置。
  2. 連携処理を行う複数のアプリケーションの一部を有するコンピュータのためのプログラムであって、
    前記複数のアプリケーションの実行順序を指定するフロー定義情報を含む第1のメッセージが送信されたことを示す送信トリガをキュー手段が受信したとき、該送信トリガに基づいて前記第1のメッセージを受信し、
    前記第1のメッセージに含まれる前記フロー定義情報に従って、実行すべきアプリケーションを呼び出し、
    前記フロー定義情報と呼び出されたアプリケーションの実行結果を含む第2のメッセージを、次のアプリケーションを実行する送信先に送信する
    処理をコンピュータに実行させることを特徴とするプログラム。
  3. 前記第1のメッセージは、フローの現在位置を示す状態管理情報を含み、前記プログラムは、前記フロー定義情報と該状態管理情報に従って前記実行すべきアプリケーションを特定する処理を、前記コンピュータに実行させることを特徴とする請求項2記載のプログラム。
  4. 前記フロー定義情報は、フローの分岐条件を示す情報を含み、前記プログラムは、該分岐条件と前記呼び出されたアプリケーションの実行結果とに応じて、前記実行すべきアプリケーションを特定する処理を、前記コンピュータに実行させることを特徴とする請求項2記載のプログラム。
  5. 前記第1のメッセージは、前記呼び出されたアプリケーションにより更新されるデータと同じデータベースに格納され、前記プログラムは、該呼び出されたアプリケーションがデータの更新に用いるトランザクションと同じトランザクションを用いて、該第1のメッセージを前記第2のメッセージに更新し、該第2のメッセージが送信されたことを示す送信トリガを前記送信先に送信する処理を、前記コンピュータに実行させることを特徴とする請求項2乃至4記載のプログラム。
JP2004319620A 2004-11-02 2004-11-02 アプリケーションフロー制御装置 Expired - Lifetime JP4102354B2 (ja)

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 true JP2006133894A (ja) 2006-05-25
JP4102354B2 JP4102354B2 (ja) 2008-06-18

Family

ID=36261712

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2004319620A Expired - Lifetime JP4102354B2 (ja) 2004-11-02 2004-11-02 アプリケーションフロー制御装置

Country Status (2)

Country Link
US (1) US8418191B2 (ja)
JP (1) JP4102354B2 (ja)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2008149427A1 (ja) * 2007-06-05 2008-12-11 Fujitsu Limited メッセージ処理プログラム、メッセージ処理方法および情報処理装置
JP2014134873A (ja) * 2013-01-08 2014-07-24 Ricoh Co Ltd 処理実行システム、情報処理装置、プログラム

Families Citing this family (15)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP5084355B2 (ja) * 2007-06-07 2012-11-28 キヤノン株式会社 フロー処理実行装置、フロー処理実行方法及びプログラム
US9986279B2 (en) 2008-11-26 2018-05-29 Free Stream Media Corp. Discovery, access control, and communication with networked services
US10631068B2 (en) 2008-11-26 2020-04-21 Free Stream Media Corp. Content exposure attribution based on renderings of related content across multiple devices
US10419541B2 (en) 2008-11-26 2019-09-17 Free Stream Media Corp. Remotely control devices over a network without authentication or registration
US9386356B2 (en) 2008-11-26 2016-07-05 Free Stream Media Corp. Targeting with television audience data across multiple screens
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
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
US9154942B2 (en) * 2008-11-26 2015-10-06 Free Stream Media Corp. Zero configuration communication between a browser and a networked media 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
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
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
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
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
JP6953703B2 (ja) * 2016-10-19 2021-10-27 株式会社リコー システム、情報処理方法、情報処理装置、プログラム

Family Cites Families (10)

* Cited by examiner, † Cited by third party
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

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2008149427A1 (ja) * 2007-06-05 2008-12-11 Fujitsu Limited メッセージ処理プログラム、メッセージ処理方法および情報処理装置
JP2014134873A (ja) * 2013-01-08 2014-07-24 Ricoh Co Ltd 処理実行システム、情報処理装置、プログラム

Also Published As

Publication number Publication date
US20060092834A1 (en) 2006-05-04
JP4102354B2 (ja) 2008-06-18
US8418191B2 (en) 2013-04-09

Similar Documents

Publication Publication Date Title
JP4102354B2 (ja) アプリケーションフロー制御装置
US6980988B1 (en) Method of applying changes to a standby database system
JP6223569B2 (ja) ビジネスフローをスケジュールするためのコンピュータ装置、方法及び装置
US7779298B2 (en) Distributed job manager recovery
US9286368B2 (en) Linking framework for information technology management
US6014673A (en) Simultaneous use of database and durable store in work flow and process flow systems
US7328213B2 (en) Transaction processing method, transaction control apparatus and program thereof
EP2335153B1 (en) Queue manager and method of managing queues in an asynchronous messaging system
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
US20090320044A1 (en) Peek and Lock Using Queue Partitioning
US9069632B2 (en) Message processing
JP2002007182A (ja) 外部記憶装置の共有ファイル管理方式
US20100088287A1 (en) Information system, method and recording medium having program recorded thereon relating to collectively registered data
US7747829B2 (en) Arrangement and method for update of configuration cache data
US20030191918A1 (en) Data processing arrangement and method
US20020040380A1 (en) Program executing management system, a computer program product and a process executing management method
JP2006338197A (ja) トランザクション制御プログラム、トランザクション制御方法及びトランザクション処理システム
JP2009169793A (ja) サービス管理方法とシステムおよびプログラム
CN115687491A (zh) 一种基于关系型数据库的数据分析任务调度系统
JP5537917B2 (ja) 管理装置及びデータ処理制御装置及び管理方法及びデータ処理制御方法及びプログラム
JP4262932B2 (ja) トランザクション処理装置、同装置のトランザクション処理方法、トランザクション処理プログラムおよび同プログラムを記録したコンピュータ読み取り可能な記録媒体
JP2001067214A (ja) コンピュータシステム及びプログラムファイル更新方法
JP2001265614A (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