Friday Oct 21, 2011

Oracle Java Cloud Service - A Public Cloud for Real World Enterprise Applications, Part II - Integrated

Time to tackle another reason why the Java Cloud Service is well suited for real world applications: pre-built integrations. 'Integrated' is an easy word to throw around, so let me attempt to describe what I mean.

Each Java Cloud Service instance is integrated with a set of common services - built on Fusion Middleware products - that are made available by the Oracle Public Cloud. These services fall into the following three broad categories:

  • Identity Management
  • Service and Application Management
  • Integration Services

Out of the gate, the identity management services of the Oracle Public Cloud consist of an LDAP based identity store and a Single Sign-On (SSO) access management service. You will be able to take advantage of these services through an Oracle Public Cloud concept known as a service group. A service group is an administrative scoping mechanism. You define the service group to which an Oracle Public Cloud service (of any type, that is whether it is a Java service, a DB service, or a Fusion Applications service) belongs at provisioning time.

One of the reasons why you might want to associate multiple service instances with the same service group is for the purpose of making sure that they are sharing the same LDAP based identity store and are part of the same SSO realm. You can populate your service group's identity store with the users, groups, and roles that applications deployed to service instances within the service group need. Under the covers, the WebLogic Domains that form the service instances that are part of the same service group will be configured with a WebLogic Server authentication provider that will be pointing to the same LDAP server. From a SSO perspective, you will have the option to enabled SSO for all applications deployed to service instances within the same service group. Perimeter authentication will be performed for all protected pages, and once a user is logged it to one application, he will stay logged in when accessing others within the service group. Both the configuration of a common identity store as well as perimeter authentication are complex configuration which require expert knowledge of Identity Management concepts and technologies. However, the Java Cloud Service's integration with the Oracle Public Cloud common Identity Management service makes makes this configuration unnecessary and its resulting benefits seamless.

The second set of common services available to all Java Cloud Service instances are those in the service and application management category. Every service group is associated with its on management service which exposes environment monitoring and application management functions. Through these services, you will be able to perform monitoring functions such as retrieving usage and performance metrics about your service instances and deploying, stopping, starting, and un-deploying individual applications. These services are exposed through a Command Line Interface, Ant Tasks, IDE features (through integration with Eclipse, NetBeans, and JDeveloper - more on that in another post) and Enterprise Manager based web console, and finally a REST interface. Together they should serve the needs of the different types of external users of the Java Cloud Service such as developers, build engineers, and operations management staff. These needs are of course addressed without the need to install any additional software or hardware within your premises, thanks to the built-in integrations of the Java Cloud Service.

Finally, the common integration services available to the Java Cloud Service are all about interoperability with Oracle Public Cloud Services of other types. For starters, two such integration points exist. The first is between the Java Cloud Service and the Database Cloud Service. When you associate a Java Cloud Service instances and a Database Cloud Service instance with the same service group, the Java instances will be pre-configured with JDBC data sources pointing to the schema encapsulated by the Database service instance in the cloud. Since this data source will be a WebLogic Server JDBC data source, all of the benefits they provide, such as for example connection pooling and testing, will apply, except that the work associated with the configuration of the data source will be completely abstracted by the Java Cloud Service's common integration services.

The second element of the common integration service is regarding the secure invocation of web services between the Java Cloud Service and Fusion Application services. Applications deployed to the Java Cloud Service can contain Web Services call-outs to the Web Service end-points exposed by Fusion Applications instances within the cloud (actually they can also make the calls to web services endpoints outside of the cloud as well). These invocations will automatically be made - thanks to the use of the Oracle Web Services Manager under the covers - with a SAML based WS-Security policy which will automatically propagate the identity of the user logged into the Java Cloud Service application. In an on-premise environment, there would be quite a bit of work involved in ensuring that this identity propagation is performed over an encrypted link (e..g think credential and key store setup), but in the Oracle Public Cloud, it will happen seamlessly, thanks to the common integration services.

This blog entry only touches on the integrations built into the Java Cloud Service. There is a lot more to be said and done on that topic and a great deal of exciting features that can be thought of in terms of integrations of the Java Cloud Service with other Oracle Fusion Middleware products. All of this makes the Java Cloud Service a powerful solution in optimizing the deployment of real world enterprise Java applications in the cloud.

Friday Oct 07, 2011

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. 


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.


« August 2016