All I want for Christmas is a new SOA component model

They are back at it. Software infrastructure vendors have a new (old) approach to alleviate the noxious old (new) complexity for allowing different business applications to have something to do with one another. We've been down this alley before, and we can only hope that this time the relief lasts and it doesn't cost too much.
Allow yourself to be introduced to the two new kids on the block: Service Component Architecture (SCA) and Service Data Objects (SDO). And what are they for? Simpler SOA!
Yep, just when you thought the Java-.NET wars were quieted by an increasing I wonder whether enterprises might not be getting ready to punt this expanding onion of application integration. reliance on Web services standards and XML et al, a group of prominent Enterprise Java vendors (BEA, IBM, Oracle, SAP, IONA, Siebel, and Sybase) comes up with SCA. Yes, folks, it's Dueling Component Models for SOA, or, Let's Not Be Too Concerned with That Middleware Stuff After All.
Monty, what do we have behind door number one for our enterprise architect contestants? It's SCA, which describes assemblies of components written from a variety of programming models and protocols in order to make integrating services and applications easier and without regard to specific middleware APIs or languages.
Door number two opens to show us SDO, which offers wide access to business data, be it XML or relational, otherwise known as a standardized way to represent data as it moves to and around a budding SOA service network.
And behind door number three? It's two years of waiting to see if these things actually catch on as standards, gauging whether that standardization actually benefits you, and then figuring out what you need to do to implement them (upgrades anyone?) across your far-flung data centers.
This impressive standards initiative may well be the first step to establishing a new runtime tier to accommodate SOA. Such a new tier would allow for greater portability than Java and BPEL4WS allow, and takes the interoperability of Web service standards to the higher level of letting actual components operate with far more autonomy with regard to underlying infrastructure. The goal seems to be to ensure portability of services among and between different infrastructures.
Incidentally, that would make J2EE and .NET platforms buried lower in the hierarchy of plumbing (middleware?), and hence no longer be where you might apply the creation and coordination of business logic for services. In other words, SCA may be setting up the new "place" where developers and business analysts would use new tools to build composite applications and event-driven SOA business processes. Can you say Legacy and apply it to .NET and J2EE? Sure you can. Sure.
BTW: Funny how the two most conspicuous absentees from the SCA kin are Microsoft and Sun Microsystems. Microsoft, sure, because it demands that you rely on .NET, CLR, and then Windows for runtime, SOA or not. This is otherwise known as, We Make the Development Easy So You Run on Our Stuff Only, SOA or Not. But Sun? The Steward of Java not being in the SCA camp is like all the other kids in the class locking the self-elected hall monitor out of the building.
Remember when Web services standards (WS-*) were there to obviate the need for all that heavy lifting around components and object brokering? Just elevate the applications communications to semantic loosely coupled chit chat, they said. Microsoft used it all to show how oh, so open they are after all. Sun said all you really needed were Java Web services, whatever those are. No wonder Sun is now giving it all away.
Well, now with SCA/SDO for SOA we're elevating the role of the component model again. Heave! This time above the Web services wire protocol complexity we go. Now it's the tightly coupled approach to the rescue, sans the reliance on a single environment. Java, .NET, please take a back seat.
As usual, this exercise is not about peeling the layers back from an onion -- only to find more layers. It's actually adding more layers to the onion in order to hide the lower layers, which are too complex, as you know. And you'll probably need better runtimes and hardware to run it all because level 16 is emulating level 14 to level 9, which is translated to level 15, etc. etc.
This time the new required layer to provoke simplicity to hide the complexity will result in ... More necessary investment from the enterprises in more software infrastructure to reduce the complexity that the last round of investment has necessitated. All the noise, noise, noise! Baah, humbug.
Now, I see the logic for these vendors in taking computer science to the next level. And I know it's still too hard for business logic-focused developers to create munged and composite applications with nascent GUI tools.  I know, surely, that Microsoft is in love with SOA like a spider loves flies. But I do wonder whether today's enterprises might not really, truly, finally be getting ready to punt this expanding onion of application integration and ubiquitous data access mess for good.
I wish the major software vendors well with SCA/SDO for SOA. I hope it makes application interactivity easier. I really want to see additional standardization of acess to the resources for business data and logic, regardless of the underlying platform. I do.

And, hey, I'm okay with separating the assembly of business logic from the underlying wire protocols. Do it. Perhaps they are right, and a significant portion of the "services" assembled in an SOA will be from the same container type, and therefore assembly can be automated, err ... standardized, based on tight association between the tools and the middleware. Fine. Either way, same or hetero. Fine.
I just have sneaky suspicion that Adam Bosworth may be on to something, and that AJAX, RISK, Web 2.0, and the ad model (not component model) wave will be pushed higher and faster by such efforts as SCA/SDO for SOA. Then maybe we can look to Google, Salesforce.comanche, Comcast, and at&t to manage the onion soup. The rest of us can then just use the apps and do business, and to hell with the next new way to simplify application integration.