尽管当今一些分布式对象技术 (包括 Java RMI) 允许服务器通过反馈来回调客户端对象，但这种流行的回调客户端对象的方法存在一些问题。

首先，它强制地逻辑去除了来自操作的反馈，因为客户端必须创建对象才能接收反馈调用。这些对象必须维持该操作的状态，或在以后被调用时传送充足的信息，以将反馈与操作重新关联起来。无论是哪种情况，如果服务器不产生反馈，这些额外的工作就会浪费。例如，如果产生例外的操作与该例外相分离，则会造成例外处理的困难。应该说，在操作反馈和例外处理之间有逻辑上的相似之处。

第二，如果服务器不执行回调，则传送远程对象引用将导致浪费额外工作。如果想通过将这些引用保留在缓存中 (即，发送一次，以后再次使用) 来消除这种额外工作，则会损害系统的耐用性，因为导出原始对象的通信传输到被使用时可能已断开连接。Java 小程序不能接受引入的连接，所以无法重新连接失去时效的客户端引用。试图对超时的连接进行回调，只会在服务器中产生例外。

最后，由于 applet 不接受引入的连接，所以通过 HTTP 代理进行隧道连接的 Java RMI 将不允许服务器进行回调，因为用于调用的通信传输方式 (HTTP) 无法处理反方向的调用。

Windchill 体系结构在远程方法调用协议中采用一种轻型反馈机制，解决了这些问题。其方法为：允许从服务器向客户端发送反馈对象，作为 RMI 答复封送流的一部分。这些对象在执行调用的线程内进行接收和处理，它们与调用共享同一通信连接，从而与调用保持逻辑上的结合。

当处理来自客户端的方法调用时，是从 RMI 答复封送代码内调用服务器端的方法，允许服务器端的方法随意将反馈对象刷新到答复流。客户端答复拆收代码将这些对象识别为反馈，并调用其初始方法，然后继续等待实际的答复。当启动长时间操作时，服务器方法可发送 GUI 组件，如进度条和取消按钮。服务器可定期刷新附加的反馈对象，更新此组件。“取消”按钮用来调用第二个线程中取消方法的操作，该线程能够中断方法服务器中的第一个线程。