Copyright © Cloud Software Group, Inc. All Rights Reserved

Deployment Choices

When configuring an administration domain, you can set how the administration server creates and stores application data. This section explains the choices available and discusses their implications. You have the following choices when configuring an administration domain that uses TIBCO Rendezvous. If TIBCO Enterprise Message Service is used, only the local application data choice is available. Server-based application data is not available.

•	Using Local Application Data

•	Using Server-based Application Data

For both choices, a directory is created for each deployed application on the target machine under TIBCO_TRA_DOMAIN_HOME\domain-name\application. The executables, property files and deployment files required for the application are stored under this directory.

The TIBCO_TRA_DOMAIN_HOME\domain-name\datafiles directory is also created as needed and only for local deployment. This directory contains the project files used by an application’s non adapter components such as TIBCO BusinessWorks. Adapter repository files (.dat) are stored in the TIBCO_TRA_DOMAIN_HOME\domain-name\data directory.

Using Local Application Data

When using TIBCO Domain Utility to create an administration domain, you can select the Local Application Data option. When the option is chosen, deployment files for an application are sent to target machines. This allows the application to run independently of the administration server (unless an application performs operations that require connecting to the administration server in a file-based domain, such as HTTP or SOAP authentication). Selecting the option makes it the default in the domain. For domains that use TIBCO Rendezvous, you can change the option per application to use Rendezvous, or HTTP/HTTPS when deploying the application in the TIBCO Administrator GUI or the appManage utility.

Choosing the Local Application Data option results in the following benefits:

•	Because the local service instances use no memory, thread or CPU resources on the administration server, the solution is infinitely scalable.

•

At runtime, because there is no communication between the deployed application and the administration server, a server failure has no effect on the runtime application (unless an application performs certain operations that require connecting to the administration server in a file-based domain, such as HTTP or SOAP authentication).

•

Application data for TIBCO BusinessWorks is stored in its native format as a multifile project, while adapters use their native format .(dat files). The required storage format is determined based on the application’s components installed on the target machine. For example, if an application uses a TIBCO Adapter, a .dat file is written to the target machine. If the application uses TIBCO BusinessWorks, a project file is written to the target machine.

•	For server-based domains, TIBCO BusinessWorks applications must do an in-memory transformation at startup.

Issues with this Choice

The main issue with this choice is synchronization. If deployment is done cleanly, all client machines will remain synchronized as appropriate processes are stopped and each will receive updated deployment files. However, if a subset of client machines are unavailable during deployment and later started, their service instances, metadata and configurations can be out of sync. This could result in severely aberrant behavior.

When using this option, you must ensure that each application deploys successfully. If an application does not deploy successfully, a warning message will appear in the TIBCO Administrator GUI Deployed Configuration pane. The person responsible for the application should ensure that the components on the failed machine are not started until they are successfully updated.

The other significant concern is security. Repository instances can contain sensitive information such as database or application user ids and passwords. While the passwords are encrypted, the encryption algorithm used is 3DES. To protect this data, you must provide strong file system security on each machine to which applications are deployed.

Using Server-based Application Data

For domains using TIBCO Rendezvous as the transport, the server-based application data option is available. When deploying an application with this option set, a repository instance for the application is created on the administration server and the repository instance is referenced in each application’s instance’s property file (.tra file).

•

Two transport protocols are available for server-based communication, TIBCO Rendezvous, and HTTP/HTTPS. The default transport option is configured using TIBCO Domain Utility when creating the domain. The utility can be run later to change the default transport option for a domain. The transport can be changed when deploying an application, either in the TIBCO Administrator GUI or with the appManage utility. This allows one application in the domain to use Rendezvous, another application to use HTTP and another to use the local deployment option.

If you configure an administration server for HTTPS, that server’s GUI will not be accessible via HTTP. You can, however, access the same server programmatically using both HTTP and HTTPS.

You must use TIBCO Rendezvous or the local deployment option to connect to a version 4.x TIBCO Adapter. HTTP or HTTPS cannot be used.

Issues with this Choice

Using this choice, there are no significant issues related to synchronization.

The main concern with this approach is that each repository instance on the administration server consumes memory and threads. The memory requirement is 3-5 times the size of the .dat file, which can range in size up to tens of megabytes. With many applications starting simultaneously, the server could become overwhelmed causing time-outs and application failures. Other issues include increased network traffic, and maintaining network and administration security.

Another issue is related to fault tolerance. Runtime applications can not start, and in some cases can not function without being able to communicate with the administration server. This makes the administration server a single point of failure at runtime. The server does have some fault tolerance with the secondary servers, but deployment can be significantly slowed when secondary servers are used.

Copyright © Cloud Software Group, Inc. All Rights Reserved