Analysts see Java EE dying in an SOA world

By Rich Seeley, News Writer10 Jul 2006 | SearchWebServices.com

RSS FEEDS:   News on SOA, EAI, Web services

Java Platform, Enterprise Edition (Java EE) is not going to survive as a major standard programming model in the next five years, predicts Richard Monson-Haefel, senior analyst with the Burton Group, and SOA is part of the reason.

In five years, Java EE will be the CORBA of the 21st Century. People will look at it and say, 'It had its time but nobody uses it any more because it was too complicated.'

This past week, Burton set off a bombshell with the release of a report by Monson-Haefel titled "JEE5: The Beginning of the End of Java EE." Like one of those prehistoric animals that went extinct because it got too big to live off the available foliage, the Burton analyst said that with the release this spring of JEE5, the Java EE platform has grown too complex to be workable for enterprise developers, who are increasingly looking at alternatives such as Ruby-on-Rails.

Monson-Haefel's conclusion is as stark as any death certificate: "JEE5's failure to address complexity is a harbinger of the Java EE platforms' fall from dominance in the enterprise development platform arena. Organizations should look elsewhere when considering new enterprise development and should plan for the eventual sunset of Java EE as an enterprise solution."

The Java EE platform will go the way of other once promising standards, such as CORBA (Common Object Request Broker Architecture), which eventually fell out of favor and usage, he said.

"In five years, Java EE will be the CORBA of the 21st Century," Monson-Haefel quipped. "People will look at it and say, 'It had its time but nobody uses it any more because it was too complicated.' "

He took pains to emphasize that he is only sounding the death knell for the Java EE platform and not the Java language.

"The Java programming language is not threatened here," the Burton analyst said. "I think the Java programming language is going to continue to thrive and be the mainstay for most enterprise development for years to come."

Monson-Haefel is not the lone analyst predicting the demise of the Java EE platform or in viewing SOA as part of the reason.

"Java EE's days have been numbered for a while now," said Jason Bloomberg, senior analyst with ZapThink LLC, who also sees the main culprit being the increased complexity that comes with each new version. "Clearly, every time a new version comes out or module gets added, it only adds to the complexity. Eventually, it'll simply collapse under its own weight. It's not like there will be a future version of Java EE that's more lightweight than its predecessor."

Complexity aside, Bloomberg, who specializes with SOA and Web services, sees the Java platform as fatally flawed when it comes to moving into the service-oriented enterprise era.

"The Java EE world is fundamentally not built for SOA," the ZapThink analyst said. "Now, you can build perfectly good SOA implementations on Java and many of the SOA implementations in production today depend on their J2EE-based runtime infrastructure. In fact, Java is many things – an object-oriented programming language, a virtual machine infrastructure and the Java EE flavor of Java is specifically a framework for implementing n-tier architectures. Unfortunately, none of these facets of Java, or any other virtual machine-based, object-oriented runtime environment for that matter, are ideally suited as a platform for SOA."

Object orientation (OO) as implemented in Java EE does not fit well with the service orientation that is the heart of SOA, Bloomberg argues.

"From the OO perspective, a service and a service instance are the same thing," he said. "The whole notion of an object instance as an individual thing provides little value in SOA."

Nor is the virtual machine in Java EE the right approach for SOA, Bloomberg argues.

"The goal of the virtual machine is to provide for code portability, while in SOA, interoperability is far more important," he said. "Why go through all that trouble to build portable code, when in SOA, you want to leave the code where it is? Fundamentally, the virtual machine approach to distributed computing is through the serialization of objects leading to remote method invocation, while SOA runs on the exchange of messages between services with contracted interfaces."

From Monson-Haefel's perspective, the service orientation makes the need for a unified platform such as Java EE irrelevant.

"SOA certainly diminishes the importance of a common programming model," the Burton analyst said. "Because it's not what's serving up the communications that's important, it's the communications itself. It's the data you're exchanging. It's the method in which you're exchanging the data that matters, not the programming model behind the data."

Java EE's primary benefit was in providing a common programming model, but that isn't of primary importance when developing for the SOA world, Monson-Haefel said.

For more information Forrester: Digital Business Architecture emerges from SOA

"SOA and Web services diminished the importance of what you have running on the backend," the Burton analyst said. "They emphasize how you interface with each other, which is XML and HTTP for Web services, for instance. What's running behind the scenes is really less important."

Finally, ZapThink's Bloomberg said the Enterprise JavaBeans/Servlet/Java Server Pages framework doesn't jibe with SOA.

"You'll see that Java EE focuses on providing a framework for scalable n-tier architectures like those that large, transactional Web sites require," Bloomberg said. "However, if you were to set out to create an enterprise-class framework for SOA, you'd build something quite different. You'd build a framework centered on enabling and maintaining the services abstraction layer so critical to SOA. So, while Java EE is well-suited for running platform-dependent services, it is not built for SOA."