In my previous blog post, I wrote about how IBM API Management can be used to create, secure, socialize and manage application programming interfaces (APIs) to address the requirements of business users, IT operations and mobile app developers. In this blog post, I will delve deeper into the product architecture and describe the deployment topology and user interfaces.
IBM API Management deployment topology
IBM API Management customers will typically have multiple environments such as development, test and production.
Each environment consists of the following nodes:
- Gateway node: one or more physical or virtual IBM WebSphere DataPower appliances that implement API security, usage limits and caching at run time. All API traffic is processed by this node first before being routed to proxied HTTP endpoints or the assembly node.
- Management node: one or two virtual appliances that store the environment configuration and host the user interfaces. The gateway node caches a copy of the configuration it requires so that the management node is not queried for every API call.
- Analytics node: one or more virtual appliances that collect and store data about the runtime API traffic flowing through the environment. This data is used to generate graphs that show which APIs are being called, who is calling them and how often. It is also used to monitor the health of the appliances in the environment.
- Assembly node: one or more virtual appliances that add the ability to assemble APIs from systems such as databases, SOAP services or HTTP data sources. This node can be used when an existing Representational State Transfer (REST) service is not available to proxy, or when you need to convert a SOAP service to REST in minutes. Data from multiple sources can be composed into a single API resource. The data format can be transformed using a simple graphical mapping tool that includes basic functions such as converting text to upper case or concatenating several fields.
Each environment can be scaled dynamically by adding or removing nodes at run time. Before a node is added, the underlying appliance must be started and configured on the network. Virtual appliances can be hosted in either VMWare ESXi, IBM Workload Deployer or IBM PureApplication System.
IBM API Management user interfaces
IBM API Management has a different user interface for each set of stakeholders:
1. Environment console
This is used by information technology (IT) operations to configure, manage and monitor the health of the IBM API Management environment.
2. API manager
The API manager is used by IT operations to create, secure and monitor performance of APIs. Business users also use this interface to do the following:
- Customize the developer portal to socialize the APIs
- Add samples and tutorials to the self-documenting APIs
- Control visibility and access to APIs
- Gain business insight through analytics
3. Developer portal
This is used by mobile app developers to do the following:
- Create a developer account
- Browse the available APIs and learn how to use them
- Register their apps so they can invoke the APIs
- Monitor the API use from their apps
All the user interfaces are viewed from a web browser; Microsoft Internet Explorer, Google Chrome and Mozilla Firefox are all supported.
Each environment contains one or more tenants that logically partition the system into separate organizations for increased flexibility. The tenants are configured in the environment console, and each tenant has its own API manager and developer portal. Therefore, an API developer with an account in the API manager for one tenant cannot view or edit APIs in another tenant. Similarly, an app developer with an account in the developer portal for one tenant cannot view or register to use APIs in another tenant.
If you’re interested in the IBM API Management product, you can learn more about it on ibm.com, YouTube, Slideshare or Speaker Deck. Also, please feel free to leave a comment below or connect with me on Twitter.