Production Gateways are normally deployed in the DMZ and provide services for mobile and client systems located in less secure zones. The business services being secured by the Gateway are normally in the secure zone. In the Network diagram below, there are multiple databases. The Gateway does not require any specific network location, but network and security architects often require that all databases are located in the secure zone. 

Field implementations must cover both environment configuration and service "programming." Many individual policy operations require configuration data obtained by querying a database, an LDAP server, or an external system via SSL. Each has configuration, for example: credentials for the database or the SSL certificate for the external system. These parts are not directly in policy, but are in common configuration storage that must not be overlooked when migrating between environments.

Services and policies have "Environment Dependencies" specific to the physical environment the Gateway is deployed in; for example IP addresses of back-end systems and LDAP-specific details. It is critical to plan for these dependencies during policy development, especially for migration.

Specific environment specific values should be captured as cluster properties. These properties allow you to refer to common configuration items as symbols instead of literal values, making it very simple to make wholesale changes to many references. Cluster properties are referenced in the policy editor as "${gateway.

<property_name>

}".

Example: In the Route via HTTP(S) Assertion, you use the cluster property 

${gateway.BusinessService}

" in the host URL field, you can define the 

BusinessService

 cluster property as "dev.bizsvc.company.com" for your Development environment and as "qa.bizsvc.company.com" in your QA environment. When you move a group of policies that all refer to that business service from Development to QA, you need change only the value of the cluster property. This concept can be use for most shared resources: app servers, database servers, LDAP services.

Most Gateway subsystems rely in various predefined cluster properties for details of configuration. A common example is the HTTP input subsystem, which uses the predefined cluster property Input/Output Cluster Properties. This defines the number of simultaneous HTTP-based inbound connections allowed at one time. The default of 500 should be able to accommodate the traffic expectations for most common deployments.

All nodes in a Gateway cluster share the same configuration, greatly easing installation of larger environments. You create new cluster properties on demand, which provide tremendous power in implementing cluster-wide configuration changes. To learn more about the predefined cluster properties, see these topics:

.