Opinari

Subscribe

Opinari #16 Posted: SOA and the Reality of Reuse  
# Wednesday, August 30, 2006
 
Will software reuse really be much easier with SOA? I'd like to believe the answer is yes, but my experience so far suggests otherwise. The latest issue of my Opinari newsletter, available here, explains why.

I'd like nothing more than to be wrong about this. After all, it's still relatively early days for SOA, and some organizations have seen successful service-based reuse. Still, the overall picture so far isn't especially encouraging. The inevitable move to services brings plenty of benefits, but I'm becoming doubtful that widespread reuse of business logic will be among them.

5 comments :: Post a Comment

 

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