WSO2 API Manager includes five main components as the Publisher, Store, Gateway, Traffic Manager and Key Manager. In a stand-alone APIM setup, these components are deployed in a single server. However, in a typical production setup, they need to be deployed in separate servers for better performance. Installing and configuring each or selected component/s in different servers is called a distributed setup.
...
| Component | Description | ||
|---|---|---|---|
| API Gateway | This component is responsible for securing, protecting, managing, and scaling API calls. The API gateway is a simple API proxy that intercepts API requests and applies policies such as throttling and security checks. It is also instrumental in gathering API usage statistics. We use a set of handlers for security validation and throttling purposes in the API Gateway. Upon validation, it will pass Web service calls to the actual back end. If it is a token request call, it will then directly pass the call to the Key Manager Server to handle it. | ||
| API Store | This component provides a space for consumers to self-register, discover API functionality, subscribe to APIs, evaluate them, and interact with API publishers. Users can view existing APIs and create their own application by bundling multiple APIs together into one application. | ||
| API Publisher | This component enables API providers to easily publish their APIs, share documentation, provision API keys, and gather feedback on API features, quality, and usage. You can create new APIs by pointing to the actual back end service and also define rate-limiting policies available for the API. | ||
| API Key Manager Server | This component is responsible for all security and key-related operations. When an API call is sent to the Gateway, it calls the Key Manager server and verifies the validity of the token provided with the API call. If the Gateway gets a call requesting a fresh access token, it forwards the username, password, consumer key, and consumer secret key obtained when originally subscribing to the API. All tokens used for validation are based on OAuth 2.0.0 protocol. All secure authorization of APIs is provided using the OAuth 2.0 standard for Key Management. The API Gateway supports API authentication with OAuth 2.0, and it enables IT organizations to enforce rate limits and throttling policies for APIs by consumer. Login/Token API in the Gateway node should point to the token endpoint of Key Manager node. The Key Manager is given as https://localhost:9443/oauth2endpoints/token. In a distributed setup, it should be
| ||
| API Traffic Manager | The Traffic Manager helps users to regulate API traffic, make APIs and applications available to consumers at different service levels, and secure APIs against security attacks. The Traffic Manager features a dynamic throttling engine to process throttling policies in real-time, including rate limiting of API requests. | ||
| LB (load balancers) | The distributed deployment setup depicted above requires two load balancers. We set up the first load balancer, which is an instance of NGINX Plus, internally to manage the cluster. The second load balancer is set up externally to handle the requests sent to the clustered server nodes, and to provide failover and autoscaling. As the second load balancer, you can use an instance of Nginx NGINX Plus or any other third-party product. | ||
| RDBMS (shared databases) | The distributed deployment setup depicted above shares the following databases among the APIM components set up in separate server nodes.
|
...
| Table of Content Zone | ||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||||||||||||||||||||||||||||||||||||||||
Pattern 0Single node deployment.
Figure: All-in-one instance This pattern consists of a stand-alone API-M setup with a single node deployment. This pattern uses the embedded H2 databases. Pattern 1Single node deployment.
Figure: All-in-one instance This pattern consists of a stand-alone WSO2 API-M setup with a single node deployment. This pattern uses external RDBMS (e.g., MySQL databases). The only difference between pattern-0 and pattern-1 is that pattern-0 uses embedded H2 databases and pattern-1 is configured to use external RDBMS. Pattern 2Single node deployment, which has all WSO2 API-M components in one instance, with Analytics.
Figure: All-in-one instance with analytics This pattern consists of a stand-alone WSO2 API-M setup with a single node deployment and with a single Pattern 3Gateway worker/manager separation.
This pattern consists of a fully distributed WSO2 API-M setup (including a Gateway cluster of one manager and one worker) with a single Pattern 4
This pattern consist of a fully distributed API-M setup including two Gateway clusters, where each has one manager and one worker, with a single Pattern 5Gateway worker/manager separation. Gateway worker and Key Manager in the same node.
This pattern consists of a distributed WSO2 API-M setup including a Gateway cluster of one manager and one worker and the Gateway worker is merged with the Key Manager. It also consists of a single Pattern 6Gateway worker/manager separation. Store in the same node as the Publisher.
This pattern consists of a distributed WSO2 API-M setup (including a Gateway cluster of one manager and one worker) of which the Publisher is merged with the Store. It also consists of a single Pattern 7WSO2 Identity Server acts as a Key Manager node for the WSO2 API Manager.
This pattern consists of a stand-alone WSO2 APIM setup with a single node deployment. The pattern uses external MySQL databases. The only difference of this pattern from pattern-1 is that this uses WSO2 Identity Sever as the Key Manager. |
...