To leverage the web browser's ability to view, save, and operate on a diverse set of content types, it must be possible to stream file content from the Windchill system to the browser through the HTTP gateway. As shown in the following figure, requests for file transfer are encoded into appropriate HTTP requests against the server's HTTP gateway. Requests are then delegated to frames within the web browser’s HTML windows, where they are submitted and responses are received.

In the Windchill method server, HTTP responses are generated using a streaming interface, allowing the responses to be arbitrarily large. As shown below, this is accomplished by invoking the method to generate the response from within the RMI reply marshaling so the response can be written directly to the RMI result marshaling stream. This allows entire files to be streamed directly from the database without the need to stage them on disk or in memory.

In the following figure, upload streaming is performed in a similar manner, using HTTP POST requests. In this case, the method to read the post is invoked from within the RMI argument marshaling so it can read directly from the RMI argument marshaling stream.

It is possible to develop customized trusted applets that access the client file system directly. They can use similar techniques to stream data to and from Windchill servers. However, the Windchill architecture tries to minimize dependence on techniques like code signing because of the client-side administration required. Therefore, this type of file transfer client applet is generally built as a customization when a site has a client infrastructure that can support code signing.