Java RMI などの、現在の分散オブジェクトテクノロジーの中にはサーバーからクライアントオブジェクトにコールバックしてフィードバックを提供できるものもありますが、クライアントのフィードバック方法には明らかに問題があります。

まず、このアプローチでは、クライアントがフィードバック呼び出しを受け取るオブジェクトを作成する必要があるので、操作からフィードバックを論理的に分離する処理を強制的に行います。これらのオブジェクトでは、操作に関する状態を維持したり、後でフィードバックを操作に再び関連付けるためにコールに関する十分な情報を渡したりする必要があります。いずれの場合も、サーバーでフィードバックが生成されないと、この余分な負荷が無駄になります。同様に、例外が生じる操作から例外が切り離されていると、困難な例外処理が生じる場合もあります。操作のフィードバックと例外処理での論理的な類似性については、議論の余地があります。

次に、リモートオブジェクトの参照を渡すとオーバーヘッドが生じ、サーバーがコールバックを実行しない場合は無駄になります。あらかじめ参照をキャッシュする (つまり、いったん送信して後で再使用する) ことによってこの無駄をなくそうとすると、元のオブジェクトをエクスポートした通信トランスポートは、そのオブジェクトが使用される時間まで切断されるので、信頼性が損なわれます。Java アプレットでは着信接続を承諾できないので、無効になったクライアント参照は再接続できません。タイムアウトした接続でコールバックしようとすると、サーバーで単に例外が生じることになります。

最後に、アプレットは着信接続を受け入れられないので、HTTP プロキシを通してトンネル化された Java RMI はサーバーにコールバックを許可しません。呼び出し (HTTP) に使用される通信転送が反対方向の呼び出しを十分に処理できないからです。

Windchill アーキテクチャでは、リモートメソッドを起動するプロトコルにライトウェイトのフィードバックメカニズムを導入してこの問題に対処しています。つまり、サーバーからクライアントに RMI 応答マーシャルストリームの一部としてフィードバックオブジェクトを送信できます。これらのオブジェクトは、コールを実行するスレッド内で受信および処理され、コールと同じ通信接続が共有されるので、コールそのものと論理的に結合されたままの状態になります。

クライアントからメソッドを起動する際、RMI 応答マーシャルコードでサーバー側のメソッドが起動され、サーバー側のメソッドでフィードバックオブジェクトを応答ストリームに随意にフラッシュできます。クライアントの応答マーシャルコードでは、これらのオブジェクトがフィードバックとして認識されてクライアントの init メソッドが呼び出され、実際の応答が待ち続けられます。長時間にわたる操作を開始する場合、サーバーメソッドは、進捗状況バーやキャンセルボタンなどの GUI コンポーネントを送信できます。サーバーでは、このコンポーネントを更新するほかのフィードバックオブジェクトを定期的にフラッシュできます。キャンセルボタンは、メソッドサーバーの最初のスレッドを中断するため、2 番目のスレッドの操作キャンセルメソッドを呼び出します。