Saturday, December 17, 2005

Obsolescing J2EE

Without a doubt, the biggest story of 2005 has been the radical obsolescing of J2EE. As much as I would like to say that the J2EE was completely obsoleted, that would be incorrect. Service Component Architecture (SCA) only makes about 75% of J2EE obsolete. Remember, SCA targets: invocation, data structure and composition mechanism.

My Java friends hate when I refer to J2EE as a "deprecated API". Of course, this is an exaggeration - no one actually deprecated the standard. More accurately, one could say that "SCA has superseded J2EE". Or if you want to be politically correct you could say, "SCA represents an abstraction layer to the J2EE component, data and invocation model." Yes, in the short term you will likely use J2EE API's significantly inside of your SCA components. But later, the vehicle of choice will likely become the DSL that 1. Does the job the best 2. Reduces the impedance mismatch.

For those of you that are building out your SOA Reference Models and Architectures, MomentumSI is now recommending a section that discusses the "SOA Programming Model". And of course the most common will be:
1. Java Web Services (JAX-RPC, JAX-M, JAX-B, etc.)
2. Service Component Architecture (SCDL, WSDL, etc.)
2.A SCA with Java only bindings
2.B SCA with XYZ bindings
3. Microsoft Windows Communication Foundation
4. A combination of 1-3 (the most common answer)

So, if we obsolete Java 2 Enterprise Edition - any guess what is obsoleted after that? Bulls eye. Ya gotta love the variation of "embrace and extend" called "Abstract, Replace and Transition"... I can just hear it now... "We warned you about the JCP!" Bam!


---- S I D E N O T E
SCA doesn't mandate domain specific languages like JSP. So, yes JSP is safe - from SCA that is. However, it is clear to me that the AJAX, Ruby on Rails and the Web 2.0 movement will redefine the enterprise reference architectures for the Presentation and Collaboration Layer. The bottom line is that the tolerance continuum allows us to use light weight protocols, dynamic languages and late binding at the presentation layer. Why? Because humans are the best 'fault handler'. Remember: "tolerance over rigidity on the presentation layer!" So although SCA isn't directly attacking J2EE presentation layer, I believe that J2EE presentation vehicles will lose to more tolerant solutions.

No comments: