Oracle Java Cloud Service - A Public Cloud for Real World Enterprise Applications, Part I - Open

The Oracle Java Cloud Service was announced by Larry Ellison at Oracle OpenWorld last week. I have been fortunate to be part of the Oracle team who is behind this new and exciting product, but until now I was not able to write about it since we were keeping the project under the wraps until its big unveiling at OpenWorld. With the announcement now behind us, I will be focusing my blog entries on the Java Cloud Service and its various capabilities going forward. I would like to begin by discussing the fact that the Java Cloud Service is designed from the ground up as a Cloud solution for real world enterprise applications. This is a big difference between the Oracle Java Cloud Service and most of the other Java PaaS offerings out there so let me attempt to articulate how this is so in this and subsequent blog entries. 

The first reason why the Java Cloud Service is a solution suited to real world enterprise applications is its openness: You can think of the Java Cloud Service truly as a Java EE container in the cloud and not as a new proprietary container in the cloud. This means that you can use it in exactly the same way as an on-premises Java EE environment and deploy your enterprise Java applications on a Java Cloud Service instance as is. Let's say for example that your application is made-up of a WAR file with a JSF based web application that acts as a client to a set of SLSB EJBs within a separate EAR file. The business logic encapsulated by the SLSBs in turn uses EclipseLink JPA as an Object-Relational (OR) mapping technology for the application's domain model. This is a fairly common application pattern out there and therefore a good sample for a real-world enterprise application. Within the Oracle Public Cloud, you can create the environment for deploying this application within a couple of minutes. All you need is a Java Cloud Service instance that is associated with a Database instance, you can then deploy the application's two deployment archives, and you are done. To deploy the same application on other Java based cloud solutions however, you would have had to worry about a number of things that you just don't have to with the Java Cloud Service:

  1. The fact that your application uses EJBs, since not all Java clouds support their deployment even though they are an important part of the Java EE toolkit for implementing application business logic. 
  2. The fact that your application uses JPA and hence a relational database. Again, some Java cloud solutions don't support an RDBMS persistence model (let alone JPA) and require you to use their custom cloud persistence API thus locking you into the cloud. 
  3. The fact that your application consists of multiple deployment archives. Many public cloud solutions out there only allow for the deployment of a single Java EE deployment archive. However, a significant number of enterprise applications consist - usually for reasons related to modularity - of multiple deployment archives.  

What this means is that to deploy your application to any other Java public cloud solution, you would have had to:

  1. Combine your deployment archives into one and lose modularity.
  2. Modify your application's OR mapping layer to use a new persistence model and thus tie-yourself into a proprietary technology.
  3. Re-write the application business logic so that it does not use EJBs and in the process, potentially lose the benefits brought on by the technology, such as transactionality, remoting, and security.

As should be obvious, such changes would imply a significant negative cost and flexibility impact. Therefore, it is safe to conclude that for any serious enterprise application, no IT shop would be eager to contemplate them just to get the benefits of a public cloud. With the Oracle Public Cloud and the Java Cloud Service on the other hand, none of these sacrifices are necessary thus making the Java Cloud Service an ideal solution for real world enterprise applications. 



I've never experienced any enterprise PaaS deployment and the first question that comes in my mind in the case of JEE application deployed in a JEE Cloud is wether it will require the underlining database to sit in a "near" Cloud to avoid performance bottlenecks at the db to bc roundtrips level ?
In which case, moving part of your entire database to a Cloud might be a constraint for your environment in case your database is also used by many other applications other than the Cloud deployed Java application.
Meaning that a Cloud deployment could fit either a marginal and opportunistic deployment or your entire infrastructure.

Your comments are welcome.


Posted by guest on October 08, 2011 at 05:13 PM PDT #


You are absolutely right. There is likely a significant number of
cases where you would want to keep your database on premise, while you deploy
some of its dependent Java applications to the cloud. However, in such
scenarios, latency and security related issues come to play. From a latency
perspective, the question becomes how can you maintain low data access latency
given the fact that your application is in a different WAN (within the cloud)?
From a security perspective, the question is how you can make sure that you can
securely access the data through JDBC when going out of the cloud? We are
looking at features that would address both questions for the Java Cloud
Service. However, in the meantime, it is fair to say that the service is best
suited for applications that are self-contained from an app<->DB access
perspective, so that you can provision your DB within the Oracle Public Cloud
Database Cloud Service and use it from the Java Cloud Service deployed

Hope this helps,


Posted by Reza on October 09, 2011 at 07:55 AM PDT #

Thanks Reza.

The Security side is to me somehow easier to address than the latency one.

Features (I would call innovations) capable of addressing the latency constraint are really going to open up the potential of Enterprise Cloud computing.

A very interesting subject to follow..


Posted by guest on October 09, 2011 at 09:13 PM PDT #

Please, please, please, consider Glassfish as an alternative for WebLogic. We have an application developed in EJB 3.1 and WebLogic won't support it any time soon. We want to move this application to a cloud infra-structure, but without Glassfish it is not possible for the moment.

Posted by Hildeberto Mendonça on October 11, 2011 at 08:10 PM PDT #

If the BL is in the cloud and the DBMS is in your factory you can use JDBC with encription ...


Posted by guest on October 11, 2011 at 08:15 PM PDT #

Reza, welcome to the blogosphere. Where are the pretty pictures?

Posted by James Bayer on October 12, 2011 at 09:06 AM PDT #


No time for pretty pictures yet, but maye some in my next post. Hope you are enjoying the mac. :)


Posted by Reza on October 13, 2011 at 03:28 AM PDT #

Post a Comment:
  • HTML Syntax: NOT allowed

Reza Shafii is the product manager for the Java Cloud Service component of the Oracle Public Cloud. Prior to his work at Oracle, Reza was a consultant within the BEA Systems Consulting practice. Reza is the author of various published technical articles as well as the book Oracle Fusion Middleware Architecture and Management, published by McGraw Hill.


« July 2016