The

CA API Gateway

consists of a protocol independent message processor, network input subsystems, and assertions that provide actions in the message processor, and output capabilities as well. The Gateway is not an app server.

The message processor is protocol independent because it operates on a message--how that message is received (i.e., HTTP or FTP) is not considered. The back-end system that eventually receives the request may be of different technology. For example, it is common to submit a HTTP message a back end using a JMS Queue.

 The product allows environment dependencies to have shared configuration between different services. For example, an environment may have multiple LDAP servers, with more than one Service that authenticates against each LDAP server. This configuration is supported, though it increases the chances of error.

 The Gateway design is partially based on the concept of "XML Firewalling", so there are some similarities to an IP Firewall. By default, the Gateway assumes all messages are suspect and may be attempts to bypass security until proven otherwise. This is similar to best practices in IP firewalling, where all TCP ports are closed by default. As a result, the Gateway does not pass any data by default. If the inbound request contains anything unexpected, the Gateway is designed to block that information. The Gateway does not copy most HTTP headers from a request to the back end unless specifically configured to do so. All data must be explicitly referenced. Text data offers best performance, as interpreting binary data in a policy may require additional decoding and encoding steps.