(57)【要約】【課題】一つのサーバに対し複数のクライアントがそれぞれ異なるデータを要求するとき、サーバは一つ一つの要求に対応するために、要求の種類だけコールバック関数を用意しなければならない。コールバック関数の種類を増やすためには、サーバとクライアントの両者でプログラムの変更が必要となり手間がかかる。クライアントの数が増えたとしても、コールバック関数の種類を増やすことなく、クライアントに要求に対応したい。【解決手段】サーバが処理結果のＩＤをあらかじめ公開し、クライアントがデータを問い合わせるためのインタフェースを一つだけ用意する。クライアントは公開されたＩＤとインタフェースを使って自ら必要なデータを必要な回数だけサーバに問い合わせる。サーバは要求されたデータのみをクライアントに渡す。【選択図】図１
2017120456.tif 000002
【特許請求の範囲】
【請求項１】
サービスの処理結果を保持する処理結果記憶部（１６０）と、
前記処理結果記憶部を解析するコールバックデータ解析部（１４０）と、
クライアントにコールバックするコールバック呼出部（１５０）を有するサーバプログラムのデータ通知方法であって、
前記コールバック呼出部が前記コールバックデータ解析部のアドレスをクライアントへのコールバックに載せてクライアントに通知し（Ｓ２０６）、
前記コールバックデータ解析部がクライアントからの要求に応じて解析結果を通知する（Ｓ４００）
サーバプログラムからクライアントアプリケーションへのデータ通知方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、サービスを提供するプログラムが、サービスを要求したアプリケーションプログラムに対し処理結果等のデータを通知するための方法に関する。
【背景技術】
【０００２】
サービスを要求したアプリケーションプログラム（クライアント）に、サービスを提供するプログラム（サーバ）が処理状況や結果を通知するための手段として、コールバックがある。コールバックは、クライアントが用意したコールバック関数をサーバが呼び出す手法であり、クライアントがコールバック関数のアドレスをサーバに通知し、そのアドレスが指し示すコールバック関数をサーバが呼び出すことで実現される。
【０００３】
特許文献１には、データベースサーバで特定のデータが更新された際に通知を受け取れるよう、アプリケーションプログラムが自身のコールバック関数をデータベース更新通知システムに登録する手段が記載されている。また、データベース更新通知システムから受け取った通知にコールバック関数アドレスが添えられていた場合、アプリケーションプログラムからそのコールバック関数を呼び出す手段についても記載されている。これは、クライアントのコールバック関数の中からまた別のコールバック関数が呼び出されることで、所定の処理を実行する例である。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特許第５６５２４８０号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
一般的にコールバック関数は通知内容ごとに異なるものを用意する必要があり、上記特許文献１の例も同様である。しかし、通常一つのサーバに対しクライアントは複数存在し、クライアントごとにサーバに異なる通知内容を要求するのは当然である。
【０００６】
例えば、複数のクライアントが同一のサーバに同じサービスを要求した場合でも、クライアントによってはサービスの処理速度を求めたり、出力物の大きさや数を求めたり、サービスを依頼した日時や、処理に失敗したサービスの依頼内容を求めたりと、要求するデータが異なる。サーバはこれらの要求一つ一つに対応するために、要求の種類だけコールバック関数を用意しなければならない。そのためクライアントは、サーバの仕様に従ってサーバが対応できる範囲内の要求しか出さない、あるいは、サーバに新たなコールバック関数に対応するようサーバの開発担当者に依頼をしなければならない。
【０００７】
後者の場合、コールバック関数の種類を増やすため、サーバ側とクライアント側の両方でプログラムの変更が必要となる。これは開発の費用、日程、技術面等を考慮すると簡単に実現できるとは限らない。そしてクライアントの数と要求が増えるに従い、すべての要求のために異なるコールバック関数を定義することは現実的でなくなる。
【０００８】
この課題を解決するため、クライアントの数が増えたとしても、コールバック関数の種類を増やすことなく、単一のコールバック関数を用いてそれぞれのクライアントに要求されたデータのみを通知する方法を提案する。
【課題を解決するための手段】
【０００９】
上記の課題を解決するために、本発明に係るデータ通知方法は、
サービスの処理結果を保持する処理結果記憶部（１６０）と、
前記処理結果記憶部を解析するコールバックデータ解析部（１４０）と、
クライアントにコールバックするコールバック呼出部（１５０）を有するサーバプログラムのデータ通知方法であって、
前記コールバック呼出部が前記コールバックデータ解析部のアドレスをクライアントへのコールバックに載せてクライアントに通知し（Ｓ２０６）、
前記コールバックデータ解析部がクライアントからの要求に応じて解析結果を通知する（Ｓ４００）
サーバプログラムからクライアントアプリケーションへのデータ通知方法である。
【発明の効果】
【００１０】
本発明に係るデータ通知方法によれば、異なる通知内容を要求する複数のクライアントに対し、それぞれの要求に応えるためのコールバック関数を新たに定義することなく、単一のコールバック関数で各クライアントに要求された内容のみを通知することができる。
【図面の簡単な説明】
【００１１】
【図１】クライアントとインプロセスサーバの構成を示す図である。
【図２】インプロセスサーバが持つ処理結果のデータテーブルを示す模式図である。
【図３】クライアントの処理フローである。
【図４】インプロセスサーバの処理フローである。
【図５】クライアントのコールバック関数の処理フローである。
【図６】特定のデータを要求された際のコールバックデータ解析部の処理フローである。
【図７】情報処理システムが動作するＰＣのハードウエア構成図である。
【発明を実施するための形態】
【００１２】
以下、本発明を実施するための形態について説明する。
【００１３】
［実施形態１］
まずは図１に、本発明であるインプロセスサーバ（１００）とクライアント（２００）の構成を示す。
【００１４】
インプロセスサーバ（１００）は、サービス要求元であるクライアントのプロセス内で動作し、クライアントにサービスを提供するプログラムである。クライアント（２００）は自身にインプロセスサーバ（１００）をロードし、インプロセスサーバ（１００）が提供するサービスを利用する、コンピュータのＯＳ上で動作するアプリケーションプログラムである。
【００１５】
インプロセスサーバ（１００）はサービス要求受付部（１１０）、サービス実行部（１２０）、コールバックデータ発行部（１３０）、コールバックデータ解析部（１４０）、コールバック呼出部（１５０）、処理結果記憶部（１６０）から成る。
【００１６】
サービス要求受付部（１１０）は、クライアント（２００）から発行されたサービス要求を受け付ける。サービス実行部（１２０）はクライアント（２００）の要求に応じたサービスを実行する。コールバックデータ発行部（１３０）はサービス実行部（１２０）から処理結果を取得し、処理結果記憶部（１６０）に記憶されたデータを更新する。処理結果記憶部（１６０）はサービスの処理結果を記憶しており、サービス実行部（１２０）が処理した結果を、例えばｘｍｌ形式のデータとして記憶している。
【００１７】
コールバックデータ解析部（１４０）は、処理結果記憶部（１６０）に記憶されたデータを解析し、解析結果から図２に示すデータテーブル（２０００）を作成して保持する。データテーブル（２０００）はサービスの処理結果の値とＩＤを結び付けて記憶するテーブルであり、詳細については後述する。コールバックデータ解析部（１４０）はクライアント（２００）に関数を一つだけ公開している。クライアント（２００）はこの関数を呼び出す際、データテーブル（２０００）の特定の値のＩＤを指定することができる。コールバックデータ解析部（１４０）は指定されたＩＤと結び付けられた値をデータテーブル（２０００）から取得しクライアント（２００）に渡す役割を担っている。
【００１８】
コールバック呼出部（１５０）はクライアント（２００）のコールバック関数呼び出す。コールバック呼出部（１５０）はクライアントへのコールバックに、コールバック解析部（１４０）を指し示すアドレスを添える。これはクライアント（２００）からコールバック解析部（１４０）にアクセスすることを可能にするためである。
【００１９】
クライアント（２００）は、少なくともサービス要求発行部（２１０）、処理部（２２０）、コールバック処理部（２３０）を持ち、図１に示すようにインプロセスサーバ（１００）をロードすることができる。サービス要求発行部（２１０）は、クライアント（２００）がロードしたインプロセスサーバ（１００）に対しサービスを要求する。処理部（２２０）はクライアントの所定の処理を実行する。そしてコールバック処理部（２３０）はインプロセスサーバ（１００）からのコールバックを実行する。
【００２０】
ここで図２に示すデータテーブル（２０００）について説明する。
【００２１】
データテーブル（２０００）は処理結果記憶部（１６０）に記憶されたデータをテーブル形式にしたものである。データテーブル（２０００）はクライアント（２００）からのサービス要求一つに対し一つ作成される。図２の各行は処理結果を示すデータを表し、上からジョブＩＤ、サービスを受け付けた日時、サービスの結果、出力ファイルの数、出力ファイルのパス、出力ファイルのタイプ、処理時間等が記録されている様子を表している。また各データは３つの情報からなり、図２では左の列から、処理結果のＩＤ、インデックス、値が表されている。
【００２２】
クライアント（２００）にはあらかじめ処理結果のＩＤが提供されており、クライアント（２００）は興味のある処理結果のＩＤをインプロセスサーバ（１００）に提示しデータを要求することができる。また、図２では「ＯｕｔｐｕｔＰａｔｈ（出力ファイルパス）」と「ＯｕｔｐｕｔＴｙｐｅ（出力ファイルタイプ）」が２つずつ存在するが、同じＩＤの出力結果が存在する場合はそれらを区別するため、データテーブル（２０００）作成時にインデックスが割り当てられる。インデックスを割り当てられたデータを要求する場合、クライアント（２００）はインプロセスサーバ（１００）に対し処理結果のＩＤとインデックスの両方を提示する必要がある。インデックスの最大値を求める必要があるときは、クライアント（２００）はインプロセスサーバ（１００）に「Ｏｕｔｐｕｔｓ（出力ファイルの数）」を問い合わせればよい。
【００２３】
続いて、クライアント（２００）とインプロセスサーバ（１００）の処理フローについて説明する。
【００２４】
図３に、インプロセスサーバ（１００）をロードしたクライアント（２００）の処理フローを示す。
【００２５】
クライアント（２００）は所定の処理を処理部（２２０）で実行するが、インプロセスサーバ（１００）が提供するサービスが必要になるとサービス要求発行部（２１０）からインプロセスサーバ（１００）に対しサービスを要求する（Ｓ１０１）。このとき、サービス要求発行部（２１０）はコールバック処理部（２３０）のアドレスをサービス要求に載せてインプロセスサーバ（１００）に通知する。インプロセスサーバ（１００）の処理が完了するとコールバック処理部（２３０）がインプロセスサーバ（１００）から呼び出されるので、クライアント（２００）はコールバック処理部（２３０）でコールバックの処理を実行する（Ｓ１０２、Ｓ３００）。
【００２６】
図４にはインプロセスサーバ（１００）の処理フローを示す。
【００２７】
インプロセスサーバ（１００）はサービス要求受付部（１１０）でクライアント（２００）のサービス要求発行部（２１０）からサービス要求を受ける（Ｓ２０１）。
【００２８】
サービス要求にはクライアント（２００）のコールバック処理部（２３０）のアドレスが添えられているので、インプロセスサーバ（１００）はこれを記憶する。
【００２９】
次にインプロセスサーバ（１００）はコールバックデータ発行部（１３０）でサービスの処理結果を記憶するための処理結果記憶部（１６０）を作成する（Ｓ２０２）。例えば、処理結果記憶部（１６０）がｘｍｌ形式で処理結果を記憶する場合、まずは受け付けたサービスに関する情報（要求の内容や日時）をｘｍｌ形式に加工したデータを作成する。
【００３０】
続いてインプロセスサーバ（１００）はサービス実行部（１２０）でサービス要求に応じてサービスを実行し、コールバックデータ発行部（１３０）によって処理結果記憶部（１６０）に記憶されたデータを更新する（Ｓ２０３、Ｓ２０４）。処理結果記憶部（１６０）では処理結果として新たなデータが追記されたり、既存のデータが上書きされたりする。
【００３１】
処理結果記憶部（１６０）が更新されると、インプロセスサーバ（１００）はコールバックデータ解析部（１４０）で、処理結果記憶部（１６０）に記憶された処理結果のデータを解析し、解析したデータを自身で保持する。例えば処理結果記憶部（１６０）がｘｍｌ形式で処理結果を記憶している場合は、コールバックデータ解析部（１４０）はｘｍｌを解析し、データテーブル（２０００）を作成して保持する。
【００３２】
コールバック解析部（１４０）での解析が完了すると、コールバック呼出部（１５０）が、Ｓ２０１で受け取ったクライアント（２００）のコールバック処理部（２３０）のアドレスに対し、コールバックする（Ｓ２０６）。このときコールバック呼出部（１５０）はコールバックデータ解析部（１４０）のアドレスをコールバックの呼出しに載せる。これにより、クライアント（２００）のコールバック処理部（２３０）はインプロセスサーバ（１００）のデータテーブル（２０００）を保持したコールバック解析部（１４０）にアクセスすることが可能となる。
【００３３】
クライアント（２００）はコールバック処理部（２３０）からコールバック解析部（１４０）にサービスの処理結果を問い合わせ、必要なデータのみを取得することができる。
【００３４】
図５はコールバック処理部（２３０）がコールバック呼出部（１５０）から呼び出されたときの処理フローである。
【００３５】
コールバック処理部（２３０）はインプロセスサーバ（１００）のコールバック解析部（１４０）が公開している唯一つの関数に興味のあるデータのＩＤを渡し、データテーブル（２０００）にＩＤと結びつけて記憶された処理結果を要求し、値を取得する（Ｓ３０１、Ｓ３０２）。コールバック処理部（２３０）はデータのＩＤを変更しながらＳ３０１とＳ３０２を繰り返し、必要な値をインプロセスサーバ（１００）から取得する（Ｓ３０３）。コールバック処理部（２３０）は必要な値がそろうと、取得した値を使って所定の処理を実行する（Ｓ３０４）。
【００３６】
図６に、コールバック処理部（２３０）からデータのＩＤを渡されたときのコールバックデータ解析部（１４０）の処理フローを示す。
【００３７】
インプロセスサーバ（１００）のコールバックデータ解析部（１４０）はクライアント（２００）からデータのＩＤを受け取ると、データテーブル（２０００）からＩＤと結びついた値を取得し、その値をクライアント（２００）に返す（Ｓ４０１、Ｓ４０２、Ｓ４０３）。
【００３８】
このように本発明ではインプロセスサーバ（１００）が、処理結果のＩＤをあらかじめ公開し、クライアント（２００）がデータを問い合わせるための唯一つのインタフェースをコールバックに載せてクライアント（２００）に通知する。クライアント（２００）は公開されたＩＤと通知されたインタフェースを使って自ら必要なデータをインプロセスサーバ（１００）に問い合わせることができ、インプロセスサーバ（１００）は要求されたデータをクライアント（２００）に渡すことができる。これにより、インプロセスサーバ（１００）に対して異なるデータを要求するクライアントが複数存在する場合でも、インプロセスサーバ（１００）はクライアントごとに異なるコールバック関数を用意する必要がなくなった。つまり、異なるデータを要求するクライアントが今後増えたとしても、インプロセスサーバ（１００）はコールバック関数の種類を増やすことなく、クライアントに要求されたデータを的確に渡すことができる。
【００３９】
また本実施形態では、インプロセスサーバ（１００）でのサービスが完了したらクライアント（２００）へのコールバックを実施する例を示したが、インプロセスサーバ（１００）はサービスの途中結果をクライアント（２００）に通知することも可能である。
【００４０】
最後にインプロセスサーバ（１００）とクライアント（２００）が動作するコンピュータのハードウエア構成図を図７に示す。
【００４１】
インプロセスサーバ（１００）とクライアント（２００）はＨＤＤ（１００２）あるいはＲＯＭ（１００３）に格納されている。ＣＰＵ（１００５）がＯＳとアプリケーションプログラムをＨＤＤ（１００２）あるいはＲＯＭ（１００３）から読み出してＲＡＭ（１００４）にロードし実行する。処理結果はファイルとしてＨＤＤ（１００２）に格納、あるいはデータとしてＲＡＭ（１００４）に記憶される。アプリケーションプログラムはコンピュータに接続されている入力装置（１００７）からユーザーの入力、各種センサの読み取り値を取得する。出力装置（１００６）に対しては情報を出力し、処理結果を表示する。さらに、通信装置（１００８）を介してネットワークに接続された他のコンピュータや装置と通信を行う。これらのハードウエアはバス（１００１）で互いに接続されていてアプリケーションプログラムから操作できるように構成されている。
【符号の説明】
【００４２】
１００  インプロセスサーバ、１４０  コールバックデータ解析部、
１５０  コールバック呼出部、１６０  処理結果記憶部、２００  クライアント、
２３０  コールバック処理部、２０００  データテーブル
【図１】
2017120456.tif 000003
【図２】
2017120456.tif 000004
【図３】
2017120456.tif 000005
【図４】
2017120456.tif 000006
【図５】
2017120456.tif 000007
【図６】
2017120456.tif 000008
【図７】
2017120456.tif 000009