All I want for Christmas is a new SOA component model

All I want for Christmas is a new SOA component model

Summary: This impressive standards initiative may well be the first step to establishing a new runtime tier to accommodate SOA.

SHARE:

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.

Topic: Enterprise Software

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.

Talkback

3 comments
Log in or register to join the discussion
  • Still doing stories on SOA...?

    Hi Dana,

    Still stuck doing stories on the non-existent SOA universe? You must have really p*ssed off someone pretty high up there in the ZDNet hierarchy.

    The facts speak for themselves, as do the complete lack of talk-backs around the subject, SOA is a non-starter. Nobody cares...

    Everyone out here in customer land can see that it is just another buzzword from the brainless marketing 'droids over in the boiler room. It just describes what we've all been doing for a decade now. It's no more than a new name for existing technology, coined with the desperate hope that some greedy bastard can convince us to buy his new hype machine that none of us need.

    Ask your boss to give you a real assignment. You're too good to be wasting yourself on SOA.

    Regards,
    Jon
    JonathonDoe
  • Disagree with your understading of SDO, SCA

    SDO and SCA are a way of implementing end-points in Java, and that is it. The primary motivation is this:
    If you are an app developer that wants to consume a non-Java (say .Net) service using WS and also read from a legacy database using JCA and also need to read data from a database and integrate all that, you don't have to juggle between a JCA API to access legacy system, a JDBC API to access database, and Java-WS API for accessing WS. The SDO will hide all that behind and provide a unified interface to all these data, so you can program against a single API.

    .Net ALREADY has this kinda ability and it is called ADO.NET.
    rtraja
    • Not quite

      SCA and SDO are language neutral: you'll note a C++ specification on any of the partner web sites. SCA is highly complementary to languages like BPEL.

      In any case, I would take issue with parts of Dana's analysis: SCA is not about tight coupling. The "component model" -- and maybe that was a poor choice of terms -- describes metadata required to connect services. Ultimately, some concrete binding is necessary to establish a communication channel, but there's nothing to say this cannot be highly dynamic and applied in an execution environment. SCA is deliberately agnostic about how services are implemented, though it does propose a high level programming model for Java. I tend to think of it as being "lightweight" and more analagous to Spring (note that the forward thinking folks at Interface21 are involved with SCA as well).
      Greg Pavlik