What makes Java EE application platforms different?

The goal of Java EE is to provide a rich collection of standard APIs that offer a stable foundation for web and business applications and portability between Java EE implementations. An often overlooked fact is that the functionality specified in the Java EE specification does not vary between certified platforms. JBoss EAP, IBM WebSphere Application Server editions, and Oracle WebLogic editions are all Java EE 7 full platform certified using the same criteria. The code to implement the Java EE 7 specification certainly varies and contributes to differences in runtime performance. However, the Java EE 7 functionality itself is common.
We must look beyond the implementation of the Java EE specification to find out what makes one Java application platform different from another. Differences in open source project support, total cost of acquisition, and other non-Java EE specification features such as monitoring are often evaluated.
Further comparative differences vary depending on if the application platform is being used on-premise or in the cloud. On-premise differences include features such as broad support for virtualized environments, administration, management, and monitoring. Cloud differences can include storage, networking, scaling, administration, and other features that the application platform should be compatible with.
In some cases, on-premise features and cloud features overlap. When this occurs, product differences can be found in how well the overlapping features coexist. The existence of an on-premise feature should not preclude using a cloud-provided feature when running in that environment. Or vice versa.
Examples of how features can differ in different environments include scaling, clustering, and runtime administration. JBoss EAP has specific code included with the distribution to enable clustering regardless of running on-premise or running in an OpenShift by Red Hat cloud.
When JBoss EAP is run on-premise, clustering and scaling is managed through a choice of administrative tools, including JBoss Operations Network. When running in an OpenShift cloud environment, the cloud native administrative procedures are used.
Red Hat smartly provides a mix of features in JBoss EAP above and beyond the Java EE specification that allow it to run equally well in multiple environments. Where it makes sense, the functionality is seamless, such as with the clustering example. In other cases, where it makes sense, Red Hat supports using one overlapping environment over another, like the administrative example provided.

Pivotal’s Java technology, which is not Java EE technology, can be run on-premise using tcServer or in the cloud using Cloud Foundry. Pivotal tcServer is based on the open source Apache Tomcat project to which Pivotal then adds proprietary code. Pivotal recommends creating Java applications using the Spring framework. This framework takes a builder approach to the Java stack where build tools, and at times manual configuration by developers, add needed libraries into the build process.
Functional overlap related to Java coding is less of an issue than the different environment capabilities applications are deployed to. When this comparison is made, the runtime functionality available in Cloud Foundry is greater than that available for on-premise deployment using tcServer. An example of this is out-of-the-box scalability and load balancing of stateless 12-factor Java applications in the cloud that is not matched with on-premise use of tcServer.
However, in some cases functionality available on-premise is missing from the Cloud Foundry environment. An example of this is a lack of persistent volumes in Cloud Foundry that provide the ability to mount persistent storage. This means Java applications that could write to disk, or supporting applications like databases that run on-premise, just won’t run on Cloud Foundry. Pivotal encourages Java applications to be re-written to be stateless 12-factor applications which is a time consuming and potentially expensive process. Applications that can’t be rewritten this way must run outside of the Cloud Foundry environment.
OpenShift by Red Hat does offer persistent volumes for applications like JBoss EAP, databases, and all other deployed applications. Persistent volumes are available for all stages of an applications running lifecycle including automatic mounting of persistent storage as the applications scale up and down.

IBM WebSphere Application Server has limited variability in on-premise and BlueMix cloud deployments. This is due to the fact that the product can run natively in virtual machines for on-premise or in IBM BlueMix virtual machines.
However, IBM has several features in WebSphere Liberty Profile including administration, security, clustering, and intelligent management that overlap between the on-premise and the BlueMix cloud environment. When these features overlap, the runtime characteristics of WebSphere Liberty Profile can be different.
One notable example is clustering. For on-site deployments and BlueMix virtual machines, WebSphere Liberty Profile servers can be clustered within what is known as a collective. When running in an on-premise Docker environment, collectives are currently only available as a V8.5.5.6 beta feature with no guarantees that functionality will be in the general release. When running in the IBM BlueMix containers environment, collectives are not supported at all. When run as a BlueMix buildpack, standard Cloud Foundry features control collections of servers and associated functionality.
Another functional overlap is intelligent management and scaling. For on-site deployments, the full functionality of this feature set is available. For Docker environments, the functionality it still in beta. For BlueMix container environments, the beta functionality of IBM WebSphere Liberty Profile v9 beta is not documented as supported or unsupported. And finally, for BlueMix Cloud Foundry, IBM intelligent management features for scaling are not supported.

Oracle differences between user managed onsite and cloud deployments of WebLogic can be primarily found in the setup procedures.
On-site deployments provide the greatest setup flexibility for customers who have complete control over the infrastructure and WebLogic installation options. Customers who use the Oracle Java Cloud Service are limited to configuring the number of cores per virtual CPU, memory, and storage options that Oracle makes available. Customers who use the Oracle Java Cloud Service – SaaS Extension have even fewer options.
The primary reason for limited variability in the on-premise and Oracle Java Cloud Service is that Oracle is using virtual machines via the Oracle Compute Cloud Service to provide the WebLogic cloud offerings. The Oracle Compute Cloud Service takes care of provisioning, connecting, and otherwise managing the virtual machines. What runs on them is of no concern to the Oracle Compute Cloud Service. In the case of Weblogic, the Oracle Java Cloud Service simplifies deploying the virtual machines bytakes care of this providing a limited scope of available WebLogic editions and possible configurations that users can choose from.
The use of virtual machines allows users to use standard Oracle on-premise tools in the cloud for all WebLogic offerings other than the SaaS Extension. However, it also means that Oracle is not providing an overarching PaaS offering. The administrative procedures Oracle Java Cloud service are different from the other tools used by applications that might run on the Oracle Compute Cloud Service. While this results in a consistent WebLogic administrative experience, it does not provide a consistent administrative experience for other middleware or applications that would run on the Oracle Compute Cloud Service.

Comments are closed.