Gateway Architecture

The working unit of the gateway is a HTTP, JMS, or FTP-accessible endpoint. Clients access the Gateway through a URI or queue compatible with one of the above protocols. The Gateway functions as a reverse proxy for service requests and should be the single web service traffic enforcement point in a network.
gateway91
The working unit of the
Layer7 API Gateway
is a HTTP, JMS, or FTP-accessible endpoint. Clients access the Gateway through a URI or queue compatible with one of the above protocols. The Gateway functions as a reverse proxy for service requests and should be the single web service traffic enforcement point in a network.
Due to the number of subsystems involved, changes made in the Policy Manager may require up to 15 seconds to be reflected in the Gateway.
In a typical network, the Gateway resides in the DMZ (demilitarized zone), shielding downstream services as it enforces predefined policy assertions on incoming and outgoing messages. In the Gateway, several interdependent layers work together to enable this end-to-end XML firewalling, security, and service protection.
Gateway_Architecture
Gateway_Architecture
Routing Layer
The Routing Layer represents an industry-standard load balancer configured to provide TCP-level load balancing. It is not required for a standalone Gateway.
Processing Layer
The Processing Layer represents the Gateway’s core "runtime" component. When a request message is received, the Gateway executes a service resolution process that attempts to identify the targeted destination service. When a published service is resolved, the Gateway executes the Policy Manager-configured policy for the service. If the policy assertions succeed, then the request is routed; if one or more policy assertions fail, then the request is either denied with a SOAP fault or the connection is dropped.
In a Gateway cluster, systems that are installed with this runtime component are referred to as "Processing Nodes".
The Processing Layer involves the following components:
  • Identity Providers
  • Trust Store
  • UDDI
  • Logging and Auditing Functionality
Identity Providers
The Gateway uses identity providers to authenticate and identify users and groups when authenticating messages and administrative access. The Gateway can use its built-in identity provider (called the
Internal Identity Provider
or the
Federated Identity Provider
in an identity bridging scenario), or interface directly with any LDAP-based identity provider or, through a custom assertion, connect to and utilize an external identity management system (such as CA Single Sign-On or IBM Tivoli Access Manager).
For more information, see:
Trust Store
The Gateway maintains a trust store of certificates that do not belong to it but that are trusted and used for one or more vital security functions, such as signing client certificates. Certificates are imported into the Gateway trust store through the Policy Manager. For more information, see Manage Certificates.
UDDI
The Gateway can publish a web service by using a WSDL located in a UDDI (Universal Description, Discovery, and Integration) registry.
To enable UDDI registry support in the Gateway, see Manage UDDI Registries.
Logging and Auditing Functionality
The Gateway provides several logging and auditing features, allowing users to monitor the activity and health of the Gateway, and the ongoing success or failure of service policy resolution. Auditing is provided for all system events, and is configurable for individual service policies. All audit records can be viewed through the Policy Manager. Gateway logging is performed during runtime, and you can view this logs through the the Policy Manager. The Manager also features a Dashboard that allows administrators to monitor activity through the Gateway in real-time. For more information, see Gateway Dashboard.
Database Layer
The Gateway stores policies, processing audits, Internal Identity Provider, keystore, configuration details, and other information in a MySQL database. In a typical configuration this database resides on the same physical system as a processing node, although in rare circumstances it may reside on a separate system.
There are typically two processing nodes in a cluster, both of which communicate with a single MySQL database. This database should be located on one of the processing node.
System Layer
The System Layer represents the Operating System, Java Virtual Machine, and hardware platform. You can install the Software form factor on Red Hat Enterprise Linux (RHEL), CentOS, SUSE Linux Enterprise Server (SLES), or Oracle Solaris (x86 or SPARC).