Windchill System Administrator's Guide

system to be considered available. This process could be viewed as a Windchill
daemon since it must be running at all times.
Running more than one server VM is not a requirement of the Java architecture.
Windchill implements this architecture for reasons of reliability and scalability.
Allowing for multiple method servers reduces the risk of a single VM being
unable to fully use high-performance multiprocessor hardware when contention
for shared resources within a single VM becomes a limiting factor. By allowing
multiple processes, the system itself can scale beyond the capacity of the
individual VMs to handle high transaction rates.
For example, if a given type II (native method) JDBC driver implementation
began to show synchronization bottlenecks at some number of concurrent DB
transaction threads, a second method server could double the system's capacity for
concurrent transactions.
This architectural feature also addresses reliability because the method servers,
unlike the server manager, will execute customized Java code developed by non-
Windchill programmers. Although the Java VM provides a very reliable, threadsafe
environment, which makes it difficult for errant code to affect other threads,
instability can be introduced in the form of memory consumption or resource
deadlocks. Further, method servers may use native (non-Java) libraries for
database interfaces or other application-specific interfaces. These native libraries
can contain bugs that introduce instability into an entire VM. By keeping the
Windchill system daemon (server manager) and instances of method servers in
separate VMs, individual method servers can terminate without making the
Windchill system unavailable or losing user validation information.
Performance concerns are addressed by minimizing the interprocess
communication required between the method servers and the server manager, and
between clients and the server manager. After clients use the server manager to
bind to a method server once, they call that method server directly. If that method
server later becomes unavailable (terminates), automatic exception handling
transparently rebinds the client to a new one.
RMI Bootstrap Registry
Windchill Java clients use Java RMI to communicate with Windchill servers. To
use RMI, a client must first obtain a reference to a remote object on which it can
invoke methods. The Java RMI runtime initiates this operation by using the
concept of a bootstrap registry object, which clients have a built-in ability to
construct. This allows them to invoke lookup operations on the registry and
receive other, references to remote objects.
To reduce the complexity of the system as well as reduce the number of network
connections between clients and servers, Windchill runs its own registry object in
the server manager, using a configurable port number. The only object registered
in this registry is the local server manager implementation. Other Java RMI
applications do not share this registry, and Windchill does not depend on any
registry that other Java RMI applications may be using.
Windchill Runtime Environment A-11