Evolution of Oracle's API offering

As described in the Preface of this book, APIs are not really new. What is new is how we refer to them in the context of the web architectures and the standards/technologies/protocols used to deliver them. For this reason, when looking back through time, one must also look at traditional integration platforms such as Enterprise Service Bus (ESB).

For example, Oracle's first ESB offering was part of the very first release of Oracle SOA Suite (10g) launched mid/late 2006. This ESB centric architecture, offered support for SOAP/WSDL-based APIs that at the time we referred to as web services. It also offered support for emerging standards such as Business Process Execution Language (BPEL) with BPEL Process Manager, WS-* standards such as WS-Security with Web Services Manager (WSM), business rules with the Rules Engine (also known as Rules Author) and real-time business dashboards with Business Activity Monitoring (BAM).

This ESB and open-standards centric architecture delivered the initial capabilities for XML-based APIs. This is why it is referred to in the diagram as Generation Zero. In other words, the starting point:

Oracle's Generation Zero API platform

As SOA continued to gain popularity, Oracle's offer also evolved to offer richer capabilities in support of Service Oriented Architectures (SOA).

It is worth mentioning that some of the reasons SOA had become so popular industry-wide are because it promised to deliver countless business benefits, most notably, it promised to close the gap between business and IT with the adoption of languages such as BPEL that in theory would make it easier for business people to define processes that could later be executed, reduce of IT spending by re-using existing assets exposed as web services, increased business agility by providing an architecture that was easier to change and evolve, and better visibility and insight over how and when business assets were used and reused and how processes were executed.

Oracle SOA Suite 11g, released around 2008, was an important milestone for Oracle and it enjoyed vast community support and wide-spread industry adoption. The product was the result of the merge of SOA Suite 10g with the then recently acquired BEA Aqualogic offering. It was (and still is) feature-rich and many used it as a one-stop-shop to deliver SOA and requirements around it:

Oracle's 1^st generation API platform

An important characteristic of 1^st generation is the appearance of what was referred at the time as XML Gateways. The main purpose of such Gateways was to act as a Security Proxy to SOAP Web Services in Demilitarized Zones (DMZ) so when exposed to untrusted or insecure networks (for example, the internet), the Web Service would have an additional layer of security. Some of the capabilities introduced by such gateways were SSL termination, WS-Security and protection against major treats such as the ones mentioned in the Open Web Application Security Project (OWASP) Top 10. Although at this time Oracle did not offer a specific solution for this, the industry saw the likes of Vordel (later acquired by Axway), DataPower (later acquired by IBM), and Layer 7 (later acquired by CA) emerging as leaders in this space.

As the adoption of SOA proliferated across organizations of every size, almost in parallel the popularity of smartphones and mobile apps rocketed, to the point of becoming an essential part of everyone's everyday life. From this point forward, mobile apps became a vehicle for organizations to not just more intimately engage customers, but also to introduce mobility to the workforce which would in turn optimize processes and increase productivity.

It's worth noting that the popularity of smartphones really started with the launch of Apple's first iPhone back in 2007. Although the concept of apps wasn't really new (specially in Linux communities), the iPhone made it a marketing session and mobile apps became the new session.

As communities of mobile developers grew exponentially around the globe, a common trend started to emerged. When it came to delivering access to backend enterprise information assets, majority of mobile developers favored Roy Fielding's REpresentational State Transfer (REST) architectural style to implement APIs over the technologies and protocols commonly used in traditional SOA architectures (for example, XML/SOAP web services).

By many, web services and standards around it had perhaps become too complicated, both to understand and implement, and therefore, a simpler way of implementing APIs was well received, not just by mobile developers, but eventually also by application developers and SOA practitioners as well. Needless to say, the popularity of SOAP-based web services started to decline, and the use of REST APIs became prevalent.

At this point a new architectural component was introduced in the majority of solutions: the API Gateway. The purpose of the API Gateway was (and still is to an extend) to not only provide the security capabilities offered previously by XML Gateways, but also the message routing capabilities offered by ESBs, however in the context of REST APIs, and thus supporting different message notations (like for example the JavaScript Object Notation (JSON) as alternative to XML).

Perhaps because of the obvious similarities of API Gateways to ESBs and also XML Gateways, majority vendors opted to adjust their existing (1^st generation) offerings.

2^nd generation API platforms are therefore nothing but (1^st generation) ESBs and/or XML Gateways that had been extended and/or enhanced in support of rich REST APIs capabilities and the life cycle management of API, disciplined later known as API management.

For example, Oracle's 2^nd generation API Management Suite (launched between 2013 and 2015), consisted of the following components:

• Oracle API Catalog 12c, an adaptation (simplification) of Oracle Enterprise Repository (OER) to support the harvesting and cataloging of REST APIs
• Oracle's API Manager 12c, an extension to Oracle Service Bus (OSB) to support management capabilities of REST endpoints
• Oracle API Gateway 11g, an OEM of Axway's (former Vordel's) XML Gateway which was adapted/extended to support REST and JSON payloads

More on this in Chapter 10, Moving from API Management 12c to APIP CS.

Oracle's 2^nd generation API platform

Although 2^nd generation API Platforms did provide some of the answers many customers were after, they also had a major pitfall. As they are in effect the result of additional layers of capabilities and extensions added to an existing (perhaps already complicated) stack, instead of delivering the simplicity that made the REST architectural style so popular, the entire process of installing/configuring the platform plus building, deploying and managing APIs on top tended to be very complicated, to say the least.

During this same period, Cloud Computing had also become a serious choice for large organizations to run their workloads. This meant that information assets were no longer to be available in on-premise data centers, but also in a vendor's cloud (and not necessarily Oracle's). Because of this, capabilities to being able to also implement APIs in the cloud were also expected of a vendor's API Platform.

As if this wasn't enough, the rise of Microservices Architectures as a more flexible, highly scalable, and alternative way to implement APIs and realize SOA meant that traditional 2^nd generation platforms seriously struggled to keep up with the pace of change and thus, meet the expectations of customers – many of which had already been exposed to a degree to all these new technology trends.

3^rd generation API Platform are therefore born not as enhancement or extension of previous offerings, but rather built to a very large extend from the ground up to satisfy modern architectural requirements souring REST/Web APIs, microservices architectures and hybrid landscapes where information is distributed among systems deployed in the cloud (and not just one, but multiple clouds) and on-premise data centers:

Oracle's 3^rd generation API platform

That said, Oracle API Platform Cloud Service was launched early 2017 as a strong response to the industry demands and as a flagship product for API Management in general. The offering aligns perfectly well with the concept of 3^rd generation API Platforms not just because of its hybrid capabilities, but also because of its flexible and scalable architecture which makes it suitable for use not just in traditional SOA landscapes, but also modern Microservices Architectures, both on-premise or cloud.

The platform, built almost entirely from the ground up, does not have any relation with Oracle's previous (2^nd generation) API offering as it is much simpler, lighter weight, and scalable. The following chapter describes this in more detail.