Thursday Jan 26, 2012

PaaS is not Middleware over IaaS

When I use Google docs, I am not aware of what middleware components its implementation is using. Google docs might be built on BigTable or it might not, but as a user of the product, all middleware implementation details of it are irrelevant to me. I also don’t care about the infrastructure side of things such as the operating system being used to execute the computations behind my spreadsheet. These details would also be irrelevant to me as an IT organization that might have chosen to introduce Google docs as its office tools solution. That is, from the point of view of the IT organization, all that matters is that the application’s functionality is reliably delivered to my organization’s end users. This is in fact the core value proposition of a public SaaS to IT: The concern for the ownership and maintenance of the underlying middleware and infrastructure is completely shifted from the IT organization to the SaaS provider. The diagram below illustrates this IT delivery model.

[A note on reading the diagrams in this entry: Consider anything within the aaS gray space as available to the IT shop, but without the burden of maintenance which is shifted to the aaS provider]

With this understanding in mind, it is worth considering what the equivalent scenario is for a Platform as a Service (PaaS) solution. If I introduce a PaaS solution in my enterprise, the benefits from an IT organization should be exactly the same: The concern for the ownership and maintenance of the underlying middleware and infrastructure should be completely shifted from the IT organization to the PaaS provider. The only difference from a SaaS point of view is that I am now also able to create custom applications and deploy them on my PaaS environment. These custom applications would enhance and complement my set of SaaS delivered applications. From a development point of view, the developers of these custom applications should still be able to leverage middleware technologies and concepts (web apps, web services, messaging, and so on) to develop great applications, but they should in turn be freed from the need for concern of the maintenance of these middleware technologies. This to me is the criterion of what constitutes a PaaS and the diagram bellow illustrates where it fits relative to an Infrastructure as a Service (IaaS) and SaaS solution.

Now, as I have been introducing the Java Cloud Service – part of the PaaS services of the Oracle Public Cloud - to our customers, I have found that sometimes, the expectation is of an environment where the administrators would be able to provision machine instances (with specific CPU/memory footprints, file storage properties, and so on) that have a pre-installed set of Fusion Middleware products (WebLogic Server, Oracle Web Services Manager, ADF, etc…). The picture behind this thinking is as follows.

Effectively, this model is to use an Infrastructure as a Service (IaaS) layer to host and manage middleware in a traditional manner. To be sure this model has benefits, in that the concern for the ownership and maintenance of the underlying infrastructure is shifted from the IT organization to the IaaS provider. This means that the IT organization no longer has to worry about machine hardware space or OS patches and updates. However, notice that the concern for the ownership and maintenance of the underlying middleware remains exactly the same as if the middleware was running within on-premise, non-IaaS delivered, infrastructure. The IT organization would still have to purchase the packaged middleware components and have a set of trained administrators to install and maintain it. Therefore, this model is in my view not a PaaS, but can be characterized much more accurately as Middleware over IaaS.

The Middleware over IaaS model today provides more flexibility to application administrators in that they have full control of the middleware runtime environment and its infrastructure knob. However, the beauty of a PaaS model is that it promises to eliminate the need for the control of these parameters altogether. The ultimate PaaS solution would be able to automatically deduce the optimal runtime environment for an application and automatically adjust it as the needs of the application and its usage evolve. To give some concrete examples, with a PaaS solution you would not need to worry about whether the application server’s clustering protocol uses multicast or unicast, or what the exact JMS destinations that must be created for your application are. Instead, the PaaS solution will automatically figure out these details for you and make your application available in a reliable manner based on quality of services policies alone (e.g. this application is more important than the other, or requests for this application should never take longer than 1 second to complete).

Such a solution is of course not going to materialize itself overnight in the PaaS world for the entire spectrum of applications out there. However, my expectation is that as PaaS offerings mature, this vision will become a reality for more and more complex and varied types of applications. This evolution should then allow enterprises to move from a Middleware over IaaS type of cloud solution to a PaaS solution. Now, if you take this predication to its logical conclusion, the diagram below could then represent the IT shop of the enterprise of the future.

As we progressively move towards IT shops that are purely PaaS and SaaS delivered, the world of IT should as a result become incrementally simpler and more cost effective. This is because the burden of the ownership and management of the entire middleware and infrastructure will be shifted to the PaaS/SaaS providers letting IT focus instead on its true core capability, which is of course the timely delivery of business applications. With the Oracle Public Cloud, Oracle is introducing a solution that will allow for a big leap towards this end.

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. 

Tuesday Aug 12, 2008

Links To The Past...


Since dev2dev articles have been moved to OTN, I thought I should add here a quick reference to the new links of the three articles that I had authored. Here they are along with a quick blurb on their relevancy in the world as we know it today:



Creating Callback Enabled Clients for Asynchronous Web Services: Even though this article is now over 3 years old (wow, time sure does fly!), it might sill have some useful content. The concepts discussed are fairly protocol neutral specially when it comes to the discussion regarding the creation of stand-alone Java clients for asynchronous web services that provide a callback interface.



An Introduction to Business Process Testing using JProcessUnit: Unfortunately the JProcessUnit code-share project, the main subject of this article, got lost in translation during the Oracle transition. In the next few days I will try to see what the best way is for me to somehow make at least the downloads for the project available. If I can do so, I will update this paragraph with the links.



Kaizen, BPM, and Agile Methodologies: This is my most recent article and the subject of my previous blog entry so I won't babble any more about it.




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.


« October 2016