Java EE, R.I.P.?

After the last post I still owe you an opinion about “Analysts see Java EE dying in an SOA world“. Well, here it is (perhaps a little overstated):

This article is fundamentally flawed. It confuses the SOA architectural approach, SOA environments and frameworks, services and service implementations. It implies wrong architectural attempts to prove the inability to deliver something upon it. It ignores todays tool ladden development environments that manage complexity quite well. It even dismisses Java as a plattform — for reasons that would also apply to .NET –, at the same time contradicting itself.

I picked just some points to justify may statements:

• “The Java EE world is fundamentally not built for SOA”. SOA is about architectures that (technically speaking) deal with message exchange patterns between independend services. Java EE on the other hand is an implementation technology for those services, i.e. it covers the inner workings of a service and its interface. For this Java EE is perfectly suited. Confusion of SOA and service implementation.
• Also the same paragraph states that “Java is specifically a framework for implementing n-tier architectures” which has been the architecture of choice for scaleable and reliable web applications even before they have been adorned with SOAP interfaces. Contradiction.
• “Object orientation (OO) as implemented in Java EE does not fit well with the service orientation that is the heart of SOA”. This implies that the OO approach is used at the SOA level, i.e. accross services. This is exactly what remote object technologies (CORBA, DCOM, RMI) tried to do. They failed — hardly any news at all — and services entered the stage to address the respective problems. Implication of wrong architectural attempts. (Again, this does by no means rule out Java as implementation technology for services itself.)
• “It’s the method in which you’re exchanging the data that matters, not the programming model behind the data.” So, if the programming model does not matter from a SOA perspective, why dismiss any programming model at all? Why argue about virtual machines or portability in the first place? Contradiction.
• “You’ll see that Java EE focuses on providing a framework for scalable n-tier architectures like those that large, transactional Web sites require”. Which is also exactly what business services need. Contradiction or just lack of understanding? 
• “However, if you were to set out to create an enterprise-class framework for SOA…” Now what is that? A framework to unify the service implementations? And I thought “the service orientation makes the need for a unified platform such as Java EE irrelevant.” Contradiction. Or does this refer to some kind fo SOA plattform, say an ESB? Who just said “it’s not what’s serving up the communications that’s important, it’s the communications itself.” Contradiction. And by the way: The only noteable SOA plattform not built on Java is MS BizTalk.
• …

Now, I can understand that analysts riding the SOA hype need to attract attention and statements that strong do that especially well. But these staements do not do them credit, rather they show some vital lack of understanding of SOA* — or deliberate obfuscation. Which one, I cannot say. I can only hope that they have been quoted distortingly or out of context.

* It cannot be lack of understanding of Java EE since one of the quoted analysts is an author of well regarded books on Java (J2EE Web Services and Enterprise JavaBeans 3.0 — which I own myself. Sic!)

As I said: This may be overstated, but it’s straight to the point. And it’s only an opinion, no insult intended!

So, well… . I — yeah, that is me, the one who usually signs its posts with AJ.NET — can firmly stand up and announce publicly and unequivocal with loud and clear voice:
Java EE ist still alive and kicking! Any reports allegedly anouncing his death are wrong.
As we say in german: “Totgesagte leben länger…” (proverb, something like “people declared death/written off live longer…”).

Please note that I’m not saying that the role of Java EE (read EJB) is not changing: Au contraire! It is quite obvious that lightweight approaches gain more and more momentum in situations where EJB is overkill. But there still are complex demands that ask for transactional and component life time services, security, operations support, etc.. I guess it boils down to “use the right tool”. However, the fact that our toolbox has more items in it does not mean one should throw away the “older” tools. Usually they got old because they had value.

That’s all for now folks,
AJ.EE 😉

Advertisement