Most client applications access Windchill using HTTP or HTTPS connections, so an HTTP or HTTPS connection must be available. The default ports are 80 and 443 for HTTP and HTTPS, respectively.

Some Java clients may access Windchill directly using Java’s Remote Method Invocation (RMI). These clients can attempt direct connection to the server by default, using the RMI ports specified in the following wt.properties:

RMI is a Java-centric remote procedure called (RPC) mechanism that is implemented on sockets. RMI stub objects perform a remote method invocation between an RMI client and an RMI server. These stub objects contain a host name and port number. The client uses these stub objects when opening TCP and IP connections. Windchill exposes only two RMI objects to clients: a server manager object and a method server object. Other RMI objects are used server-to-server to coordinate cached information, but these RMI objects are not necessary for clients to connect.

RMI communication can also be forced to “tunnel” over HTTP or HTTPS. Tunneling over HTTP is no more secure than direct RMI communication. However, tunneling can leverage a reverse proxy by encrypting HTTP and HTTPS traffic. For more information on tunneling RMI, see Windchill Runtime Environment.

Controlled by the java.rmi.server.hostname property, the Windchill server host is used in URLs and RMI stubs and must resolve to an IP address for clients inside and outside the firewall. If the firewall is performing network address translation or is configured to proxy Windchill connections, the host names presented by Windchill to its clients must be valid to connect to the servers.

Many existing Windchill applets and applications use Java RMI to invoke server transactions. There is a continuing shift of focus from this form of communication towards HTTP and XML. But for now, the Windchill development environment continues to support code generation of classes that use RMI to invoke remote service methods.