The following diagram illustrates the major components of the 

CA API Gateway

:

Messages enter the message processor via network listeners (examples: HTTP, FTP) or via outbound connectors that initiate connections to external services (examples: IMAP Polling, Tibco EMS, MQ Series). The complete list of connectors varies between releases and there is an SDK to add additional network output protocols. Message input connectors are more complex, requiring a different, non-public SDK.

These input systems have two roles: Provide the network protocol as appropriate and prefill some network level details that are used later in policy. For example, the HTTP connector puts the remote IP address into a special context variable.

The message processor is an efficient, multithreaded system that invokes functions (known as "assertions") on an inbound message as it follows policy logic.

Assertions are "aware" of their context within the currently executing policy. They get this information from a variety of sources, including the request and response messages, context variables, and the policy language.

Note that there is no specific message output system defined. This reflects how the Gateway is protocol independent. If a use case has a back-end system on JMS, then the policy uses the Route via JMS Assertion. If the back-end system is SFTP, then the policy uses the Route via SSH2 Assertion (which provides SFTP routing). This underscores the important point: 

Back-end requests are explicit policy actions.

 

The support tooling provides services used by multiple assertions and the listeners: Certificates, caching, connection pooling, audit, logging, management, token services, etc.