Is Enterprise Java Still Relevant?

When I submitted a JavaOne session with this topic earlier in the year I never anticipated it would be become quite so topical in the run-up to the conference. It meant I had a nice full room. And it was the day after the JavaOne keynote when the major Java EE vendors all spoke about their latest support for the platform. Here we are, picture courtesy of @ArunGupta:

I sent this to my kids and thought I was being quite funny challenging them to Name the new Boy Band! Seems they’re funnier than me as they came straight back with ‘No Direction’….

As you’d expect, the keynote was all about ‘good news’ for EE7 with major product announcements from the 3 largest EE vendors. But is there still really a place in the world for EE7 now that the cloud is the real platform? Anything can run in the cloud, sealed up inside virtualization containers, so does anyone still really care about Java EE? 

Back at the dawn of time, technology platforms were a choice you made and conditioned how enterprise architectures were implemented. The days of the technology-specific platform are not yet over but the cloud is changing the way developers and businesses think about platform - cloud now *is* the platform and these technologies are increasingly just service-related domains within that bigger platform. Does there become a point at which the technology-specific platforms become irrelevant? To muddy the water further, virtualization containers are an increasingly popular technology to wrap around services delivered to the cloud which further hide the details of the technology/language/framework used by the cloud service.  These virtualization containers could be traditional VMs or lighter-weight docker containers or any form of virtualization which seals in the content to a standard deliverable unit of deployment.

And in this environment, is a 16-year old technology that some people were calling “elephantine” 10 years ago actually relevant and a good place to be for new cloud applications? When I thought about how to approach this topic, I decided to go back to the beginning and start with a review of what Java EE set out to solve and how it has evolved from there – to set the context of where it fits in today’s world of cloud and microservices and to help take a view on whether it is still fit for purpose in this world. And, if it is, how would it need to change in order to remain healthy?

Is Enterprise Java Still Relevant (JavaOne 2015 session) 

Genesis

In the 90s,  e-Business placed huge stress on the IT infrastructure. Web servers running serialized CGI scripts in front of the back-ends couldn’t scale. A middle tier was needed both to support a larger concurrent load delivered through the web servers and to reduce the work running in the mainframes. Mainframes and databases continue to house the real business data but the cost of processing the data, combining with multiple sources of data, and presenting it to a new sort of client needed somewhere cheaper to run. Java enterprise specs started to emerge - we had servlets and JSPs to serve up dynamic web pages behind the web-servers but Java was not on the guest-list for the highly-scalable distributed enterprise computing party. For that we had proper technology like CORBA…

But CORBA was late in understanding the need to distinguish between the responsibilities of the app and that of the middleware; it provided little real help in terms of application programming model or management of the application resource environment. Apps were on their own when it came to things like getting connections to data sources and having data resources included in any transaction. Of course, CORBA servers evolved and invented application level frameworks to hide some of this. IBM had a highly sophisticated Managed Object Framework (MOFW) infrastructure in one of our fore-runners to Java EE, called Component Broker. This invented some of the ideas we simplified and standardized in Java EE. 

Enterprise Java introduced containers and defined contracts between applications and containers. Clear separation of concern freed the application from middleware concerns so it contained only business logic and transaction demarcation – all the resource management, transactional enlistment and transactional lifecycle management is taken care of by the container. It seems quite quaint now, but the big breakthrough for Enterprise Java was the EJB. For the first time we have a truly declarative model for transactions, along with declarative security, for a truly ‘enterprise’ bean. EJBs, more than any other spec, created the environment for the enterprise Java Platform that became Java EE (originally J2EE) with multiple commercial vendor offerings. 

The Lean challenge

J2EE now looked strong and grew, gaining widespread adoption, supported by many large vendors – which became less over time as they bought one another…EE grew and grew. It got bigger and better. And bigger. And bigger. Along with the flowers, weeds grew that would one day need to removed like JAXR, JAX-RPC and the non-portable CMP part of EJB. J2EE 4 was a significant achievement and had a significant girth. At this time, lightweight frameworks challenge the orthodoxy and Spring’s IOC container hit the sweet-spot for developers. And while Java EE ploughed on full-steam ahead getting bigger and better, developers looked at their apps and wondered how many really need all of Java EE? For more and more web apps, Spring was enough and EE looked monolithic and old-school. Open source projects proliferated. LAMP stacks grow up alongside Java.

But EE learned. Java EE 5 took lessons from Spring by introducing a more IOC model for EJB3. And Java EE6 took the first proper steps towards a more modular platform with the first profile subset (Web Profile) and CDI components to enable resources to be contextualized to web-request scope. But while a step in the right direction, Web Profile was still far more than enough for a large proportion of Web applications. As a platform, this was not nearly granular enough for emerging next-gen apps.

The WebSphere team’s answer to this challenge was to create WebSphere Liberty in 2012 as part of WAS V8.5 – a truly modular implementation of Java EE. Our customers use it to create lightweight applications running Java EE 6 or 7 level of specifications for either the Web Profile or full profile of Java EE. It also solved the single biggest barrier to IBM customer adoption of later levels of Java EE – the sheer cost of application migration for all those little spec clarifications that broke bug-compatibility from one version of EE (or SE) to the next. Liberty explicitly versions all its features so each server can run either EE6 or EE7 and completely avoid the whole migration question. 

Containers and containers

But is any of this really relevant anymore? If I can bundle together my app or service and all its dependencies in a virtualization container like docker, expose an API and run the container in the cloud, who cares whether it’s using Java EE or PHP or Node or whatever? Containers can now my unit of deployment rather than EARs or WARs and I can just tear down and replace the whole thing when I update my app. Virtual containers are good for this, especially if the choice of target cloud deployment environment is a little unclear and a degree of portability and insurance is desired. But apps or services don’t run in a vacuum and there is still an app container within that virtualization environment. Managing the content of the virtualization container is now important – we now have to be careful about the weeds growing amongst the flowers inside the virtualization container. Just as before with the emergence of huge numbers of frameworks of varying usefulness and quality, Java EE can be successful in this environment but only when it’s applied in a way that enables the content of that virtualization container to be right-sized for the application. Lets take a look at Java EE inside docker. We make a number of WebSphere Liberty containers available on Docker hub including EE6 & EE7 Web profile and full Java EE7, each building on a common Liberty kernel layer. Its then very easy to build a fully-customized EE docker container by starting with just the Liberty kernel and the specific list of features in a server.xml configuration. But even virtualization containers are just one way to put apps in the cloud – there are other ways too. For example if you just push your WAR to a PaaS like Cloud Foundry or OpenShift you don’t see the EE container – it’s just whatever is in your cloud. When you do start caring is when you need to configure that app container e.g. for resource definitions. Docker and other virtualization containers give me more control than this; you end up owning more stuff but you can configure it exactly how you want and the docker container is a more self-contained unit to deploy portably across clouds. For greatest control, if you also care about topologies or preserving existing automation scripts, you can virtualize just at the IaaS. In all but the very simplest case, you do care about the application container and its configuration. 

A multi-cultural society

Of course, the cloud is not just about Java. The Bluemix cloud, for example, supports an ever-increasing number of runtime environments, with the two most popular being Java (based on Liberty) and Node.js. Node is becoming increasingly important as a server-side runtime, particularly for creating and exposing APIs. What we see is the cloud becoming the deployment platform and surrounding technology-specific application-platforms like Java EE and Node. As the larger technology vendors all become cloud vendors, the vendor investment spreads wider and becomes thinner. We’ve all seen the technology press howling that Java EE is dead but of course it isn’t – it’s just competing in each EE vendor and in each development organization against the other platforms they host or run alongside (and with) it. My own time is divided between Java EE and Node as complimentary parts of the cloud platform.

 

Room for improvement

And there are some things we need to do a better job of within our own organizations. I’ve lost count of the times I’ve heard people say that cloud applications in Bluemix may be Java but they are not Java EE. This is nonsense. An application or cloud service deploying a servlet with CDI, calling other cloud services over websockets, using OAUth to authenticate and passing JSON documents to a Mongo DB is using some non-EE technologies but it is a Java EE application. And can be a very small one at that. So if you are tired of hearing that Java EE is dead, challenge these assertions that are designed to damage it – Java EE is only monolithic if you implement it that way and Java applications that use EE specifications are EE applications however and wherever they run in the cloud. My co-presenter Erin and her team created a new lightweight Java EE app following 12-factor app best practices to demonstrate this. We demoed it for the first time in this session and you can take a look yourself at http://game-on.org/ - play our throwback text-based adventure in the cloud, get the source code, and never underestimate the value of a good pair of 6-inch stilettos.

There are a number of things the EE community needs to do a much better job of, to help itself. Take a look at some of the stuff around the edges…the SpecJEnterprise2010 EE benchmark is a classic example of why EE gets labelled monolithic and old – this needs to be replaced by a modern cloud-friendly benchmark that actually uses EE7 technologies (instead of EE5!), has run-rules for cloud, and supports running just a Web profile subset. All the EE vendors are part of the Spec committee for that benchmark – what on earth are you taking so long over? Are you scared of more vendors publishing?

Outlook

Java EE is at a crossroads. It’s still strong and relevant at the cloud party, but the younger guests are making more noise. The vendors support an increasingly diverse cloud environment and while their development dollars are still going to Java EE, all the marketing money is going to the new stuff. So it’s not surprising we see less evangelizing of Java EE in the past. But EE has to help itself if it want to survive and thrive. Enterprises want new without breaking existing. Java EE has the advantage of incumbency in the enterprise but it will lose it if Java SE or EE break backward compatibility in their rush to evolve and stay vital. The need for Applications to have to perform any migration in order to stay on the platform as it evolves must be avoided at all costs - as mentioned earlier, the cost of migration is the single biggest barrier of adoption of the latest versions of Java. The future should be bright – Java EE 8’s focus on web standards is good. Worrying about cloud multi-tenancy at the Java level is probably a waste of time though - these days I’ll use a virtualization container for that.

If you care about Java EE – speak up about it and what it’s good for. The engineering is as strong as it ever was and ideal for the cloud, even if the marketing people are distracted by their newer toys. As that old survivor Sheriff Woody would say, “Reach for the sky!”