In this article Oracle ACE Associates Arturo Viveros and Robert van Molken, and Oracle ACE Rolando Carraso discuss Oracle SOA Cloud Service in detail, together with its implications, possible use cases and scenarios. The authors also attempt to clarify some potentially confusing elements and draw some first-hand conclusions on the present and future of the product.
by Arturo Viveros
, Robert van Molken, and Rolando Carrasco
Introduction
Service Oriented Architecture (SOA) has been present in the Oracle Fusion Middleware Stack for many years now. With varied and powerful options such as Business Process Execution Language _(_BPEL) Process Manager, Service Bus, Mediator, Business Rules, Business Activity Monitoring (BAM) and others all running on WebLogic Server (WLS) since version 11g, SOA Suite has established itself as the solution of choice for achieving all kinds of on-premises integrations, as well as a comprehensive toolset for enabling the adoption and implementation of Service Orientation design principles.
Furthermore, and looking beyond the tools, SOA itself has evolved into a modern and dynamic architectural style, aligned with business and industry trends and widely regarded as an enabler for technological innovation and digital disruption.
Long gone are the days when SOA adoption was perceived as an almost esoteric ultimate goal, as are the proclamations that left it for dead. After its first generation, SOA reinvented itself and took hold in the IT mainstream. In this regard, SOA Suite has maintained its relevance, despite Oracle’s transformation into a Cloud-first company; so much so that, within a single year, we witnessed first the emergence of a 12c version, an Integration Cloud Service (ICS) built on top of it, and now the delivery of a full-fledged SOA Suite Cloud Service.
In this article we discuss this new offering in detail, together with its implications, possible use cases and scenarios. Along the way, we’ll also attempt to clarify some potentially confusing elements and draw some first-hand conclusions on the present and future of the product.
SOA Cloud Service Overview
First, Oracle has categorized this new offering as an Integration Platform as a Service (iPaaS) alternative, and rightly so. Let’s look at Gartner’s definition for iPaaS:
“…a suite of cloud services enabling development, execution and governance of integration flows connecting any combination of on premises and cloud-based processes, services, applications and data within individual or across multiple organizations”
This is a very broad definition for a cloud-based solution, where Oracle has positioned a lightweight and simplified option in ICS; nevertheless, the need for integration within the cloud increases by the day, which definitely leaves room for much more.
So, this is where SOA Cloud Service comes in, as a ready-made platform for running not only the bona fide functionalities of SOA-Infra and Service Bus, but also API Manager; a recent and very valuable addition to the Fusion Middleware stack (we’ll come back to this later).
Let’s take a look at the components available in this first release:
|
- Oracle SOA Suite
- Oracle Cloud Adapters
- B2B
- MFT
- Event Processing
|
- Oracle Service Bus
- Oracle Technology Adapters
|
That’s a whole lot on our plate to get started with the design and implementation of increasingly sophisticated and robust cloud integration solutions.
Another interesting angle is to match up this product with the strategic cloud benefits and characteristics that organizations are commonly looking for when acquiring an iPaaS solution:
|
Reduced investment and proportional cost
|
With a SOA CS subscription, organizations don't need to invest in elements such as infrastructure, licensing, installation, tuning, and maintenance.
|
|
Scalability
|
Scalability is inherent to this kind of cloud deployment model; in the case of Oracle, it is further enhanced by the infrastructure behind the curtains (Oracle Public Cloud, Java CS, Exalogic, Exadata, etc.).
|
|
Availability / Reliability
|
These are also inherent cloud characteristics, meaning that the client needn’t worry about typical on-premises issues like disaster recovery, continuity of business, etc.; this is well supported both by data center setup and redundancy, as well as by internally leveraging WLS/Oracle DB clustering and failover capabilities.
|
|
Rapid provisioning
|
This is an important one, particularly because of the accelerated time-to-market usually required by cloud integration initiatives. In this regard, a client subscribes to SOA CS and easily requests provisioning of the desired environment entirely through a self-service portal. The environment setup then takes place automatically and is delivered in a matter of hours, as opposed to the weeks or months that would have to be invested for a new on-premises SOA domain.
|
|
Ubiquitous access
|
Having SOA Suite 100% in the cloud means that remote access for multiple purposes (development, monitoring, management, deployment) can be done from any location at any time.
|
|
Measured usage
|
This is a paramount characteristic of cloud-based solutions; API Manager, SOA Service console and Enterprise Manager Cloud Control are the available options for monitoring and measuring the activity flowing through SOA CS.
|
Finally, it’s important to note and understand some fundamental differences between the SOA CS and the on-premises version, especially for developers, system administrators and architects who are well acquainted with SOA Suite and/or Java Cloud Service:
|
Available domain types
|
In SOA CS’s first release, only the following configurations will be supported:
- SOA
- Service Bus
- SOA + Service Bus (1 domain)
- API Manager
This also means that for the time being it’s not possible to configure a custom domain type; you have to pick one of those from a list (no configuration wizard)
|
|
Administrative Tasks
|
Patching, scaling and backup/recovery are taken care of automatically and homogeneously across all of the client’s SOA CS instances; thus, Oracle SOA CS domains are not available to run on JCS’s virtual image configuration.
*The customer will be able to decide when to apply most of the patches and upgrades
|
|
Supported versions
|
SOA Suite & API Manager 12.1.3 with version 12.2.1 coming soon
|
|
Prerequisites
|
Oracle SOA CS does run over JCS; however, a client does not need to have a JCS subscription in order to buy SOA CS, as it all comes in the same bundle and subscription rate.
DB Cloud Service, on the other hand, is required for provisioning the SOA CS domain, so the client must have a pre-existent DBCS instance compliant with the SOA domain's needs.
Storage Cloud Service is also a prerequisite for SOA CS.
*Repository Creation Utility (RCU) will be executed by the automated provisioning process
*Disc storage is allocated for any of these services through the Compute Service Console
|
|
Managed Server Configuration
|
This is very different from most on-premises implementations, where it is very common to set up complex domain configurations comprised by multiple clusters and dedicated/load balanced managed servers.
In SOA CS, the above is not supported, so the way to go is to provision as many single-purpose domains as needed, and later leverage the available virtualization technology by assigning the right number of OCPUs for each use case’s required computing capacity.
|
|
Developer tools
|
In the beginning this will be almost identical, because developers will rely on JDev to locally design, test and debug SOA projects.
According to Oracle’s roadmap for the product, integration with Developer Cloud Service will be available soon enough. This is very relevant as the kind of cloud integration projects organizations will want to do with SOA CS will be highly suitable and even probably require agile development, continuous integration and a DevOps discipline.
|
Some of these considerations are critical in the design and implementation of SOA CS projects and should be kept in mind when facing the prospect of utilizing this powerful tool.
So now that we have had an overview, let’s identify the most relevant use cases for Oracle SOA CS.
Key Use Cases for SOA Cloud Service
The SOA Cloud Service is the newest descendant in the IPaaS space, but because of the growing number of Cloud Services, it's good to know where the SOA CS makes a difference. Let’s look at some relevant uses cases.
The SOA Cloud Service is best in these key use cases:
- Sandbox (incl. Dev/Test) environments in the Cloud
- Lift & Shift on-premises workload to the Cloud
- Rapid development of SOA Applications born in the Cloud
- Hybrid cloud integration/orchestration
Provisioning Sandbox, Dev and Testing Environments
Every project demands a stable environment on which to develop and test--but it can take some time/resources to get an on-premises environment provisioned. Imagine if you had to provision only acceptance and production on-premises. With SOA CS, it is fast and easy to provision those environments in the Cloud. And on SOA Cloud CS you can create UAT environments per customer, patch validation, security fixes; you can also test the upgrade before purchasing.
Figure 1: Development and test environments in the Cloud
Lift and Shift on-premises workload to the Cloud
Low resources to manage and administer on-premises environments? Need to lower the Total Cost of Ownership? Migrate any SOA, Service Bus, B2B, or Managed File Transfer (MFT) Production applications to SOA Cloud Service. Just deploy the already built version of your on-premises application to the Cloud just as easily as you would to any on-premises environment. SOA CS supports one-click patching, out-of-the-box backup strategy and scale-out of cluster nodes. If your company needs to comply with new regulations, it is possible to bring the SOA application back on-premises.
Figure 2: Lift and Shift workload to the Cloud
Rapid development of new SOA Applications
Does it take your organization to organize the necessary on-premises environments/bare metal? With SOA CS, you can build and deploy a departmental/born in the cloud SOA Application from Development to Test to Production in the cloud--with no waiting time and no need for your own hardware or resources to provision the environments.
Hybrid cloud integration/orchestration
Today, we already have SOA Suite environments running on-premises. Some are even high-risk systems that are just not built for the Cloud. With SOA CS you can extend functionality to SaaS applications, integrate SaaS applications and on-premises apps, and create a secure entry to your on-premises applications. Integrate with other cloud services as Integrated Cloud Service, Internet of Things Cloud Service and/or the Process Cloud Service.
Figure 3: Hybrid integration with ICS, SOA CS, PCS and SOA Suite on-premises
Where does SOA Cloud Service fit with ICS and PCS?
The use case for SOA Cloud Service can be confused with Integration Cloud Service; in the future, they may overlap even more. Let’s look at both Cloud Services and determine which one is best under certain circumstances.
Integration Cloud Service
ICS is best when most of your integrations are between cloud-based applications and you have little (to no) need for integration to on-premises, or between on-premises applications. ICS is ideal when integrations and mappings are less complex. The focus is usually on rapid integration. Keep in mind that ICS has a limitation of 100,000 messages per hour on each connection, which includes sending and receiving messages. If your use case will exceed this number, you might want to look at SOA Cloud Service.
Figure 4: Integration flow of two web services with capabilities explained
In the next update ICS is getting much powerful, with such new features as content-based routing, Business Process Management (BPM)/ Business Process Execution Language (BPEL)-like orchestration and Data/File integration with scheduling. With these features, the gap is closing even more.
Figure 5: Content-based routing in next ICS update
Process Cloud Service
The Process Cloud Service (PCS) is best when you want to rapidly automate such business processes as your internal travel and expense management in the Cloud. PCS is not BPM Suite in the cloud and can’t be compared to that. With PCS, you can create business-friendly forms in a self-service environment, which even provides out-of-the-box mobile capabilities. It includes tooling and run-time for process design, execution, monitoring and optimization, but lacks functionality for adaptive case management and custom scripting. PCS can integrate through ICS and SOA CS with cloud and on-premises applications.
Figure 6: Create business processes using web-based composer in PCS
Taking away the confusion
The SOA Cloud Service--or, in other words, SOA Suite in the Cloud--is best when you have to handle integrations between Cloud to on-premises, between on-premises applications, or if you have Mobile, IoT or B2B integrations. With SOA CS, you can quickly deliver integration projects without provisioning knowledge or investing in hardware, but want the same access, backup and portability as on-premises.
Yes, both Integration Cloud and SOA Cloud provide a service to integrate between SaaS Cloud applications and on-premises. Even so, the ICS is for a different kind of integration--simpler, and for a different kind of user, namely, the citizen developer. When taking about the citizen developer a LOB user is referred that knows what the business wants and can create the integration without a lot of technical knowledge.
The biggest difference between the Integration Cloud and the SOA Cloud is that ICS is mostly for short-running, point-to-point integrations with the possibility of enriching data using intermediate calls, while SOA CS is for more complex orchestrations, and long(er)-running integrations with all the possibilities of integrating with B2B, IoT and Managed File Transfer.
How do they co-exist and work together?
All the above Cloud services are made to co-exist and work together. Let’s demonstrate that with a feasible scenario that uses the three services and the upcoming Agent to connect to Cloud and on-premises applications.
Figure 7: ICS, PCS, SOA CS and API Mgmt CS co-exist and work together
Introducing the Agent
A newcomer in the image above is the Agent. With the Agent you can connect to on-premises without an already existing SOA Suite environment. The Agent itself delivers a platform to connect to on-premises applications using the JCA Framework. The Agent uses the Messaging Cloud for message exchange by creating a secure connection to the Oracle Cloud. When using the Agent, you don't have to open inbound ports or host assets on DMZ.
Exploring the full potential of the Integrated Cloud
Using the image above, imagine the following scenario: let’s take our internal travel and expense management case and automate it using PCS. In PCS, a webform is created with which it is possible to submit a travel/expense declaration. When the form is submitted, the form data is send to a web service published by SOA CS.
The web service virtualization is done by the Service Bus component and is secured using API Manager CS; this means an API key must be used to call the web service. (You can read more on API Mgmt CS in the upcoming section.) The Service Bus routes the message to an SCA Composite with the same interface, which uses the BPEL component to orchestrate the data first to the Service Cloud via ICS and then to the on-premises Enterprise Resource Planning (ERP).
ICS uses the data from the webform to create a new service ticket in the Oracle Service Cloud. ICS is used because of the available Cloud adapter for the Service Cloud, and because a citizen developer (e.g., a LOB user) can implement the right integration much more quickly. There is no need to transfer knowledge to the Integration developer. The Service Cloud returns the number under which the ticket is created and ICS returns this number, in the same synchronous transaction, to the BPEL process.
BPEL combines the data from the webform and the result from the Service Cloud, passed by ICS, and calls the on-premises ERP application, via the Agent, using the JCA adapter framework. In ERP, a process is started to feed the declared expenses to the financial administration.
The initial process is now finished, but the business process is still open in PCS. Both the Service Cloud and ERP can send update messages to interact with the process in PCS. PCS can be used to validate the expense declaration and accept or decline the declaration.
In this scenario the Service Cloud is used to inform (external) parties about the progress of the expense declaration. And when, for example, the declaration is declined, PCS can send this status using SOA CS and ICS to the Service Cloud to update the ticket. The same goes for the ERP application/process: it can send update messages via the Agent through SOA CS and ICS to the Service Cloud to notify when expenses are paid and travel arrangement are made.
Why API Management in SOA Cloud Service?
API has been a hot topic for the last five years or so, but software development history has shown us that APIs have been around forever. I remember my old days of integration programming, and one of the first questions I used to ask was:
“Does your application have an API that I can use to integrate with?”
Normally, those APIs were exposed as JAVA, C or even .NET. In order to use them, you needed to know those programming languages. If you were a versatile programmer, then any language was OK, but if you just knew how to program with one of them, then the problems started. There was no standardized way to engage with an API. To think about how to control the release of those APIs, to engage with the programmers, was right out of the equation. Applications were just trying to offer a way to enable others to communicate with them, but nothing more than that.
Further, those applications were meant to be on-premise. Or, if it were a B2B type of integration, other mechanisms were available to achieve this. Our programming environment was here on land, not in the clouds.
So a need to expose those APIs to the external world was a problem that the IT guys didn't have. And since there was no need for mobile development, we didn't need to have an API strategy.
We could say: I’ve been using or even developing APIs for a long time, but I haven’t been interested in exposing them, managing them, sharing them, and securing them until recently.
Let’s keep in mind that mobile and the Cloud are here for all of us--not just as consumers but as service providers. So a new economy has been born: the API economy.
Enterprises have just started to expose their business assets in an API fashion. Developers are constantly creating new applications to deploy them through the common mobile apps platforms (iOS, Android) and users are enjoying the functionality.
Consider the possible uses cases for this. Imagine a telco that wants to move into the MVNE (Mobile Virtual Network Enabler) space and create a set of MVNOs (Mobile Virtual Network Operators). This telco already has assets to create new subscribers, to charge them, to offer them new products, to create packages that mix SMS, Internet, etc. So if they are to offer an MVNE platform, the only thing they need to do is to take this step to create, expose and control their APIs.
Then imagine the MVNOs. They just need to connect to those APIs and start offering a telco service; all the business logic will be accessed through the APIs. The MVNE will benefit with each new subscriber (for example), and also for every time the MVNO uses their APIs.
The MVNOs, for their part, benefit because they now offer products that they couldn’t even imagine they could offer.
And users benefit because they have a broader telco offering from which to choose.
As we can see, there are many benefits in this new API economy--and most of the time all this is happening in the cloud, which seems to be the natural environment for APIs.
Enterprises are looking to expose their APIs, but that means that many others could use them. In order to be prepared, in order to respond to this demand and maintain flexibility, the following cloud concepts and platforms are key:
- Elasticity
- Scalability
- Consumption model
Oracle has very well identified this environment and offers us a cloud platform where APIs can live as comfortably as you can imagine. This is a brand new Oracle Cloud offering: Oracle API Manager Cloud Services.
From Oracle.com:
This Oracle Cloud offering is very well aligned to what we’ve described elsewhere in this article.
We are describing all this to answer the question of how important it is to have Oracle API Manager as part of the Oracle CS. As we’ve described, the Cloud is a common environment for APIs, and it is there that we would like to expose them so that developers can easily engage with and use them. It was thus very natural for Oracle to decide include the API Manager in their Cloud services, and to integrate it with the ICS and with the brand-new SOA CS.
CONCLUSIONS
The Oracle SOA Cloud Service and the Oracle API Management Cloud Services are two great product offerings by Oracle. Both confirm the leadership that Oracle has in the market, specifically in the SOA space. The API market will be for Oracle as well, there is no doubt about it.
To have such a powerful SOA platform in the Cloud is exciting. For those of us who continuously face challenges to integrate on-premises with Cloud-based applications, or Cloud-to-Cloud integration, or even challenges where customers are looking to have a real SOA solution in the Cloud, this Oracle offering is just great.
For Dev and test environments to have this subscription option for SOA Suite in the Cloud is huge. We have had significant projects where the whole purpose is just to install the product. It could take weeks to install a couple of domains--not because of the difficulty of the installation process, but because of the HW provisioning, network adjustments, operative system installation and tuning, database provisioning, security, etc. Now, however, you just need a browser and, after a few clicks, you have an environment ready to be used.
For SOA Developers and Architects, this represents a major change and a big opportunity to continue to specialize in this exciting SOA space.
The world’s digital transformation needs this type of foundation: Cloud, Mobile and Integration. As Developers and Architects, we can envision that the market will continue to demand this type of skill more than ever, and that we will have work for the upcoming years. But if we think of it as a new economy, just as the APIs are, it is a very good opportunity to generate new business. Not only does the enterprise benefit, so do developers. It's already happening with the mobile apps development.
For an Oracle SOA specialist, API Management should be a natural step. But it is very important to understand the differences between an API strategy and an SOA strategy, and to identify to whom we are going to pitch API Management, SOA Governance or both.
The SOA specialist has become a very key individual in the IT organization. With API management, with Mobile, with Cloud projects, with typical integration projects, with innovative projects, with strategic projects, with digital transformation projects, the common denominator could very easily be: SOA and API Management. Further, the perspective of having SOA projects that are born, evolve and stay entirely in the Cloud speaks for itself as a brave new world of technological innovation keeps emerging before our eyes.
This is a great moment to continue growing our expertise. Oracle has created a very strong stack, so let’s use it. This is just the beginning.
About the Authors
Arturo Viveros is an outstanding professional currently based in Mexico City, with 12 years of experience in the development, design, architecture and delivery of IT Projects for a variety of industries. He is also a regular speaker in technology conferences, both in Mexico and abroad. He is an Oracle ACE Associate and member of the S&P Solutions team. Arturo is also part of the coordinating committee for ORAMEX (Oracle User Group in Mexico) and has recently achieved the Oracle SOA Certified IT Architect certification as well as the Cloud Certified Architect and SOA Certified Architect grades from Arcitura Inc. He is a certified trainer authorized to deliver the SOA School and Cloud School modules both in English and in Spanish. Arturo is also the co-founder and chief editor of the SOA MythBusters blog and co-author of the recently published Oracle API Management 12c Implementation Book.
Robert van Mölken is a Senior Oracle Integration Specialist with an emphasis on building service-oriented business processes. Robert has over 7 years of experience in Oracle's SOA Suite and Oracle's Service Bus (10g, 11g and 12c), where his specialty is with BPEL, SCA, SOAP, XPath, XQuery, XML, Java, JAX-WS, Advanced Queueing, and PL / SQL. Since 2007 Robert has been working with Oracle SOA Suite 10g and later with SOA Suite 11g and is a Lead SOA Developer. Robert started working for AMIS Services in the fall of 2011 where his knowledge broadened on Oracle's Service Bus and Oracle's BPM Suite. Robert is a frequent author of blog-articles on the AMIS Technology Blog and he coordinated, stimulated and participated in writing blog articles for AMIS celebrating the GA of SOA Suite 12c. Robert is also a SIG leader for SOA Suite at AMIS and for the Oracle Dutch User Group (OGh). Robert participated in the SOA Suite 12c Beta program (both on site at Oracle HQ and remotely at AMIS) and organized most of the activities around the Beta program at AMIS. Robert has presented on many different conferences, including Oracle OpenWorld 2013, the SOA Suite 12c Community Launch Event in The Netherlands (organized by AMIS and Oracle The Netherlands) and at the Oracle Fusion Middleware Forum 2015.
Rolando Carrasco is a SOA Architect, co-founder and part of the S&P Solutions team in Mexico and Latin America. He’s been working with Oracle SOA since 2003/2004, and his professional career has been focused in the integration space. He worked for HP and Oracle. In Oracle he was part of the Product Management team with responsibilities in the Latin-American region. Rolando is also co-director of the Oracle Users Group in Mexico (ORAMEX). This user group is focused on Oracle Technology, and since 2012 has been coordinating activities oriented to deliver events for the community, and among other things to coordinate the OTN Tour. Rolando is also an Oracle ACE and co-founder of the SOA MythBusters blog.
This article represents the expertise, findings, and opinions of the authors. 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.