JP2009123202A - データを処理するためのプロセッサ‐サーバ・ハイブリッド・システムおよび方法 - Google Patents

Abstract

【課題】ウェブ３．０の特性を効率的に取り扱うシステムおよび方法を提供する。
【解決手段】本発明には、（特に）１組の（１つ以上の）サーバ（例えば、メインフレーム）と、１組のフロントエンド・アプリケーション最適化プロセッサとを備えるプロセッサ‐サーバ・ハイブリッド・システムに関する。さらに、本発明の実施は、Ｉ／Ｏ接続ハイブリッド・システムを介して細粒レベルでアプリケーションの実行を分散および管理するためのサーバおよびプロセッサ・ハイブリッド・システムおよび方法を提供する。本方法によって、あるシステムをシステム機能の管理および制御のために使用することができ、１つ以上の他のシステムをコプロセッサとして使用することができる。
【選択図】図１

Description

本発明は、一般的には、データ処理に関する。特定的には、本発明は、より効率的なデータ処理のためのプロセッサ‐サーバ・ハイブリッド・システムに関する。

本願は、いくつかの局面において、同じ権利者が所有する２００７年１１月１５日出願の同時係属特許出願番号（追って補充）、名称「データを処理するためのサーバ‐プロセッサ・ハイブリッド・システム（ＳＥＲＶＥＲ‐ＰＲＯＣＥＳＳＯＲ ＨＹＢＲＩＤ ＳＹＳＴＥＭ ＦＯＲ ＰＲＯＣＥＳＳＩＮＧ ＤＡＴＡ）」、代理人整理番号ＥＮＤ９２００７０３７５ＵＳ１に関するものであり、その全体の内容を本願において参照により引用するものとする。本願は、いくつかの局面において、同じ権利者が所有する２００７年１０月２４日出願の同時係属特許出願第１１／８７７９２６号、名称「高帯域幅画像処理システム（ＨＩＧＨ ＢＡＮＤＷＩＤＴＨ ＩＭＡＧＥ ＰＲＯＣＥＳＳＩＮＧ ＳＹＳＴＥＭ）」、代理人整理番号ＥＮＤ９２００７０３９８ＵＳ１に関するものであり、その全体の内容を本願において参照により引用するものとする。本願は、いくつかの局面において、同じ権利者が所有する２００７年６月２５日出願の同時係属特許出願第１１／７６７７２８号、名称「ハイブリッド画像処理システム（ＨＹＢＲＩＤ ＩＭＡＧＥ ＰＲＯＣＥＳＳＩＮＧ ＳＹＳＴＥＭ）」、代理人整理番号ＥＮＤ９２００７０１１０ＵＳ２に関するものであり、その全体の内容を本願において参照により引用するものとする。本願は、いくつかの局面において、同じ権利者が所有する２００７年４月２３日出願の同時係属特許出願第１１／７３８７２３号、名称「異機種画像処理システム（ＨＥＴＥＲＯＧＥＮＥＯＵＳ ＩＭＡＧＥ ＰＲＯＣＥＳＳＩＮＧ ＳＹＳＴＥＭ）」、代理人整理番号ＥＮＤ９２００７０１１０ＵＳ１に関するものであり、その全体の内容を本願において参照により引用するものとする。また、本願は、いくつかの局面において、同じ権利者が所有する２００７年４月２３日出願の同時係属特許出願第１１／７３８７１１号、名称「異機種画像処理システム（ＨＥＴＥＲＯＧＥＮＥＯＵＳ ＩＭＡＧＥ ＰＲＯＣＥＳＳＩＮＧ ＳＹＳＴＥＭ）」、代理人整理番号ＥＮＤ９２００７０１１１ＵＳ１に関するものであり、その全体の内容を本願において参照により引用するものとする。

ウェブ１．０は、歴史的にはワールド・ワイド・ウェブ（Ｗｏｒｌｄ Ｗｉｄｅ Ｗｅｂ）と称され、元々は、コンピュータを接続して、コンピュータにとって技術をより効率的なものとすることに関するものであった。ウェブ２．０／３．０は、コンテキスト的な関係を構築するコミュニティおよびソーシャル・ネットワークを網羅するものとされ、知識の共有および仮想ウェブ・サービスを促進するものである。従来のウェブ・サービスは、超シン・クライアント（ｖｅｒｙ ｔｈｉｎ ｃｌｉｅｎｔ）であると考えることもできる。すなわち、ブラウザがサーバによって中継された画像を表示し、重要な各ユーザ・アクションがサーバへ通信されて処理に供される。ウェブ２．０は、クライアントにおけるソフトウェア層からなる社会的な対話であるので、ユーザは迅速なシステム応答を得る。データのフロントエンド記憶および取り出しが背景において非同期で行われるので、ユーザはネットワークを待つ必要がない。ウェブ３．０は、仮想世界におけるなどの３次元バージョンを目指している。これは、共有する３次元を使用して接続および共同するための新たなやり方を切り開くことができよう。このような方針に沿って、ウェブ３．０は、いくつかの別個のパスに沿ったウェブの使用法および対話の進化を表す。これには、ウェブのデータベースへの変換や、コンテンツをブラウザ以外の複数のアプリケーションによってアクセス可能にする動きが含まれる。

残念なことに、従来のサーバは、ウェブ３．０の特性を効率的に取り扱うことができない。この問題に対する既存の取り組みはない。以上に鑑み、この不備を解決する取り組みが必要である。

本発明は、（特に）１組の（１つ以上の）バックエンド・サーバ（例えば、メインフレーム）と、１組のフロントエンド・アプリケーション最適化プロセッサとを備えるプロセッサ‐サーバ・ハイブリッド・システムに関する。さらに、本発明の実施は、Ｉ／Ｏ接続ハイブリッド・システムを介して細粒レベルでアプリケーションの実行を分散および管理するためのサーバおよびプロセッサ・ハイブリッド・システムおよび方法を提供する。本方法によって、あるシステムをシステム機能の管理および制御のために使用することができ、１つ以上の他のシステムをサーバ機能に関するフロントエンド・コプロセッサまたはアクセラレータとして機能させることができる。アプリケーション最適化プロセッサは、リアルタイムのストリームの処理、高スループットでのビットおよびバイト計算、およびサーバによって容易に取り扱うことができるトランザクションへのストリームの変換をうまく行うことができる。サーバは、リソース管理、作業負荷管理、およびトランザクション処理をうまく行うことができる。

本発明によって、サーバ管理および制御システム構成要素を再使用することができ、仮想ウェブまたはゲーム処理構成要素などのアプリケーションをフロントエンド・コプロセッサ上で実行することができる。システム構成要素は、異なるオペレーティング・システムを使用して実行可能である。（複数の）サーバは、通常のトランザクション・ベースの計算リソースとして機能するが、そのために、このようなトランザクションは、リアルタイムのストリーミング・データまたはそれを通る他のマルチモードのデータからフロントエンド・プロセッサによって構成される。プロセッサは、そのような機能を取り扱うためにフロントエンドに配置される。従来のトランザクション処理に加えて、（複数の）サーバは、特定プロセッサ選択機能、ならびに例えばセル・コプロセッサなどのアプリケーション最適化プロセッサのセットアップ、制御、および管理機能をも行うことになろう。

本発明の第１の局面は、データを処理するためのプロセッサ‐サーバ・ハイブリッド・システムを提供するものであって、外部ソースからデータを受信および処理するための１組のフロントエンド・アプリケーション最適化プロセッサと、データを処理して、処理済みデータを１組のフロントエンド・アプリケーション最適化プロセッサへ返すための１組のバックエンド・サーバと、１組のネットワーク・インターコネクトを有し、１組のバックエンド・サーバを１組のフロントエンド・アプリケーション最適化プロセッサに接続するインターフェースとを備える。

本発明の第２の局面は、データを処理するための方法を提供するものであって、フロントエンド・アプリケーション最適化プロセッサ上で外部ソースからデータを受信するステップと、フロントエンド・アプリケーション最適化プロセッサからバックエンド・サーバへ、１組のネットワーク・インターコネクトを有するインターフェースを介してデータを送信するステップと、データをバックエンド・サーバ上で処理して、処理済みデータを生じさせるステップと、フロントエンド・アプリケーション最適化プロセッサ上でバックエンド・サーバから処理済みデータを受信するステップとを含む。

本発明の第３の局面は、データを処理するためのプロセッサ‐サーバ・ハイブリッド・システムを実施するための方法を提供するものであって、フロントエンド・アプリケーション最適化プロセッサ上で外部ソースからデータを受信し、フロントエンド・アプリケーション最適化プロセッサからバックエンド・サーバへ、１組のネットワーク・インターコネクトを有するインターフェースを介してデータを送信し、データをバックエンド・サーバ上で処理して、処理済みデータを生じさせ、フロントエンド・アプリケーション最適化プロセッサ上でバックエンド・サーバから処理済みデータを受信するように動作可能なコンピュータ・インフラストラクチャを提供することを含む。

本発明のこれらおよび他の特徴は、添付の図面とともに本発明の様々な局面の以下の詳細な説明から容易に理解されるだろう。

図面は、必ずしも一律の縮尺に従っていない。図面は、概略的な表現に過ぎず、プロセッサの具体的なパラメータを表すものではない。図面は、単に本発明の典型的な実施の形態を示すものであるので、本発明の範囲を限定するものとみなされるべきではない。図面において、同様の番号付けは、同様の要素を示す。

本発明は、（特に）１組の（１つ以上の）バックエンド・サーバ（例えば、メインフレーム）と、１組のフロントエンド・アプリケーション最適化プロセッサとを備えるプロセッサ‐サーバ・ハイブリッド・システムに関する。さらに、本発明の実施は、Ｉ／Ｏ接続ハイブリッド・システムを介して細粒レベルでアプリケーションの実行を分散および管理するためのサーバおよびプロセッサ・ハイブリッド・システムおよび方法を提供する。本方法によって、あるシステムをシステム機能の管理および制御のために使用することができ、１つ以上の他のシステムをサーバ機能に関するコプロセッサまたはアクセラレータとして機能させることができる。

本発明によって、サーバ管理および制御システム構成要素を再使用することができ、仮想ウェブまたはゲーム処理構成要素などのアプリケーションをアクセラレータまたはコプロセッサとして使用することができる。システム構成要素は、異なるオペレーティング・システムを使用して実行可能である。（複数の）サーバは、通常のトランザクション・ベースの計算リソースとして機能するが、そのために、このようなトランザクションは、リアルタイムのストリーミング・データまたはそれを通る他のマルチモードのデータからフロントエンド・プロセッサによって構成される。プロセッサは、そのような機能を取り扱うためにフロントエンドに配置される。従来のトランザクション処理に加えて、（複数の）サーバは、特定プロセッサ選択機能、ならびにセル・コプロセッサのセットアップ、制御、および管理機能をも行うことになろう。プロセッサをフロントエンド上に有することによって、（特に）ストリームおよびマルチモードのデータに対するリアルタイムの予測可能な処理が提供される。これは、サーバの深みのあるキャッシュ階層によって、処理時間が変動し、高いスループットのビット、バイト、およびベクトル・データ処理となって、ストリームおよびマルチモードのデータをトランザクションに変換してバックエンド・サーバへ入力することができるからである。

図１を参照すると、本発明に係る論理図が示されている。一般的に、本発明が提供するのは、プロセッサ‐サーバ・ハイブリッド・システム１１であって、１組の（１つ以上の）バックエンド・サーバ１２（以後、サーバ１２）と、１組のフロントエンド・アプリケーション最適化プロセッサ２０（以後、プロセッサ２０）とを備える。図示のように、各サーバ１２は、典型的には、インフラストラクチャ１４（例えば、電子メール、スパム、ファイアウォール、セキュリティなど）と、ウェブ・コンテンツ・サーバ１６と、ポータル／フロントエンド１８（例えば、以下にさらに説明するようなインターフェース）とを含む。アプリケーション１９およびデータベース１８は、これらのサーバ上で動作する。このような場合、（複数の）サーバ１２は、典型的には、ニューヨーク州アーモンクのＩＢＭ社から販売されているＳｙｓｔｅｍ ｚサーバ（Ｓｙｓｔｅｍ ｚおよび関連の用語は、米国または他の国ならびにその両方におけるＩＢＭ社の商標である）となる。各プロセッサ２０は、典型的には、１つ以上のアプリケーション・プリプロセッサ２２と、１つ以上のデータベース関数プリプロセッサ２４とを含む。そのような場合、（複数の）プロセッサ２０は、典型的には、ＩＢＭ社から販売されているｃｅｌｌ ｂｌａｄｅｓ（ｃｅｌｌ，ｃｅｌｌ ｂｌａｄｅ，および関連の用語は、米国または他の国ならびにその両方におけるＩＢＭ社の商標である）となる。図示のように、プロセッサ２０は、典型的には通信方法（例えば、ＬＡＮ，ＷＬＡＮなど）を介して外部ソース１０からデータを受信する。そのようなデータは、サーバ１２のインターフェースを介して処理するためのサーバ１２へ通信される（図２に示す）。処理済みデータは、その後、さらなる処理のために、プロセッサ２０に記憶されるか、または戻されるか、あるいはその両方が行われ、さらに外部ソース１０に記憶されるか、または戻されるか、あるいはその両方が行われ得る。図示のように、プロセッサ２０は、ハイブリッド・システム１１のフロントエンドを表し、サーバ１２は、バックエンドを表す。注意すべきなのは、プロセッサ２０は、なんら前処理することなく、外部クライアント１０から直接サーバ１２へデータを直接渡してもよい。同様に、サーバ１２からの処理済みデータは、プロセッサ２０が介在することなく、外部クライアント１２へ直接送られてもよい。

本システムを、図２〜図３にさらに示す。図２は、（複数の）サーバ１２と通信する（複数の）外部ソース１０を示し、サーバ１２は、インターフェース２３を介して（複数の）プロセッサ２０と通信する。典型的には、インターフェース２３は、各サーバ１２内に実施される／含まれる入出力（Ｉ／Ｏ）ケージである。また、インターフェース２３は、ＰＣＩ（ｅｘｐｒｅｓｓ ｐｅｒｉｐｈｅｒａｌ ｃｏｍｐｏｎｅｎｔ ｉｎｔｅｒｃｏｎｎｅｃｔｓ）２５などの１組のネットワーク・インターコネクトを含む。また、インターフェース２３は、上記包含された特許出願に示されるような他の構成要素を含んでもよい。

いずれにせよ、（複数の）プロセッサ２０上でデータが（複数の）外部ソース１０から受信され、（複数の）インターフェース２３を介して（複数の）サーバ１２へ通信されることになる。一旦受信すると、（複数の）サーバ１２は、当該データを処理し、処理済みデータを（複数の）プロセッサ２０へ戻すことになり、さらに（複数の）プロセッサ２０は、同データを処理するか、（複数の）外部ソース１０へ戻すか、あるいは同データを処理し処理済みデータを（複数の）外部ソース１０へ戻すことができる。また、（複数の）プロセッサ２０は、ステージング記憶装置および処理済みデータ記憶装置を活用して、元データまたは処理済みデータあるいはその両方を記憶することができる。図３に示すように、各プロセッサ２０は、典型的には、電力処理要素（ＰＰＥ）３０と、ＰＰＥに結合された要素インターコネクト・バス（ＥＩＢ）３２と、１組の（例えば、１つまたはそれ以上の）典型的には複数の特殊目的エンジン（ＳＰＥ）３４とを含む。ＳＰＥは、データを処理するための負荷を共有する。

図４を簡単に参照すると、ハイブリッド・システム１１内の構成要素の配置を示す、より具体的な図が示されている。図示のように、（複数の）プロセッサ２０は、外部ソースＡおよびＢからデータを受信／送信し、当該データを（複数の）サーバ１２へ転送して処理に供する。そのような処理の後、処理済みデータは、（複数の）プロセッサ２０および外部ソースＡおよびＢへ戻される。また、ハイブリッド・システム１１には、ステージング記憶装置３６と、処理済みデータ記憶装置３８とがある。ステージング記憶装置３６は、処理前、処理中、または処理後、あるいはそのすべてにおいて、データを記憶するために使用することができ、処理済みデータ記憶装置は、処理済みデータを記憶するために使用することができる。

今度は図５〜図８を参照して、本発明にかかる処理例のフロー図を説明する。簡潔にするために、発明を実施するための最良の形態において、以下、サーバ１２は「Ｓ」と称し、プロセッサ２０は「Ｃ」と称する。ステップＳ１において、外部ソース（Ａ）は、Ｃに対して接続要求を行う。ステップＳ２において、接続要求は、プロセッサＣによる検証後にＳへ渡される。ステップＳ３において、Ｓは接続を受け付け、ＣはＡに接続設定完了を通知する。ステップＳ４において、ストリームＰがＡからプロセッサＣに到着する。ＣはＰ’＝Ｆ（Ｐ）を行う。式中、ＦはストリームＰに対する変換関数である。ステップＳ５において、Ｃはデータを記憶装置にセーブするか、またはそれを他の装置へ渡すか、あるいはその両方を行うことができる。ステップＳ６において、出力バイトが連続してＳへ渡される。ステップＳ７において、ＳはＰ”＝Ｕ（Ｐ’）を行う。式中、ＵはＳによって行われる変換関数である。ステップＳ８において、Ｐ”はＣへ転送して戻される。ＣはＰ^３＝Ｖ（Ｐ”）を行う。式中、ＶはステップＳ９においてプロセッサＣによって行われる変換関数である。ステップＳ１０において、Ｐ^３は連続してＢまたはＡへ転送される。加えて、ステップＳ１０において、Ａは接続終了パケット（Ｅ）を提示する。ステップＳ１１において、ＣはＥを受信し、Ｓ１２において、ＣはＥを検査する。ステップＳ１３において、Ｅは接続終了パケットであると判定される。ステップＳ１４において、入力サンプリングおよび計算が終了する。ステップＳ１５において、ＣはＳにストリーム完了を通知する。ステップＳ１６において、Ｓは計算を停止する。ステップＳ１７において、ＳはＣに計算終了を通知する。ステップＳ１８において、ＣはＢに接続終了を通知する。ステップＳ１９において、ＣはＡに対して計算完了であると応答する。

別途図示されてはいないが、以下は本発明において可能となった他の制御フローの一例である。この制御フローは、データがＡから来たりまたはＢへ転送されたりすることなく、要求がＳに対して直接Ｃによってなされる場合に有用である。これは、参照および履歴データのルックアップのために有用である。
１．Ｃは接続要求を行う。
２．接続要求は有効か？（Ｓによって行われる）
３．はいの場合、Ｓによって受け付けられる。
４．ストリームＰがＣからサーバＳに到着する（Ｐは単に、所定長を有する「ブロック」入力またはマルチモードのデータであってもよい）。
５．ＳはＦ（Ｐ）を行う。式中、ＦはストリームＰに対する変換関数である。
６．Ｆ（Ｐ）出力バイトが連続してＣへ転送されて戻される。
７．Ｃはファイル終了またはストリーム終了にあう。
８．Ｃは通信終了パケット（Ｅ）を提示する。
９．ＳはＥを検査する。
１０．Ｅは接続終了パケットか？
１１．はいの場合、Ｓにおけるサンプリング入力を停止し、計算を停止する。
１２．ＳはＣに対して計算終了であると応答する。

別途図示されてはいないが、以下は本発明において可能となったさらに他の制御フローの一例である。この制御フローは、データがＡから来たりまたはＢへ転送されたりすことなく、要求がＣに対して直接Ｓによってなされる場合に有用である。この場合、サーバＳは、接触可能な外部クライアントのリストを有する。これは、サーバＳのサービスに加入している外部クライアントに対してサーバＳがデータを「プッシュ」しなければならない場合に有用であるが（例えば、ＩＰマルチキャスト）、外部クライアントによって消費されるのに適したデータをＣが「後処理」する必要がある。
１３．Ｓは接続要求を行う。
１４．接続要求は有効か？（Ｃによって行われる）
１５．はいの場合、Ｃによって受け付けられる。
１６．ストリームＰがＳからプロセッサＣに到着する（Ｐは単に、所定長を有する「ブロック」入力またはマルチモードのデータであってもよい）。
１７．ＣはＦ（Ｐ）を行う。式中、ＦはストリームＰに対する変換関数である。
１８．Ｆ（Ｐ）出力バイトが連続してＣから外部クライアントへ「プッシュ」される。
１９．Ｓはファイル終了またはストリーム終了にあう。
２０．Ｓは通信終了パケット（Ｅ）を提示する。
２１．ＣはＥを検査する。
２２．Ｅは接続終了パケットか？
２３．はいの場合、Ｃにおけるサンプリング入力を停止し、計算を停止する。
２４．ＣはＳに対して計算終了であると応答する。

本発明において、プッシュ・モデルおよびプル・モデルの両方を使用することができる。データ・メッセージを通常のデータ・パス上で送ると共に、制御メッセージを別個の制御パス上で送ることができる。ここで、２つの別個の接続ＩＤが必要となる。制御メッセージは、データ・メッセージと共に同一のパス上で送ることもできる。この場合には、１つの接続ＩＤのみが必要である。プッシュ・モデルおよびプル・モデルは共に、別個または統一されたデータ・パスおよび制御パスで実現可能である。プッシュ・モデルは、待ち時間が問題となる短いデータに有用である。制御メッセージは、通常、データ転送に関して待ち時間の制約を有する。これは、すべてのデータがプッシュされるまでデータ・ソースであるコンピュータ・プロセッサの関与を必要とする。プル・モデルは、通常、宛先のコンピュータがソースの中央プロセッサを関与させずにソースのメモリから直接データを読み出すことができる場合の大量のデータに有用である。ここで、データの位置およびサイズをソースから宛先へ通信する際の待ち時間は、データ転送全体にわたって容易に償却可能である。本発明の好ましい一実施の形態において、プッシュおよびプル・モデルは、交換すべきデータの長さによって選択的に呼び出される。

以下のステップは、プッシュ・モデルおよびプル・モデルがどのように動作するかを示す。
動的なモデル選択
（１）ＣおよびＳは、通信を望んでいる。送信者（ＣまたはＳ）は、以下の判断を行う。
ステップ１―データは所定長であり、プッシュ閾値（ＰＴ）より小さく、あて先における受信についてリアルタイムの期限を有する可能性があるか？
ステップ２―はいの場合、「プッシュ」を用いる。
ステップ３―いいえの場合、データは、既知のサイズのないストリーミング様のものである。送信者はデータの位置アドレスなしで受信者に対して「肩たたき（ｓｈｏｕｌｄｅｒ ｔａｐｓ）」する
プッシュ閾値（Ｐｕｓｈ Ｔｈｒｅｓｈｏｌｄ：ＰＴ）は、システムの設計者が所定のアプリケーションまたはデータ型（固定長またはストリーム）用に選択可能なパラメータである。
プッシュ・モデル
Ｃは（既知であれば）データ・ブロック・サイズを用いてＳに対して肩たたきする。
Ｃはアプリケーション通信レート要件（Ｒ）をルック・アップする。
Ｃは「リンク合算プール」（Ｎ）内のリンクの番号をルック・アップする。
ＣはＮを拡張または縮小することによってＲとＮとを一致させる［リンク合体による動的割り当て］。
ＣおよびＳはデータ転送に必要なリンク数を一致させる。
ＣはデータをＳにプッシュする。
すべてのデータ（サイズは既知）が送信されてジョブが完了すると、Ｃは接続を以下のようにして終わらせることができる。
ＣはＳに対して肩たたきすることによって接続を終わらせる。
プル・モデル
Ｃはデータ・ブロック・サイズ（既知であれば）と最初のバイトのアドレス位置とを用いてＳに対して肩たたきする。
Ｃはアプリケーション通信レート要件（Ｒ）をルック・アップする。
Ｃは「リンク合算プール」（Ｎ）内のリンクの番号をルック・アップする。
ＣはＮを拡張または縮小することによってＲとＮとを一致させる［動的割り当て］。
ＣおよびＳはデータ転送に必要なリンク数を一致させる。
ＳはＣメモリからデータをプルする。
すべてのデータ（サイズは既知）が送信されてジョブが完了すると、Ｃは接続を以下のようにして終わらせることができる。
ＣはＳに対して肩たたきすることによって接続を終わらせる。

図４において、ＣおよびＳは、ステージング記憶装置３６に対するアクセスを共有する。ＣがデータセットＤをＳへ転送する必要がある場合には、以下のステップが生じなければならない。すなわち、（ｉ）ＣはＤを読み出して、（ｉｉ）リンクＬ上でＤをＳへ転送しなければならない。代わりに、Ｃは、Ｓにデータセットの名前を通知することもでき、Ｓは、ステージング記憶装置３６から直接このデータセットを読み出すこともできる。これが可能なのは、ＣおよびＳがステージング記憶装置３６を共有しているからである。これに必要なステップは、以下に列挙するとおりである。
ステップ１―Ｃはデータセットの名前および位置（データセット・デスクリプタ）を制御パスに沿ってＳに提供する。これが「肩たたき」としての役割を果たす。Ｓは、Ｃから「プッシュ」されたデータに対してポーリングすることによってこの情報を受信する。
ステップ２―Ｓはデータセット・デスクリプタを使用してＤからデータを読み出す。
ステップ１―プッシュまたはプルの実施が可能となる。
ステップ２―プルまたはプッシュの実施が可能となる。
ステップ１（プッシュ）―「制御パス」
Ｃは（既知であれば）データセットの名前および位置を用いてＳに対して肩たたきする（書き込む）。
ステップ１（プル）―「制御パス」
Ｃは（既知であれば）データ・ブロック・サイズを用いてＳに対して肩たたきする。
ＳはデータをＣメモリからプルする。
ステップ２（プル型）―「データ・パス」
ステージング記憶装置３６は、データセットの名前およびデータセットのブロック位置と共にテーブルを記憶する。
Ｓはデータセットの名前Ｄを用いてステージング記憶装置３６に対して読み出し要求を行う。
ステージング記憶装置３６は、第１のブロックに対する「ポインタ」／アドレスと共にブロックのリストをＳに提供する。
Ｓはステージング記憶装置３６からブロックを読み出す。
Ｓはデータセットの終了にあう。
Ｓは接続を終わらせる。
ステップ２（プッシュ型）―「データ・パス」
ステージング記憶装置３６は、データセットの名前およびデータセット・ブロック位置と共にテーブルを記憶する。
Ｓはデータセットの名前ＤとＳ上の受信バッファの位置／アドレスを用いてステージング記憶装置３６に対する読み出し要求を行う。
ステージング記憶装置３６の記憶コントローラは、Ｄのディスク・ブロックを直接Ｓメモリへプッシュする。
ステージング記憶装置３６は、接続を終了する。

本発明の様々な局面の上記説明は、図示および説明という目的のためになされてきた。これは、網羅的でもなく、本発明を開示されたのと同一の形式に限定するものでもなく、数多くの変形および変種が可能であることは明らかである。当業者にとって明白であるようなそのような変形および変種は、添付の請求項によって規定されるような本発明の範囲内に含まれることになる。

本発明に係るプロセッサ‐サーバ・ハイブリッド・システムの構成要素を示す箱図を示す。 本発明に係る図１のシステムのより詳細な図を示す。 本発明に係るハイブリッド・システムの（複数の）フロントエンド・アプリケーション最適化プロセッサのより具体的な図を示す。 本発明に係るプロセッサ‐サーバ・ハイブリッド・システム内の通信フローを示す。 本発明に係る方法フロー図を示す。 本発明に係る方法フロー図を示す。 本発明に係る方法フロー図を示す。 本発明に係る方法フロー図を示す。

符号の説明

１０ クライアント―社内および外部
１１ プロセッサ‐サーバ・ハイブリッド・システム
１２ バックエンド・サーバ
１４ インフラストラクチャ―メール、スパム、ファイアウォール、セキュリティ
１６ ウェブ・コンテンツ・サーバ
１７ ポータル／バックエンド
１８ データベース
１９ アプリケーション
２０ フロントエンド・アプリケーション最適化プロセッサ
２２ アプリケーション・プリ／ポストプロセッサ
２４ データベース関数プリ／ポストプロセッサ

Claims (18)

1. データを処理するためのプロセッサ‐サーバ・ハイブリッド・システムであって、
   外部ソースから前記データを受信および処理するための１組のフロントエンド・アプリケーション最適化プロセッサと、
   前記データを処理して、処理済みデータを前記１組のフロントエンド・アプリケーション最適化プロセッサへ返すための１組のバックエンド・サーバと、
   １組のネットワーク・インターコネクトを有し、前記１組のバックエンド・サーバを前記１組のフロントエンド・アプリケーション最適化プロセッサに接続するインターフェースと
   を備える、システム。
2. 前記インターフェースは、入出力（Ｉ／Ｏ）ケージである、請求項１に記載のプロセッサ‐サーバ・ハイブリッド・システム。
3. 前記１組のフロントエンド・アプリケーション最適化プロセッサの各プロセッサは、
   電力処理要素（ｐｏｗｅｒ ｐｒｏｃｅｓｓｉｎｇ ｅｌｅｍｅｎｔ：ＰＰＥ）と、
   前記ＰＰＥに結合された要素インターコネクト・バス（ｅｌｅｍｅｎｔ ｉｎｔｅｒｃｏｎｎｅｃｔ ｂｕｓ：ＥＩＢ）と、
   前記ＥＩＢに結合された１組の特殊目的エンジン（ｓｐｅｃｉａｌ ｐｕｒｐｏｓｅ ｅｎｇｉｎｅｓ：ＳＰＥ）と
   を備える、請求項１に記載のプロセッサ‐サーバ・ハイブリッド・システム。
4. 前記１組のＳＰＥは、前記データを処理するように構成される、請求項３に記載のプロセッサ‐サーバ・ハイブリッド・システム。
5. ウェブ・コンテンツ・サーバ、ポータル、アプリケーション、データベース、アプリケーション・プリ／ポストプロセッサ、およびデータベース関数プリ／ポストプロセッサをさらに備える、請求項１に記載のプロセッサ‐サーバ・ハイブリッド・システム。
6. ステージング記憶装置と、
   処理済みデータ記憶装置と
   をさらに備える、請求項１に記載のプロセッサ‐サーバ・ハイブリッド・システム。
7. データを処理するための方法であって、
   フロントエンド・アプリケーション最適化プロセッサ上で外部ソースから前記データを受信するステップと、
   前記フロントエンド・アプリケーション最適化プロセッサからバックエンド・サーバへ、１組のネットワーク・インターコネクトを有するインターフェースを介して前記データを送信するステップと、
   前記データを前記バックエンド・サーバ上で処理して、処理済みデータを生じさせるステップと、
   前記フロントエンド・アプリケーション最適化プロセッサ上で前記バックエンド・サーバから前記処理済みデータを受信するステップと
   を含む、方法。
8. 前記インターフェースは、入出力（Ｉ／Ｏ）ケージである、請求項７に記載の方法。
9. 前記フロントエンド・アプリケーション最適化プロセッサは、
   電力処理要素（ＰＰＥ）と、
   前記ＰＰＥに結合された要素インターコネクト・バス（ＥＩＢ）と、
   前記ＥＩＢに結合された１組の特殊目的エンジン（ＳＰＥ）と
   を備える、請求項７に記載の方法。
10. 前記１組のＳＰＥは、前記データを処理するように構成される、請求項７に記載の方法。
11. ウェブ・コンテンツ・サーバ、ポータル、アプリケーション、データベース、アプリケーション・プリ／ポストプロセッサ、およびデータベース・プリ／ポストプロセッサをさらに備える、請求項７に記載の方法。
12. データを処理するためのプロセッサ‐サーバ・ハイブリッド・システムを配備するための方法であって、
    フロントエンド・アプリケーション最適化プロセッサ上で外部ソースから前記データを受信し、
    前記フロントエンド・アプリケーション最適化プロセッサからバックエンド・サーバへ、１組のネットワーク・インターコネクトを有するインターフェースを介して前記データを送信し、
    前記データを前記バックエンド・サーバ上で処理して、処理済みデータを生じさせ、
    前記フロントエンド・アプリケーション最適化プロセッサ上で前記バックエンド・サーバから前記処理済みデータを受信する
    ように動作可能なコンピュータ・インフラストラクチャを提供することを含む、方法。
13. 前記インターフェースは、入出力（Ｉ／Ｏ）ケージである、請求項１２に記載の方法。
14. 前記インターフェースは、１組のバックエンド・サーバのうちの少なくとも１つのサーバにおいて具体化される、請求項１２に記載の方法。
15. 前記フロントエンド・アプリケーション最適化プロセッサは、
    電力処理要素（ＰＰＥ）と、
    前記ＰＰＥに結合された要素インターコネクト・バス（ＥＩＢ）と、
    前記ＥＩＢに結合された１組の特殊目的エンジン（ＳＰＥ）と
    を備える、請求項１２に記載の方法。
16. 前記１組のＳＰＥは、前記データを処理するように構成される、請求項１５に記載の方法。
17. ステージング記憶装置と、
    処理済みデータ記憶装置と
    をさらに備える、請求項１３に記載の方法。
18. ウェブ・コンテンツ・サーバ、ポータル、アプリケーション、データベース、アプリケーション・プリ／ポストプロセッサ、およびデータベース関数プリ／ポストプロセッサをさらに備える、請求項１３に記載の方法。

Images