JPH10289171A - プログラム間連携システム - Google Patents

Abstract

(57)【要約】 【課題】 本発明は、セションの継続形態が異なるプロ
グラム間を連携するシステムの提供を目的とする。 【解決手段】 コネクションレス型の通信を行うユーザ
１１とコネクション型の通信を行うメインフレーム２２
との間にサービスシステム１２を設け、これを介して連
携処理を行う。サービスシステム１２では、ユーザ１１
に対しては１回のセション毎に生成、消滅する処理プロ
セス１３を、メインフレーム２２に対しては常駐して回
線を保持する通信プロセス１５を生成し、この処理プロ
セス１３と通信プロセス１５との間でデータの送受信を
することによって連携処理を実現する。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、プログラム間のデ
ータの送受信の連携を行うプログラム間連携システムに
関するものである。

【０００２】

【従来の技術】現在、インターネットの急速に普及に伴
い、ＷＷＷサーバとメインフレーム（ホスト）との連携
が要求されている。

【０００３】一般にＷＷＷブラウザが用いるＨＴＴＰ
（Hyper Text Transfer Protocol）による通信はコネク
ションレスであるため、そのセションは、ブラウザがペ
ージを要求する時に設定され、サーバがそのページを送
信すると切れてしまう。従って次の画面にアクセスした
場合は別のセションが設定され、前の通信との関連性が
保存されない。

【０００４】このためユーザがＷＷＷブラウザを介して
ＷＷＷサーバにアクセスしたとき、ＷＷＷサーバから起
動されたプログラムがユーザの要求を受け付けて処理を
行い、その結果をユーザに返すが、このプログラムとユ
ーザとのセションは、１往復のやり取りで切れてしま
う。

【０００５】一方、メインフレームをサーバとするクラ
イアント・サーバシステムでは、通常ユーザ（クライア
ント）は一度ログインし接続を行うと、そのサーバとの
セションを張ったままの状態で種々な処理を連続して実
行できる。

【０００６】そこで、ＷＷＷサーバとメインフレームと
を連携させるためには、ユーザがアクセスしたときにＷ
ＷＷサーバから起動された特定プログラムと、メインフ
レームをサーバとしたときのクライアント側のプログラ
ムとを連携させ、その間の接続状態を維持する機能が要
求される。

【０００７】従来のプログラム間連携システムは、クラ
イアント（サービスを要求し、受け取るプログラム）が
要求を発行すると、サーバ（サービスを提供するプログ
ラム）でそれに対応した処理を実行して応答を返すよう
な、一度の要求・応答でクライアントとサーバの処理と
接続が完結する図１２（ａ）に示すコネクションレス型
の方式と、クライアントがサーバに一度接続すると、ク
ライアントがサーバに終了を要求するまで、種々な処理
の要求と応答を繰り返すことができるようにその接続状
態を継続する図１２（ｂ）に示すコネクション型の方式
とがある。

【０００８】前者の図１２（ａ）の方式は、クライアン
トプロセス１０１が要求を発行すると、それに応じた処
理をサーバプロセス１０２が行い、その結果を返す。こ
の処理が終わると接続状態が切れる。

【０００９】後者の図１２（ｂ）の方式は、クライアン
トプロセス１０３が最初に要求を発行したときに、サー
バプロセス１０４に接続し、その後、数回の要求・応答
を繰り返した後、クライアントプロセス１０３からの切
断要求により接続が切れる。

【００１０】また、従来のプログラム間通信システムに
おけるプロセスの生成方法は、図１２（ｃ）に示すよう
に、親サーバが１つのクライアントプロセスに対して１
つのサーバプロセスを生成し、１対１で通信するように
している。

【００１１】

【発明が解決しようとする課題】上述した従来のプログ
ラム間通信システムは、図１２（ａ）に示すような１度
の要求・応答のみでセション接続状態が完了してしまう
プログラムと、図１２（ｂ）に示すようなセション接続
状態を継続して要求・応答を繰り返すプログラムとを連
携させることができないという問題があった。

【００１２】また、プロセス生成方法については、上記
図１２（ａ）の方式を使用してクライアントプロセスが
一度終了したあと、再びサーバプロセスと通信するため
には、再度サーバプロセスへ接続要求を出すというよう
に、アクセスを行う度に接続要求を出すという煩雑な処
理が要求されるという問題があった。

【００１３】本発明は、上記問題を鑑み、セション継続
形態が異なるプログラム間の連携を実現するプログラム
間連携システム及び連携方法を提供することを目的とす
る。

【００１４】

【課題を解決するための手段】図１は本発明の原理図で
ある。本発明に於けるプログラム間連携システムは、コ
ネクションレス型の通信を行う第１の情報処理装置１上
のプログラムとコネクション型の通信を行う第２の情報
処理装置６上のプログラムとの連携を行うことを前提と
し、処理プロセス生成手段及び通信プロセス生成手段を
備える。

【００１５】処理プロセス生成手段３は、上記第１の情
報処理装置１よりデータを受信した時、上記データに付
加された送信元を一意に識別するユーザＩＤに対応させ
て、上記第１の情報処理装置１との通信を行う処理プロ
セス２を生成する。

【００１６】通信プロセス生成手段４は、上記処理プロ
セス２からの指示により、上記ユーザＩＤに対応し、上
記データにより指示された上記第２の情報処理装置６と
の通信を行う、通信プロセス５を生成する。

【００１７】処理プロセス２と通信プロセス５との間の
通信は、例えばユーザファイルを用いて行われる。この
場合、処理プロセス２は、上記ユーザＩＤに対応するユ
ーザファイルが存在するかどうかを調べ、存在する場合
には該ユーザファイルに第１の情報処理装置１から受信
したデータを書込み、存在しない場合には通信プロセス
生成手段４に通信プロセス５の生成を依頼すると共に上
記ユーザＩＤに対応するユーザファイルを生成し、該ユ
ーザファイルに第１の情報処理装置１から受信したデー
タを書込む。通信プロセス５は、自己が対応するユーザ
ＩＤと同じユーザＩＤに対応するユーザファイルより処
理プロセス２が書込んだデータを読みだすとともに第２
の情報処理装置６に対して送信し、該第２の情報処理装
置６から受信した処理結果を上記ユーザファイルに書込
み、該書込んだ処理結果を処理プロセス２がユーザファ
イルから読み出す。

【００１８】あるいは本システムは、キューを更に備
え、処理プロセス２と通信プロセス５との間のデータの
授受は上記キューを介して行う。また本発明は、コネク
ションレス型の通信を行う第１の情報処理装置１上のプ
ログラムとコネクション型の通信を行う第２の情報処理
装置６上のプログラムとのプログラム間連携方法も含
む。

【００１９】この場合、第１の情報処理装置１よりデー
タを受信した時、上記データに付加された送信元を一意
に識別するユーザＩＤに対応させて、第１の情報処理装
置１との通信を行う処理プロセス２を生成し、該処理プ
ロセス２からの指示により、前記ユーザＩＤに対応し、
上記データにより指示された前記第２の情報処理装置６
との通信を行う、通信プロセス５を生成する。そして処
理プロセス２は、上記第１情報処理装置１上のプログラ
ムとコネクションレス型通信を行い、通信プロセス５は
第２の情報処理装置６上のプログラムとコネクション型
通信を行い、処理プロセス２と通信プロセス５との間で
データの授受を行うことにより上記プログラム間の連携
を行う。この処理プロセス２と前記通信プロセス５との
間のデータの授受は、例えば名前付きパイプによって、
あるいはキューを生成し、該キューを用いて実現され
る。

【００２０】本発明によれば、コネクションレス型の通
信を行う第１の情報処理装置１に対しては処理プロセス
２が生成され、コネクション型の通信を行う第２の情報
処理装置６に対しては通信プロセス５が生成される。そ
してこの処理プロセス２と通信プロセス６との間でデー
タの授受を行うことにより第１の情報処理装置１上のプ
ログラムと第２の情報処理装置６上のプログラムとの間
の連携を実現する。

【００２１】

【発明の実施の形態】図２を参照して本発明の動作原理
を説明する。図２は本実施形態に於けるシステムのブロ
ック図である。図２において、ユーザ１１は、サービス
の要求を行うプログラムやＷＷＷブラウザなどの第１の
プログラム２３によって動作しコネクションレスな通信
を行う、例えばネットワーク端末である。

【００２２】メインフレーム２２は、ユーザ１１から送
信されるデータによって選出され、ユーザ１１からの要
求、例えばデータベース処理等を第２のプログラム２４
によって処理するもので、コネクション型の通信を行う
情報処理装置である。

【００２３】サービスシステム１２は、本発明において
ユーザ１１の第１のプログラム２３とメインフレーム２
４の第２のプログラム２４を連携処理させるためにユー
ザ１１とメインフレーム２２の間に設けられるものであ
って、ユーザ１１とメインフレーム２２はこのサービス
システム１２を介して互いに通信を行う。

【００２４】このサービスシステム１２は、図３（ａ）
に示す様に、処理付加軽減のためユーザ１１やメインフ
レーム２２とは別の情報処理装置２５上に設ける構成に
も、あるいは図３（ｂ）に示す様にメインフレーム２２
上に設ける構成にすることも出来る。

【００２５】またサービスシステム１２は、メインフレ
ーム２２に対して１対１に構成することも、１つのサー
ビスシステム１２で複数のメインフレーム２２との接続
を請け負う構成にすることも可能である。

【００２６】サービスシステム１２は、ユーザ１１から
のサービス要求に応答するものであって、ここでは、ユ
ーザ１１とメインフレーム２２との間でデータの授受を
行うためのものである。サービスシステム１２は、処理
プロセス１３、管理プロセス１４、および通信プロセス
１５などから構成されている。

【００２７】処理プロセス１３は、ユーザ１１との接続
を受け持つもので、ユーザ１１から送信された要求（デ
ータ）を受信したときに、例えばＯＳが持つプロセス生
成機能によって生成、起動され、管理プロセス１４に依
頼して通信プロセス１５を生成・起動したり、結果をユ
ーザ１１に応答した後終了、消滅するものである。

【００２８】管理プロセス１４は、処理プロセス１３か
らの依頼に対応して通信プロセス１５を生成・起動など
をするものである。また管理プロセス１４は、通信プロ
セス１５の負荷を軽減するために通信プロセス１５が必
要な情報のメモリ上へのロード等を受け持つ。これは、
例えば負荷が大きい、タイマ監視の時間やメインフレー
ム２２が維持できるユーザの数などの環境定義ファイル
やシステム情報など通信プロセス１５が必要な情報のロ
ード等を受け持ち、通信プロセス１５の負荷を軽減させ
る等のための処理である。

【００２９】通信プロセス１５は、メインフレーム２２
との接続を受け持つもので各ユーザに対応して生成さ
れ、ユーザを一意に識別するユーザＩＤによって管理さ
れる。通信プロセス１５は、処理プロセス１３からの要
求（データ）を受信してメインフレーム２２に送信し、
メインフレーム２２からの応答（データ）を処理プロセ
ス１３へ返信する等の処理を行う。また、終了要求が出
されるまで常駐し、メインフレーム２２との接続を維持
する。

【００３０】処理プロセス１３内の相手プログラム特定
部１６は、ユーザ１１からの要求（データ）を受信した
ときに当該要求（データ）としてユーザＩＤが与えられ
る場合、あるいは要求（データ）中にユーザＩＤが埋め
込まれている場合、このユーザＩＤを識別子とするユー
ザファイルが作成済みか否かを検索する。この検索結果
作成済みのときはそのユーザファイルを作成する必要が
ないので同期部１９に処理を渡す。また、作成済みでな
いときはプログラム作成依頼部１７に作成依頼を管理プ
ロセス１４に通知してもらう処理を行う。

【００３１】プログラム作成依頼部１７は、受信した要
求（データ）のユーザＩＤを識別子として持つユーザフ
ァイルが見つからなかった場合、管理プロセス１４に通
信プロセス１５の生成・起動を依頼したり、ユーザファ
イルを作成する等の処理を行う。

【００３２】セション継続監視部１８は、ユーザ１１と
のセションを監視するものである。セション継続監視部
１８は、例えばユーザファイルへのポーリングの結果か
ら、所定期間内に処理プロセス１３によるユーザファイ
ルへの書き込みが行われたか否かを監視することによ
り、ユーザ１１とのセションの監視を行う。

【００３３】同期部１９は、ユーザファイルをポーリン
グして、通信プロセス１５あるいは処理プロセス１３に
よるユーザファイルへの書き込みが行われたかを監視す
る。このポーリングの実現方法としては、例えば一定期
間毎にファイルを読み出す、フラグを用いる等様々な方
法が考えられる。

【００３４】通信部２０は、処理プロセス１３と通信プ
ロセス１５との間でデータの受け渡しを行うためのもの
で、ここではユーザファイルを介してデータの受け渡し
を行うものである。

【００３５】終了通知部２１は、ユーザ１１からの終了
要求に対して連携処理の終了のための処理を行うもので
ある。次にユーザ１１とメインフレーム２２が、サービ
スシステム１２を介して連携処理を行った時の概略動作
を説明する。

【００３６】サービスシステム１２が、第１のプログラ
ムからのデータを受信すると、処理プロセス１３が生成
される。このユーザ１１からのデータには各ユーザ１１
を一意に識別するユーザＩＤが付加されており、処理プ
ロセス１３はこのユーザＩＤによって、受信データがユ
ーザ１１から送信される最初のデータであるかどうかを
調べる。その結果最初のデータであるならば、管理プロ
セス１４はこのユーザＩＤに関連づけて通信プロセス１
５を生成する。そして、ユーザ１１からのデータをこの
通信プロセス１５に渡す。また受信データが最初のデー
タでなければ、このユーザＩＤに対する通信プロセス１
５は既に生成されているので、ユーザ１１からのデータ
をこの通信プロセス１５に渡す。

【００３７】この処理プロセス１３と通信プロセス１５
との間の通信は、例えばＵＮＩＸやＷｉｎｄｏｗｓ Ｎ
Ｔなどで用いられる名前付きパイプによって実現され
る。この場合、処理プロセス１３はユーザ１１からデー
タを受け取ると、そのユーザＩＤに対応したユーザファ
イル、例えばユーザＩＤに基づいたファイル名を持つユ
ーザファイルが存在するかどうかによりそのデータがユ
ーザ１１からの最初のデータであるかどうかを判断す
る。その結果最初のデータであるならば、上述した管理
プロセス１４への通信プロセス１５の生成依頼を行うと
共に、そのユーザＩＤに対応したファイル名を持つユー
ザファイルを生成する。以降このユーザＩＤが付加され
たデータは、このユーザファイルを介して処理プロセス
１３から通信プロセス１５に送られ、またその処理結果
をこのユーザファイルを介して通信プロセス１５より処
理プロセス１３が受け取る。

【００３８】例えば、ユーザ１１から受け取ったデータ
を処理プロセス１３はそのデータに付加されているユー
ザＩＤに対応したユーザファイルに格納する。すると通
信プロセス１５は、このユーザファイルよりデータを取
りだし、メインフレーム２２に送信する。その後処理結
果をメインフレーム２２から受け取ると、通信プロセス
１５はそれを対応するユーザファイル内に格納する。そ
して処理プロセス１３は、この処理結果をユーザファイ
ルから取り出し、ユーザ１１に送信する。

【００３９】このユーザファイルを用いた名前付きパイ
プによる処理プロセス１３と通信プロセス１５との間の
データのやり取りでは、通信プロセス１５または処理プ
ロセス１３が、ユーザファイルにデータの書き込みを行
ったか否かをユーザファイルに対してポーリングするこ
とによって判定している。

【００４０】また、通信プロセス１５はユーザファイル
にデータが書き込まれているか否かをポーリングし、一
定時間経過してもユーザファイルに処理プロセス１３か
らデータが書き込まれなかった場合には、エラー処理を
行う。

【００４１】このエラー処理としては、例えばユーザ１
１の第１のプログラムに対して、データの再度送信を要
求する、あるいは連携処理を終了しメインフレーム２２
との通信を中止するかを問い合わせるなどが考えられ
る。通信を中止する場合には、通信プロセス１５は終了
・消滅する。

【００４２】また処理プロセス１３と通信プロセス１５
との間の通信は、キューを設けることによっても実現で
きる。この場合サービスシステム１２では、受け取った
データを通信プロセス１５によりメインフレーム２２の
第２のプログラムに渡し、メインフレーム２２にこのデ
ータに対する処理を行わせている間に次のデータをユー
ザ１１から受け取り、このデータもメインフレーム２２
に渡し、２つのデータに対する処理を並列に行わせるこ
とも可能である。

【００４３】また、通信プロセス１５は、受信するデー
タが多く負荷が多くなった場合に、ユーザ１１に負荷軽
減を問い合わせる機能を備えている。この様に本システ
ムによれば、セション継続状態が異なるプログラム間
（第１のプログラムと第２のプログラム間）を連携し、
かつ効率的にプロセス生成を実現するシステムを構築す
ることが可能となる。

【００４４】次に、図４から図１２を用いて本発明の実
施の形態および動作を順次詳細に説明する。まず、図２
のプログラム作成依頼部１７、セション継続監視部１
８、同期部１９、通信部２０によって、通信する場合を
図４を用いて模式的に説明する。

【００４５】図４は、一実施形態としてシステムを名前
付きパイプにより実現した場合の構成を示す図である。
図４において、ＷＷＷブラウザ４０は、ユーザ３１内の
第１のプログラムに対応するもので、インターネットで
使用されるＷＷＷブラウザ（プログラム）である。

【００４６】ＷＷＷサーバ４１は、ＷＷＷブラウザ４０
からの要求に対応して、サービスを提供するものであっ
て、インターネットで使用されるＷＷＷサーバ（プログ
ラム）である。

【００４７】第２のプログラム４４は、メインフレーム
３２中で各種サービスを実際に提供する処理を行うプロ
グラムである。ＷＷＷブラウザ４０とサービスシステム
３２のＷＷＷサーバ４１との間のセションは１回のアク
セス毎に切断される。そして、各アクセス毎にその接続
を受け持つ処理プロセス３３が生成され、アクセスが終
了すると処理プロセス３３も終了・消滅する。

【００４８】またサービスシステム３２とメインフレー
ム４２とのセションは通信プロセス３５が受け持つ。こ
の通信プロセス３５はユーザ３１とメインフレーム４２
との間の連携処理が終了し、ユーザ３１より終了要求が
送られてくるか、あるいはエラーによる切断処理が実行
されるまでサービスシステム３２内に常駐してメインフ
レーム４２との接続を維持する。

【００４９】次に、動作を詳細に説明する。図４におい
て、まずＳ１０１として、ＷＷＷブラウザ４０がサービ
スシステム３２を構成する処理プロセス３３に接続して
サービスの要求を送信する。

【００５０】処理プロセス３３は、Ｓ１０２としてプロ
グラム作成依頼部によって通信プロセス３５の生成・起
動依頼を管理プロセス３４に通知する。Ｓ１０３で管理
プロセス３４は、Ｓ１０２での通知に対応して、通信プ
ロセス３５を生成・起動する。

【００５１】Ｓ１０４、Ｓ１０５では、同期部がポーリ
ングを行い、処理プロセス３３によってユーザファイル
４３に要求が書き込まれたか判別する。またＳ１０６で
通信プロセス３５中のセション継続監視部が、同期部に
よるポーリングの結果から、処理プロセス３３によりユ
ーザファイル４３にＷＷＷブラウザ４０からの要求（デ
ータ）の書込みが所定時間内に行われるか監視する。そ
してユーザファイル４３への書込みが行われずに所定時
間経過したときは、セション継続監視識別部はユーザ３
１との通信は終了したと判断し通信プロセス３５を終了
させる。

【００５２】Ｓ１０７、Ｓ１０８は、処理プロセス３３
の通信部がユーザファイル４３に要求を書き込み（Ｓ１
０７）、これを同期部１９が検出すると通信プロセス３
５の通信部が書込まれた要求をユーザファイル４３から
読み出す（Ｓ１０８）。これにより処理プロセス３３か
ら通信プロセス３５に要求が送信される。

【００５３】Ｓ１０９は、通信プロセス３５がメインフ
レーム４２にサービス処理の要求を送信する。Ｓ１１０
は、メインフレーム４２の第２のプログラムがユーザ３
１によるサービス処理に対する応答としてその処理結果
を通信プロセス３５に返す。

【００５４】Ｓ１１１、Ｓ１１２は、同期部がポーリン
グによってユーザファイル４３に書き込みが行われたか
を判別する。Ｓ１１３、Ｓ１１４は、通信プロセス３５
の通信部がユーザファイル４３にメインフレーム４２か
ら受取った処理結果を書き込み（Ｓ１１３）、それを同
期部が検知すると処理プロセス３３の通信部が書込まれ
た処理結果をユーザファイル４３から読み出す（Ｓ１１
４）。これにより通信プロセス３５から処理プロセス３
３に応答が送信される。

【００５５】Ｓ１１５は、処理プロセス３３が処理結果
を応答としてユーザ３１にを返し、終了する。Ｓ１１６
は、ＷＷＷブラウザ４０が処理を終了する。

【００５６】以上のＳ１０１からＳ１１６に示したよう
に、処理プロセス３３はＷＷＷブラウザ４０と１対１の
送受信を１回行うと処理を終了し、消滅する。また、通
信プロセス３５はメインフレーム４２の第２のプログラ
ム４４と１対１の送受信を１回行うと、サービスシステ
ム３３内に常駐し、待機する。

【００５７】以降ＷＷＷブラウザ４０より新たな要求を
受信する毎に、サービスシステム３２では処理プロセス
３３が生成される。そして処理プロセス３３は、ＷＷＷ
ブラウザ４０からの要求を、サービスシステム３２内に
常駐してメインフレーム４２とのセションを保っている
通信プロセス３５に送り、メインフレーム４２にこの要
求に対する処理を依頼する。

【００５８】また処理プロセス３３は、ＷＷＷブラウザ
４０からの要求に対する処理を全てメインフレーム４２
に依頼するのではなく、例えばＷＷＷブラウザ４０から
の要求に対する処理がＷＷＷブラウザ４０へのエラー通
知等、自己で対処できるものであった場合は、その要求
を通信プロセス３５には送信せず、自己によって処理
し、その結果をＷＷＷブラウザ４０に返答する。

【００５９】通信プロセス３５は、ユーザ３１より終了
要求が通知され、ユーザ３１とメインフレーム４２との
通信が終了するか、あるいは自己のセション継続監視部
によって通信が終了したと判断されるまで、サービスシ
ステム３２内に常駐してメインフレーム４２とのセショ
ンを保つ。そして、自己が対応するユーザ３１のユーザ
ＩＤに対応したファイル名をもつユーザファイル４３
を、同期部によってポーリングして処理プロセス３３か
らデータが送信されてくるのを監視する。そして処理プ
ロセス３３によってユーザファイル４３に書込みが行わ
れると、これを通信部により読み出した後メインフレー
ム４２へ送信する。

【００６０】この様にして、本実施形態に於けるサービ
スシステム３２はユーザ３１とメインフレーム４２との
連携処理を実現する。ＷＷＷブラウザ４０と第２のプロ
グラム４４との連携処理が完了し、ログオフする時は、
ユーザ３１より終了要求が送信される。以下のＳ１２１
からＳ１３５までは、その時の動作を示す。

【００６１】ユーザ３１は、メインフレーム４２からロ
グオフする時終了要求を発行し、サービスシステム３２
を介してメインフレーム４２に送信する。Ｓ１２１で
は、ＷＷＷブラウザ４０がサービスシステム３２を構成
する処理プロセス３３に接続してこの要求（終了要求）
を送信する。

【００６２】Ｓ１２２は、処理プロセス３３の相手プロ
グラム特定部によって受信した要求に埋め込まれている
ＩＤに対応するユーザファイル４３を、ここではＳ１０
２で作成したユーザファイル４３を見つける。そして、
Ｓ１２３、Ｓ１２４に進む。

【００６３】Ｓ１２３、Ｓ１２４は、同期部がポーリン
グを行い、処理プロセス３３によってユーザファイル４
３に要求が書き込まれたか判別する。Ｓ１２５は、通信
プロセス３５中のセション継続監視部が同期部によるポ
ーリングの結果から、処理プロセス３３によりユーザフ
ァイル４３にＷＷＷブラウザ４０からの要求（データ）
が所定時間内に書き込まれるか監視する。その結果ユー
ザファイル４３への書込みが行われずに所定時間経過し
たときは、セション継続監視部はユーザ３１との通信は
終了したと判断し通信プロセス３５を終了させる。

【００６４】Ｓ１２６、Ｓ１２７は、処理プロセス３３
の通信部がユーザファイル４３に要求を書き込み（Ｓ１
２６）、これを同期部が検知すると通信プロセス３５の
通信部が書込まれた要求をユーザファイル４３から読み
出す（Ｓ１２７）。これにより処理プロセス３３から通
信プロセス３５に要求が送信される。

【００６５】Ｓ１２８は、通信プロセス３５がメインフ
レーム４２に要求を送信する。Ｓ１２９は、メインフレ
ーム４２の第２のプログラムがその要求に対する応答と
して処理結果（この場合は要求が終了要求なので終了処
理結果）を通信プロセス３５に返す。

【００６６】Ｓ１３０、Ｓ１３１は、同期部がポーリン
グによってユーザファイル４３に要求の書き込みが行わ
れたか判別する。Ｓ１３２、Ｓ１３３は、通信プロセス
３５の通信部がユーザファイル４３にメインフレーム４
２からの処理結果を書き込む（Ｓ１３２）。これを同期
部が検知すると、処理プロセス３３の通信部が書込まれ
た処理結果をユーザファイル４３から読み出す（Ｓ１３
３）。これにより通信プロセス３５から処理プロセス３
３に応答が送信される。

【００６７】Ｓ１３４は、通信プロセス３５が処理を終
了する。Ｓ１３５は、処理プロセスが応答をＷＷＷブラ
ウザ４０に返し、終了する。Ｓ１３６は、ＷＷＷブラウ
ザ４０が処理を終了する。

【００６８】以上のＳ１２１からＳ１３６で処理プロセ
ス３３は、ＷＷＷブラウザ４０と１対１の送受信を１回
行うと処理を終了し、消滅する。また通信プロセス３５
は、メインフレーム４２の第２のプログラム４４との送
受信を行った後終了、消滅する。

【００６９】次に、図５、６、７を用いて図４の構成で
動作を更に詳細に説明する。図５は、ユーザ認証時の動
作フローチャートである。この図５のフローチャート
は、ユーザ３１がメインフレーム４２と連携処理を行う
にあたり、ユーザ３１が最初の認証要求をメインフレー
ム４２に通知して認証処理を行うときの一連の手順であ
る。ここで、ユーザ３１、サービスシステム３２、処理
プロセス３３、管理プロセス３４、通信プロセス３５及
びメインフレーム４２は、図４のそれぞれに対応するも
のである。

【００７０】図５において、認証処理が開始されると、
まずステップＳ１は、ユーザＩＤ、パスワードが入力さ
れる。続いてステップＳ２として、ユーザＩＤ、パスワ
ードと共に認証要求を送信する。

【００７１】ステップＳ３は、サービスシステム３２の
処理プロセス３３がステップＳ２で送信された認証要
求、ユーザＩＤ、パスワードを受信する。ステップＳ４
は、ユーザファイルに認証要求と共に送信されたユーザ
ＩＤに対応するファイル名を持ったユーザファイル４３
が存在するか調べる。ここでは、認証要求であるので存
在せず（Ｓ４、なし）、ステップＳ５に進む。また、も
しここで存在すれば（Ｓ４、あり）、エラーとなる（最
初の接続であって、ユーザファイル４３が作成されてい
ないので、ありの場合にはエラーとなる。）。

【００７２】ステップＳ５は、処理プロセス３３がユー
ザ３１のユーザＩＤのファイル名を持つユーザファイル
４３を作成する。ステップＳ６は、ユーザ３１のユーザ
ＩＤと共に通信プロセス３５の生成依頼を管理プロセス
３４に通知する。

【００７３】ステップＳ７は、管理プロセス３４がユー
ザＩＤに対応する通信プロセス３５の生成・起動を行
う。ステップＳ８は、処理プロセス３３が認証要求をユ
ーザＩＤ、パスワードと共にユーザファイル４３に書込
む。

【００７４】ステップＳ９は、対応するユーザファイル
４３に処理プロセス３３からの認証要求が書込まれる。
生成・起動後、通信プロセス３５は、ステップＳ１０と
して対応するユーザファイル４３のポーリングを行い、
処理プロセス３３からユーザファイル４３への書込みが
あったかを調べる。ステップＳ１０で書込みがありの場
合には、ユーザファイル４３に認証要求が書き込まれて
いると判明したので、ステップＳ１１に進む。ステップ
Ｓ１０で書込みがなしの場合には、ユーザファイル４３
に要求（データ）が書き込まれるまで待機し、ステップ
Ｓ１２で所定時間経過したかを監視する。ステップＳ１
２で所定時間経過したときにはユーザ３１との間のセシ
ョンが切断されたと推定し、後述する図７のステップＳ
６９以降の処理によって切断処理（通信プロセス３５の
終了処理など）を行う。

【００７５】ステップＳ１１は、通信プロセス３５がユ
ーザファイル４３から、ここでは認証要求をユーザＩ
Ｄ、パスワードと共に読みだして受信する。ステップＳ
１３は、通信プロセス３５がこの認証要求、ユーザＩＤ
及びパスワードをメインフレーム４２に通知する。

【００７６】ステップＳ１４は、メインフレーム４２が
認証処理を行い、その結果をサービスシステム３２へ返
答する。ステップＳ１５は、通信プロセス３５がメイン
フレーム４２からの認証処理の結果を受信し、対応する
ユーザファイル４３に書き込む。

【００７７】ステップＳ１６は、ユーザファイル４３に
認証処理の結果が書き込まれ、保持される。一方処理プ
ロセス３３では、ステップＳ８の処理の後、ステップＳ
１７として対応するユーザファイル４３のポーリングを
行い、認証要求に対する結果が通信プロセス３５によっ
てユーザファイル４３に書込まれたか調べる。ステップ
Ｓ１７で書込みがありの場合には、ユーザファイル４３
に認証結果が書き込まれていると判明したので、ステッ
プＳ１８に進む。書込みがなしの場合には、ユーザファ
イル４３に認証結果が書き込まれていないと判明したの
で、ステップＳ１７を繰り返し待機する。

【００７８】ステップＳ１８は、処理プロセス３３がユ
ーザファイル４３から認証処理の結果を読み出し、受信
する。ステップＳ１９は、処理プロセス３３は受信した
認証結果より正常に認証されたか否かを判別する。正常
に認証された場合には、ステップＳ２０で次処理に対す
る表示用ページのデータを作成し、このデータ中にユー
ザＩＤを埋め込み、ユーザ３１に送信する。一方、正常
に認証されずエラーの場合には、ステップＳ２２でエラ
ーの通知を行うページのデータを作成してユーザ３１に
送信する。処理プロセス３３は、この認証結果に対応し
た表示データを送信後、処理を終了し、消滅する。

【００７９】ステップＳ２１は、ユーザ３１に正常に認
証された旨の認証結果及び次処理に対応するページを表
示する。そして、図６のステップＳ３１に進む。ステッ
プＳ２３は、認証結果として、未認証等のエラーを知ら
せるエラーページを表示する。

【００８０】以上によって、ユーザ３１からメインフレ
ーム４２への認証要求に対する処理が完了する。次に、
上記認証後のユーザ３１からのサービス要求に対する処
理を図６を用いて説明する。

【００８１】図６は、ユーザ３１からのサービス要求に
対する動作を示すフローチャートである。この図６のフ
ローチャートは、ユーザ３１が２回目以降の要求、即ち
上記認証要求以降の要求をメインフレーム４２に通知し
て処理を行うときの一連の手順である。ここでユーザ３
１、サービスシステム３２、処理プロセス３３、管理プ
ロセス３４、通信プロセス３５及びメインフレーム４２
は、図２および図４のそれぞれに対応するものである。

【００８２】図６において、ステップＳ３１でユーザ３
１は、要求するサービスの種類を示し、ユーザＩＤが埋
め込まれた処理要求（データ）を送信する。ステップＳ
３２では、サービスシステム３２内の処理プロセス３３
がステップＳ３１で送信された処理要求を受信する。

【００８３】ステップＳ３３は、処理要求に埋め込まれ
ているユーザＩＤに対応するファイル名を持ったユーザ
ファイル４３が存在するか検索する。ここでは、認証要
求後の要求であり、該認証要求時にユーザファイル４３
は生成されているので、あり（ユーザファイル４３が存
在する）となりステップＳ３４に進む。またユーザファ
イル４３なしの場合には、エラーとなる（２回目の要求
に係わらず、ユーザファイル４３が作成されていないの
で、エラーとなる。）。

【００８４】ステップＳ３４は、処理プロセス３３が処
理要求をユーザファイル４３に書き込む。ステップＳ３
５は、ユーザファイル４３に処理要求が保持される。

【００８５】ステップＳ３６は、通信プロセス３５が対
応するユーザファイルのポーリングを行い、処理プロセ
ス３３からユーザファイル４３への書込みがあったかど
うか調べる。ステップＳ３６で書込みがありの場合に
は、ユーザファイル４３にここでは処理要求が書き込ま
れていると判明したので、ステップＳ３７に進む。ステ
ップＳ３６で書込みがなしの場合には、ユーザファイル
４３に処理要求（データ）が書き込まれるまで待機し、
ステップＳ３８で所定時間経過したかを監視する。ステ
ップＳ３８で所定時間経過時にはユーザ３１と処理プロ
セス３３との間のセションが切断されたと推定し、後述
する図７のステップＳ６９以降の処理によって切断処理
（通信プロセス３５の終了処理など）を行う。

【００８６】ステップＳ３７は、通信プロセス３５がユ
ーザファイル４３から、ここでは処理要求を読みだして
受信する。ステップＳ３９は、通信プロセス３５がこの
処理要求をメインフレーム４２に通知する。

【００８７】ステップＳ４０は、メインフレーム４２が
要求に対する処理を行い、その結果を返答する。ステッ
プＳ４１は、通信プロセス３５がこの処理の結果を受信
し、対応するユーザファイル４３に書き込む。

【００８８】ステップＳ４２は、ユーザファイル４３に
処理の結果が書き込まれ、保持される。一方処理プロセ
ス３３では、ステップＳ３４後、ステップＳ４３で対応
するユーザファイル４３のポーリングを行い、ステップ
Ｓ３４で送った処理要求に対する結果が書込まれたか調
べる。その結果書込みがありの場合には、ユーザファイ
ル４３に処理結果が書き込まれていると判明したので、
ステップＳ４４に進む。書込みがなしの場合には、ユー
ザファイル４３に処理結果が書き込まれていないと判明
したので、ステップＳ４３を繰り返し待機する。

【００８９】ステップＳ４４は、処理プロセス３３がユ
ーザファイル４３から処理結果を読み出し、受信する。
ステップＳ４５は、処理結果が正常か否か判別する。正
常の場合には、処理プロセス３３はステップＳ４６で処
理結果の表示及び次処理に対する表示用ページのデータ
を作成し、このデータ中にユーザＩＤを埋め込み、ユー
ザ３１に送信した後、終了・消滅する。一方メインフレ
ーム４２において、処理要求に対して要求通りの処理を
行えなかった等、エラーの場合には、処理プロセス３３
はステップＳ４９でエラーの表示ページのデータを作成
してユーザ３１に送信した後、終了・消滅する。

【００９０】ステップＳ４７は、処理結果（次処理用ペ
ージ）を表示する。ステップＳ４８は、ステップＳ４７
で表示させたページ上にある、この連携処理の終了を要
求する時に用いる終了ボタンが押下されたか判別する。
ＹＥＳ（押下された）の場合には、図７のステップＳ６
１に進む。またＮＯ（押下されない）の場合には、図６
のステップＳ３１に進み次の要求を受け付ける。

【００９１】ステップＳ５０は、処理結果としてエラー
を通知するエラーページを表示する。以上によって、ユ
ーザ３１からメインフレーム４２へのサービス要求等の
処理要求に対する処理が完了する。この処理は、Ｓ４８
で終了ボタンが押下され、終了要求が発行されるまで繰
り返される。

【００９２】次に、Ｓ４８で終了ボタンが押され、終了
要求が発行された場合の処理を図７を用いて説明する。
図７は、ユーザ３１とメインフレーム４２との間の処理
を終了させる際の処理を示すフローチャートである。こ
の図７のフローチャートは、ユーザが終了要求をメイン
フレーム４２に通知して終了処理を行うときの一連の手
順である。ここで、ユーザ３１、サービスシステム３
２、処理プロセス３３、管理プロセス３４、通信プロセ
ス３５及びメインフレーム４２は図４のそれぞれに対応
するものである。

【００９３】図７において、ステップＳ６１は、処理内
容として終了処理を示す、ユーザＩＤが埋め込まれた終
了要求（データ）を送信する。ステップＳ６２は、サー
ビスシステム４２内の処理プロセス３３がステップＳ６
１で送信された終了要求を受信する。

【００９４】ステップＳ６３は、処理要求に埋め込まれ
ているユーザＩＤに対応するファイル名を持ったユーザ
ファイル４３が存在するか検索する。ここでは、２回目
以降の要求であり既にユーザファイル４３が生成されて
いるので、ありとなり、ステップＳ６４に進む。ユーザ
ファイル４３がなしの場合には、エラーとなる（２回目
以降の要求に係わらず、ユーザファイル４３が生成され
ていないので、エラーとなる。）。

【００９５】ステップＳ６４は、処理プロセス３３が終
了要求をユーザファイル４３に書き込む。ステップＳ６
５は、ユーザファイル４３に終了要求が保持される。

【００９６】ステップＳ６６は、通信プロセス３５が対
応するユーザファイルのポーリングを行い、処理プロセ
ス３３からユーザファイル４３への書込みがあったか調
べる。ステップＳ６６で書込みがありの場合には、ユー
ザファイル４３に終了要求が書き込まれていると判明し
たので、ステップＳ６７に進む。ステップＳ３６で書込
みがなしの場合には、ユーザファイル４３に処理要求
（データ）が書き込まれるまで待機し、ステップＳ６８
で所定時間経過したかを監視する。ステップＳ６８でユ
ーザファイル４３に書込みが行われずに所定時間経過し
たときには、終了要求とは別の理由でユーザ３１と処理
プロセス３３との間のセションが切断されたと推定し、
ステップＳ６９の切断処理へ進む。

【００９７】ステップＳ６７は、通信プロセス３５がユ
ーザファイル４３から、ここでは終了要求を読み出して
受信する。ステップＳ６９は、通信プロセス３５がこの
終了要求をメインフレーム４２に通知する。

【００９８】ステップＳ７０は、メインフレーム４２が
切断処理（終了処理）を行い、その結果を返答する。ス
テップＳ７１は、通信プロセス３５がこの処理の結果を
受信し、対応するユーザファイル４３に書き込む。この
ステップＳ７１の処理の後通信プロセス３５は、適宜な
タイミングで、ステップＳ７６として対応するユーザフ
ァイル４３を削除した後終了・消滅する。

【００９９】ステップＳ７２は、ユーザファイル４３に
終了処理要求に対する結果が書き込まれる。一方、処理
プロセス３３ではステップＳ６４の後ステップＳ７３
で、対応するユーザファイル４３のポーリングを行い、
送信した要求に対する結果が通信プロセス３５によって
書込まれたか調べる。その結果書込みがありの場合に
は、ユーザファイル４３に終了結果が書き込まれている
と判明したので、ステップＳ７４に進む。書込みがなし
の場合には、ユーザファイル４３に終了結果が書き込ま
れていないと判明したので、ステップＳ７３を繰り返し
待機する。

【０１００】ステップＳ７４は、処理プロセス３３がユ
ーザファイル４３から終了処理結果を読み出し、受信す
る。ステップＳ７５は、処理プロセス３３は読み出した
処理結果より終了ページのデータを作成し、ユーザ３１
に送信し、その後終了・消滅する。

【０１０１】ステップＳ７７は、ユーザ３１が送られて
きたデータより終了の表示を行う。以上によって、ユー
ザ３１からの終了要求により、ユーザ３１とメインフレ
ーム４２との間の終了処理が完了する。

【０１０２】図８は、ユーザ３１−１、３１−２、３１
−３の３つのユーザからの要求を受け付けている時のサ
ービスシステム３２内の各プロセスの構成状態を示す図
である。

【０１０３】この様にサービスシステム３２では、コネ
クションレスな通信を行うユーザ３１に対しては１回の
セション毎にユーザ３１との通信を担当する処理プロセ
ス３３が生成され、また通信が終了するまで接続を維持
するコネクション型の通信を行うメインフレーム４２に
対しては、ユーザ３１毎にメインフレーム３２との通信
を担当する通信プロセス３５が生成される。

【０１０４】そして処理プロセス３３は、ユーザ３１か
らの要求に対して、自己で処理可能なものはメインフレ
ーム４２に通知せず自己で処理し、処理結果をユーザ３
１に通知する。また処理プロセス３３は、自己で処理可
能でないものは、ユーザ３１からの要求をユーザファイ
ル４３を介して通信プロセス３５に送信し、通信プロセ
ス３５はこれをメインフレーム４２に送信する。またそ
の処理結果は通信プロセス３５がメインフレーム４２か
ら受け取り、ユーザファイル４３を介して処理プロセス
３３に送信する。そして処理プロセス３３は、これをユ
ーザ３１に送信する。

【０１０５】以上の様にして、本実施形態のサービスシ
ステム３２は、異なる接続形態をもつ通信処理を行う装
置又はプログラム間での連携処理を実現する。次に、サ
ービスプロセス内にキューを設け、処理プロセスと通信
プロセスとの間の通信をこのキューを用いて行う構成の
場合について説明する。尚以下の説明では、これまで述
べてきたものと同一内容の部分は省略する。

【０１０６】図９のサービスシステム５２は、内部に各
ユーザ毎に要求キュー５４と結果キュー５６を必要に応
じて生成し、これらのキューを用いて処理プロセス５３
と通信プロセス５５との間の通信を行う構成としたもの
である。これらのキューは図４のユーザファイル４３と
同様に、各処理プロセス５３によって生成され、ユーザ
５１とメインフレーム６２の間の通信が終了すると消滅
する。

【０１０７】図４の名前付きパイプによるユーザファイ
ル４３を用いるサービスシステム３２の場合には、同一
ユーザからの命令は１つの命令しか処理することが出来
なかった。しかしこのキューを用いるサービスシステム
５２は、ユーザからの要求に対する結果が得られる前に
そのユーザから新たな要求が送信されても、この新たな
要求を受け付けて処理する、並列処理を行うことが出来
る。

【０１０８】以下に、この並列処理を行った場合につい
ての動作説明を行う。ユーザの認証処理時の図４のサー
ビスシステム４２と図９のサービスシステム５２の相違
点は、サービスシステム４２では処理プロセスによって
生成されるものがユーザファイルで、このユーザファイ
ルによって処理プロセスと通信プロセスとの間の通信を
行うのに対し、サービスシステム５２では要求キューと
命令キューが生成され、これらのキューによって処理プ
ロセスと通信プロセスとの間の通信を行う点である。よ
って以下の説明は、ユーザ５１の認証が済んだ後の処理
について行う。

【０１０９】まずユーザ５１は、メインフレーム６２に
対するサービス要求である要求１を発行し、これをサー
ビスシステム５２に送信する。この要求１は、ＷＷＷサ
ーバ６１を介して要求１の受信時に生成された処理プロ
セス５３−１に渡される。

【０１１０】処理プロセス５３−１は、この要求１に自
己を識別するＩＤを付加し、要求１に含まれているユー
ザＩＤに対応する要求キュー５４に繋げる。通信プロセ
ス５５は、自己に対応する要求キュー５４から要求を先
頭から１つ取り出し、これをメインフレーム６２に渡し
て処理させる。

【０１１１】一方ユーザ５１は、要求１に対する処理結
果を得る前に、新たなサービス要求である要求２を発行
し、これをサービスシステム５２に送信し、また要求
１、２に対する処理結果を得る前に、新たに要求３を発
行、送信したとする。

【０１１２】この要求２及び３に対して、サービスシス
テム５２ではそれぞれ処理プロセス５３−２、５３−３
を生成し、これらを受け付ける。処理プロセス５３−２
及び５３−３はこの要求２、３に自己を識別するＩＤを
付加し、要求２、３に含まれているユーザＩＤに対応す
る要求キュー５４に繋げる。

【０１１３】この様に、サービスシステム５２では、ユ
ーザ５１から送信された要求を順次受け付け、要求キュ
ー５４に格納してゆく。メインフレーム６２に要求１に
対する処理を依頼し、メインフレーム６２がこの処理を
行っている間に、要求キュー５４内に要求が残っていれ
ば、通信プロセス５５はその要求を順次取りだし、メイ
ンフレーム６２に渡して処理させる。図９の場合、要求
キュー５４には要求２、要求３が格納されており、通信
プロセス５５は、順次これらを取り出して処理してゆ
く。

【０１１４】メインフレーム６２からサービスシステム
５２に要求に対する処理結果が返ってくると、これを必
要に応じて順番を調整しながら結果キュー５６に繋げ
る。例えば要求１、２、３が互いに関連するもので且つ
その処理順序が問題となる場合には、このメインフレー
ム６２への要求の出力順序や処理結果の結果キュー５６
への出力順序及びタイミングの調整を通信プロセス５５
によって行う。

【０１１５】各処理プロセス５３は、要求を要求キュー
５４に送った後、ユーザ５１に対応する結果キュー５６
を監視し、自己に対応するＩＤが付加されている処理結
果を見つけると、ユーザ５１に出力する。

【０１１６】尚、この結果キュー５６から処理結果の取
り出しは、処理プロセス５３が能動的に処理結果を待つ
のではなく、ユーザ５１が結果取り出し要求を発行し、
これを受取った処理プロセス５３が自己に対応するＩＤ
が付加された処理結果を結果キュー５６より探す構成に
してもよい。この場合には、要求された処理結果に対応
するものが結果キュー５６になければ、処理プロセス５
３は、例えば、「処理中」等の通知を行うデータを生
成、出力する。

【０１１７】また図９のサービスシステム５２は、要求
を受け付ける要求キュー５４と処理結果を受け付ける結
果キュー５６を各ユーザ毎に生成する構成であるが、キ
ューの構成はこれに限られるものではなく、要求とそれ
に対する結果を同じキューによって処理する構成や、複
数のユーザに対して１組のキューを備える構成とするこ
とも出来る。要求とその結果を同一のキューで扱う場合
には、例えば処理プロセスから要求をキューに繋げる前
に、結果を格納する領域を予め設けた形に要求のデータ
形式を加工した後キューに出力する。

【０１１８】また、処理プロセス５３が処理結果を能動
的に結果キュー５６より取り出す場合には、結果キュー
５６をキューではなく名前付きパイプによるユーザファ
イルとすることも出来る。

【０１１９】更にサービスプロセスにスタックを設け、
処理プロセスと通信プロセスとの間の通信をキューによ
ってではなく、スタックによって行う構成とすることも
出来る。

【０１２０】またこれらは、生成する場所として、メモ
リ上に生成する構成でも、あるいはファイル上に生成す
る構成でも良い。図１０は、本実施形態における連携シ
ステムが用いられる情報処理システムの環境を示す図で
ある。

【０１２１】この情報処理システムは、図１０の様にＣ
ＰＵ７１、主記憶装置７２、ハードディスク装置７３、
ディスプレイ、キーボード等の入出力装置（Ｉ／Ｏ）７
４、モデム等のネットワーク接続装置７５及びディス
ク、磁気テープなどの可搬記憶媒体から記憶内容を読み
出す媒体読取り装置７６を有し、これらがバス７８によ
り接続される構成を備えている。

【０１２２】図１０の情報処理システムでは、媒体読取
り装置７６により磁気テープ、フロッピーディスク、Ｃ
Ｄ−ＲＯＭ、ＭＯ等の記憶媒体７７に記憶されているプ
ログラム、データを読み出し、これを主記憶装置７２ま
たはハードディスク７３にダウンロードする。そして本
実施形態による処理を、ＣＰＵ７１がこのプログラムや
データを実行することにより、ソフトウエア的に実現す
ることも可能である。

【０１２３】また、この情報処理システムでは、フロッ
ピーディスク等の記憶媒体７７を用いてアプリケーショ
ンソフトの交換が行われる場合がある。よって、本発明
は、プログラム間連携システム及び連携方法に限らず、
コンピュータにより使用されたときに、上述の本発明の
実施の形態の機能をコンピュータに行わせるためのコン
ピュータ読み出し可能な記憶媒体７７として構成するこ
ともできる。

【０１２４】この場合、「記憶媒体」には、例えば図１
１に示されるように、ＣＤ−ＲＯＭディスク、フロッピ
ーディスク（あるいはＭＯ、ＤＶＤ、リムーバブルハー
ドディスク等であってもよい）の可搬記憶媒体８６や、
ネットワーク回線８３経由で送信される外部の装置（サ
ーバ等）内の記憶手段（データベース等）８２、あるい
はコンピュータ８１の本体８４内のメモリ（ＲＡＭ又は
ハードディスク等）８５等が含まれる。可搬記憶媒体８
６や記憶手段（データベース等）８２に記憶されている
プログラムは、本体８４内のメモリ（ＲＡＭ又はハード
ディスク等）８５にロードされて、実行される。

【０１２５】

【発明の効果】以上説明した様に、本発明によれば、コ
ネクションレス型の通信側には１回のセション毎に生
成、消滅する処理プロセスを、コネクション型の通信側
には常駐して回線を保持する通信プロセスを生成し、こ
の処理プロセスと通信プロセスとの間で通信することに
よって連携処理を実現することができる。

【０１２６】またユーザからの１回の処理毎に終了して
しまうプログラムと、一度接続するとそのセションを張
ったままの状態で種々の処理を行うことができるプログ
ラムとをシステムに負荷をかけずに１対１に接続するこ
とが可能となる。これにより、従来のユーザが使用して
いたサーバを置き換えるのではなく、従来のサービスに
影響を与えることなく、新たなサービスを提供すること
が容易に可能となる。

【図面の簡単な説明】

【図１】本発明の原理図である。

【図２】本実施形態に於けるシステムのブロック図であ
る。

【図３】サービスシステム１２をメインフレーム２２と
は別の情報処理装置上に設けた場合及びサービスシステ
ム１２をメインフレーム２２上に設けた場合を示す図で
ある。

【図４】サービスシステムに名前付きパイプを用いた場
合の構成及びその動作を示す図である。

【図５】ユーザの認証要求時の処理動作を示すフローチ
ャートである。

【図６】サービス要求時の処理動作を示すフローチャー
トである。

【図７】終了要求時の処理動作を示すフローチャートで
ある。

【図８】３つのユーザからの要求を受け付けている時の
サービスシステム３２内の各プロセスの構成状態を示す
図である。

【図９】サービスシステムにキューを用いた場合の概略
構成図である。

【図１０】本システムが用いられる情報処理システムの
環境図である。

【図１１】記憶媒体の例を示す図である。

【図１２】従来技術の説明図である。

【符号の説明】

１１、３１、５１ ユーザ １２、３２、５２ サービスシステム １３、３３、５３ 処理プロセス １４、３４ 管理プロセス １５、３５、５５ 通信プロセス １６ 相手プログラム特定部 １７ プログラム作成依頼部 １８ セション継続監視部 １９ 同期部 ２０ 通信部 ２１ 終了通知部 ２２ メインフレーム ２３ 第１のプログラム ２４、４４ 第２のプログラム ２５ 情報処理装置 ４０ ＷＷＷブラウザ ４３ ユーザファイル ５４ 要求キュー ５６ 結果キュー

───────────────────────────────────────────────────── フロントページの続き (72)発明者 樫村 嘉夫 神奈川県川崎市中原区上小田中４丁目１番 １号 富士通株式会社内 (72)発明者 上村 賢一 神奈川県川崎市中原区上小田中４丁目１番 １号 富士通株式会社内 (72)発明者 稲木 貴光 神奈川県川崎市中原区上小田中４丁目１番 １号 富士通株式会社内

Claims (17)

【特許請求の範囲】
1. 【請求項１】 コネクションレス型の通信を行う第１の
   情報処理装置上のプログラムとコネクション型の通信を
   行う第２の情報処理装置上のプログラムとの連携を行う
   プログラム間連携システムにおいて、 前記第１の情報処理装置よりデータを受信した時、前記
   データに付加された送信元を一意に識別するユーザＩＤ
   に対応させて、前記第１の情報処理装置との通信を行う
   処理プロセスを生成する処理プロセス生成手段と、 前記処理プロセスからの指示により、前記ユーザＩＤに
   対応し、前記データにより指示された前記第２の情報処
   理装置との通信を行う、通信プロセスを生成する通信プ
   ロセス生成手段とを備えることを特徴とするプログラム
   間連携システム。
2. 【請求項２】 前記処理プロセスは、前記ユーザＩＤに
   対応するユーザファイルが存在するかどうかを調べ、存
   在する場合には該ユーザファイルに前記第１の情報処理
   装置から受信したデータを書込み、存在しない場合には
   前記通信プロセス生成手段に通信プロセスの生成を依頼
   すると共に前記ユーザＩＤに対応するユーザファイルを
   生成し、該ユーザファイルに前記第１の情報処理装置か
   ら受信したデータを書込み、 前記通信プロセスは、自己が対応するユーザＩＤと同じ
   ユーザＩＤに対応するユーザファイルより前記処理プロ
   セスが書込んだデータを読みだすとともに前記第２の情
   報処理装置に対して送信し、該第２の情報処理装置から
   受信した処理結果を前記ユーザファイルに書込み、該書
   込んだ処理結果を前記処理プロセスが前記ユーザファイ
   ルから読み出すことを特徴とする請求項１記載のプログ
   ラム間連携システム。
3. 【請求項３】 キューを更に備え、前記処理プロセスと
   前記通信プロセスとの間のデータの授受は前記キューを
   介して行うことを特徴とする請求項１記載のプログラム
   間連携システム。
4. 【請求項４】 プログラム間のデータの送受信の連携を
   行うプログラム間連携システムにおいて、 自ＩＤをデータとしてあるいは自ＩＤが埋め込まれたデ
   ータを送受信する第１のプログラムと、 前記第１のプログラムから送信されたデータを最初に受
   信したとき該ＩＤに対応づけて起動され、２回目以降の
   データ受信ではデータ中に前記ＩＤに対応したデータの
   みを受信し、受信したデータが終了要求のときに終了す
   る通信プロセスと、 前記通信プロセスとの間でデータの送受信を行う第２の
   プログラムとを備えたことを特徴とするプログラム間連
   携システム。
5. 【請求項５】 プログラム間でデータの送受信の連携を
   行うプログラム間連携システムにおいて、 自ＩＤをデータとしてあるいは自ＩＤが埋め込まれたデ
   ータを送受信する第１のプログラムと、 前記第１のプログラムからデータを受信したときに起動
   され、応答したときに終了し、前記第１のプログラムか
   ら送信されたデータを最初に受信したとき、該データ内
   のＩＤを識別子として持つファイルを作成すると共に通
   信プロセスの生成・起動、およびデータを当該ファイル
   に書き込む処理プロセスと、 前記ＩＤを識別子としてもつファイルにデータが書き込
   まれたときに読み出して前記処理プロセスより受信し、
   受信したデータが終了要求のときに終了する通信プロセ
   スと、 前記通信プロセスとの間でデータの送受信を行う第２の
   プログラムとを備えたことを特徴とするプログラム間連
   携システム。
6. 【請求項６】 前記処理プロセスが受信したデータ内の
   ＩＤに対応する前記ファイルが無かったときに当該ＩＤ
   を識別子として持つファイルを作成してデータを書き込
   み、一方、該ＩＤを識別子として持つファイルが有った
   ときは該ファイルにデータを書き込むことを特徴とする
   請求項５記載のプログラム間連携システム。
7. 【請求項７】 前記ファイルにデータが書き込まれてい
   るか否かをポーリングすることにより判定することを特
   徴とする請求項５又は６記載のプログラム間連携システ
   ム。
8. 【請求項８】 前記ファイルにデータが書き込まれてい
   るか否かを判定し、一定時間経過しても当該ファイルに
   データが書き込まれなかった場合に前記第１のプログラ
   ムにデータを再度書き込むか、あるいは通信を切断する
   かを問い合わせることを特徴とする請求項５、６並びに
   ７のいずれか１項に記載のプログラム間連携システム。
9. 【請求項９】 前記通信プロセスが前記ファイルに所定
   時間を越えてもデータが書き込まれないことを検出した
   ときに当該通信プロセスの処理を終了することを特徴と
   する請求項５、６、７並びに８のいずれか１項に記載の
   プログラム間連携システム。
10. 【請求項１０】 前記通信プロセスが渡したデータを前
    記第２のプログラムが処理している間に、当該通信プロ
    セスが次のデータを受信して前記第２のプログラムに渡
    して処理させることを特徴とする請求項４、５、６、
    ７、８並びに９のいずれか１項に記載のプログラム間連
    携システム。
11. 【請求項１１】 前記通信プロセスの負荷が多くなった
    場合に、前記第１のプログラムに負荷軽減を問い合わせ
    ることを特徴とする請求項４、５、６、７、８、９、並
    びに１０のいずれか１項に記載のプログラム間連携シス
    テム。
12. 【請求項１２】 コネクションレス型の通信を行う第１
    の情報処理装置上のプログラムとコネクション型の通信
    を行う第２の情報処理装置上のプログラムとのプログラ
    ム間連携方法であって、 前記第１の情報処理装置よりデータを受信した時、前記
    データに付加された送信元を一意に識別するユーザＩＤ
    に対応させて、前記第１の情報処理装置との通信を行う
    処理プロセスを生成し、 前記処理プロセスからの指示により、前記ユーザＩＤに
    対応し、前記データにより指示された前記第２の情報処
    理装置との通信を行う、通信プロセスを生成し、 前記処理プロセスは、前記第１情報処理装置上のプログ
    ラムとコネクションレス型通信を行い、 前記通信プロセスは前記第２の情報処理装置上のプログ
    ラムとコネクション型通信を行い、 前記処理プロセスと前記通信プロセスとの間でデータの
    授受を行うことにより前記プログラム間の連携を行うこ
    とを特徴とするプログラム間連携方法。
13. 【請求項１３】 前記処理プロセスと前記通信プロセス
    との間のデータの授受は、名前付きパイプによって実現
    されることを特徴とする請求項１２記載のプログラム間
    連携方法。
14. 【請求項１４】 キューを生成し、前記処理プロセスと
    前記通信プロセスとの間のデータの授受は、前記キュー
    を用いて実現されることを特徴とする請求項１２記載の
    プログラム間連携方法。
15. 【請求項１５】 コネクションレス型の通信を行う第１
    の情報処理装置よりデータを受信した時、前記データに
    付加された送信元を一意に識別するユーザＩＤに対応さ
    せて、前記第１の情報処理装置との通信を行う処理プロ
    セスを生成し、 前記処理プロセスからの指示により、前記ユーザＩＤに
    対応し、前記データにより指示されたコネクション型の
    通信を行う第２の情報処理装置との通信を行う通信プロ
    セスを生成することをコンピュータに行わせるためのプ
    ログラムを記憶した前記コンピュータが読み出し可能な
    記憶媒体。
16. 【請求項１６】 第１のプログラムよりＩＤをデータと
    してあるいはＩＤが埋め込まれたデータを受信し、 該データを最初に受信したときデータの第１のプログラ
    ムのＩＤに対応づけて、２回目以降のデータ受信ではデ
    ータ中に前記ＩＤが埋め込まれたデータのみを受信し、
    受信したデータが終了要求のときに終了する通信プロセ
    スを起動し、 前記通信プロセスとの間で第２のプログラムとのデータ
    の送受信を行うことをコンピュータに行わせるためのプ
    ログラムを記憶した前記コンピュータが読み出し可能な
    記憶媒体。
17. 【請求項１７】 第１のプログラムから自己のＩＤをデ
    ータとしてあるいは自ＩＤが埋め込まれたデータを受信
    し、 前記データを最初に受信したとき、前記ＩＤを識別子と
    して持つファイルを作成し、前記ファイルにデータが書
    き込まれたときに読み出すことによって前記データを受
    信し、受信したデータが終了要求のときに終了する通信
    プロセスを生成・起動し、前記データを該ファイルに書
    き込む処理プロセスを生成し、 前記通信プロセスを介して第２のプログラムとデータの
    送受信を行う ことをコンピュータに行わせるためのプログラムを記憶
    した前記コンピュータが読み出し可能な記憶媒体。