JP5022382B2 - シェル・セッション - Google Patents

Description

本発明は、シェル・セッションに関する。

コマンドライン・インタプリタまたはシェル・プロセッサは、コンピュータシステムと対話するための一般的な方法である。コマンドは、キーボードからタイプされる文字（例えばテキストおよび制御文字）のシーケンスとして入力され、出力がテキストの文字列（ストリング）として受け取られる。そのようなシーケンスは通常、「何かを行う（ｄｏ ｓｏｍｅｔｈｉｎｇ）」、「どのように（ｈｏｗ）」、および「何に対して（ｔｏ ｗｈａｔ）」という形式を取る。実際には、ｄｏ ｓｏｍｅｔｈｉｎｇは動詞であり、ｈｏｗは副詞であり（例えば、コマンドを「冗長に（ｖｅｒｂｏｓｅｌｙ）」または「静かに（ｑｕｉｅｔｌｙ）」実行すべき場合）、ｔｏ ｗｈａｔは通常、コマンドが作用すべき１つまたは複数のファイルを指す。こうしたコマンドシーケンス内には、コマンドに対する入力、出力をどこに送るかを示すためのリダイレクション文字、他の制御文字などの他の文字が含まれる。

コマンドライン・インターフェースは、使用されている非常に高速な対話式インターフェースの一部であった。グラフィカル・ユーザ・インターフェース（ＧＵＩ）の出現にも関わらず、コマンドライン・シェルは、ユーザ対話なしに複雑なタスクを自動的に実行するためにユーザコマンドを容易にバッチ処理することができるので、引き続き重要な管理ツールである。現代のオペレーティング・システムは、ユーザが、直接的に、あるいはシェルに組み込まれ、またはシェルと対話するように設計されるユーティリティの助けにより、キーボードからコマンドを入力し、テキスト出力を検討することによって、システムと対話することを可能にするいくつかのコマンドライン・インタプリタをサポートする。現代のオペレーティング・システムはまた、ユーザの代わりにバッチモードでコマンドのシーケンスを実行することも可能にする。

上述のように、歴史的には、そのようなシェル・コマンド・プロセッサは文字指向である。このことは、シェル・コマンド・プロセッサがユーザから文字単位の入力を受諾し、シェルが入力を検討してそれを実行することを試みるべきであることを知らせるための特殊文字（例えば「改行」または「エンタ（Enter）」）を待機する。この文字が供給されたとき、プロセッサは、入力を構文解析し、それが正規のコマンドであるかどうかを判定し、その実行を開始する。入力が正規のコマンドでない場合、通常はエラーが返される。入力が正規のコマンドである場合、コマンドが実行され、コマンドはそれ自体の文字出力を生成することができ、それをオペレータが検討することができる。

ユーザによって使用されるパラダイムは通常、次いでシェルを「オープン」し、キーボードを介してシェルに文字を供給し、シェルがエンタキー（または使用される構文に応じた他の適切な文字）を入力として受け取ったときはいつでも、シェルは、それまでに１単位として受け取ったすべての文字を処理することを試みる。シェル・プロセッサが各単位をコマンドとして実行すると、シェルは出力をレポートする。エラーのある入力に直面した場合、プロセッサは、エラーメッセージを含む１組の文字をユーザに返すことができる。次いで、シェル・プロセッサを終了し、または現存するプログラムを終了することによってユーザがシェル・プロセッサを「閉じる」まで、このサイクルが反復される。

コンピュータがネットワーキングを介して接続されたので、そのようなコマンドをリモートに実行できることが必要となった。したがって、コマンド・プロセッサではなくキーボードがリモートであるかのようにやはり文字単位で機能する、いくつかの周知のリモート・シェル・プロトコルが開発された（例えばＴｅｌｎｅｔ、Ｓｅｃｕｒｅ Ｔｅｌｎｅｔ、Ｓｅｃｕｒｅ Ｓｈｅｌｌなど）。シェルがオープンされると、文字がやりとりされ、シェル・プロトコルは本質的に、コマンドがいつ実行されるか、あるいは実際には、何らかのコマンドがこれまで実行されたかどうかを認識しない。言い換えれば、プロトコルは単に、入力文字および出力文字をやりとりする。これにより、オペレータがある場所に居て別の場所のコンピュータに対するコマンドを実行することが可能となるが、そのような技法に関していくつかの効率問題、相互運用性問題、および他の問題が存在する。

例えば、あるコマンドは処理するための入力ストリームを必要とするので、この文字単位の手法の結果、挙動が不正確となる可能性がある場合がある。例えば、正確な文字シーケンスがコマンドまたはシェル・プロセッサによって省略される可能性がある障害シナリオ中を考える。そのような場合、入力ストリームが次のコマンドと間違われる可能性があり、または次のコマンドが前のコマンドの入力ストリームと間違われる可能性がある。一例として、それに対する入力がファイルであるコマンドを考える。コマンドを実行するためのリターン文字（例えば「エンタ」）が、ファイルからの入力文字の前に受信されない場合、ファイル内の入力文字のうちの１つ（すなわちリターン文字）が実行コマンドと間違われる可能性がある。

同様に、障害のある状態（例えば、上記の例では、リターン文字が入力文字の前に受信されること）がない場合であっても、入力文字が、他のコマンド、および／または現在実行されているコマンドの制御と間違われる状況が存在する。言い換えれば、文字単位の入力は必ずしも文字単位のコマンドおよび制御ストリームから分離されるわけではないので、コマンドまたは制御ストリングと類似の文字ストリングを伴う入力がそのような機能と間違われる可能性がある。例えば、ある文字ストリングが終了コマンドシーケンス（例えばＣｔｒｌ＾Ｘ、Ｃｔｒｌ＾Ｃなど）と同じである入力ストリングに対してコマンドが実行中である場合、処理が誤って停止される可能性がある。もちろん、間違われた入力ストリングに応じて、他のコマンドまたは制御オペレーションが、ファイルの再配置または名前変更、ファイルの削除または除去、システム全体のシャットダウン、あるいは他の有害なオペレーションなどのより問題の多い応答を引き起こす可能性がある。

さらに、シェルプロセスをリモートに操作するための現在の文字単位のプロトコルに伴う他の問題は、（１）誤りがコマンドの処理の初期に認識されないこと、および（２）こうしたシステムが通常はプラットフォーム不問または言語不問であることである。より具体的には、クライアントは単にキーボードの拡張として働くので、そのようなクライアントは通常、コマンドが正規のものであるかどうか、コマンドが実行されるかどうか、いつ実行されるか、かつ／またはどのタイプのオペレーティング・システムまたは構文がシェルプロセスで使用されるかを認識しない。したがって、間違われたコマンドまたは入力がネットワークワイヤを介して送信され、処理サイクルの初期には認識されない。さらに、ユーザは、リモート・シェルで使用される特定のタイプのプロトコル（例えばＵＮＩＸ（登録商標）シェル、ＳＳＨなど）に基づく文字使用法を知って、それを調節する必要がある。

したがって、現在のコマンドライン・シェル・プロトコルの上記およびその他の欠点および不備が、効率問題、相互運用性問題、および他の様々な問題を引き起こす。

現在のリモート・コマンドライン機構の上記で識別される不備および欠点が、本発明の例示的実施形態によって克服される。例えば、本明細書に記載の実施形態は、バイナリまたは文字指向のデータのストリームではなく、メッセージ内でバインディング機構を提供することによってコマンドライン・シェル処理セッションを確立することを実現する。この概要は、以下の詳細な説明でさらに説明する単純な形式の概念の抜粋を導入するために与えられることに留意されたい。この概要は、特許請求される主題の主要な特徴または不可欠な特徴を識別するためのものではなく、特許請求される主題の範囲を決定する助けとして使用するためのものでもない。

例示的一実施形態によれば、コマンドラインを実行するリモート・コンピューティング・システムで、シェルをオープンする要求メッセージがリモート・コマンドライン・プロセッサで受信される。次いで、バインディング機構が、実行のためにコマンドをシェルに転送する際に使用するために提供される。その後で、コマンドを実行する実行要求メッセージが受信され、実行要求メッセージは、１単位としてのコマンドとバインディング機構とを含む。

ネットワークコンピューティング環境内のクライアント装置での類似の例示的実施形態は、データのバイナリ・ストリームではなく、メッセージを使用して一連のコマンドをリモート・シェルにバインドするバインディング機構を使用することにより、コマンドのためのリモート処理セッションを確立することも実現する。この実施形態では、リモート・コマンドライン・プロセッサでシェルをオープンする要求メッセージが送信される。その後で、バインディング機構が、実行のためにシェルにコマンドを転送する際に使用するために受信される。さらに、コマンドを実行するために実行要求メッセージが送信され、実行要求メッセージは、１単位としてのコマンドと、バインディング機構とを含む。

本発明の追加の特徴および利点が以下の説明で述べられ、部分的には、その説明から明らかとなり、または本発明の実施によって知ることができる。本発明の特徴および利点は、添付の特許請求の範囲で具体的に指摘される手段および組合せによって実現し、得ることができる。本発明のこうした特徴およびその他の特徴は、以下の説明および添付の特許請求の範囲からより完全に明らかとなり、または以下で述べるように本発明の実施を実施することによって知ることができる。

本発明の上記で列挙した利点および特徴ならびに他の利点および特徴を得ることができる方式を説明するために、上記で簡潔に説明した本発明のより具体的な説明が、添付の図面に示される本発明の特定の実施形態を参照することによって与えられる。こうした図面は本発明の典型的な実施形態を示すに過ぎず、したがって本発明の範囲を限定するものとみなすべきでないことを理解して、添付の図面を使用することによって本発明をさらに具体的かつ詳細に説明する。

本発明は、（１）文字指向伝送ではなく、構造化アトミック単位としてコマンドを送達し、（２）シェル存続時間を一連のコマンドとしてモデル化し、（３）文字ではなく、特別なタイプのメッセージとしてシェル・オペレーション・フローを変更する非同期制御信号をモデル化し、（４）専用入力および出力メッセージのストリームとしてクライアントとリモート・シェルとの間のデータ交換をモデル化し、すなわちコマンドと入力／出力ストリームを混合しない方法、システム、およびコンピュータプログラム製品に及ぶ。本発明の実施形態は、以下でより詳細に論じるように、様々なコンピュータハードウェアまたはモジュールを含む専用コンピュータまたは汎用コンピュータを含むことができる。

本明細書に記載の実施形態は、シェルがコマンドを文字の単位として実行するという原理に基づく。したがって、本明細書の実施形態は、ネットワークオペレーションを行う前に、各コマンドを分離し、各コマンドを検査し、あるレベルの検証を実施し、コマンドの構造化表現をリモート・プロセッサに送達するのに十分な知能を備える送信側を提供する。より具体的には、本明細書の実施形態は、コマンドを識別し、コマンドを単一メッセージ（例えばＳＯＡＰ、ＨＴＴＰＳ、または他のタイプメッセージ）にカプセル化し、次いで単一メッセージがリモート・シェルに送信されて全体の単位として処理される機構を提供する。したがって、本明細書の実施形態は、文字指向伝送ではなく、単一の単位としてコマンドを扱う。

他の実施形態は、ユーザ入力（それが存在する場合）がコマンドを実行するための追加の情報であるが、コマンド自体とは異なる意味（semantics）を有することも考慮する。したがって、本明細書の実施形態は、そのようなユーザ提供データを１つまたは複数の入力ストリームとして扱う。同様に、実施形態は、コマンドが通常の出力とステータスまたはエラーコードとを共に放出することをさらに企図する。したがって、実施形態は、こうしたデータを出力ストリームとして扱う。あるコマンドの出力を次の入力となるように連鎖させることができるので、入力ストリームと出力ストリームとを共に指定し、それらをコマンドから分離しておくための正式な機構が本明細書で説明される。

コマンドをストリームから分離し、文字指向伝送を除去するこの２部モデルを説明する上記およびその他の実施形態は、いくつかの利点を有する。まず、ネットワークの使用がより効率的となる。ネットワークカードに関する伝送の最小単位は一般に５１２オクテット以上であるので、文字指向プロトコルでは、コマンドを組み立てる際に使用される各文字は、ネットワークパケット全体を必要とする。本明細書に記載のモデルでは、コマンドを実行する時間となった後に、実際には１つのメッセージだけが送達される。

コマンドが分離した単位であり、コマンドを実行することを試みる前に、その全体を検査することができ、アクセスおよび有効性制御リストと突き合わせてチェックすることができるので、コマンドのセキュリティおよび正確さも改善される。言い換えれば、ネットワークの送信側で一定レベルのセキュリティおよび検証を実施することができ、したがってエラーを処理サイクルの初期に認識することができる。

さらに、コマンドを単位に分離することにより、コマンドがどのようにプロセッサに送達されるかについての区別が不要になり、したがってシステム・プラットフォーム不問および言語不問となる。例えば、ＳＯＡＰを使用して、またはＨＴＴＰ要求としてコマンドを符号化して、異なるオペレーティング・システムでのシェル・プロセッサの基本的な違いからコマンドを分離することができる。一方、文字指向プロトコルは、オペレーティング・システムの挙動を直接反映し、したがって、ユーザは、リモート・シェルで使用される言語または構文を理解することが求められる。

さらに別の実施形態は、シェル・オペレーション・フローを変更する、ある特殊なケースの非同期制御信号を提供する。例えば、ユーザが進行中のコマンドの早期終了を望む場合、一般にあるタイプの「コントロール・ブレーク（control-break）」または他の文字ストリングがコマンドシェル内に存在している。したがって、本明細書に記載の実施形態は、この制御信号および他の制御信号を、入力ストリーム中の特殊文字ではなく、専用メッセージとしてモデル化する。

有利な特徴に対するより具体的な参照が、図に関してより詳細に以下で説明されるが、本発明の範囲内の実施形態は、コンピュータ実行可能命令またはデータ構造を担持し、またはそれが格納されたコンピュータ可読媒体も含む。そのようなコンピュータ可読媒体は、汎用コンピュータまたは専用コンピュータでアクセスすることのできる入手可能などんな媒体でもよい。例えば、限定はしないが、そのようなコンピュータ可読媒体は、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、ＣＤ−ＲＯＭ、または他の光ディスクストレージ、磁気ディスクストレージまたは他の磁気記憶装置、あるいはコンピュータ実行可能命令またはデータ構造の形の所望のプログラムコード手段を担持または格納するのに使用することができ、汎用コンピュータまたは専用コンピュータでアクセスすることのできる任意の他の媒体を含むことができる。情報がネットワークまたは別の通信接続（ハードワイヤード、ワイヤレス、あるいはハードワイヤードまたはワイヤレスの組合せ）を介してコンピュータに転送または提供されるとき、コンピュータは適切に、接続をコンピュータ可読媒体と見る。したがって、そのような任意の接続は、正当に、コンピュータ可読媒体と呼ばれる。上記の組合せもコンピュータ可読媒体の範囲内に含まれるべきである。

コンピュータ実行可能命令は、例えば、一定の機能または機能のグループを汎用コンピュータ、専用コンピュータ、または専用処理装置に実行させる命令およびデータを含む。構造的特徴および／または方法論的動作に特有の術語で主題が説明されているが、「添付の特許請求の範囲」で定義される主題は必ずしも上述の特定の特徴または動作に限定されないことを理解されたい。むしろ、上述の特定の特徴および動作は、特許請求の範囲を実施するための例示的形態として開示される。

本明細書では、「モジュール」または「コンポーネント」という用語は、コンピューティングシステム上で実行されるソフトウェア・オブジェクトまたはルーチンを指すことがある。本明細書に記載の様々なコンポーネント、モジュール、エンジン、およびサービスを、コンピューティングシステム上で実行されるオブジェクトまたはプロセスとして（例えば別々のスレッドとして）実装することができる。本明細書に記載のシステムおよび方法は、ソフトウェアで実装されることが好ましいが、ハードウェアまたはソフトウェアとハードウェアの組合せでの実装も可能であり、企図される。この説明では、「コンピューティング・エンティティ」は、本明細書で先に定義された任意のコンピューティングシステムでよく、またはコンピューティングシステム上で動作する任意のモジュールまたはモジュレートの組合せでよい。

図１は、例示的実施形態による、リモート・コマンドライン・シェル処理のためにメッセージ・プロトコル・ハンドラを使用するように構成されたネットワークを示す。図示されるように、クライアント１０５は、ユーザがキーボードまたは類似のインターフェースを使用してコマンドを入力することを可能にするコマンドライン・インターフェース１１５を含む。例示的実施形態によれば、次いでそのようなコマンドを、メッセージ・プロトコル・ハンドラ１２５で評価および処理することができる。言い換えれば、メッセージ・プロトコル・ハンドラ１２５は、コマンドを分離し、それを検査し、以下でより詳細に説明される様々なレベルの検証および他のオペレーションを実施することのできる解釈機構(interpretation mechanism)を定義する。次いで、こうしたコマンドがメッセージ（例えばＳＯＡＰ、ＨＴＴＰＳなど）内にカプセル化され、ネットワーク１００を介してリモート１１０側に転送され、メッセージ・プロトコル・ハンドラ１３０がメッセージを処理し、さらに処理するためにコマンドライン・シェル・プロセッサ１２０にコマンドを渡す。

メッセージ・プロトコル・ハンドラ１２５の使用により、コマンドをプラットフォーム不問および言語不問の形で処理することが可能となることに留意されたい。具体的には、クライアント１０５側のメッセージ・プロトコル・ハンドラ１２５が、コマンドに関して使用される特定のタイプの構文に無関係であるメッセージ内にコマンドをカプセル化するように構成される。同様に、リモート１１０側のメッセージ・プロトコル・ハンドラ１３０は、シェル・プロセッサ１２０に関する構文とは無関係に書かれたコマンドを評価することができるが、依然として、使用されるオペレーティング・システムまたは実装される特定の言語のタイプの如何に関わらず、シェル・プロセッサ１２０がコマンドを処理することを可能にする。言い換えれば、メッセージ・プロトコル・ハンドラ１２５、１３０は、コマンドをメッセージ自体の中で定義された独立の形式に変換し、またはその独立の形式からコマンドを変換する。

言い換えれば、こうした実施形態の一態様は、リモート・プロセッサ１２０のプラットフォーム特有の特性が、プラットフォーム境界にわたって一様であるメッセージモデルの下に隠されることである。シェル存続時間（以下でより詳細に説明する）およびメッセージ（例えばＳＯＡＰ）下のコマンドの実行をモデル化することにより、シェル１２０プロセッサでの本質的かつ厄介な違いが隠される。

プラットフォーム不問および言語不問の形でコマンドを提供するために上記のハンドラ１２５、１３０を使用するものとして以下の実施形態を説明することができるが、そのような変換は、そのような実施形態を使用するのには必要ではないことに留意されたい。さらに、本明細書に記載の実施形態が一般にはネットワーク環境内のクライアントとリモート・シェル・プロセッサとの間で実装されるが、実施形態の一部をローカルマシンにも適用できることにも留意されたい。本明細書に記載の実施形態を実施およびモデル化するための任意の数のモジュールおよび構成も企図されることにも留意されたい。したがって、本明細書に記載の実施形態を実装するための、特定の符号化フォーマット、言語構文またはオペレーティング・システム、設計レイアウトの特定の使用、あるいはリモートまたは他の特定のシェルモジュールの使用はどれも例示的なものに過ぎず、具体的に主張されるのでない限り、本明細書の実施形態の範囲を限定あるいは狭めることを意味するものではない。

使用されるコンピューティングシステムのタイプの如何に関わらず、図１Ｂに示されるように、クライアント１０５がコマンド処理のためにシェル１２０をオープンしたいとき、実施形態は、コマンドシェル・プロセッサをオープンする概念を直接モデル化する構造化オープン・シェル・メッセージ１３５を発行することを可能にする。したがって、この実施形態は、オペレーティング・システム環境内でローカルに「コマンド・ウィンドウ」を開く動作を模倣する。次いで、メッセージ１３５をリモートマシン１１０に送達することができ、リモートマシン１１０は、「現実の」シェル１２０をローカルにオープンし、その入力および出力をリモートセッションに接続する。この初期メッセージ１３５は通常、シェル１２０に関する環境変数、デフォルト・ディレクトリ（図示せず）、および他の初期化を実施する（例えば、デフォルト変数を上書きし、コマンド挙動を制御するために新しい変数を追加するなど）ことのできる所である。

この実施形態および本明細書に記載の他の実施形態では、シェル・プロセッサ１２０で行われる処理は、そのような処理の実際の実装の挙動を模倣する仮想プロセスでよいことに留意されたい。言い換えれば、行われるオペレーションは、特定のシェル・プロセッサ１２０で生じるように見えることがある。しかし、他のモジュールまたはコンポーネントは、以下でより詳細に説明するように、コマンドを処理し、または信号制御を実施するそのような挙動を模倣する。したがって、本明細書で説明され、主張されるシェル・プロセッサ１２０またはその挙動に対するどんな参照も、実際のシェル・プロセッサの代わりに、または実際のシェル・プロセッサと同様に働く仮想マシンを含むように広く解釈すべきである。

シェル・プロセッサ１２０側で（例えばサーバ側の実装で）、シェル１２０のオープンを確認するためにオープン・シェル応答メッセージ１４０をクライアント１０５に送り戻すことができる。一実施形態では、シェル１２０を識別する識別子１４２またはトークンをメッセージ１４０に添付することができることに留意されたい（例えば、図示する例では、シェルＩＤ＝１２３）。したがって、以下でより詳細に説明するように、バインディング機構１４２の使用（すなわち識別子１４２またはシェルトークン）をセッションの存続時間全体にわたって使用することができる。これにより、シェル・プロセッサ１２０セッション（その存続時間）を、一連の文字ではなく、一連のコマンドとしてモデル化することが可能となることに留意されたい。さらに、この機構は、いくつかのシェル１２０セッションをオープンすることも可能にし、それによって複数のコマンドシリーズの同時処理が可能となることに留意されたい。さらに、シェル・セッションに関するバインディング機構（すなわち識別子１４２またはシェルトークン）がメッセージ内で送信されるので、現在のシェル・セッションのバイナリまたは文字単位の確立に関連する問題が克服されることに留意されたい。

それでも、本明細書に記載のいくつかの実施形態は、本明細書に記載のセッション・バインディング１４２機構またはモデル化を必ずしも必要としないことに留意されたい。例えば、単一のセッションまたはシェルプロセス１２０のみが確立される場合、シェルＩＤ１４２またはトークンの使用は不要であることがある。したがって、セッションを確立するためのシェル識別子またはトークンの使用は、本明細書では例示のために使用されるに過ぎず、明示的に主張されるのでない限り、本明細書に記載の実施形態の範囲を制限することを意味するわけではない。

セッションを作成または確立するのにシェル識別子１４２が使用されるか否かに関わらず、図１Ｃに示されるように、実施形態は、コマンドシェル・プロセッサ１２０にコマンドを発行するとき、クライアント１０５アプリケーションが、コマンドの名前、その切替え、および首尾よく実行するために必要な他の情報を含む完全なコマンドライン単位１４７を送信側で構成することができることを実現する。言い換えれば、前述のように、本明細書の実施形態は、コマンド１４７を識別し、それを検査し、それに対して何らかの検証および他の高レベル処理を実施し（例えば、アクセスまたは検証制御リストと突き合わせて比較する）、コマンド１４７単位を実行コマンド・メッセージ１４５としてカプセル化し、処理のためにコマンド１４７をシェル・プロセッサ１２０に送信する。したがって、本明細書の実施形態は、文字指向伝送モデルに依拠するコマンドシェル・プロトコルの既存の実装ではなく、メッセージ指向プロトコルを使用してコマンド１４７を構造化アトミック単位として送達する。

ここで示されるコマンドは単一の「コピー」コマンドであることに留意されたい。しかし、他のタイプのコマンド、さらにはコマンドの組合せをメッセージに含めることができる。例えば、実行コマンド・メッセージ１４５は、あるコマンドの出力が他のコマンドの入力にパイプされる複数のコマンド１４７を含むことができる。しかし、通常は、１つのコマンドだけが単一のメッセージ内に含まれる。１つまたは複数のコマンドがメッセージ１４５内に含まれるかどうかの如何に関わらず、コマンドを全体の単位として表現すべきであり、すなわち、コマンドは、コマンド１４７の部分的表現のみを含むべきではない。したがって、メッセージ１４５内の任意の特定のタイプまたは任意の数のコマンド１４７は例示のために本明細書で説明した過ぎず、明示的に主張されるのでない限り、実施形態の範囲を限定し、または狭めるべきではない。

さらに、実行コマンド・メッセージ１４５（ならびに本明細書に記載の他のメッセージ）は、任意のタイプの周知のフォーマット、例えばＨＴＭＬ（ＨｙｐｅｒＴｅｘｔ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）、ＸＭＬ（ｅＸｔｅｎｓｉｂｌｅ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）などでよいことに留意されたい。さらに、コマンド１４７（および本明細書に記載の他の要素）をメッセージの任意の部分、例えばヘッダ、本文、または他のフィールドに配置することができる。シェルのセッションまたは存続時間が識別子またはトークン１４２を使用して確立される場合、実行コマンド・メッセージ１４５は、どのシェル１２０がオペレーションを実行すべきかを識別するトークン１４２も含むべきであることにも留意されたい。

実行コマンド・メッセージ１４５に応答して、通常はシェル・プロセッサ１２０が実行応答メッセージ１５０を発行する。以下でより詳細に説明するように、実行応答メッセージ１５０は、メッセージ出力の一部でよいことに留意されたい。例えば、実行応答メッセージ１５０は単に、ステータスコード、エラー、またはコマンド１４７が実行され、または実行されなかったかを示す他の確認メッセージでよい。以下でより詳細に説明するように、実行応答１５０は、コマンド１４７に対する特定の入力および出力を識別またはバインドするなどの事柄に使用することのできるコマンド識別子またはトークン１５２（この例ではコマンドＩＤ ４５６として示す）を含むことができる。

しかし、シェル識別子と同様に、コマンドトークン１５２は本明細書に記載のいくつかの実施形態に対しては不要であることに留意されたい。例えば、複数のコマンド１４７がセッション内で実行されていない場合、かつ／または入力／出力が生成されない場合、そのようなコマンド識別子１５２は不要であることがある。さらに、実行応答１５０も、必要に応じて、前述のように、シェル識別子１４２を含むことがあり、または含まないことがあることにも留意されたい。

それでも、図１Ｄに示されるように、大部分のコマンドは、出力、および最終的には何らかの種類の最終ステータス（例えばステータスコード、エラーコード、または前述の他の確認メッセージ）を放出するので、クライアント１０５は、コマンド１４７の実行によって生成されたどんな出力１６０の抽出も開始すべきである。一実施形態によれば、このプロセスは図示するようにループとして行われ、出力１６０の１つまたは複数のストリーム（例えば標準出力ストリーム、標準エラーストリーム、または他の出力ストリーム）がクライアント１０５によって受信され、読取り出力メッセージ１５５を使用して確認される。

通常、クライアント１０５は、コマンド１４７の実行によって放出される任意のストリーム（例えばストリーム「Ａ」、「Ｂ」、「Ｃ」など）に関する出力１６０がなくなるまで、上述のループを反復し続ける。一実施形態では、コマンド１４７によって放出される各ストリーム（例えばストリーム「Ａ」、「Ｂ」、「Ｃ」など）の出力１６０がメッセージブロック１６０内で分離される。ある時点で、ストリーム「Ｃ」にあるように、通常はｅｎｄ−ｏｆ−ｓｔｒｅａｍマーカが存在し、クライアント１０５がそのストリームについてそれ以上の出力を取得しないことを意味する（出力内のすべてのストリームおよび／またはそのようなストリームまたは任意選択に対する終了を示すのにｅｎｄ−ｏｆ−ｓｔｒｅａｍマーカを使用でき、それによってコマンドが終了した場合、例えば応答で終了コードを返す場合にストリームに終了を示唆することができることに留意されたい）。最終的に、コマンド１４７の処理に関係するすべてのストリームがｅｎｄ−ｏｆ−ｓｔｒｅａｍマーカを放出することになり、ｅｎｄ−ｏｆ−ｃｏｍｍａｎｄマーカが応答メッセージ１６０内に現れる。さらに、実施形態は、クライアント１０５に出力することのできるストリームのタイプの構成を可能にし、例えばストリーム「Ａ」を真にセットし、ストリーム「Ｂ」を偽にセットすることができることに留意されたい。

コマンド１４７がその出力１６０を放出することによって終了すると、クライアント１０５は、前述のように別のコマンド１４７を発行することができる。それでも、前述のように、ある実施形態は、複数のコマンド１４７が同一のシェル１２０インスタンスに対して、場合によっては複数のシェル１２０セッションに対して同時に実行されることも可能にする。

各出力文字を通信するための複数のラウンドトリップ(round trip)の代わりに、出力１６０が文字のチャンク（塊、chunk）として取り出されることに留意されたい。したがって、所与の応答１６０は、典型的なコマンドシェル・プロトコルの文字指向伝送とは対照的に、１つまたは多数のストリームに関する大量のデータを有することができる。したがって、表示および他の用途のために出力１６０がより効率的に受信および処理される。さらに、前述のように、通常は、必要ならば、出力メッセージ１６０は、シェル識別子１４２および／またはコマンド識別子１５２を含むべきであることに留意されたい。そのような場合、複数のシェル１２０セッションでコマンド１４７の複数の実行に対する複数の出力をクライアント１０５は受信していることがあり、シェル・プロセッサ１２０はそれを生成していることがある。さらに、以下でより詳細に説明するように、そのような出力１６０ストリームを生成されたレートで動的に調節し、様々な考慮すべき点に基づいて、かつ受信された入力に対して送信することができる。

前述のように、あるコマンド１４７は入力も必要とすることがある。そのような場合、図１Ｅに示されるように、本明細書の実施形態は、コマンド実行メッセージ１４５（すなわちコマンド１４７）がシェル・プロセッサ１２０に送信された後に入力ストリーム１６５をコマンド１４７に「供給」することを可能にする（しかし、コマンドおよび入力を依然として別々に保つことができると共に識別可能であるとき、例えばヘッダ内にコマンドがあり、本文内に入力があるＳＯＡＰメッセージなどで、ある実施形態は入力もコマンド実行メッセージ１４７に含めることを可能にすることに留意されたい）。コマンド識別子またはトークン１５２が使用される場合、入力は通常、コマンドＩＤ１５２が認識された後に送信される。さらに、シェル識別子１４２が使用される場合、適切なシェル１２０セッションを識別するためにそのような識別子１４２が入力１６５内に含まれるべきである。上述の出力ストリーム１６０と同様に、入力１６５のストリーミングは、任意のストリーム（例えばストリーム「Ａ」、「Ｂ」、「Ｃ」など）に対するコマンド１４７に供給される入力データがなくなるまで、ループ型で行われる。言い換えれば、シェル・プロセッサ１２０に首尾よく送達された書込み入力メッセージ１６５内の入力データのストリームに関して、確認メッセージ１７０がクライアント１０５によって受信され、クライアント１０５は、すべての入力が受信されたと確認されるまで（１７０）、入力１６５をシェル・プロセッサ１２０に継続的にストリーミングする。さらに、実施形態は、入力される可能性のあるストリームのタイプを構成することを可能にし、例えばストリーム「Ａ」を真にセットし、ストリーム「Ｂ」を偽にセットすることができる。

出力ストリーム１６０と同様に、各入力を文字単位で通信するのではなく、入力が文字のチャンクとして送信されることに留意されたい。したがって、所与の書込み入力メッセージ１６５は、典型的なコマンドシェル・プロトコルの文字指向伝送とは対照的に、１つまたは多数のストリームに関する大量のデータを有することができる。したがって、入力がより効率的に受信および処理される。さらに、前述のように、必要ならば、入力メッセージ１６５は、シェル識別子１４２および／またはコマンド識別子１５２を含むべきであることに留意されたい。そのような場合、シェル・プロセッサ１２０は、複数のシェル１２０セッションで複数のコマンド１４７に対する複数の入力を処理していることがある。

読取り出力メッセージ１５５と共に既に上記で説明したように、他の実施形態は、出力１６０を抽出するために入力１６５の処理が非同期かつ同時に行われることを可能にする。したがって、あるコマンド１４７が出力１６０を生成するよりも高速／低速なレートで入力１６５を要求することがあるので、本明細書の実施形態は、それに応じて入力出力レートを静的または動的に調節することができる。言い換えれば、入力１６５メッセージフローと出力１６０メッセージフローとの間にインピーダンス不整合が存在することがある。さらに、タイムアウト問題、帯域幅問題、好ましいストリームなどの任意の数の問題に基づいてフローを静的または動的に調節することができる。さらに、ヒントメッセージ、構成設定、または任意の他の周知の機構に基づいて入力１６５または出力１６０のフローを調節することができる。

さらに別の他の実施形態は、シェル１２０オペレーションフローのフローを非同期に制御または変更するための特別なメッセージの使用を可能にする。例えば、図１Ｆに示されるように、信号メッセージ１７５を使用して、コマンドの実行を終了、停止、再開、あるいは修正することができる。言い換えれば、ユーザがコマンド１４７の実行状態を変更したい場合、クライアント１０５は、信号メッセージ１７５を作成して、そのようなメッセージをシェル・プロセッサ１２０に送信することができ、シェル・プロセッサ１２０は、望み通りに適切な処置を取る。制御または信号コマンドを離散的メッセージ１７５としてモデル化することにより（ならびに本明細書でモデル化され、説明される他の実施形態）、そのようなコマンドは、文字単位伝送を使用するプロトコルについて先に述べたように、コマンドに対して誤って実行されない。

本明細書に記載の他のプロセスと同様に、コマンド１４７の状態を示す信号応答メッセージ１８０をクライアントに返すことができる。そのような応答メッセージ１８０は、コマンド１４７のステータス、望まれる修正または変更のタイプ１７５（例えば、そのような修正が正規のものである否か）などの事柄に基づくエラーまたは他のタイプの確認メッセージ１８０でよいことに留意されたい。コマンド識別子１４２および／またはセッション識別子１５２が使用される場合、信号メッセージ１７５および応答１５２は通常、適切な処理のために適切なトークンを含むべきであることにも留意されたい。信号識別子（および本明細書に記載の他の識別子）をメッセージの任意の部分に含めることができ、それがコードとして現れることができ、特定のフィールド内のフラグでよく、または他の同様の周知の方式で識別することができる。

クライアント１０５がシェル１２０をもはや必要としないとき、図１Ｇに示されるように、実施形態は、クローズ・シェル・メッセージ１８５を送信することによってシェルのクローズも可能にする。前述のようにセッションが確立される場合、クローズ・シェル・メッセージ１８５はシェル識別子１４２（Ｓｈｅｌｌ ＩＤ＝１２３として示す）を含むべきである。いずれにしても、シェル・プロセッサ１２０がシェル１８５をクローズする要求を受信したとき、当然ながらエラーが生じなかったことを条件として、シェル・セッション１２０は終了し、適切な状態またはクローズシェル応答１９０をクライアント１０５に返すことができる。

上記の実施形態では、識別されるメッセージの様々な部分を、任意の周知のｕｎｉｆｏｒｍ ｒｅｓｏｕｒｃｅ ｉｄｅｎｔｉｆｉｅｒ（ｕｒｉ）を使用して表すことができる。例えば、任意の周知のｕｒｉを使用して、コマンド１４７、オープン／クローズセッション、シェル識別子１４２、コマンドトークン１５２、信号識別子（例えば終了、停止、再開など）、およびメッセージの他の部分を識別することができる。したがって、この実施形態は、シェルプロセス内のコマンドラインを実行する際に使用される任意の特定のプラットフォームまたは構文からの別の層の抽象化を可能にする。

本発明は、機能的ステップおよび／または非機能的動作を含む方法として説明することもできる。以下は、本発明を実施する際に実施することのできるステップおよび／または動作の説明である。通常、機能的ステップは、実施される結果の点で本発明を記述するのに対して、非機能的動作は、特定の結果を達成するためのより具体的動作を記述する。機能的ステップおよび／または非機能的動作を特定の順序で記述または主張することがあるが、本発明は、何らかの特定の順序あるいはステップおよび／または動作の組合せに必ずしも限定されない。さらに、請求項の列挙でのステップおよび／または動作の使用は、そのような用語の所望の特定の使用を示すのに使用される。

図２に、本発明の様々な例示的実施形態に関する流れ図を示す。図２の以下の説明は、図１Ａ〜Ｇの対応する要素を時折参照する。これらの図の特定の要素に参照を行うことがあるが、そのような参照は、例示のために使用されるに過ぎず、明示的に主張されるのでない限り、記載の実施形態の範囲を限定し、または狭めることを意味するものではない。

図２は、例示的実施形態による、リモート・シェルでコマンドラインを実行する際に使用されるプロトコルについての流れ図である。図２の流れ図は、流れ図の中の深さ、および流れ図のどちらの側を説明しているか、すなわちクライアント２１０か、それともコマンドライン・シェル・プロセッサ２２０かなどの事柄に応じて、複数の方法（例えば２００、２０５）に関する説明を含むことに留意されたい。したがって、流れ図の以下の説明は、何らかの特定の方法を対象とすることを意味するわけではなく、以下のうちの１つまたは複数を実施するのに使用される実施形態を一般的に説明するのに使用される。（１）文字指向伝送ではなく、構造化アトミック単位としてコマンドを送達すること、（２）シェル存続時間を一連のコマンドとしてモデル化すること、（３）文字ではなく、特別なタイプのメッセージとしてシェル・オペレーション・フローを変更する非同期制御信号をモデル化すること、および（４）専用入力および出力メッセージのストリームとして、すなわちコマンドと入力／出力ストリームを混合せずに、クライアントとリモート・シェルとの間のデータ交換をモデル化すること。

実施形態は、シェルをオープンする要求を送信／受信する（２１５／２２５）ことを実現する。例えば、クライアント１０５は、オープン・シェル要求メッセージ１３５をシェル・プロセッサ１２０に送信することができる。セッションを確立すべきである場合、上述のように、実施形態は、シェル識別子を送信／受信する（２３５／２３０）ことを実現する。より具体的には、オープン・シェル・メッセージ１３５の受信時に、シェル・プロセッサは、前述のように、シェルトークンまたは識別子１４２を含むオープン・シェル応答１４０を送信することができる。その後に、クライアント側２１０は、コマンドライン・シェル・プロセッサ２２０でリモートに実行すべきコマンドを識別し（２４０）、コマンドをメッセージに添付する（２４５）。例えば、クライアント１０５は、コマンド１４７を識別することができ、シェル・プロセッサ１２０に送信するためにコマンド１４７を実行コマンド・メッセージ１４５内に含めることができ、シェル・プロセッサ１２０は通常はクライアント１０５から離れている。シェル・セッションが確立される場合、実行コマンド・メッセージ１４５はシェル識別子１４２を含むべきであることに留意されたい。

コマンドラインプロセッサ側２２０はメッセージ１４５を受信し（２２５）、次いで実行のためにコマンド１４７を識別することができる（２６０）。その後で、コマンド識別子が使用される場合、シェル・プロセッサ１２０は、そのような識別子１５２をクライアント１０５に送信することができ（２６５）、クライアント１０５は、本明細書で説明したように、入力を送信するため、またはコマンド１４７の実行を制御するためにそのような識別子１５２を受信する（２７０）。前述のように、例示的実施形態によれば、複数のコマンド１４７実行が単一のセッションで可能であるかどうか、入力／出力が必要であるか否かなどの事柄に応じて、コマンド識別子１５２が必要なことがあり、または不要なことがある。例えば、コマンド１６５を実行するための書込み入力１６５が必要である場合、コマンド識別子１５２（および、場合によっては、さらにシェル識別子１４２）をストリーミングされる入力１６５内に含めることができ、それがシェル・プロセッサ１２０によって送信／受信される（２７５／２８０）。受信された入力に対する確認２８５（例えばエラーコードなど、１７０）を送信すべきであり（２７５）、このプロセスが、入力ストリーム１６５のすべてがシェル・プロセッサ１２０によって送信／受信されるまでループする。

コマンド１４７およびストリーミングされた入力１６５（それが存在する場合）が適切に受信されると、コマンドライン・シェル・プロセッサ側２２０は、コマンド１４７を適切に実行することができる（２９０）。したがって、適切な確認をコマンドライン・シェル・プロセッサ２２０に送信する（２１４）と共に、出力１６０をクライアント１０５に送信し（２９５）、クライアント１０５で受信することができる（２０２）。入力ストリーム１６５と同様に、すべての出力１６０がクライアント１０５によって受信され／クライアント１０５に送信されるまで、出力ループを続行すべきである。

上述のように、入力２６５ストリームおよび出力２６０ストリームを、クライアント１０５とシェル・プロセッサ１２０との間で非同期かつ同時に送信／受信することができる。さらに、無数の因子に基づいて、かつ多数の方式で、そのようなフローを静的または動的に調節することができる。例えばフローは、特定のコマンド１４７に対する一定量の出力１６０を生成するのに必要な入力１６５の量に基づくことができ、かつ／または帯域幅または他の制限に基づくことができる。さらに、ヒントメッセージ、制御設定、または他の周知の機構を介してフローを制御することができる。

ユーザがセッションを終了すると、シェル１８５をクローズする要求をコマンドライン・シェル・プロセッサ側２２０に送信し（２０４）／コマンドライン・シェル・プロセッサ側２２０で受信することができ（２０８）、シェル１２０セッションが終了したことをクライアント１０５に通知する確認１９０をクライアント側２１０に送信することができる（２１２）。他の実施形態は、コマンド１４７の状態または処理を変更するために信号メッセージ１７５（例えば終了、停止、再開など）の配布を可能することにも留意されたい。本明細書に記載の他の大部分のメッセージと同じく、信号応答１８０を使用してそのような制御メッセージ１７５を確認する（またはエラーを引き起こす）ことができる。

本発明の精神または不可欠な特徴から逸脱することなく、他の特定の形態で本発明を実施することができる。記載の実施形態は、すべての点で例示的なものに過ぎず、限定的なものではないものとして理解すべきである。したがって、本発明の範囲は、上記の説明ではなく、添付の特許請求の範囲によって示される。特許請求の範囲の均等の意味および範囲内にあるすべての変更は、その範囲内に包含されるべきである。

例示的実施形態による、リモート・コマンドライン・シェル処理のためにメッセージ・プロトコル・ハンドラを使用するネットワークを示す図である。 例示的実施形態による、コマンド・セッションを確立するためのオープン・メッセージおよびリターン・シェル識別子の使用を示す図である。 例示的実施形態による、メッセージを使用して、実行のためにシェル・プロセッサにコマンド単位を送信することを示す図である。 例示的実施形態による、実行されるコマンドに関する出力のストリーミングを示す図である。 例示的実施形態による、コマンド・メッセージからの入力ストリームメッセージの分離を示す図である。 例示的実施形態による、シェル・セッションに関する制御オペレーションを送信するためのメッセージの使用を示す図である。 例示的実施形態による、コマンド・セッションを終了するためのクローズ・メッセージの使用を示す図である。 例示的実施形態による、リモート・シェルでコマンドラインを実行する際に使用されるプロトコルに関する流れ図を示す図である。

Claims (20)

1. ネットワークコンピューティング環境内のリモート装置で、一連のコマンドをシェルにバインドするために、データのバイナリ・ストリームではなく、メッセージ内にバインディング機構を提供することによってコマンドライン・シェル処理セッションを確立する方法であって、
   リモート・コマンドライン・シェル・プロセッサでシェルをオープンする要求メッセージを、クライアントから受信するステップと、
   前記シェルをオープンするステップと、
   前記シェルがオープンされたことの確認応答として、実行のためにコマンドを前記シェルに転送する際に使用されるバインディング機構を提供するオープン・シェル応答メッセージを、前記リモート・コマンドライン・シェル・プロセッサから送信するステップと、
   １単位としてのコマンドと前記バインディング機構とを含む実行要求メッセージを受信してコマンドを実行するステップと
   を備え、前記実行要求メッセージは、複数のコマンドを含むことができ、前記クライアントと前記リモート・コマンドライン・シェル・プロセッサとの間のデータ交換は、コマンドを含む前記実行要求メッセージとは別に専用の入力メッセージおよび出力メッセージのデータの１つまたは複数のストリームを送受信することを含み、前記入力メッセージのデータの１つまたは複数のストリームは、前記リモート・コマンドライン・シェル・プロセッサにおいてコマンドを実行するための入力として前記クライアントから受信され、前記出力メッセージのデータの１つまたは複数のストリームは、前記リモート・コマンドライン・プロセッサにおけるコマンドの実行結果として前記リモート・コマンドライン・シェル・プロセッサによって前記クライアントに送信されることを特徴とする方法。
2. 前記バインディング機構は、シェル識別子、シェルトークン、またはその両方であることを特徴とする請求項１に記載の方法。
3. 前記受信した実行要求メッセージに応答して、
   前記コマンドの実行に関係する入力、出力、または他の信号メッセージを識別する際に使用されるコマンド識別子を含む実行応答メッセージを送信するステップを
   さらに備えることを特徴とする請求項１に記載の方法。
4. 前記実行応答メッセージは、前記コマンドの実行のステータスレポートを含むことを特徴とする請求項３に記載の方法。
5. 前記入力メッセージは、前記バインディング機構とコマンド識別子とを共に含むことを特徴とする請求項１に記載の方法。
6. 前記出力メッセージは、前記バインディング機構とコマンド識別子とを共に含むことを特徴とする請求項１に記載の方法。
7. 前記シェルのオペレーション・フローを変更するために前記バインディング機構とコマンド識別子とを共に含む１つまたは複数の非同期信号メッセージを受信し、それにより前記コマンドの実行を終了、休止、再開、退出、または遅延させるステップを
   をさらに備えることを特徴とする請求項１に記載の方法。
8. 前記入力メッセージのデータの１つまたは複数のストリームに関するフローのレートは、前記出力メッセージのデータの１つまたは複数のストリームに関するフローのレートに対して動的に調節されることを特徴とする請求項１に記載の方法。
9. ネットワークコンピューティング環境内のリモート装置で、データのバイナリ・ストリームではなく、メッセージを使用して一連のコマンドをリモート・シェルにバインドするバインディング機構を使用することによってコマンドに関するリモート処理セッションを確立する方法であって、
   リモート・コマンドライン・シェル・プロセッサにシェルをオープンする要求メッセージを送信するステップと、
   前記シェルがオープンされたことの確認応答として、実行のためにコマンドを前記シェルに転送する際に使用されるバインディング機構を含むオープン・シェル応答メッセージを、前記リモート・コマンドライン・シェル・プロセッサから受信するステップと、
   実行すべき１単位としてのコマンドと前記バンディング機構とを含む実行要求メッセージを前記リモート・コマンドライン・シェル・プロセッサに送信するステップと
   を備え、前記実行要求メッセージは、複数のコマンドを含むことができ、クライアントと前記リモート・コマンドライン・シェル・プロセッサとの間のデータ交換は、コマンドを含む前記実行要求メッセージとは別に専用の入力メッセージおよび出力メッセージのデータの１つまたは複数のストリームを送受信することを含み、前記入力メッセージのデータの１つまたは複数のストリームは、コマンドの実行に入力を必要とするときに前記クライアントによって送信され、前記出力メッセージのデータの１つまたは複数のストリームは、前記リモート・コマンドライン・プロセッサにおけるコマンドの実行結果として前記クライアントにおいて受信されることを特徴とする方法。
10. 前記バインディング機構は、シェル識別子、シェルトークン、またはその両方であることを特徴とする請求項９に記載の方法。
11. 前記送信した実行要求メッセージに応答して、
    前記コマンドの実行に関係する入力、出力、または他の信号メッセージを識別する際に使用されるコマンド識別子を含む実行応答メッセージを受信するステップを
    さらに備えることを特徴とする請求項９に記載の方法。
12. 前記実行応答メッセージは、前記コマンドの実行のステータスレポートを含むことを特徴とする請求項１１に記載の方法。
13. 前記入力メッセージは、前記バインディング機構とコマンド識別子とを共に含むことを特徴とする請求項９に記載の方法。
14. 前記出力メッセージは、前記バインディング機構とコマンド識別子とを共に含むことを特徴とする請求項９に記載の方法。
15. 前記シェルのオペレーション・フローを変更するために前記バインディング機構とコマンド識別子とを共に含む１つまたは複数の非同期信号メッセージを受信し、それにより前記コマンドの実行を終了、休止、再開、退出、または遅延させるステップを
    さらに備えることを特徴とする請求項９に記載の方法。
16. 前記入力メッセージのデータの１つまたは複数のストリームに関するフローのレートは、前記出力メッセージのデータの１つまたは複数のストリームに関するフローのレートに対して動的に調節されることを特徴とする請求項９に記載の方法。
17. ネットワークコンピューティング環境内のリモート装置で、一連のコマンドをシェルにバインドするために、データのバイナリ・ストリームではなく、メッセージ内にバインディング機構を提供することによってコマンドライン・シェル処理セッションを確立する方法を実行させるコンピュータプログラムであって、リモート・コマンドライン・シェル・プロセッサを備えたリモート装置に、
    前記リモート・コマンドライン・シェル・プロセッサでシェルをオープンする要求メッセージを、クライアントから受信するステップと、
    前記シェルをオープンするステップと、
    前記シェルがオープンされたことの確認応答として、実行のためにコマンドを前記シェルに転送する際に使用されるバインディング機構を提供するオープン・シェル応答メッセージを、前記リモート・コマンドライン・シェル・プロセッサから送信するステップと、
    １単位としてのコマンドと前記バインディング機構とを含む実行要求メッセージを受信してコマンドを実行するステップと
    を実行させ、前記実行要求メッセージは、複数のコマンドを含むことができ、前記クライアントと前記リモート・コマンドライン・シェル・プロセッサとの間のデータ交換は、コマンドを含む前記実行要求メッセージとは別に専用の入力メッセージおよび出力メッセージのデータの１つまたは複数のストリームを送受信することを含み、前記入力メッセージのデータの１つまたは複数のストリームは、前記リモート・コマンドライン・シェル・プロセッサにおいてコマンドを実行するための入力として前記クライアントから受信され、前記出力メッセージのデータの１つまたは複数のストリームは、前記リモート・コマンドライン・プロセッサにおけるコマンドの実行結果として前記リモート・コマンドライン・シェル・プロセッサによって前記クライアントに送信されることができることを特徴とするコンピュータプログラム。
18. 前記バインディング機構は、シェル識別子、シェルトークン、またはその両方であることを特徴とする請求項１７に記載のコンピュータプログラム。
19. 前記受信した実行要求メッセージに応答して、前記リモート・コマンドライン・シェル・プロセッサに、
    前記コマンドの実行に関係する入力、出力、または他の信号メッセージを識別する際に使用されるコマンド識別子を含む実行応答メッセージを送信させるステップを
    さらに実行させることを特徴とする請求項１７に記載のコンピュータプログラム。
20. 前記入力メッセージおよび前記出力メッセージはそれぞれ、前記バインディング機構とコマンド識別子とを共に含むことを特徴とする請求項１７に記載のコンピュータプログラム。

Images