JP4280703B2

JP4280703B2 - プロセス間通信

Info

Publication number: JP4280703B2
Application number: JP2004324698A
Authority: JP
Inventors: 大介佐川; 武章吉田; 紀洋谷▲崎▼; 章山口
Original assignee: Hitachi Omron Terminal Solutions Corp
Current assignee: Hitachi Omron Terminal Solutions Corp
Priority date: 2004-11-09
Filing date: 2004-11-09
Publication date: 2009-06-17
Anticipated expiration: 2024-11-09
Also published as: JP2006134206A

Description

本発明は、プロセス間通信に関する。

ＡＴＭなどの金融端末の制御には、業務プロセスとデバイスプロセスと呼ばれるソフトウェアが利用されることが多い。業務プロセスは、ＡＴＭを制御して、ユーザから指示された処理（入金や出金など）を実行する。デバイスプロセスは、業務プロセスの指示を受けて、ＡＴＭに備えられたカード取扱装置や通帳取扱装置などの各種デバイスにおけるデバイス処理を実行する。デバイス処理は、デバイスプロセス中に、各デバイスに対して１つずつ備えられたデバイスオブジェクト（以下、ＤＯと呼ぶ）が実行する。

図４は、従来の業務プロセスとデバイスプロセスで２つの非同期処理が実行される手順を示すシーケンス図である。図４の左から順に、業務プロセスと、デバイスプロセスのＤＯ２３ａと、ＤＯ２３ｂのシーケンスである。なお、業務プロセスのシーケンスにおける斜線の枠内は、業務プロセスが、自身の担当する処理を実行中であることを示す。

まず、業務プロセスは、自身の担当する処理の実行を中断し、ＤＯ２３ａを起動する（ステップＳ１）。ＤＯ２３ａは、受付応答を返し（ステップＳ２）、デバイス処理を開始する。なお、ＤＯ２３ａとＤＯ２３ｂのシーケンスにおける太い実線は、ＤＯ２３ａとＤＯ２３ｂがデバイス処理中であることを示す。次に、業務プロセスは、ＤＯ２３ｂを起動する（ステップＳ３）。ＤＯ２３ｂは、受付応答を返し（ステップＳ４）、デバイス処理を開始する。

業務プロセスは、ＤＯ２３ａとＤＯ２３ｂから受付応答を受信すると、自身の担当する処理を実行する。そして、業務プロセスは、ＤＯ２３ａの実行結果が必要となった時点で、ＤＯ２３ａに実行結果を要求する（ステップＳ５）。ＤＯ２３ａは、要求に応じて業務プロセスに実行結果を送信する（ステップＳ６）。業務プロセスは、ＤＯ２３ａの実行結果に基づいて、自身の担当する処理を実行する。そして、業務プロセスは、ＤＯ２３ｂの実行結果が必要となった時点で、ＤＯ２３ｂに実行結果を要求する（ステップＳ７）。ＤＯ２３ｂは、デバイス処理が終了していないため、実行結果を送信することができない。よって、業務プロセスは、ＤＯ２３ｂに繰り返し実行結果を要求する（ステップＳ８）。ＤＯ２３ｂは、デバイス処理が終了すると、業務プロセスに実行結果を送信する（ステップＳ９）。業務プロセスは、ＤＯ２３ｂの実行結果に基づいて、自身の担当する処理を実行する。

以上のような非同期処理では、ＤＯ２３ａ，２３ｂがデバイス処理を実行している間にも、業務プロセスが自身の担当する処理を実行することができる。よって、デバイス処理がハードウェアの起動など時間のかかる処理である場合に、非同期処理を利用するメリットが大きい。

特開２００４−１５７７７６号公報

しかしながら、従来のＡＴＭの業務プロセスは、ＤＯ２３ａ，２３ｂ毎にＤＯ２３ａ，２３ｂを起動し（ステップＳ１，Ｓ３）、そして実行結果を要求する（ステップＳ５，Ｓ７，Ｓ８）。ＤＯ２３ａ，２３ｂも、各々が受付応答を送信し（ステップＳ２，Ｓ４）、実行結果を送信する（ステップＳ６，Ｓ９）。また、実行結果要求時にＤＯがデバイス処理を終えていない場合は、業務プロセスは繰り返し実行結果を要求する（ステップＳ７，Ｓ８）。

つまり、従来のＡＴＭでは、複数のデバイスに関する複数の非同期処理を実行する場合、業務プロセスとデバイスプロセスとの間でプロセス間通信が頻発することが多かった。そのため、ＡＴＭの処理性能に悪影響を与えるという問題があった。

このような問題は、ＡＴＭに限らず、複数のプロセス間で通信を行ないつつ処理を実行するプロセス間通信システムに共通する問題であった。

本発明は、上記した問題点を解決するためになされたものであり、プロセス間通信の回数を抑制したプロセス間通信システムを提供することを目的とする。

上記課題の少なくとも一部を解決するため、本発明によるプロセス間通信システムは、複数のプロセスが、通信を行ないつつ処理を実行するプロセス間通信システムであって、前記プロセス間通信システムは、自身の担当する処理を実行する業務ロジックと、デバイス処理の実行要求を他のプロセスに送信する第１の送受信タスクとを備えた業務プロセスと、前記実行要求を受信する第２の送受信タスクと、各々任意の前記デバイス処理を実行する複数のデバイス処理部とを備えたデバイスプロセスと、を備え、前記業務ロジックは、前記デバイス処理の実行要求を複数前記第１の送受信タスクに登録した後、登録した複数の実行要求の送信指示を前記第１の送受信タスクに送り、前記第１の送受信タスクは、前記送信指示に応じて、登録された前記複数の実行要求をまとめて前記デバイスプロセスに送信し、前記第２の送受信タスクは、前記複数の実行要求を受信し、個々の実行要求に応じた前記デバイス処理部を起動し、前記デバイス処理部は、起動されるのに呼応して、前記実行要求を受け付けたことを示す受付応答を前記第２の送受信タスクに登録して、前記デバイス処理を実行し、前記第２の送受信タスクは、前記業務プロセスから受信した前記複数の実行要求のすべてに関する前記受付応答が登録された後に、受付応答を前記業務プロセスに送信する、ことを特徴とする。

本発明によれば、プロセス間でデバイス処理の実行要求や受付応答をまとめて送受信するので、プロセス間通信の回数を抑制することができる。

前記業務ロジックは、自身の担当する処理の実行を中断して、前記デバイス処理の実行要求を複数前記第１の送受信タスクに登録した後、登録した複数の実行要求の送信指示を前記第１の送受信タスクに送り、前記デバイスプロセスから前記受付応答を受信すると、自身の担当する処理の実行を再開する、ものとしても良い。

前記デバイス処理部は、前記デバイス処理の実行結果を前記第２の送受信タスクに登録し、前記業務ロジックは、前記実行要求を出した前記デバイス処理のうち、任意の複数の前記デバイス処理に関する実行結果を前記デバイスプロセスにまとめて要求し、前記第２の送受信タスクは、前記要求に応じて、登録された実行結果のうち、要求された実行結果を、前記業務プロセスに送信する、ものとしても良い。

これによれば、業務プロセスが実行結果を要求した後、デバイスプロセスは、要求された実行結果をまとめて業務プロセスに送信するので、更にプロセス間通信の回数を抑制することができる。

前記業務ロジックは、自身の担当する処理の実行を中断して、前記実行要求を出した前記デバイス処理のうち、任意の複数の前記デバイス処理に関する実行結果を前記デバイスプロセスにまとめて要求し、前記デバイスプロセスから前記実行結果を受信すると、自身の担当する処理の実行を再開する、ものとしても良い。

前記第２の送受信タスクは、要求された複数の実行結果が全て登録されていない場合、全て登録されるまで待機し、要求された全ての実行結果をまとめて送信する、ものとしても良い。

これによれば、要求された実行結果が全て登録されていない場合であっても、登録されるまで待ってから、要求された実行結果をまとめて送信するので、更にプロセス間通信の回数を抑制することができる。

前記業務プロセスと、前記デバイスプロセスとは、コンピュータのプラットフォームに依存しないコンピュータプログラムによってそれぞれ実現されている、ものとしても良い。

前記業務プロセスと、前記デバイスプロセスとは、異なるコンピュータ上に存在する、ものとしても良い。

なお本発明は種々の形態で実現可能であり、例えば、プロセス間通信方法等の形態で実現可能である。

図１は、ＡＴＭ１００を示すブロック図である。ＡＴＭ１００は、本発明のプロセス間通信システムに相当し、業務プロセス１０とデバイスプロセス２０とで通信を行ないながら処理を実行する。業務プロセス１０は、ＡＴＭ１００を制御して、ユーザから指示された処理を実行する。デバイスプロセス２０は、ＡＴＭ１００に備えられたカード取扱装置や通帳取扱装置などのデバイスを制御しており、業務プロセス１０の指示を受けて、デバイスに関するデバイス処理を実行する。デバイス処理とは、例えば、カード情報の読み取り処理や通帳への印字処理などである。業務プロセス１０と、デバイスプロセス２０とは、コンピュータのプラットフォームに依存しない形式でプログラミングされたプログラムである。ここでは、Ｊａｖａ（登録商標）でプログラミングされている。

業務プロセス１０は、業務ロジック１１と送信タスク１２とを備えている。業務プロセス１０と、業務ロジック１１と、送信タスク１２は、いずれもオブジェクトとして実装されている。デバイスプロセス２０は、受信タスク２１と、複数のデバイスオブジェクト２２ａ〜２２ｃを備えている。デバイスプロセスと、受信タスク２１も、オブジェクトとして実装されている。

業務ロジック１１は、自身も処理を実行しつつ、複数のデバイス処理の実行要求を送信タスク１２に登録する。送信タスク１２は、業務ロジック１１からの送信指示に応じて、登録されている実行要求を全てデバイスプロセス２０の受信タスク２１に送信する。受信タスク２１は、送信タスクから複数の実行要求を受信し、個々の実行要求に応じたデバイス処理をするデバイスオブジェクト（以下、ＤＯと呼ぶ）２２ａ〜２２ｃを起動する。ＤＯ２２ａ〜２２ｃは、デバイス処理を実行する。ＤＯ２２ａ〜２２ｃは、本発明のデバイス処理部に相当する。ここでは、簡単のためにＤＯ２２ａ〜２２ｃは３個であるものとしたが、ＤＯ２２ａ〜２２ｃの数は、３個に限らず、２個であっても良いし、４個以上であっても良い。なお、送信タスク１２は、送信のみではなく、受信も実行する。また、受信タスク２１も、受信のみではなく送信も担当する。従って、これらをそれぞれ「送受信タスク」と呼ぶことも可能である。送信タスク１２は、本発明の第１の送受信タスクに相当し、受信タスク２１は、本発明の第２の送受信タスクに相当する。

図２は、業務プロセス１０とデバイスプロセス２０とで３つの非同期処理が実行される手順を示すシーケンス図である。図２の左から順に、業務ロジック１１と、送信タスク１２と、受信タスク２１と、３個のＤＯ２２ａ〜２２ｃのシーケンスである。

業務ロジック１１は、まず、ＡＴＭ１００の操作画面（図示せず）に、ユーザに対する操作ガイダンスを表示し、ユーザからの操作を受け付ける。業務ロジック１１のシーケンスにおける斜線の枠内は、業務ロジック１１が、このような自身の担当する処理を実行中であることを示す。ここでは、ＡＴＭ１００の利用者から、現金引き出しの指示がされものとする。

次に、業務ロジック１１は、現金引き出しに応じたＤＯの実行要求を送信タスク１２に登録する。具体的には、カード情報の読み取りを行なうＤＯ２２ａの実行要求を登録し（ステップＳ１０）、指紋読取装置などの認証装置の起動を行なうＤＯ２２ｂの実行要求を登録し（ステップＳ２０）、通帳の読み取りを行なうＤＯ２２ｃの実行要求を登録する（ステップＳ３０）。そして、登録した実行要求を送信するように送信タスク１２に指示を出す（ステップＳ４０）。

送信タスク１２は、登録された３つの実行要求をまとめて受信タスク２１に送信する（ステップＳ５０）。なお、図の太い実線の矢印は、複数の情報がまとめて送信されていることを示す。

受信タスク２１は、３つの実行要求を受信すると、それらを自身のタスク内に登録する。そして、実行要求に応じたＤＯ２２ａ〜２２ｃを起動する。ＤＯ２２ａ〜２２ｃのシーケンスにおける太い実線は、ＤＯ２２ａ〜２２ｃがデバイス処理中であることを示す。具体的には、受信タスク２１は、ＤＯ２２ａを起動する（ステップＳ６０）。ＤＯ２２ａは、起動されると、実行要求を受け付けたことを示す受付応答を受信タスク２１に返し（ステップＳ７０）、カード情報の読み取り処理を行なう。受信タスク２１は、受け取った受付応答を自身に登録する。更に、受信タスク２１は、ＤＯ２２ｂを起動する（ステップＳ８０）。ＤＯ２２ｂは、起動されると、受信タスク２１に受付応答を返し（ステップＳ９０）、認証装置の起動処理を行なう。受信タスク２１は、受け取った受付応答を自身に登録する。更に、受信タスク２１は、ＤＯ２２ｃを起動する（ステップＳ１００）。ＤＯ２２ｃは、起動されると、受信タスク２１に受付応答を返し（ステップＳ１１０）、通帳の読み取り処理を行なう。受信タスク２１は、受け取った受付応答を自身に登録する。

なお、受信タスク２１は、起動したＤＯ２２ａ〜２２ｃからの受付応答が所定時間以上返ってこないといった異常を検出した場合は、業務プロセス１０側に、異常報告をするものとしても良い。

受信タスク２１は、起動したＤＯ数分の受付応答、つまり３個の受付応答を自身に登録すると、３個の受付応答をまとめて送信タスク１２に送信する（ステップＳ１２０）。これにより、デバイスプロセス２０は、処理を業務プロセス１０に返す。なお、受信タスク２１がここで送信する受付応答は、ＤＯ２２ａ〜２２ｃから受信した３個の受付応答に限らず、新たに受付応答を生成して送信するものとしても良い。

受付応答を受信した送信タスク１２は、受信した３つの受付応答をまとめて業務ロジック１１に送る（ステップＳ１３０）。

業務ロジック１１は、受付応答を受け取り、処理が戻ってくると、自身の担当する処理を実行する。ここでは、カードと通帳の挿入を促すメッセージを操作画面上に表示する。ユーザは、表示に応じて、ＡＴＭ１００にカードと通帳を挿入する。

ＤＯ２２ａは、ユーザからカードが挿入されるのを待ち、カードが挿入されると、カード情報の読み取りを実行して、実行結果、つまりカード情報を受信タスク２１に登録する（ステップＳ１４０）。カード情報には、カードの暗証番号や口座番号も含まれる。ＤＯ２２ｃは、ユーザから通帳が挿入されるのを待ち、通帳が挿入されると、通帳の口座番号などの通帳情報を読み取る。

一方、業務ロジック１１は、カードと通帳の挿入を促すメッセージを操作画面上に表示した後、引き続き、暗証番号の入力を促す画面を表示し、暗証番号が入力されると、待ち受け画面を表示し、ＤＯ２２ａとＤＯ２２ｃの実行結果を送信タスク１２に対してまとめて要求する（ステップＳ１５０）。業務ロジック１１は、送信タスク１２に対して要求する際に、例えば、（２２ａＡＮＤ２２ｃ）と論理式で指定することにより、ＤＯ２２ａとＤＯ２２ｃの実行結果を要求する。このとき、実行要求を出したＤＯすべての実行結果を要求する必要はなく、任意の複数のＤＯに関する実行結果をまとめて要求すれば良い。

送信タスク１２は、業務ロジック１１から要求された実行結果を受信タスク２１に対して要求する（ステップＳ１６０）。

受信タスク２１は、業務プロセス１０から指定された条件式（２２ａＡＮＤ２２ｃ）と、自身に登録されている実行結果を基に、条件式を満たしているか否かを判定する。即ち、業務プロセス１０から要求された実行結果が、全て自身に登録されているか否かを判定する（ステップＳ１７０）。要求された実行結果が全て登録されている場合は、そこで要求された全ての実行結果をまとめて送信するが、要求された実行結果が全て登録されていない場合は、要求された実行結果が全て登録されるまで待機する（ステップＳ１８０）。ここでは、ＤＯ２２ｃの実行結果が登録されるまで待機する。ＤＯ２２ｃの実行結果は、通帳の口座番号などの通帳情報である。ここで、待機する処理とは、受信タスクが、自身上に配備されている実行結果格納スペースを参照し、指定された実行結果が登録されるのを監視する処理である。そして、受信タスク２１は、ＤＯ２２ｃの実行結果が登録されると、ＤＯ２２ａの実行結果と併せて、要求された全ての実行結果を、まとめて送信タスク１２に送信する（ステップＳ２００）。

送信タスク１２は、受信タスク２１から送信された実行結果を、まとめて業務ロジック１１に送る（ステップＳ２１０）。

業務ロジック１１は、受信した実行結果に基づいて、次に自身が実行する処理の内容を決定し、実行する。例えばここでは、ＤＯ２２ａの実行結果であるカードの暗証番号や口座番号と、ＤＯ２２ｃの実行結果である通帳の口座番号と、ユーザが入力した暗証番号とを比較し、異常があるか否かを判定する。そして、異常がある場合は、暗証番号が間違っているなどのメッセージを表示し、異常がない場合は、次の操作内容を示すメッセージを操作画面に表示する。

なお、受信タスク２１は、ＤＯ２２ａ〜２２ｃからの実行結果が所定時間以上返ってこないといった異常を検出した場合は、業務プロセス１０側に、異常報告をするものとしても良い。

以上のように、本実施例では、３つの実行要求及び３つの受付応答及び業務プロセス１０が要求した２つの実行結果をまとめて送受信することにより、プロセス間通信システムにおけるプロセス間通信の回数を抑制することができる。通信回数が抑制されることにより、取引性能を向上することが可能となる。また、本実施例では、業務ロジック１１は、送信タスク１２に対して実行結果を要求する際に、実行結果を論理式形式で指定しており、実行結果の詳細な指定が可能である。更に、本実施例では、ユーザからのカードや通帳の挿入など、業務プロセス１０が処理に必要となる時間が予測困難な処理について、デバイスプロセス２０が、実行結果が揃うまで待機して、実行結果が揃ったところで実行結果を業務プロセス１０にまとめて送信する。よって、業務プロセス１０は、実行結果を繰り返し要求する必要もなく、プロセス間通信の回数を抑制することができる。また、デバイスプロセス２０のＤＯ２２ａ〜２２ｃは、並列に処理を実行するので、取引性能も向上できる。

その他の実施例：
（１）上記実施例では、プロセス間通信システムがＡＴＭ１００上に存在するものとしているが、ＡＴＭ１００に限らず、所定のコンピュータ上に存在するものとしても良い。更に、プロセス間通信システムがすべて１つのコンピュータ上に存在するものと限らず、プロセス間通信システムが複数個のコンピュータ上に分かれて存在するものとしても良い。例えば、業務プロセス１０と、デバイスプロセス２０が、異なるコンピュータ上に存在するものとしても良い。

図３は、業務プロセス１０Ａと、デバイスプロセス２０Ａとが、異なるコンピュータ上に存在している場合のプロセス間通信システムを示す説明図である。図３のプロセス間通信システムにおいては、業務プロセス１０Ａはアプリケーションサーバ２００上に存在し、デバイスプロセス２０Ａは端末３００上に存在する。そして、業務プロセス１０Ａとデバイスプロセス２０Ａは、ネットワークを介して、ＪａｖａＲＭＩ（ＲｅｍｏｔｅＭｅｔｈｏｄＩｎｖｏｃａｔｉｏｎ）又はＣＯＲＢＡ（ＣｏｍｍｏｎＯｂｊｅｃｔＲｅｑｕｅｓｔＢｒｏｋｅｒＡｒｃｈｉｔｅｃｔｕｒｅ）を用いることにより、プロセス間通信を実行する。本発明のプロセス間通信システムでは、プロセス間通信の回数が抑制されるので、業務プロセス１０Ａと、デバイスプロセス２０Ａとが、異なるコンピュータ上に存在している場合には、ネットワークの負荷を軽減することができる。ネットワークの負荷が低減されるので、ネットワーク構築のコストを低減することが可能となる。

（２）上記実施例では、業務プロセス１０と、デバイスプロセス２０がＪａｖａによりプログラミングされているものとして説明したが、これに限らず、Ｃ言語など他の言語によりプログラミングされているものとしても良い。

（３）上記実施例では、デバイスプロセス２０は、業務プロセス１０から要求された実行結果が揃うまで待機して、要求された実行結果が全て揃ってから、要求された実行結果を全てまとめて業務プロセス１０に送信しているが、これに限らず、デバイスプロセス２０は、要求された時点で登録されている実行結果を先に業務プロセス１０に送信するものとしても良い。例えば、上記した実施例では、ＤＯ２２ａの実行結果を先に業務プロセス１０に送信するものとしても良い。

（４）上記実施例では、業務プロセス１０は、複数の実行結果をまとめて要求しているが、これに限らず、１つずつ要求するものとしても良い。

（５）上記実施例では、デバイスプロセス２０は、業務プロセス１０から実行結果が要求されてから、業務プロセス１０に実行結果を送信しているが、これに限らず、デバイス処理が終了する度に、業務プロセス１０に実行結果を送信するものとしても良い。

以上、実施例に基づき本発明に係るプロセス間通信システムを説明してきたが、上記した発明の実施の形態は、本発明の理解を容易にするためのものであり、本発明を限定するものではない。本発明は、その趣旨並びに特許請求の範囲を逸脱することなく、変更、改良され得ると共に、本発明にはその等価物が含まれることはもちろんである。

ＡＴＭ１００を示すブロック図。業務プロセス１０とデバイスプロセス２０とで３つの非同期処理が実行される手順を示すシーケンス図。業務プロセス１０Ａとデバイスプロセス２０Ａが異なるコンピュータ上に存在している場合のプロセス間通信システムを示す説明図。従来の業務プロセスとデバイスプロセスで２つの非同期処理が実行される手順を示すシーケンス図。

符号の説明

１０...業務プロセス
１０Ａ...業務プロセス
１１...業務ロジック
１２...送信タスク
２０...デバイスプロセス
２０Ａ...デバイスプロセス
２１...受信タスク
２２ａ〜２２ｃ...デバイスオブジェクト
２３ａ，２３ｂ...デバイスオブジェクト
２００...アプリケーションサーバ
３００...端末

Claims

サーバ内の業務プロセスと端末内のデバイスプロセスとの間で通信して、複数の処理を実行するプロセス間通信システムであって、
前記業務プロセスは、自身の担当する処理を実行する業務ロジックと、デバイス処理の実行要求を他のプロセスに送信する第１の送受信タスクとを備え、
前記デバイスプロセスは、前記実行要求を受信する第２の送受信タスクと、各々任意の前記デバイス処理を実行する複数のデバイス処理部とを備え、
前記業務ロジックは、前記デバイス処理の実行要求を複数前記第１の送受信タスクに登録した後、登録した複数の実行要求の送信指示を前記第１の送受信タスクに送り、
前記第１の送受信タスクは、前記送信指示に応じて、登録された前記複数の実行要求をまとめて前記デバイスプロセスに送信し、
前記第２の送受信タスクは、前記複数の実行要求を受信し、個々の実行要求に応じた前記デバイス処理部を起動し、
前記デバイス処理部は、起動されるのに呼応して、前記実行要求を受け付けたことを示す受付応答を前記第２の送受信タスクに登録して、前記デバイス処理を実行し、
前記第２の送受信タスクは、前記業務プロセスから受信した前記複数の実行要求のすべてに関する前記受付応答が登録された後に、受付応答を前記業務プロセスに送信し、
前記デバイス処理部は、前記デバイス処理の実行結果を前記第２の送受信タスクに登録し、
前記業務ロジックは、前記実行要求を出した前記デバイス処理のうち、任意の複数の前記デバイス処理に関する実行結果を前記デバイスプロセスにまとめて要求し、
前記第２の送受信タスクは、要求された複数の実行結果が全て登録されていない場合、全て登録されるまで待機し、要求された全ての実行結果をまとめて送信する、
プロセス間通信システム。
請求項１記載のプロセス間通信システムであって、
前記業務ロジックは、自身の担当する処理の実行を中断して、前記デバイス処理の実行要求を複数前記第１の送受信タスクに登録した後、登録した複数の実行要求の送信指示を前記第１の送受信タスクに送り、前記デバイスプロセスから前記受付応答を受信すると、自身の担当する処理の実行を再開する、
プロセス間通信システム。
請求項１記載のプロセス間通信システムであって、
前記業務プロセスと、前記デバイスプロセスとは、コンピュータのプラットフォームに依存しないコンピュータプログラムによってそれぞれ実現されている、
プロセス間通信システム。
複数のプロセスが、通信を行ないつつ処理を実行するプロセス間通信システムにおける通信方法であって、
前記プロセス間通信システムは、
デバイス処理の実行要求を他のプロセスに送信するサーバ内の業務プロセスと、
各々が任意の前記デバイス処理を実行する複数のデバイス処理部を備え、前記実行要求を受信して前記デバイス処理を実行する端末内のデバイスプロセスと、
を備え、
前記通信方法は、
前記業務プロセスが、複数の前記デバイス処理の実行要求をまとめて前記デバイスプロセスに送信する工程と、
前記デバイスプロセスが、まとめて送信された前記実行要求を受信し、個々の実行要求に応じた前記デバイス処理部を起動する工程と、
前記デバイス処理部が、起動されるのに呼応して、前記実行要求を受け付けたことを示す受付応答を前記デバイスプロセス内に登録して、前記デバイス処理を実行する工程と、
前記デバイスプロセスが、前記業務プロセスから受信した前記複数の実行要求のすべてに関する前記受付応答が登録された後に、受付応答を前記業務プロセスに送信する工程と、
前記デバイス処理部が、前記デバイス処理の実行結果を登録する工程と、
前記業務プロセスが、前記実行要求を出した前記デバイス処理のうち、任意の複数の前記デバイス処理に関する実行結果を前記デバイスプロセスにまとめて要求する工程と、
前記デバイスプロセスが、要求された複数の実行結果が全て登録されていない場合、全て登録されるまで待機し、要求された全ての実行結果をまとめて送信する工程と、
を備える通信方法。