Oracle ACE Director Lucas Jellema kicks off an 8-part article series written by a group of fellow ACE Directors, based on a live session/demo involving ten different Oracle PaaS services, as presented at the 2016 Oracle Fusion Middleware Partner Forum in Valencia, Spain.
By Lucas Jellema
Article Series Table of Contents
- Introduction: How to Integrate Ten Different Oracle Public PaaS Services
Introduction
In February 2016 a brave band of Oracle ACE Directors accepted a challenge: demonstrate to a live audience how to make as many different Oracle PaaS products work together as you can. This challenge culminated in a one-hour live demo during the Oracle Fusion Middleware Partner Forum in Valencia, Spain in March 2016. During that session, ACE Directors Wilfred van der Deijl, Mark Simpson, Lonneke Dikmans, Torsten Winterberg, and myself showed an end-to-end flow across ten different Oracle PaaS offerings—kicked off by wild Twitter activity from the audience.
In this series of articles, these same daredevils will explain what they each did to provide the pieces of this 10-part puzzle. How they leveraged the Oracle Public Cloud offerings and welded them together for their integrated demo scenario—a wild ride across the cloud. The articles will touch upon the strengths for each cloud service, the typical integration points, and some of the challenges that have been overcome. Key code samples and configuration details will be provided.
The complete code repository is available on GitHub: https://github.com/lucasjellema/aced-cloud-demo-ofmw2016-valencia.
Initial Challenge and Objective
In our day jobs we are often confronted with a business scenario that needs to be mapped to a solution, a solution that typically comprises multiple middleware platform components working together to support a complex flow. In this case, we had to think backwards. Starting from an as-large-as-possible number of platform components or PaaS Cloud Services – we had to come up with a business scenario in which they could all be linked together at least somewhat realistically, and yet was still simple enough to be demonstrated in a one-hour session. Additionally, this business scenario should involve audience participation, a live demo that would offer a peek behind the magician’s curtain to prove it is really a live demo. And we needed several outcomes to present to the audience, not just XML messages and administrator’s consoles.
Additional constraints derived from the time we had to prepare, the skills between us, and of course the availability of the PaaS Cloud Services that were still being rolled out as we prepared for our live demo. We decided to go for the set of PaaS services indicated in the image below, including the Internet of Things, Integration, Process, Social Network, Sites, Document, SOA, Database, and Mobile Cloud Services, as well as the Application Container Cloud. The Sites CS was added less than one week before the show.
Defining the Business Scenario
Here’s the storyline we concocted to create our end-to-end cloud integration flow: at Oracle OpenWorld there is a great appreciation event each year in which a stunning line-up of artists performs for the conference attendees. The announcement about who will perform each year is a big surprise -- some years bigger than others. In our hypothetical scenario we thought it would be fun to include the community—represented by our live audience—in the decision-making process about which artists should perform at the next event. The audience would tweet their session proposals for this year’s appreciation event. If enough proposals were tweeted for a particular act, that proposal is picked up and put before a human approver. Based on various factors -- whether the act [still] exists, has recently performed at the event, is anywhere near budget and has more than a very niche-based following -- the proposal for the act is either rejected or approved. The approved proposals are published on a website.
This may sound like a simple enough flow. However, would that still be true after mapping the flow to a large number of cloud services?
The next figure illustrates how we took this fairly straightforward functional flow and projected it onto the PaaS Services that we had selected to demonstrate. Of course, it is extremely unrealistic to apply these services to this fairly silly business scenario. However, we do show how each service is used for a key characteristic and how the services work together.
The audience uses a special Twitter hashtag to publish proposals for acts to perform at Oracle OpenWorld, or uses a physical voting machine based on, for example, Arduino or Raspberry Pi technology. These proposal messages are processed by the Internet of Things Cloud Service, in much the same vein that events published from physical sensors and other things would be. If and when the number of proposals for an artist in a specified time period exceeds a configurable threshold, IoT CS calls out to the Integration Cloud Service (ICS). ICS is the middleman that forwards the selected proposal to Process Cloud Service (PCS). Here, a new human workflow is initiated, to have an approver judge the proposed artist. This actor can use Oracle Social Network to have conversations with colleagues or other relevant stakeholders about the proposal. If the proposal is approved, the approver can associate an appropriate image of the act with the proposal by uploading the image to the folder on Document Cloud Service (Doc CS) that is linked to the PCS workflow. While the approved proposal is sent from PCS via ICS to SOA CS to be recorded in the enterprise database, the actor can use Sites CS to quickly put together a micro site for the proposed act. In this site, the image that is forwarded to SOA CS can be reused from Doc CS.
Before SOA CS records the proposal in the Database as a Service, it enriches the data. Using a REST service that calls out to the Spotify and Echo Nest APIs, implemented in Node.js and running on the Application Container Cloud, it gathers biographical data on the artist as well as a list of recently released albums and URLs to album cover images. When SOA CS is done recording the enriched proposal details, it calls out to ICS to leverage the ICS Cloud Adapter for Twitter to publish a tweet, announcing the new artist proposal to the world; this tweet included the title of the most recent album from the artist.
All proposed artists are published through a rich and responsive client web application that is also mobile enabled. This application is developed using Oracle JET and deployed as a Node.js application on an instance of the Application Container Cloud (ACC) service. This application uses REST and JSON based APIs published from the Mobile Cloud Service (MCS). MCS is also used to track usage of the APIs and enforce security constraints. The MCS APIs are backed by the SOAP Web Services implemented on SOA CS to publish the information on the current artist proposals.
Organizing the Work
Once the high-level business scenario was decided upon and the mapping to the various PaaS Cloud Services was complete (as discussed in the previous section), we could define the deliverables that need to be created by our geographically distributed team and allocate the associated work packages among the team members.
The next figure describes the major areas of implementation that we identified and allocated. The interaction with the outside world – Twitter and physical devices – and the analysis of the incoming event messages using IoT CS is a distinct area on its own, tackled by Torsten. The next area covers all forms of human workflow, including the integration with Social Network and Document Cloud Service as well as the microsite management with Sites CS. Mark took care of this area. ICS and SOA CS are the linking pins to help achieve a smooth flow, using DBaaS for persistence and ACC for easy REST callouts. I handled this integration. The contract-based design, mock creation and real implementation of the Rich Client APIs on MCS are under Lonneke’s jurisdiction. The rich, responsive and mobile-enabled JET application running on ACC and calling out to these MCS APIs is created by Wilfred.
At this point, what we really needed was a good definition of the interfaces and interactions between each of these areas. As a team, we were distributed over three countries and five physical locations and even though we were in more or less the same time zone, we worked on our various deliverables at very different times, so we might as well have been spread out around the world. Interfaces to allow decoupled development were of the essence. As you will learn from the detailed articles, we quickly defined the REST APIs and JSON message formats as well as some SOAP Service contracts and XSD-based XML message definitions that allowed us to work independently towards the integrated flow.
The first steps after defining these interfaces were, on the one hand, the creation of mock implementations of the services and APIs we agreed on, and on the other the definition of test cases in Soap UI to test call outs to each of the interfaces along our end-to-end flow.
Getting Hold of Cloud Service Instances
The plan was ready. Time to execute. And for our execution, we needed running instances of the PaaS Services involved in our scenario. Through the Oracle ACE Director program, we have personal access to a number of cloud services, running in the EMEA2 Data Center. With the help of Jürgen Kress, responsible for partner adoption of Fusion Middleware and Oracle PaaS Services and a great friend to the community, we also got access to a number of trial service instances in the US2 Data Center. At the time, we did not have access to a cloud-based instance of IoT CS; instead, we used a VM image with the complete set of software. Because our flow starts with IoT CS listening in to external sources and routing to ICS, we could still do the complete demo starting with this workaround; all other cloud service instances need to be running in the cloud.
The next figure illustrates how we used various instances spread across the globe.
Conclusion
You now know our objectives and our approach for tying together ten PaaS Cloud Services. You know how we conceived of a business scenario to somewhat credibly integrate these services and how we created a mapping between the scenario and services. We have identified five areas and sets of deliverables, we have divided the work between the team, and we have procured a set of cloud service instances to create and run our deliverables. You can now read the detailed articles that describe the work we did in each of these five areas to implement the pieces of the end-to-end integrated flow across the clouds.
About the Author
Oracle ACE Director Lucas Jellema is solution architect and CTO at AMIS, based in the Netherlands. An Oracle, Java, and SOA specialist, he works as a consultant, architect, and instructor in diverse areas such as Database & SQL, Java/Java EE, SOA/BPM and PaaS and SaaS Cloud Solutions. The running theme through most of his activities is the transfer of knowledge and enthusiasm (and live demos). Lucas is a well-known speaker at Oracle OpenWorld, JavaOne and various Oracle User Group conferences around the world. His articles have appeared in OTN, OTech and the AMIS Technology Weblog, and he is the author of Oracle SOA Suite 11g Handbook (2014, McGraw Hill) and the Oracle SOA Suite 12c Handbook (2015, McGraw Hill).
This article represents the expertise, findings, and opinion of the author. It has been published by Oracle in this space as part of a larger effort to encourage the exchange of such information within this Community, and to promote evaluation and commentary by peers. This article has not been reviewed by the relevant Oracle product team for compliance with Oracle's standards and practices, and its publication should not be interpreted as an endorsement by Oracle of the statements expressed therein.