Variant Configurations
Administrators can define application instances to configure varying arrangements of transports and stores for different environments.
When an application runs as a single process, the administrator determines one such set of transports and stores.
Sometimes, when an application runs as many processes, it nonetheless requires only one set of transports and stores. That is, the same set serves all the application processes in the same way.
However, at other times when an application runs as many processes, some of those processes require a different set of transports and stores than the others do.
For example, the following diagram returns to an earlier example, in which application Pub sends messages to application Sub.
Pub runs as a single process on host 1. If Sub were to run as a single process on host 1 as well, then the administrator could arrange a very simple communication scheme, consisting only of shared memory transport T1. Even if host 1 were to run many Sub processes, that same scheme could serve them all.
However, if we add Sub processes on other hosts, they cannot use T1, because shared memory transports can operate only within a single host computer. Sub processes on other hosts require a different transport type, so the administrator must arrange a variant communication scheme for these processes.
The administrator must connect Pub to transports of both types. In contrast, Sub processes must use different variants. The correct variant depends on the host computer where the process runs.
In TIBCO FTL software we call such variants application instances. For each application, administrators can define one or more application instances. Each application process selects the appropriate application instance at run time based on environmental factors, such as the host name.