Simon Haslam's Oracle Fusion Middleware blog

SOA Cloud Service - initial impressions for SOA architects and administrators

Yesterday Oracle officially released their SOA Cloud Service (SOA-CS) - see the SOA team's blog post. As with Java Cloud Service (JCS) back in May I thought I'd write up my initial impressions, based on what I've learned so far about SOA-CS "on paper" and drawing on quite lot of hands-on experimentation with JCS.

Firstly, given that it sometimes feels like Oracle is announcing cloud services on a near daily basis at the moment, here's how Oracle positions SOA-CS:

 Oracle SOA on-premises, SOA-CS and ICS

In other words, SOA-CS is the cloud delivered equivalent of SOA Suite (the same relationship as JCS is to WebLogic) and gives you full control of the software via VM access. Integration Cloud Service (ICS) and Process Cloud Service (PCS) are higher level versions of these products with simplified user/administration experience.


Before we go too far let's consider pricing. JCS has some relatively complex options for pricing, depending on whether you pay for continuous running or metered by the hour or month, whether you have full JCS or Virtual Image, whether to use standard or high memory, and the edition of WebLogic you want. For example, a 24/7 cluster of two high memory, 1 core WebLogic Suite nodes costs you (2 * $2175 + $2100) * 12 = ~$77k pa including the web tier load balancer (plus you need to subscribe to database and storage cloud services).

SOA-CS pricing for SOA/OSB has such no options so is much simpler - there's a single price of $5500 per month per OCPU (i.e. Xeon core - see earlier article). I'm very pleased to see that the "Load Balancer pricing will be based on Compute Service", by which I would like to think that Oracle will just charge you the base price for the compute service - customers with clusters will already be spending a considerable amount so I think it's reasonable that the load balancer should be inexpensive.

Unfortunately I can't make head nor tail of the Compute Service pricing page - it doesn't seem to specify the actual compute cost, only the extras. Therefore, for the sake of estimation, I'm going to assume 1 OCPU compute is the price of the cheapest full JCS option (non-metered SE is $338 per month, so $4k pa) - that includes the cost of compute, WebLogic software, tooling and support so isn't dissimilar from Traffic Director. It would be more sensible for Oracle to just have an identical "Load Balancing Service" OCPU price across all relevant PaaS services in my opinion.

Therefore I estimate that a minimum-sized SOA-CS cluster will cost $136k pa, a little less than I'd expected based on JCS and Oracle on-premises pricing. Oracle will also be offering their SOA adapters (Salesforce etc) on SOA-CS for an additional fee (not yet announced).

Important Note: just because this configuration is the minimal size it it is not low performance: 2 cores, or 4 vCPU, of SOA processing (minus some for the Admin Server) on modern Xeon servers would be sufficient for production, at least for OSB and possibly SOA, for many of my customers.

Not having a Virtual Image option does raise the question of what customers will do for test systems - will they cost the same a production? Also Disaster Recovery (DR) is a little unclear for Oracle Public Cloud as a whole - if for this price DR to another Oracle data centre was included then that would make a significant difference since for on-premises software Oracle charges you full price for DR.

Of course, like most things in life, real world pricing will depend on what deal you can do with Oracle...


Now that we have the grubby topic of money out of the way, let's consider the topology offered. As you might expect this looks very similar to JCS, for example I expect a 2 node SOA-CS cluster would be:

Expected SOA-CS 2 node cluster topology

Whilst it will probably still have the Admin Server on a managed server node, with SOA-CS all of the VMs are high memory shapes so the smallest will have 15GB (and many may choose 4 vCPU VMs which have 30GB memory), therefore a 4GB "lump" may not be quite so offensive/inefficient.

As with full JCS you need to supply a Database Cloud Service instance for the FMW repository and a Storage Cloud Service container for backups.

Although I provisioned SOA 12c on JCS earlier in the summer as an experiment, trying to build an Enterprise Deployment Guide (EDG) style environment presented a couple of key challenges:

  • Shared storage: there's currently no OS-level shared storage service in OPC. Block level shared devices, which you could in theory configure on JCS, are not supported. For my SOA 12c example I set up an NFS server in a utility VM but I don't pretend for a moment that is a robust production configuration. The options ought to be an NFS share presented by a ZFS appliance (which is probably the most conventional approach), storing the transactional data in the database, or I suppose it wouldn't be impossible to use an external messaging service. It will be interesting to see what Oracle have done here.
  • Multiple managed servers on a single VMs: I actually quite like to have one big managed server per VM - whilst it bucks the current trend for containerisation, with modern virtualisation platforms it's not actually particularly expensive when pooling licences but makes the isolation of performance issues considerably easier. However for a typical SOA EDG you have multiple managed servers - SOA, OSB, WSM, ESS, BAM. In theory some of these can be merged together (and future WebLogic multi-tenancy will help here too) but for now I'm not sure what Oracle is doing since JCS only supports one managed server per VM. I'll keep you posted.
Coherence note: I have been doing interesting things with Coherence recently, especially as SOA 12c makes much more use of it. With JCS you can easily run a separate Coherence cluster (albeit costing the same as WebLogic VM so it's not cheap). Coherence is not yet mentioned from what I've seen of SOA-CS so I'm assuming is using clients in the SOA managed servers, but you can imagine some high performance solutions appearing in the future.

Provisioning Approach

If you've tried JCS, or watched my OTN VTS webcast, you'll find provisioning SOA-CS a doddle. The only new considerations are:

  • Domain contents: you can currently choose OSB only, SOA (BPEL) only, both OSB+SOA, or API Manager
  • SOA adapters: there will be a number of the SOA Suite adapters available for you to request pre-installed in your domain

The main provisioning screen looks like this:

SOA-CS Service Bus main provisioning page

All of those fields are identical to provisioning full JCS without Coherence. 

There really isn't anything much to add on top of the detailed observations I made on JCS - you will end up with a set of Oracle Linux VMs, running SOA Suite, with automated patching/backup, all running in Oracle's data centre.

Data Centre Integration

The real elephant in the room, and something I touch upon in my OTN JCS session, is the integration between Oracle public cloud and your on-premises systems.

Today if you commission a new data centre you usually have an interconnect of some sort which allows your data centre LANs to co-exist and talk directly to one another. Whilst there will be routing and firewalls in place, as the middleware administrator, you usually don't need to worry too much. The equivalent to this with a public cloud provider would be a VPN, something like Amazon Virtual Private Cloud which I like a lot.

At the moment Oracle cloud doesn't have a VPN service but I gather it's on its way. Oracle are also talking about various approaches where you have some kind of software/device that sits between in your data centre (almost certainly in the DMZ) and provides a gateway to Oracle services. Depending on the level of abstraction chosen this could behave like a VPN, acting as a tunnel, or else could work at the application level like a service bus. Either way, I foresee that this is where most initial challenges will lie - even if your even if your organisation has adopted a "cloud first" approach I think you'll have substantial number of existing systems running on premises that will need integrating for some time.


SOA Cloud Service looks very promising indeed. This will give administrators the full capability and control of SOA Suite, and hopefully do things in the manner they would have done themselves. Other than the actual integration across data centres, which I expect to be an evolving topic, I can see SOA-CS as a very natural place to run orchestration and integrations. I hope to write up more detailed observations and experiences of SOA-CS over the coming weeks.

Note: the final showing of my OTN Virtual Technology Summit session is later today (or tomorrow morning in Europe) - free registration is at



Ah, after further digging I've found from the SOA-CS Known Issues document ( that deployment plans must be copied to managed servers and that adapter HA is not currently supported. Therefore it seems highly likely to me that there's no shared storage yet and that Oracle are using the database for storing JMS and JTA transactional data (a perfectly valid approach with some trade-offs).
Stay tuned..!

Posted by Simon Haslam on September 29, 2015 at 10:07 PM BST #

I've just noticed today that the SOA CS pricing page ( now says that OTD is now "based on JCS Suite General Purpose Compute" ($2100 pcm non-metered) price, not "based on Compute Service" as it said previously.

In the above calculation I assume Compute for OTD equated to around $4k per year, giving $136k pa, whereas with JCS Suite metered the load balancer is costing $25.2k, a total of around $157k pa for a minimal-sized SOA CS cluster. Hmmm.

Posted by Simon Haslam on November 07, 2015 at 12:28 PM GMT #

Post a Comment:
Comments are closed for this entry.

Search this blog

About me
Oracle ACE Director (Middleware and SOA)
Presentation downloads

I'm speaking at Oracle OpenWorld

UKOUG Ambassador Partner
Oracle WebLogic Server 12c Certified Specialist
Oracle WebLogic Server 12c Certified Specialist