Oracle has release of Oracle API Platform Cloud Service. This new platform -not to be confused with Oracle's previous solution, has been built almost entirely from the ground up to satisfy modern API management requirements.
I have been lucky enough to be part of the beta programme and have actually been implementing the product for the last 4 months or so (but trying it for almost a year now). In this blog post I share some of the insight and experiences I've gained in the process.
What is the Oracle API Platform Cloud Service?
Is a 3rd generation API Platform that delivers a 'true hybrid' model that allows for APIs to be created, deployed and managed centrally (from the Oracle Cloud) whilst API gateways (engines that run the APIs) can be deployed in any cloud (i.e. Amazon, Azure, Oracle Cloud, IBM Softlayer/bluemix, etc) and/or on-premises.
In addition with the incorporation of Apiary into the portfolio, the platform also incorporates a solid/world-class API-first solution so developers also get the tools and means to properly design APIs either using Swagger or API blueprint (Apiary's own API design notation), whilst interacting with the API consumers and therefore ensuring that before any code is built, the API contract is fit-for-purpose.
API Platform Architecture
The platform consists of 7 key components as the diagram illustrates:
- Management service: The management service is the cloud-based system that underpins the management console, developer portal and platform API. It's the engine of the entire platform. The brains.
- Management Console: As the name suggests this is where APIs, Gateways and User/Roles are managed. It's a role-based application so what a user can do pretty much depends on the role the user belongs to.
- Developer Portal: A web-based application where developers can search and subscribe to APIs. This is where all of the API documentation can be found and also where application keys are provided after a subscription to an API takes place.
- Platform API: The entire platform was built following an API-first model. In fact, it can be argued that management service is in fact an API, as everything that can be done (and more) via the management and developer portals can be done by directly invoking the Platform API. The platform API is also consumed by the gateways when phoning home to retrieve new API's, policies and also send analytics information.
- Apiary: As previously mentioned, Apiary is a platform for designing APIs that encourages API designers to maintain an active dialogue with API consumers. Both the management and developer portals are already integrated with Apiary so when a user finds an API in the portal, the API specification (i.e. API blueprint) can also be accessed from one single place.
- API Gateways: These are the engines that run the APIs and can be deployed anywhere. In any vendor's cloud and/or on-premises. Gateways communicate to the management service iby making API calls (feature known as "phone home"). In this model, it's the gateways responsibility to establish the communication to the "mother ship" (management service) and not the other way around. Because of this, the management of gateways becomes a lot easier as there is no need to open firewall ports (i.e. opening firewall ports) as all communications are outbound triggered.
- Identity Cloud Service: Most organisations already have their own LDAP directory (i.e. MS Active Directory) where users and roles are managed. The Identity Cloud Service is used to allow the API platform to use an organisation's existing directory as the source for users and roles.
API Platform Roles
The platform by default support 5 types of roles.
- Administrator: Super user of the platform. Has all rights to deal with user settings and also create/manage APIs and configure gateways.
- Gateway manager: Role responsable for the gateway operations including deploying, registering, and managing gateways.
- API manager: The API implementers roles as it gives users full lifecycle rights, including design, create and deploy APIs and also manage the API grants.
- API designers: Individuals who take on a full or part-time responsibility (i.e. an architect or developer) to define APIs (either in swagger or API blueprints) using Apiary.
- Application developer: In other words, these are the API consumers. Users with this role can log into the portal and search/subscribe to APIs.
- Gateway runtime: Not really a user role, it's a service account used by the gateways to communicate with the to the management service via the platform API. Users assigned this role can’t sign into the Management Portal or the Developer Portal.
User can be created and assigned to any of these roles (excluding Gateway runtime which is a service account). Platform restrictions will apply depending on what role a user belongs to. Read the complete article here
SOA & BPM Partner Community
For regular information on Oracle SOA Suite become a member in the SOA & BPM Partner Community for registration please visit www.oracle.com/goto/emea/soa (OPN account required) If you need support with your account please contact the Oracle Partner Business Center.
Blog Twitter LinkedIn Facebook Wiki
Technorati Tags: SOA Community,Oracle SOA,Oracle BPM,OPN,Jürgen Kress