News

Introducing the Integration Cloud Service

ics18
Oracle released some more Cloud offerings and in this article we introduce the Integration Cloud Service. This cloud service lets your organization create integrations between cloud applications, but also between cloud and on premise applications. Create connections to well-known and less known SaaS applications using a bunch of cloud adapters, publish or subscribe to the Messaging Cloud Service, or use industry standards like SOAP & REST. The available set of cloud adapters will certainly grow in the future when the marketplace is fully up-and-running.

Java Cloud Service – initial impressions for WebLogic architects and administrators

jcs3
There’s no doubt that “the cloud” is coming, even in the relatively conservative world of mission-critical Oracle platforms.
At the end of 2012 I took a trial of what was then “Java (or WebLogic) as a Service” (now known as “SaaS Extension”). Back then I wasn’t hugely impressed – yes, I could deploy a simple web app, but the WebLogic environment was very heavily constrained and almost entirely hidden from the administrator – no WebLogic console, no WLST, minimal logs. As a result as soon as I tried to deploy something non-trivial, in this case Apache Roller (the software running this blog), I ran into all sorts of class white-list issues and with little debug information so I quickly gave up in despair!
Anyway here we are, over 2 years later, and Oracle’s latest “Java Cloud Service” (JCS) is looking far more promising, so here are my initial impressions of what I’ve seen and read. First things first: JCS comes in 3 variants:
Java Cloud Service – SaaS Extension: essentially this is product I tried previously which is now targetted at extending Oracle’s SaaS applications (including cloud-based Oracle Fusion Applications), presumably with relatively simple ADF apps.
Java Cloud Service – Virtual Image: this is a single instance WebLogic VM intended for development use and simple testing.
Java Cloud Service: the “full” version (Oracle doesn’t seem to have a distinct name to differentiate it) which can be clustered and is designed for production workloads.
For this article I’m only going to focus on the last of these options, i.e. fully clustered WebLogic with root level access to the VMs but automated provisioning and management provided by Oracle! 
Pricing
Before we get into too much technical detail, let’s get an idea of pricing for a single, production-grade environment. To keep it simple I’m going to make some assumptions:
I need WebLogic Suite for all its various benefits, as well as the option to run SOA Suite, etc.
I’m only considering a 2 node cluster of 2 x 2 vCPU (or 2 x 4 vCPU) running in a single data centre.
The cluster is of static specification and running 24/7 for a year.
I need a load balancer to front my cluster and for SSL termination.
Oracle has come up with a term called the Oracle (OCPU) for billing purposes. 1 OCPU equates to the “CPU capacity of an Intel Xeon E5-2600 … processor core with hyper threading enabled. Each OCPU corresponds to two hardware execution threads, known as vCPUs.” Elsewhere (I can’t find it now) I’ve seen it called a “2012 model 3.0 GHz Xeon core”, which would be an E5-26xx (v1) processor, though, like Amazon EC2, I suspect there will be some variability – if you’re lucky you might “land” on a new E5-26xx v3-based server. Very sensibly Oracle are allocating those vCPUs from the same cores (see below) – modern hyper-threading gives you a performance boost but it’s a long way from double the single core performance, and having vCPUs on hyper-threads on different, fully populated, cores would be very bad for performance.

A Word About Microservice Architectures and SOA

mircoservice1
Microservice architectural style is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API. These services are built around business capabilities and independently deployable by fully automated deployment machinery. There is a bare minimum of centralized management of these services, which may be written in different programming languages and use different data storage technologies
The article overall it’s a fantastic piece of work (really suggest you read it). The way Microservice Architectures it’s defined opens up a few pandora boxes (in a good way I think) which I will talk about subsequently.
First of all, if you are familiar with SOA and it’s guiding principles this will seem very familiar (read for example). Yet, if you noticed the highlighted texts, it’s not quite the same as what we are used to in traditional SOA. The truth is, wether we accept it or not, SOA architectures evolved around the adoption of certain design patterns (such as Enterprise Service Bus (ESB), canonical schemas, centralised contracts, -see  for more) and the use of SOA specific infrastructures to build and deploy services and APIs became the approach of choice (note that the service vs API topic it’s not discussed in this post. For my view on this read ).
From my perspective, I would define Microservice Architecture’s as both 1) a design pattern and 2) a discipline for delivering services and APIs. To elaborate further based on my conclusions I can highlight the following guiding principles:
Delivering business focused and lightweight services/APIs that are truly design, built, deployed and executed independently of each other (meaning that in terms of infrastructure dependencies, they share very little)
Strong focus on people collaboration and communication as the main mechanism in the adoption of best practices and standards rather than common set of strict guidelines and standards that constraint the way services are define, built, deployed and maintained
DevOps (config management, deployment automation, CI, Continuous Delivery) as a fundamental building block rather than a value add
Scalability should be easy as services are very lightweight and stateless (The same service can run in many servers and DevOps makes the deployment process automatic and easy)
Doesn’t encourages the use of monoliths to deploy services (a monolith is for example an application server or an ESB). Services should run almost as demons
One can argue that SOA architectures can also satisfy the listed requirements as SOA it’s really an architecture paradigm that can be realised in different ways. I personally think this myself and I would regard Microservice Architecture as a SOA design pattern, however as per my previous point, comparing it with traditional SOA architecture’s there is a difference.

SOA MythBusters

soamyth5
So, do you work with Oracle SOA Suite?, that’s great because we also do, every single day since a long time ago. As Oracle professionals, we’ve seen the SOA stack grow, change, incorporating new products and technology with each version, from 10g to 12c.
We’re Rolando Carrasco (Oracle ACE) and Arturo Viveros (Oracle ACE Associate), the SOA Myth Busters from Mexico, and as we go with this series we will put to the test a number of questions, myths and urban legends regarding both SOA & the Oracle SOA Platform in seek of finding out which myths are true and which are not
.

Many organizations use multiple software systems for their own purposes. Different software systems often need to exchange data with each other, and a web service is an increasingly common method of communication that allows two software systems to exchange this data over the internet.

A very plain definition for the concept of “web service” would be the following:

“A web service is a method of communication between two electronic devices over a network.”

The W3C Web Services Architecture Working Group, has furthermore defined a Web Services Architecture, requiring a specific implementation of a “web service” in the following way:

   “…a web service has an interface described in a machine-process able format (specifically WSDL). Other systems interact with the Web service in a manner prescribed by its description using SOAP (Simple Object Access Protocol) messages, typically conveyed using HTTP with an XML serialization in conjunction with other Web-related standards…”