SOA and Web 2.0 - chalk and cheese?

This post on SOA World starts out with the kind of glib assertions that normally make me very suspicious:

SOA brings together people, not just software. That's why integrating Web 2.0 concepts into a SOA-such as comments, feeds, ratings, tags, and automatic search alerts-holds so much promise for breaking down business silos and enabling many people to work together for the first time.

SOA - bringing people together? I don't think so... at least not until the applications that front-end the services in a SOA platform choose to apply themselves to social networking. But then it occurred to me that the most successful SOA-based platforms provide that success by integrating user profiles and event notifications with the Web Services backbone that integrates the functions needed by the users. I'm thinking of Rearden Commerce, salesforce.com and others which - although they see themselves as Saas and SOA rather than Web 2.0 - provide the kinds of Web 2.0 features that the article quoted above is espousing: even if these come in the form of corporate policy people doing the tagging and rating which is used by the people whose spending they're trying to trace and control.

The death (or at least redifintion) of middleware

This post by Neil Ward-Dutton on his company's blog makes the point that:

In the mid 1990s, "middle" meant "the gaps between applications and software components". Middleware was technology you turned to in order to try to build distributed systems: we were faced with transaction processing middleware, database middleware, object middleware, and so on...

Now, when you see most of the talk about "middleware", "middle" means "the gap in a technology stack between an operating system and packaged applications". Middleware is now defined largely by vendors from a software product marketing perspective, rather than by customers from a technology perspective.

I have a small quibble with the initial definition (from my admittedly CORBA focus). In the mid-90s I saw middleware as a way of building applications from distributed - sometimes reused - software components.

However I agree that middleware is becoming an increasingly vague and marketing driven term. I'm often distressed that leaders in the IT industry are claiming that Web Services is the "obvious" (or even the "only") choice to make when building or integrating distributed applications, while at the same time claiming that Web Services is not middleware! The disclaimer seems to be indicating that you can't expect the same level of platform support from WS* that used to come with CORBA, or Transactional middleware, because "Web Services isn't designed to do the same thing".

My question then is "Why are you using it to do the same job, if it doesn't - and isn't expected to - provide the same facilities as 90s middleware to the distributed application developer?"

SOA's dirty little secret

This recent ZDnet post claims that the dirty little secret of SOA is that it places more responsibility on IT departments that used to rest with software vendors. It claims that we now need a new breed of super service aggregators. Interesting observation. Hopefully Smart Services CRC can step into this space and fill the void.