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.

Annoying Patents

It's no secret that I'm opposed to software patents. I believe that the system by which they are registered is not capable of determinining what is truely a novel "invention", and what is derivative in the way that patent protection was designed to operate. As a result this is sometimes determined much later my a court, at great expense, and great profit to the lawyers. In other cases it is used by industry heavyweights with lawyers on their side to bully or bankrupt smaller players who are often responsible for true innovations. More likely, however, a patent is used as insurance so that when someone sues you for a patent infringement, you check your register of patents to see which of them the other party is infringing, and then everyone backs off. Stupid!

So you can imagine my annoyance when I found this patent over the "invention" of Distributed service aggregation and composition which is in my area of research. As usual, it is vague and general enough to apply to a whole host of possible inventions that could arise independently. I suspect that it will be easy enough to find some published prior art... maybe even by my DSTC colleagues, but I'm not sure.

Humph!
|<

Trust is not a property of a service

Since being employed to work at Smart Services CRC, I have been fully engaged with Service Orientation, and in particular with non-functional charachteristics of services. I keep seeing "Trust" mentioned right alongside "Security" when talking about these non-functional properties.

However, it's obvious to me, just using ordinary English semantics, that "trust" is a property (or attitude, or belief) of a service user with regard to a service, or service provider. It is trust that allows a consumer of a service to hand over their credit card details in the belief that the service they are paying for will be delivered without some fraud taking place.

Now I'm sure my colleagues are not stupid, and don't believe that a service can be modelled for trust. As soon as one starts looking at the literature, it becomes obvious that people are attempting to represent aspects of services and their providers that might engender trust in a service consumer. For example, the YAWL Foundation's
Service-Description.com site's model of "trust" actually models endorsements, operating history and other aspects that give the service user a basis on which to trust a service.

I just wish that writers would be a little more reticent to label things as "trust", which are really to do with "reputation".

|<

Why Apple and Google promote an open Web for rich applications

This article gives a good overview of the motivations of Apple, Google, Microsoft and Adobe (among others) in the "broswer plugin wars".

|<