Server Software Components

The HTTP server is either the HTTP Server (powered by Apache) or a commercial HTTP server such as IIS. The HTTP Server is bundled with Windchill. Other HTTP servers can be purchased separately. An HTTP server must be present on each Windchill server host. The web server provides HTML pages and Java classes, as well as gives access to a Windchill HTTP gateway (described later in this section) as an in-process Java servlet.

The user authentication capabilities of the web server are leveraged by Windchill to take advantage of the improving authentication standards being built into web browsers and servers. These include HTTP 1.0 Basic authentication, HTTP 1.1 Message Digest authentication, Digital Certificates, Windows/NT Challenge-Response authentication, and more. Since Windchill is Web-centric, it is important to leverage the server's user authentication rather than become a hole in that security by using an obsolete authentication scheme that is not integrated with the customer's environment. For example, a site using web servers that support LDAP-based, centralized user and access management is automatically integrated with Windchill for user authentication, rather than maintain a second set of user preferences.

Integration is achieved by configuring a protected instance of the Windchill HTTP gateway. Java applets send a session login request to this URL. The web server does not allow access until the user satisfies the server's user authentication requirements. Normally this involves the server returning an unauthorized response to the client browser that identifies the authentication scheme required. The browser then reacts by resending the request with the appropriate authentication headers, possibly after prompting the user for a password.

Essentially, Windchill is not involved until the web browser and web server have securely established the user's identity. Only then does it receive the session logon request along with the authenticated user identity.

For more information about authentication and to customize authentication methods, see the customization information located in the “Basic Customization” and “Advanced Customization” areas of the Windchill Help Center.

HTTP gateway is a Java application executed as a servlet. It serves as the initial point of contact between a client browser and Windchill services. The HTTP gateway resides within Embedded Servlet Engine (which is embedded in the method server) and acts as a conduit to carry the requests and responses between the HTTP server (web server) and Windchill method servers.

The HTTP gateway invokes a special method to handle the HTTP request. The request headers (or CGI properties) set by the web server are passed on within the Windchill method server along with any submitted data. The invoked method determines what is being requested based on the submitted data. It delegates to appropriate submethods to generate an HTTP response, usually in the form of an HTML page with appropriate applets embedded within it.

Most requests to the HTTP gateway originate from an HTML browser window, either as a result of an embedded link within a static HTML page that is already being shown, or from a Java applet using the AppletContext.showDocument method to bootstrap a page into the HTML browser window.

This is a fundamental mechanism for linking federated systems, the Java classes from two systems cannot communicate directly. Showing pages from several Windchill systems in standard web browser HTML windows allows the client browser to be the center of a star configuration, linking the systems without requiring violation of the strict security restrictions placed on untrusted applets. Requests are forwarded between the systems by encoding appropriate GET requests against their HTTP gateways and delegating to frames within the web browsers HTML windows to submit these requests.

The HTTP gateway is accessed through HTTP GET or POST requests. A Windchill URL generally takes the following form:

The <class name> and <method name> are used by the method server to dispatch the request to a specific method for processing, and <arguments> is a URL-encoded query string. The query string is used to supply additional data that is specific to the method being invoked, such as an object ID. When using a POST request, additional data may also be supplied within the body of the POST request.

This data can range from simple URL-encoded HTML form data to multi-part MIME messages containing the entire contents of one or more files. In either case, the target class is responsible for forming the URL, and, the target method understands what to expect.

Many target methods accept both GET and POST requests, and expect the GET request's query string or the POST request's body to contain URL-encoded form data. This is the standard encoding that would result from submitting a simple HTML form to the web server. It allows using HTML forms as test drivers for these methods, even if the requests are generated in Windchill Java applets rather than from HTML forms.

Basically, URL-encoded form data sends arbitrary name=value pairs separated by a question mark (?). All spaces are replaced by plus characters (+), and all special characters are hex-escaped into %dd format, where dd is the hexadecimal ASCII value that represents the original character.

The HTTP gateway is used when establishing authenticated user credentials. This is done by configuring two identical HTTP gateways: one public and the other protected by web server user access controls. When a Java client needs to establish valid credentials (to perform secure RMI calls to a Windchill method server), it submits a login request via the protected HTTP gateway. The web server supplies the authenticated user name and authentication type to the HTTP gateway, and that information is passed on to the Windchill method server.

The HTTP gateway acts as a conduit for delivering requests to Windchill method servers and returning responses through the HTTP server. The content of the responses is controlled by methods implemented within Windchill method servers. These methods may make sophisticated use of JavaScript or JScript in their responses in order to manage HTML browser windows and standalone Java windows from one or more Windchill systems, thereby giving the appearance of a seamlessly integrated environment.

Files are transferred from the client to the server using a chunked RMI upload. The file is split into manageable pieces and then sent to the server where it is reconstructed and inserted into persistent storage. This capability is only accessible to applet clients and is available as a standard bean within Windchill core. This bean has direct access to the client's file system. It can upload files with the RMI transfer, and it can remove and replace files from the Windchill system.

Be aware that this upload architecture addresses limitations in some browser's Java HTTP classes. The HTTP upload procedure is still available, but PTC does not recommend using it for content upload from an applet. Downloads from the Windchill server via HTTP do not exhibit the same limitations as uploads, and downloads can still use the HTTP architecture described below.

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.

The server manager is a Java application running on each server host. Its primary role is to manage a set of method servers, but it also maintains user session credentials, and manages background processing and other system management functions.

There is a single instance of a server manager on each Windchill server host. It runs in its own Java Virtual Machine (VM) and must be running for the Windchill 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, execute customized Java code developed by non-Windchill programmers. Although the Java VM provides a very reliable, thread-safe 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.

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.

Unlike the default RMI registry implementation, the one used internally by the server manager allows client connections to be timed out, which improves the scalability of the system in environments with many users. This flexibility is one of the justifications for controlling the bootstrap registry as an internal part of the Windchill system.

The primary purpose of the Windchill server manager is to introduce clients to method servers as needed. The Windchill architecture separates the server manager VM from the method server VM for purposes of reliability and scalability. Clients call the server manager to obtain a reference to a method server and then communicate directly with that server as long as they can. When more than one method server is available, the server manager returns references so as to distribute the load among the available servers.

The protocol for obtaining method server references in the client is encapsulated within the classes that invoke remote methods. It includes fault tolerance for network failures and server manager restarts, and generally is never accessed directly by Windchill customizers.

The server manager is responsible for maintaining the method servers.

The server manager executes method servers as child processes on an as-needed basis. Under high load, it expands the pool of available servers and contracts as usage declines, within some range of management thresholds.

In general, all Windchill method servers are created equal. They are all instances of the same implementation, which dynamically loads Java classes as necessary to carry out requests received from clients. However, to allow for specialty servers that may have unique management requirements, such as limitations due to application-specific native libraries, the server management protocol allows the assignment of unique service names that control the management thresholds and the method server's startup arguments.

Although most generated interfaces invoke the default method service, you can build custom interfaces that request specific service names.

It is often necessary to have a system carry out operations without being directly connected to an end user. This is the case for periodic (time-based) activities, as well as operations that are triggered by a user operation, but for which the user does not wait. For example, an action is performed that promotes an object to a new life cycle state. The change to this life cycle state may trigger additional processing that is not directly related to the user's action. These activities should be carried out in the background.

The Windchill server manager is responsible for guaranteeing that background processing takes place. The implementation of processing queues and triggering mechanisms actually resides in the Windchill method servers. The server manager is simply responsible for keeping an instance of the method server running so that background processing can take place.

As described in Advanced Deployment, your environment can be configured such that there are multiple method servers, one of which is dedicated to running background processing queues.

For more information about queue configuration and maintenance, see About Background Queues.

Windchill leverages the user authentication capability of the HTTP server. For client requests that use RMI instead of HTTP, a place to cache the HTTP authenticated user names is required so the client requests can be securely associated with subsequent RMI calls. Because the server manager represents a daemon process that outlives individual method server processes, that place is within the server manager VM.

As discussed previously, when clients need valid credentials, Windchill is uninvolved until after the HTTP server allows access to a protected Windchill HTTP gateway. The gateway then passes the authenticated HTTP request to a method server for processing. The method server processes the request for credentials by storing the authenticated user name and associated session properties (passed on the request) with a session manager that runs in the server manager VM.

Live connections are not used to maintain the session database within the server manager. To reduce resource consumption, credentials are validated by the method server, even though the client is disconnected from the server manager. Rather than live connections, a limited size, most-recently-used caching algorithm is used. In the event a client is still alive after its session credentials have been aged out, automatic exception handling transparently reestablishes the credentials.

Scalability demands that individual clients do not consume significant server resources indefinitely. A large number of infrequent users should not require that the system is hosted on super-server hardware. Server host sizing should be a function of transaction throughput, not of user count.

The Java I/O model, in particular the Java RMI implementation, dedicates at least one thread to each network connection. To make this scalable to a large number of users, Windchill implements two mechanisms to free network connections and threads. The first is to time out connections that remain idle for a specified period of time. The second is to limit the total number of client sockets the RMI runtime is allowed to consume. This limit is enforced by closing the least-recently-used connect. Thus, new client connections are not refused, and connection timeout is faster when under a heavy client load. Clients recover from the disconnection automatically.

Being the daemon process of the Windchill architecture, the server manager becomes the key process for performing Windchill system management functions, such as starting and stopping method servers.

You can use JMX MBeans to perform system management functions, although some actions (like shutting down the servers) are restricted to authorized user names.

For more information about JMX, see Using Java Management Extensions (JMX).

This component is a Java application that executes all methods representing business object transactions. Architecturally, it starts out simply as a skeleton process that dynamically loads specific Java classes as they are needed to service client requests. The following figure shows the anatomy of a method server.

When a method server process is started, it creates an instance of a method server object, which is exported as a remote object to the server manager. Clients bind to a method server by retrieving this object reference from the server manager, and interacting with the method server directly.

The binding and method-invoking machinery is hidden from application developers by utility classes and generated helper classes. Its architectural significance is that it helps explain how the Windchill runtime operates.

A significant advantage of using Java RMI to invoke server methods is the built-in support for transferring arbitrarily complex object graphs between client and server. This allows transactions to use sophisticated arguments and results without complex programming of the client-to-server interface.

Access to server-side methods is exposed to clients by using helper classes corresponding to each business class. These classes wrap the externally available server-side methods of their business class with implementations that forward the calls to a method server where the real method is invoked.

For more information about modeling of the interfaces and the generation of helper classes, see the customization information located in the Basic Customization and Advanced Customization areas of the Windchill Help Center.

The method server is the only Windchill process that communicates directly with the database. In this sense, Windchill runtime is a classic three-tier architecture. Using a shared database login, the method server maintains multiple database connections assigned to worker threads as needed to carry out individual transactions.

The interface to the database is implemented by a Persistent Object Manager (POM) layer within the server that acts to abstract the actual database interface from the business logic.

For more information about persistence see the customization information located in the Basic Customization and Advanced Customization areas of the Windchill Help Center.

As with the server manager, scalability demands that individual clients do not consume significant method server resources indefinitely. Therefore, Windchill method servers implement the same mechanisms as the server manager to time out idle connections and limit the number of client sockets the RMI runtime is allowed to consume.

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.

To authorize access to a given object or operation, the method server must be able to reliably identify the user performing the action. Various aspects of user authentication (securely establishing session credentials) have already been discussed. These things come together in the method server to allow a method to inquire about the user associated with the current execution thread. This capability allows applications to implement access control policies, which are described in detail in the Policy Administration section of the help center.

Java RMI does not provide an inherent means of reliably identifying the calling user. However, the Windchill runtime architecture satisfies this need within the method server's remote method-invoking interface. Client credentials are implicitly included with RMI method arguments, and digital signatures are used to securely associate the RMI thread with an authenticated user name. This association is established before the target method is called, so method signatures do not need to contain an extra context or user argument. The information is retrieved if and when it is needed.

Additionally, the association can be dynamically modified in the course of executing an operation. For example, it may be necessary to carry out certain steps of a transaction as a participant other than the user initiating the transaction. To implement arbitrary authorization delegation schemes, methods are allowed to push and pop the participant currently associated with the execution thread.

Windchill provides for background processing through the use of background method queues stored in the database. The queues are tables of method invocation specifications that are executed by a background processing manager. The specifications are essentially method names and serialized arguments (stored as BLOBs) that are stored in the database for reliability.

A transaction that triggers background processing includes updating a background method queue as part of the overall transaction. Once committed, the background manager is notified, and it proceeds to execute the methods asynchronously. Removal of queue entries is performed within the transaction that carries out the method, thus guaranteeing that entries are processed to completion only once, while still ensuring that incomplete transactions are restarted after system failures. Upon failure, entries are marked as requiring administrator intervention and ignored.

Examples of the background processing mechanism include life cycle processing, workflow automation, and full text retrieval (FTR) index maintenance.

For more information about queue configuration and maintenance, see About Background Queues.

Log files are used to capture exception/error tracebacks and debug tracing messages. In the first case, log entries are generally infrequent, marking exceptional events. However, you can enable more verbose logging levels for troubleshooting purposes. (Full tracebacks may not be available when you run some JIT compiler implementations.)

Starting in Windchill 9.0, Apache log4j is now being used as the primary mechanism for managing and issuing log messages. Some legacy logging has been modified to make use of log4j, but a large amount of previously existing Windchill logging capabilities remain as they were in previous releases and are still managed by Windchill property files configuration settings. In the 10.0 release, additional legacy Windchill logging capabilities have been migrated to log4j.