Externalization of business assets with IBM Cast Iron Web API
Introduction
In this blog we provide an overview of advantages using IBM Cast Iron Web API platform, and describing the usage of it’s analytics tools for adopting the enterprise to rapid changes in the market. We are using documentation and diagrams provided by IBM.
Markets are changing faster than ever. Companies are dealing with a shortage of skilled resources, time, and money to implement and maintain critical business applications that allow them to reach new channels and maintain a competitive edge, especially with the multitude of devices available today.
Additionally, integration with new and existing partners is taking too long. To help resolve these challenges, and sometimes by pure partner pressures, companies are externalizing core service as web APIs.
As web APIs can be easily invoked via mobile apps and browser, and since the application developers can easily access and use them, web APIs allow businesses to quickly integrate with multiple partners in a simplified and standard way. They also allow companies to tap into the large external and internal developer pools.
WebSphere Cast Iron Live Web API Services
WebSphere Cast Iron Live is a multi-tenant cloud service offering which consists of both web API services and integration services.
These services enable companies to orchestrate and create new web APIs, secure and manage the web APIs, gain business insight with analytics, socialize the web APIs in communities, and quickly integrate their cloud services with on-premise applications and enterprise systems.
WebSphere Cast Iron Live Web API Services is part of the WebSphere Cast Iron Live product, which provides a complete set of web API capabilities and can:
- Allow rapid creation of new APIs from existing business assets or cloud services through configuration.
- Attract more partners and innovative application developers, both internally and externally, by providing the application developers portal for creating applications on top of web APIs.
- Socialize the web API communities of the company in a branded developer portal with community hooks.
- Providing framework for business insights with analytics, which will be the basis for strategic evaluations in the future.
Web API Cloud Platform roles and flows
The following Roles are participating in the web APIs creation and consumption:
Enterprise Web API Administrator
- Creates web API from existing business assets or cloud services.
- Create and manages Quotas for different levels of usage and pricing per each web API.
- Customize Developers Portal with the Company specifics, which would be exposed to the application developers while Signing Up their application (for instance Terms and Conditions of Usage) and while creating their applications.
Application Developer
- Develops applications which use a combination of web APIs exposed in the company web API store.
- Registers the applications on the company web API store and selects the API entitlements level for each web API used by the application.
End User
- Uses the application (for instance on the mobile device), which interacts with the web API.
As depicted below, the administrator of the company web API store creates a number of web APIs (for Insurance, Airline and Retail). An application developer signs up to the web API store and browses the available APIs in the store, along with the documentation attached to the API. In order to make use of the APIs in his application, the application developer registers the application with web API store, and selects the entitlements level for each web API used by the application. As a result of the application registration, the application developer gets two tokens:
- The App ID – is a unique identifier for the application. If the API entitlement requires an ID for the calls, App ID must be included in each call to the API.
- The App Secret – is the application secret for the application. For extra security, some API entitlements require both the App ID and the App Secret to be included in the calls.
Externalizing web APIs
By providing each web API call with application identifier, the calls for the web APIs can be monetized, and provide the business insights with analytics. Each end user, making a call for the web API (for instance through mobile device), using this application, will implicitly passes the application credentials with the call.
Passing application credentials
The process diagram specifying the overall processes participating in the Web API consumption, is depicted below:
Process Diagram
Usage Scenarios
API Assembly with external APIs and on-premise services
Web API can be assembled as a combination of external APIs (for instance Salesforce.com) with on-premise SOA services and Database actions. The client of web API (for instance the mobile application) is unaware of the internal implementation of the API. The company can leverage the flexibility of creating this kind of APIs as prompt response to the change in the market.
API Assembly with external APIs and on-premise services
Expose SOA Services as APIs
An Enterprise can expose it’s SOA services as externalized web API, as depicted below. The exposed web API can contain the combination of internal services (usually protected within the Enterprise) and public services (for example Google Maps). The access to the SOA services by end user can be restricted through use of quota, while the partner access doesn’t have a quota restriction. In this scenario IBM DataPower acts as a Security Gateway protecting the enterprise and centralizing the access to its internal services.
Expose SOA Services as APIs
Analytics tools to identify value
The following tools are available through the dashboard on Application Developer Portal:
Number of calls per application (top 5 best performing)
Enables to evaluate the extent of user exposure of each application.
Number of calls per application (top 5 best performing)
Clients Invoking The Application
Enable to identify which client on the market uses/interested in the particular application.
Number of Calls per API ( Top 5 best performing)
Enables to identify if the exposed web API is indeed in use among the customers, otherwise it may be replaces with the updated web API, which better reflects the customers needs.
References
