JP2007004608A - 連携処理システム及び装置及び方法 - Google Patents

Abstract

【課題】ストリームを取り扱えないデータ処理コンポーネント同士の連携を可能にする。
【解決手段】第１ホスト１−１上に存在する第１データ処理コンポーネント２０−１は、保持するデータをストリーム６０へと出力する機能を少なくとも備えた出力保持オブジェクト４０ａ、を処理結果として出力する。パイプライン手段１４−１及び１４−２は、前記出力保持オブジェクト４０ａに、該出力保持オブジェクト４０ａが保持するデータを第２ホスト１−２宛のストリーム６０へと出力させると共に、該ストリーム６０を入力とする入力保持オブジェクト３０ｂを該第２ホスト１−２に生成させ、該入力保持オブジェクト３０ｂにストリーム６０からのデータを格納させる。第２ホスト１−２上に存在する第２データ処理コンポーネント２０−２は、入力保持オブジェクト６０を引数として入力して処理する。
【選択図】図４

Description

本発明は複数のデータ処理コンポーネントを連携させて一連の処理を行わせる分散データ処理技術に関する。

複数のデータ処理コンポーネントを連携させて一連の処理を実行させる分散データ処理方法として、例えば特許文献１に示される方法がある。この方法では、結合処理の手続き情報および中間結果情報を転送情報単位としてネットワーク内を巡回させ、一方各部分処理を実行して結果を保持する各ノードはネットワークから転送情報単位を取得し、この転送情報単位の手続き情報に基づき、当該ノードの保持する部分処理結果と該取得した中間結果情報とを用いて、結合処理の一部を行い、この結果により中間結果情報を更新し、手続き情報とともにネットワークに送出する。

また、特許文献２には、ウェブサーバ上の原料ファイルをＨＴＴＰサーバ上で動作する処理サーバ（データ処理コンポーネント）に処理させ、複数の処理サーバの処理を連携させることで、複雑な加工を施した処理結果を求めるシステムが開示されている。このシステムでは、ウェブブラウザは、原料ファイルを手続名、パラメータ、コンピュータ名等で修飾した第１の仮想ＵＲＬ(Uniform Resource Locator)によりリクエストを送出する。複数の部分処理を組み合わせた複合的な処理が第１の仮想ＵＲＬで表記されている。複合的な処理を構成するには、部分処理を、第２の仮想ＵＲＬとして表現し、第２の仮想ＵＲＬが、第１の仮想ＵＲＬ中に引数として記述する。このことから、あたかも関数合成式を構成するように、仮想ＵＲＬを引数とし、複合的な処理を表す別の仮想ＵＲＬを階層的に構成できる。各処理サーバは、自分宛の仮想ＵＲＬを解釈してその中に含まれ、かつ、処理できない引数（仮想ＵＲＬ）を抽出し、それをリクエストとして処理可能な第２の処理サーバにＨＴＴＰ(Hypertext Transfer Protocol)で転送し、第１の処理サーバはレスポンスとして処理結果を取得し、それを入力データとして自分の処理に利用する。このように、入力された仮想ＵＲＬを、多重に入れ子になった計算処理式とみなし、最内側から順に、かつ分散的に実行することをなし得ている。この場合、各コンポーネントはＨＴＴＰプロトコルで接続され、相互に通信を行って、分散的なパイプライン処理を実現する。

また特許文献３には、１台のホストコンピュータ上で実行される１つのアプリケーション内で、複数のＨＴＴＰモジュールをイベント駆動で連携動作させることで、外部からの１つのＨＴＴＰリクエストを処理する方式が開示される。この方式では、外部からのＨＴＴＰリクエストを論理的に表現し、そのＨＴＴＰ要求に関連する少なくとも１つのプロパティをカプセル化するコンテキストオブジェクトを生成する。そして、コンテキストオブジェクトに対応しそれぞれが対応するイベントを有する複数の要求イベントを有するイベントパイプラインを形成し、要求イベントに対応するイベントが生じたとき、および、その要求イベントに関連してアプリケーションとモジュールのうち少なくとも１つが登録されたときにコールバックを生成し、コンテキストオブジェクトを処理するための前記コールバックに応答して、前記要求イベントに関連付けて登録される各アプリケーションと各モジュールを開始する。

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

特許文献１の方法では、ネットワーク内に巡回させる転送処理単位に中間処理結果のデータ実体が含まれるので、各処理コンポーネントは中間処理結果のデータ実体を授受するための通信を考慮したプログラミングを行う必要がある。このため、処理コンポーネントのプログラミングが難しいという問題がある。

この問題は、１つのコンピュータ装置上の複数のデータ処理コンポーネントを連携させる場合にも生じることである。ＵＮＩＸ（登録商標）等のＯＳ（オペレーティングシステム）が提供するパイプライン処理機能は、パイプラインを構成する各プログラムをＯＳが最初に並列に起動し、それらプログラムの標準出力ストリームを、パイプラインにおける次のプログラムの標準入力ストリームに結合することで、連携処理を実現している。しかしながら、このような方式では、各コンポーネントは、ストリームによるデータ通信を実現しなくてはならない。ストリームでないデータやオブジェクトを引数とし、メソッド呼び出しを行うような簡単なプログラミングに適応できない。

ネットワークを跨ったデータ処理コンポーネント間の連携を考えた場合、中間処理結果のデータはＨＴＴＰ等のネットワーク通信プロトコルを用いてネットワーク経由で受け渡すことになる。この種のネットワーク通信プロトコルでは、ネットワークを転送するデータはストリームの形となることが多い。ストリーム送受信の機能のプログラミングは一般に困難である。また、データ処理コンポーネントは、実行する処理の内容が重要であって、その処理のための入出力の制御はいわば副次的なものである。そのような副次的な入出力制御のためにプログラミングのための資源が利用されることは好ましいとはいえない。例えば、ワークフローシステムの要素となる個々のビジネスロジックを実現するデータ処理コンポーネントを開発するベンダは、ビジネスロジックのプログラミングに注力するものであり、入出力制御のプログラミングにはあまり資源を割きたくないであろう。

また、特許文献２の方式では、各データ処理コンポーネントを、ＨＴＴＰのリクエストを入力としＨＴＴＰのレスポンスを出力とするように実現する必要があり、特許文献１の方式と同じ問題がある。

また、特許文献３の方式は、同一ホストコンピュータ内、特に同一アプリケーション内のＨＴＴＰモジュールを連携させるものであり、この方式はそのままではネットワークを跨るホストコンピュータ間での処理コンポーネントの連携には適用できない。すなわち、同一ホスト内ならば処理対象となるオブジェクトをそのままＨＴＴＰモジュール同士の間で受け渡せばよいが、ネットワークを経由する場合はそのような簡単な受け渡し方式は実行不可能である。

本発明は、データ通信ネットワークを跨って複数のデータ処理コンポーネントが連携する連携処理システムにおいて、ストリームを取り扱う複雑なデータ入出力機構を持たないデータ処理コンポーネントでも、ネットワーク経由でのデータの受け渡しを伴う連携を実現できるようにするための技術を提供する。

１つの側面では、本発明は、第１のホストコンピュータ上に存在する第１のデータ処理コンポーネントであって、保持するデータをストリームへと出力する機能を少なくとも備えた出力保持オブジェクト、を処理結果として出力する第１のデータ処理コンポーネントと、前記第１のデータ処理コンポーネントが出力した前記出力保持オブジェクトに、該出力保持オブジェクトが保持するデータを第２のホストコンピュータ宛のストリームへと出力させると共に、該ストリームを入力とする入力保持オブジェクトを該第２のホストコンピュータに生成させ、該入力保持オブジェクトに前記ストリームからのデータを格納させるパイプライン手段と、前記第２のホストコンピュータ上に存在する第２のデータ処理コンポーネントであって、前記入力保持オブジェクトを引数として入力して処理する第２のデータ処理コンポーネントと、を備える連携処理システムを提供する。

別の側面では、本発明は、コンピュータ装置であって、第１の処理を実行する第１のデータ処理コンポーネントであって、前記第１の処理により得られるデータをストリームとして出力する機能を備えた出力保持オブジェクト、を前記第１の処理の結果として出力する第１のデータ処理コンポーネントと、前記第１のデータ処理コンポーネントの前記第１の処理により得られるデータを前記コンピュータ装置とは異なる第２のコンピュータ装置上の第２のデータ処理コンポーネントに対して提供して第２の処理を実行させる場合に、前記出力保持オブジェクトに対し、該出力保持オブジェクトが持つデータを、第２のホストコンピュータ宛のストリームとして出力させる出力側パイプ手段と、を備えるコンピュータ装置を提供する。

更に別の側面では、本発明は、コンピュータ装置であって、第１の処理を実行する第１のデータ処理コンポーネントと、外部装置からのストリームを入力とする入力保持オブジェクトを生成し、該ストリームを介して転送されてくる入力データを該入力保持オブジェクトに格納させる入力側パイプ手段と、前記入力保持オブジェクトを引数として前記第１のデータ処理コンポーネントに入力することにより、前記第１のデータ処理コンポーネントに前記入力データを処理させる処理指示手段と、を備えるコンピュータ装置を提供する。

更に別の側面では、本発明は、次のような連携処理方法を提供する。すなわち、この連携処理方法では、第１のホストコンピュータが、保持するデータをストリームへと出力する機能を備えた出力保持オブジェクト、を処理結果として出力する第１のデータ処理コンポーネントを実行し、パイプライン手段が、前記第１のデータ処理コンポーネントが出力した前記出力保持オブジェクトに、該出力保持オブジェクトが保持するデータを第２のホストコンピュータ宛のストリームへと出力させると共に、該ストリームを入力とする入力保持オブジェクトを該第２のホストコンピュータに生成させ、該入力保持オブジェクトに前記ストリームからのデータを格納させ、第２のホストコンピュータが、前記第１のデータ処理コンポーネントの処理結果を用いて処理を行う第２のデータ処理コンポーネントであって、前記入力保持オブジェクトを引数として入力して処理する第２のデータ処理コンポーネントを実行する。

以下、図面を参照して本発明の好適な実施形態を説明する。

本実施形態では、図１に示すように、複数のホストコンピュータ（以下、に「ホスト」と呼ぶ）１が、クライアント２からの要求に応じ、インターネット３等のＨＴＴＰを利用可能なネットワークを介して処理の連携を行う。

各ホスト１が有する連携処理のためのソフトウエアは、図２に示すように、処理制御部クラス１０，データ処理コンポーネントクラス２０，入力側ＨＴＴＰケイパブルクラス３０，及び出力側ＨＴＴＰケイパブルクラス４０の４種類のオブジェクトのクラスを有する。

データ処理コンポーネントクラス２０は、単位的なデータ処理を実行するデータ処理コンポーネントのオブジェクトのクラスである。単位的なデータ処理（以下「単位処理」という）の内容には特に限定はない。例えば、文書の要約、複数文書のマージ（併合）など、さまざまなものが単位処理の例として考えられる。データ処理コンポーネントクラス２０は、当該データ処理コンポーネントに定義された単位処理の実行を指示するためのexecuteメソッド２２（"execute()"）を備える。文書要約や文書マージと言った個別具体的な単位処理のクラスは、このデータ処理コンポーネントクラス２０を継承する子孫クラスとして実現される。個別具体的な単位処理のオブジェクトのexecuteメソッド２２を呼び出すことで、そのオブジェクトにその単位処理を実行させることができる。本実施形態のシステムでは、このような個別具体的な単位処理のデータ処理コンポーネントを、インターネット３等のネットワークを跨いで連携させることで、クライアント２に提供するサービスのための一連のデータ処理を実現する。なお、データ処理コンポーネントクラス２０やその子孫の個別具体的な処理用のコンポーネントのクラスは、executeメソッド２２以外のメソッドを有していても構わない。

データ処理コンポーネントクラス２０及びその子孫クラスである個別具体的な処理コンポーネントのクラスは、処理対象となる入力データとして後述する入力側ＨＴＴＰケイパブル(capable)クラス３０（或いはその子孫クラス）のオブジェクトを取り、処理結果として後述する出力ＨＴＴＰケイパブルクラス４０のオブジェクトを出力するよう構成される。それらのクラスは、データストリームの入出力のための機能（メソッド）は持たなくてよい。

処理制御部クラス１０は、それら複数のデータ処理コンポーネントの連携を制御するオブジェクトのクラスであり、例えばＪａｖａ（登録商標）のサーブレットとして実装することができる。処理制御部クラス１０の主たる役割は、クライアント２や他のホスト１から指示された処理に対応するデータ処理コンポーネントのオブジェクトを起動して、その処理を実行させることである。処理制御部クラス１０は、evalメソッド１２（"eval()"）とpipeメソッド１４（"pipe()"）を有する。

evalメソッド１２は、当該ホスト１上の処理制御部クラス１０のオブジェクトをクライアント２や他のホスト１が呼び出す際に用いるメソッドであり、このメソッドの引数には、当該ホスト１に実行させたい処理の内容を示す情報、例えば個別具体的なデータ処理コンポーネントの識別名やそのコンポーネントに与える処理パラメータなどが含まれる。また、複数のデータ処理コンポーネントの処理の順序を示したスクリプトや、そのスクリプトの識別情報などをevalメソッド１２の引数に指定することもできる。後者の場合、処理制御部クラス１０のオブジェクトは、そのスクリプトの識別情報に対応するスクリプト実体データを当該ホスト１内又はネットワーク上に存在するスクリプトサーバから取得して利用する。

pipeメソッド１４は、あるホスト１上のデータ処理コンポーネントの処理結果をインターネット２０等のネットワークを介して別のホスト１上のデータ処理コンポーネントに受け渡すためのメソッドである。ネットワークを介したデータの受け渡しには、様々な通信プロトコルが利用可能であるが、以下では一例としてＨＴＴＰを用いる場合の例を説明する。

ネットワーク経由のデータの受け渡しには、例えば、次の２つの方式が考えられる。一つは、プッシュ方式であり、処理を実行した前段のホスト１がその次の処理の実行要求を示すＨＴＴＰリクエストを後段のホスト１へと送り、前段のホスト１の処理結果のデータ（すなわち後段のホスト１の処理対象データ）をそのＨＴＴＰリクエストのストリームを介して転送する。もう一つは、プル方式であり、後段の処理を実行するホストが前段の処理を実行したホストに処理対象データを要求するＨＴＴＰリクエストを送り、このリクエストに対するＨＴＴＰレスポンスで前段のホストがその処理結果のデータを後段のホストへと転送する。本実施形態では、これら２つの方式のどちらを採用することもできる。pipeメソッド１４は、上記２つの方式のうちから選んだ１つの方式でのデータ転送を実現するために呼び出される。例えば、プッシュ方式の場合は、前段の処理を実行したホスト１が後段の処理を実行するホスト１に送るＨＴＴＰリクエストにて、その後段のホスト１の処理制御部クラス１０のpipeメソッド１４を呼び出す。プル方式の場合は、後段のホスト１が前段のホスト１に処理結果のデータを要求するＨＴＴＰリクエストにて、前段のホスト１の処理制御部クラス１０のpipeメソッド１４を呼び出す。なお、１つのシステムで上記２つの方式の両方を許容する場合は、方式ごとに異なるメソッドを用意すればよい。

なお、pipeメソッド１４そのものは、ＨＴＴＰリクエスト（及びプル方式の場合は更にＨＴＴＰレスポンス）を発行する機能を備えていればよく、データ処理コンポーネントの処理結果をＨＴＴＰストリームとして送信したり受信したりする機能は持たなくてもよい。そのようなストリームの送信及び受信の機能は、後で詳述する出力側ＨＴＴＰケイパブルクラス４０及び入力側ＨＴＴＰケイパブルクラス３０がそれぞれ備えている。

なお、処理制御部クラス１０は、evalメソッド１２やpipeメソッド１４以外のメソッドを有していても構わない。

この例では、ネットワークを跨ったデータの転送機能を処理制御部クラス１０のpipeメソッド１４として構成したが、この代わりに処理制御部クラス１０とは別のパイプラインクラスを定義し、ネットワークを跨ったデータの転送機能をこのパイプラインクラスのオブジェクトに実行させるようにしてもよい。

出力側ＨＴＴＰケイパブルクラス４０は、データ処理コンポーネントの出力する処理結果データを保持し、保持したデータをＨＴＴＰストリーム経由で出力する機能を備えたオブジェクトのクラスである。本実施形態のデータ処理コンポーネントクラス２０又はその子孫クラスのオブジェクトは、当該オブジェクトのデータ処理の結果として、この出力側ＨＴＴＰケイパブルクラス４０のオブジェクト（出力側ＨＴＴＰケイパブルオブジェクトと呼ぶ）を出力する。すなわち、データ処理コンポーネントオブジェクトが処理結果として出力する出力側ＨＴＴＰケイパブルオブジェクトは、データ処理コンポーネントオブジェクトの処理結果データを保持している。この処理結果データには、ＨＴＴＰのヘッダ情報又はボディ情報又はその両方が含まれる。出力側ＨＴＴＰケイパブルクラス４０は、ＨＴＴＰのヘッダ情報の出力するためのoutputHeaderメソッド４２("outputHeader()")と、ＨＴＴＰのボディ情報を出力するためのoutputBodyメソッド４４("outputBody()")とを有する。outputHeaderメソッド４２及びoutputBodyメソッド４４は、それらＨＴＴＰヘッダ及びＨＴＴＰボディのデータの出力先となるデータ出力ストリーム（の識別名）を引数にとる。他の装置やプログラム、オブジェクトは、データ出力ストリームを引数として出力側ＨＴＴＰケイパブルオブジェクトのoutputHeaderメソッド４２を呼び出すことで、その出力側ＨＴＴＰケイパブルオブジェクトが持つデータ（すなわち当該オブジェクトを生成したデータ処理コンポーネントオブジェクトの処理結果）のうちのＨＴＴＰヘッダを、そのオブジェクトからデータ出力ストリーム上に出力させることができる。同様に、出力側ＨＴＴＰケイパブルオブジェクトのoutputBodyメソッド４４をデータ出力ストリームを引数として呼び出せば、そのオブジェクトが持つＨＴＴＰボディのデータをデータ出力ストリームに出力させることができる。

なお、以上ではデータ出力コンポーネントは処理結果として出力側ＨＴＴＰケイパブルクラス４０のオブジェクトを出力するとしたが、これに限らず、出力側ＨＴＴＰケイパブルクラス４０を継承する子孫クラスを処理結果として出力するようにしてもよい。以下では、特に区別する必要がない限り、子孫クラスのオブジェクトも出力側ＨＴＴＰケイパブルオブジェクトと呼ぶ。

入力側ＨＴＴＰケイパブルクラス３０は、データ処理コンポーネントに対しインターネット３等のネットワーク経由でＨＴＴＰストリームとして送られてくるデータの受け皿となるオブジェクトのクラスである。すなわちクラス３０は、ＨＴＴＰストリームとして送られてくるデータ処理コンポーネントへの入力データを、データ処理コンポーネントに代わって受信して保持するオブジェクトのクラスである。入力側ＨＴＴＰケイパブルクラス３０は、constructor（コンストラクタ）メソッド３２("constructor()")を有する。constructorメソッド３２は、入力側ＨＴＴＰケイパブルクラス３０のオブジェクト（以下、入力側ＨＴＴＰケイパブルオブジェクトと呼ぶ）を生成するためのメソッドである。constructorメソッド３２は、データ入力ストリームを引数にとる。他の装置やプログラム、オブジェクトは、データ入力ストリームを引数として入力側ＨＴＴＰケイパブルクラス３０のconstructorメソッド３２を呼び出すことで、入力側ＨＴＴＰケイパブルオブジェクトを生成することができる。生成された入力側ＨＴＴＰケイパブルオブジェクトは、そのデータ入力ストリームからデータをＨＴＴＰに従って受け取り、当該オブジェクト内に格納する。データ処理コンポーネントは、この入力側ＨＴＴＰケイパブルオブジェクトを引数として受け取ることで、そのオブジェクトに保持されたデータを取得し、そのデータに対して当該コンポーネントの処理を施すことができる。

なお、以上ではネットワーク経由で送られてくる処理対象のデータが入力側ＨＴＴＰケイパブルクラス３０のオブジェクトにより受信されるとしたが、これに限らず、入力側ＨＴＴＰケイパブルクラス３０を継承する子孫クラスのオブジェクトにより受信されるようにすることもできる。以下では、特に区別する必要がない限り、子孫クラスのオブジェクトも入力側ＨＴＴＰケイパブルオブジェクトと呼ぶ。

なお、以上に説明したクラス３０及び４０の名称における「ＨＴＴＰケイパブル」という用語は、そのクラスがＨＴＴＰストリームに対するデータの出力又はＨＴＴＰストリームからのデータの入力が可能で、データをＨＴＴＰに準拠した形で保持できるということを意味する。ＨＴＴＰケイパブルクラス５０のオブジェクトは、ＨＴＴＰ要求を読み出して所定のデータ型に応じてデータを解析して保持し、自身が保持するデータから必要に応じてＨＴＴＰストリームを再現できると言う意味で、ＨＴＴＰリクエストをカプセル化したものである。特許文献３の技術におけるコンテキストオブジェクトはＨＴＴＰリクエストをカプセル化したものではあるが、それはＨＴＴＰリクエストのプロパティをカプセル化したに過ぎず、コンポーネントの処理対象又は処理結果となるデータを含むとは限らないし、またそのようなデータをＨＴＴＰストリームとして再現する機能は持たない。

また、入力側ＨＴＴＰケイパブルクラス３０及び出力側ＨＴＴＰケイパブルクラス４０又はそれらの子孫クラスは、上述したメソッド以外のメソッドを備えていても構わない。

また、以上の例では入力側ＨＴＴＰケイパブルクラス３０と出力側ＨＴＴＰケイパブルクラス４０の２つのクラスを用意したが、この代わりに、上述のconstructorメソッド３２、outputHeaderメソッド４２及びoutputBodyメソッド４４を全て備えた、図３に示すようなＨＴＴＰケイパブルクラス５０を用意してもよい。ＨＴＴＰケイパブルクラス５０又はその子孫クラスのオブジェクトは、上述の入力側ＨＴＴＰケイパブルオブジェクト及び出力側ＨＴＴＰケイパブルオブジェクトの両方の機能を果たすことができる。

以上、連携処理システムを構成するホスト１のソフトウエア構成について説明した。ホスト１のハードウエア構成は、一般的な汎用コンピュータと同様のものでよい。

次に、複数のホスト１上のデータ処理コンポーネント同士の連携処理の流れを説明する。前述のように、連携処理は、データ処理コンポーネントの処理結果（連携処理全体で見れば中間処理結果）をネットワーク経由で他のデータ処理コンポーネントへと渡す方式により、プッシュ方式とプル方式の２つの方式に大別できる。まず、プッシュ方式の場合の連携処理について説明する。

図４は、第１ホスト１−１上のデータ処理コンポーネント（オブジェクト）２０−１の処理結果を、リモートの第２ホスト１−２上の別のデータ処理コンポーネント２０−２に、ＨＴＴＰリクエストによるプッシュ方式で受け渡す場合の連携処理の流れを説明する図である。以下、この流れを順に説明する。

１．まずクライアント２又は他のホスト１等の外部装置から、処理を要求するＨＴＴＰリクエストＲｅｑ１が到来する。このＨＴＴＰリクエストＲｅｑ１は、例えばリクエスト送信側の装置にて次のようなＵＲＬから生成される。

http://host1.domain/Evaluator?method=eval&script=script1.groovy…(1)

このＵＲＬにおいて、"host1"は第１ホスト１−１のホスト名、"domain"はそのホスト１−１が存在するドメインの名前、"Evaluator"は処理制御部クラス１０のクラス名である。また、クエリ部（"?"以降）における"method=eval"は呼び出すメソッド１２"eval"を示し、"&script=script1.groovy"はそのevalメソッド１２が処理するスクリプトの名前script1.groovyを示す。

このようなＵＲＬに対応するＨＴＴＰリクエストＲｅｑ１を受け取った第１ホスト１−１では、処理制御部クラス１０のオブジェクトである第１処理制御部１０−１が生成される。そして、第１処理制御部１０−１のevalメソッド１２が、リクエストＲｅｑ１中で指定されたスクリプト名に対応するスクリプトを第１ホスト１−１又はネットワーク上のスクリプトサーバから取得し、そのスクリプトに示される命令を順に処理していく。スクリプト記述の具体例を以下に示す。

id0 = Component1.execute(url1); …(2)

id1 = Evaluator.eval(host1, "scriptA.groovy", id0) … (3)

id2 = Evaluator.eval(host2, "scriptB.groovy", id1) … (4)

このスクリプト記述は、(2), (3), (4)の３つの式からなるものであり、第１ホスト１−１（ホスト名が"host0"であるとする）の第１処理制御部１０−１のevalメソッド１２により実行されるスクリプトの一部である。第２ホスト１−２のホスト名を"host1"とし、図４には図示しない第３のホストのホスト名を"host2"とする。"Component1"は第１データ処理コンポーネント２０−１のクラス名であり、"Evaluator"は処理制御部クラス１０のクラス名である。例えば(2)式は、第１ホスト１−１内の第１データ処理コンポーネント２０−１に、"url1"に示されるＵＲＬから入手できるデータを処理対象として処理を実行させることを示す。そのコンポーネント２０−１の処理結果である第１ＨＴＴＰケイパブルオブジェクト４０ａの識別子が変数"id0"にセットされる。また(3)式の命令は、第２ホスト"host1"に対し、スクリプト"scriptA.groovy"を、"id0"で示されるオブジェクト４０ａを引数として実行させ、その実行の結果（すなわちそのスクリプトに示される一連のデータ処理コンポーネント群の最終処理結果）である出力側ＨＴＴＰケイパブルオブジェクトの識別子を変数"id1"にセットする旨の指示を示している。次の(4)式の命令は、この"id1"が示す処理結果を処理対象データとして、第３ホスト"host2"が、スクリプト"scriptB.groovy"を実行することを示している。

スクリプトには、反復や条件分岐などの制御構造を記述することもできるが、ここでは説明を省略する。スクリプトを用いた複数のデータ処理コンポーネント間での連携処理については、本願と同時係属中の特願２００４−３２１４４５号（２００４年１１月５日出願）に詳しく説明されており、参照のためその出願の明細書、特許請求の範囲、図面、及び要約書をここに組み込むものとする。

このようにスクリプト中の各命令は、起動するデータ処理コンポーネントと、そのデータ処理コンポーネントに対する入力データを示す引数とを含んでいる。したがって、スクリプト中の命令を順に実行していく過程で、第１処理制御部１０−１は、命令に示されるデータ処理コンポーネント（第１データ処理コンポーネント２０−１）を起動（すなわちインスタンス生成）し、そのコンポーネントに処理を実行させることになる。

以上では、ＨＴＴＰリクエストＲｅｑ１に、第１ホスト１−１が実行すべきスクリプトが指定されている例を示したが、リクエストＲｅｑ１には、スクリプトの代わりに、第１ホスト１−１が実行すべき単位処理（この例では第１データ処理コンポーネント２０−１）が指定されてもよい。

２．第１処理制御部１０−１が起動するデータ処理コンポーネントが処理対象のデータを必要とするものである場合、そのコンポーネントの起動の前にその処理対象のデータを入手し、そのコンポーネントに入力可能な形にする必要がある。このため第１処理制御部１０−１の第１パイプライン処理部１４−１は、ＨＴＴＰリクエストＲｅｑ１に対応する入力データの受け皿として、入力側ＨＴＴＰケイパブルクラス３０又はＨＴＴＰケイパブルクラス５０のオブジェクトである第０ＨＴＴＰケイパブルオブジェクト３０ａを生成する。第１パイプライン処理部１４−１は、pipeメソッド１４の機能を実行するプログラムモジュールである。

第１データ処理コンポーネント２０−１への入力データは、例えば外部装置からのＨＴＴＰリクエストＲｅｑ１中に含まれる。ここで、ＨＴＴＰリクエストＲｅｑ１中の、例えば上述のＵＲＬ例(1)におけるメソッド名やその引数のスクリプト名の後にその入力データの実体が続く場合、第１パイプライン処理部１４−１は、そのＨＴＴＰリクエストＲｅｑ１により形成されたＨＴＴＰストリームのストリーム名を引数として、constructorメソッド３２を呼び出すことで、第０ＨＴＴＰケイパブルオブジェクト３０ａを生成することができる。生成された第０ＨＴＴＰケイパブルオブジェクト３０ａは、そのＨＴＴＰストリームのデータ（より厳密には上述のメソッド名やその引数の後に続くデータ部分）を受信し、それを保持する。ＨＴＴＰリクエストＲｅｑ１中に含まれるのが入力データの実体ではなく参照（例えばその入力データのＵＲＬ）である場合は、第１パイプライン処理部１４−１は、その参照が示すデータ源に対して入力データを要求するＨＴＴＰリクエストを発し、これに対するデータ源からのレスポンスのＨＴＴＰストリームを引数としてconstructorメソッド３２を呼び出し、第０ＨＴＴＰケイパブルオブジェクト３０ａを生成する。また、データ処理コンポーネントへの入力データへの参照が、スクリプト中の命令の中に、メソッドの引数として記述される場合もあるが、この場合も同様に、第１パイプライン処理部１４−１がその参照が示すデータを要求するＨＴＴＰリクエストを発行し、これに対するレスポンスを受け取るオブジェクト３０ａを生成すればよい。

３．第０ＨＴＴＰケイパブルオブジェクト３０ａが生成されると、第１処理制御部１０−１は、そのオブジェクト３０ａのデータを処理すべき第１データ処理コンポーネント２０−１のexecuteメソッド２２を、そのオブジェクト３０ａの識別子を引数として呼び出すことにより、第１データ処理コンポーネント２０−１を起動する。

４．起動された第１データ処理コンポーネント２０−１は、第０ＨＴＴＰケイパブルオブジェクト３０ａが保持するデータを受け取り、このデータに対して処理を施す。

５．そして第１データ処理コンポーネント２０−１は、その処理の結果のデータを保持した第１ＨＴＴＰケイパブルオブジェクト４０ａを出力する。このオブジェクト４０ａは、出力側ＨＴＴＰケイパブルクラス４０又はＨＴＴＰケイパブルクラス５０のオブジェクトである。一例として、この出力処理は、第１データ処理コンポーネント２０−１が、自身のデータ出力ストリームを引数としてconstructorメソッド３２を呼び出すことで実現することができる。

６．第１データ処理コンポーネント２０−１は、自身の処理を実行すると、その処理結果のステータスを含んだ応答を第１処理制御部１０−１に返す。処理が成功した場合、その応答には、そのコンポーネント２０−１が出力した第１ＨＴＴＰケイパブルオブジェクト４０ａの識別子が含まれる。

７．第１処理制御部１０−１が実行しているスクリプトの中に、第１データ処理コンポーネント２０−１の実行命令の次に第２ホスト１０−２上で実行されるスクリプトの実行命令が記述されていた場合（例えば上記(3)式）、或いは第２ホスト１０−２上の第２データ処理コンポーネント２０−２の実行命令が記述されていた場合、第１処理制御部１０−１は第１パイプライン処理部１４−１に対し、第２ホスト１０−２への処理要求発行を指示する。これを受けた第１パイプライン処理部１４−１は、第２データ処理コンポーネント２０−２の実行を第２ホスト１０−２の第２パイプライン処理部１４−２に対して要求するＨＴＴＰリクエストＲｅｑ２を発行する。例えば上記(3)式を実行する場合には、第１処理制御部１０−１は、その式に示される宛先ホスト名及びスクリプト名を含んだ、第２ホスト１０−２宛のＨＴＴＰリクエストＲｅｑ２を作成し、発行する。

８．また第１パイプライン処理部１４−１は、ＨＴＴＰリクエストＲｅｑ２の発行により形成されたＨＴＴＰストリーム６０を引数として第１ＨＴＴＰケイパブルオブジェクト４０ａ（これは、(2),(3)式において変数"id0"で示される）のoutputHeaderメソッド４２及びoutputBodyメソッド４４を順に、或いはそれらメソッド４２又は４４の一方を呼び出すことで、第１ＨＴＴＰケイパブルオブジェクト４０ａにデータ出力を指示する。

９．この出力指示に応じ、第１ＨＴＴＰケイパブルオブジェクト４０ａは、自身が保持するデータをＨＴＴＰストリーム６０へと出力する。

１０．一方、第２ホスト１０−２は、第１ホスト１０−１からのＨＴＴＰリクエストＲｅｑ２に応じ、上述のパイプライン機能を果たす第２パイプライン処理部１４−２を備えた第２処理制御部１０−２を起動する。そして、第２パイプライン処理部１４−２は、ＨＴＴＰストリーム６０を引数としてconstructorメソッド３２を呼び出すことで、入力側ＨＴＴＰケイパブルクラス３０又はＨＴＴＰケイパブルクラス５０の第２ＨＴＴＰケイパブルオブジェクト３０ｂを生成する。生成された第２ＨＴＴＰケイパブルオブジェクト３０ｂは、ＨＴＴＰストリーム６０から入力されるデータ（ＨＴＴＰヘッダ又はＨＴＴＰボディ又はその両方）を取得し、保持する。この処理により生成される第２ＨＴＴＰケイパブルオブジェクト３０ｂは、第１ホスト１−１上の第１ＨＴＴＰケイパブルオブジェクト４０ａのレプリカ（複製物）となる。

１１．第２ＨＴＴＰケイパブルオブジェクト３０ｂの生成が成功すると、第２処理制御部１０−２は、第２ＨＴＴＰケイパブルオブジェクト３０ｂを入力データとして、リクエストＲｅｑ２で指定されたスクリプトを実行する。例えば、そのスクリプトの中での最初の処理が、そのオブジェクト３０ｂを引数とした第２データ処理コンポーネント２０−２の実行である場合、第２処理制御部１０−２は、オブジェクト３０ｂの識別子を引数として第２データ処理コンポーネント２０−２を起動する。

１２．起動された第２データ処理コンポーネント２０−２は、オブジェクト３０ｂが保持するデータを取得し、このデータに対して当該コンポーネント２０−２自身の処理を施す。

１３．第２データ処理コンポーネント２０−２は、その処理の結果を、出力側ＨＴＴＰケイパブルクラス４０又はＨＴＴＰケイパブルクラス５０の第３ＨＴＴＰケイパブルオブジェクト４０ｂとして出力する。また、第２データ処理コンポーネント２０−２は、第２処理制御部１０−２に対し、このオブジェクト４０ｂの識別子を返す。

この後、オブジェクト４０ｂの持つデータは、そのデータに対して処理を施す後続のデータ処理コンポーネントに渡される。後続のデータ処理コンポーネントが、ＨＴＴＰリクエストＲｅｑ２を発行した第１ホスト１０−１上にある場合は、そのＨＴＴＰリクエストＲｅｑ２に対するＨＴＴＰレスポンスのストリームに乗せて、そのオブジェクト４０ｂの持つデータが第１ホスト１０−１に返される。また、後続のデータ処理コンポーネントがその他のホストである場合は、上述と同様、そのホストのパイプライン処理部に対してＨＴＴＰリクエストを発行し、そのＨＴＴＰのストリームを介してオブジェクト４０ｂのデータを転送すればよい。

以上、データ処理コンポーネントの処理結果を、第１ホスト１０−１と第２ホスト１０−２との間でプッシュ方式で受け渡す場合の処理の流れを説明した。次に、その受け渡しをプル方式で行う場合の流れを、図５を参照して説明する。

プル方式では、ホスト１−１と１−２の間でやりとりされるＨＴＴＰリクエストに２つの種類がある。すなわち、ある処理を実行した第１ホスト１−１から、その次の処理を実行する第２ホスト１−２に後続の処理の実行を要求するＨＴＴＰリクエストＲｅｑ４（処理要求リクエストと呼ぶ）と、当該後続の処理の対象データ（すなわち第１ホスト１−１の処理結果）を第２ホスト１−２から第１ホスト１−１に要求するＨＴＴＰリクエストＲｅｑ５（データ要求リクエスト）の２種類である。処理実行を要求するリクエストＲｅｑ４には、宛先のホストが実行すべきスクリプト又はデータ処理コンポーネントの指定と、その対象データへの参照（例えば、その対象データを持つ出力側ＨＴＴＰケイパブルオブジェクトの識別子）とが含まれ、その対象データの実体は含まれない。対象データを要求するリクエストＲｅｑ５は、その参照の情報を含む。

以下、プル方式の場合の連携処理の流れを順に説明する。プル方式は、データ処理コンポーネント間の処理結果の受け渡しの流れはプッシュ方式と異なるが、他の部分はプッシュ方式と類似しているので、以下ではプッシュ方式の場合と重複する説明は適宜省略する。

１．まず第１ホスト１０−１に対して外部装置（クライアント２又は他のホスト１）から処理を要求するＨＴＴＰリクエストＲｅｑ３が到来する。この処理要求リクエストＲｅｑ３には、第１ホスト１−１が処理すべきスクリプト、又は第１ホスト１−１が実行すべきデータ処理コンポーネントを特定する情報が含まれる。

２．リクエストＲｅｑ３中のスクリプト又は実行すべきデータ処理コンポーネントの指定に従い、第１処理制御部１０−１は第１データ処理コンポーネント２０−１を起動して処理を実行させる。図示は省略したが、第１データ処理コンポーネント２０−１が処理対象データを必要とし、その処理対象データを指す参照情報がリクエストＲｅｑ３中に含まれている場合は、プッシュ方式の場合と同様第１処理制御部１０−１は、その参照情報が示すデータ源からその処理対象データを取得してこれを入力側ＨＴＴＰケイパブルオブジェクトに格納し、第１データ処理コンポーネント２０−２を、この入力側ＨＴＴＰケイパブルオブジェクトを引数として起動する。

３．第１データ処理コンポーネント２０−１の処理結果は、出力側ＨＴＴＰケイパブルオブジェクトである第１ＨＴＴＰケイパブルオブジェクト４０ａとして出力される。

４．第１データ処理コンポーネント２０−１は、処理を実行すると、その処理結果である第１ＨＴＴＰケイパブルオブジェクト４０ａの識別子を含んだ応答を第１処理制御部１０−１に返す。

５．第１データ処理コンポーネント２０−１の次に、第２ホスト１０−２上の第２データ処理コンポーネント２０−２を実行する必要がある場合、第１処理制御部１０−１は、その処理コンポーネントの実行を指示するＨＴＴＰリクエストＲｅｑ４を発行する。第２データ処理コンポーネント２０−２が処理対象のデータを特定できるようにするために、このＨＴＴＰリクエストＲｅｑ４には、第１ＨＴＴＰケイパブルオブジェクト４０ａの識別子、又は第１データ処理コンポーネント１０−１（インスタンスオブジェクト）の識別情報などの情報が、引数として含まれる。

６．ＨＴＴＰリクエストＲｅｑ４を受け取った第２ホスト１−２の第２処理制御部１０−２は、第２データ処理コンポーネント２０−２を起動する前に、第２パイプライン処理部１４−２により、そのコンポーネントの処理対象データを要求するＨＴＴＰリクエストＲｅｑ５を第１ホスト１−１へと送る。このＨＴＴＰリクエストＲｅｑ５には、処理対象データを特定する識別情報が含まれる。この識別情報はＨＴＴＰリクエストＲｅｑ４から求められる。

７．ＨＴＴＰリクエストＲｅｑ５を受け取った第１ホスト１−１の第１パイプライン処理部１４−１は、そのリクエストＲｅｑ５に対するＨＴＴＰレスポンスＲｅｓ１を第２パイプライン処理部１４−２へと返す。

８．次に第１パイプライン処理部１４−１は、ＨＴＴＰリクエストＲｅｑ５に含まれる識別情報に対応する第１ＨＴＴＰケイパブルオブジェクト４０ａを特定し、ＨＴＴＰレスポンスＲｅｓ１のＨＴＴＰストリーム７０を引数としてそのオブジェクト４０ａのoutputHeaderメソッド４２又はoutputBodyメソッド４４又はその両方を呼び出すことで、第１ＨＴＴＰケイパブルオブジェクト４０ａにデータ出力を指示する。

９．この出力指示に応じ、第１ＨＴＴＰケイパブルオブジェクト３０ａは、自身が保持するデータをＨＴＴＰストリーム７０へと出力する。

１０．一方、第２ホスト１０−２の第２パイプライン処理部１４−２は、第１ホスト１０−１からのＨＴＴＰレスポンスＲｅｓ１に応じ、ＨＴＴＰストリーム７０を引数としてconstructorメソッド３２を呼び出すことで、入力側ＨＴＴＰケイパブルオブジェクトである第２ＨＴＴＰケイパブルオブジェクト３０ｂを生成する。生成された第２ＨＴＴＰケイパブルオブジェクト３０ｂは、ＨＴＴＰストリーム７０から入力されるデータを取得し、保持する。

これ以降の処理１１〜１３は、プッシュ方式の場合と同様でよい。

以上、データ処理コンポーネントの処理結果を異なるホスト間でネットワーク経由で受け渡すための２つの方式について説明したが、この他に同一ホスト内の別のデータコンポーネントにその処理結果を受け渡す場合もある。この場合は、図６に示すように、第１処理制御部１０−１は、第１データ処理コンポーネント２０−１の処理結果である第１ＨＴＴＰケイパブルオブジェクト４０ａの識別子を引数として、その次のデータ処理コンポーネント２０−３を起動すればよい。

以上説明したように、本実施形態によれば、ＨＴＴＰストリームの入出力制御は入力側ＨＴＴＰケイパブルオブジェクト又は出力側ＨＴＴＰケイパブルオブジェクトにより実行される。これにより、単位処理を行うデータ処理コンポーネントは、単にそれらのオブジェクト型のデータを入出力できるようにプログラミングすればよくなる。すなわち、本実施形態によれば、ＨＴＴＰストリームによるデータの入出力を、ストリーム型でないオブジェクト型のデータ入出力に置き換えることができるので、データ処理コンポーネントの開発が容易になり、生産性が高まる。

なお、以上の例では、各ホスト１が、データ処理コンポーネントの実行命令又は他のスクリプトの実行命令を１個以上並べたスクリプトを実行する場合の例であった。しかし、本発明は、このようなスクリプトを用いる場合に限られるものではない。例えば、ホストから他のホスト上のデータ処理コンポーネントの実行を（スクリプト経由ではなく）直接指示することもできる。この場合、スクリプトを実行する処理制御部クラス１０は本質的なものではなくなる。各ホスト１には、処理制御部クラス１０の代わりに、パイプライン処理部１４−１，１４−２の機能を実現するオブジェクトのクラスを用意すればよい。また、別の方法として、データ処理コンポーネントクラス２０に、パイプライン機能を果たすpipeメソッドを組み込んでもよい。

次に、本実施形態の変形例について説明する。

まず第１の変形例について説明する。上記実施形態では特に言及しなかったが、ＨＴＴＰケイパブルオブジェクトに対し（入力側も出力側も）、データ型を持たせることができる。たとえばバイナリ型のＨＴＴＰケイパブルオブジェクトは、ＨＴＴＰリクエスト又はレスポンスのＨＴＴＰストリームのボディパート（ＨＴＴＰボディ）（入力側の場合）、又はデータ処理コンポーネントの処理結果データ（出力側の場合）をバイナリデータとして解釈し、バイト配列として保持する。同様に、テキスト型のＨＴＴＰケイパブルオブジェクトは、ＨＴＴＰストリームからの入力データ又はデータ処理コンポーネントの処理結果のデータを文字配列として保持する。また、ＸＭＬ(eXtensible Markup Language)型のＨＴＴＰケイパブルオブジェクトは、ＨＴＴＰストリームからの入力データ又はデータ処理コンポーネントの処理結果のデータをテキストで表現されたＸＭＬデータとして解釈し、そのＸＭＬデータをパースし、そのパースの結果をパースツリーとして保持する。またＣＳＶ(Comma Separated Value)型のＨＴＴＰケイパブルオブジェクトは、ＨＴＴＰストリームからの入力データ又はデータ処理コンポーネントの処理結果のデータをテキストデータで表現されたＣＳＶデータとして解釈し、このＣＳＶデータをパースし、２次元の表構造（２次元配列）として保持する。それぞれの型のＨＴＴＰケイパブルオブジェクトは、内部で保持するデータに応じたアクセスメソッドを提供する。たとえば、ＣＳＶ型のＨＴＴＰケイパブルオブジェクトは、２次元配列におけるインデックスを指定して該当するデータにアクセスするようなメソッドを提供する。

このようにデータ型ごとに異なるように実現されたＨＴＴＰケイパブルオブジェクトをあつかうために、第１の変形例では、出力側ＨＴＴＰケイパブルオブジェクトのヘッダ出力メソッド"outputHeader"は、そのオブジェクト自身のデータ型をＨＴＴＰリクエスト又はレスポンスのヘッダのＨＴＴＰエンティティタイプ（ヘッダ属性ContentTypeの値部分。ＭＩＭＥ(Multipurpose Internet Mail Extensions)のメディアタイプ）として出力するようにする。また、図７に示すように、ホスト（図７では代表として第２ホスト１−２を示す）にＨＴＴＰケイパブルファクトリ３５を持たせる。ＨＴＴＰケイパブルファクトリ３５は、受信したＨＴＴＰストリームのヘッダ情報に含まれるＨＴＴＰエンティティタイプを解析し、指定されたデータ型の入力側ＨＴＴＰケイパブルオブジェクトのコンストラクタ(constructor)メソッドを起動する。これにより、出力側の第１ＨＴＴＰケイパブルオブジェクト４０ａと同じデータ型であることが保証されている第２ＨＴＴＰケイパブルオブジェクト３０ｂを生成することができ、このオブジェクト３０ｂを第２データ処理コンポーネント２０−２の引数とすることができる。

次に第２の変形例について説明する。

上記第１の変形例では、受け側のホスト１のＨＴＴＰケイパブルファクトリ３５が、送り側のホスト１の出力側ＨＴＴＰケイパブルオブジェクトのデータ型と同じデータ型の入力側ＨＴＴＰケイパブルオブジェクトを生成していた。ところが、送り側の第１データ処理コンポーネント２０−１が処理結果として出力するオブジェクトのデータ型と、第１データ処理コンポーネント２０−１の処理結果を利用する第２データ処理コンポーネント２０−２が入力として受け入れるオブジェクトのデータ型とが一致するとは限らない。例えば、ＸＭＬデータは、単なるテキストデータ(文字配列)として解釈することも、またバイナリデータ(バイト配列)として解釈することもできる。したがってＸＭＬ型ＨＴＴＰケイパブルオブジェクトから送信されたデータは、ＸＭＬ型ＨＴＴＰケイパブルオブジェクトで受信することができるのはもちろんのこと、テキスト型やバイナリ型のＨＴＴＰケイパブルオブジェクトで受信して処理することもできる。このように、前段と後段のデータ処理コンポーネントの間でデータ型が一致しない場合でも、データ処理コンポーネント間でデータを受け渡して連携処理することが可能な場合がある。

このような場合に、この第２の変形例では、ＨＴＴＰケイパブルオブジェクトのデータ型の変換（キャスト）を行う。このための機能ブロックは、図７に示した第１の変形例のものと同様である。ただし、第２パイプライン処理部１４−２の機能が第１の変形例の場合と異なる。

すなわち、第２の変形例では、第２ホスト１−２の第２パイプライン処理部１４−２は、第２ＨＴＴＰケイパブルオブジェクト３０ｂを生成しようとする際、そのオブジェクト３０ｂを処理する第２データ処理コンポーネント２０−２又はそのコンポーネント２０−２を起動して制御する第２処理制御部１０−２に対し、該コンポーネント２０−２が要求する引数（入力側ＨＴＴＰケイパブルオブジェクト）のデータ型を問い合わせる。これには例えばＪａｖａ（登録商標）のＡＰＩ(Application Programming Interface)の一つであるreflectionを用いることができる。そして第２パイプライン処理部１４−２は、この問合せによって得たデータ型をＨＴＴＰケイパブルファクトリ３５に指定する。これより、ＨＴＴＰケイパブルファクトリ３５は、他のホストからのＨＴＴＰリクエスト又はレスポンスから得られるエンティティタイプに変えて、第２パイプライン処理部１４−２から指定されたデータ型を持つ第２ＨＴＴＰケイパブルオブジェクト３０ｂを生成し、第２データ処理コンポーネント２０−２の引数とする。

なお、キャストが可能なデータ型同士の関係は決まっており、そのような関係に合致する場合にのみ上記のキャスト処理を行うものとする。

次に第３の変形例について説明する。

この第３の変形例は、図５に示したプル方式の実施例の変形例である。この変形例では、図８に示すように、各ホスト１（図では第２ホスト１−２を代表として示す）は、入力側ＨＴＴＰケイパブルオブジェクトを一時的に保存するキャッシュ８０を備える。

第２パイプライン処理部１４−２は、第１ホスト１−１からのＨＴＴＰレスポンスから第１ＨＴＴＰケイパブルオブジェクト４０ａ（図５参照）のレプリカである第２ＨＴＴＰケイパブルオブジェクト３０ｂを生成すると、そのオブジェクト３０ｂをそのオブジェクト３０ｂを、ＩＤ８２と対応づけてキャッシュ８０に登録する。キャッシュ８０としては、例えば、Ｊａｖａ（登録商標）のハッシュマップ(HashMap)クラスのオブジェクトを用いることができる。ＩＤ８２は、キャッシュしたオブジェクト３０ｂの元である第１ＨＴＴＰケイパブルオブジェクト４０ａを一意的に特定する識別情報である。ＩＤ８２としては、例えば第１ＨＴＴＰケイパブルオブジェクト４０ａのＵＲＬやＵＲＩ(Uniform Resource Identifier)を用いることが好適であるが、これに限られるものではない。

図５の実施例では、第２パイプライン処理部１４−２は、第２データ処理コンポーネント２０−２の処理対象データが必要になった場合、その処理対象データを保持した第１ＨＴＴＰケイパブルオブジェクト４０ａを取得するＨＴＴＰリクエストＲｅｑ５を発行した。これに対し、この第３の変形例では、第２パイプライン処理部１４−２は、ＨＴＴＰリクエストＲｅｑ５を発行する前に、キャッシュ８０を検索し、そのオブジェクト４０ａのレプリカ（オブジェクト３０ｂ）が存在するかどうかを調べる。この処理では、ＵＲＬ等のオブジェクト４０ａのＩＤ８２をキーとしてキャッシュ８０内を検索する。取得しようとするオブジェクト４０ａのＩＤは、ＨＴＴＰリクエストＲｅｑ５を生成するために必要なものなので、第２パイプライン処理部１４−２はそれを知っており、そのＩＤを用いて検索ができる。この検索で取得対象のオブジェクトのＩＤに対応するオブジェクト３０ｂがキャッシュ８０から見つかれば（キャッシュ・ヒット）、第２パイプライン処理部１４−２は、そのオブジェクト３０ｂを引数として第２データ処理コンポーネント２０−２を起動する。一方、キャッシュ８０がヒットしなれば、第２パイプライン処理部１４−２は、オブジェクト４０ａを要求するＨＴＴＰリクエストＲｅｑ５を第１ホスト１−１へと発行し、オブジェクト４０ａのレプリカ生成を行う（図５参照）。

なお、キャッシュ８０は、例えばＬＲＵ(Last Recently Used)方式などの既存のキャッシュ保守方式に従い、久しく使われないオブジェクトを削除するなどの保守を行うことも好適である。

この変形例によれば、あるホスト（第１ホストと呼ぶ）があるデータ処理コンポーネント（第１コンポーネントと呼ぶ）のために他のホストから取得したデータが、再度その第１コンポーネント又は第１ホスト内の他のデータ処理コンポーネントで使用される場合、キャッシュ８０からそのデータを取得できるので、処理の速度を向上させることができる。

また、従来のように各データ処理コンポーネントの処理結果を入出力のストリームを介して受け渡したのでは、各コンポーネントごとの処理結果がコンピュータ装置上に残らないため、デバッグなどの様に、途中の処理結果を調べたい場合には不十分であったのに対し、第３の変形例では、キャッシュ８０に処理結果が残るので、途中の処理結果を調べたい場合などに有益な情報を提供できる。

次に第４の変形例について、図９を参照して説明する。

上記第３の変形例において、第２データ処理コンポーネント２０−２（図８参照）のために取得されキャッシュ８０に保持されたオブジェクト３０ｂが、後で別のデータ処理コンポーネント２０−４に再利用される場合を考える。このような場合、引数とするオブジェクトのデータ型がコンポーネント２０−２と２０−４とで異なる場合が生じ得る。このような場合に対応するため第４の変形例では、ホスト１にコンバータファクトリ９０を設けた。コンバータファクトリ９０は、データ型変換のためのコンバータプログラムを複数種類備えると共に、それら各コンバータプログラムがどのようなデータ型変換に使用できるかを示す変換表を備える。変換表の一例を以下に示す。
[表１]
入力型 出力型 コンバータ
text/xml text/html XSLTranslater
text/html text/csv HTMLTableConverter
text/xml text/csv XMLTableConverter

この表において、「入力型」はコンバータへの入力（すなわちキャッシュ８０内のオブジェクト）のデータ型を、「出力型」はコンバータの出力（すなわちそのオブジェクトをこれから使用しようとするデータ処理コンポーネントの引数のデータ型）を示す。そして、「コンバータ」は、「入力型」を「出力型」に変換するコンバータプログラムの識別名である。例えばHTMLTableConverterは、ＨＴＭＬのデータを解析し、Table要素を取り出して解釈して表を作成し、その表をＣＳＶ形式で出力するコンバータである。HTMLのTable要素からのCSVの作成は、それを行う既存のアプリケーション（HC95 http://www.smfknife.com/ht/hc95.php 等）を利用することで可能である。XMLTableConverterもこれと同様である。

第２パイプライン処理部１４−２は、データ処理コンポーネント２０−４の処理に用いるデータとして、キャッシュ８０から第２ＨＴＴＰケイパブルオブジェクト３０ｂを見つけた場合、そのコンポーネント２０−４の待ち受けデータ型（引数のデータ型）をそのコンポーネント２０−４自身又は第２処理制御部１０−２に問合せる。そして、オブジェクト３０ｂのデータ型を入力型とし、データ処理コンポーネント２０−４の引数のデータ型を出力型とするコンバータを変換表から特定する。そして、そのコンバータを起動することで、データ処理コンポーネント２０−４の入力データ型に適合した第３ＨＴＴＰケイパブルオブジェクト３０ｃをオブジェクト３０ｂから生成し、そのオブジェクト３０ｃをデータ処理コンポーネント２０−４の引数とする。

第４の変形例の使用例として、次のようなものが考えられる。すなわち、ＸＭＬ(text/xml)のデータを、ＸＳＬＴ(Extensible Stylesheet Language Transformations)のスタイルを指定して、ＸＳＬプロセッサでＨＴＭＬ(text/html)データに変換することは良く知られている。キャッシュ８０内のオブジェクト３０ｂのデータ型がtext/xmlであって、データ処理コンポーネント２０−４の待ち受けデータ型がtext/htmlであれば、コンバータファクトリ９０は、上記変換表から"XSLTranslater"というコンバータを引き当て、そのコンバータを用いてオブジェクト３０ｃを得る。

従来、データ実体のシグニチャ（データ処理コンポーネントが入力、あるいは出力するデータのタイプと並び）が異なるデータ処理コンポーネント同士の間でデータを受け渡した場合、後段のデータ処理コンポーネントでタイプミスマッチが発生し、連携できなかった。これに対し、第４変形例では、前後のコンポーネント同士のシグニチャの組合せが、コンバータファクトリ９０で変換可能なものであれば、それらコンポーネント同士の連携処理が可能となる。

上記第３及び第４の変形例では各ホスト１にキャッシュ８０を設けたが、この代わりにキャッシュ８０の機能を持つキャッシュサーバを、ネットワーク上に設けるようにすることも可能である。この場合、ホスト１からキャッシュサーバへと上述のプッシュ方式でデータ転送を行うことで、ホスト１内のデータ処理コンポーネントの処理結果である出力側ＨＴＴＰケイパブルオブジェクトのレプリカをキャッシュサーバに送信する。キャッシュサーバは、その出力側ＨＴＴＰケイパブルオブジェクトのＩＤと対応づけてそのレプリカを保存する。また、ホスト１のパイプライン処理部１は、ホスト１内のデータ処理コンポーネントの処理対象データが必要となった場合、まずキャッシュサーバからのデータ取得を試み、それに失敗した場合に、その処理対象データを持つホスト１から取得を行う。

以上では、ホスト間のデータの受け渡しにＨＴＴＰを用いる例を示したが、本発明は、ＨＴＴＰに限らず、ホスト間のデータをストリームとして受け渡すプロトコル全般に適用可能である。

以上に説明した実施形態及びその変形例は、本発明の実施例の一例に過ぎない。本発明の技術的思想の範囲内で、この他にも様々な変形が可能である。

本発明が適用されるネットワークシステムの概要を示す図である。 システムを構成する各ホストコンピュータが持つプログラムモジュール群の構成の例を示す図である。 システムを構成する各ホストコンピュータが持つプログラムモジュール群の構成の別の例を示す図である。 中間処理結果をプッシュ方式で受け渡す場合の連携処理の流れを説明する図である。 中間処理結果をプル方式で受け渡す場合の連携処理の流れを説明する図である。 同一ホスト内のデータ処理コンポーネント間での処理結果の受け渡しを説明するための図である。 第１及び第２変形例でのＨＴＴＰケイパブルオブジェクトのデータ型の制御を説明するための図である。 ＨＴＴＰケイパブルオブジェクトのキャッシュを備える第３変形例のホストの構成を示す図である。 コンバータファクトリを備える第４変形例のホストの構成を示す図である。

符号の説明

１−１ 第１ホスト、１−２ 第２ホスト、１０−１ 第１処理制御部、１０−２ 第２処理制御部、１４−１ 第１パイプライン処理部、１４−２ 第２パイプライン処理部、２０−１ 第１データ処理コンポーネント、２０−２ 第２データ処理コンポーネント、３０ａ 第０ＨＴＴＰケイパブルオブジェクト、３０ｂ 第２ＨＴＴＰケイパブルオブジェクト、４０ａ 第１ＨＴＴＰケイパブルオブジェクト、４０ｂ 第３ＨＴＴＰケイパブルオブジェクト。

Claims (29)

1. 第１のホストコンピュータ上に存在する第１のデータ処理コンポーネントであって、保持するデータをストリームへと出力する機能を備えた出力保持オブジェクト、を処理結果として出力する第１のデータ処理コンポーネントと、
   前記第１のデータ処理コンポーネントが出力した前記出力保持オブジェクトに、該出力保持オブジェクトが保持するデータを第２のホストコンピュータ宛のストリームへと出力させると共に、該ストリームを入力とする入力保持オブジェクトを該第２のホストコンピュータに生成させ、該入力保持オブジェクトに前記ストリームからのデータを格納させるパイプライン手段と、
   前記第２のホストコンピュータ上に存在する第２のデータ処理コンポーネントであって、前記入力保持オブジェクトを引数として入力して処理する第２のデータ処理コンポーネントと、
   を備える連携処理システム。
2. 前記パイプライン手段は、前記第１のホストコンピュータ上に存在する出力側パイプ手段と、前記第２のホストコンピュータ上に存在する入力側パイプ手段と、を有し、
   前記入力側パイプ手段は、前記第２のデータ処理コンポーネントに処理を実行させる場合に、該処理のために必要なデータを保持する出力保持オブジェクトを示す識別情報を含んだデータリクエストを前記出力側パイプ手段に対して発行し、
   前記出力側パイプ手段は、前記入力側パイプ手段からの前記データリクエストに応じたレスポンスを発行し、前記データリクエスト中の識別情報に対応する前記出力保持オブジェクトにその保持するデータを該レスポンスのストリームへと出力させ、
   前記入力側パイプ手段は、前記出力側パイプ手段からのレスポンスのストリームを入力とする前記入力保持オブジェクトを生成し、該入力保持オブジェクトに前記ストリームからのデータを格納させる、
   ことを特徴とする請求項１記載の連携処理システム。
3. 前記パイプライン手段は、入力保持オブジェクトを、該入力保持オブジェクトの元になった出力保持オブジェクトの識別情報と対応づけて保存するキャッシュ手段、を更に備え、
   前記入力側パイプ手段は、前記第２のデータ処理コンポーネントに処理を実行させる場合に、前記データリクエストを発行する前に、該処理のために必要なデータを保持する出力保持オブジェクトの識別情報に対応づけられた入力保持オブジェクトを前記キャッシュ手段から検索し、該当する入力保持オブジェクトが検索できた場合は、前記データリクエスト発行を取りやめ、検索された入力保持オブジェクトを前記第２のデータ処理コンポーネントに引数として与える、
   ことを特徴とする請求項２記載の連携処理システム。
4. 前記パイプライン手段は、前記キャッシュ手段に保存された前記入力保持オブジェクトのデータ型と、該入力保持オブジェクトが保持するデータを処理する前記第２のデータ処理コンポーネントの入力データ型とが異なる場合に、前記入力保持オブジェクトを該入力データ型に型変換し、この型変換結果のオブジェクトを前記第２のデータ処理コンポーネントに引数として与える、
   ことを特徴とする請求項３記載の連携処理システム。
5. 前記パイプライン手段は、前記第１のホストコンピュータ上に存在する出力側パイプ手段と、前記第２のホストコンピュータ上に存在する入力側パイプ手段と、を有し、
   前記出力側パイプ手段は、前記入力側パイプ手段に対してリクエストを発行し、前記出力保持オブジェクトに、保持するデータを該リクエストのストリームへと出力させ、
   前記入力側パイプ手段は、前記出力側パイプ手段からのリクエストのストリームを入力とする前記入力保持オブジェクトを生成し、該入力保持オブジェクトに前記ストリームからの入力データを格納させる、
   ことを特徴とする請求項１記載の連携処理システム。
6. 前記出力保持オブジェクト及び前記入力保持オブジェクトはデータ型を有し、
   前記パイプライン手段は、前記第２のホストコンピュータ上に入力保持オブジェクトを生成するためのオブジェクトファクトリを有し、
   前記オブジェクトファクトリは、データ型の異なる複数種類の入力保持オブジェクトを生成する機能を備え、それら複数種類の入力保持オブジェクトのうち、前記出力保持オブジェクトのデータ型に対応するデータ型の入力保持オブジェクトを生成する、
   ことを特徴とする請求項１記載の連携処理システム。
7. 前記出力保持オブジェクト及び前記入力保持オブジェクトはデータ型を有し、
   前記パイプライン手段は、前記第２のホストコンピュータ上に入力保持オブジェクトを生成するためのオブジェクトファクトリを有し、
   前記オブジェクトファクトリは、データ型の異なる複数種類の入力保持オブジェクトを生成する機能を備え、前記第２のデータ処理コンポーネントの引数のデータ型に対応するデータ型の入力保持オブジェクトを生成する、
   ことを特徴とする請求項１記載の連携処理システム。
8. 前記入力保持オブジェクトは、入力保持オブジェクトクラス又はこれを継承する子孫クラスのインスタンスであり、
   前記入力保持オブジェクトクラスは、引数として指定されたストリームを入力とし、該ストリームから入力されるデータを保持する入力保持オブジェクトを生成するコンストラクタメソッドを備えることを特徴とする請求項１記載の連携処理システム。
9. 前記出力保持オブジェクトは、出力保持オブジェクトクラス又はこれを継承する子孫クラスのインスタンスであり、
   前記出力保持オブジェクトクラスは、出力保持オブジェクトが保持するデータを、引数として指定されたストリームに出力するデータ出力メソッド、
   を備えることを特徴とする請求項１記載の連携処理システム。
10. 前記出力保持オブジェクト及び前記入力保持オブジェクトは、データ保持オブジェクトクラス又はこれを継承する子孫クラスのインスタンスであり、
    前記データ保持オブジェクトクラスは、
    引数として指定されたストリームを入力とし、該ストリームから入力されるデータを保持するデータ保持オブジェクトクラスのインスタンスを前記出力保持オブジェクトとして生成するコンストラクタメソッドと、
    前記入力保持オブジェクトとしてのデータ保持オブジェクトクラスのインスタンスが保持するデータを、引数として指定されたストリームに出力するデータ出力メソッドと、
    を備えることを特徴とする請求項１記載の連携処理システム。
11. 前記ストリームは、ＨＴＴＰリクエスト又はＨＴＴＰレスポンスの発行に応じて形成されるデータストリームであることを特徴とする請求項１記載の連携処理システム。
12. 第１のコンピュータを、
    第１の処理を実行する第１のデータ処理コンポーネントであって、前記第１の処理により得られるデータをストリームとして出力する機能を備えた出力保持オブジェクト、を前記第１の処理の結果として出力する第１のデータ処理コンポーネント、
    前記第１のデータ処理コンポーネントの前記第１の処理により得られるデータを前記コンピュータとは異なる第２のコンピュータ上の第２のデータ処理コンポーネントに対して提供して第２の処理を実行させる場合に、前記出力保持オブジェクトに対し、該出力保持オブジェクトが持つデータを、第２のホストコンピュータ宛のストリームとして出力させる出力側パイプ手段、
    として機能させるプログラム。
13. 前記第１のコンピュータを、
    外部装置からのストリームを入力とする入力保持オブジェクトを生成し、該ストリームを介して転送されてくる入力データを該入力保持オブジェクトに格納させる入力側パイプ手段、
    前記入力保持オブジェクトを引数として前記第１のデータ処理コンポーネントに入力することにより、前記第１のデータ処理コンポーネントに前記入力データを処理させる処理指示手段、
    として更に機能させる請求項１２記載のプログラム。
14. 前記入力側パイプ手段は、前記第１のデータ処理コンポーネントに処理を実行させる場合に、該処理のために必要な原料データを示す識別情報を含んだデータリクエストを、該データを保持する前記外部装置へと送信し、該データリクエストに対するレスポンスのストリームを入力とする前記入力保持オブジェクトを生成する、ことを特徴とする請求項１３記載のプログラム。
15. 前記入力側パイプ手段は、
    生成した入力保持オブジェクトを、該入力保持オブジェクトの元になった前記原料データの識別情報と対応づけて保存するキャッシュ手段を備え、
    前記第１のデータ処理コンポーネントに処理を実行させる場合に、前記データリクエストを発行する前に、該処理のために必要な原料データの識別情報に対応づけられた入力保持オブジェクトを前記キャッシュ手段から検索し、該当する入力保持オブジェクトが検索できた場合は、前記データリクエスト発行を取りやめ、検索された入力保持オブジェクトを前記第２のデータ処理コンポーネントに引数として与える、
    ことを特徴とする請求項１４記載のプログラム。
16. 前記入力側パイプ手段は、前記キャッシュ手段に保存された前記入力保持オブジェクトのデータ型と、該入力保持オブジェクトが保持するデータを処理する前記第１のデータ処理コンポーネントの入力データ型とが異なる場合に、前記入力保持オブジェクトを該入力データ型に型変換し、この型変換結果のオブジェクトを前記第１のデータ処理コンポーネントに引数として与える、ことを特徴とする請求項１５記載のプログラム。
17. 前記出力側パイプ手段は、前記第２のコンピュータに対し前記第２のデータ処理コンポーネントの実行を要求するリクエストを発行し、前記出力保持オブジェクトに、保持するデータを該リクエストのストリームへと出力させる、ことを特徴とする請求項１２記載のプログラム。
18. 前記出力保持オブジェクトは、前記ストリームに対し、自身の保持するデータに加え、自身のデータ型を示す型情報を出力することを特徴とする請求項１２記載のプログラム。
19. 前記入力側パイプ手段は、前記ストリームを介して転送されてくるデータのデータ型に対応したデータ型を持つ入力保持オブジェクトを生成することを特徴とする請求項１３記載のプログラム。
20. 前記入力側パイプ手段は、前記第１のデータ処理コンポーネントの引数のデータ型に対応するデータ型の入力保持オブジェクトを生成することを特徴とする請求項１３記載のプログラム。
21. 前記第１のコンピュータを、第３の処理を実行する第３のデータ処理コンポーネント、として機能させると共に、
    前記出力側パイプ手段は、前記第１のデータ処理コンポーネントの前記第１の処理により得られるデータを前記第３のデータ処理コンポーネントに対して提供して処理させる場合、入力データを示す引数として前記出力保持オブジェクトを示す情報を指定して前記第３のデータ処理コンポーネントを起動する、
    ことを特徴とする請求項１２記載のプログラム。
22. 前記入力保持オブジェクトは、入力保持オブジェクトクラス又はこれを継承する子孫クラスのインスタンスであり、
    前記入力保持オブジェクトクラスは、引数として指定されたストリームを入力とし、該ストリームから入力されるデータを保持する入力保持オブジェクトを生成するコンストラクタメソッドを備える、
    ことを特徴とする請求項１３記載のプログラム。
23. 前記出力保持オブジェクトは、出力保持オブジェクトクラス又はこれを継承する子孫クラスのインスタンスであり、
    前記出力保持オブジェクトクラスは、出力保持オブジェクトが保持するデータを、引数として指定されたストリームに出力するデータ出力メソッド、
    を備えることを特徴とする請求項１２記載のプログラム。
24. 前記出力保持オブジェクト及び前記入力保持オブジェクトは、データ保持オブジェクトクラス又はこれを継承する子孫クラスのインスタンスであり、
    前記データ保持オブジェクトクラスは、
    引数として指定されたストリームを入力とし、該ストリームから入力されるデータを保持するデータ保持オブジェクトクラスのインスタンスを前記出力保持オブジェクトとして生成するコンストラクタメソッドと、
    前記入力保持オブジェクトとしてのデータ保持オブジェクトクラスのインスタンスが保持するデータを、引数として指定されたストリームに出力するデータ出力メソッドと、
    を備えることを特徴とする請求項１３記載のプログラム。
25. 前記ストリームは、ＨＴＴＰリクエスト又はＨＴＴＰレスポンスの発行に応じて形成されるデータストリームであることを特徴とする請求項１２記載のプログラム。
26. コンピュータを、
    第１の処理を実行する第１のデータ処理コンポーネント、
    外部装置からのストリームを入力とする入力保持オブジェクトを生成し、該ストリームを介して転送されてくる入力データを該入力保持オブジェクトに格納させる入力側パイプ手段、
    前記入力保持オブジェクトを引数として前記第１のデータ処理コンポーネントに入力することにより、前記第１のデータ処理コンポーネントに前記入力データを処理させる処理指示手段、
    として機能させるプログラム。
27. コンピュータ装置であって、
    第１の処理を実行する第１のデータ処理コンポーネントであって、前記第１の処理により得られるデータをストリームとして出力する機能を備えた出力保持オブジェクト、を前記第１の処理の結果として出力する第１のデータ処理コンポーネントと、
    前記第１のデータ処理コンポーネントの前記第１の処理により得られるデータを前記コンピュータ装置とは異なる第２のコンピュータ装置上の第２のデータ処理コンポーネントに対して提供して第２の処理を実行させる場合に、前記出力保持オブジェクトに対し、該出力保持オブジェクトが持つデータを、第２のホストコンピュータ宛のストリームとして出力させる出力側パイプ手段と、
    を備えるコンピュータ装置。
28. コンピュータ装置であって、
    第１の処理を実行する第１のデータ処理コンポーネントと、
    外部装置からのストリームを入力とする入力保持オブジェクトを生成し、該ストリームを介して転送されてくる入力データを該入力保持オブジェクトに格納させる入力側パイプ手段と、
    前記入力保持オブジェクトを引数として前記第１のデータ処理コンポーネントに入力することにより、前記第１のデータ処理コンポーネントに前記入力データを処理させる処理指示手段と、
    を備えるコンピュータ装置。
29. 第１のホストコンピュータが、保持するデータをストリームへと出力する機能を備えた出力保持オブジェクト、を処理結果として出力する第１のデータ処理コンポーネントを実行し、
    パイプライン手段が、前記第１のデータ処理コンポーネントが出力した前記出力保持オブジェクトに、該出力保持オブジェクトが保持するデータを第２のホストコンピュータ宛のストリームへと出力させると共に、該ストリームを入力とする入力保持オブジェクトを該第２のホストコンピュータに生成させ、該入力保持オブジェクトに前記ストリームからのデータを格納させ、
    第２のホストコンピュータが、前記第１のデータ処理コンポーネントの処理結果を用いて処理を行う第２のデータ処理コンポーネントであって、前記入力保持オブジェクトを引数として入力して処理する第２のデータ処理コンポーネントを実行する、
    連携処理方法。

Images