Service Oriented Enterprise


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.

posted by jeff | 4:35 AM


Friday, December 16, 2005

Is REST Needed?  

Mark "I won't rest until you REST" Baker is at it again. In a recent presentation, Mark tells the population:



He goes on to state:



and the follows it up with several slides like this:


Yes Mark, you can order a pizza with SOAP, with REST, with CORBA, with RMI, with EJB and more. What's your point? The world needs REST? Let's be clear: "REST" is unnecessary - as is all of this stuff! If we want to build our distributed systems with Sockets and EDI we could - BUT WE DON'T!

Mark - if you want to compare and contrast REST and Web services than do it right. This is crap and you know it. The funny thing is, I'm a REST fan - I just can't stomach this one-sided bullshit.

posted by jeff | 5:43 AM


Wednesday, December 14, 2005

Bye Bye MS UBR!  

Just received this email:
You are receiving this mail because you have registered as a publisher on the Microsoft node of the UDDI Business Registry (UBR).

The primary goal of the UBR was to prove the interoperability and robustness of the UDDI specifications through a public implementation. This goal was met and far exceeded, and now the UBR is discontinuing its operations. As part of this process the Microsoft UBR node at uddi.microsoft.com will be permanently unavailable for all operations beginning January 12, 2006. Data stored in the UBR may be retrieved until January 12, 2006 and used in accordance with the UDDI Business Registry terms of use available at http://uddi.microsoft.com/policies/termsofuse.aspx. You may find the UDDI Data Export Wizard useful for retrieving your data, and it is available here: http://www.microsoft.com/downloads/details.aspx?familyid=9D467A69-57FF-4AE7-96EE.

For more information, please see the frequently asked questions related to the UBR discontinuation at http://uddi.microsoft.com/about/FAQshutdown.htm. You may submit feedback to Microsoft at the following location: http://uddi.microsoft.com/contact/default.aspx.

Thank You,
Microsoft UDDI Team


Did I just read that..."The primary goal of the UBR was to prove the interoperability and robustness of the UDDI specifications through a public implementation." Revisionist history is a true thing of beauty. Any chance Microsoft could resend it the email and replace the aforementioned sentence with this one:

"The UBR was a really dumb idea and we apologize for making you sit through lectures on a service oriented yellow pages hosted in the cloud."

posted by jeff | 10:51 PM


Mr. Don Box,  

Mr. Don Box,
It wasn't too long ago that you were sniffing around JBI - asking all the right questions. It was clear that you had concerns - as did I.

That said, what's your take on 'Service Component Architecture'?

More precisely, do you agree with the approach given the capabilities of the Java language (and knowing that the Java binding was key)?

Secondly, do you see an SCA binding to .Net components being valuable for your large customers that have mixed platforms?

Respectfully submitted,
Jeff

posted by jeff | 4:05 PM

archives