David Chappell

Opinari

Get the Feed! Subscribe

The Real Threat to Java EE  
# Friday, August 04, 2006
 
A report from Richard Monson-Haefel, Senior Analyst at the Burton Group, got a great deal of press coverage last month. The report's key message is that the venerable J2EE, known in its latest incarnation as just "JEE", is on the way out. The report also generated some responses from Java EE vendors, who not surprisingly see things differently. A big part of Richard's argument is that Java EE is just too complex, and that the latest version, JEE5, doesn't really improve this. As a result, he believes, organizations should look to other platforms such as Microsoft's .NET Framework or Ruby on Rails for future development.

Richard's a smart guy--I have lots of respect for his work--and nobody can deny the complexity of the Java platform. Yet this discussion about Java EE's future omits what I would argue is the most important threat it faces: Service Component Architecture (SCA). SCA effectively provides an alternative way to accomplish much (although not all) of what Java EE offers. Furthermore, SCA is created and promoted by today's leading Java EE vendors, including IBM, BEA, and Oracle. It can't be a good sign when the vendors with the largest market share in a technology band together to create an alternative to that technology.

Like Java EE, SCA is being created by a committee, and committees (especially committees of competing vendors) seldom create simple technologies. Just how usable SCA will ultimately be remains to be seen. And the vendors behind SCA take pains to point out that it can be used with existing Java EE technologies such as EJB. They have to say this, of course, since telling existing customers that their current investments are headed for obsolescence isn't a smart thing to do. Nonetheless, applications that today might rely on EJB, Java RMI, JMS, or JAX-WS could in the future use SCA instead.

The success of SCA isn't assured; the vendors behind it still have plenty of opportunities to screw it up. But I don't think they will--too much is riding on its success. And assuming that SCA is successful, it should displace (and yes, simplify) important parts of Java EE. In fact, I'd bet that the vendors behind SCA agree wholeheartedly with the Burton Group's assessment of Java EE's complexity. With SCA, each vendor wants to make sure they provide a good alternative whenever a customer does decide to step off the Java EE path.


6 comments :: Post a Comment

 


Comments:

He says J2EE is complex, not J2SE with Spring for example. He doesn't recommends ruby or .net.
 

Apologies but "Rubbish Dave!" ...

I thought you were smarter than Richard Monster-Headcase, I am not so sure now!

SCA is about service composition and decoupling the transport/protocol binding, nothing more nothing less ...

While you are careful to point out that it perhaps renders some of J EE protocol/distributed APIs less relevant (such as RMI and JMS) J EE is much more than that and SOA and SCA does not address web facing client/server applications, database access, security, transactions, scalability etc etc the list goes on and on!

One could even argue that SCA could be used to describe components that would naturally bind to 'classic EJB', JMS/MDB, or even JAX-WS, which with it's annotation scheme is scariily close to what SCA does ... or vica versa!

J EE is evolving, a "living" std, not something we solidified in 1997! There is no reason why J EE cannot and many reasons why it should can and will evolve to embrace SCA as another (bloody) component model on the server.

I dont believe any of the vendors that have created SCA have claimed either privately or publically that SCA is an alternative to J EE ... nor will they, simply because it's not ... go read the specs!

all the best

- Larry Cable
 

To Anonymous: Actually, Richard does explicitly recommend Ruby or .NET or something else. Here's a quote from the report: "Although it is not necessary to remove and replace existing Java EE deployments, for future development, organizations should consider alternative frameworks such as Linux, Apache, MySQL, PHP/Python/Perl (LAMP), Spring, Hibernate, RoR, and Microsoft .NET, which offer simpler and more productive programming models".

I feel obliged to point out that I'm neither agreeing nor disagreeing with Richard's assessment. My point is that SCA really is intended to replace parts of J2EE, and so people need to understand this.
 

To Larry Cable: I have read the specs. Perhaps you've seen the comparison I wrote late last year of SCA and WCF.

As you point out, there are many things in Java EE that SCA doesn't address, such as browser applications and database access. But my post doesn't dispute this. Instead, as you seem to agree, I describe how SCA provides an alternative API for the functionality offered by RMI, JMS, and more. And the 0.9 specs explicitly describe plans to add support for transactions, security, and other functions. In the same way that Microsoft's WCF supersedes Enterprise Services, .NET Remoting, and other communication-oriented aspects of the .NET Framework, SCA has the potential to supersede EJB, RMI, and and other communication-oriented aspects of Java EE.

SCA does more than this, as you also point out, addressing service composition and other areas. Still, the technology described in the 0.9 specs is capable of displacing significant chunks (although certainly not all) of Java EE.

And while it's possible that the vendors who control SCA will decide to put it into the official Java EE embrace, I'd be surprised to see this happen. If this was their goal, why invent a process outside the JCP to create SCA?

Finally, I don't usually allow posts to my blog that contain personal insults. Making fun of Richard's name is more than a little unprofessional. Please don't do this in future comments.
 

You said: "As a result, he believes, organizations should look to other platforms such as Microsoft's .NET Framework or Ruby on Rails for future development."

Richard said:
"Although it is not necessary to remove and replace existing Java EE deployments, for future development, organizations should consider alternative frameworks such as Linux, Apache, MySQL, PHP/Python/Perl (LAMP), Spring, Hibernate, RoR, and Microsoft .NET, which offer simpler and more productive programming models".

You said he recommended 2 platforms and he really recommended 4 platforms (including Java!). Or as I see, he didn't recommend the full J2EE especification.
 

I guess that to me the phrase "such as" indicates that I'm giving examples, not the complete list. Richard's report does clearly state that he believes the Java language has a good future--it's specifically Java EE that he's concerned about. Once again, though, I'm not expressing an opinion here about Richard's report--I'm just quoting from it.
 

Post a Comment


<< Home