Although some of today's distributed object technologies, including Java RMI, allow servers to call back to client objects with feedback, there are problems with this obvious approach to client feedback.

First, it forces a logical decoupling of the feedback from the operation, because the client must create objects to receive feedback calls. These objects must maintain state about the operation, or pass enough information on calls to reassociate feedback to the operations at a later time. In either case, this additional overhead is wasted if the server does not produce any feedback. An analogy may be the unwieldy exception processing that would result if the exception were decoupled from the operation throwing it. It can be argued that there is a logical similarity between operation feedback and exception handling.

Second, passing remote object references incurs overhead that is wasted if the server does not perform a callback. If one tries to eliminate this by caching the references up front (that is, send once, reuse later), robustness suffers because the communication transport on which the original object was exported may be disconnected by the time it is used. Java applets cannot accept incoming connections, so a stale client reference cannot be reconnected. Attempting to call back on a timed-out connection simply throws an exception in the server.

Finally, because applets cannot accept incoming connections, Java RMI tunneled through an HTTP proxy does not allow the server to call back because communication transport used for the call (HTTP) is not sufficient to handle a call in the reverse direction.

The Windchill architecture addresses these concerns by implementing a lightweight feedback mechanism into the remote method-invoking protocol. This is done by allowing feedback objects to be sent from the server to the client as part of the RMI reply marshaling stream. They are received and processed within the thread performing the call, and they share the same communication connection as the call, thus remaining logically coupled to the call itself.

When processing a method invocation from a client, the server-side method is invoked from within the RMI reply marshaling code, allowing the server-side method to flush feedback objects onto the reply stream at will. The client reply unmarshaling code recognizes these objects as feedback and calls their init methods, then continues to wait for the real reply. When starting a long operation, the server methods can send a GUI component such as a progress bar and cancel button. The server can periodically flush additional feedback objects that update this component. The cancel button is programmed to invoke an operation canceling method in a second thread capable of interrupting the first thread in the method server.