David Chappell

  • September 2020
  • November 2017
  • April 2017
  • October 2016
  • March 2016
  • February 2016
  • August 2015
  • April 2015
  • December 2014
  • October 2014
  • September 2014
  • August 2014
  • July 2014
  • June 2014
  • May 2014
  • April 2014
  • March 2014
  • February 2014
  • January 2014
  • December 2013
  • November 2013
  • October 2013
  • September 2013
  • August 2013
  • July 2013
  • June 2013
  • May 2013
  • April 2013
  • March 2013
  • February 2013
  • January 2013
  • December 2012
  • November 2012
  • October 2012
  • September 2012
  • August 2012
  • July 2012
  • June 2012
  • May 2012
  • April 2012
  • March 2012
  • February 2012
  • January 2012
  • December 2011
  • November 2011
  • October 2011
  • September 2011
  • August 2011
  • July 2011
  • June 2011
  • May 2011
  • April 2011
  • March 2011
  • February 2011
  • January 2011
  • December 2010
  • November 2010
  • October 2010
  • September 2010
  • August 2010
  • July 2010
  • June 2010
  • May 2010
  • April 2010
  • March 2010
  • February 2010
  • January 2010
  • December 2009
  • November 2009
  • October 2009
  • September 2009
  • August 2009
  • July 2009
  • June 2009
  • May 2009
  • April 2009
  • March 2009
  • February 2009
  • January 2009
  • December 2008
  • November 2008
  • October 2008
  • September 2008
  • August 2008
  • July 2008
  • June 2008
  • May 2008
  • April 2008
  • March 2008
  • February 2008
  • January 2008
  • December 2007
  • November 2007
  • October 2007
  • September 2007
  • August 2007
  • July 2007
  • June 2007
  • May 2007
  • April 2007
  • March 2007
  • February 2007
  • January 2007
  • December 2006
  • November 2006
  • October 2006
  • September 2006
  • August 2006
  • July 2006
  • June 2006
  • May 2006
  • April 2006
  • March 2006
  • February 2006
  • January 2006
  • December 2005
  • November 2005
  • October 2005
  • September 2005
  • August 2005
  • July 2005
  • June 2005
  • May 2005
  • April 2005
  • March 2005
  • February 2005
  • January 2005
  • December 2004
  • November 2004
  • October 2004
  • September 2004
  • August 2004
  • July 2004
  • June 2004
  • May 2004
  • April 2004
  • March 2004
  • February 2004
  • January 2004
  • December 2003

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