Busting the UBR Revisionists

I'm sorry - that whole thing about the UBR being an interoperability test really bugged me. And it wasn't just Microsoft that sent out the BIG FAT LIE, IBM did it too.

So, how do you prove 'revisionist' thinking on the web? That's easy - you go back in time. Yes, you visit the WayBackMachine!

And I quote from the Microsoft UDDI site:

"How can you get involved in UDDI? If you are a business, you need to start thinking about how you will transition your company to the world of Web Services. IT architects should read through the UDDI specifications and start thinking about which Web Services your company will define and publish in the UDDI Business Registry. If you are a software developer, you should download the Microsoft UDDI SDK. If you are a software company or an ecommerce portal, you need to start thinking about how you will integrate your products and services with the UDDI Business Registry."

Or do you prefer this one:

Most importantly, UDDI involves the shared implementation of a Web Service based on the UDDI specifications. This Web Service -- the UDDI Business Registry -- is an Internet directory of businesses and the applications they have exposed as Web Services for trading partners and customers to use. Business programs will use the UDDI Business Registry to determine the specifications for programs at other companies in a manner similar to how people use Web search engines today to find websites. This automated application-to-application discovery and integration over the Internet will help eliminate many of the configuration and compatibility problems that are preventing businesses from more widely adopting B2B, despite B2B's potential for cost savings and improved efficiency.

What I don't understand - is how these marketing-whiz-kids thought that they wouldn't get called out on this. This is the age of the Internet - where everything is archived.

See it for yourself:
http://web.archive.org/web/20040718020748/uddi.microsoft.com/about/default.aspx

Some Past Predictions...

Ok - I nailed almost all predictions... except I missed it all by one year.

http://schneider.blogspot.com/2003_12_28_schneider_archive.html#107314457798165610

Take a look at #1, 7 & 10 - oh yea - can you say SCA?


BTW - here is the 2003 list:
http://schneider.blogspot.com/2003_12_28_schneider_archive.html#107262788720914053

And yes, hind sight is 20/20...

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.

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.

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."

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

SCA and Location Coupling

For some reason, I'm fairly obsessed with coupling. I've written a few things on the subject: Dynamic Coupling and A Coupling Index.

I've been monitoring the progress of the IBM/BEA Service Component Architecture for quite some time now. One area of interest to me is the concept of 'spatial' or 'location' coupling (or decoupling, if you prefer).

On many occasions, developers create a model whereby they make an assumption about the caller:

1. The caller will be local (not incurring network issues)


2. The caller will be remote (incurring network issues)

In our quest to progress down the decoupling continuum, the issue of 'location assumption' must be addressed. Hence I was quite pleased to see the following text in the SCA whitepaper:

"Components and their service interfaces can be designed for purely local use by other components, or components can be designed for remote access, either from other parts of the business or from other businesses. Local components can use interfaces optimized to exploit the co-location of the service client and the service implementation. Services designed for remote use must take account of the potential for the client being connected over a remote link and so must offer interfaces that are compatible with this remoteness."

I've been wondering... what will end up being a bigger event, the release of SOAP/WSDL or the release of SCA/SDO. Only time will tell.

Refabricating Architecture

I just finished reading the book, Refabricating Architecture. The book isn't about software; the domain is the architecture associated with 'building construction' (apartments, homes, etc.) I enjoy reading these books as part of a personal cross-training program. There are a couple items that I wanted to share:

"The way to art in much twentieth century theory and practice would be by means of a thorough transformation of production. Architecture as a mass-produced product would transform both access and perception; it would become a thing, a commodity, a vernacular shelter for the twentieth century. Great architecture is today equated with art. Commodity, most believe is the creed of the philistine. It is possible, however, to see commodity instead as the crucible of art itself and to recognize the process engineer - not the design engineer - as the high priestess of this new art. It is not the engineer as the designer of artifacts that we applaud, but rather as a designer of processes that show the way forward in art."

Authors, Kieran and Timberlake, go on to state:

"The single most devastating consequence of modernism has been the embrace of a process that segregates designers from makers: The architect has been separated from the contractor, and the materials scientist has been isolated from the product engineer"

First, let me state my position. I am interested in the commoditization of software architecture. I am embarrassed by the current state of voodoo architecture, wizard architects and clean-sheet implementations. Don't get me wrong, I'm not stating that we should quit inventing or innovating. There is a place for 'material scientists', just not inside of every Fortune 500 I.T. shop...

SOA has the potential to act as the 'material enabler' of the commoditization of software architecture. Modern methodologies will act as the 'process enabler'. Pure and simple - this is my goal. I realize that wizard architects will refute this. They'll hate the concepts of the software factory, mass customization, template architecture and meet-in-the-middle methodologies (not top down). It attacks their creativity and their personal income potential. The true professionals however, will see the ultimate value and find the art in the discipline.