This section describes the client tier components of the Windchill runtime architecture.

The Windchill primary client component is a web browser. The widespread availability of low-cost, powerful web browsers, makes it possible to deploy a large, distributed information system with little or no maintenance of individual client hosts.

The ability to display HTML pages, although adequate for simple applications, does not provide enough functionality for all aspects of complex information authoring applications. Therefore, Windchill requires a browser capable of hosting Java applets based on the Java runtime and base classes. Two popular examples are Mozilla Firefox and Microsoft Internet Explorer.

Using a web browser as a front-end, allows leveraging of HTTP server capabilities on the back end. For example, HTTP request authentication, designed for controlling access to other web server resources, is used to authenticate access to the Windchill system with the need to license and embed security software into Windchill clients and servers. Instead, rapidly evolving authentication schemes can be used in a manner transparent to the Windchill system, giving you more freedom to manage your Web security infrastructure as you see fit.

A web browser front end also allows you to leverage built-in file download and upload capabilities and the launching of helper applications and plug-ins.

The initial point of contact between a client and a Windchill server is an HTTP GET or POST request. It is typically a GET request, activated by a link embedded in an HTML page, that initiates connection with the Windchill system.

The Windchill system responds with an HTML page. This page may contain JavaScript or JScript to coordinate window or frame usage within the browser.

Many simple accesses to the system may use only HTML presentation, with HTML form data serving as input. However, the typical client session requires that applet tags (used to carry out complex user interactions involving complex data) be embedded in these HTML responses.

Java applets are downloaded from Windchill servers and executed on the client system. They provide sophisticated graphical user interface functionality, allowing for complex interactions with the user.

Once running, the applets communicate directly with Windchill servers via Java RMI. This avoids the additional overhead of communicating indirectly through the HTTP server and allows for very complex data to be passed easily between client and server.

If it is necessary to get through firewalls by using an HTTP proxy, Java RMI communication is automatically layered on HTTP. However, this results in greater performance degradation than a direct connection to a Windchill server.

Applet classes loaded from the same Windchill system communicate with one another to use the browser windows and frames, presenting a seamless system image.

Applet classes loaded from federated Windchill systems (coming from separate HTTP servers) cannot communicate directly with one another for security reasons. Intersystem links are therefore accomplished using HTTP URLs, given to the browser for loading into HTML windows. The resulting HTML pages contain JavaScript/JScript and applet tags that use windows and frames to present a seamless system image.

Interactive applets can present feedback on behalf of long-running server transactions. This feedback can take the form of progress indicators and, in some cases, provides the ability to cancel the operation.

Following settings are required at the client side:

If an applet is blocked due to security error, add it in the exception list from Java Control Panel > Web Settings > Exception Site List > Add. Ensure to add the Windchill base URL in the exception list. The URL string is formatted as http://<hostname>:<port>/<webapp>.

To delete temporary files, follow these steps:

Port entry needs to be added in Java security policy file to run direct RMI.

To add the port entry, open the JRE location and add the corresponding port entries as per your Java version.