Deployment Topology Options

This section discusses the various tactics for placing software capabilities onto virtual or physical hardware servers. The distribution of software across hardware and networks is here referred to as a chosen “topology”.

Key Point

When software applications are deployed to computing resources, the software applications do not have to be co-located on a single network server and, on the other hand, the computing resources can be numerous.

The range of possibilities extends from deploying everything (Jazz CLM, Jazz’s database backend, the Windchill PLM, the PLM database backend, the RLIA Adapter, the license servers, the user browser, etc) to a single laptop to deploying each software capability to a separate microservice in virtual cloud service providers.

You must choose where to deploy capabilities based on the information access needs of the organization and on the computational resources of the servers and the networks. There is not a technical reason why software must be co-located or distributed.

Networking Identification

  1. Determine the web URLs to each of the software servers: for PTC Windchill™, for IBM ™ Rational Collaboration Lifecycle Management (CLM), and for the Windchill Adapter
  2. Record the Hostname Address (e.g. https://host.domain.com:8443) for each of these servers and use those addresses identically and consistently throughout the installation. It is recommended to use a hostname address instead of an IP address.
  3. For the purpose of describing the installation procedures with illustrative URLs, the following URLs are used:

Three topologies are discussed, your actual deployment likely will be a hybrid of several of these.

Be advised that after installation you cannot rehost any of the applications to different servers — unless they are behind reverse proxy servers. Because their public hostnames are encoded in the URLs stored in the Jazz and in the PLM repositories' resources the public names of the application servers cannot be changed over time. This is a known consequence of persistent services based on REST APIs.

If you elect to deploy your applications in any of the topologies where the applications reside on distributed virtual or physical servers, read and honor the requirements in Configurations Necessary for Distributed Deployments.

For additional information on the architecture of the Adapter, read An Overview of the Architecture of the Adapter.