Preface

As you are reading this, we can assume you will have some sense of what Oracle Integration Cloud Service (ICS) is; if you don't, then do not worry, as this book will guide you through the product and the underlying concepts. We start by putting ICS into context in terms of the rapidly growing cloud marketplace, and given that we are writing for the benefit of a broad audience, let's try to get a common understanding. As you probably know, enterprise cloud solutions can be roughly split into three layers: Software as a Service (SaaS), Platform as a Service (PaaS), and Infrastructure as a Service (IaaS). ICS fits into the broad band of PaaS, which itself is divided into many forms, but we will come back to that in a moment. IaaS services such as Amazon Web Services, Microsoft Azure, and Oracle IaaS are well understood–effectively, the provision of virtualized hardware and the idea is not that new. We just have cool new names and have developed the concept. If you were involved with websites 10 years ago, you would have talked about hosting using a third-party server on which you would have installed a chosen website tool or written something from scratch. The difference between then and now is primarily the hyperscales, the speed of provisioning, and the ability to provision as many servers as you need. SaaS, at the end of the scale, is essentially a full-blooded application that users may be able to configure to meet their specific needs, but fundamentally, there is no major development involved. Illustrations include commodity blogging solutions such as WordPress and enterprise-class capabilities such as Salesforce and Office 365.

PaaS differentiates itself from the top and the bottom tiers by the fact that the platform will give you a foundation far greater than just the operating system and network, but not a complete solution that is ready to configure and use. PaaS represents the cloud-based provision of the resources you would need to build a contemporary enterprise solution such as an empty database and an application container. To return to our IaaS analogy, if in setting up a hosted website you were given all the software preinstalled to then build the website (for example, a MySQL database and perhaps a CMS solution such as Drupal) and your provider took care of the patching and so on, of the software (that is, deployment of the latest software versions with new features, bug fixes, and security fixes for the O/S, MySQL, and Drupal), then you were buying into the idea of PaaS. The challenge in understanding is the vast breadth of functionality here – from almost SaaS-like offerings such as WordPress (which can be used to build whole websites) to cloud-hosted databases, which are only a bit more than IaaS. As a result of all the flavors of PaaS we talk about, the different areas of PaaS have developed their own terms to make them distinct from other PaaS offerings; for example, integration platforms have adopted the term of iPaaS (integration Platform as a Service), and cloud databases are referred to as DBaaS, and so on.

This fragmentation, as well as the desire for a similar acronym for all layers, has spawned the adoption of the expression XaaS—anything (or X) as a Service.

iPaaS can be commonly characterized in two flavors of products—the heavily technical solutions such as Oracle SOA Suite (known as SOA CS) and IBM's WebSphere Application Server on Cloud, along with the second type with graphical user interface-driven solutions in which ICS competes, which includes products such as MuleSoft, Dell Boomi, and SnapLogic. These more visual and often less technical tools can often draw on more consumer-like experiences, and you can trace the origins of this group of iPaaS solutions to consumer predecessors such as products in the form of solutions such as IFTTT (If This Then That – https://ifttt.com/) and Zapier (https://zapier.com), where you could set up in a fairly visual manner integrations like, when a favorite RSS feed posts something, you can get it to be tweeted by on your Twitter account by exploiting the APIs provided.

The difference between solutions such as IFTTT and iPaaS at the enterprise end of the spectrum is sophistication, capability, security, and reliability; that is, you expect enterprise solutions to be 24/7 resilient and very robust, not to mention, having a focus on connecting enterprise solutions such as Salesforce, Workday, Oracle Taleo, Office 365, and SuccessFactors. That said, as more social and collaborative platforms influence more and more of the workplace, we will see this line blur.

The last thing to keep in mind with our first iPaaS group is that these more technical products are typically cloud-enabled versions of their mature on-premises solutions. As mentioned previously, SOA CS is Oracle SOA Suite when deployed on-premises (with a few additional tools added to address the need to hide the platform considerations of the deploying SOA). The newer generation products, such as ICS, Boomi, and MuleSoft, are largely focused on a cloud delivery approach and cannot be deployed as on-premises solutions in the traditional manner (such as SOA Suite), although vendors such as Oracle are leading innovative thinking in this space.

Before we look at why ICS is a significant product in the iPaaS space, it is important to remember that you do not need to have acquired any other products from Oracle to use it. In simple terms, ICS can be used to integrate with any application/service if it complies with one of a number of supported standards or has an adaptor. The ability to offer adapters that simplify integration is going to be an area of growth and market differentiation.

Oracle has several distinct advantages in the marketplace that makes ICS a very significant player. Setting aside the arguments of Oracle's deep pockets, the factors you might consider are as follows:

• Mature leading integration solutions that can be exploited to create a new feature rich tool. Even while Oracle had focused on on-premises solutions, they have had to build connectors to major cloud solutions such as Salesforce and Workday, and these are being ported to the cloud.
• Oracle has a very large partner base and has created an ecosystem for partners, customers, and the wider community to build, sell, or donate their adaptors to work with ICS (and potentially for SOA CS and other parts of their PaaS offering).
• ICS can be easily adopted by both its middleware (SOA Suite and so on) and customer base, as well as its applications customers (E-Business Suite, Seibel, Fusion applications, and so on).
• Hyper-convergence means that Oracle owns solutions from microchips and other hardware all the way to SaaS, which in turn creates economies and optimizations as the hardware is tailored to provide optimal performance for the different product elements. It also allows Oracle to make market propositions the competition cannot, for example, protecting cloud services against attacks that exploit very low-level vulnerabilities because there is logic in the microprocessors to detect it.
• You can buy full Oracle cloud stack and run on-premises and even have a financial model based upon cloud concepts such as compute utilization (not hardware and license cost) and some other major vendors as recognizing this idea as well.
• If you are an Oracle customer, then your existing products will have the benefit of connectors that have been developed for Oracle's own products, making integration easier and simpler (something we will explore further in this book).
• Oracle's portfolio has been broadened and is now exploiting open source initiatives far more quickly within the PaaS space with the arrival of Application Container Cloud Service (based on Docker), Kafka service, and Node.js. In many respects, this approach appears a lot like that of Red Hat in so far as they take versions of open source offerings and then make them sufficiently robust enough that they can offer a service with them. This is something that can be done in a cost-effective manner, as Oracle can drive the continued updates and patching rather than needing to offer long-term support agreements for on-premises solutions.

The last point here is worth exploring a little further. Oracle's application portfolio has grown through build as well as acquisition. This has meant Oracle has needed to have a story for making these products working together easily. This approach has changed over the years, starting when Oracle effectively owned multiple discrete products and having overtime brought the best of the different products together to form what is now known as Fusion applications. The Fusion applications are also the core of many of Oracle's SaaS solutions (and the foundation of Fusion applications is Fusion Middleware and is the basis of nearly all Oracle products today).

The following diagram illustrates how Oracle has evolved and enabled integration between the different portfolio offerings over the last decade to arrive at where they are today:

We can characterize the different periods and their approaches to integration along the following lines:

• Oracle Products Period:
  • Completely discrete solutions with integration offered by middleware and licensed PIPs
  • Applications built on own technologies
  • Applications that effectively share nothing out-of-the-box
• Oracle Fusion Applications Period:
  • Rebuilt applications using Fusion technology stack
  • Here, product features overlapped the best ideas, which were carried forward to the Fusion generation
  • Integration needs that were sought to be reduced by making data models more common and exploit Fusion integration mechanisms internally
• Oracle Cloud Suites Period:
  • Grouping of related Fusion applications/components
  • Each cloud offering is now decoupled from other clouds—so, ICS is invoked by cloud solution event framework
  • The customer configures ICS to respond to Create, Read, Update, Delete (CRUD)-based services – interface data model mapping is kept easy through a recommendation engine populated with standard Oracle provided mappings