Oracle Java Cloud Service - A Public Cloud for Real World Enterprise Applications, Part I - Open
By Reza Shafii on Oct 07, 2011
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:
- 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.
- 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.
- 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:
- Combine your deployment archives into one and lose modularity.
- Modify your application's OR mapping layer to use a new persistence model and thus tie-yourself into a proprietary technology.
- 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.